Archiwa: Phishing - Strona 32 z 105

Chmurowe telefony napędzają nową falę oszustw finansowych

Wprowadzenie do problemu / definicja

Chmurowe telefony to zdalnie udostępniane środowiska mobilne uruchamiane w centrach danych, które z perspektywy aplikacji i części systemów bezpieczeństwa mogą przypominać zwykłe smartfony użytkowników. Technologia ta ma legalne zastosowania w testowaniu aplikacji, automatyzacji procesów i pracy zdalnej, ale coraz częściej pojawia się również w operacjach fraudowych.

Z punktu widzenia cyberbezpieczeństwa problem polega na tym, że chmurowe instancje mobilne umożliwiają masowe prowadzenie działań z poziomu środowiska wyglądającego jak autentyczne urządzenie. To osłabia skuteczność mechanizmów antyfraudowych opartych wyłącznie na reputacji telefonu, numeru czy podstawowych sygnałach telemetrycznych.

W skrócie

Chmurowe telefony stają się atrakcyjnym narzędziem dla cyberprzestępców, ponieważ pozwalają równolegle uruchamiać wiele odseparowanych instancji mobilnych. Każda z nich może prezentować inny zestaw parametrów urządzenia, ustawień systemowych i cech sieciowych.

umożliwiają masowe zakładanie fałszywych kont,
ułatwiają obchodzenie mechanizmów device fingerprinting,
wspierają automatyzację procesów rejestracji i logowania,
mogą służyć do obsługi kodów SMS i innych etapów weryfikacji,
zwiększają skalę oraz opłacalność kampanii oszustw finansowych.

Kontekst / historia

Przez lata sektor finansowy traktował urządzenie mobilne jako względnie stabilny punkt odniesienia. Jeśli klient korzystał z tego samego telefonu, z podobnej lokalizacji i w powtarzalnym schemacie, systemy ryzyka uznawały taki wzorzec za wiarygodny.

Model ten zaczął jednak tracić skuteczność wraz z rozwojem usług oferujących zdalne uruchamianie wielu instancji Androida lub środowisk mobilnych w chmurze. Rozwiązania projektowane z myślą o testach, marketingu czy zarządzaniu wieloma kontami zostały przejęte przez operatorów fraudowych, którzy wykorzystują ich skalowalność, izolację i łatwość rekonfiguracji.

W rezultacie instytucje finansowe muszą mierzyć się z nową klasą zagrożeń, w której zaufanie do samego faktu użycia aplikacji mobilnej nie jest już wystarczające. To szczególnie istotne w procesach onboardingu, odzyskiwania dostępu i autoryzacji działań wysokiego ryzyka.

Analiza techniczna

Technicznie chmurowy telefon może przyjmować różne formy: emulowanego środowiska Android, wirtualizowanej instancji mobilnej lub dostępu do fizycznych urządzeń osadzonych w infrastrukturze dostawcy. Operator uzyskuje do nich dostęp przez przeglądarkę albo dedykowaną aplikację, a następnie może zarządzać nimi centralnie.

Z perspektywy przestępcy kluczową zaletą jest możliwość jednoczesnego uruchomienia dziesiątek lub setek instancji. Każda z nich może mieć inny identyfikator urządzenia, odmienną konfigurację systemu, język, strefę czasową czy parametry sieciowe. Dodatkowo środowiska te można szybko resetować, klonować i odtwarzać po wykryciu przez system obronny.

Taka infrastruktura dobrze wspiera masowe zakładanie kont, tworzenie syntetycznych tożsamości i obejście prostych reguł ograniczających liczbę rejestracji z jednego urządzenia. Jeśli organizacja opiera ocenę ryzyka głównie na sygnaturze telefonu, chmurowa instancja może dostarczyć wystarczająco wiarygodnych sygnałów, by przejść początkową selekcję.

Istotnym elementem jest również automatyzacja. Chmurowe telefony mogą być sterowane skryptami lub z poziomu scentralizowanych paneli, co umożliwia automatyczne logowanie, przechodzenie przez ekrany aplikacji, inicjowanie działań transakcyjnych czy obsługę kodów jednorazowych. W praktyce obniża to koszt pojedynczego ataku i zwiększa tempo działania kampanii.

Szczególne ryzyko dotyczy środowisk, w których numer telefonu i SMS-owe 2FA nadal pełnią rolę głównego atrybutu zaufania. Gdy chmurowa infrastruktura mobilna jest powiązana z kontrolowanym kanałem komunikacji, przestępcy mogą skuteczniej utrzymywać konta, przechodzić etapy weryfikacji i wzmacniać pozory legalnej aktywności.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem dla instytucji finansowych jest spadek jakości sygnałów, które dotąd uznawano za wiarygodne. Aktywność z aplikacji mobilnej i z pozoru unikalnego urządzenia nie musi już oznaczać realnego klienta ani pojedynczego użytkownika.

Przekłada się to na wyższe ryzyko oszustw w procesach otwierania kont, resetu danych dostępowych, nadużyć promocyjnych i autoryzacji płatności. Organizacje mogą ponosić bezpośrednie straty finansowe, rosnące koszty chargebacków oraz wydatki związane z przebudową modeli decyzyjnych.

Problem ma także wymiar regulacyjny i operacyjny. Niewystarczająca zdolność wykrywania nadużyć w kanałach cyfrowych może prowadzić do większej liczby incydentów związanych z praniem pieniędzy, rachunkami słupami, phishingiem, smishingiem i obchodzeniem limitów transakcyjnych.

Rekomendacje

Podstawową zmianą powinno być odejście od nadmiernego polegania na pojedynczym sygnale urządzeniowym. Device fingerprinting pozostaje użyteczny, ale wyłącznie jako element szerszego modelu oceny ryzyka, który uwzględnia kontekst sesji, zachowanie użytkownika i historię środowiska.

wdrożenie detekcji anomalii wskazujących na środowiska wirtualne lub zdalnie hostowane,
analizę cyklu życia urządzenia i jego historii w organizacji,
sprawdzanie spójności między geolokalizacją, strefą czasową, językiem systemu i schematem aktywności,
ocenę szybkości oraz powtarzalności interakcji z aplikacją,
korelację numeru telefonu z historią konta, transakcjami i innymi atrybutami tożsamości,
wzmocnienie procesów rejestracji i odzyskiwania dostępu,
stosowanie adaptacyjnego uwierzytelniania opartego na ryzyku.

Duże znaczenie ma również modelowanie zagrożeń osobno dla każdego etapu łańcucha ataku. Inne sygnały ostrzegawcze będą istotne przy zakładaniu konta, inne podczas autoryzacji płatności, a jeszcze inne przy nagłym wzroście aktywności urządzenia lub nietypowej rotacji środowisk mobilnych.

Dla sektora finansowego szczególnie ważne jest ograniczenie zaufania do SMS-owego 2FA jako samodzielnego zabezpieczenia. Tam, gdzie to możliwe, warto wdrażać silniejsze metody uwierzytelniania, w tym mechanizmy odporne na phishing, kryptograficzne potwierdzanie urządzenia i dodatkowe kontrole zależne od ryzyka transakcji.

Podsumowanie

Chmurowe telefony stają się pełnoprawnym elementem infrastruktury wykorzystywanej w nowoczesnych oszustwach finansowych. Ich siła nie wynika wyłącznie z samej technologii, ale z tego, że podważają założenia, na których oparto wiele współczesnych systemów antyfraudowych.

