Credential stuffing: co dzieje się z hasłami po wycieku

Czym jest credential stuffing

Credential stuffing to zautomatyzowane wstrzykiwanie skradzionych par login i hasło w formularze logowania, żeby uzyskać nieuprawniony dostęp do kont. Tak opisuje go OWASP i w tej definicji mieści się cała mechanika ataku: nikt tu niczego nie zgaduje. Atakujący sprawdza poświadczenia, które gdzieś już zadziałały, licząc na to, że zadziałają jeszcze raz w innym miejscu.

Odróżnienie go od dwóch pokrewnych technik ma znaczenie praktyczne, nie akademickie. Każda z nich zostawia inny ślad w logach i każdą zatrzymuje co innego, a w polskich materiałach te trzy nazwy bywają używane wymiennie. Skutek jest taki, że obrona zostaje ustawiona pod scenariusz, który akurat nie występuje.

Z tej tabeli wynika jeden wniosek, który zmienia priorytety. Blokada konta po pięciu nieudanych próbach, czyli klasyczna odpowiedź na brute force, prawie nie przeszkadza credential stuffingowi. Atak z gotowej listy wykonuje jedną próbę na konto i przechodzi dalej, więc żaden licznik przy pojedynczym koncie się nie zapełnia. Widać go dopiero wtedy, gdy patrzy się na wszystkie próby razem, a nie na każde konto osobno.

Paliwo ataku: combolisty i pliki ULP

Credential stuffing zaczyna się od pliku tekstowego, nie od exploita. To część opisu, która bywa pomijana, a bez niej nie da się ocenić, czy alert o wycieku dotyczy naszej organizacji i jak pilny jest. Materiał krąży w dwóch formatach, które różnią się jedną informacją, i ta różnica decyduje o tym, ile prób musi wykonać atakujący.

Combolista to plik z parami adres e-mail i hasło, pozbawiony kontekstu. Group-IB opisuje ją jako najprostszą postać handlowego materiału: nie wiadomo, z jakiego serwisu pochodzi para ani kiedy powstała. Powstaje z logu infostealera, z którego przestępca wyciąga same poświadczenia i przepakowuje je w format łatwiejszy do odsprzedaży i do wczytania przez narzędzie.

# combolista: para bez kontekstu
adres@example.com:Wiosna2024!
adres@example.com:Zaq12wsx

# plik ULP: adres serwisu + login + haslo
poczta.example.com\adres@example.com:Wiosna2024!
intranet.example.com\jkowalski:Zaq12wsx

Plik ULP dokłada adres serwisu i przez to jest cenniejszy. Nazwa to skrót od URL, login i hasło: każdy wiersz mówi nie tylko, jakie poświadczenie skradziono, ale też gdzie ono działało. Atakujący nie musi więc testować jednej pary na kilkudziesięciu serwisach, tylko od razu kieruje ją tam, gdzie ma największą szansę. Skraca to liczbę prób, a przy okazji redukuje ślad, po którym można atak zauważyć: mniej prób oznacza mniej nieudanych logowań w logach.

Dystrybucja odbywa się na forach, w publicznych i płatnych kanałach Telegram oraz w serwisach do wymiany plików. To korekta obrazu powtarzanego w polskich materiałach, w których wszystko sprowadza się do skanowania sieci Tor: giełda logów i kanał w komunikatorze przejęły znaczną część obrotu, a jeden plik trafia naraz do wielu odbiorców. Skalę źródła pokazuje operacja Europolu i Microsoftu, w której między 16 marca a 16 maja 2025 zidentyfikowano ponad 394 000 komputerów z Windows zainfekowanych infostealerem Lumma. Jak powstaje pojedynczy log na stacji użytkownika i skąd biorą się dane w combolistach, opisaliśmy osobno.

Większość materiału w obiegu jest stara

Nowa nazwa pliku nie oznacza nowych danych. Group-IB opisuje udokumentowany przypadek, w którym urządzenie zainfekowano 8 lipca 2024 roku, a te same poświadczenia krążyły w plikach dystrybuowanych w marcu 2025, czyli dziewięć miesięcy później. To nie jest wyjątek, tylko reguła tego rynku: rekordy wracają latami, przepakowane, połączone z innymi zbiorami i ogłoszone jako świeży wyciek.

