VENOM: Kradzież danych kadry zarządzającej z ominięciem MFA

Czym jest kampania VENOM

VENOM to kampania kradzieży poświadczeń wymierzona w kadrę zarządzającą, opisana przez Arsen po ponad pięciu miesiącach obserwacji. Cele są wybierane imiennie w ponad 20 branżach, a 60% odbiorców zajmuje stanowiska C-level, prezesa lub przewodniczącego rady. Wyróżnikiem nie jest jakość podróbki strony logowania — te bywały dobre od lat — tylko to, co dzieje się po zalogowaniu.

W klasycznym phishingu łupem pada hasło. Tutaj łupem pada token: napastnik przechwytuje wynik poprawnego uwierzytelnienia, razem z zaliczonym drugim składnikiem. Kampania robi to na dwa sposoby. W wariancie adversary-in-the-middle (AiTM) fałszywa strona pośredniczy w prawdziwym logowaniu i po drodze zbiera ciasteczko sesji oraz token odświeżania. W wariancie device code ofiara loguje się na autentycznej stronie Microsoftu, a jedyną nieprawidłowością jest to, komu system wyda tokeny na końcu.

Kadra zarządzająca jest celem nie z powodu słabszej higieny bezpieczeństwa, lecz z powodu zasięgu uprawnień i wagi korespondencji. Skrzynka członka zarządu zawiera projekty umów, harmonogramy transakcji i wątki, w których polecenie przelewu nie budzi zdziwienia. To podręcznikowy spear phishing i whaling, tyle że z ładunkiem w postaci uwierzytelnionej sesji zamiast złośliwego załącznika.

Skala: to nie jest atak niszowy

Najlepiej udokumentowany przykład tej klasy ataku pochodzi z kwietnia 2026 roku. Microsoft Threat Intelligence opisał kampanię AiTM podszywającą się pod firmowy kodeks postępowania, która między 14 a 16 kwietnia dosięgła ponad 35 tys. użytkowników w ponad 13 tys. organizacji w 26 krajach. Rozkład branżowy pokazuje, że dobór celów nie był przypadkowy: ochrona zdrowia 19%, usługi finansowe 18%, usługi profesjonalne i technologie po 11%.

Zmienia się też opakowanie. W pierwszym kwartale 2026 roku Microsoft przeanalizował około 8,3 mld phishingowych wiadomości e-mail i wskazał kody QR jako najszybciej rosnący nośnik: ze 7,6 mln ataków w styczniu do 18,7 mln w marcu, czyli o 146%. W marcu 70% z nich przyszło w załącznikach PDF. Kod QR nie jest ozdobnikiem: przenosi kliknięcie z zarządzanego laptopa na prywatny telefon, poza proxy, EDR i filtry poczty. Za tym opakowaniem stoi już cały rynek, bo narzędzia do takich kampanii sprzedaje się w abonamencie; opisujemy go przy ostrzeżeniu FBI przed platformą Kali365.

Motyw finansowy stoi na końcu tego łańcucha. FBI IC3 podało za 2025 rok 3,046 mld dolarów strat z ataków typu BEC przy 24 768 zgłoszeniach, co daje około 123 tys. dolarów na zgłoszenie. Przejęta skrzynka członka zarządu jest najkrótszą drogą do takiego przelewu, bo pozwala prowadzić rozmowę z prawdziwego adresu, w prawdziwym wątku, ze znajomością prawdziwego harmonogramu płatności. W Polsce skala zjawiska widać po stronie CERT Polska: 260 783 zarejestrowane incydenty w 2025 roku, z czego 97% to oszustwa komputerowe, i blisko 250 tys. domen dopisanych do listy ostrzeżeń, o 166% więcej niż rok wcześniej. Nie każde poświadczenie zebrane w takiej kampanii trafia od razu do przelewu. Część wraca później na listach, które napastnicy odtwarzają w masowych próbach logowania tą samą parą login–hasło w innych serwisach, już bez udziału człowieka po drugiej stronie.

Pięć faz łańcucha ataku

Jak device code flow zamienia się w kradzież tokenu