Dla organizacji oznacza to konieczność przejścia od prostego zaufania do urządzenia mobilnego w stronę wielowarstwowej analizy ryzyka. Tylko korelacja telemetrii, zachowania użytkownika, reputacji sieci i historii życia urządzenia pozwoli skuteczniej ograniczać straty oraz zwiększać odporność operacyjną.

Źródła

https://www.infosecurity-magazine.com/news/cloud-phones-financial-fraud/
https://support.huaweicloud.com/intl/en-us/usermanual-cph/cph-usermanual-pdf.pdf
https://trustfull.com/articles/disposable-phone-numbers-101-privacy-and-fraud-risks
https://support.huaweicloud.com/intl/en-us/bestpractice-cph/Cloud%20Phone%20Best%20Practices.pdf
https://www.ultatel.com/press/ultatel-businesses-using-personal-phone-lines-are-vulnerable-to-350-million-telemarketing-fraud/

Fałszywi rekruterzy podszywają się pod Palo Alto Networks. Kandydaci tracą setki dolarów w nowym schemacie phishingowym

Wprowadzenie do problemu / definicja

Podszywanie się pod rekruterów znanych firm to coraz częstsza odmiana phishingu ukierunkowanego, łącząca socjotechnikę, oszustwo finansowe i nadużycie zaufania do rozpoznawalnej marki. W opisywanym przypadku cyberprzestępcy imitowali proces rekrutacyjny Palo Alto Networks, aby przekonać kandydatów do opłacenia rzekomej usługi dopasowania CV do wymagań systemów ATS.

To istotny przykład współczesnych oszustw, w których atak nie musi zaczynać się od złośliwego załącznika ani linku. Wystarczy wiarygodna narracja, dobrze przygotowana komunikacja i wykorzystanie presji towarzyszącej procesowi rekrutacji.

W skrócie

Atakujący podszywali się pod rekruterów Palo Alto Networks i kontaktowali się z kandydatami do pracy.
Kampania wykorzystywała publicznie dostępne dane zawodowe do personalizacji wiadomości.
Ofiary były informowane, że ich CV wymaga płatnej korekty pod kątem systemów ATS.
Oferowane pakiety kosztowały od 400 do 800 dolarów.
Celem było bezpośrednie wyłudzenie pieniędzy oraz potencjalne pozyskanie cennych danych osobowych i zawodowych.

Kontekst / historia

Oszustwa rekrutacyjne od lat pozostają aktywnym elementem krajobrazu zagrożeń, jednak ich obecna forma jest znacznie bardziej dopracowana niż klasyczne kampanie phishingowe. Cyberprzestępcy coraz lepiej rozumieją sposób działania działów HR, znaczenie systemów ATS oraz zachowania kandydatów ubiegających się o stanowiska specjalistyczne i menedżerskie.

W tym przypadku szczególnie skuteczne okazało się połączenie kilku czynników: rozpoznawalnej marki technologicznej, profesjonalnie brzmiącej komunikacji, wykorzystania szczegółów z kariery zawodowej ofiary oraz stworzenia pozornego problemu proceduralnego. Taki model działania wpisuje się w szerszy trend nadużywania procesów zatrudnienia jako wektora ataku.

Na tle innych kampanii rekrutacyjnych ten schemat wyróżnia się naciskiem na bezpośredni komponent finansowy. Zamiast klasycznego dostarczania malware lub kradzieży poświadczeń na pierwszym etapie, atakujący skupili się na przekonaniu ofiary do dobrowolnej płatności.

Analiza techniczna

Łańcuch ataku miał charakter socjotechniczny, ale był zaprojektowany w sposób metodyczny i wieloetapowy. Pierwszym krokiem było nawiązanie kontaktu przez osobę podszywającą się pod przedstawiciela zespołu rekrutacyjnego. Wiadomości sprawiały wrażenie autentycznych, ponieważ zawierały profesjonalny język, odniesienia do doświadczenia zawodowego kandydata oraz elementy budujące wiarygodność marki.

Następnie następowała personalizacja przekazu. Atakujący wykorzystywali dane z publicznych profili zawodowych, aby odwoływać się do konkretnych stanowisk, osiągnięć i etapów kariery. Taka technika skutecznie ogranicza sygnały ostrzegawcze typowe dla masowego phishingu i zwiększa prawdopodobieństwo zaufania do nadawcy.

Kolejny etap polegał na stworzeniu sztucznej przeszkody proceduralnej. Ofiara otrzymywała informację, że jej CV nie spełnia wymagań systemu Applicant Tracking System. Motyw ATS jest szczególnie przekonujący, ponieważ odpowiada realiom współczesnej rekrutacji i brzmi wiarygodnie dla kandydatów.

W dalszej fazie pojawiał się kolejny rzekomy specjalista, który oferował płatne poprawienie dokumentów. Proponowane usługi obejmowały różne poziomy wsparcia, od podstawowego dopasowania do ATS po pełne przepisanie CV i pozycjonowanie kandydata pod role liderskie. Jednocześnie wzmacniano presję czasu, sugerując, że decyzje rekrutacyjne zapadną w krótkim terminie.

Z perspektywy bezpieczeństwa mamy tu do czynienia z dojrzałym oszustwem procesowym zbliżonym do modelu Business Email Compromise w wariancie HR fraud. Kluczowym elementem nie jest złośliwy kod, lecz zmanipulowanie decyzji użytkownika i skłonienie go do wykonania płatności lub przekazania kolejnych danych.

Konsekwencje / ryzyko

Najbardziej bezpośrednią konsekwencją dla ofiary jest strata finansowa. Jednak rzeczywiste ryzyko jest znacznie szersze. Kandydaci mogą przekazać oszustom rozbudowane informacje osobowe i zawodowe, w tym historię zatrudnienia, dane kontaktowe, informacje o obecnym pracodawcy oraz szczegóły dotyczące obowiązków i struktury organizacyjnej.

Tego rodzaju dane mają dużą wartość wywiadowczą. Mogą zostać wykorzystane do kolejnych kampanii phishingowych, prób przejęcia kont, ataków ukierunkowanych na pracodawcę ofiary albo sprzedaży w przestępczym obiegu informacji.

Ryzyko dotyczy także firmy, pod którą podszywają się napastnicy. Takie incydenty osłabiają zaufanie do marki pracodawcy, obciążają działy HR i bezpieczeństwa dodatkowymi zgłoszeniami oraz mogą prowadzić do szkód reputacyjnych. W praktyce atak uderza równocześnie w kandydatów i w wiarygodność całego procesu rekrutacyjnego.

Rekomendacje

Kandydaci powinni traktować jako poważny sygnał ostrzegawczy każdą sytuację, w której rekruter żąda opłaty za udział w procesie, sugeruje skorzystanie z płatnej usługi zewnętrznej lub wywiera presję związaną z krótkim terminem poprawienia aplikacji. Legalne procesy rekrutacyjne nie wymagają od kandydatów opłacania korekty CV w celu przejścia do kolejnego etapu.

Warto stosować wielokanałową weryfikację tożsamości rekrutera. Najlepiej sprawdzić, czy oferta istnieje na oficjalnej stronie kariery, czy osoba kontaktująca się z kandydatem rzeczywiście jest powiązana z organizacją oraz czy domena nadawcy i dane kontaktowe są spójne z publicznie dostępnymi informacjami.

Nie dokonuj żadnych płatności związanych z rekrutacją bez niezależnego potwierdzenia autentyczności procesu.
Sprawdzaj domenę nadawcy, adres odpowiedzi i spójność podpisu w korespondencji.
Weryfikuj ofertę pracy na oficjalnej stronie firmy oraz w jej kanałach komunikacyjnych.
Nie przekazuj nadmiarowych danych osobowych ani dokumentów bez upewnienia się, że kontakt jest legalny.
Stosuj unikalne hasła, menedżer haseł i MFA dla poczty oraz kont zawodowych.