Dla zespołu, który dostaje alert, wiek materiału jest pierwszym pytaniem, a nie ciekawostką. Jeśli hasło zmieniono już po dacie infekcji urządzenia, rekord jest historyczny i uzasadnia weryfikację, nie alarm. Jeśli od tamtej pory nikt go nie zmienił, ten sam wiersz jest aktualnym kluczem do konta, niezależnie od tego, że plik ma dwa lata. Rozstrzyga data infekcji urządzenia i data ostatniej zmiany hasła, a nie data publikacji zbioru.

Zmienia to sposób, w jaki czyta się wyniki monitorowania wycieków danych logowania. Wartością nie jest liczba trafień, bo ta rośnie z każdym przepakowanym zbiorem i szybko przestaje cokolwiek znaczyć. Wartością jest możliwość zestawienia trafienia z kontem w katalogu, z datą infekcji i z logami logowania. Alert bez tego kontekstu prowadzi albo do paniki, albo do znieczulenia, a oba stany kończą się tak samo: nikt nic nie robi.

Dlaczego to w ogóle działa

Skuteczność ataku opiera się na jednym zjawisku: to samo hasło działa w wielu serwisach. Użytkownik zakłada konto w sklepie, w portalu branżowym i w narzędziu do wideokonferencji, a hasło ustawia jedno, czasem z drobną modyfikacją na końcu. Atakujący nie musi znać odsetka takich osób. Wystarczy, że jest on niezerowy, bo koszt jednej próby jest bliski zeru, a lista ma miliony wierszy.

W organizacji to zjawisko wzmacnia jeszcze służbowy adres używany jako login prywatny i logowanie jednokrotne. Flare, po analizie 18,7 mln logów infostealerów z 2025 roku, podaje, że odsetek infekcji zawierających firmowe dane logowania do SSO albo do dostawcy tożsamości wzrósł z około 6% na początku 2024 roku do około 14% pod koniec 2025, a dane wstępne wskazują 16%. Microsoft Entra ID występuje w 79% logów, w których w ogóle pojawiła się firmowa tożsamość.

Przejęcie konta w takiej architekturze rzadko kończy się na jednej aplikacji, bo jeden zestaw poświadczeń otwiera pocztę, dysk i część systemów wewnętrznych. Verizon podaje, że dane logowania stanowiły 28% danych skompromitowanych w analizowanych naruszeniach, a 73% ofiar ransomware miało w poprzedzającym roku infekcję infostealerem albo zdarzenie wycieku danych logowania, przy czym połowa z nich w ciągu 95 dni przed atakiem. Wyciek haseł pracowników bywa więc nie końcem historii, tylko jej pierwszym rozdziałem.

Jak credential stuffing wygląda w logach uwierzytelniania

Tego ataku nie widać w pojedynczym zdarzeniu, tylko we wzorcu. Każda z poniższych obserwacji z osobna ma sensowne, niegroźne wytłumaczenie. Dopiero zestawione razem w oknie kilku godzin układają się w obraz automatu pracującego na gotowej liście, i właśnie tak trzeba je czytać.

• Rozkład prób w czasie: równe odstępy, aktywność bez przerw i tempo, którego człowiek nie utrzyma, albo przeciwnie, próby celowo rozrzedzone tak, żeby nie wyzwolić blokady
• Rotacja adresów źródłowych: jedna próba z adresu, potem kolejny, często z puli serwerów pośredniczących albo z łączy domowych w wielu krajach naraz
• Nagłówek klienta: ten sam user-agent przy tysiącach różnych kont, ciąg nietypowy dla przeglądarki albo całkowity brak takiego nagłówka
• Wysoki odsetek nieudanych logowań przerwany nagłym pojedynczym sukcesem: to ten sukces jest zdarzeniem, nie seria porażek przed nim
• Logowania spoza typowych godzin pracy i z lokalizacji, w których organizacja nie prowadzi działalności
• Ten sam login pojawiający się w krótkim czasie w kilku aplikacjach, do których użytkownik zwykle nie sięga
• Próby na kontach, które nie istnieją albo dawno zostały wyłączone: to ślad listy, a nie ślad użytkownika

Żadnego z tych sygnałów nie da się zobaczyć, jeśli logi uwierzytelniania nie trafiają w jedno miejsce i nie są przechowywane dłużej niż typowe okno wykrycia. Korelacja prób pomiędzy kontami wymaga jednego zbioru, a nie siedmiu konsol, w których każda pokazuje własny fragment. Który element warstwy detekcji za co odpowiada i jak długo musi sięgać retencja, rozłożyliśmy w porównaniu SIEM, SOAR, XDR i EDR.

