Monitorowanie wycieków danych: jak dowiedzieć się pierwszym, a nie ostatnim

Dlaczego o własnym wycieku dowiadujecie się ostatni

Sekwencja jest niemal zawsze ta sama. Ktoś z zewnątrz widzi Wasze dane wcześniej niż Wy: badacz, klient z powiadomieniem, dziennikarz, wreszcie organ nadzorczy z pytaniem o zgłoszenie. Wewnątrz organizacji nic w tym czasie nie zapaliło się na czerwono, bo z punktu widzenia Waszych systemów nie wydarzyło się nic nietypowego. Poświadczenia wypłynęły ze stacji pracownika albo z serwisu zewnętrznego, a nie z Waszej sieci. Skala zjawiska nie maleje: CERT Polska obsłużył w 2025 roku 260 783 unikalne incydenty, o 152% więcej niż rok wcześniej.

Ta luka daje się zmierzyć. Według raportu DBIR 2026 73% ofiar ransomware miało w roku poprzedzającym atak infekcję infostealerem albo zdarzenie wycieku danych logowania, a połowa z nich doświadczyła tego w ciągu 95 dni przed atakiem. To nie opis korelacji, tylko opis kolejności: najpierw ktoś zbiera poświadczenia, potem ktoś inny je kupuje, a dopiero na końcu przychodzi szyfrowanie. Między pierwszym a ostatnim krokiem są tygodnie, w których nikt w organizacji nie zagląda w to miejsce.

Warto od razu rozdzielić dwie perspektywy, bo bywają mylone. Kontrola tego, co wypływa z organizacji (załączniki, nośniki, kanały wysyłki), to zadanie dla systemu DLP i kontroli kanałów danych. Monitorowanie wycieków patrzy z drugiej strony: nie pilnuje drzwi, tylko sprawdza, co już leży na zewnątrz. Te dwie funkcje się nie zastępują, bo wyciek danych w firmie coraz rzadziej zaczyna się w firmie. Materiał pochodzi z prywatnego laptopa, ze stacji kontrahenta albo z bazy serwisu, w którym pracownik założył konto służbowym adresem.

Gdzie ten materiał naprawdę krąży

Zdanie „skanujemy dark web" jest w polskich ofertach standardem i jest opisem spóźnionym o dekadę. Klasyczne fora w sieci Tor nadal istnieją i nadal mają znaczenie, ale przestały być głównym miejscem obrotu. Materiał przeniósł się tam, gdzie transakcja jest szybsza: na kanały komunikatorów i wyspecjalizowane giełdy logów działające w zwykłym internecie. Usługa, która patrzy wyłącznie w stronę sieci Tor, pomija kanały, w których dziś odbywa się obrót.

Kierunek działań organów ścigania potwierdza ten obraz. W ramach operacji Endgame między 10 a 14 listopada 2025 roku wyłączono 1025 serwerów obsługujących infrastrukturę złośliwego oprogramowania, a we wcześniejszej fazie wymierzonej w Lummę, między 16 marca a 16 maja 2025 roku, zidentyfikowano ponad 394 000 zainfekowanych komputerów z Windows. Wniosek dla obrońcy pozostaje jednak ostrożny: infrastruktura wraca, kanały dystrybucji się przenoszą, a logi zebrane przed przejęciem serwerów krążą dalej.

Dla organizacji oznacza to jedno: pytanie nie brzmi „czy nasze dane są gdzieś w darkwebie", tylko „gdzie konkretnie, od kiedy i w jakiej postaci". Monitoring darknetu rozumiany jako przeszukiwanie samych ukrytych usług odpowiada dziś na coraz mniejszą część tego pytania. Jak wygląda droga od zainfekowanej stacji do gotowego logu wystawionego na sprzedaż, rozkładamy w tekście o tym, jak działa infostealer.

Trzy różne rzeczy, które trafiają pod jedną nazwę

Największe nieporozumienie w tym temacie polega na traktowaniu „wycieku danych logowania" jak jednej kategorii. To trzy różne rodzaje materiału, o różnym pochodzeniu, różnej świeżości i — co najważniejsze — wymagające innej reakcji. Usługa, która ich nie rozdziela, zasypie Was alertami o pozornie równej wadze, choć jeden oznacza czynne przejęcie stacji, a drugi kopię pliku sprzed czterech lat.