Z perspektywy organizacji kluczowe jest publikowanie jasnych zasad procesu rekrutacji, informowanie, że firma nie pobiera opłat od kandydatów, monitorowanie nadużyć marki oraz zapewnienie łatwego kanału zgłaszania fałszywych kontaktów. Istotne są również szkolenia dla HR i zespołów employer branding w zakresie impersonacji i fraudów rekrutacyjnych.

Podsumowanie

Kampania wykorzystująca markę Palo Alto Networks pokazuje, że nowoczesny phishing coraz częściej odchodzi od prostych, masowych przynęt na rzecz starannie przygotowanych oszustw osadzonych w realnych procesach biznesowych. Personalizacja, autorytet znanej firmy, wiarygodny motyw ATS i presja czasu tworzą skuteczny model wyłudzenia.

Dla rynku cyberbezpieczeństwa to wyraźny sygnał, że ochrona użytkowników musi obejmować nie tylko wykrywanie złośliwego oprogramowania, ale także identyfikację manipulacji procesowej i nadużyć zaufania. Rekrutacja staje się pełnoprawną powierzchnią ataku, a kandydaci do pracy są dziś celem działań prowadzonych z dużą precyzją.

Źródła

Dark Reading — https://www.darkreading.com/cyberattacks-data-breaches/phishers-pose-palo-alto-networks-recruiters-job-scam
Palo Alto Networks Unit 42 — 2025 Unit 42 Global Incident Response Report: Social Engineering Edition — https://unit42.paloaltonetworks.com/2025-unit-42-global-incident-response-report-social-engineering-edition/
Palo Alto Networks Unit 42 — Contagious Interview: DPRK Threat Actors Lure Tech Industry Job Seekers — https://unit42.paloaltonetworks.com/north-korean-threat-actors-lure-tech-job-seekers-as-fake-recruiters/

Google wzmacnia dark web intelligence. Gemini ma wykrywać realne zagrożenia ukryte w szumie danych

Wprowadzenie do problemu / definicja

Dark web intelligence to obszar cyberbezpieczeństwa skupiony na monitorowaniu forów przestępczych, podziemnych usług, kanałów komunikacji oraz ofert sprzedaży dostępu, danych i narzędzi wykorzystywanych w atakach. Największym wyzwaniem od lat nie jest jednak brak informacji, lecz ich nadmiar, niski poziom trafności oraz duża liczba fałszywych alarmów, które utrudniają zespołom bezpieczeństwa szybkie podjęcie działań.

Google zapowiedział nową funkcję w Google Threat Intelligence, która ma wykorzystać model Gemini do analizy ogromnych wolumenów sygnałów pochodzących z dark webu. Celem rozwiązania jest wyłapywanie wyłącznie tych zdarzeń, które mogą mieć realne znaczenie dla konkretnej organizacji.

W skrócie

Google rozwija możliwości Google Threat Intelligence o funkcję dark web intelligence wspieraną przez Gemini.
System ma automatycznie budować profil organizacji i dopasowywać do niego sygnały z podziemnego ekosystemu cyberprzestępczego.
Nowe podejście ma ograniczyć liczbę false positive i poprawić wykrywanie rzeczywistych zagrożeń.
Szczególny nacisk położono na wcześniejsze identyfikowanie przypadków sprzedaży dostępu przez initial access brokerów.

Kontekst / historia

Monitorowanie dark webu od dawna stanowi ważny element programów threat intelligence, zwłaszcza w dużych organizacjach oraz sektorach o podwyższonym ryzyku. Przez lata dominowały narzędzia oparte głównie na dopasowywaniu słów kluczowych, nazw marek, domen, adresów e-mail czy innych łatwych do zidentyfikowania wskaźników.

Taki model miał jednak istotne ograniczenia. Cyberprzestępcy często nie wskazują ofiary wprost, lecz opisują ją pośrednio, odwołując się do branży, lokalizacji, skali działalności, poziomu przychodów czy rodzaju wykorzystywanych systemów. W praktyce oznaczało to, że wiele potencjalnie ważnych wpisów mogło pozostać niewykrytych, jeśli nie zawierały jednoznacznych identyfikatorów. Google próbuje odpowiedzieć na ten problem, przesuwając ciężar analizy z prostego wyszukiwania fraz na semantyczne rozumienie kontekstu.

Analiza techniczna

Nowa funkcja ma działać jako dodatkowa warstwa analityczna w ramach Google Threat Intelligence. Zamiast wymagać ręcznego utrzymywania list słów kluczowych, system ma autonomicznie budować profil organizacji, uwzględniając jej działalność, geograficzny zasięg, specyfikę operacyjną oraz prawdopodobne elementy środowiska IT.

Technicznie kluczowe są trzy elementy. Po pierwsze, skala przetwarzania, ponieważ rozwiązanie ma analizować miliony zdarzeń dziennie pochodzących z forów, usług i infrastruktury powiązanej z dark webem. Po drugie, warstwa semantyczna, dzięki której model AI nie ogranicza się do wyszukania nazwy firmy, ale interpretuje znaczenie wpisu i porównuje je z profilem organizacji. Po trzecie, korelacja kontekstowa wspierana przez wiedzę operacyjną analityków Google Threat Intelligence Group.

Przykładowy scenariusz dotyczy oferty sprzedaży aktywnego dostępu VPN do dużego europejskiego detalisty. W ogłoszeniu może nie pojawić się nazwa firmy, ale wystarczające mogą być informacje o regionie działania, poziomie przychodów i typach systemów, do których uzyskano dostęp, takich jak portale HR czy systemy logistyczne. W klasycznym modelu taki wpis mógłby zostać pominięty, natomiast analiza kontekstowa ma umożliwić powiązanie tych cech z konkretną organizacją lub jej spółką zależną.

Istotnym celem rozwiązania jest także redukcja szumu analitycznego. Wiele dotychczasowych platform generowało zbyt dużo alertów o niskiej wartości, ponieważ nie potrafiły odróżnić nazw marek od pojęć ogólnych albo poprawnie zrozumieć wieloznacznych skrótów. Model językowy ma ograniczać ten problem, uwzględniając szerszy kontekst biznesowy i znaczeniowy.

Konsekwencje / ryzyko

Z punktu widzenia obrony organizacji nowe podejście może skrócić czas między pojawieniem się sygnału w przestępczym obiegu a reakcją zespołu bezpieczeństwa. Ma to szczególne znaczenie w scenariuszach związanych ze sprzedażą dostępu początkowego, wyciekiem poświadczeń, przygotowaniami do ataku ransomware lub handlem informacjami o infrastrukturze ofiary.

Wcześniejsze wykrycie takich sygnałów może dać zespołom SOC i IR czas na reset poświadczeń, izolację punktów wejścia, weryfikację logów dostępowych i uruchomienie procedur reagowania, zanim intruz przejdzie do kolejnych etapów ataku. To może realnie zmniejszyć skutki incydentu lub nawet całkowicie go udaremnić.

Ryzyko nie znika jednak całkowicie. Skuteczność narzędzi opartych na AI nadal zależy od jakości danych wejściowych, poprawności profilu organizacji oraz zdolności modelu do interpretacji niejednoznacznych komunikatów. Możliwe są zarówno fałszywe alarmy, jak i pominięcie istotnych sygnałów, jeśli atakujący celowo zniekształcą opis ofiary lub zastosują niestandardowe formy komunikacji.

