News | Secawa

Trzy niezależne zespoły badawcze pokazały w pierwszej połowie sierpnia 2026 r., jak przejść uwierzytelnianie oparte na passkeys bez znajomości klucza prywatnego użytkownika, a w jednym przypadku także jak ten klucz odzyskać.

Michael Grafnetter ze SpecterOps zaprezentował atak Pass-the-Passkey na Black Hat USA 2026 w dniu 5 sierpnia, Unit 42 z Palo Alto Networks opisała rodzinę ataków Pass-ta-key wymierzonych w Google Password Manager w Chrome, a Dirk-jan Mollema wykazał możliwość użycia Windows Hello for Business bez PIN-u i biometrii.

Relację z całości opublikował 10 sierpnia 2026 r. serwis The Hacker News. Żadna z tych metod nie łamie kryptografii FIDO2/WebAuthn, wszystkie celują w infrastrukturę wokół standardu, a każda wymaga, żeby napastnik miał już dostęp do środowiska ofiary, czyli konta uwierzytelnionego użytkownika bez podwyższonych uprawnień albo złośliwego oprogramowania działającego w jego sesji.

Trzy niezależne badania, jeden wspólny mianownik

Passkeys to poświadczenia oparte na kryptografii asymetrycznej, w których klucz prywatny nie opuszcza urządzenia ani chronionego magazynu użytkownika, a serwis weryfikuje wyłącznie podpis wygenerowany na żądanie. Taka konstrukcja usuwa hasło jako sekret możliwy do przekazania napastnikowi, dlatego logowanie passkeyem uchodzi za odporne na phishing i w politykach dostępu figuruje jako phishing-resistant MFA. Sierpniowe badania nie podważają tej właściwości na poziomie protokołu, pokazują natomiast, że status phishing-resistant da się uzyskać bez klucza prywatnego ofiary i bez jej udziału w logowaniu.

Trzy linie badawcze uderzają w różne elementy łańcucha uwierzytelniania:

Pass-the-Passkey (SpecterOps, Black Hat USA 2026, 5 sierpnia) – ponowne wykorzystanie podpisów WebAuthn zapisywanych w dzienniku zdarzeń Windows do uwierzytelnienia w Microsoft Entra ID jako inny, uprzywilejowany użytkownik.
Pass-ta-key wraz z najgroźniejszym wariantem Golden Pass-ta-key (Unit 42, Palo Alto Networks) – trzy ścieżki ataku na zsynchronizowane passkeys w Google Password Manager w Chrome, łącznie z odzyskaniem kluczy prywatnych ofiary.
Windows Hello for Business bez PIN-u i biometrii (Dirk-jan Mollema) – generowanie świeżych asercji WebAuthn kluczem chronionym przez moduł TPM, bez ponownego potwierdzenia tożsamości przez użytkownika.

Kolejność zdarzeń jest w każdym z tych scenariuszy taka sama – napastnik najpierw uzyskuje dostęp do środowiska ofiary, a dopiero potem sięga po passkey. Różni je skutek oraz stan poprawek, od luki w pełni załatanej przez producenta po ochronę wciąż częściową.

Podpisy WebAuthn zapisywane w dzienniku zdarzeń Windows

Michael Grafnetter ze SpecterOps wykazał, że do uwierzytelnienia w Microsoft Entra ID wystarczy podpis WebAuthn wygenerowany wcześniej przez cudzy klucz sprzętowy, o ile da się go odczytać z logów systemowych. Windows zapisywał takie podpisy, między innymi pochodzące z kluczy YubiKey, w postaci jawnej, dostępnej dla uwierzytelnionego użytkownika bez podwyższonych uprawnień, również pracującego zdalnie.

Atak przebiegał w czterech krokach:

Odczytanie podpisu WebAuthn z dziennika zdarzeń Windows, bez podwyższonych uprawnień i bez fizycznego dostępu do klucza sprzętowego ofiary.
Przesłanie tego podpisu do Entra ID jako odpowiedzi na challenge WebAuthn, czyli jednorazowe wyzwanie wysyłane przez usługę do podpisania.
Uwierzytelnienie się jako inny, uprzywilejowany użytkownik – wydobycie klucza prywatnego z YubiKeya nie było potrzebne, bo Entra przyjmowała sam podpis jako dowód posiadania passkeya.
Zachowanie statusu phishing-resistant MFA i przejście reguł Conditional Access, które ten scenariusz miały wykluczać.

Podatność na ponowne użycie podpisu wynikała także z konstrukcji challenge’y po stronie Entra. Według SpecterOps „Entra nadal używa tokenów JSON Web Token (JWT) jako challenge’y WebAuthn zamiast pseudolosowo generowanych nonce’ów i nie wydaje się wiązać challenge’y WebAuthn z ciasteczkami sesji” .

Stan podatności i poprawek wygląda następująco

CVE-2026-34348 dotyczy usługi Windows Event Logging Service i została oceniona na CVSS 6.5.
Podatne są Windows 10, Windows 11 i Windows Server.
Poprawki Microsoft wydał 14 lipca 2026 r., skracając pole podpisu w logowanych asercjach do sześciu bajtów.
SpecterOps ocenia, że po ich zainstalowaniu pełny łańcuch ataku z Windows do Entra jest niewykonalny, ponieważ zapisy w logach nie nadają się już do ponownego odtworzenia.
Mechanizm challenge’y po stronie Entra pozostał bez zmian, a badacze zaznaczają, że nie testowali go ponownie od czerwca 2026 r.

Microsoft odniósł się do zgłoszenia w wypowiedzi dla The Hacker News:

Doceniamy pracę SpecterOps, która zgłosiła ten problem w ramach skoordynowanego ujawniania podatności. Zastosowaliśmy mitygacje dla zgłoszonego problemu dotyczącego przekazywania asercji passkey i nadal inwestujemy w usprawnienia bezpieczeństwa metod uwierzytelniania. Zalecamy przyjęcie podejścia least-privilege, korzystanie z metod uwierzytelniania odpornych na phishing oraz utrzymywanie ochrony urządzeń końcowych w modelu Zero Trust, aby zapewnić lepszą ochronę.

Microsoft

Klucz nadrzędny chroniący synchronizację passkeys w Chrome

Zsynchronizowane passkeys różnią się od poświadczeń przypisanych do jednego urządzenia tym, że ich zaszyfrowane kopie trafiają na konto użytkownika u dostawcy i schodzą na kolejne urządzenia po zalogowaniu. Unit 42 z Palo Alto Networks opisała wymierzoną w ten model rodzinę ataków Pass-ta-key na Google Password Manager w przeglądarce Chrome. Wszystkie warianty zakładają, że na urządzeniu ofiary działa już złośliwe oprogramowanie, przy czym uprawnienia administracyjne nie są do nich potrzebne.

Badacze opisali trzy ścieżki

Nadużycie tożsamości urządzenia w Chrome – złośliwy kod podszywa się pod legalnego klienta Password Managera i uzyskuje podpisy uwierzytelniające, mimo że użytkownik nie odblokował w tym czasie urządzenia.
Manipulacja flagą user verification – flaga mówi serwisowi, czy użytkownik potwierdził tożsamość PIN-em lub biometrią. Jej podmiana pozwala wyłudzić od serwisu zgodę na logowanie, którego nikt nie zatwierdził. Unit 42 zademonstrowała tę technikę na serwisie eBay.
Golden Pass-ta-key – najgroźniejszy wariant, celujący w Security Domain Secret, czyli 32-bajtowy klucz nadrzędny, którym Google chroni zsynchronizowane passkeys użytkownika.

Zdobycie Security Domain Secret pozwala odzyskać prywatne klucze passkeys ofiary, a nie tylko wygenerować pojedynczy podpis. Skutek jest przy tym trwały, ponieważ dla tego sekretu nie istnieje obecnie mechanizm rotacji ani unieważnienia – ofiara nie może go zmienić tak, jak zmienia hasło.

Reakcje po zgłoszeniu były częściowe. Google usunął Security Domain Secret z logów urządzenia, ale według badaczy sekret nadal pojawia się przejściowo w pamięci procesu Chrome podczas ponownej rejestracji. eBay poprawił walidację flagi user verification po otrzymaniu zgłoszenia.

Klucz w module TPM użyty bez PIN-u i biometrii

Dirk-jan Mollema pokazał trzecią drogę, tym razem przez Windows Hello for Business – metodę logowania, w której klucz uwierzytelniający jest chroniony przez moduł TPM i odblokowywany PIN-em albo biometrią. Proces o niskich uprawnieniach, działający w już zalogowanej sesji użytkownika, może odwołać się do interfejsów kryptograficznych Windows i użyć tego klucza bez ponownego podania PIN-u i bez skanu biometrycznego. Klucz pozostaje niemożliwy do wyeksportowania, ale generuje świeże asercje WebAuthn na żądanie atakującego.

Sprzyja temu sposób, w jaki Entra wystawia wyzwania do podpisania. Challenge WebAuthn zachowuje ważność przez pięć minut i nie jest powiązany z sesją, użytkownikiem ani tenantem, więc podpis wykonany w tle spełnia reguły Conditional Access wymagające uwierzytelnienia odpornego na phishing. Mollema wskazał też, że w takim uwierzytelnieniu może zabraknąć informacji o identyfikatorze urządzenia, co otwiera drogę do pozyskania Primary Refresh Token i utrzymania dostępu do środowiska na dłużej.

Warunkiem wstępnym pozostaje złośliwe oprogramowanie działające w sesji zalogowanego użytkownika. Relacja The Hacker News nie podaje informacji o poprawce dla tego scenariusza.

Co zalecają badacze i dostawcy

Zalecenia sformułowane po sierpniowych publikacjach dotyczą dwóch obszarów jednocześnie: łatania konkretnych podatności i pilnowania miejsc, w których passkeys istnieją w formie możliwej do przechwycenia.

Instalacja poprawek dla CVE-2026-34348 na wszystkich objętych systemach Windows.
Egzekwowanie wymogu user verification po stronie serwisów przyjmujących asercje WebAuthn, zamiast przyjmowania flagi bez weryfikacji.
Traktowanie magazynów passkeys, pamięci przeglądarki oraz procesów odzyskiwania konta, wykorzystywanych już wcześniej do przejmowania kont na dużą skalę, jako obszaru wrażliwego na równi z samymi poświadczeniami.
Monitorowanie nietypowych uwierzytelnień Windows Hello for Business pozbawionych identyfikatora urządzenia oraz nieoczekiwanych rejestracji nowych urządzeń.
Śledzenie liczników podpisów (signature counter), które ujawniają ponowne użycie tego samego poświadczenia.

Microsoft w cytowanej wyżej wypowiedzi dokłada do tego podejście least-privilege i ochronę urządzeń końcowych w modelu Zero Trust.

Passkeys zastępują kody SMS w Entra ID

Od 1 września 2026 r. użytkownicy Entra ID korzystający z uwierzytelniania SMS-em lub połączeniem głosowym będą automatycznie obejmowani passkeys i zachęcani do ich rejestracji. Dostarczanie kodów SMS i połączeń głosowych przez Microsoft kończy się 1 lutego 2027 r. Sierpniowe publikacje badawcze wypadają więc w okresie, w którym liczba kont chronionych passkeys w Entra ID rośnie.

12 sierpnia 2026 r. wicepremier i minister cyfryzacji Krzysztof Gawkowski potwierdził wyciek danych z systemów firmy MyDr, która dostarcza lekarzom i placówkom ochrony zdrowia oprogramowanie do prowadzenia elektronicznej dokumentacji medycznej. Według jego słów incydent sięga blisko 19 milionów obywateli Polski i dotyczy ponad 12 tys. placówek ochrony zdrowia. 12 sierpnia zwołano posiedzenie Połączonego Centrum Operacyjnego Cyberbezpieczeństwa, a wykradzione dane mają trafiać do rządowego serwisu bezpiecznedane.gov.pl, który pozwoli obywatelom ustalić, czy są wśród poszkodowanych.