Rozróżnienie między pierwszym a drugim wierszem ma konkretną definicję. Combolista to plik tekstowy z parami adres–hasło, pozbawiony jakiegokolwiek kontekstu. Plik ULP (URL-Login-Password) dokłada adres serwisu, przez co jest cenniejszy: wskazuje, gdzie dane poświadczenie pasuje, i skraca liczbę prób. Oba powstają z logów infostealerów. Przestępcy wyciągają z bogatego logu same poświadczenia i przepakowują je w prostszy format. To dlatego ten sam wyciek haseł pracowników potrafi wrócić do Was trzykrotnie, za każdym razem pod inną nazwą pliku.

Trzeci wiersz jest inny co do natury. Dump z naruszenia dotyczy serwisu, a nie stacji: nie mówi nic o tym, czy komputer pracownika jest zainfekowany, mówi natomiast, że dane powierzone dostawcy znalazły się poza jego kontrolą. Stronę formalną opisujemy osobno, w tekście o naruszeniu ochrony danych po stronie dostawcy. Konsekwencja techniczna jest zawsze ta sama i zawsze niedoceniana: jeśli pracownicy powtarzali hasła, cudza baza staje się kluczem do Waszych systemów, a zautomatyzowana metoda, która to wykorzystuje, nazywa się credential stuffing.

Co monitorowanie faktycznie obejmuje

Zakres tej pracy najłatwiej opisać przez to, czego się szuka, a nie przez listę funkcji w panelu. Poniższe pięć obszarów to minimum, poniżej którego usługa przestaje odpowiadać na pytanie „czy to nas dotyczy" i sprowadza się do monitorowania wycieków haseł z jednej listy adresów.

• Dane logowania pracowników i klientów: nie tylko adresy w domenie firmowej, ale też konta prywatne używane do logowania w narzędziach służbowych oraz konta kontrahentów mających dostęp do Waszych systemów
• Ciasteczka sesji i tokeny: materiał pozwalający odtworzyć zalogowaną sesję bez znajomości hasła i bez przechodzenia przez drugi składnik
• Wzmianki o marce i kadrze: ogłoszenia brokerów dostępu opisujące ofiarę branżą i wielkością, wpisy na stronach wycieków, wątki dotyczące osób decyzyjnych
• Zasoby wystawione do internetu i shadow IT: panele, instancje testowe i konta w usługach chmurowych założone poza wiedzą działu IT, których nie ma w żadnej ewidencji
• Domeny podszywające się: rejestracje łudząco podobne do Waszej, przygotowywane pod phishing, zanim jeszcze zostaną użyte

Skala pokazuje, dlaczego to nie jest ćwiczenie teoretyczne. Z 18,7 mln przeanalizowanych logów z 2025 roku 2,05 mln zawierało firmowe dane tożsamości, a Microsoft Entra ID pojawia się w 79% z nich. Materiał prowadzi więc najczęściej prosto do centralnego katalogu tożsamości, a nie do pojedynczej aplikacji. Dwa ostatnie punkty listy bywają traktowane jak dodatek, a to one odróżniają monitorowanie od odpytania bazy adresów: powiązanie znaleziska z konkretnym zasobem i konkretną osobą jest już pracą wywiadowczą. Sposób, w jaki organizuje się ją w instytucji, opisujemy w tekście o threat intelligence w podmiocie publicznym, a warstwę narzędziową w naszej ofercie stanowi platforma Flare, na której opieramy monitorowanie wycieków danych.

Punkt drugi wymaga osobnego komentarza, bo w tym miejscu kończy się wiele poradników. Rada „włącz uwierzytelnianie wieloskładnikowe" jest słuszna i niewystarczająca: skradzione ciasteczko sesji pozwala wejść w sesję już uwierzytelnioną, więc drugi składnik nie jest w ogóle pytany. Dlatego 1,17 mln logów z 2025 roku zawierających jednocześnie firmowe dane logowania i ciasteczka sesji to liczba ważniejsza niż sama liczba haseł, a właściwą reakcją na taki alert jest unieważnienie sesji, nie zmiana hasła. Kampanię opartą na tym mechanizmie rozłożyliśmy w tekście o kradzieży poświadczeń kadry zarządzającej i obejściu MFA.

Dlaczego surowy feed bez analityka jest bezużyteczny

Dostęp do źródeł jest dziś towarem. Feed z milionami rekordów da się kupić, podłączyć i włączyć powiadomienia, a po tygodniu wszyscy przestaną je czytać. Wartość powstaje dopiero w triage: w decyzji, które znalezisko jest zdarzeniem bezpieczeństwa, a które notatką do rejestru. Poniższe pary opisują, na co patrzy się przy takiej decyzji.