Rekomendacje

Organizacje zainteresowane dark web intelligence powinny traktować tego typu funkcje jako element szerszego programu threat intelligence, a nie samodzielne rozwiązanie problemu. Największą wartość uzyskuje się wtedy, gdy sygnały z zewnętrznych źródeł są powiązane z procesami monitoringu, reagowania i zarządzania tożsamością.

Powiąż monitoring dark webu z procesami SOC, IR oraz IAM.
Zdefiniuj krytyczne atrybuty organizacji, takie jak marki, spółki zależne, regiony działania i typy systemów.
Wdróż szybkie procedury walidacji alertów dotyczących VPN, paneli administracyjnych, portali HR i systemów logistycznych.
Regularnie przeglądaj ekspozycję tożsamości, zwłaszcza kont uprzywilejowanych i poświadczeń zewnętrznych.
Integruj sygnały z dark webu z telemetrią z EDR, SIEM, IAM i systemów pocztowych.
Przygotuj playbooki na scenariusze związane z initial access brokerami, kradzieżą sesji i sprzedażą danych uwierzytelniających.
Oceniaj dostawcę nie po liczbie alertów, lecz po ich jakości, trafności i czasie reakcji.

Równolegle należy utrzymywać podstawowe zabezpieczenia, takie jak MFA odporne na phishing, segmentacja dostępu, monitorowanie anomalii logowania oraz zasada minimalnych uprawnień. Nawet najbardziej zaawansowany wywiad o dark webie nie zastąpi solidnej higieny bezpieczeństwa.

Podsumowanie

Nowa funkcja Google pokazuje, że dark web intelligence wchodzi w etap silnej automatyzacji i analizy kontekstowej wspieranej przez modele AI. Najważniejsza zmiana polega na odejściu od prostego dopasowywania słów kluczowych na rzecz semantycznej korelacji sygnałów z profilem organizacji.

Jeżeli deklaracje producenta potwierdzą się w praktyce, rozwiązanie może poprawić trafność alertów, ograniczyć szum i przyspieszyć wykrywanie zagrożeń na bardzo wczesnym etapie cyklu ataku. Dla zespołów bezpieczeństwa oznacza to większą szansę na identyfikację działań initial access brokerów jeszcze przed materializacją pełnego incydentu.

Źródła

Naruszenie danych w Navia ujawniło informacje pracowników HackerOne

Wprowadzenie do problemu / definicja

Naruszenia danych po stronie zewnętrznych dostawców usług pozostają jednym z najtrudniejszych do ograniczenia zagrożeń w obszarze cyberbezpieczeństwa. W tego typu scenariuszu celem ataku nie jest bezpośrednio organizacja końcowa, lecz partner przetwarzający jej dane — na przykład operator świadczeń pracowniczych, dostawca usług HR lub firma payrollowa. Taki model incydentu wystąpił w przypadku Navia Benefit Solutions, gdzie nieautoryzowany dostęp do systemów doprowadził do ujawnienia danych osób powiązanych z wieloma podmiotami, w tym pracowników HackerOne.

Sprawa jest istotna nie tylko ze względu na skalę zdarzenia, ale także na charakter ujawnionych informacji. W grę wchodzą dane osobowe o wysokiej wartości operacyjnej dla cyberprzestępców, które mogą zostać wykorzystane do kradzieży tożsamości, oszustw finansowych oraz ukierunkowanych kampanii socjotechnicznych.

W skrócie

Według dostępnych informacji atakujący uzyskali nieautoryzowany dostęp do środowiska Navia i przebywali w nim od 22 grudnia 2025 roku do 15 stycznia 2026 roku. Naruszenie wykryto 23 stycznia 2026 roku, a skala incydentu miała objąć niemal 2,7 mln osób. W przypadku HackerOne zagrożonych mogło zostać 287 pracowników.

Zakres potencjalnie ujawnionych danych obejmuje między innymi:

imiona i nazwiska,
daty urodzenia,
numery Social Security,
numery telefonów,
adresy e-mail,
informacje związane ze świadczeniami i planami zdrowotnymi.

Taki zestaw danych znacząco zwiększa ryzyko nadużyć, ponieważ umożliwia budowanie wiarygodnych profili ofiar oraz prowadzenie precyzyjnych działań phishingowych.

Kontekst / historia

Ataki na dostawców obsługujących obszary kadrowe, benefitowe i administracyjne od dawna należą do najbardziej opłacalnych z perspektywy przestępców. Jeden skuteczny incydent może zapewnić dostęp do danych wielu organizacji jednocześnie, bez konieczności przełamywania zabezpieczeń każdej z nich osobno. To właśnie dlatego firmy świadczące usługi HR, payroll czy administration services są atrakcyjnym elementem łańcucha dostaw.

W przypadku Navia szczególne znaczenie ma fakt, że pośrednio poszkodowaną organizacją okazała się firma z branży cyberbezpieczeństwa. To pokazuje, że nawet podmioty o wysokiej świadomości bezpieczeństwa pozostają uzależnione od poziomu ochrony stosowanego przez swoich partnerów biznesowych. Naruszenie po stronie dostawcy może więc wywołać realne skutki mimo braku bezpośredniego włamania do infrastruktury firmy docelowej.

Istotny jest także aspekt terminowości powiadomień. Opóźnienie pomiędzy wykryciem incydentu a dostarczeniem informacji do podmiotów dotkniętych naruszeniem zwiększa ryzyko skutecznego wykorzystania danych w oszustwach, phishingu i próbach podszywania się pod instytucje finansowe lub administratorów świadczeń.

Analiza techniczna

Z technicznego punktu widzenia incydent wpisuje się w klasyczny model naruszenia poufności danych w środowisku dostawcy zewnętrznego. Choć nie ujawniono publicznie pełnych szczegółów dotyczących początkowego wektora ataku, wiadomo, że napastnik uzyskał nieautoryzowany dostęp do systemów Navia i utrzymywał obecność w środowisku przez kilka tygodni.

Tak długi przedział czasowy sugeruje, że atak nie musiał ograniczać się do jednorazowej eksfiltracji. W praktyce napastnik mógł prowadzić działania rozpoznawcze, identyfikować repozytoria danych, analizować strukturę systemów oraz selekcjonować rekordy o najwyższej wartości. W środowiskach obsługujących benefity pracownicze szczególnie atrakcyjne są dane identyfikacyjne, kontaktowe, podatkowe i zdrowotne.

Zakres ujawnionych informacji wskazuje na możliwość wykorzystania ich w kilku scenariuszach operacyjnych. Połączenie danych identyfikacyjnych z informacjami kontaktowymi i szczegółami dotyczącymi świadczeń pozwala przygotować wyjątkowo przekonujące wiadomości podszywające się pod pracodawcę, administratora planu zdrowotnego, ubezpieczyciela albo instytucję finansową. To znacząco podnosi skuteczność spear phishingu i ataków socjotechnicznych.

Incydent podkreśla również szerszy problem bezpieczeństwa łańcucha dostaw. Ochrona organizacji nie może ograniczać się do własnych systemów i aplikacji. Równie ważne są procedury, kontrole techniczne oraz poziom dojrzałości bezpieczeństwa po stronie podmiotów przetwarzających dane pracowników i klientów.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją jest ryzyko kradzieży tożsamości. Dane takie jak numer Social Security, data urodzenia, imię i nazwisko oraz dane kontaktowe mają wysoką wartość przestępczą i mogą być wykorzystywane przez długi czas po samym incydencie. Ofiary mogą być narażone nie tylko na phishing, ale również na próby otwierania rachunków, zaciągania zobowiązań czy przejmowania kont.