Device code flow to legalny mechanizm OAuth 2.0 stworzony dla urządzeń, na których nie da się wygodnie wpisać hasła: telewizorów, konsol, narzędzi wiersza poleceń, urządzeń IoT. Urządzenie prosi dostawcę tożsamości o krótki kod, wyświetla go użytkownikowi i czeka. Użytkownik wchodzi na osobnym, zaufanym urządzeniu na stronę logowania, wpisuje kod, uwierzytelnia się normalnie, a dostawca tożsamości wydaje tokeny temu, kto o kod poprosił.

Nadużycie polega na rozerwaniu tego założenia. To napastnik inicjuje przepływ i dostaje kod, po czym przesyła go ofierze pod pretekstem dołączenia do spotkania, potwierdzenia dostępu albo weryfikacji urządzenia. Ofiara wpisuje kod na prawdziwej stronie Microsoftu, przechodzi prawdziwe MFA i widzi prawdziwy komunikat o powodzeniu. Tokeny trafiają do napastnika, bo od początku to jego urządzenie czekało na wynik. Microsoft opisał tę technikę w lutym 2025 roku przy okazji kampanii aktora śledzonego jako Storm-2372, wymierzonej między innymi w administrację publiczną, organizacje pozarządowe, obronność i energetykę.

Kluczowy jest token odświeżania. Token dostępu wygasa po godzinie, ale token odświeżania wystawia kolejne tokeny dostępu tak długo, jak pozostaje ważny, bez ponownego logowania, bez MFA i bez kontaktu z ofiarą. Napastnik odpytuje wtedy Microsoft Graph, przeszukuje skrzynkę pod kątem słów w rodzaju „hasło” czy „przelew”, pobiera pliki z OneDrive i wysyła wiadomości z konta ofiary. Reset hasła sam z siebie tego nie przerywa.

W logach Microsoft Entra ta sekwencja ma charakterystyczny kształt. Uwierzytelnienie device code zostawia najpierw wpis z kodem wyniku 50199 (przerwa na wpisanie kodu), a chwilę później wpis udany dla tego samego użytkownika, często z innego adresu IP i z aplikacji klienckiej, której dana osoba normalnie nie używa. Trzeci wpis, w dzienniku audytu, to rejestracja nowej metody uwierzytelniania. I to jest moment, w którym atak przestaje zależeć od skradzionego tokenu.

// 1. Every device code sign-in in the last 14 days. Most tenants never use
//    this flow, so the baseline itself is the detection.
SigninLogs
| where TimeGenerated > ago(14d)
| where AuthenticationProtocol =~ "deviceCode"
| extend Country = tostring(LocationDetails.countryOrRegion)
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Country, ResultType, CorrelationId
| order by TimeGenerated desc

// 2. The device code interrupt (50199) followed by a success for the same user
//    from another address within five minutes: the shape a phished code leaves.
let lookback = 14d;
let gap = 5m;
let prompts = SigninLogs
    | where TimeGenerated > ago(lookback) and ResultType == 50199
    | project UserPrincipalName, PromptTime = TimeGenerated, PromptIP = IPAddress;
let grants = SigninLogs
    | where TimeGenerated > ago(lookback) and ResultType == 0
    | where AuthenticationProtocol =~ "deviceCode"
    | project UserPrincipalName, GrantTime = TimeGenerated, GrantIP = IPAddress, AppDisplayName;
prompts
| join kind=inner grants on UserPrincipalName
| where GrantTime between (PromptTime .. PromptTime + gap)
| where PromptIP != GrantIP
| project UserPrincipalName, PromptTime, PromptIP, GrantTime, GrantIP, AppDisplayName

// 3. A new authentication method registered within an hour of a device code
//    sign-in. This is the persistence step, and it survives a password reset.
let tokens = SigninLogs
    | where TimeGenerated > ago(14d)
    | where AuthenticationProtocol =~ "deviceCode" and ResultType == 0
    | project UserPrincipalName, GrantTime = TimeGenerated, GrantIP = IPAddress;
AuditLogs
| where TimeGenerated > ago(14d)
| where LoggedByService == "Authentication Methods"
| where OperationName in ("User registered security info",
                          "User registered all required security info")
| where Result == "success"
| extend UserPrincipalName = tostring(TargetResources[0].userPrincipalName)
| join kind=inner tokens on UserPrincipalName
| where TimeGenerated between (GrantTime .. GrantTime + 1h)
| project TimeGenerated, UserPrincipalName, OperationName, GrantTime, GrantIP

Dlaczego MFA nie wystarcza — i które MFA wystarcza