Największa trudność polega na tym, że udane logowanie prawidłowym hasłem jest zdarzeniem poprawnym. System tożsamości nie ma powodu go zgłaszać, bo użytkownik podał dokładnie to, co miał podać. Dlatego reguła oparta wyłącznie na progu nieudanych prób wyłapie brute force i przepuści credential stuffing. Wykrycie zaczyna się tam, gdzie do logowania dokłada się kontekst: urządzenie, lokalizacja, pora oraz to, czy dane tego konta już krążą.

Gdzie kończy się skuteczność MFA

Uwierzytelnianie wieloskładnikowe zatrzymuje klasyczny credential stuffing i to jest uczciwa część rekomendacji, którą powtarza cała branża. Para z combolisty nie wystarczy, gdy przy logowaniu trzeba potwierdzić tożsamość drugim składnikiem. Problem zaczyna się tam, gdzie atakujący w ogóle nie loguje się przez formularz.

Skradzione ciasteczko sesji to poświadczenie, które nie potrzebuje logowania, bo dowodzi, że logowanie już się odbyło. Infostealer zabiera z przeglądarki nie tylko zapisane hasła, ale również aktywne sesje, a Flare podaje, że 1,17 mln logów z 2025 roku zawierało jednocześnie firmowe dane tożsamości i ciasteczka sesji. Jak wygląda to w praktyce jednej kampanii, pokazaliśmy przy obejściu MFA w kampanii VENOM.

Wniosek nie brzmi „MFA nie działa", tylko „MFA rozwiązuje jedną klasę problemu". Rekomendacja, która kończy się na włączeniu drugiego składnika, zostawia otwarte trzy sprawy: unieważnianie sesji, odporność samego składnika na przekazanie oraz to, czy ktoś w ogóle zauważy udane logowanie z przejętej sesji. Passkeys i klucze sprzętowe podnoszą poprzeczkę przy logowaniu, ale nie unieważniają tokenu, który wyciekł wcześniej.

Obrona w czterech warstwach

Sensowna obrona przed credential stuffingiem rozkłada się na warstwy, bo żadna pojedyncza kontrola nie pokrywa całej ścieżki ataku. Poniższe zestawienie porządkuje, która warstwa odbiera atakującemu co i w którym momencie łańcucha to działa.

Warstwa tożsamości jako jedyna odbiera atakowi paliwo, bo unieważnia parę login i hasło jako wystarczający dowód. Jedno zastrzeżenie z pierwszej sekcji obowiązuje i tutaj: blokada konta po serii nieudanych prób pomaga przy brute force, a przy jednej próbie na konto niewiele zmienia. Więcej dają polityki dostępu warunkowego i ocena ryzyka logowania, bo patrzą na kontekst zamiast na licznik.

Warstwa aplikacji i brzegu pracuje na kształcie ruchu, a nie na treści poświadczenia. Realizują ją kategorie rozwiązań takie jak zapora aplikacji webowych z modułem wykrywania automatów, brama dostępowa i ochrona brzegu sieci, a spośród rozwiązań, które dostarczamy, tę rolę pełni Imperva, a obok niej pracują zapora aplikacji webowej z wykrywaniem automatów oraz kontrola na brzegu sieci. Kryterium doboru jest proste: czy narzędzie potrafi odróżnić automat od użytkownika bez blokowania połowy ruchu przy okazji.

Warstwa wywiadu odpowiada na pytanie, którego dwie poprzednie nie zadają: czy nasze poświadczenia już krążą. Platformy pełniące tę rolę, takie jak Flare czy Group-IB, wykorzystywane w monitorowaniu wycieków danych, zbierają materiał z giełd logów i kanałów dystrybucji, ale samo trafienie jest dopiero półproduktem. Wartość powstaje po zestawieniu go z kontem w katalogu, z datą infekcji urządzenia i z datą ostatniej zmiany hasła, bo dopiero wtedy wiadomo, czy trzeba działać teraz, czy zapisać obserwację.