Dodatkowym zagrożeniem są oszustwa związane z benefitami i opieką zdrowotną. Informacje o planach zdrowotnych mogą posłużyć do przygotowania fałszywych komunikatów dotyczących rozliczeń, refundacji, aktualizacji polisy czy potwierdzania danych medycznych. Tego typu wiadomości są zwykle bardziej wiarygodne niż standardowy phishing masowy, ponieważ odwołują się do realnych procesów administracyjnych.

Z perspektywy organizacji incydent oznacza również ryzyka prawne, reputacyjne i operacyjne. Firmy korzystające z usług zewnętrznych administratorów danych muszą przeanalizować zakres przekazywanych informacji, ocenić wpływ naruszenia na własne obowiązki zgodności oraz zweryfikować, czy obowiązujące umowy i mechanizmy nadzoru nad dostawcą były wystarczające.

Rekomendacje

Incydent powinien być sygnałem ostrzegawczym dla wszystkich organizacji korzystających z zewnętrznych dostawców usług HR, payroll i benefitowych. W pierwszej kolejności warto ustalić, jakie dane są przekazywane partnerom, czy stosowana jest zasada minimalizacji oraz czy retencja informacji nie wykracza poza rzeczywiste potrzeby biznesowe i regulacyjne.

Kluczowe znaczenie ma także zaostrzenie wymagań wobec dostawców w ramach programu zarządzania ryzykiem stron trzecich. Umowy powinny jasno określać standardy bezpieczeństwa, obowiązki raportowania incydentów, terminy notyfikacji oraz możliwość prowadzenia audytów i przeglądów zgodności.

przeprowadzenie inwentaryzacji dostawców mających dostęp do danych pracowników,
klasyfikację partnerów według poziomu ryzyka i rodzaju przetwarzanych informacji,
okresowe przeglądy bezpieczeństwa dostawców,
wymaganie MFA, szyfrowania danych i zasady najmniejszych uprawnień,
monitorowanie kampanii phishingowych wykorzystujących temat świadczeń i ubezpieczeń,
wdrożenie procedur szybkiej reakcji na próby podszywania się i wyłudzeń.

Osoby potencjalnie dotknięte naruszeniem powinny zachować podwyższoną ostrożność wobec wiadomości związanych z benefitami, świadczeniami zdrowotnymi i danymi kadrowymi. Zasadne jest także monitorowanie aktywności kredytowej oraz weryfikowanie każdej nietypowej prośby o podanie danych za pomocą niezależnego kanału kontaktu.

Podsumowanie

Przypadek Navia pokazuje, że bezpieczeństwo danych pracowniczych jest nierozerwalnie związane z dojrzałością cyberbezpieczeństwa całego ekosystemu dostawców. Nawet jeśli organizacja skutecznie chroni własną infrastrukturę, naruszenie po stronie partnera może doprowadzić do ujawnienia wrażliwych danych i wygenerować długofalowe ryzyka dla pracowników oraz biznesu.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest jasny: zarządzanie ryzykiem stron trzecich musi obejmować nie tylko dostawców technologii, ale również operatorów usług administracyjnych, kadrowych i benefitowych. To właśnie tam często przetwarzane są dane o najwyższej wartości z punktu widzenia kradzieży tożsamości i zaawansowanej socjotechniki.

Źródła

AI przyspiesza cyberataki, a tożsamość staje się głównym celem napastników

Wprowadzenie do problemu / definicja

Współczesne cyberataki coraz rzadziej rozpoczynają się od klasycznego wykorzystania podatności czy wdrożenia złośliwego oprogramowania. Coraz częściej punktem wejścia jest przejęcie tożsamości cyfrowej — kont użytkowników, tokenów sesyjnych, kluczy API, uprawnień administracyjnych oraz relacji zaufania między usługami. W praktyce oznacza to, że napastnicy nie muszą już „włamywać się” do organizacji w tradycyjnym sensie, lecz po prostu logują się przy użyciu skradzionych lub nadużytych danych dostępowych.

Na ten trend nakłada się rozwój sztucznej inteligencji, która skraca czas potrzebny na rekonesans, personalizację phishingu, analizę środowiska ofiary i automatyzację kolejnych etapów ataku. AI nie zmienia podstawowych mechanizmów kompromitacji, ale istotnie zwiększa tempo i skalę działań ofensywnych.

W skrócie

Najważniejszy wniosek jest jednoznaczny: AI przyspiesza działania cyberprzestępców, jednak główną przyczyną skutecznych incydentów nadal pozostają słabości w obszarze zarządzania tożsamością i dostępem. W najnowszych analizach zespołów reagowania na incydenty zdecydowana większość naruszeń zawiera komponent związany z identity security.

Atakujący coraz częściej wykorzystują legalnie wyglądający dostęp zamiast głośnych technik włamania.
Skradzione poświadczenia, tokeny i nadużycia uprawnień umożliwiają szybki ruch boczny.
AI skraca czas od uzyskania dostępu do eksfiltracji danych lub eskalacji incydentu.
Klasyczne mechanizmy ochrony perymetru nie wystarczają bez silnej ochrony tożsamości.

Kontekst / historia

Przez wiele lat strategia bezpieczeństwa opierała się głównie na ochronie perymetru: zaporach sieciowych, segmentacji i wykrywaniu malware. Ten model przestał jednak odpowiadać realiom środowisk chmurowych, rozproszonego SaaS, pracy hybrydowej i rosnącej liczby integracji API. W efekcie tożsamość użytkownika, administratora, aplikacji i usługi stała się nowym perymetrem bezpieczeństwa.

Wraz z tą zmianą wzrosło znaczenie phishingu, przejęcia sesji, credential stuffingu, obejścia MFA, nadużywania zaufanych aplikacji oraz wykorzystywania nadmiernych uprawnień. Cyberprzestępcy konsekwentnie wybierają ścieżki najmniejszego oporu — błędne konfiguracje IAM, brak widoczności telemetrycznej i rozproszone systemy zarządzania tożsamością. Sztuczna inteligencja wzmacnia ten trend, ponieważ pozwala szybciej identyfikować słabe punkty i skuteczniej przygotowywać kampanie socjotechniczne.

Analiza techniczna

Z technicznego punktu widzenia AI pełni dziś rolę mnożnika siły dla działań ofensywnych. Umożliwia automatyzację rekonesansu, generowanie przekonujących wiadomości phishingowych, analizę publicznie dostępnych danych o ofierze, przygotowanie skryptów oraz przyspieszenie działań po uzyskaniu pierwszego dostępu. W rezultacie znacząco skraca się czas między kompromitacją a realizacją celu ataku.

Kluczowe pozostaje jednak to, że pierwszy etap wielu incydentów polega na przejęciu legalnie wyglądającego dostępu. Może to być hasło, token OAuth, ciasteczko sesyjne, klucz API albo dostęp federacyjny. W środowiskach z wieloma usługami SaaS, rozproszonym katalogiem tożsamości i zbyt szerokimi uprawnieniami napastnik może przemieszczać się lateralnie bez używania klasycznych narzędzi post-exploitation.

Szczególnie groźne są następujące scenariusze:

przejęcie konta użytkownika za pomocą phishingu lub credential stuffingu,
obejście słabego MFA, zwłaszcza opartego na SMS lub podatnego na push fatigue,
kradzież tokenów sesyjnych z przeglądarki lub urządzenia końcowego,
nadużycie aplikacji z nadmiernymi uprawnieniami OAuth,
wykorzystanie kont serwisowych i tożsamości nieludzkich,
pivoting między usługami chmurowymi dzięki federacji i nadmiernym rolom.