Oficjalne potwierdzenie wycieku danych medycznych z systemu MyDr

Wcześniej, w programie Onet Rano, wicepremier mówił jedynie o „prawdopodobieństwie bardzo dużego wycieku danych związanego z jedną z firm obsługujących lekarzy i gabinety lekarskie”. Konferencja prasowa po posiedzeniu PCOC 12 sierpnia potwierdziła, że do doszło do incydentu bezpieczeństwa.

Z przykrością muszę poinformować, że doszło do nadzwyczajnego wycieku danych, sięgającego blisko 19 milionów obywateli Polski, które w różnych kategoriach korzystały z wsparcia medycznego

powiedział Wicepremier i Minister Cyfryzacji Krzysztof Gawkowski

Sprawa zaczęła się 10 sierpnia, kiedy pojawiły się pierwsze doniesienia o możliwym wycieku z systemu obsługującego polskie przychodnie. Z redakcją Zaufanej Trzeciej Strony skontaktowali się wtedy rzekomi sprawcy incydentu bezpieczeństwa i przekazali próbkę danych. Dziennikarze poprosili ich o sprawdzenie numerów PESEL czterech osób z branży, które zgodziły się na eksperyment – rekordy z bazy otrzymali dla dwóch z nich. Redakcja zastrzegła przy tym, że jej możliwości weryfikacji są ograniczone i że nie potrafi potwierdzić informacji o danych ponad 18 mln osób.

Skala wycieku według rządu i według sprawców

Sprawcy twierdzą, że wykradli 18 814 422 unikatowe numery PESEL. Rząd podaje zbliżoną skalę – w komunikacie Ministerstwa Cyfryzacji mowa jest o 18,8 mln osób i ponad 12 tys. placówek medycznych, a wicepremier na konferencji mówił o „blisko 19 milionach obywateli Polski”.

W próbce udostępnionej dziennikarzom znalazły się:

numery PESEL,
imiona i nazwiska,
numery telefonów,
regiony NFZ,
dane recept wraz z informacjami o lekach.

Dokładny zakres wykradzionego zbioru wciąż jest ustalany. Z komunikatu resortu cyfryzacji wynika, że nieuprawniony dostęp objął dane historyczne gabinetów lekarskich przechowywane w systemach MyDr.

Cyberprzestępcy mogą wykorzystać te dane w przyszłych atakach. Dowiedz się, jak rozpoznać fałszywy telefon

Jak rozpoznać vishing? Krótki przewodnik

Posiedzenie Połączonego Centrum Operacyjnego Cyberbezpieczeństwa (PCOC)

Posiedzenie PCOC odbyło się 12 sierpnia o godz. 12:00, a konferencja prasowa z udziałem wicepremiera nastąpiła po nim. Z komunikatu Ministerstwa Cyfryzacji wynika, że działania koordynowane są przy udziale ministra koordynatora służb specjalnych, ministry zdrowia, Prezesa Urzędu Ochrony Danych Osobowych, Prokuratury Krajowej oraz Centralnego Biura Zwalczania Cyberprzestępczości.

Firma potwierdziła nieuprawniony dostęp do danych historycznych gabinetów lekarskich przechowywanych w jej systemach. Resort zaznaczył, że incydent ograniczył się do systemów MyDr i nie zakłócił pracy placówek – recepty wystawiane są normalnie.

Kto stoi za atakiem i co z okupem

Służby na tym etapie nie widzą śladów działania obcego państwa.

Nic nie wskazuje dzisiaj na to, że mamy do czynienia z atakiem zewnętrznym (…) ze strony rosyjskiej bądź jakiegokolwiek innego państwa

stwierdził Wicepremier i Minister Cyfryzacji Krzysztof Gawkowski

Służby wskazują na cyberprzestępców motywowanych finansowo, którzy liczą na wypłatę okupu.

Rząd tę kalkulację odrzucił. „Nikt w Polsce nie będzie płacił żadnych okupów” – zapowiedział wicepremier, zwracając się jednocześnie do sprawców: „Będziemy was bezwzględnie ścigali! (…) Bezwzględność polskich służb i prokuratury będzie ostateczna”.

Weryfikacja danych w serwisie Bezpieczne Dane

Obywatele sprawdzą swoje dane przez rządowy serwis bezpiecznedane.gov.pl.

„Po identyfikacji, czyje dane zostały w sposób nieuprawniony przejęte przez cyberprzestępców, będą one sukcesywnie przekazywane do serwisu bezpiecznedane.gov.pl, w którym każdy będzie mógł sprawdzić, czy ten incydent dotyczy go bezpośrednio” – czytamy w komunikacie resortu cyfryzacji.

Weryfikacja nie zostanie więc uruchomiona natychmiast. Resort zastrzegł, że przekazanie danych do serwisu może zająć kilka dni, ponieważ administratorami są poszczególne gabinety lekarskie i placówki ochrony zdrowia.

Rekomendacje rządu dla obywateli – należy zastrzec PESEL

Zastrzeżenie numeru PESEL rząd wskazał jako pierwszą czynność do wykonania i nazwał je „elementarną higieną cyfrową”.

Zastrzeżenie numeru PESEL w mObywatelu trwa 5 sekund

podkreślił Wicepremier i Minister Cyfryzacji Krzysztof Gawkowski

Mechanizm polega na tym, że instytucje finansowe mają obowiązek sprawdzić, czy numer PESEL jest zastrzeżony, przy zawieraniu m.in. umowy kredytu lub pożyczki. Zastrzeżenie nie utrudnia przy tym rejestracji u lekarza, realizacji recept ani wykonywania przelewów.

Pozostałe zalecenia przedstawione na konferencji:

uwierzytelnianie dwuskładnikowe w usługach online, najlepiej z użyciem kluczy sprzętowych U2F,
silne i unikalne hasła dla każdego serwisu,
ostrożność wobec niespodziewanych kontaktów telefonicznych, SMS-owych i mailowych.

Ostatni punkt ma bezpośredni związek z zakresem wycieku. W próbce znalazły się numery telefonów i dane recept, czyli informacje, którymi można posłużyć się w rozmowie z ofiarą, żeby uwiarygodnić kontakt.

Kto ma obowiązek zawiadomić pacjentów i UODO

Zawiadomienie pacjentów i Urzędu Ochrony Danych Osobowych należy do administratora danych, a jest nim każda przychodnia korzystająca z MyDr osobno – nie dostawca oprogramowania. Zgodnie z wytycznymi UODO obowiązek zgłoszenia spoczywa na administratorze także wtedy, gdy do naruszenia doszło u podmiotu przetwarzającego.

Sama firma na etapie pierwszych doniesień przekazała redakcji Zaufanej Trzeciej Strony, że „obecnie prowadzimy postępowanie wyjaśniające dotyczące zgłoszonego incydentu związanego z systemami MyDr”, i zadeklarowała uruchomienie procedur reagowania oraz współpracę z organami i ekspertami. Przy ponad 12 tys. placówek oznacza to tysiące oddzielnych zawiadomień. Dlatego resort cyfryzacji zapowiedział centralną weryfikację przez serwis Bezpieczne Dane, zastrzegając, że przekazanie danych może potrwać kilka dni.

Podsumowanie

12 sierpnia 2026 r. rząd potwierdził, że doszło do wycieku danych z systemów firmy MyDr, dostarczającej oprogramowanie do elektronicznej dokumentacji medycznej. Gigantyczny wyciek danych objął według sprawców 18 814 422 unikatowe numery PESEL, a według rządu blisko 19 milionów Polaków i ponad 12 tys. placówek ochrony zdrowia.

Cyberatak naruszył bezpieczeństwo danych pacjentów z historycznych zasobów gabinetów lekarskich – numerów PESEL, imion i nazwisk, numerów telefonów, regionów NFZ oraz danych recept. Posiedzenie Połączonego Centrum Operacyjnego Cyberbezpieczeństwa zwołano na godz. 12:00 w dniu 12 sierpnia, a służby nie widzą śladów działania obcego państwa i wskazują na przestępców liczących na okup, którego rząd zapowiedział, że nie zapłaci.

W ramach ochrony swoich danych obywatele powinni zastrzec numer PESEL w aplikacji mObywatel lub w urzędzie gminy, włączyć uwierzytelnianie dwuskładnikowe i zachować ostrożność wobec niespodziewanych telefonów (vishing) i SMS-ów (smishing). Każdy będzie mógł sprawdzić w serwisie bezpiecznedane.gov.pl, czy jego dane znalazły się w wycieku, gdy resort przekaże tam zidentyfikowane rekordy.

Jak rozpoznać vishing?

Pobierz krótki przewodnik

JadePuffer to pierwszy udokumentowany atak ransomware przeprowadzony od początku do końca przez autonomicznego agenta AI, bez udziału człowieka w podejmowaniu decyzji na którymkolwiek etapie włamania. Zespół Sysdig Threat Research Team namierzył operację, w której duży model językowy samodzielnie wykorzystał lukę w Langflow, przejął dane uwierzytelniające, przeniósł się na produkcyjny serwer z bazą MySQL i Alibaba Nacos, zaszyfrował 1342 elementy konfiguracji i zostawił notę z żądaniem okupu w Bitcoin.

Agent nie kopiował gotowego skryptu. Diagnozował przyczynę błędu i wdrażał poprawkę w tempie nieosiągalnym dla człowieka czytającego log ręcznie: w udokumentowanym przypadku od nieudanej próby logowania do działającej korekty minęło 31 sekund.

Atak JadePuffer w skrócie

Pierwszy w pełni autonomiczny atak ransomware sterowany przez LLM, opisany przez Sysdig w lipcu 2026 roku
Punkt wejścia: CVE-2025-3248, luka RCE w Langflow, popularnym frameworku do budowy aplikacji AI
Cel właściwy: osobny, eksponowany do internetu serwer produkcyjny z MySQL i Alibaba Nacos
Czas reakcji agenta na błąd logowania: 31 sekund od nieudanej próby do działającej poprawki
Klucz szyfrujący nigdy nie trafił do atakującego – dane ofiary są nie do odzyskania nawet po zapłacie okupu

Dotychczasowe procedury reagowania na incydenty zakładały, że za atakiem ransomware zawsze stoi człowiek, którego można spowolnić, wprowadzić w błąd albo z którym da się negocjować czas. JadePuffer pokazuje, że ten etap tradecraftu można już oddać modelowi.

Czym jest ransomware?

Ransomware to złośliwe oprogramowanie, które szyfruje pliki lub całe systemy operacyjne, a odblokowanie danych uzależnia od zapłaty okupu, najczęściej w kryptowalucie. Ten typ ataku od ponad dekady należy do najbardziej dochodowych narzędzi w rękach grup przestępczych, bo atakuje to, co dla organizacji ma największą wartość operacyjną: dostęp do własnych danych.

Klasyczny scenariusz ransomware trojan wygląda podobnie niezależnie od wariantu. Złośliwy kod trafia do systemu przez phishing, złamane hasło albo lukę w oprogramowaniu. Następnie po cichu szyfruje kluczowe dane na dysku i w kopiach zapasowych, po czym wyświetla notę z żądaniem okupu i terminem zapłaty.

Historia pokazuje rosnącą pomysłowość przestępców, ale też powtarzalny wzorzec działania oprogramowania ransomware: zaszyfruj, zażądaj, czekaj.

