Vishing w 2026: dlaczego phishing głosowy to dziś główny wektor naruszeń w chmurze

Vishing jest dziś drugim wektorem pierwszego dostępu

M-Trends 2026, oparty na ponad 500 tys. godzin reagowania na incydenty prowadzonego przez Mandiant w 2025 roku, ustawia kolejność jednoznacznie. Na pierwszym miejscu, szósty rok z rzędu, są exploity z wynikiem 32%. Zaraz za nimi phishing głosowy: 11%. Vishing nie wyprzedził exploitów, ale wyprzedził wszystko inne: wcześniejsze naruszenie, skradzione dane logowania i phishing e-mailowy.

Druga liczba jest ciekawsza od pierwszej. Phishing e-mailowy spadł z 14% w 2024 roku do 6% w 2025. To nie wahnięcie próby, tylko konsekwentny trend. Bramy pocztowe, sandboxing i przepisywanie linków zrobiły swoje: opłacalność masowej kampanii mailowej spadła szybciej niż koszt zorganizowania fałszywego call center.

W chmurze proporcje wyglądają zupełnie inaczej. Tam vishing odpowiada za 23% kompromitacji i jest wektorem numer jeden, przed przejęciem przez stronę trzecią (17%), skradzionymi danymi logowania (16%) i phishingiem e-mailowym (15%). Exploity spadają do 6%. Wyjaśnienie jest proste: w SaaS nie ma wiele do zeksploitowania od strony sieci, jest za to helpdesk, który potrafi zresetować MFA.

Verizon 2026 DBIR patrzy na to samo z innej strony i dochodzi do zbieżnego wniosku. Czynnik ludzki występuje w 62% naruszeń, socjotechnika jest trzecim najczęstszym wzorcem incydentu (16%), a pretexting (budowanie zaufania pod zmyślonym pretekstem, według raportu „najczęściej głosowo”) wszedł do zestawienia jako osobny wektor z wynikiem 6%. W symulacjach mediana skuteczności kanałów mobilnych, czyli głosu i SMS-a, jest o 40% wyższa niż tego samego scenariusza w e-mailu.

Dlaczego telefon działa tam, gdzie e-mail przestał

Kontrole pocztowe nie mają czego przenieść na kanał głosowy. Filtr działa dlatego, że wiadomość jest artefaktem: ma nagłówki, nadawcę, domenę, załącznik, link. Każdy z nich da się sprawdzić wobec reputacji, wzorca i piaskownicy, zanim użytkownik go zobaczy. Rozmowa nie ma żadnego z tych elementów i nie zostawia nawet obiektu, który dałoby się przeskanować po fakcie.

To nie metafora, tylko konkretna lista rzeczy, których w tym kanale brakuje:

• Brak artefaktu do analizy: nie ma pliku, adresu URL ani nagłówków SPF, DKIM i DMARC; nie ma czego wysłać do piaskownicy
• Brak śladu do przeszukania: bez nagrania w logach zostaje co najwyżej metadana połączenia
• Prezentacja numeru nie jest uwierzytelnieniem. CLI można sfałszować, o czym CERT Polska ostrzega wprost: „Nie ufaj bezkrytycznie wyświetlanemu numerowi lub nazwie osoby dzwoniącej”
• Rozmowa jest interaktywna: napastnik reaguje na wahanie, zmienia argument, podnosi lub odpuszcza presję
• Presja czasu działa natychmiast: od e-maila można odejść na godzinę, a w słuchawce trwa cisza, którą trzeba wypełnić
• Autorytet jest deklarowany, nie weryfikowany: „dzwonię z działu bezpieczeństwa” brzmi identycznie niezależnie od tego, czy jest prawdą

M-Trends nazywa to wprost: choć phishing e-mailowy i głosowy mieszczą się pod wspólnym parasolem socjotechniki, „rozróżnienie między nimi jest kluczowe dla obrońców, ponieważ ataki interaktywne są znacznie odporniejsze na zautomatyzowane kontrole techniczne i wymagają innych strategii detekcji”. Budżet, który poszedł na bramę pocztową, nie kupił żadnej kontroli działającej na telefonie.

