Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Na początku kwietnia 2026 roku opisano kampanię phishingową wykorzystującą nową platformę phishing-as-a-service o nazwie VENOM. Operacja jest wymierzona przede wszystkim w członków zarządów, dyrektorów finansowych oraz menedżerów wysokiego szczebla korzystających z Microsoft 365, a jej celem jest nie tylko kradzież poświadczeń, lecz także przejęcie sesji i utrzymanie dostępu do środowiska tożsamości ofiary.
To istotna zmiana w charakterze współczesnych ataków. W praktyce napastnicy nie muszą już ograniczać się do wyłudzenia hasła, ponieważ coraz częściej próbują przechwycić zaufaną sesję lub uzyskać tokeny pozwalające działać w ramach legalnego procesu uwierzytelniania.
W skrócie
- VENOM to zamknięta platforma PhaaS używana do precyzyjnych kampanii przeciwko kadrze kierowniczej.
- Ataki podszywają się pod powiadomienia SharePoint i wykorzystują kody QR zapisane znakami Unicode.
- Mechanizm przenosi ofiarę na urządzenie mobilne, co pomaga ominąć część zabezpieczeń stacji roboczej.
- Po wejściu w łańcuch ataku użytkownik może trafić do scenariusza AiTM albo phishingu opartego na device code.
- Celem jest przejęcie sesji, tokenów oraz ustanowienie trwałego dostępu do konta Microsoft 365.
Kontekst / historia
Phishing ukierunkowany na środowiska Microsoft 365 od lat pozostaje jednym z głównych wektorów przejęcia tożsamości w firmach. W ostatnich latach obserwujemy przejście od prostych stron wyłudzających hasła do bardziej zaawansowanych zestawów adversary-in-the-middle, które pośredniczą w czasie rzeczywistym podczas logowania i przechwytują tokeny sesyjne.
Równolegle rośnie skala nadużyć związanych z mechanizmem device code. Ten model bazuje na legalnym procesie autoryzacji urządzenia, dlatego bywa trudniejszy do wykrycia niż klasyczny phishing formularzowy. VENOM wpisuje się w ten trend, ale wyróżnia się wysokim poziomem organizacji operacyjnej, własnym panelem zarządzania kampaniami oraz kontrolowanym, ograniczonym sposobem dystrybucji.
Analiza techniczna
Łańcuch ataku rozpoczyna się od wiadomości e-mail imitującej wewnętrzne powiadomienie SharePoint. Wiadomości są silnie spersonalizowane i skonstruowane tak, aby wyglądały jak realna korespondencja biznesowa. Dodatkowe elementy HTML, sztuczne klasy CSS, komentarze i rozbudowane wątki wiadomości mają utrudniać analizę treści oraz omijać mechanizmy detekcji oparte na sygnaturach.
Jednym z najbardziej charakterystycznych elementów kampanii jest użycie kodów QR zapisanych jako układ znaków Unicode osadzonych bezpośrednio w HTML. Taka technika zmniejsza skuteczność części rozwiązań skanujących obrazy i załączniki, a jednocześnie zachęca odbiorcę do zeskanowania kodu telefonem i kontynuowania interakcji poza firmowym endpointem.
Adres ofiary bywa ukrywany w fragmencie adresu URL zakodowanym podwójnym Base64. Ponieważ część po znaku kratki nie jest standardowo przesyłana do serwera w żądaniu HTTP, analiza i reputacyjne wykrywanie takich linków stają się trudniejsze. Po wejściu na stronę użytkownik trafia do warstwy filtrującej, która ma oddzielić realne cele od badaczy, automatycznych skanerów, sandboxów i systemów analitycznych.
Mechanizmy filtrujące wykorzystują między innymi ocenę User-Agent, reputację adresu IP, elementy honeypot i dodatkowe kontrole wskazujące na środowisko analityczne. Osoby lub systemy, które nie spełniają kryteriów, są przekierowywane do legalnych serwisów, co ogranicza ryzyko wzbudzenia podejrzeń.
Po przejściu przez filtr ofiara trafia do jednego z dwóch scenariuszy. W modelu AiTM fałszywa strona pośredniczy w prawdziwym logowaniu do Microsoft. Użytkownik widzi wiarygodny ekran logowania, często z poprawnym brandingiem organizacji i wstępnie uzupełnionym adresem e-mail, a operator ataku przechwytuje dane logowania, kody MFA i finalnie sesję.
Drugi wariant opiera się na device code phishing. W tym przypadku użytkownik otrzymuje instrukcję wprowadzenia kodu na legalnej stronie logowania urządzenia i zatwierdzenia dostępu. Ofiara nie wpisuje hasła w fałszywym formularzu, co znacząco utrudnia wykrycie ataku przez klasyczne zabezpieczenia antyphishingowe, ale skutkiem nadal jest wydanie tokenów napastnikowi.
Kluczowym etapem jest utrzymanie dostępu. W scenariuszu AiTM platforma może doprowadzić do zarejestrowania nowego urządzenia lub dodatkowej metody MFA na koncie ofiary jeszcze w trakcie aktywnej sesji. W wariancie device code trwałość zapewnia przejęty refresh token, dlatego sama zmiana hasła może nie wystarczyć do pełnego usunięcia dostępu intruza.
Konsekwencje / ryzyko
Ryzyko związane z kampanią VENOM jest szczególnie wysokie, ponieważ celem są osoby posiadające szerokie uprawnienia, dostęp do danych finansowych i strategicznych oraz możliwość autoryzowania wrażliwych działań biznesowych. Przejęcie konta członka zarządu lub dyrektora finansowego może prowadzić do oszustw BEC, wyłudzeń płatności, kradzieży dokumentów poufnych i dalszej kompromitacji organizacji.
Dodatkowym problemem jest skuteczność zastosowanych technik omijania zabezpieczeń. Unicode QR, ukrywanie danych w fragmencie URL oraz przekierowania do legalnych stron dla niepożądanych odwiedzających tworzą wielowarstwowy model utrudniający wykrywanie i analizę incydentu.
Kampania podważa również założenie, że samo MFA jest wystarczającą ochroną. Jeśli napastnik przejmie tokeny sesyjne lub skłoni ofiarę do zatwierdzenia legalnie wyglądającego procesu device code, może uzyskać dostęp bez klasycznego obchodzenia kontroli wieloskładnikowej. Z perspektywy obrońcy oznacza to konieczność ochrony nie tylko haseł, ale całego procesu tożsamości i sesji.
Rekomendacje
Organizacje powinny traktować tego typu kampanie jako atak na warstwę tożsamości. Priorytetem jest wdrożenie metod uwierzytelniania odpornych na phishing, takich jak FIDO2 i passkeys, zwłaszcza dla kadry kierowniczej, administratorów oraz kont uprzywilejowanych.
Warto przeanalizować, czy przepływ device code jest rzeczywiście potrzebny biznesowo. Jeśli nie, należy go ograniczyć lub wyłączyć. Jeżeli pozostaje wymagany, powinien zostać objęty ścisłym monitoringiem, politykami dostępu warunkowego i dodatkowymi kontrolami ryzyka.
- Monitorować rejestrację nowych urządzeń i metod MFA.
- Analizować nietypowe logowania do Entra ID oraz anomalie związane z tokenami odświeżania.
- Wdrożyć alerty dla nietypowych lokalizacji, urządzeń i przepływów autoryzacyjnych.
- Uwzględnić w procedurach IR unieważnianie aktywnych sesji oraz cofanie tokenów.
- Regularnie przeglądać zarejestrowane metody MFA i listę zaufanych urządzeń.
- Szkolić kadrę zarządzającą z rozpoznawania wiadomości z kodami QR i nietypowych żądań logowania na telefonie.
W reagowaniu na incydenty trzeba założyć, że reset hasła może być niewystarczający. W przypadku podejrzenia kompromitacji konieczne może być unieważnienie wszystkich aktywnych sesji, cofnięcie zgód tokenowych, przegląd metod MFA, usunięcie nieautoryzowanych urządzeń i szczegółowa analiza historii logowań oraz działań administracyjnych.
Podsumowanie
VENOM pokazuje, że współczesny phishing coraz częściej koncentruje się na przejęciu zaufanej tożsamości, a nie wyłącznie na kradzieży hasła. Połączenie personalizacji, technik unikania analizy, przeniesienia interakcji na urządzenia mobilne oraz nadużycia legalnych mechanizmów uwierzytelniania sprawia, że atak jest szczególnie groźny dla organizacji korzystających z Microsoft 365.
Dla firm oznacza to potrzebę przesunięcia strategii obrony z tradycyjnego antyphishingu na ochronę warstwy tożsamości, tokenów i sesji. Bez takiej zmiany nawet dobrze wdrożone MFA może nie zapewnić oczekiwanego poziomu odporności.