CryptoLocker (2013) – jeden z pierwszych masowo rozpowszechnionych programów typu ransomware, rozprzestrzeniający się przez zainfekowane załączniki e-mail i szyfrujący pliki silnym kluczem asymetrycznym.
CryptoLocker 2.0 – wariant napisany od nowa w innym języku programowania, który pojawił się krótko po rozbiciu infrastruktury oryginalnego CryptoLockera. Badacze bezpieczeństwa ocenili go jako naśladowcę korzystającego z rozpoznawalnej nazwy, nie kontynuację kodu pierwowzoru, i technicznie mniej dopracowanego.
CryptoDefense – wariant, który przez błąd programistyczny przechowywał klucz deszyfrujący lokalnie na zainfekowanej maszynie, co części ofiar pozwoliło na odzyskanie danych bez płacenia okupu.
Diskcoder ransomware – rodzina złośliwego oprogramowania niszcząca główny rekord rozruchowy dysku, przez co szyfrowanie plików uniemożliwiało nawet uruchomienie systemu operacyjnego.

Grupa ransomware nie musi dziś pisać własnego kodu od zera. Rynek cyberprzestępczy oferuje gotowe zestawy ransomware-as-a-service, a rola operatora często ogranicza się do wyboru celu i wysłania pierwszego payloadu. Zagrożenia ransomware ewoluowały z pojedynczych, autorskich programów w usługowy, powtarzalny model biznesowy – i to jeszcze zanim do gry weszły autonomiczne modele językowe.

JadePuffer – pierwszy atak ransomware w pełni sterowany przez LLM

Zespół Sysdig Threat Research Team udokumentował latem 2026 roku operację JadePuffer – pierwszy znany przypadek, w którym cały łańcuch ataku ransomware, od rekonesansu po zniszczenie danych, prowadził autonomiczny agent oparty na dużym modelu językowym, bez udziału człowieka na żadnym etapie włamania. Sysdig nazywa taki typ przeciwnika agentic threat actor (ATA) – aktorem, którego zdolność ofensywna pochodzi z agenta AI, a nie z ręcznie prowadzonego zestawu narzędzi.

Atak rozegrał się na dwóch różnych celach. Host skompromitowany jako pierwszy posłużył agentowi wyłącznie jako punkt startowy do włamania na właściwy, znacznie cenniejszy cel.

Jak przebiegał atak JadePuffer krok po kroku

Faza 1 – host wejściowy (Langflow)

Wejście przez CVE-2025-3248 – nieautoryzowaną lukę RCE w endpoincie walidacji kodu Langflow, popularnego open-source’owego frameworku do budowy aplikacji i agentów LLM. Producent załatał lukę 1 kwietnia 2025 roku, a CISA oznaczyła ją jako aktywnie wykorzystywaną w maju tego samego roku.
Rekonesans i przechwytywanie sekretów – agent zebrał dane o hoście (id, uname, interfejsy sieciowe, procesy) i równolegle przeszukał środowisko pod kątem kluczy API dostawców LLM, danych uwierzytelniających chmury (w tym chińskich dostawców Alibaba, Tencent, Huawei, obok AWS, GCP i Azure), portfeli kryptowalut oraz danych do baz danych.
Zrzut lokalnej bazy Postgres Langflow – wykradzione dane uwierzytelniające, klucze API i rekordy użytkowników zostały zapisane lokalnie, przejrzane, a pliki tymczasowe usunięte.
Enumeracja MinIO – agent użył domyślnych danych logowania (minioadmin:minioadmin), by przeszukać zasobnik obiektów, w tym bucket terraform-state. Gdy jedno z zapytań zwróciło XML zamiast oczekiwanego JSON, kolejny payload natychmiast dostosował parser do nowego formatu.
Utrzymanie dostępu – na hoście Langflow agent zainstalował wpis w harmonogramie zadań (crontab), wysyłający sygnał do infrastruktury atakującego co 30 minut. Dzięki temu nawet restart serwera nie przerywał połączenia z atakującym.

Faza 2 – cel właściwy (serwer produkcyjny MySQL i Alibaba Nacos)

Pivot na osobny serwer – z hosta Langflow agent przeszedł na eksponowany do internetu serwer produkcyjny z bazą MySQL i usługą Alibaba Nacos, wykorzystując konto root, którego pochodzenia badacze nie zdołali ustalić.
Przejęcie Nacos – równolegle wykorzystano lukę uwierzytelniania CVE-2021-29441, sfałszowano token JWT przy użyciu publicznie znanego domyślnego klucza podpisującego Nacos, a przez dostęp root do bazy wstrzyknięto konto administratora typu backdoor.
Rozpoznanie container escape – agent testował zapisywanie i odczyt plików przez MySQL, sprawdzał dostęp do docker.sock oraz plików procesu init – typowy zestaw działań poprzedzających próbę wyjścia z kontenera.
Szyfrowanie – wszystkie 1342 elementy konfiguracji Nacos zaszyfrowano funkcją AES_ENCRYPT() w MySQL, oryginalne tabele usunięto, a w ich miejsce utworzono tabelę README_RANSOM z żądaniem okupu, adresem Bitcoin i kontaktem e-mail.
Masowe niszczenie danych – agent eskalował z usuwania pojedynczych wierszy do komend DROP DATABASE na całych schematach, komentując w kodzie własną priorytetyzację celów według potencjalnej wartości danych. Warto zaznaczyć: adnotacja o wcześniejszym skopiowaniu danych na serwer zewnętrzny to twierdzenie samego agenta zapisane w jego własnym kodzie, nie fakt potwierdzony niezależnie przez badaczy. Rzeczywista skala eksfiltracji danych pozostaje nieznana.

Cztery dowody, że atakiem sterował LLM, nie człowiek

Sysdig wskazuje cztery niezależne przesłanki, które łącznie wykluczają scenariusz stałego, wcześniej napisanego skryptu:

Kod komentujący własne działania. Payloady zawierały szczegółowe uzasadnienia w naturalnym języku – dlaczego dana baza jest priorytetem, która jest „największa”, co dany krok ma osiągnąć. Człowiek pisząc jednorazowy skrypt raczej tego nie robi, model językowy robi to odruchowo.
Diagnoza i poprawka błędu w czasie liczonym w sekundach. Najbardziej precyzyjny dowód autonomii widać w sekwencji tworzenia konta administratora w Nacos:

Godzina (UTC)	Działanie agenta
19:34:24	Wstawia konto xadmin z hashem hasła wygenerowanym przez wywołanie subprocess
19:34:36	Próba logowania kończy się niepowodzeniem
19:34:48	Równolegle testuje dwie możliwe przyczyny błędu
19:35:07	Wprowadza poprawkę: bezpośredni import biblioteki bcrypt, usunięcie i odtworzenie konta
19:35:18	Logowanie kończy się sukcesem

Od nieudanej próby do działającej poprawki minęło 31 sekund – czas nieosiągalny dla człowieka czytającego log błędu, stawiającego diagnozę i piszącego korektę.

Rozumienie kontekstu podanego w naturalnym języku, a nie tylko dopasowywanie wzorców przez skaner – zachowanie powtarzalne w sesjach odległych od siebie o tygodnie. To ta sama zdolność modelu do interpretowania i reagowania na język naturalny, która w innych scenariuszach bywa nadużywana w atakach typu prompt injection. Tutaj jednak agent wykorzystywał tę zdolność we własnym działaniu ofensywnym, nie jako cel wstrzykniętych instrukcji.
Niejasność wokół adresu Bitcoin w nocie okupu – to standardowy przykładowy adres P2SH, powielany w dokumentacji Bitcoin, prawdopodobnie odtworzony przez model z danych treningowych. Blockchain pokazuje jednak, że to również aktywny portfel: 737 potwierdzonych transakcji i około 46 BTC otrzymanych w całej jego historii, przy czym każdy wpływ był natychmiast przekazywany dalej, a bieżące saldo wynosi zero. To nie rozstrzyga, czy model po prostu wygenerował ten adres z danych treningowych, czy operator świadomie skonfigurował agenta z realnym, kontrolowanym portfelem, ale wzmacnia argument, że nie jest to przypadkowy, martwy ciąg znaków. Łącznie ponad 600 odrębnych, celowych payloadów wykonanych w skompresowanym czasie potwierdza, że operację prowadził autonomiczny agent, nie człowiek zza klawiatury.

Konsekwencje dla organizacji – dlaczego to sygnał alarmowy dla CISO, CTO, CSO i CIO

Najpoważniejszą konsekwencją ataku ransomware sterowanego przez LLM nie jest samo szyfrowanie danych, lecz to, że przestają działać założenia, na których do tej pory opierały się procedury odzyskiwania danych i reagowania na incydenty.

Zapłata okupu nie gwarantuje odzyskania danych. Klucz szyfrujący w JadePuffer wygenerowano losowo i nigdy nie przesłano do atakującego – został tylko raz wypisany na ekranie sesji agenta. Ofiara nie odzyska 1342 zaszyfrowanych elementów konfiguracji Nacos nawet po spełnieniu żądania z noty ransom.
Kopie zapasowe nie rozwiązują problemu same z siebie. Celem ataku była żywa baza konfiguracyjna produkcyjnego serwera, nie tylko pliki na dysku. Szyfrowanie kopii zapasowych i procedury backupu mają sens tylko wtedy, gdy kopie są odizolowane od tej samej ścieżki dostępu, którą wykorzystał agent do ataku na system źródłowy.
Zasoby typu NoMoreRansom.org tu nie pomogą. Inicjatywy oferujące darmowe odzyskiwanie danych działają, gdy da się złamać implementację znanej rodziny ransomware albo odzyskać przechłamany klucz. Przy losowo generowanym, nigdzie nie przechowywanym kluczu AES nie ma czego łamać.
Próg wejścia do prowadzenia ataków ransomware spada do kosztu uruchomienia agenta. Aktywne dziś grupy ransomware, takie jak Rhysida czy Qilin (który przejął dużą część rynku po tym, jak RansomHub zniknął z sieci wiosną 2025 roku i został wchłonięty przez kartel DragonForce), to naturalni kandydaci do przejęcia podobnych narzędzi agentowych.
Tempo ataku eliminuje okno na reakcję. Sekwencja od nieudanego logowania do działającej poprawki zajęła 31 sekund. Kwartalny przegląd bezpieczeństwa infrastruktury, która zmienia się codziennie, zostawia luki, które autonomiczny agent zdąży wykorzystać, zanim ktokolwiek zauważy incydent.

JadePuffer nie jest odosobnionym sygnałem, że modele językowe da się skierować przeciwko organizacji

Niedawno opisywaliśmy, jak atakujący przekonali chatbota Meta AI, by zresetował hasła i pomógł przejąć 20 225 kont na Instagramie – zupełnie inny wektor, ten sam mechanizm: model wykonujący szkodliwe działania na podstawie tego, co „zrozumiał”.

Rosnąca liczba zgłoszonych ataków ransomware i incydentów ransomware z użyciem AI pokazuje, że to już nie jest scenariusz teoretyczny, tylko element krajobrazu cyberataków w erze GenAI, z którym organizacje muszą się zmierzyć już dziś. Jeśli chcesz zobaczyć więcej takich przypadków rozłożonych na czynniki pierwsze, w bezpłatnym cyklu webinarów AI vs. Cybersecurity Secawa omawialiśmy zarówno ataki sterowane przez AI, jak i ataki wymierzone w same systemy AI, wraz z nagraniami i materiałami do pobrania.

Bezpłatny cykl webinarów: ataki wspierane AI, Shadow AI, ataki na AI (prompt injection) i AI jako wsparcie CISO. 4 spotkania, dodatkowe materiały i kilku specjalistów SECAWA, którzy szczegółowo rozłożyli temat AI w kontekście cyberbezpieczeństwa.

Odbierz nagrania i materiały z cyklu AI vs Cybersecurity

Jak zabezpieczyć organizację przed ransomware sterowanym przez AI?