Wiek materiału zmienia decyzję bardziej niż cokolwiek innego, a dane logowania w obiegu prawie nigdy nie mają metryki. Datę trzeba odtworzyć z kontekstu, a nie odczytać z nagłówka. Group-IB udokumentował 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, dziewięć miesięcy później, w innym formacie i pod inną nazwą. Bez rozpoznania recyklingu taki alert uruchamia procedurę incydentu po raz drugi za to samo zdarzenie. Odwrotny błąd jest groźniejszy: uznanie świeżego logu za kolejną starą combolistę i zamknięcie sprawy jednym kliknięciem.

Skala tej pracy jest przy tym mniejsza, niż się wydaje, i to argument za robieniem jej porządnie. Według DBIR 2026 mediana liczby zdarzeń wycieku danych logowania w ciągu roku wynosi 7 w małych organizacjach i 20 w większych. To nie setki spraw miesięcznie, tylko kilkanaście przypadków rocznie, z których każdy zasługuje na godzinę uwagi kogoś, kto wie, na co patrzy. Jak te proporcje rozkładają się w konkretnej branży, pokazujemy w analizie wycieków danych logowania w fintechu regionu EMEA.

Czego alert od Was wymaga

Znalezisko nie jest ciekawostką do przekazania na spotkaniu statusowym. Jeśli dotyczy danych osobowych, uruchamia analizę ryzyka dla praw i wolności osób, a jej wynik trzeba udokumentować niezależnie od tego, czy skończy się zgłoszeniem. Obowiązkiem jest samo przeprowadzenie analizy, nie jej rezultat.

Jeżeli analiza wskaże naruszenie, zaczyna biec termin: zgłoszenie do organu nadzorczego bez zbędnej zwłoki, nie później niż w ciągu 72 godzin od stwierdzenia naruszenia, a po przekroczeniu tego czasu trzeba wyjaśnić opóźnienie. W sierpniu 2026 roku UODO przypomniał, że obowiązek zgłoszenia spoczywa na administratorze także wtedy, gdy do zdarzenia doszło u podmiotu przetwarzającego, a przed zgłoszeniem administrator musi uzyskać od procesora potwierdzenie, że incydent objął jego dane. To ten krok decyduje o momencie startu zegara i to on potrafi się przeciągnąć.

Warto zapamiętać jedno zdanie: spóźnione zgłoszenie jest samodzielną podstawą odpowiedzialności, niezależną od samego wycieku, a monitorowanie skraca dokładnie ten odcinek (czas do stwierdzenia naruszenia); szerzej piszemy o tym przy naruszeniu ochrony danych u dostawcy. Osobno biegną obowiązki z ustawy o krajowym systemie cyberbezpieczeństwa, jeśli jesteście podmiotem kluczowym albo ważnym, z własnymi terminami i własnym adresatem zgłoszenia; progi rozłożyliśmy w tekście o NIS2 i ustawie o KSC. Wniosek praktyczny: decyzja o tym, kto odbiera alert i kto ma prawo uruchomić procedurę, musi zapaść przed pierwszym alertem, a nie w jego trakcie.

Od znaleziska do zamknięcia

Poniższa sekwencja opisuje pojedyncze zgłoszenie dotyczące firmowego konta znalezionego w logu infostealera. Zakłada, że wiadomo z góry, kto podejmuje decyzje, bo to jest część, której nie da się nadrobić w trakcie.

1. Krok 1Analityk monitorowania
   Weryfikacja znaleziska

   Zanim ktokolwiek zostanie obudzony, trzeba ustalić trzy rzeczy: czy konto istnieje i jest aktywne, jaka jest data pochodzenia materiału i czy nie widzieliście go już w innej paczce. Na tym etapie odpada część zgłoszeń, nie dlatego, że są nieprawdziwe, tylko dlatego, że opisują zdarzenie już obsłużone.

2. Krok 2Analityk + administrator tożsamości
   Ustalenie zasięgu

   Jeżeli materiał pochodzi z logu, przedmiotem sprawy nie jest jedno konto, tylko cała stacja. Z jednego urządzenia wypływa zwykle wszystko, co było zapisane w przeglądarce: konta służbowe i prywatne, dostępy do paneli dostawców, klucze wklejone kiedyś do notatek. Ustala się więc, czyje to urządzenie, jakie tożsamości były na nim używane i do czego te tożsamości uprawniają.