Warstwa detekcji i reakcji nie zapobiega niczemu. Decyduje o tym, ile trwa reszta. Bez centralnego zbioru logów uwierzytelniania każda z trzech poprzednich warstw widzi wyłącznie swój fragment: warstwa tożsamości zna nieudane próby na jednym koncie, brzeg zna ruch, wywiad zna trafienie w obiegu, i nikt nie zestawia tego ze sobą. Dopiero korelacja prób pomiędzy kontami pokazuje, że to jedna kampania, a nie kilkanaście niezależnych zdarzeń. Ta warstwa zamienia sygnał w decyzję w godzinach zamiast w tygodniach po fakcie.

Co zrobić po udanym przejęciu konta

Poniższa sekwencja zakłada jedno przejęte konto użytkownika w środowisku z pocztą w chmurze i centralnym katalogiem tożsamości. Czasy są orientacyjne, kolejność nie: pierwsze dwa kroki wykonane odwrotnie zostawiają atakującemu okno na powrót.

1. Minuty 0–15Dyżurny analityk
   Odetnij sesję, nie samo hasło

   Reset hasła to połowa kroku. Razem z nim trzeba unieważnić wszystkie aktywne sesje i tokeny odświeżania, inaczej atakujący pracuje dalej na uwierzytelnionej sesji, której zmiana hasła nie dotyczy. Konto warto na ten czas zablokować, a nie tylko wylogować.

2. Minuty 15–60Administrator tożsamości
   Sprawdź, co konto zdążyło zmienić

   Nowe metody uwierzytelniania, reguły przekierowania poczty, zgody nadane aplikacjom zewnętrznym, dodane urządzenia, zmiany uprawnień i członkostwa w grupach. To są mechanizmy powrotu i wszystkie przeżywają reset hasła. Każdą zmianę z okresu po pierwszym podejrzanym logowaniu trzeba cofnąć świadomie, a nie hurtem.

3. Godziny 1–4Zespół bezpieczeństwa
   Ustal zasięg

   Z jakich adresów logowano się na konto, do jakich aplikacji sięgnięto, jakie dane były w zasięgu i co zostało pobrane. Osobne pytanie brzmi, czy to jedno konto, czy fragment listy: jeśli ten sam wzorzec prób widać na innych loginach, incydent dotyczy zbioru poświadczeń, nie użytkownika.

4. Godziny 4–24Zespół bezpieczeństwa i IT
   Zamknij źródło poświadczenia

   Jeśli źródłem był log infostealera, konto jest objawem, a przyczyną pozostaje zainfekowana stacja. Urządzenie idzie do izolacji i odtworzenia, a wszystkie hasła zapisane w przeglądarce tego użytkownika trzeba uznać za spalone, łącznie z prywatnymi, jeśli tam były.

5. Doba 1–3Właściciel ryzyka i IOD
   Oceń obowiązki i domknij lukę

   Przejęcie konta z dostępem do danych osobowych uruchamia analizę naruszenia, a w części przypadków także terminy zgłoszeniowe. Równolegle zapisuje się wnioski techniczne: który wyjątek od polityki umożliwił wejście, czy retencja logów wystarczyła do ustalenia zasięgu i której reguły detekcji zabrakło.

Ten harmonogram ma sens tylko wtedy, gdy ktoś jest na dyżurze. Credential stuffing rzadko trafia w poniedziałkowy poranek, bo automat pracuje wtedy, kiedy skończy się kolejka, a nie wtedy, kiedy zaczyna się zmiana. Jeśli w organizacji nie ma obsady poza godzinami pracy, warto rozważyć całodobowe monitorowanie i reakcję albo z góry przyjąć, że pierwsze cztery godziny z powyższej tabeli wydarzą się następnego dnia.

Najczęstsze pytania

Podsumowanie

Credential stuffing jest atakiem tanim, powtarzalnym i całkowicie zależnym od materiału, który powstał wcześniej i gdzie indziej. To dobra wiadomość, bo daje trzy niezależne punkty przecięcia łańcucha: wartość poświadczenia można odebrać po stronie tożsamości, automat można zatrzymać na brzegu, a o wycieku można dowiedzieć się, zanim ktoś zacznie testować listę. Najsłabsza wersja obrony kończy się na włączeniu drugiego składnika, bo pomija sesje, wyjątki i logi, w których ten atak w ogóle da się zobaczyć.

Atakujący nie musi znać Waszych haseł. Wystarczy, że zna te, które ktoś już kiedyś zapisał w przeglądarce.