Zapobieganie atakom ransomware tego typu nie wymaga nowych narzędzi, tylko konsekwentnego domknięcia luk, które JadePuffer wykorzystał w kolejności zero-day nigdy nie było potrzebne:

Załataj Langflow do wersji usuwającej CVE-2025-3248 i nie eksponuj do internetu endpointów wykonania ani walidacji kodu.
Nie trzymaj kluczy API i danych uwierzytelniających chmury w środowisku serwerów orkiestracji AI. Sekrety powinny trafiać do dedykowanego menedżera, poza zasięgiem procesów dostępnych z sieci.
Utwardź Nacos – zmień domyślny klucz podpisujący (token.secret.key), zaktualizuj do wersji wymuszającej własny klucz, nigdy nie wystawiaj usługi do internetu i nigdy nie łącz jej z bazą jako root.
Nie eksponuj konta administracyjnego bazy danych do internetu. Silne, unikalne dane logowania i ograniczenia po adresie źródłowym IP to minimum.
Wprowadź kontrolę ruchu wychodzącego (egress), tak by skompromitowany host aplikacyjny nie mógł swobodnie łączyć się z dowolną infrastrukturą ani zewnętrznymi bazami.
Zainwestuj w wykrywanie zagrożeń działające w czasie rzeczywistym na poziomie procesów bazodanowych, nie tylko na poziomie sieci czy sygnatur plików.
Monitoruj wskaźniki kompromitacji – nietypowe zadania cron z wywołaniami sieciowymi, anomalie w nagłówkach żądań, nagłe skoki w liczbie zapytań do usług konfiguracyjnych.

Natomiast żadna z tych rekomendacji nie zadziała bez ludzi, którzy rozumieją, że socjotechnika w erze agentów AI wygląda inaczej niż jeszcze dwa lata temu. Zespoły bezpieczeństwa i IT warto przygotować również na metody socjotechniczne wspierane przez GenAI, bo granica między atakiem czysto technicznym a wspieranym manipulacją coraz częściej się zaciera.

Podsumowanie

JadePuffer zmienia trzy założenia, na których opierało się dotychczasowe planowanie obrony. Po pierwsze, próg wejścia do prowadzenia ataku ransomware spadł do kosztu uruchomienia agenta – a przy modelach napędzanych kradzionym dostępem obliczeniowym koszt ten zbliża się do zera. Po drugie, stare, pozornie niegroźne podatności – jak luka w Nacos z 2021 roku – są dziś automatycznie odświeżane przez agenty przeszukujące cały historyczny katalog CVE, więc zaniedbana, niezałatana infrastruktura staje się bardziej, nie mniej, atrakcyjnym celem. Po trzecie, kod generowany przez LLM sam opisuje swoje intencje – ta sama cecha, która czyni agenta groźnym, daje obrońcom nową szansę wykrycia ataku zanim dojdzie do szyfrowania.

Modelowanie zagrożeń dla systemów opartych na AI przestaje być ćwiczeniem akademickim – to punkt wyjścia do oceny ryzyka w każdej organizacji, która wdraża agentowe narzędzia AI albo jest potencjalnym celem takich, jak JadePuffer. Więcej o tym, jak systematycznie modelować zagrożenia związane z prompt injection w systemach AI, znajdziesz w naszym poprzednim materiale.

Jeśli wolisz zobaczyć te mechanizmy rozłożone na czynniki pierwsze na żywo, zapraszamy do bezpłatnego cyklu webinarów AI vs. Cybersecurity, gdzie omawialiśmy zarówno ataki sterowane przez AI, jak i ataki na same systemy AI – z dostępnymi nagraniami i materiałami do pobrania.

Źródła:

https://www.bleepingcomputer.com/news/security/jadepuffer-ransomware-used-ai-agent-to-automate-entire-attack

https://www.darkreading.com/cyberattacks-data-breaches/jadepuffer-first-complete-llm-driven-ransomware-attack

Kampania phishingowa wykorzystująca fałszywe oferty pracy pod szyldem ponad 30 rozpoznawalnych marek wykrada dane logowania do kont Google należących do specjalistów marketingu. Will Thomas, starszy doradca (senior advisor) w firmie Team Cymru, zidentyfikował co najmniej 34 domeny użyte w tej operacji, która działa nieprzerwanie od minimum pięciu miesięcy.

Na czym polega ta kampania phishingowa i kogo atakuje?

Atak podszywa się pod rekrutację. Ofiara otrzymuje wiadomość od „rekrutera” poszukującego kandydatów na stanowiska marketingowe. Wiadomość zawiera imię i nazwisko odbiorcy oraz odnosi się do jego rzeczywistej branży, co wskazuje na wcześniejsze rozpoznanie sylwetki zawodowej celu, zanim wysłano fałszywą wiadomość.

Na czym polega phishing w tym wydaniu?

W klasycznym ujęciu to próba wyłudzenia danych lub pieniędzy przez podszycie się pod zaufany podmiot. Tutaj rolę zaufanego podmiotu odgrywa jednocześnie znana marka (Adobe, Netflix, Coca-Cola, OpenAI i kilkanaście innych) oraz konkretny, imiennie wskazany rekruter.

Kampania różni się od typowych ataków phishingowych tym, że nie prowadzi ofiary od razu na złośliwą domenę. Wcześniej przepuszcza ją przez kilka legalnych platform SaaS, co utrudnia wykrycie przez standardowe filtry bezpieczeństwa.

Celem operacji są wyłącznie osoby pracujące w marketingu. Ten wybór nie jest przypadkowy. Dział marketingu regularnie nawiązuje kontakt z zewnętrznymi rekruterami, agencjami i partnerami, więc pracownicy tego obszaru mają niższą naturalną czujność wobec wiadomości rekrutacyjnych niż na przykład dział IT czy bezpieczeństwa.

Jak przebiega atak: fałszywa oferta pracy krok po kroku

Wiadomość od „rekrutera” z prawdziwym nazwiskiem i zdjęciem

Atakujący podpisują wiadomości nazwiskiem i zdjęciem prawdziwego rekrutera zatrudnionego w podszywanej firmie, co nadaje fałszywej ofercie pracy wiarygodność trudną do zweryfikowania na pierwszy rzut oka. W jednym z udokumentowanych przypadków fałszywe wiadomości podszywały się pod Paulinę Manzo, rekruterkę Adidas, która publicznie ostrzegła o wykorzystaniu jej tożsamości na LinkedIn. Sama nigdy nie wysłała takiego e-maila.

**Źródło: https://www.bleepingcomputer.com/news/security/phishing-poses-as-big-brand-job-interview-to-steal-google-accounts/**

Łańcuch przekierowań przez cztery platformy o dwóch różnych funkcjach

Zamiast prowadzić ofiarę od razu na złośliwą domenę, atak przepuszcza ją przez cztery kolejne platformy, zanim dotrze do finalnej strony phishingowej. Warto rozróżnić dwie odmienne funkcje, które te platformy pełnią w łańcuchu.

Trzy pierwsze ogniwa służą do ,,pożyczania” zaufania i reputacji domeny. E-mail wysyłany jest z PeopleForce, realnej, chmurowej platformy HR i ATS (Applicant Tracking System). Link prowadzi dalej do exct.net, domeny Salesforce Marketing Cloud działającej pod dawną marką ExactTarget. Z exct.net ruch przekierowywany jest do Wise Agent, chmurowego systemu CRM dla agentów nieruchomości, całkowicie niezwiązanego z rekrutacją. Każda z tych trzech domen ma ugruntowaną reputację i realne zastosowanie biznesowe, dlatego filtry antyspamowe oceniające pierwszy link w wiadomości nie mają powodu, by go zablokować.

Czwartym ogniwem jest sama strona phishingowa, hostowana na Netlify, darmowej platformie do publikowania statycznych stron internetowych, na przykład mckinsey-careers[.]com. Netlify nie pożycza tu reputacji marki tak jak trzy poprzednie platformy. Jego rola jest inna: to szybki, darmowy i łatwy do rotacji hosting, który pozwala atakującym stawiać i wymieniać strony docelowe bez wpływu na wcześniejsze etapy łańcucha e-mailowego. Ta różnica ma znaczenie dla obrońców, bo wymaga dwóch odmiennych typów wykrywania: analizy reputacji domen pośredniczących oraz monitoringu nowo rejestrowanych, tanich stron hostingowych łudząco podobnych do nazwy własnej marki.

Nie wiadomo, jak atakujący zdobyli dostęp do PeopleForce, Salesforce Marketing Cloud i Wise Agent. Mogli założyć konta testowe specjalnie do kampanii albo wykorzystać przejęte dane logowania istniejącego klienta. Żadna z tych ścieżek nie wymaga włamania do infrastruktury samych dostawców usług.

Fałszywe okno logowania Google: technika Browser-in-the-Browser (BitB)

Po dotarciu na finalną stronę phishingową ofiara widzi przycisk „Continue with Google” i przycisk do zaplanowania rozmowy. Kliknięcie otwiera okno łudząco przypominające natywne okno przeglądarki z formularzem logowania Google, łącznie z paskiem adresu URL, ikonami i układem typowym dla prawdziwego okna OAuth. W rzeczywistości to wyłącznie kod HTML i CSS wyrenderowany wewnątrz samej strony phishingowej, a nie odrębne okno systemowe.

Ta technika, znana jako Browser-in-the-Browser, neutralizuje najpopularniejszą radę dawaną pracownikom: sprawdzenie adresu w pasku przeglądarki przed podaniem danych logowania. Skoro pasek adresu też jest częścią fałszywej grafiki, ofiara nie ma prostego sposobu odróżnienia go od prawdziwej strony logowania Google, o ile nie zwróci uwagi na to, że całe okno nie zachowuje się jak niezależny proces systemowy, na przykład nie da się go przesunąć poza granice karty przeglądarki.

Jakie marki i sektory wykorzystano w kampanii

Kampania obejmuje co najmniej 34 domeny podszywające się pod firmy z sześciu różnych branż, co pokazuje, że atakujący nie ograniczyli się do jednego sektora, a budowali infrastrukturę pod szeroki wachlarz potencjalnych ofiar.

W liniach lotniczych i podróżach podszyto się pod American Airlines, Booking.com, Delta Air Lines i United Airlines.
W branży spożywczej wykorzystano nazwę Coca-Coli (cztery odrębne domeny, w tym cocacola-hr[.]com i cocacola-careerhub[.]com), PepsiCo i Red Bulla.
W segmencie odzieży i dóbr luksusowych ofiarami podszycia stały się Adidas, Louis Vuitton, Sephora i Levis.
W obszarze staffingu, konsultingu i technologii wykorzystano marki Adobe (jobs-adobe[.]com), Aquent, ManpowerGroup, McKinsey & Company i OpenAI (careers-openai[.]com).
W hotelarstwie i marketingu ucierpiały Marriott i Omnicom Group, a w rozrywce i sporcie FIFA (sześć odrębnych domen) oraz Netflix (jobsatnetflix[.]com).

Skala i rozpiętość sektorowa tej kampanii wskazują na zorganizowaną i dobrze zaplanowaną operację, prowadzoną w sposób ciągły, a nie jednorazowy incydent. To nie musi oznaczać dużego budżetu: rejestracja domeny i postawienie szablonowej podstrony kariery na darmowym hostingu to dziś proces tani i częściowo automatyzowany. Świadczy raczej o konsekwencji operacyjnej i długim horyzoncie działania niż o skali finansowania, którą trudno oszacować na podstawie samej liczby domen.

Dlaczego marketerzy są głównym celem tego ataku