To właśnie dlatego współczesne incydenty są coraz trudniejsze do wykrycia. Gdy napastnik korzysta z prawidłowych poświadczeń, standardowych interfejsów API i autoryzowanych sesji, tradycyjne mechanizmy detekcji oparte wyłącznie na sygnaturach lub wskaźnikach IOC okazują się niewystarczające. Skuteczna obrona wymaga korelacji sygnałów z warstwy IAM, poczty, endpointów, sieci i środowisk chmurowych.

Konsekwencje / ryzyko

Ataki oparte na tożsamości niosą dla organizacji szczególnie wysokie ryzyko, ponieważ pozwalają ominąć część klasycznych zabezpieczeń perymetrycznych. Legalnie wyglądająca aktywność wydłuża czas wykrycia, a przejęcie konta o szerokich uprawnieniach może prowadzić do szybkiej eskalacji skutków — od wycieku danych po sabotaż operacyjny i ransomware.

Największe zagrożenie dotyczy środowisk chmurowych i SaaS. Jedna skuteczna kompromitacja może otworzyć dostęp do poczty, repozytoriów kodu, dokumentów, systemów HR, narzędzi CI/CD i paneli administracyjnych. Jeśli organizacja nie wdrożyła zasady least privilege, nie prowadzi pełnej inwentaryzacji aplikacji i nie monitoruje tożsamości nieludzkich, skala potencjalnego incydentu rośnie bardzo szybko.

Dodatkowym problemem jest to, że AI przyspiesza nie tylko wejście do środowiska, ale również kolejne fazy ataku. To zmniejsza margines czasu na reakcję po stronie SOC i zwiększa znaczenie automatyzacji procesów obronnych.

Rekomendacje

Organizacje powinny traktować bezpieczeństwo tożsamości jako jeden z fundamentów cyberodporności. Oznacza to konieczność wdrożenia działań zarówno technicznych, jak i operacyjnych.

Wdrożenie phishing-resistant MFA, najlepiej w standardzie FIDO2/WebAuthn, szczególnie dla kont uprzywilejowanych, administratorów i dostępu zdalnego.
Regularny przegląd ról i uprawnień oraz eliminacja nieużywanych kont zgodnie z zasadą least privilege.
Objęcie ochroną tożsamości nieludzkich, takich jak konta serwisowe, tokeny API, sekrety w CI/CD i integracje między aplikacjami.
Centralizacja telemetrii i analiza behawioralna obejmująca anomalie logowania, nietypowe użycie tokenów i eskalację uprawnień.
Ograniczanie powierzchni ataku przeglądarki i poczty elektronicznej poprzez ochronę sesji, kontrolę rozszerzeń i twarde polityki OAuth.
Ćwiczenie scenariuszy reagowania na incydenty identity-centric, w tym przejęcia kont administratorów, tokenów sesyjnych oraz aplikacji SaaS.

W praktyce tożsamość powinna być monitorowana równie uważnie jak ruch sieciowy czy aktywność endpointów. Bez tego nawet rozbudowane środki ochrony mogą nie wykryć ataku, który formalnie wygląda jak zwykłe logowanie uprawnionego użytkownika.

Podsumowanie

Najważniejszy trend w cyberbezpieczeństwie nie polega wyłącznie na pojawieniu się AI, lecz na tym, że sztuczna inteligencja wzmacnia ataki wykorzystujące dobrze znane słabości organizacyjne. Tożsamość pozostaje najłatwiejszą drogą do kompromitacji, a automatyzacja ofensywna dodatkowo skraca czas potrzebny napastnikom na osiągnięcie celu.

Dla zespołów bezpieczeństwa oznacza to konieczność przesunięcia uwagi z samej ochrony perymetru na ochronę kont, sesji, integracji, uprawnień i relacji zaufania. Firmy, które zbudują dojrzały program identity security, wdrożą odporne na phishing MFA oraz poprawią widoczność w środowiskach SaaS i chmurowych, będą lepiej przygotowane na nową generację przyspieszonych cyberataków.

Źródła

https://www.paloaltonetworks.com/resources/research/unit-42-incident-response-report
https://www.paloaltonetworks.com/company/press/2026/unit-42-report–ai-and-attack-surface-complexity-fuel-majority-of-breaches
https://www.cisa.gov/mfa
https://www.cisa.gov/news-events/alerts/2022/10/31/cisa-releases-guidance-phishing-resistant-and-numbers-matching
https://www.techtarget.com/searchsecurity/news/366639638/News-brief-Attackers-gain-speed-in-cybersecurity-race

Phishing typu device code atakuje Microsoft 365 i omija klasyczne zabezpieczenia OAuth

Wprowadzenie do problemu / definicja

Phishing typu device code to technika przejęcia dostępu, która wykorzystuje legalny mechanizm OAuth 2.0 Device Authorization Grant. Został on zaprojektowany z myślą o urządzeniach z ograniczonym interfejsem, takich jak telewizory smart, kioski czy urządzenia IoT, jednak w praktyce coraz częściej staje się narzędziem nadużyć w środowiskach chmurowych.

W tym scenariuszu atakujący nie musi kraść hasła w tradycyjny sposób. Zamiast tego nakłania ofiarę do wpisania specjalnego kodu urządzenia na prawdziwej stronie logowania Microsoft. Jeśli użytkownik zakończy proces powodzeniem, napastnik może uzyskać tokeny dostępu i odświeżania, które pozwalają na dalsze działanie w koncie ofiary.

W skrócie

W marcu 2026 roku opisano kampanię wymierzoną w ponad 340 organizacji korzystających z Microsoft 365 w kilku krajach, w tym w Stanach Zjednoczonych, Kanadzie, Australii, Nowej Zelandii i Niemczech. Atak wykorzystywał legalny przepływ device code w ekosystemie Microsoft 365 i Microsoft Entra ID.

Mechanizm ataku polegał na generowaniu prawidłowego kodu urządzenia, a następnie przekazywaniu go ofierze za pośrednictwem spreparowanych wiadomości e-mail i stron pośrednich. Po wpisaniu kodu przez użytkownika na autentycznej stronie Microsoft dochodziło do wystawienia tokenów OAuth, co mogło zapewnić napastnikowi trwały dostęp do danych i usług organizacji.

Atak bazuje na legalnym procesie logowania Microsoft.
Może działać mimo poprawnie wdrożonego MFA.
Umożliwia przejęcie tokenów bez kradzieży hasła.
Stanowi rosnące zagrożenie dla środowisk Microsoft 365.

Kontekst / historia

Device code flow jest częścią standardu OAuth 2.0 i służy do uwierzytelniania urządzeń, które nie mają pełnej przeglądarki lub wygodnej klawiatury. Użytkownik rozpoczyna logowanie na jednym urządzeniu, a kończy je na innym, wpisując kod na stronie logowania. Z perspektywy użyteczności jest to rozwiązanie wygodne, ale z perspektywy bezpieczeństwa tworzy nietypową powierzchnię ataku.

Już wcześniej badacze oraz dostawcy zabezpieczeń ostrzegali, że phishing wykorzystujący device code może być używany zarówno w operacjach ukierunkowanych, jak i w bardziej masowych kampaniach. Obecna fala ataków pokazuje jednak wyraźną ewolucję tej techniki: od pojedynczych incydentów do szerzej zakrojonych, częściowo zautomatyzowanych operacji wspieranych zewnętrzną infrastrukturą phishingową.