Anatomia ataku: od wiadomości do przejęcia konta

Typowa kampania nie zaczyna się od telefonu, tylko od wiadomości, która ma go sprowokować. Ta sekwencja omija kontrole obu kanałów naraz. Cztery kroki poniżej odzwierciedlają przebieg opisywany we wspólnym advisory FBI i CISA na temat Scattered Spider oraz w analizach Proofpointa poświęconych TOAD.

TOAD: e-mail, którego brama nie ma jak zablokować

Telephone-Oriented Attack Delivery to nazwa na wiadomość, która jest wyłącznie pretekstem do rozmowy. Proofpoint opisuje mechanizm bez ozdobników: przekaz zawiera „nie więcej niż numer telefonu i kilka nieprawdziwych informacji”, a łańcuch ataku aktywuje się dopiero wtedy, gdy ofiara wybierze ten numer. Przestępcze call center prowadzą rozmówców do przyznania zdalnego dostępu, ujawnienia danych logowania albo zainstalowania złośliwego oprogramowania.

Z punktu widzenia bramy pocztowej to wiadomość czysta. Nie ma adresu URL do sprawdzenia w reputacji, pliku do piaskownicy ani makra do rozbrojenia. Zostaje analiza treści i kontekstu nadawcy, czyli warstwa, w której generatywne modele językowe zlikwidowały ostatnie łatwe sygnały: kalki, błędy fleksyjne i nienaturalny szyk zdania.

• Wariant finansowy: rozmówca prowadzi do instalacji legalnego narzędzia zdalnego dostępu, przejmuje pulpit i operuje bankowością ofiary; ekran bywa wygaszany, żeby ukryć jego działania
• Wariant złośliwego oprogramowania: ofiara pobiera „narzędzie diagnostyczne” ze wskazanego adresu, co kończy się loaderem, a dalej ransomware
• Wariant korporacyjny: celem nie są pieniądze z konta, tylko kod jednorazowy albo zatwierdzenie monitu MFA, które otwiera dostęp do tenanta
• Wariant odwrotny: kontakt zaczyna się od telefonu, a e-mail lub SMS przychodzi dopiero jako „potwierdzenie” rozmowy

Skala tego kanału jest źle odwzorowana w programach świadomościowych. Proofpoint podaje, że symulacje smishingu i vishingu prowadzi 23% badanych organizacji. Mniej niż jedna czwarta ćwiczy scenariusz, który w chmurze jest wektorem numer jeden. Program kończący się na klikaniu w linki trenuje zachowanie, którego atakujący od tej grupy celów już nie wymagają.

Helpdesk jest celem, bo trzyma klucz do resetu MFA

Największy problem nie polega na tym, że pracownik poda kod, tylko na tym, że helpdesk zresetuje MFA na prośbę osoby, której tożsamości nikt nie zweryfikował. Wspólne advisory FBI, CISA, RCMP, ACSC, AFP, CCCS i NCSC-UK w sprawie Scattered Spider, w aktualizacji z 29 lipca 2025 roku, opisuje ten przepływ jako podstawową technikę grupy: napastnicy podszywają się pod pracowników, aby przekonać personel helpdesku do zresetowania hasła i przeniesienia tokenu MFA na kontrolowane przez siebie urządzenie.

Microsoft opisuje tę samą grupę pod nazwą Octo Tempest i dodaje szczegół przesądzający o skuteczności: napastnicy prowadzą wcześniej rozpoznanie, naśladują sposób mówienia konkretnej osoby i operują danymi osobowymi, które pozwalają przejść standardowe pytania kontrolne. Bywa też, że podszywają się pod świeżo zatrudnionego pracownika, gdzie „nie mam jeszcze dostępu” nie budzi podejrzeń.