Marketerzy padają ofiarą tej kampanii nie przez przypadek, a dlatego że ich codzienna praca wymaga otwartości na kontakt z nieznanymi wcześniej osobami: agencjami, freelancerami, influencerami, potencjalnymi partnerami biznesowymi i właśnie rekruterami. Ta zawodowa otwartość, która w innych okolicznościach jest zaletą, w kontekście phishingu staje się słabym punktem. Naturalna czujność wobec nieznanego nadawcy jest w tej grupie niższa niż na przykład w dziale IT czy bezpieczeństwa, gdzie kontakt z zewnętrznymi podmiotami podlega ściślejszym procedurom.

Konto Google należące do specjalisty marketingu bywa też bramą do zasobów wykraczających daleko poza samą skrzynkę pocztową. Wiele organizacji korzysta z Google Workspace jako centralnego mechanizmu logowania (SSO) do innych narzędzi, od Google Analytics i Google Ads przez arkusze z danymi kampanii po platformy do zarządzania treścią. Przejęcie jednego konta może więc otworzyć dostęp do budżetów reklamowych, kont social media marki i danych kampanii jednocześnie, a nie tylko do prywatnej korespondencji.

Dodatkowym czynnikiem ryzyka jest to, że marketerzy regularnie klikają linki z zewnętrznych źródeł jako część swojej pracy: śledzą kampanie konkurencji, testują landing page’e, analizują narzędzia marketingowe. To sprawia, że kliknięcie w link od „rekrutera” nie wywołuje takiej samej podejrzliwości, jaką wywołałoby w zespole przyzwyczajonym do ograniczonego, weryfikowanego zestawu kontaktów zewnętrznych.

Jakie ryzyko fałszywe rekrutacje stanowią dla organizacji

Ryzyko operacyjne: eskalacja przez konto Google i SSO

Przejęcie jednego konta Google rzadko kończy się na kradzieży prywatnej korespondencji. W wielu organizacjach to konto działa jako centralny mechanizm logowania do innych systemów, więc jego utrata otwiera drogę do znacznie szerszego incydentu bezpieczeństwa.

Atakujący z dostępem do skrzynki marketera zyskuje wgląd w historię komunikacji z agencjami, dostawcami i wewnętrznymi zespołami, materiał wystarczający do przygotowania kolejnego, jeszcze bardziej wiarygodnego ataku, na przykład w formule Business Email Compromise, gdzie przejęte konto służy do wysyłania fałszywych poleceń płatności lub zmiany danych do przelewu w imieniu prawdziwego pracownika.

Konsekwencją może być też wyciek danych, listy kontaktów czy danych dostępowych do kolejnych narzędzi zapisanych w skrzynce lub w Google Workspace.

Ryzyko reputacyjne: wykorzystanie tożsamości rekruterów i marki

Wykorzystanie nazwiska i zdjęcia prawdziwego rekrutera bez jego wiedzy uderza w wiarygodność firmy, nawet gdy sama organizacja nie ponosi winy za atak.

Paulina Manzo, rekruterka Adidas, musiała publicznie ostrzegać swoją sieć kontaktów na LinkedIn, że nigdy nie wysłała spornej wiadomości. To sytuacja, w którą żaden pracownik nie powinien być stawiany przez działania osób trzecich.

Kandydaci, partnerzy i klienci, którzy zetknęli się z fałszywą ofertą pracy, mogą trwale skojarzyć markę z oszustwem, niezależnie od tego, jak szybko firma zareagowała. Organizacje o rozpoznawalnej nazwie powinny traktować monitoring domen łudząco podobnych do własnej marki jako stały element ochrony reputacji, a nie jednorazową reakcję na zgłoszenie.

Ryzyko regulacyjne: obowiązki zgłoszenia incydentu

Duże organizacje objęte Krajowym Systemem Cyberbezpieczeństwa i unijną dyrektywą NIS2 mają obowiązek zgłaszania istotnych incydentów bezpieczeństwa w określonych terminach. Przejęcie konta Google pracownika, które doprowadziło do wycieku danych klientów, kampanii lub dostępu do kolejnych systemów, może kwalifikować się jako taki incydent, co przesuwa odpowiedzialność za reakcję z działu marketingu prosto na biurko CISO i zarządu.

Jak firmy i pracownicy mogą się chronić

Technika Browser-in-the-Browser

Najskuteczniejszą techniczną odpowiedzią na technikę Browser-in-the-Browser jest uwierzytelnianie odporne na phishing: klucze FIDO2 lub passkeys, które wiążą proces logowania z konkretnym adresem domeny. Nie da się ich przechwycić przez fałszywe okno wyrenderowane w HTML, bo po prostu odmówią zadziałania na stronie, która nie jest prawdziwym Google, niezależnie od tego, jak wiarygodnie wygląda.

To odróżnia je od hasła i klasycznego kodu jednorazowego: nie ma publicznie potwierdzonych dowodów, że ta konkretna kampania przechwytuje i wykorzystuje w czasie rzeczywistym kod SMS lub OTP do zalogowania się na prawdziwe konto, więc zwykłe uwierzytelnianie dwuczynnikowe wciąż stanowi realną barierę wobec prostego przechwycenia hasła.

FIDO2 i passkeys pozostają jednak najsilniejszym zabezpieczeniem, bo eliminują ryzyko podania danych na fałszywej stronie niezależnie od tego, jak dokładnie działa zaplecze atakującego.

Procedura weryfikacji

Drugim filarem ochrony jest procedura weryfikacji rekrutera przez firmowe kanały, zanim pracownik kliknie jakikolwiek link w wiadomości o pracę. Prosta zasada, sprawdzenie profilu rekrutera na stronie firmy lub kontakt przez oficjalny adres, a nie przez link z e-maila, neutralizuje większość wariantów tego ataku, ponieważ atakujący nie mają dostępu do prawdziwych kanałów komunikacji podszywanej organizacji.

Monitoring rejestrowanych domen

Organizacje z rozpoznawalną marką powinny wdrożyć stały monitoring rejestrowanych domen łudząco podobnych do własnej nazwy (typu „-careers”, „-hiring”, „-jobs”) i mieć gotową procedurę zgłaszania takich domen do blokowania fałszywych stron u rejestratorów i w przeglądarkach, zamiast reagować dopiero po zgłoszeniu od pracownika czy kandydata.

Monitoring pełnych łańcuchów przekierowań w linkach

Zespoły IT i bezpieczeństwa powinny dodatkowo analizować pełne łańcuchy przekierowań w linkach zawartych w wiadomościach e-mail, nie tylko pierwszy widoczny adres URL. Ta kampania pokazuje, że filtr oceniający wyłącznie pierwszy hop linku (domenę PeopleForce) przepuści wiadomość, która kilka przekierowań dalej prowadzi na stronę phishingową. Sandboxing linków i pełne śledzenie łańcucha przekierowań w bramie pocztowej wykrywa tę technikę znacznie skuteczniej niż statyczne listy reputacji domen.

Utrwalone procedury postępowania

Jeśli dane logowania zostały już podane na podejrzanej stronie, kluczowe jest tempo reakcji. Pracownik powinien natychmiast zmienić hasło do konta Google, a administrator IT wylogować wszystkie aktywne sesje, sprawdzić reguły przekazywania poczty (mail forwarding) oraz przejrzeć listę aplikacji trzecich połączonych z kontem przez OAuth. Token dostępu do takiej aplikacji może przetrwać samą zmianę hasła, więc bez tego przeglądu atakujący może zachować dostęp nawet po zresetowaniu poświadczeń.

Wysoka świadomość bezpieczeństwa – Praktyczny Trening Antyphishingowy

Najtrwalszym elementem obrony pozostaje przygotowanie ludzi, bo cała ta kampania opiera się na inżynierii społecznej, nie na złośliwym oprogramowaniu ani exploitach technicznych. Testy socjotechniczne pokazują w liczbach, ilu pracowników kliknęłoby w podobną wiadomość, ale sama diagnoza nie buduje odporności – potrzebne jest praktyczne ćwiczenie reakcji na konkretny scenariusz ataku.

Praktyczny Trening Antyphishingowy uczy zespół rozpoznawania sygnałów ostrzegawczych na aktualnych, realnych scenariuszach ataków. W odróżnieniu od jednorazowego szkolenia teoretycznego trening opiera się na cyklicznych symulacjach cyberataków dopasowanych do specyfiki danego działu, co ma szczególne znaczenie w zespołach o naturalnie niższej czujności wobec kontaktu zewnętrznego, jak marketing. Budowanie kultury cyberbezpieczeństwa w takich zespołach wymaga częstszych i bardziej ukierunkowanych ćwiczeń niż standardowe szkolenie roczne obejmujące całą firmę.

Dzięki PTA możesz

obniżyć klikalność w wiadomości phishingowe nawet poniżej 4% już po roku systematycznego treningu, a pracownicy sami zaczną aktywnie zgłaszać podejrzane wiadomości dzięki dedykowanemu rozszerzeniu do Gmaila i Outlooka,
odciążyć zespół IT, który nie musi już samodzielnie przygotowywać, prowadzić i analizować kampanii – pełną odpowiedzialność za planowanie, symulacje i raportowanie przejmuje zespół Secawa, a zaangażowanie koordynatora po stronie klienta to maksymalnie ok. 3 godziny miesięcznie,
przygotować pracowników na realny atak. Scenariusze są dopasowane do charakteru Twojej branży i organizacji oraz do wykorzystywanych systemów w codziennej pracy, a każda wpadka uruchamia natychmiastowe nanoszkolenie dokładnie w momencie, gdy uwaga i zapamiętywanie są najwyższe.
spełnić wymagania regulacyjne DORA, NIS-2, ISO 27001 i RODO w obszarze edukacji cyberbezpieczeństwa – platforma automatycznie generuje raporty gotowe do audytu lub kontroli, które stanowią dowód należytej staranności.

Organizacje, które chcą sprawdzić, jak ich zespół zareagowałby na wiadomość podobną do opisanej w tym artykule, mogą zacząć od Bezpłatnego Testu Phishingowego – bez kosztów i zobowiązań.

Poznaj naszą autorską platformę do symulacji phishignowych – spersonalizowane scenariusze (zamiast generycznych szablonów), polskie rozwiązanie (dane zostają w UE) i gotowość na audyty i kontrole (RODO, DORA, UKSC/NIS2).

Umów demo – Praktyczny Trening Antyphishingowy

WhatsApp zmienia sposób, w jaki użytkownicy identyfikują się na platformie. Od czerwca 2026 roku Meta pozwala rezerwować unikalne nazwy użytkownika, które z czasem zastąpią numer telefonu jako główny identyfikator kontaktu. Zmiana dotyczy ponad 3 miliardów użytkowników w 180 krajach i ma bezpośrednie przełożenie na jeden z najpowszechniejszych wektorów oszustw ostatnich lat – phishing prowadzony przez WhatsApp.

Co to WhatsApp?

WhatsApp to komunikator należący do Meta, wykorzystywany przez ponad 3 miliardy osób w 180 krajach do prywatnych rozmów, połączeń głosowych i wideo oraz komunikacji z firmami. Aplikacja szyfruje wiadomości end-to-end, co oznacza, że treść czatów odczytać mogą tylko nadawca i odbiorca, nie sam WhatsApp.

Dlaczego zmiana w aplikacji ma znaczenie dla bezpieczeństwa firm?

Dla organizacji WhatsApp od dawna wykracza poza sferę prywatną:

zespoły sprzedaży i obsługi klienta prowadzą przez niego rozmowy z klientami,
pracownicy korzystają z niego na urządzeniach służbowych,
a w wielu firmach funkcjonują nieformalne grupy zespołowe.

To sprawia, że każda zmiana w mechanizmie identyfikacji użytkowników WhatsApp ma znaczenie nie tylko dla osoby prywatnej, ale i dla modelu ryzyka całej organizacji.