Zdanie „mamy MFA” nic nie mówi o odporności na tę kampanię, bo MFA dzieli się na dwie klasy o zupełnie różnych właściwościach. CISA rozdziela je wprost: metody odporne na phishing to FIDO2/WebAuthn oraz uwierzytelnianie oparte na PKI (karty PIV/CAC). Wszystko inne (SMS, kod TOTP z aplikacji, powiadomienie push) jest podatne, bo sprowadza się do sekretu, który człowiek może przepisać lub zatwierdzić w niewłaściwym miejscu. Różnica jest mierzalna: Proofpoint odnotował w 2025 roku próby przejęcia blisko 3000 kont w ponad 900 środowiskach Microsoft 365, z potwierdzoną skutecznością przekraczającą 50%.

Trzecia kolumna jest tą, którą najczęściej się pomija. Passkey rzeczywiście zamyka wariant AiTM, bo podpis kryptograficzny jest związany z domeną i nie da się go odtworzyć na stronie pośredniczącej. Nie zamyka wariantu device code, bo tam ofiara loguje się na prawdziwej domenie Microsoftu i przechodzi prawdziwe, odporne na phishing uwierzytelnienie. Błąd nie leży w sposobie logowania, tylko w pochodzeniu kodu. Ten wariant zamyka polityka dostępu warunkowego.

Kierunek zmian po stronie platformy jest jednoznaczny. Od 1 września 2026 roku Microsoft Entra ID czyni passkey domyślnym sposobem logowania i automatycznie włącza go użytkownikom korzystającym z SMS lub połączeń głosowych, a od 1 lutego 2027 roku wycofuje własną dostawę tych dwóch metod. Po tej dacie osoba, której jedynym drugim składnikiem jest SMS, zostanie przy logowaniu zablokowana do czasu zarejestrowania passkeya. Organizacje, które przeprowadzą tę migrację wcześniej i dobrowolnie, zrobią to taniej niż te, które zrobią to pod presją terminu.

Dlaczego socjotechnika sprawia, że to działa

Zaawansowanie techniczne to tylko połowa sukcesu. Kampania działa, ponieważ wykorzystuje głęboko zakorzenione wzorce zachowań w codziennej pracy kadry zarządzającej:

• Autorytet i rutyna: imitowane platformy odpowiadają codziennym przepływom pracy zarządu, więc wywołują reakcję nawykową, bez krytycznej oceny
• Personalizacja: domeny nadawców i stopki pochodzą od organizacji celu, co tworzy pozór komunikacji wewnętrznej
• Subtelność device code: cel wykonuje prawdziwą czynność na microsoft.com, więc żadna z wyuczonych heurystyk („sprawdź adres strony”) nie zapala się

Jak odróżnić prawdziwą prośbę o zalogowanie od tej kampanii

Sygnał rozpoznawczy jest jeden i nie wymaga wiedzy technicznej: prośba o zalogowanie lub o wpisanie kodu, której nie poprzedziło żadne Twoje działanie. Prawdziwe logowanie jest zawsze konsekwencją czynności, którą właśnie wykonałeś. Kod przychodzący „do potwierdzenia” z zewnątrz nie ma legalnego odpowiednika. Poniższe zestawienie porządkuje resztę sygnałów.

Pierwsze 60 minut po podejrzeniu przejęcia sesji

Kolejność ma tu znaczenie większe niż komplet czynności. Celem pierwszej godziny jest odebranie napastnikowi ważnych tokenów i usunięcie tego, czym mógłby je odzyskać, zanim ktokolwiek zacznie analizować, jak do tego doszło. Poniższa procedura zakłada dostęp do Microsoft Entra i dziennika audytu.

1. Minuty 0–10Dyżurny SOC
   Unieważnij sesje, nie tylko hasło

   Wywołaj unieważnienie sesji logowania dla konta (operacja revokeSignInSessions w Microsoft Graph). Dopiero to odbiera ważność tokenom odświeżania. Reset hasła wykonaj równolegle, ale traktuj go jako czynność drugą, nie pierwszą.

2. Minuty 10–20Administrator tożsamości
   Przejrzyj metody uwierzytelniania konta

   Sprawdź w dzienniku audytu wszystkie rejestracje metod uwierzytelniania z ostatnich 30 dni. Usuń każdą, której użytkownik nie rozpoznaje, i dopiero potem pozwól mu zarejestrować nową. Zapisz zrzut stanu sprzed zmian.