Kolumna z kosztem operacyjnym jest tu równie ważna jak odporność. Procedura wydłużająca każde zgłoszenie o dziesięć minut stanie się obejściem w pierwszym tygodniu po wdrożeniu, zwłaszcza przy zgłoszeniu od członka zarządu. Sensownym kompromisem jest stopniowanie: rutynowa sprawa po jednej weryfikacji, reset hasła i przepięcie MFA po dwóch niezależnych, a konta uprzywilejowane wyłącznie ścieżką bez samodzielnej decyzji helpdesku.

// 1. Authentication methods changed by somebody other than the account owner.
//    This is the signature of a reset talked out of the help desk: actor != target.
AuditLogs
| where TimeGenerated > ago(30d)
| where LoggedByService == "Authentication Methods"
| where OperationName has_any ("registered security info", "updated security info",
                               "deleted security info")
| extend Actor  = tostring(InitiatedBy.user.userPrincipalName)
| extend Target = tostring(TargetResources[0].userPrincipalName)
| where isnotempty(Actor) and isnotempty(Target) and Actor != Target
| project TimeGenerated, Actor, Target, OperationName, Result, CorrelationId
| order by TimeGenerated desc

// 2. An admin-driven password reset followed within the hour by a successful
//    sign-in from a country the user has not signed in from before. That gap is
//    the tail end of a hijack that started as a phone call.
let resets = AuditLogs
    | where TimeGenerated > ago(30d)
    | where OperationName has "Reset user password" and Result == "success"
    | project ResetTime = TimeGenerated,
              Target = tostring(TargetResources[0].userPrincipalName),
              Admin  = tostring(InitiatedBy.user.userPrincipalName);
let baseline = SigninLogs
    | where TimeGenerated between (ago(90d) .. ago(30d)) and ResultType == 0
    | summarize KnownCountries = make_set(tostring(LocationDetails.countryOrRegion))
        by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(30d) and ResultType == 0
| extend Country = tostring(LocationDetails.countryOrRegion)
| join kind=inner resets on $left.UserPrincipalName == $right.Target
| where TimeGenerated between (ResetTime .. ResetTime + 1h)
| join kind=leftouter baseline on UserPrincipalName
| where isnull(KnownCountries) or Country !in (KnownCountries)
| project TimeGenerated, UserPrincipalName, Country, IPAddress, ResetTime, Admin

// 3. A help desk operator whose reset volume spikes well above their own norm.
//    Not an incident by itself, but it is the cheapest metric that catches a
//    campaign aimed at one support seat rather than at one user.
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName has_any ("Reset user password", "registered security info")
| extend Admin = tostring(InitiatedBy.user.userPrincipalName)
| where isnotempty(Admin)
| summarize Daily = count() by Admin, Day = bin(TimeGenerated, 1d)
| summarize AvgDaily = avg(Daily), PeakDaily = max(Daily), ActiveDays = count() by Admin
| where PeakDaily > 3 * AvgDaily and ActiveDays > 5
| order by PeakDaily desc

Te zapytania nie wykryją rozmowy. Wykryją jej skutek. To w praktyce jedyne miejsce, w którym vishing zostawia telemetrię: zmiana metody uwierzytelniania wykonana przez kogoś innego niż właściciel konta, reset hasła, po którym natychmiast pojawia się logowanie z nieznanego kraju, oraz stanowisko helpdesku obsługujące nagle wielokrotność swojej normy resetów. Jeśli nikt nie czyta tych sygnałów codziennie, jest to zakres pokrywany przez SOC-as-a-Service.

Klonowanie głosu: co jest udowodnione, a co jest demonstracją

Warto tu oddzielić badania od marketingu. Praca „From One Stolen Utterance”, przedstawiona na IEEE Symposium on Security and Privacy w 2025 roku, przetestowała pięć technik klonowania głosu wobec ośmiu systemów uwierzytelniania głosowego i trzydziestu ludzkich słuchaczy, na materiale ponad 7 tys. mówców. Wniosek: współczesne klonowanie oszukuje zarówno systemy weryfikacji, jak i ludzi, a metody detekcji nie nadążają za nowymi generatorami.