Sama potrzeba, którą Meta adresuje wprowadzeniem nazw użytkownika, jest prosta i dobrze znana każdemu, kto korzystał z grupowych czatów. Jak opisuje to sama firma, dołączenie do czatu rodziców z drużyny sportowej dziecka albo grupy sąsiedzkiej wymagało dotąd podania numeru telefonu osobom, których się nie znało.

Numer telefonu, w odróżnieniu od nazwy użytkownika, jest trwale powiązany z tożsamością, historią kredytową, kontem bankowym i wieloma innymi usługami – stąd jego udostępnianie nieznajomym niosło ryzyko wykraczające daleko poza samą aplikację.

Czym są nazwy użytkownika (usernames) w WhatsApp i jak działają

Nazwa użytkownika w WhatsApp to unikalny identyfikator, który osoba dzieląca się nim udostępnia zamiast numeru telefonu.

Kontakt, który nie ma numeru w swojej książce adresowej, po wdrożeniu funkcji zobaczy właśnie username, nie cyfry. Mechanizm działa na Androidzie, iOS, Windows i w wersji webowej.

Źródło: https://wabetainfo.com/whatsapp-is-rolling-out-the-username-feature-on-android-and-ios/

Rezerwacja i generator username

Rezerwacji można dokonać już teraz, mimo że pełne uruchomienie funkcji nastąpi w drugiej połowie 2026 roku, stopniowo, kraj po kraju.

Ścieżka jest krótka: Ustawienia > Konto > Username, po aktualizacji do najnowszej wersji aplikacji. Nazwa musi mieć od 3 do 35 znaków, zawierać co najmniej jedną literę i może się składać z małych liter, cyfr, kropek i podkreśleń. Nie może zaczynać się od „www.” ani kończyć domeną, jak „.com” czy „.net” – to zabezpieczenie przed nazwami imitującymi adresy stron. Ponieważ z WhatsAppa korzysta ponad 3 miliardy osób, wiele oczywistych nazw jest już zajętych, dlatego Meta udostępniła też generator, który proponuje warianty dostępnego username.

Username key jako warstwa kontroli pierwszego kontaktu

Poza samą nazwą można ustawić opcjonalny username key – krótki kod, który osoba kontaktująca się po raz pierwszy musi znać razem z username. Bez klucza sama nazwa nie wystarczy do napisania wiadomości. WhatsApp nie prowadzi żadnego katalogu ani wyszukiwarki użytkowników i nie podsuwa sugestii kontaktów – trzeba znać dokładną nazwę, żeby nawiązać rozmowę.

Opcja dla twórców, firm i organizacji

Osoby prowadzące działalność, które chcą zachować spójną obecność w internecie, mogą przejąć na WhatsAppie username już zajęty przez nie na Instagramie lub Facebooku, po weryfikacji własności przez Accounts Center. Ten wybór ułatwia rozpoznawalność marki, ale ma też konsekwencje, do których wracam w części o nowych ryzykach.

Zasady nazewnictwa i ograniczenia

Username musi być dostępny równocześnie na WhatsApp, Instagramie i Facebooku – jeśli ktoś zajął go wcześniej na jednej z tych platform, nie można go użyć na WhatsAppie bez potwierdzenia własności. Część nazw jest zarezerwowana z góry dla rządów, osób publicznych i firm i nie będzie można ich zająć jako zwykły użytkownik. Nazwę można w każdej chwili zmienić lub usunąć, ale zwolniona staje się dostępna dla kogoś innego.

Dlaczego numer telefonu był dotąd słabym punktem WhatsAppa?

Numer telefonu jako identyfikator konta miał jedną fundamentalną wadę: był stały, publiczny i wielokrotnie wykorzystywany poza samym WhatsAppem – w bankowości, u operatora, w systemach weryfikacji dwuetapowej innych serwisów. Każdy wyciek danych, który obejmował numery telefonów, automatycznie dawał przestępcom gotową listę potencjalnych ofiar WhatsAppa.

Jak phisherzy wykorzystywali numer telefonu – mechanizm kodu weryfikacyjnego i przekierowania połączeń

Dużą grupą metod jest wykorzystanie samego procesu rejestracji WhatsAppa, do którego numer telefonu jest niezbędny.

Kod weryfikacyjny jako najprostsza droga do przejęcia konta

Napastnik nie musi łamać żadnego zabezpieczenia WhatsAppa – wystarczy, że zna numer telefonu ofiary. Schemat wygląda tak: numer telefonu ofiary, żądanie rejestracji konta na urządzeniu napastnika, prawdziwy sześciocyfrowy kod wysłany przez WhatsApp na numer ofiary, fałszywa strona lub wiadomość skłaniająca do ujawnienia tego kodu, przekazanie kodu, przejęcie konta.

Singapore Police Force opisała w listopadzie 2025 roku falę takich ataków, w których po przejęciu konta oszust wysyłał do kontaktów ofiary prośby o pożyczkę, podszywając się pod jej wiarygodną tożsamość (źródło). Mechanizm jest prosty właśnie dlatego, że opiera się na znajomości numeru i chwili nieuwagi właściciela konta, nie na luce technicznej w samej aplikacji.

Przekierowanie połączeń i kody USSD – ograniczenia mechanizmu

Indyjski ośrodek I4C ostrzegał w grudniu 2025 roku przed oszustami podszywającymi się pod kurierów, którzy nakłaniali ofiary do wybrania kodu USSD rozpoczynającego się od *21 i zawierającego numer kontrolowany przez przestępcę, co aktywowało przekierowanie połączeń.

Warto tu zachować precyzję: przekierowanie połączeń nie oznacza automatycznego przekazywania standardowych wiadomości SMS, a atak na WhatsAppa jest możliwy przede wszystkim wtedy, gdy napastnik wcześniej uruchomi rejestrację konta na numer ofiary i wybierze przekazanie kodu w automatycznym połączeniu głosowym – WhatsApp oficjalnie umożliwia odebranie sześciocyfrowego kodu zarówno przez SMS, jak i przez połączenie telefoniczne.

Same kody USSD i ich działanie różnią się zależnie od kraju, operatora i konfiguracji sieci, więc nie da się mówić o jednym uniwersalnym „kodzie przejmującym WhatsAppa”.

Złośliwe linki, QRLJacking i fałszywe wersje aplikacji – od WhatsApp Gold do dziś

Ten sam cel, przejęcie kontroli nad kontem lub urządzeniem, osiąga się też bez żadnego kodu weryfikacyjnego. Kody QR udostępniane w czatach mogą po zeskanowaniu połączyć urządzenie napastnika z sesją WhatsApp Web ofiary – technikę tę określa się mianem QRLJacking.

Przynęta w postaci „WhatsApp Gold”, rzekomej ulepszonej wersji aplikacji z dodatkowymi funkcjami, krąży w wiadomościach łańcuszkowych od co najmniej 2016 roku i wraca cyklicznie, prowadząc do złośliwego oprogramowania lub fałszywych stron płatnych.

Pokazuje to, że triki oparte na fałszywych aktualizacjach i linkach nie są nowością związaną z rokiem 2025 czy 2026 – zmienia się tylko opakowanie, jak we wspomnianej wcześniej kampanii z plikami VBS opisanej przez Microsoft.

Inne przykłady cyberataków z użyciem WhatsApp

Przejęcia kont administratorów grup

W grupie rodziców z drużyny sportowej administrator poprosił uczestników o przekazanie kodu, rzekomo potrzebnego do udziału w spotkaniu. W rzeczywistości był to kod zabezpieczający ich konta WhatsApp – atak, który Derbyshire Police i Castle Gresley Parish Council opisały jako falę przejęć kont w grupach na początku 2025 roku (źródło). Numer telefonu każdego z członków grupy był identyfikatorem konta, wobec którego napastnik uruchamiał proces przejęcia, a sama grupa dawała mu gotową listę kolejnych ofiar i wiarygodny pretekst.

GhostPairing – przejęcie przez sfałszowany link parowania

Badacze Gen Digital i Avast opisali atak, w którym ofiara dostawała od już przejętego konta znajomego wiadomość w stylu „znalazłem twoje zdjęcie”, prowadzącą do strony imitującej Facebooka. Strona przeprowadzała ją przez legalny proces parowania WhatsAppa z nowym urządzeniem, więc ofiara sama, nieświadomie, zatwierdzała dostęp napastnika (Gen Digital, Avast).

Fałszywe głosowanie w konkursie jako przynęta w kampanii globalnej

Whalebone Threat Intelligence odnotował ten sam schemat co GhostPairing, oparty na fałszywym głosowaniu w konkursie, w ponad 15 krajach na całym świecie – głównie w Europie Środkowej i Południowej (Czechy, Słowacja, Słowenia, Serbia, Rumunia, Bułgaria, Polska, Chorwacja), ale też w Hiszpanii, Włoszech, Brazylii czy Meksyku – z wariantami językowymi dopasowanymi do lokalnych odbiorców i rozbudowaną infrastrukturą phishingową obejmującą ponad 200 zablokowanych domen (źródło).

Podszywanie się pod bliskich z przejętego konta

Wspólny biuletyn Sussex Police i Surrey Police opisał przypadek osoby z Sussex, która dostała na WhatsAppie wiadomość z przejętego konta swojej siostry z prośbą o pieniądze i straciła niemal 500 funtów, zanim zorientowała się, że rozmawia z oszustem (źródło). Numer telefonu i wynikające z niego zaufanie do kontaktu z listy znajomych są tu kluczowe – ofiara nie weryfikowała rozmówcy, bo wiadomość przyszła z konta, które znała od lat.

Złośliwe pliki i infekcja urządzenia

Microsoft opisał kampanię trwającą od końca lutego 2026 roku, w której przez WhatsApp rozsyłano złośliwe pliki VBS, uruchamiające wieloetapowy łańcuch infekcji i instalujące backdoory MSI zapewniające zdalny dostęp do systemu (źródło).

Fałszywe „WhatsApp Security Centre”

HKCERT ostrzegał w czerwcu 2026 przed fałszywymi stronami „WhatsApp Security Centre”, które pod pretekstem odblokowania rzekomo zawieszonego konta nakłaniały do zeskanowania kodu QR lub podania kodu parowania (źródło).

Czym jest phishing przez WhatsApp

Phishing przez WhatsApp to metoda ataku, w której przestępca za pomocą wiadomości, połączenia głosowego lub linku udostępnionego w komunikatorze podszywa się pod znaną markę, instytucję albo osobę z kontaktów ofiary, aby wyłudzić dane osobowe, pieniądze lub dostęp do konta.

Od phishingu mailowego różni go kilka cech, które akurat na WhatsAppie działają na korzyść atakującego:

Szyfrowanie end-to-end chroni treść rozmów przed podsłuchem, ale jednocześnie oznacza, że WhatsApp nie może automatycznie skanować czatów w poszukiwaniu złośliwych linków czy oszukańczego tekstu – wykrycie ataku zależy w całości od odbiorcy.
Komunikator jest też przestrzenią zbudowaną na zaufaniu do bliskich kontaktów, więc wiadomość od „znajomego” czy „administratora grupy” budzi mniej podejrzeń niż analogiczny e-mail od nieznanego nadawcy.
Do tego dochodzi to, że wiadomość trafia na telefon z powiadomieniem w czasie rzeczywistym, co skłania do szybszej, mniej przemyślanej reakcji niż w przypadku poczty elektronicznej.

Phishing przez WhatsApp przybiera wiele konkretnych form – od fałszywych kodów weryfikacyjnych i stron imitujących centrum bezpieczeństwa, przez złośliwe linki i pliki, po podszywanie się pod bliskich z przejętego konta. Wspólnym mianownikiem wszystkich wariantów jest wykorzystanie zaufania i presji czasu do obejścia zdrowego rozsądku ofiary, nie łamanie zabezpieczeń technicznych samej aplikacji.

Jak nazwy użytkownika mogą ograniczyć phishing na WhatsApp