3. Minuty 20–35Administrator poczty
   Zabezpiecz i wyczyść reguły skrzynki

   Wyeksportuj reguły skrzynki i reguły przekazywania, zanim cokolwiek skasujesz. Szukaj przekierowań na adresy zewnętrzne oraz reguł przenoszących wiadomości ze słowami „faktura”, „przelew” czy „bank” do folderów rzadko odwiedzanych. Sprawdź też delegacje i uprawnienia zastępcze.

4. Minuty 35–50Administrator tożsamości
   Przejrzyj zgody aplikacji OAuth

   Wypisz zgody wyrażone przez użytkownika i przez administratora dla tej dzierżawy, ze szczególną uwagą na uprawnienia do poczty, plików i odczytu katalogu. Zgoda dla aplikacji jest niezależnym mechanizmem trwałego dostępu, który przeżyje zarówno reset hasła, jak i unieważnienie sesji.

5. Minuty 50–60Prowadzący incydent
   Ustal zasięg i zabezpiecz kontekst finansowy

   Odtwórz z logów, do jakich zasobów sięgnięto przez Microsoft Graph i co zostało wysłane z konta. Jeżeli w wątkach są sprawy płatnicze, powiadom księgowość osobnym kanałem i wstrzymaj przelewy potwierdzane wyłącznie mailowo do czasu weryfikacji głosowej.

Po pierwszej godzinie zostaje część, której nie da się zrobić w pośpiechu: ustalenie, ile innych osób dostało tę samą wiadomość, przeszukanie logowań device code w całej dzierżawie i decyzja, czy incydent podlega zgłoszeniu do organu nadzorczego. Jeśli w skrzynce były dane osobowe, zegar 72 godzin z RODO zaczyna biec od momentu stwierdzenia naruszenia, a nie od zamknięcia analizy.

Co zamknąć zawczasu

Prewencja w tym przypadku jest wyjątkowo konkretna, bo atak korzysta z policzalnej liczby mechanizmów platformy. Poniższa lista jest ułożona według stosunku efektu do wysiłku, od zmian konfiguracyjnych do zmian organizacyjnych.

Koszt tej pracy rozkłada się na kilka pozycji i warto policzyć je osobno, zamiast szukać jednej kwoty. Po stronie licencji liczy się poziom Entra ID, bo dostęp warunkowy i ochrona tokenów wymagają planów wyższych niż podstawowy. Po stronie sprzętu: liczba osób, które dostaną klucz FIDO2, i to, czy potrzebują drugiego klucza zapasowego. Po stronie czasu zespołu: inwentaryzacja aplikacji korzystających dziś z device code, okres pracy polityki w trybie raportowania i obsługa zgłoszeń w tygodniach rejestracji passkeyów. Po stronie procesu: przepisanie procedury reagowania tak, aby unieważnienie tokenów było w niej krokiem pierwszym.

Wykrywanie jest tu równie ważne jak konfiguracja, bo część sygnałów pojawia się dopiero po fakcie: nowa metoda MFA, nietypowa aplikacja kliencka, logowanie device code w dzierżawie, która nigdy go nie używała. Jeśli nikt nie patrzy na te zdarzenia poza godzinami pracy, oprzyj tę warstwę o monitoring 24/7, a ekspozycję danych zarządu w źródłach przestępczych śledź osobno (Flare).

Najczęstsze pytania

Podsumowanie

MFA pozostaje kontrolą konieczną, ale przestało być wystarczające dla kont zarządu. Kiedy napastnik działa wewnątrz uwierzytelnionej sesji i dopisuje własną metodę logowania, liczy się nie to, czy drugi składnik istnieje, lecz jakiej jest klasy, które przepływy uwierzytelniania zostawiono otwarte i jak szybko da się unieważnić tokeny. Wszystkie trzy rzeczy ustawia się przed incydentem, nie w jego trakcie. Zarząd i asystentów warto objąć osobnym programem symulacji phishingu i deepfake, a wykrywanie przejętych sesji powierzyć całodobowemu SOC.

Atak nie omija MFA. Sprawia, że MFA staje się nieistotne, działając wewnątrz uwierzytelnionej sesji. Obrona przed tym wymaga przemyślenia, co „bezpieczne uwierzytelnianie” naprawdę oznacza w 2026 roku.