Przegląd przygotowany dla Parlamentu Europejskiego dokłada kontekst rynkowy. 53% osób udostępnia nagrania własnego głosu w internecie, 70% dorosłych nie ma pewności, czy odróżniłoby klon od oryginału, a co czwarty zetknął się z oszustwem opartym na klonowaniu głosu. Do tego 49% firm w badanych krajach zetknęło się z oszustwem wykorzystującym deepfake audio lub wideo.

Gdzie przebiega granica między demonstracją a realnym użyciem? Potwierdzone przypadki dotyczą przede wszystkim oszustw finansowych i podszywania się pod osoby publiczne. FBI IC3 opisało kampanię, w której napastnicy wysyłali SMS-y oraz „generowane przez AI wiadomości głosowe” podszywające się pod wysokich rangą urzędników amerykańskich. Europol odnotował operację, w której przechwycono ponad 7,5 tys. połączeń, zapobiegając stratom przekraczającym 10 mln euro w ponad 80% przypadków.

Czego dane nie potwierdzają: że sklonowany głos jest dziś domyślnym elementem korporacyjnego vishingu. W opisach kampanii Scattered Spider i Octo Tempest przewagą jest rozpoznanie i naśladowanie sposobu mówienia, a nie synteza mowy. Wniosek w obu scenariuszach jest identyczny: skoro głos przestał być dowodem tożsamości, procedura nie może traktować go jako uwierzytelnienia.

Prawdziwy telefon z IT albo z banku a atak

Różnice nie leżą w brzmieniu głosu, tylko w tym, o co rozmówca prosi i jak reaguje na przerwanie rozmowy. Zestawienie opiera się na zaleceniach CERT Polska i FBI IC3 oraz na advisory w sprawie Scattered Spider.

Pierwsze 60 minut po tym, jak ktoś dał się przekonać

Zgłoszenie brzmi zwykle tak: „chyba właśnie podałem komuś kod z SMS-a”. Od tego momentu liczy się kolejność działań, bo przejęta sesja i przepięta metoda MFA przeżywają reset hasła. Poniższy przebieg zakłada jednego dostawcę tożsamości i typową obsadę: użytkownik, helpdesk, zespół bezpieczeństwa.

1. Minuty 0–5Użytkownik i helpdesk
   Zgłoś fakt rozmowy, nie próbuj naprawiać samodzielnie

   Pracownik zgłasza rozmowę nawet wtedy, gdy nie ma pewności, czy cokolwiek ujawnił. Helpdesk nie prowadzi śledztwa. Przyjmuje zgłoszenie i eskaluje. Zanotuj numer, godzinę połączenia i to, o co proszono; te trzy dane wystarczą, żeby zacząć wyszukiwanie w logach.

2. Minuty 5–15Zespół bezpieczeństwa
   Unieważnij sesje i tokeny, nie tylko hasło

   Wymuś reset hasła, a następnie unieważnij wszystkie aktywne sesje i tokeny odświeżania dla tej tożsamości. Sam reset hasła zostawia napastnika w środku tak długo, jak żyje token odświeżania. Jeśli w środowisku działa continuous access evaluation, sprawdź, czy unieważnienie faktycznie się rozpropagowało do aplikacji.

3. Minuty 15–30Zespół bezpieczeństwa
   Sprawdź metody MFA i zarejestrowane urządzenia

   Wylistuj metody uwierzytelniania i urządzenia zarejestrowane dla konta w ciągu ostatnich 30 dni. Każda pozycja dodana w oknie rozmowy lub tuż po niej jest do usunięcia. To krok najczęściej pomijany i to on decyduje, czy napastnik wróci mimo zmienionego hasła.