Rosnące znaczenie tej techniki wynika również z faktu, że organizacje przez długi czas traktowały device code flow jako niszowy wyjątek. Dziś staje się jasne, że legalny przepływ uwierzytelniania może zostać skutecznie wykorzystany do przejęcia tożsamości bez klasycznego podszywania się pod stronę logowania.

Analiza techniczna

Schemat ataku jest stosunkowo prosty. Napastnik najpierw uzyskuje legalny kod urządzenia z interfejsu device code. Następnie przygotowuje wiadomość phishingową opartą na wiarygodnym pretekście biznesowym, na przykład dotyczącym dokumentu, wiadomości głosowej, podpisu elektronicznego lub postępowania przetargowego.

Ofiara trafia na stronę pośrednią, która wyświetla wygenerowany kod oraz instruuje, aby przejść do prawdziwej strony logowania Microsoft i go wpisać. Po uwierzytelnieniu i zatwierdzeniu MFA system wydaje tokeny powiązane z sesją. Ponieważ atakujący kontroluje początkowy proces, może następnie odebrać te tokeny z odpowiedniego punktu końcowego OAuth.

W analizowanej kampanii wykorzystano wieloetapowe łańcuchy przekierowań oraz infrastrukturę pośredniczącą, w tym usługi chmurowe i komponenty PaaS. Końcowe strony phishingowe dynamicznie prezentowały kod urządzenia, co sugeruje częściową automatyzację procesu. Badacze opisali także powiązania z usługami phishing-as-a-service oraz z technikami utrudniającymi analizę, takimi jak blokowanie narzędzi deweloperskich czy inspekcji strony.

Najważniejsza różnica względem klasycznego phishingu polega na tym, że użytkownik nie wpisuje danych na fałszywej stronie. Loguje się do autentycznej usługi Microsoft, co znacząco obniża czujność i utrudnia rozpoznanie oszustwa.

Konsekwencje / ryzyko

Największe zagrożenie wynika z tego, że legalny interfejs logowania budzi zaufanie użytkownika. W efekcie tradycyjne porady, takie jak sprawdzanie domeny, przestają być wystarczające. Atak nie bazuje na podróbce formularza, lecz na socjotechnice i nadużyciu poprawnego przepływu uwierzytelniania.

Drugim poważnym ryzykiem jest trwałość dostępu. Jeśli napastnik uzyska token odświeżania, może utrzymać dostęp nawet po zmianie hasła, o ile organizacja nie unieważni aktywnych sesji i tokenów. To oznacza, że samo zresetowanie poświadczeń może nie zakończyć incydentu.

Skutki mogą obejmować przejęcie skrzynki pocztowej, dostęp do dokumentów w SharePoint i OneDrive, nadużycia aplikacji OAuth, a także dalszy ruch boczny w środowisku SaaS. W praktyce taka kompromitacja może prowadzić do ataków BEC, wewnętrznego phishingu oraz wycieku danych biznesowych.

Rekomendacje

Najważniejszym krokiem obronnym jest wyłączenie lub ścisłe ograniczenie device code flow wszędzie tam, gdzie nie jest on rzeczywiście potrzebny operacyjnie. Organizacje korzystające z Microsoft Entra Conditional Access powinny jawnie kontrolować ten przepływ i blokować go dla większości użytkowników, lokalizacji oraz scenariuszy dostępu.

Drugim filarem ochrony pozostaje monitoring logów logowania. Zespoły bezpieczeństwa powinny analizować wykorzystanie device code flow, nietypowe adresy IP, logowania pochodzące z infrastruktury chmurowej niewykorzystywanej w działalności operacyjnej oraz wszelkie anomalie pojawiające się po interakcji użytkownika z podejrzaną wiadomością.

Wyłączyć device code flow tam, gdzie nie jest niezbędny.
Monitorować logi Microsoft Entra pod kątem użycia tego przepływu.
Unieważniać aktywne sesje i refresh tokeny po incydencie.
Przeglądać zgody aplikacyjne oraz uprawnienia OAuth.
Rozszerzyć szkolenia awareness o scenariusze wpisywania kodu na legalnej stronie Microsoft.

W przypadku podejrzenia kompromitacji nie należy ograniczać się do zmiany hasła. Konieczne jest unieważnienie sesji, cofnięcie tokenów, analiza aktywności w poczcie i plikach, a także sprawdzenie, czy konto nie zostało wykorzystane do dalszych działań wewnętrznych. Warto również ograniczyć możliwość samodzielnego nadawania zgód aplikacjom przez użytkowników.

Podsumowanie

Kampania phishingu typu device code pokazuje, że współczesne ataki na tożsamość coraz częściej koncentrują się nie na kradzieży haseł, lecz na przejmowaniu tokenów i nadużywaniu legalnych przepływów OAuth. To przesuwa punkt ciężkości z klasycznego phishingu domenowego w stronę bardziej wyrafinowanych nadużyć zaufanej infrastruktury.

Dla organizacji korzystających z Microsoft 365 najważniejszy wniosek jest prosty: legalny proces logowania nie zawsze oznacza legalną intencję. Device code flow powinien być traktowany jako funkcja podwyższonego ryzyka, objęta ścisłą kontrolą, monitoringiem i procedurami reagowania uwzględniającymi unieważnianie tokenów, a nie tylko reset haseł.

Źródła

The Hacker News — Device Code Phishing Hits 340+ Microsoft 365 Orgs Across Five Countries via OAuth Abuse — https://thehackernews.com/2026/03/device-code-phishing-hits-340-microsoft.html
Huntress — Oh, Auth 2.0! Device Code Phishing in Google Cloud and Azure — https://www.huntress.com/blog/oh-auth-2-0-device-code-phishing-in-google-cloud-and-azure
Microsoft Learn — Authentication flows as a condition in Conditional Access policy – Microsoft Entra ID — https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows
Microsoft Learn — OAuth 2.0 device authorization grant – Microsoft identity platform — https://learn.microsoft.com/en-ie/entra/identity-platform/v2-oauth2-device-code
Microsoft Learn — Protect against consent phishing – Microsoft Entra ID — https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/protect-against-consent-phishing

GlassWorm wykorzystuje dead dropy w Solanie do dostarczania RAT i kradzieży danych przeglądarki oraz kryptowalut

Wprowadzenie do problemu / definicja

GlassWorm to zaawansowana kampania malware powiązana z atakami na łańcuch dostaw oprogramowania. W najnowszej odsłonie zagrożenie łączy złośliwe pakiety i zatrute aktualizacje z mechanizmem ukrywania infrastruktury C2 opartym na blockchainie Solana, który pełni rolę dead drop resolvera.

W praktyce oznacza to, że złośliwe oprogramowanie nie musi zawierać na stałe zakodowanego adresu serwera sterującego. Zamiast tego może dynamicznie pobierać dane konfiguracyjne z informacji umieszczonych w transakcjach, co utrudnia blokowanie i analizę infrastruktury napastników.

W skrócie

GlassWorm wykorzystuje Solanę do pobierania informacji o serwerach C2.
Kampania łączy infostealera, RAT, phishing portfeli sprzętowych i przejęcie danych przeglądarkowych.
Malware kradnie cookies, tokeny sesyjne, historię przeglądania, dane portfeli kryptowalutowych, zrzuty ekranu i naciśnięcia klawiszy.
Ataki obejmują również fałszywe rozszerzenie podszywające się pod Google Docs Offline.
Użytkownicy Ledger i Trezor są wabieni do ujawnienia seed phrase przez spreparowane komunikaty.

Kontekst / historia