Username realnie utrudnia jeden konkretny etap ataku: pierwszy, niezamówiony kontakt oparty na znajomości samego numeru telefonu.

Nie chroni natomiast przed przejęciem konta, gdy napastnik już zna numer, ma dostęp do kodu rejestracyjnego albo działa z poziomu konta osoby, którą ofiara zna i której ufa.

Co username realnie blokuje?

Boty typu auto-dialer, które masowo skanują zakresy numerów w poszukiwaniu aktywnych kont WhatsApp, tracą swój podstawowy atut. Sam numer przestaje wystarczać do nawiązania pierwszego kontaktu – potrzebna jest dokładna nazwa użytkownika, a przy włączonym username key także dodatkowy kod.

Brak katalogu i sugestii kontaktów oznacza też, że nie da się „przeglądać” użytkowników WhatsAppa tak, jak przegląda się profile w innych serwisach społecznościowych.

Dla ofiar masowych kampanii spamowych i oszustw pierwszego kontaktu, takich jak fałszywe loterie czy oferty pracy trafiające na numer z wyciekniętej bazy, to realna, mierzalna bariera.

Co username nie blokuje

Żaden z opisanych wcześniej przypadków, który polegał na przejęciu konta, nie zniknąłby dzięki samej nazwie użytkownika.

Kod weryfikacyjny wciąż trzeba będzie przekazać, jeśli ktoś się na to nabierze, niezależnie od tego, czy nadawca zna numer, czy tylko username.
Kod parowania i skanowanie QR w GhostPairingu czy fałszywym „WhatsApp Security Centre” działają na urządzeniu ofiary, nie na jej numerze telefonu.
Wiadomość od przejętego konta znajomego, jak w przypadku opisanym przez Surrey Police, dociera do ofiary niezależnie od tego, czy widzi numer, czy nazwę – zaufanie budzi tu tożsamość rozmówcy, nie forma jego identyfikatora.

Innymi słowy, username przesuwa próg dla ataków opartych na anonimowym, masowym docieraniu do numerów, ale zostawia otwartą całą kategorię ataków opartych na przejęciu istniejącego konta, która w materiale źródłowym z lat 2025-2026 dominuje liczebnie nad klasycznym cold phishingiem na nieznany numer.

Strategia Cyfryzacji Polski do 2035 to pierwszy w historii kraju kompleksowy dokument, który porządkuje transformację cyfrową państwa wokół jednego celu – poprawy jakości życia obywateli dzięki cyfryzacji. Opracowało ją Ministerstwo Cyfryzacji, a w październiku 2024 roku trafiła do konsultacji społecznych jako projekt zastępujący Program Zintegrowanej Informatyzacji Państwa.

Dokument organizuje działania wokół czterech obszarów horyzontalnych:

cyberbezpieczeństwa,
koordynacji cyfrowej transformacji,
komunikacji elektronicznej,
kompetencji przyszłości.

Uzupełniają je obszary szczegółowe rozpisane na trzy płaszczyzny: państwo (m.in. e-usługi, tożsamość cyfrowa, chmura obliczeniowa, otwarte dane), ludzie (bezpieczna przestrzeń cyfrowa) oraz gospodarka i technologie (m.in. sztuczna inteligencja). Cyberbezpieczeństwo pełni w tej strukturze rolę fundamentu przecinającego pozostałe obszary, od niego zależy wiarygodność wszystkich e-usług.

Strategia wyznacza rosnącą ścieżkę nakładów na cyfryzację: z ok. 0,8% PKB w 2025 roku do 2% PKB w 2030 roku i docelowo 5% PKB w 2035 roku, co odpowiada rzędowi około 100 mld zł rocznie po 2030 roku.

Zespoły bezpieczeństwa odczują skutki Strategii bardzo konkretnie. Zapowiada ona:

powstanie centralnej instytucji odpowiedzialnej za cyberbezpieczeństwo na bazie Połączonego Centrum Operacyjnego Cyberbezpieczeństwa (PCOC),
rozwój krajowych i europejskich schematów certyfikacji jako narzędzia bezpieczeństwa łańcucha dostaw,
mechanizm identyfikacji i ograniczania dostawców wysokiego ryzyka (DWR),
krajowy plan migracji do kryptografii postkwantowej,
monitorowanie zgodności przedsięwzięć informatycznych z Architekturą Informacyjną Państwa.

W dalszej części wyjaśniamy, czym jest Strategia, co obejmuje, jaki ma harmonogram i jak przełożyć jej zapisy na priorytety zespołów bezpieczeństwa.

Czym jest Strategia Cyfryzacji Polski do 2035?

Strategia Cyfryzacji Polski do 2035 to ponadsektorowy dokument strategiczny w dziedzinie informatyzacji państwa, który po raz pierwszy ujmuje cyfryzację kraju całościowo – nie jako oddzielny resort, lecz jako proces przenikający niemal wszystkie obszary funkcjonowania społeczeństwa, państwa i gospodarki. Nadrzędnym celem dokumentu jest poprawa jakości życia obywateli poprzez cyfryzację do 2035 roku.

Strategię przygotowało Ministerstwo Cyfryzacji we współpracy z innymi urzędami administracji rządowej oraz z udziałem interesariuszy społecznych i biznesowych. Zastępuje ona Program Zintegrowanej Informatyzacji Państwa i ma stanowić podstawę strategiczną dla wydatkowania europejskich funduszy przeznaczonych na cyfryzację, wyznaczając kierunek negocjacji na nadchodzącą perspektywę finansową.

Cele dokumentu są rozwijane w powiązanych dokumentach sektorowych, między innymi w:

Strategii Cyberbezpieczeństwa RP na lata 2025-2029 (przyjętej w marcu 2026 roku, zastępującej strategię na lata 2019-2024),
Narodowym Planie Szerokopasmowym,
Programie Rozwoju Kompetencji Cyfrowych,
Programie Otwierania Danych,
Polityce Rozwoju Sztucznej Inteligencji w Polsce do 2030 roku.

Wniosek dla kadry zarządzającej bezpieczeństwem nasuwa się sam: ogólne zapisy Strategii będą uszczegóławiane w regulacjach sektorowych, które wprost wpłyną na codzienną pracę zespołów IT i bezpieczeństwa. Śledzenie tych dokumentów to nie formalność, lecz źródło konkretnych obowiązków.

Dlaczego powstała Strategia?

Strategia Cyfryzacji Państwa powstała, by uporządkować rozwój cyfrowych usług, które dotąd budowano w oderwaniu od siebie, bez wspólnego kierunku. Jak ujął to wiceminister cyfryzacji Dariusz Standerski, dokument „kończy z tą epoką fragmentarycznego rozwoju cyfrowych usług” i po raz pierwszy „definiuje nasz cyfrowy plan na najbliższą dekadę”.

Obieramy w niej konkretne cele – za dziesięć lat to Polska będzie liderem cyfrowego rozwoju Europy. Do 2030 roku 100% kluczowych usług publicznych będzie dostępna cyfrowo, 85% Polaków będzie posiadać podstawowe kompetencje cyfrowe do 2035 roku, a na cyfryzację przeznaczymy 5% PKB.

Dariusz Standerski, Wiceminister Cyfryzacji

Dokument odpowiada na konkretną ambicję: Polska ma stać się liderem cyfryzacji w Unii Europejskiej, a nie pozostawać odbiorcą cudzych technologii. Temu służą mierzalne cele z terminami i wskaźnikami, między innymi:

pełna cyfrowa dostępność kluczowych usług publicznych,
powszechny zasięg światłowodu oraz 5G do 2030 roku,
wzrost kompetencji cyfrowych obywateli, upowszechnienie AI w urzędach i nakłady na cyfryzację rzędu 5% PKB do 2035 roku.

Strategia jasno definiuje też, czego cyfryzacja robić nie powinna: uzależniać, dezinformować ani wykluczać. Ochrona praw cyfrowych obywateli, ochrona dzieci i młodzieży przed szkodliwymi mechanizmami platform oraz budowanie suwerenności technologicznej są w niej traktowane na równi z rozwojem e-usług. Całość wpisuje się w unijną agendę „Droga ku Cyfrowej Dekadzie” do 2030 roku.

Co obejmuje Strategia Cyfryzacji Polski?

Strategia porządkuje cyfryzację kraju w dwóch wymiarach: czterech obszarach horyzontalnych, które stanowią fundament transformacji, oraz trzech płaszczyznach mieszczących obszary szczegółowe.

Cztery obszary horyzontalne

To punkt wyjścia całej Strategii – obszary, których stan warunkuje powodzenie reszty:

Komunikacja elektroniczna, czyli powszechny dostęp do ultraszybkiego internetu, sieci 5G i 6G oraz suwerenna łączność satelitarna.
Kompetencje przyszłości, czyli umiejętności cyfrowe obywateli, liczba specjalistów ICT i higiena cyfrowa.
Cyberbezpieczeństwo, czyli odporność państwa, instytucji i obywateli na rosnące cyberzagrożenia.
Koordynacja transformacji cyfrowej, czyli Architektura Informacyjna Państwa, Komitet do spraw Cyfryzacji i koniec silosowości w administracji.

Trzy płaszczyzny: Państwo, Ludzie, Gospodarka i technologie

Pozostałe cele Strategii pogrupowano w 17 obszarach w ramach trzech płaszczyzn:

Państwo (6 obszarów): e-usługi publiczne, cyfryzacja procesów administracyjnych i postępowań sądowych, systemy i rejestry, cyfrowa tożsamość, chmura obliczeniowa, otwarte dane i wymiana danych.
Ludzie (4 obszary): bezpieczna przestrzeń cyfrowa, cyfrowe zdrowie, branże kreatywne, cyfrowa akademia.
Biznes i technologie (7 obszarów): cyfrowa transformacja przedsiębiorstw, sztuczna inteligencja, inne technologie przełomowe, technologie kosmiczne, finansowanie i wsparcie innowacji, open source, cyfrowa i zielona transformacja.

Na jakich zasadach opiera się Strategia?

Strategia deklaruje zasady, według których ma przebiegać cyfryzacja – i to one wyznaczają granice wdrożeń:

Technorealizm – uznanie, że rozwój technologii nie jest odpowiedzią na wszystkie problemy.
Prymat bezpieczeństwa – wprowadzanie nowych rozwiązań cyfrowych nigdy nie może odbywać się kosztem bezpieczeństwa, rozumianego jako cyberbezpieczeństwo, prawa podstawowe i dobrostan obywateli.
Sprawiedliwa transformacja cyfrowa – włączenie społeczne, dostępność dla osób z niepełnosprawnościami, prawa pracownicze i powiązanie z transformacją energetyczną.
Neutralność technologiczna – unikanie długofalowego uzależnienia od jednego dostawcy.

Cele Strategii Cyfryzacji Polski

Strategia przekłada wizję na mierzalne cele, których wartości docelowe wyznaczono w większości na 2035 rok. Najważniejsze z nich:

85% obywateli z co najmniej podstawowymi, a 50% z ponadpodstawowymi kompetencjami cyfrowymi.
Minimum 1,5 mln specjalistów ICT (cel: 10% udziału wśród pracujących, w tym 35% kobiet).
20 mln aktywowanych portfeli tożsamości cyfrowej.
80% urzędów i 50% firm korzystających ze sztucznej inteligencji.
100% projektów IT o publicznym zastosowaniu zgodnych z Architekturą Informacyjną Państwa.
100% spraw w podmiotach publicznych załatwianych elektronicznie i 100% jednostek udostępniających e-płatności.
Wszystkie istotne incydenty cyberbezpieczeństwa zgłaszane terminowo do zespołów CSIRT.
Powszechny dostęp do mobilnych usług telekomunikacyjnych o przepustowości co najmniej 100 Mb/s na terenie całego kraju.
Co najmniej dziesięciokrotnie większa moc obliczeniowa dla nauki w infrastrukturze PLGrid (docelowo HPC rzędu 1 eksaflopsa i AI rzędu 40 eksaflopsów).
100 jednostek chorobowych analizowanych z wykorzystaniem AI, a wszystkie placówki ochrony zdrowia wymieniają dokumentację medyczną elektronicznie.