3. Krok 3Administrator tożsamości
   Unieważnienie sesji, nie tylko zmiana hasła

   To krok, który łatwo wykonać w połowie. Zmiana hasła nie kończy sesji odtworzonej ze skradzionego ciasteczka, nie unieważnia wydanych tokenów odświeżania i nie usuwa dodanej wcześniej metody uwierzytelniania. Kolejność jest odwrotna niż intuicyjna: najpierw wymuszone wylogowanie ze wszystkich sesji i unieważnienie tokenów, potem przegląd zarejestrowanych metod MFA oraz reguł przekierowania poczty, a zmiana hasła dopiero na końcu.

4. Krok 4SOC albo zespół IT
   Sprawdzenie logowań wstecz

   Materiał ma datę, więc przegląd zaczyna się od niej, a nie od dnia alertu. Szuka się udanych logowań z nietypowych lokalizacji i adresów, nowych rejestracji urządzeń, utworzonych reguł skrzynki, nadanych zgód aplikacjom i dostępów do zasobów, których dana osoba normalnie nie otwiera. Tu rozstrzyga retencja logów: jeśli jest krótsza niż wiek znaleziska, odpowiedzi na pytanie o przejęcie konta po prostu nie będzie. O tym, która warstwa detekcji co przechowuje, piszemy w porównaniu SIEM, SOAR, XDR i EDR.

5. Krok 5Inspektor ochrony danych + zarząd
   Decyzja o zgłoszeniu

   Na tym etapie znany jest zakres: czyje dane, jakiego rodzaju, w jakiej ilości i czy ktoś z nich skorzystał. Dopiero teraz da się przeprowadzić analizę ryzyka i podjąć decyzję o zgłoszeniu do organu oraz o zawiadomieniu osób. Decyzja odmowna też jest decyzją i również wymaga uzasadnienia w dokumentacji.

6. Krok 6Właściciel procesu
   Wnioski i zamknięcie

   Sprawę zamyka odpowiedź na pytanie, dlaczego to się udało: czy stacja była poza zarządzaniem, czy hasło było powtórzone, czy konto miało uprawnienia szersze, niż wymagała rola, czy w ogóle wiedzieliście o istnieniu tego konta. Bez tego kroku ten sam alert wróci za kwartał, a organizacja obsłuży go po raz drugi od zera.

Po czym poznać dobrą usługę monitorowania

Rynek jest tu nierówny, a różnic nie widać po opisie na stronie, bo wszyscy używają tych samych słów. Poniższe kryteria są neutralne wobec dostawcy. Da się je zadać jako pytania w zapytaniu ofertowym i porównać odpowiedzi obok siebie.

• Jakie źródła realnie obejmuje. Poproście o wymienienie kategorii: fora, giełdy logów, kanały komunikatorów, strony wycieków, serwisy wymiany plików. Odpowiedź „dark web" nie jest odpowiedzią
• Czy rozdziela typy materiału: czy alert mówi wprost, że to log ze stacji, przepakowana combolista albo dump z naruszenia, bo to trzy różne procedury
• Czy podaje datę pochodzenia i historię obiegu: bez tego nie da się odróżnić nowej infekcji od recyklingu sprzed roku
• Czy obejmuje ciasteczka sesji i tokeny, nie tylko hasła: inaczej największa część ryzyka pozostaje niewidoczna
• Kto wykonuje triage i w jakim czasie: czy dostajecie surowy rekord, czy zweryfikowane zgłoszenie z rekomendacją, i kto odpowiada poza godzinami pracy
• Czy zakres obejmuje kontrahentów i łańcuch dostaw: spora część znalezisk dotyczy kont u dostawców mających dostęp do Waszych systemów
• Co dostajecie w formie nadającej się do dokumentacji: zrzut ekranu z panelu nie jest materiałem, na którym da się oprzeć analizę ryzyka
• Jak wygląda wyjście z usługi: czy historia znalezisk zostaje u Was, czy u dostawcy

Najczęstsze pytania

Podsumowanie

Monitorowanie wycieków danych nie jest kolejnym panelem do oglądania. To rozstrzygnięcie, kto dowiaduje się pierwszy: Wy czy ktoś, kto właśnie kupił Wasze poświadczenia. Usługę, która to zmienia, odróżniają od generatora raportów trzy rzeczy: patrzy tam, gdzie materiał faktycznie krąży, a nie tam, gdzie krążył dekadę temu; rozdziela świeży log od przepakowanej starej listy; i kończy każde zgłoszenie decyzją, a nie powiadomieniem. Reszta sprowadza się do tego, czy ktoś odbierze alert w piątek po siedemnastej.

Wyciek nie zaczyna się w dniu, w którym się o nim dowiadujecie. Zaczyna się w dniu, w którym dowiedział się o nim ktoś inny.