GlassWorm był wcześniej łączony z długotrwałą aktywnością wymierzoną w ekosystem deweloperski. Operatorzy zagrożenia publikowali złośliwe pakiety w popularnych repozytoriach, nadużywali platform kodu oraz przejmowali konta maintainerów, aby rozprowadzać skażone aktualizacje.

Takie podejście wpisuje się w szerszy trend ataków supply chain, w których ofiara instaluje pozornie legalny komponent z zaufanego źródła. Najnowsza analiza pokazuje jednak dalszą ewolucję tej kampanii: celem nie jest już tylko kradzież danych z hosta, ale także przejęcie aktywów kryptowalutowych, utrzymanie dostępu i zwiększenie odporności infrastruktury na zakłócenia.

Analiza techniczna

Łańcuch infekcji rozpoczyna się od zainfekowanego pakietu lub komponentu dostarczonego przez skompromitowany kanał dystrybucji. Po uruchomieniu malware analizuje środowisko ofiary i unika infekowania systemów z rosyjską lokalizacją, a następnie pobiera dane potrzebne do dalszej komunikacji z infrastrukturą operatora.

Najważniejszym elementem kampanii jest użycie Solany jako dead drop resolvera. Zamiast przechowywać adres C2 bezpośrednio w kodzie, malware odczytuje go z memo zapisanych w transakcjach blockchain. W części łańcucha infekcji wykorzystywane jest także publiczne wydarzenie w Google Calendar jako dodatkowy kanał pozyskiwania konfiguracji.

Drugi etap obejmuje framework do kradzieży danych, który zbiera poświadczenia, profiluje system i przechwytuje informacje związane z portfelami kryptowalutowymi. Dane są następnie pakowane do archiwum i eksfiltrowane na serwery kontrolowane przez napastników.

Jednym z modułów jest binarium .NET ukierunkowane na phishing portfeli sprzętowych. Komponent wykorzystuje WMI do wykrywania podłączenia urządzeń USB. Po wykryciu Ledger lub Trezor użytkownik otrzymuje fałszywy komunikat błędu i formularz zachęcający do wpisania 24-wyrazowej frazy odzyskiwania. Dodatkowo legalna aplikacja może być zamykana, a okno phishingowe wyświetlane ponownie.

Kolejny istotny element to JavaScriptowy RAT komunikujący się przez WebSocket. Moduł wykorzystuje rozproszoną tablicę skrótów do pozyskiwania konfiguracji, a w razie niepowodzenia wraca do mechanizmu opartego na Solanie. RAT umożliwia m.in. uruchomienie HVNC, zestawienie tunelu SOCKS z użyciem WebRTC, pobieranie danych z przeglądarek, wykonywanie kodu JavaScript i przesyłanie informacji systemowych.

Szczególnie groźny jest moduł odpowiedzialny za kradzież danych z przeglądarek takich jak Chrome, Edge, Brave, Opera, Opera GX, Vivaldi i Firefox. Według opisu badaczy potrafi on obchodzić mechanizmy ochronne Chrome App-Bound Encryption, zwiększając skuteczność pozyskiwania lokalnie przechowywanych danych.

Na Windows i macOS malware instaluje również rozszerzenie Chrome podszywające się pod Google Docs Offline. Rozszerzenie może zbierać cookies, localStorage, drzewo DOM aktywnej karty, zakładki, zrzuty ekranu, naciśnięcia klawiszy, zawartość schowka, historię przeglądania oraz listę zainstalowanych dodatków. Analiza wskazuje też na monitorowanie wybranych serwisów, w tym reguły powiązane z platformami kryptowalutowymi.

Konsekwencje / ryzyko

GlassWorm jest zagrożeniem wysokiego ryzyka, ponieważ łączy kilka klas ataków w jednym łańcuchu operacyjnym. Dla użytkowników indywidualnych oznacza to możliwość utraty haseł, aktywnych sesji, danych z przeglądarek oraz środków przechowywanych w portfelach kryptowalutowych.

Dla organizacji szczególnie niebezpieczne jest to, że punkt wejścia może stanowić pozornie legalny pakiet deweloperski lub rozszerzenie. Taka infekcja może prowadzić do przejęcia kont uprzywilejowanych, tokenów sesyjnych do usług SaaS, danych z narzędzi programistycznych oraz lokalnie zapisanych sekretów. Możliwość uruchamiania HVNC i tuneli proxy dodatkowo zwiększa potencjał do ruchów bocznych i ukrywania aktywności operatora.

Wykorzystanie blockchaina oraz zewnętrznych usług jako dead dropów podnosi odporność infrastruktury napastników na blokowanie. Z kolei złośliwe rozszerzenie przeglądarkowe pozwala przechwytywać dane już po uwierzytelnieniu, co czyni samą ochronę haseł niewystarczającą.

Rekomendacje

Organizacje powinny zaostrzyć kontrolę pochodzenia pakietów i rozszerzeń instalowanych w środowiskach deweloperskich. Konieczne jest weryfikowanie wydawców, historii publikacji, integralności paczek oraz ograniczanie instalacji komponentów spoza zatwierdzonych rejestrów.

W warstwie endpointów warto monitorować nietypowe procesy potomne uruchamiane przez narzędzia deweloperskie, aktywność WMI związaną z wykrywaniem urządzeń USB, podejrzane instalacje rozszerzeń przeglądarkowych oraz anomalie w ruchu WebSocket i WebRTC.

Zespoły bezpieczeństwa powinny rozwijać detekcję prób dostępu do magazynów cookies, tokenów sesyjnych, localStorage i historii przeglądania. W środowiskach o podwyższonym ryzyku należy rozważyć blokowanie nieautoryzowanych rozszerzeń oraz stosowanie list dozwolonych dodatków.

Użytkownicy portfeli sprzętowych powinni pamiętać, że legalne aplikacje nie proszą o podanie pełnej frazy odzyskiwania w oknie systemowym po podłączeniu urządzenia. Każdy taki komunikat należy traktować jako próbę phishingu. Dobrym podejściem jest także oddzielenie systemów używanych do operacji kryptowalutowych od codziennej pracy.

W przypadku podejrzenia infekcji należy przeanalizować zainstalowane pakiety i rozszerzenia, unieważnić aktywne sesje, zresetować poświadczenia i klucze oraz sprawdzić system pod kątem artefaktów powiązanych z kampanią GlassWorm.

Podsumowanie

GlassWorm pokazuje, że współczesne kampanie malware coraz skuteczniej łączą ataki supply chain, kradzież danych, phishing portfeli sprzętowych i nadużycia rozszerzeń przeglądarkowych. Wykorzystanie Solany jako dead drop resolvera dodatkowo utrudnia wykrywanie i neutralizację infrastruktury sterującej.

Dla obrońców najważniejszy wniosek jest prosty: pakiety, rozszerzenia i sesje przeglądarkowe muszą być traktowane jako krytyczna powierzchnia ataku. Skuteczna ochrona wymaga połączenia kontroli aplikacyjnych, telemetrii endpointowej, monitoringu przeglądarek oraz ciągłej walidacji zaufania do komponentów zewnętrznych.

Źródła

The Hacker News — GlassWorm Malware Uses Solana Dead Drops to Deliver RAT and Steal Browser, Crypto Data — https://thehackernews.com/2026/03/glassworm-malware-uses-solana-dead.html
Aikido Security — analiza kampanii GlassWorm — https://www.aikido.dev/
Koi Security — obserwacje dotyczące GlassWorm i MCP — https://www.koi.ai/
AFINE — Glassworm-hunter — https://afine.com/
GitHub — glassworm-hunter — https://github.com/