4. Minuty 30–45Zespół bezpieczeństwa
   Ustal zasięg: skrzynka, reguły, pliki, uprawnienia

   Sprawdź reguły skrzynki i przekierowania utworzone po rozmowie, logi dostępu do plików, zmiany uprawnień oraz nowe zgody aplikacji OAuth. Jeśli konto miało role katalogowe, rozszerz przegląd o operacje wykonane tymi rolami. Utrwal wyniki, zanim zaczniesz sprzątać.

5. Minuty 45–60Bezpieczeństwo, HR i komunikacja
   Ostrzeż resztę organizacji i zdecyduj o zgłoszeniach

   Ta sama kampania niemal nigdy nie dzwoni raz. Roześlij ostrzeżenie z konkretem — jakiego pretekstu użyto i o co proszono — i sprawdź, czy inni odebrali podobne połączenia. Równolegle oceń obowiązki zgłoszeniowe: naruszenie ochrony danych osobowych do UODO w ciągu 72 godzin, incydent poważny zgodnie z obowiązkami sektorowymi. Nie karz osoby, która zgłosiła.

Jeżeli w ciągu tej godziny okaże się, że napastnik zdążył zarejestrować własną metodę MFA albo wykonać operacje z uprawnieniami administracyjnymi, przestaje to być incydent obsługiwany przez helpdesk. To moment na uruchomienie reagowania na incydenty i na potraktowanie tożsamości, a nie stacji roboczej, jako głównego obszaru dochodzenia.

Kontrole, które realnie zmniejszają ryzyko

Vishing jest problemem procesu i uprawnień, nie problemem narzędziowym. Najskuteczniejsze kontrole są organizacyjne i nie wymagają nowego produktu. Wymagają decyzji o tym, kto ma prawo co zrobić i na czyją prośbę. Poniższa lista układa je w kolejności od najtańszych do najbardziej wymagających wdrożeniowo.

Koszt takiego programu rozkłada się na pozycje, których nie zastąpi jedna licencja. Pierwsza to czas helpdesku: dodatkowa weryfikacja wydłuża obsługę, więc liczy się ją w zgłoszeniach miesięcznie, a nie w abstrakcyjnym narzucie proceduralnym. Druga to sprzęt do uwierzytelniania odpornego na phishing: liczba kluczy, ścieżka wydania i procedura na wypadek zgubienia. Trzecia to integracje: alerty z katalogu tożsamości muszą trafiać tam, gdzie ktoś je czyta.

Czwarta pozycja jest pomijana najczęściej: utrzymanie. Hasła kontrolne wymagają rotacji, rejestr kontrahentów wymaga właściciela, a scenariusze symulacji zużywają się po kilku powtórzeniach. Rozsądniej umocować to w cyklu, na przykład w ramach vCISO, niż traktować jako jednorazowy projekt. Odporność zespołu na konkretny pretekst sprawdza się symulacjami socjotechnicznymi obejmującymi kanał głosowy; vishing opisujemy też w przewodniku po rodzajach phishingu, obok spear phishingu i whalingu.

Najczęstsze pytania o vishing

Podsumowanie

Przesunięcie z e-maila na telefon nie jest zaskoczeniem, tylko konsekwencją tego, że kontrole pocztowe zaczęły działać. Napastnicy przenieśli się na kanał, w którym nie ma bramy, nagłówków ani niczego do przeskanowania. Obrona musi przenieść się razem z nimi: do procedury weryfikacji dzwoniącego, do ograniczenia tego, co helpdesk może zrobić na prośbę z telefonu, i do treningu na scenariuszu, który w chmurze jest wektorem numer jeden. Żadna kontrola techniczna nie odbierze za Ciebie tego telefonu.

Rozmowy telefonicznej nie da się załatać ani przeskanować. Jedyną kontrolą, która skaluje się na tym kanale poza pojedynczą osobę, jest procedura mówiąca wprost, czego helpdesk nie zrobi przez telefon, i zarząd, który potwierdził, że odłożenie słuchawki nigdy nie będzie błędem.