Harmonogram Strategii Cyfryzacji Polski

Strategia rozkłada cele w czasie, od najpilniejszych zmian instytucjonalnych w latach 2025-2026 po docelowy rok 2035. Kluczowe kamienie milowe wynikające z tabeli wskaźników:

2025/2026 – powołanie centralnej instytucji odpowiedzialnej za cyberbezpieczeństwo; uruchomienie systemu oceny etycznej narzędzi AI stosowanych przez państwo (2025).
2026 – pełnomocnicy ds. informatyzacji we wszystkich urzędach ministrów i w KPRM; wdrożenie mechanizmu identyfikacji i ograniczania dostawców wysokiego ryzyka; wskazanie organu koordynującego przeciwdziałanie dezinformacji; mechanizm koordynacji wdrożeń AI w administracji; koordynatorzy szerokopasmowi w gminach i powiatach.
2027 – umocowanie prawne referencyjnych rejestrów publicznych.
2029 – chmura niejawna osiąga pełną zdolność operacyjną.
2031 – 100% gospodarstw domowych wyposażonych w inteligentne liczniki.
2035 – termin docelowy większości celów: kompetencje cyfrowe, portfele tożsamości, AI w administracji, zgodność projektów IT z AIP, terminowe zgłaszanie incydentów.

Strategia ma charakter wieloletni, dlatego przewiduje stały cykl zarządzania, czyli przegląd dokumentu co 2 lata oraz monitoring raz w roku, ze sprawozdaniem dla Komitetu do spraw Cyfryzacji i publikacją na stronie Ministerstwa Cyfryzacji.

Podsumowanie

Strategia Cyfryzacji Państwa do 2035 roku po raz pierwszy spina rozwój cyfrowy Polski w jeden, mierzalny plan, w którym cyberbezpieczeństwo jest jednym z czterech fundamentów warunkujących powodzenie reszty.

Dla zespołów bezpieczeństwa nie jest to zapowiedź konkretnych zmian: centralnej instytucji cyberbezpieczeństwa na bazie PCOC, obowiązkowych CSIRT-ów sektorowych, mechanizmu identyfikacji i ograniczania dostawców wysokiego ryzyka, krajowego planu migracji do kryptografii postkwantowej oraz powiązania przedsięwzięć IT z Architekturą Informacyjną Państwa.

Te kierunki zyskują moc wiążącą poprzez powiązane regulacje, przede wszystkim nowelizację ustawy o KSC wdrażającą dyrektywę NIS2 i ustawę o krajowym systemie certyfikacji cyberbezpieczeństwa. Im wcześniej organizacja przełoży zapisy Strategii na własną mapę obowiązków, tym mniejsze ryzyko, że dostosowanie do nowych wymogów stanie się działaniem awaryjnym zamiast zaplanowanym.

Pod koniec maja na kanałach Telegramu pojawiła się instrukcja, która pozwalała przejąć cudze konto na Instagramie bez znajomości hasła i bez dostępu do skrzynki ofiary. Wystarczył do tego czat z Meta AI.

Meta potwierdziła, że tą metodą przejęto 20 225 kont, a wśród ofiar znalazły się uśpiona strona Obama White House, profil sieci kosmetycznej Sephora oraz konto wysokiego rangą oficera US Space Force.

Jak czat z Meta AI pozwolił przejąć konta na Instagramie?

Hakerzy przejmowali konta, polecając chatbotowi Meta AI powiązanie profilu ofiary z własnym adresem e-mail, na który system wysyłał link resetujący hasło. Nie łamali haseł ani nie włamywali się do cudzych skrzynek, cały atak sprowadzał się do rozmowy z chatbotem.

Według zgłoszenia Meta podatność wykryto 31 maja 2026 roku, a rejestr prokuratora generalnego stanu Maine wskazuje 17 kwietnia jako prawdopodobną datę pierwszego ataku. Oznaczałoby to, że luka pozostawała otwarta przez około sześć tygodni, choć Meta nie podała oficjalnie, kiedy ataki się rozpoczęły.

Na czym polegała luka w chatbocie Meta AI?

Słabym ogniwem okazał się High Touch Support (HTS), uruchomiony w marcu 2026 roku system odzyskiwania kont wspomagany sztuczną inteligencją. Meta zbudowała go, by odciążyć powolną obsługę użytkowników odciętych od Instagrama.

Jak firma przyznała w zgłoszeniu naruszenia złożonym u prokuratora generalnego stanu Maine, samo narzędzie działało zgodnie z założeniem, ale błąd w odrębnej ścieżce kodu sprawiał, że system nie weryfikował, czy wskazany adres e-mail w ogóle należy do danego konta. Zamiast odrzucić takie żądanie, wysyłał link resetujący na obcy adres. Mechanizmem, który zawiódł, była brakująca kontrola autoryzacji w zapleczu procesu odzyskiwania.

Jak wyglądał atak na czat z Meta AI krok po kroku?

Sam scenariusz był banalnie prosty. Napastnik łączył się przez VPN z adresu IP w okolicy typowej lokalizacji ofiary, prawdopodobnie po to, aby żądanie resetu wyglądało wiarygodnie i nie wzbudziło podejrzeń systemu.

Następnie prosił o reset hasła i przechodził do czatu z Meta AI. Tam wydawał chatbotowi polecenie powiązania konta z nowym adresem e-mail, na który trafiał jednorazowy kod.

Pozwalało to ustawić nowe hasło i zalogować się na cudze konto. Warunek był jeden: konto ofiary nie mogło mieć włączonego uwierzytelniania dwuskładnikowego (2FA).

Czego ten atak uczy o bezpieczeństwie agentów AI?

Chatbot potrafił wykonać poważne operacje, jak reset hasła czy zmiana e-maila, ale nie miał jak zweryfikować, że prosi o nie prawdziwy właściciel konta. Ten sam błąd, czyli potężne uprawnienia bez kontroli tożsamości, powtarza się w całej klasie ataków wymierzonych w agentów AI.

Dlaczego chatbot to nowa powierzchnia cyberataków?

Problemem nie jest sama sztuczna inteligencja, tylko zakres uprawnień, jakie jej powierzono.

To fundamentalna wada architektury. Model otrzymał uprawnienia do wrażliwych operacji bez odpowiedniej kontroli dostępu.

Brian Westnedge, Red Sift, wypowiedź dla Reutersa (tłum. red.)

Atak przypomina socjotechnikę stosowaną wobec ludzkich konsultantów: zamiast łamać zabezpieczenia, napastnik po prostu poprosił o wykonanie operacji, a system ją zrealizował.

Część ekspertów cytowanych przez Reutersa klasyfikowała incydent jako prompt injection, czyli manipulację konwersacyjną modelem. Warto jednak odnotować, że techniczne wyjaśnienie samej Mety wskazuje nie na podatność modelu językowego, lecz na brakującą weryfikację w kodzie obsługującym reset hasła. Niezależnie od klasyfikacji wniosek pozostaje ten sam: bot dostał prawo do wrażliwych operacji bez mechanizmu sprawdzającego, kto i na jakiej podstawie o nie prosi.

Skala potencjału szkód rośnie wraz z tym, jak kolejne platformy oddają chatbotom obsługę logowania, resetu haseł czy odzyskiwania kont. Ian Goldin z Black Lotus Labs ostrzega, że wchodzimy na nieznany grunt i podobnych ataków będzie przybywać. Engin Kirda z Northeastern University ujął to dosadnie: kiedyś celem oszustw byli ludzie, teraz stają się nimi agenci AI.

Prompt injection a bezpieczeństwo systemów AI. Jak modelować zagrożenia?

Przeczytaj artykuł

Jak chronić konto na Instagramie przed przejęciem przez hakerów?

Najskuteczniejszą barierą okazało się uwierzytelnianie dwuskładnikowe. Według samych hakerów exploit nie zadziałał wobec żadnego konta z włączonym MFA, a blokował go nawet najsłabszy wariant, czyli kod SMS.

Warto jednak korzystać z mocniejszych metod, czyli klucza sprzętowego lub passkey. Kod SMS, choć w tym przypadku wystarczył, pozostaje podatny na przejęcie numeru ofiary (SIM swapping), dlatego nie powinien być jedyną linią obrony.

Skoro atak polegał na podpięciu obcego adresu e-mail do konta, warto też sprawdzić w Centrum kont, czy do profilu nie przypisano nieznanego adresu lub numeru telefonu, i usunąć takie wpisy.

Po wykryciu luki Meta wyłączyła system HTS i unieważniła wygenerowane linki, wymusiła reset haseł na zagrożonych kontach oraz objęła je obowiązkowym punktem kontroli bezpieczeństwa, a także zapowiedziała przegląd podobnych procesów odzyskiwania na swoich platformach.

Jak chronić organizację przed atakami na AI?

Przypadek Instagrama to podręcznikowy przykład zagrożenia, które rozłożyliśmy na czynniki pierwsze w bezpłatnym cyklu „AI vs Cybersecurity”. Cztery odcinki pokazują nie tylko, jak cyberprzestępcy wykorzystują GenAI do ataków, ale i jak wykorzystać AI w codziennej pracy CISO, aby skutecznie chronić organizację.

Najbliżej opisanego ataku jest odcinek numer trzy: Ataki na AI. Tłumaczymy w nim, jak modelować i minimalizować ryzyko ataków wymierzonych w systemy AI, w tym manipulację modelem i prompt injection. To pokrewna klasa zagrożeń, którą przypadek Meta AI dobitnie obnażył: agent z prawem do wrażliwych operacji staje się celem, gdy zabraknie kontroli, kto i na jakiej podstawie o nie prosi. Do tego udostępniamy skrócony poradnik krok po kroku, jak takie ryzyko ograniczać w praktyce.

Pozostałe odcinki rozszerzają ten obraz:

W odcinku pierwszym – AI Atakuje – pokazujemy, jak przestępcy używają AI do ataków socjotechnicnzych i automatyzacji działań; w pakiecie czeka checklista 15 pytań dla CISO oraz poradnik rozpoznawania phishingu.
Shadow AI (odc.2) dotyczy niekontrolowanego korzystania z narzędzi AI przez pracowników i daje walidator AI Act, przewodnik bezpiecznego korzystania z AI w pracy oraz checklistę zarządzania Shadow AI w organizacji.
AI jako wsparcie CISO, odcinek ostatni z cyklu webinarów, odwraca perspektywę i pokazuje, jak wykorzystać sztuczną inteligencję po stronie obrony.

Dostęp do nagrań i wszystkich materiałów jest bezpłatny. Wystarczy wypełnić formularz na stronie cyklu AI vs Cybersecurity.

Uzyskaj dostęp do nagrań i materiałów z bezpłatnego cyklu webinarów AI vs Cybersecurity

Wypełnij formularz

Źródła:

https://krebsonsecurity.com/2026/06/hackers-used-metas-ai-support-bot-to-seize-instagram-accounts

https://www.bleepingcomputer.com/news/security/meta-ai-support-data-breach-affects-20-000-instagram-accounts

https://insideretail.asia/2026/06/04/how-the-sephora-instagram-hack-exposed-metas-ai-weakness/

https://www.404media.co/hackers-simply-asked-meta-ai-to-give-them-access-to-high-profile-instagram-accounts-it-worked

https://www.reuters.com/legal/government/high-profile-meta-ai-chatbot-breach-spotlights-security-risks-automation-2026-06-03