850 gigabajtów, 200 tysięcy plików i jedno cudze hasło

15 kwietnia 2026 roku, gdzieś w zamkniętej części sieci, do której nie prowadzi żadna wyszukiwarka, pojawił się katalog. Około dwustu tysięcy plików, łącznie 850 gigabajtów. Większość — jakieś 650 GB — to niegroźne materiały audiowizualne o charakterze publicznym. Ale reszta, blisko 33 tysiące plików, zawierała numery PESEL, serie dowodów osobistych i paszportów, adresy zamieszkania, numery rachunków bankowych, dane z dokumentów podatkowych, informacje ze zwolnień lekarskich i wizerunki. Nadawcą zbioru nie był haker z filmowego stereotypu. Był nim ktoś, kto po prostu zalogował się prawidłowym loginem i hasłem do systemu Uniwersytetu Warszawskiego — największej polskiej uczelni.

Historia zaczęła się wcześniej. Już 17 lutego 2026 roku wicepremier i minister cyfryzacji Krzysztof Gawkowski poinformował na platformie X o zidentyfikowanym ataku na część infrastruktury IT UW; tego samego dnia uczelnia potwierdziła, że złośliwe oprogramowanie wykryto na jednej ze stacji roboczych, a zdarzenie miało miejsce w styczniu. Ponad miesiąc później analitycy firmy ESET wskazali, że za atakiem stoi grupa przestępcza „Interlock". Co istotne — danych nie zaszyfrowano. Nie było klasycznego ransomware'u z żądaniem okupu za klucz. Napastnicy po cichu skopiowali pliki, a gdy uczelnia nie spełniła oczekiwań, po prostu je opublikowali.

Analiza dziennikarska Oskara Klimczuka z portalu CyberDefence24 pokazała, jak konkretne były to dane: wśród nich znalazły się wykazy rekrutacyjne dwóch jednostek — Wydziału Neofilologii oraz Wydziału Stosowanych Nauk Społecznych i Resocjalizacji. Listy osób przyjętych, list rezerwowych, a nawet kandydatów, którzy nigdy studentami nie zostali. Roczniki sięgające 2019/2020. To nie jest opowieść o jednym pechu jednej uczelni. To podręcznikowy przykład tego, jak wygląda dziś włamanie do dużej organizacji — i dlaczego samorząd, szpital, spółka komunalna czy średnia firma powinny czytać ją jak własną instrukcję.

Anatomia włamania: żadnego łamania, samo logowanie

Warto zatrzymać się nad tym, czego w tej historii nie było. Nie było spektakularnego przełamania firewalla. Nie było exploita na nieznaną podatność. Nie było zaszyfrowanych serwerów i odliczającego zegara. Był login i było hasło — prawdziwe, ważne, należące do pracownika uczelni. Osoba nieuprawniona zalogowała się nimi tak, jak zrobiłby to sam pracownik, i przez pewien czas poruszała się po zasobach z uprawnieniami legalnego użytkownika. Z perspektywy większości systemów bezpieczeństwa nie wydarzyło się nic podejrzanego, bo formalnie to był autoryzowany dostęp.

Skąd napastnik wziął dane logowania? Najbardziej prawdopodobny scenariusz, wskazany także w komunikacie UW, to złośliwe oprogramowanie na urządzeniu użytkownika — tak zwany infostealer, który wykrada zapisane w przeglądarce hasła, ciasteczka sesyjne i tokeny. Wystarczy jeden pobrany „crack" do programu, jeden załącznik, jedno kliknięcie na spreparowanej stronie. Reszta dzieje się automatycznie, w tle, bez wiedzy ofiary.

Uderzająca jest też lokalizacja skradzionych plików. Analiza CyberDefence24 wykazała, że większość dokumentów pochodziła nie z centralnych, dobrze chronionych baz danych, lecz z folderów „Pobrane", z kosza i z pulpitów stacji roboczych pracowników. To codzienny bałagan cyfrowy każdej organizacji: raz pobrany plik, który nigdy nie został skasowany; eksport z systemu dziekanatowego zrobiony „na szybko" i zapomniany; arkusz z rekrutacji sprzed pięciu lat, leżący na pulpicie „na wszelki wypadek". Napastnik nie musiał włamywać się do serca infrastruktury. Wystarczyło mu jedno przejęte konto i cudza niefrasobliwość.

Osobny, niewygodny wątek to czas. Zdarzenie miało miejsce w styczniu 2026 roku, złośliwe oprogramowanie potwierdzono w lutym, atrybucję do grupy Interlock ustalono ponad miesiąc później, a dane opublikowano w darknecie dopiero 15 kwietnia. Między pierwszym nieuprawnionym dostępem a ujawnieniem skali wycieku minęły więc tygodnie, w których napastnik poruszał się po zasobach, a organizacja nie wiedziała o pełnych rozmiarach problemu. Ten dystans — w branży nazywany „dwell time", czasem przebywania intruza w sieci — jest miarą, która oddziela drobny incydent od katastrofy. Im dłużej przejęte konto działa niezauważone, tym więcej danych zdąży wypłynąć. Skrócenie tego czasu z tygodni do godzin nie zależy od grubszego firewalla, lecz od zdolności wykrywania nietypowego zachowania kont i stacji roboczych.

Dlaczego duża instytucja jest łatwiejszym celem, niż się wydaje

Uniwersytet Warszawski to dziesiątki wydziałów i instytutów, tysiące pracowników, dziesiątki tysięcy studentów i — co dla bezpieczeństwa kluczowe — bardzo silna autonomia jednostek. Każdy wydział ma własne procesy, własne przyzwyczajenia, często własne, historycznie ukształtowane rozwiązania IT. To środowisko, w którym trudno o jeden spójny standard i jeszcze trudniej o jego wyegzekwowanie. Im większa i bardziej rozproszona organizacja, tym więcej stacji roboczych, kont, eksportów i „tymczasowych" plików — i tym większa powierzchnia, którą napastnikowi wystarczy trafić w jednym punkcie.

To nie jest problem wyłącznie uczelni. Dokładnie tę samą strukturę ma duży urząd miasta z kilkunastoma wydziałami i jednostkami podległymi. Ma ją szpital z oddziałami, poradniami i administracją. Ma ją spółka komunalna łącząca dział techniczny, biuro obsługi klienta i księgowość. Wszędzie tam obowiązuje ta sama, żelazna zasada: bezpieczeństwo całości jest tak mocne, jak jej najsłabsze pojedyncze konto. Napastnik nie potrzebuje przełamać wszystkich zabezpieczeń — potrzebuje jednego pracownika, który zapisał hasło w przeglądarce i pobrał niewłaściwy plik.

Uczelnie mają przy tym cechę, która czyni je szczególnie łakomym kąskiem: przetwarzają dane niezwykle różnorodne i wrażliwe. Numery PESEL i dokumentów tożsamości setek tysięcy osób, dane kadrowe i płacowe, informacje o stanie zdrowia ze zwolnień lekarskich, dane rekrutacyjne kandydatów z całej Polski. To nie jest jedna kategoria danych do wykradzenia — to cała mapa tożsamości ludzi, którzy często nawet nie pamiętają, że kiedyś aplikowali na dany kierunek.

Dane, które nigdy nie powinny tam leżeć

Najbardziej pouczający wątek całej sprawy nie dotyczy hakera, lecz danych, które w ogóle nie powinny być w zasięgu przejętego konta. W wycieku znalazły się listy rekrutacyjne z roczników 2019/2020, 2020/2021 i kolejnych. Znalazły się w nim osoby, które nie dostały się na studia — kandydaci z list rezerwowych i osoby nieprzyjęte. Po co uczelnia — a właściwie: po co pojedyncza stacja robocza pracownika — miałaby po pięciu latach przechowywać numer PESEL kogoś, kto nigdy nie został studentem?

Tu wchodzimy w fundament RODO, który wielu administratorów traktuje jako formalność, a który właśnie w takich momentach decyduje o skali katastrofy. Zasada minimalizacji danych (art. 5 ust. 1 lit. c RODO) mówi, że przetwarzać wolno tylko dane adekwatne i niezbędne do celu. Zasada ograniczenia przechowywania (art. 5 ust. 1 lit. e RODO) wymaga, by dane usuwać, gdy cel ustał. Cel przetwarzania danych osoby, która nie dostała się na studia w 2020 roku, wygasł najpóźniej wtedy, gdy zakończyła się rekrutacja. Każdy dzień, w którym ten plik nadal leżał na czyimś pulpicie, był naruszeniem tych zasad — na długo zanim pojawił się jakikolwiek haker.

Ten mechanizm działa identycznie w każdej organizacji. Stare bazy klientów „na wszelki wypadek", skany dowodów sprzed lat, eksporty z systemów kadrowych zapomniane w folderze „Pobrane" — to wszystko jest paliwem dla wycieku. Im mniej danych organizacja przechowuje, tym mniej może wyciec. Retencja i minimalizacja nie są biurokratycznym rytuałem. Są najtańszą polisą ubezpieczeniową, jaką można wykupić — bo dane, których nie ma, są odporne na każdy atak świata.

Infostealer — niewidzialny złodziej tożsamości cyfrowej

Żeby zrozumieć, dlaczego przejęte hasło stało się problemem całej uczelni, trzeba spojrzeć na skalę zjawiska. Raport CERT Polska za 2025 rok to dokument, który powinien odebrać sen niejednemu zarządowi. Zespół odnotował 658 320 zgłoszeń — blisko dwa tysiące dziennie — a liczba obsłużonych incydentów wzrosła rok do roku o ponad 150 procent. Aż 30 procent wszystkich zdarzeń, około 78 tysięcy, to phishing: próby wykradzenia loginów, haseł i danych dostępowych.

Sercem tego przemysłu są właśnie infostealery. Na przejętych stacjach roboczych dominowały w 2025 roku dwie rodziny: Lumma.Stealer (36,3 procent) i RedLine (34,5 procent). Ich zadanie jest proste i brutalnie skuteczne — wyssać z komputera wszystko, co pozwala się gdzieś zalogować: hasła zapisane w przeglądarce, aktywne sesje, tokeny, dane kart. We wrześniu 2025 roku na publicznym kanale Telegram opublikowano ponad 1,8 miliona rekordów z danymi logowania. Rynek skradzionych poświadczeń jest dziś tak duży, że napastnik często nie musi niczego wykradać samodzielnie — może po prostu kupić działający login do interesującej go organizacji.

Warto przy tym pamiętać, skąd zwykle bierze się infekcja. Infostealer rzadko trafia na komputer przez frontalny atak na organizację — częściej wchodzi tylnymi drzwiami prywatnego nawyku. Zapisane w przeglądarce służbowe hasło synchronizowane z prywatnym laptopem, na którym ktoś pobrał „darmową" wersję programu. Załącznik otwarty na telefonie, który loguje się do tej samej poczty. Wtyczka do przeglądarki z nieznanego źródła. Granica między urządzeniem służbowym a prywatnym, którą wiele organizacji zaciera w imię wygody, jest dokładnie tą szczeliną, przez którą wypływają poświadczenia. Dlatego higiena rozdzielenia sfery prywatnej i służbowej — osobne przeglądarki, zakaz zapisywania haseł służbowych, kontrola nad tym, co łączy się z firmowymi zasobami — nie jest przesadą, lecz elementarną obroną.

W tej rzeczywistości pojedyncze hasło przestało być zabezpieczeniem. Jest zabezpieczeniem tylko wtedy, gdy towarzyszy mu drugi składnik uwierzytelniania — kod z aplikacji, klucz sprzętowy, potwierdzenie na telefonie. Uwierzytelnianie wieloskładnikowe (MFA) to jedyny mechanizm, który sprawia, że skradzione hasło samo w sobie jest bezużyteczne. Gdyby konto pracownika UW było chronione MFA, przejęty login byłby dla napastnika bezwartościowym ciągiem znaków. To jedno wdrożenie, tania i dostępna technologia, zatrzymuje dziś większość ataków opartych na kradzieży poświadczeń. Pisaliśmy o tym szerzej przy okazji kary UODO dla kancelarii podatkowej, w której również przejęto konto pracownika — schemat jest bliźniaczo podobny.

Kradzież danych to naruszenie — nawet gdy nic nie zaszyfrowano

Pokusa, by w takiej sytuacji się uspokoić, jest silna: „przecież nie zaszyfrowali serwerów, systemy działały, uczelnia pracowała". To myślenie jest fałszywe i niebezpieczne. Z punktu widzenia RODO naruszeniem ochrony danych jest już samo uzyskanie do nich nieuprawnionego dostępu — tak stanowi definicja z art. 4 pkt 12 rozporządzenia. Nie trzeba szyfrowania. Nie trzeba nawet dowodu, że dane zostały pobrane. Wystarczy, że osoba nieuprawniona mogła się do nich dostać.

Ten kierunek potwierdza najnowsze orzecznictwo. Naczelny Sąd Administracyjny w marcu 2026 roku, w sprawie związanej z decyzją UODO wobec Fortum, przyjął, że sama ekspozycja danych — udostępnienie ich osobie nieuprawnionej — stanowi naruszenie, niezależnie od tego, czy udało się wykazać ich dalsze wykorzystanie. W przypadku Uniwersytetu Warszawskiego problem jest tym poważniejszy, że danych nie tylko ktoś dotknął — zostały opublikowane w darknecie. To najwyższy możliwy poziom ryzyka dla osób, których dotyczą.

Konsekwencje proceduralne są jednoznaczne. Administrator ma 72 godziny na zgłoszenie naruszenia organowi nadzorczemu (art. 33 RODO), a przy wysokim ryzyku dla praw i wolności — obowiązek zawiadomienia samych osób, których dane dotyczą (art. 34 RODO). Uniwersytet Warszawski zgłosił sprawę Prezesowi UODO i opublikował komunikat o naruszeniu, w którym doradził osobom potencjalnie dotkniętym zastrzeżenie numeru PESEL, ostrożność wobec prób kontaktu od nieznajomych i włączenie uwierzytelniania dwuetapowego. To właściwe kroki — ale wykonane już po fakcie, gdy dane były w obiegu. Cała trudność zarządzania takim incydentem polega na tym, że wycieku danych nie da się cofnąć. Opublikowanego PESEL-u nie da się „odpublikować".

Uczelnia w reżimie NIS-2 i ustawy o KSC: zegar tyka do 3 października

Sprawa UW wybrzmiewa w bardzo konkretnym momencie prawnym. Znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa, wdrażająca dyrektywę NIS-2, weszła w życie 3 kwietnia 2026 roku, a do 3 października 2026 roku podmioty objęte przepisami mają czas na samoidentyfikację i wpis do wykazu podmiotów kluczowych i ważnych. Ministerstwo Cyfryzacji szacuje, że nowe regulacje mogą objąć około 38 tysięcy podmiotów, z czego blisko 27 tysięcy to podmioty publiczne — urzędy, szpitale, samorządy i właśnie uczelnie.

Szkolnictwo wyższe i nauka to jeden z sektorów objętych nowym reżimem; badania naukowe znalazły się wśród obszarów wymienionych w NIS-2. Uczelnie publiczne, jako jednostki wykonujące zadania publiczne, mają realizować obowiązki wynikające z ustawy — od audytu bezpieczeństwa, przez wdrożenie systemu zarządzania bezpieczeństwem informacji, po szkolenia kadry i wyznaczenie osób odpowiedzialnych. Eksperci sektora, m.in. z uczelni akademickich, otwarcie ostrzegają przed ryzykiem nadregulacji i kosztów, na które szkoły wyższe nie są przygotowane — ale prawo nie pyta o gotowość. Zegar do 3 października tyka jednakowo dla wszystkich. Mechanikę tego wpisu opisaliśmy krok po kroku w przewodniku po samoidentyfikacji NIS-2.

Największym wyzwaniem dla dużej, autonomicznej instytucji nie jest przy tym samo złożenie wniosku, lecz przełożenie papierowego SZBI na realną praktykę dziesiątek jednostek. Bo można mieć wzorowo napisaną politykę bezpieczeństwa i jednocześnie pliki z PESEL-ami na pulpicie w jednym z instytutów. NIS-2 nie kończy się na dokumencie. Zaczyna się tam, gdzie dokument spotyka codzienną pracę pojedynczego pracownika.

Model „exfiltracja i wymuszenie" zastępuje klasyczny ransomware

W przypadku UW nie doszło do zaszyfrowania danych — i to nie przypadek, lecz sygnał zmiany, którą warto zrozumieć. Klasyczny ransomware, który blokuje systemy i żąda okupu za klucz, przestaje być jedynym modelem. Coraz częściej napastnicy stosują czystą eksfiltrację połączoną z szantażem: wykradają dane, a następnie grożą ich publikacją, jeśli ofiara nie zapłaci. Szyfrowanie bywa pomijane, bo wywołuje natychmiastowy chaos operacyjny i alarmuje ofiarę, podczas gdy cicha kradzież pozwala dłużej pozostać niezauważonym i daje mocniejszą dźwignię negocjacyjną. Publikacja zbioru w darknecie to zwykle ostatni akt — kara za brak zapłaty.

Dla organizacji oznacza to trzy rzeczy. Po pierwsze, backup — choć absolutnie niezbędny — nie chroni już przed wszystkim. Kopia zapasowa pozwala odtworzyć zaszyfrowane systemy, ale nie cofnie publikacji skradzionych danych. Po drugie, kluczowe stają się mechanizmy wykrywania nietypowego dostępu i wynoszenia danych — bo napastnik, który loguje się prawidłowymi poświadczeniami, nie zostanie zatrzymany przez blokadę na złe hasło. Wychwyci go dopiero analiza zachowania: konto, które nagle pobiera setki plików, łączy się o nietypowych porach albo z nietypowej lokalizacji.

Po trzecie, wyciek uruchamia drugą falę zagrożeń — wtórny phishing i oszustwa wymierzone w same ofiary. Gdy przestępca dysponuje imieniem, nazwiskiem, numerem PESEL i historią studiów konkretnej osoby, jego telefon czy e-mail brzmią wiarygodnie. Dlatego rekomendacja UW, by zachować ostrożność wobec nagłych kontaktów nakłaniających do pilnego działania, nie jest formalnym dodatkiem — to realna linia obrony osób, których dane trafiły do sieci. Ten sam scenariusz „drugiego uderzenia" obserwowaliśmy podczas wiosennej fali ransomware'u na szpitale i samorządy.

Czego sprawa UW uczy każdą inną organizację

Łatwo potraktować ten wyciek jako problem jednej uczelni. Byłby to błąd, bo mechanizm ataku jest uniwersalny i powtarzalny. Napastnik przejął pojedyncze konto — najpewniej przez infostealer na prywatnym lub służbowym urządzeniu — a następnie wykorzystał je do sięgnięcia po dane, które od lat leżały tam, gdzie leżeć nie powinny. Nie potrzebował zaawansowanych narzędzi. Potrzebował jednego słabego ogniwa. Każda organizacja ma swój Wydział Neofilologii — jednostkę, dział albo pojedynczą osobę, u której skupia się nadmiar danych i niedomiar dyscypliny.

Wnioski są konkretne i przekładają się na decyzje, które można podjąć od zaraz. Po pierwsze, uwierzytelnianie wieloskładnikowe na wszystkich kontach dających dostęp do danych osobowych — to pojedyncze wdrożenie unieważnia większość ataków opartych na kradzieży haseł. Po drugie, ochrona stacji roboczych klasy EDR, która wykrywa infostealery, zanim wyślą łup, oraz twarda zasada, że hasła służbowe nie są zapisywane w przeglądarce. Po trzecie, inwentaryzacja i minimalizacja danych: świadomość, gdzie w organizacji naprawdę leżą pliki z PESEL-ami, i konsekwentne usuwanie tych, których cel przetwarzania wygasł.

Po czwarte, segmentacja i zasada minimalnych uprawnień — konto pojedynczego pracownika nie powinno otwierać dostępu do danych całej instytucji. Po piąte, monitorowanie i logowanie dostępu, bo naruszenie popełnione „ważnym" hasłem wychwyci wyłącznie analiza nietypowego zachowania, a nie klasyczna blokada. I po szóste, regularne szkolenia — bo to człowiek pobiera plik, klika w link i zapisuje hasło, i to człowiek jest zarówno najsłabszym ogniwem, jak i najtańszą do wzmocnienia linią obrony.

Dlaczego z Fib.Code: bezpieczeństwo danych w dużej instytucji

Fib.Code Sp. z o.o. specjalizuje się w bezpieczeństwie informacji, cyberbezpieczeństwie, ochronie danych osobowych i audytach zgodności — w tym w reżimie ISO 27001, RODO oraz ustawy o krajowym systemie cyberbezpieczeństwa wdrażającej NIS-2. Rozumiemy specyfikę dużych, rozproszonych organizacji, w których autonomia jednostek zderza się z wymogiem jednolitego standardu bezpieczeństwa — a właśnie tam, jak pokazuje sprawa UW, rodzą się najpoważniejsze ryzyka.

Pracujemy według trzech zasad. Zaczynamy od faktów, nie od formularzy — najpierw ustalamy, gdzie realnie leżą dane, kto ma do nich dostęp i którędy mogą wypłynąć, a dopiero potem budujemy dokumentację. Traktujemy bezpieczeństwo jako proces, nie projekt — polityka bez wdrożenia jej w codzienną pracę pojedynczego stanowiska jest tylko papierem. I stawiamy na proporcjonalność — dobieramy środki do rzeczywistego ryzyka i możliwości organizacji, zamiast mnożyć koszty bez pokrycia.

Efektem naszej pracy jest instytucja, która nie tylko ma zgodny z prawem system zarządzania bezpieczeństwem informacji, lecz realnie potrafi wykryć przejęte konto, ograniczyć skutki incydentu i udźwignąć obowiązki NIS-2 przed terminem 3 października 2026 roku. Wspieramy też w roli pełnomocnika ds. bezpieczeństwa informacji i inspektora ochrony danych — tak, by ktoś kompetentny czuwał nad całością na co dzień, a nie tylko w dniu kontroli.

Co zrobić w najbliższy tydzień: plan dla uczelni i nie tylko

Zacznij od jednego spotkania — 60 minut, w gronie osoby odpowiedzialnej za IT, IOD-a lub pełnomocnika ds. bezpieczeństwa oraz kogoś z zarządu lub kierownictwa, kto może podejmować decyzje. Na tym spotkaniu zadaj cztery pytania. Pierwsze: czy wszystkie konta z dostępem do danych osobowych są chronione uwierzytelnianiem wieloskładnikowym, a jeśli nie — które i do kiedy zostaną nim objęte? Drugie: gdzie w naszej organizacji naprawdę leżą pliki z numerami PESEL i danymi wrażliwymi — także na pulpitach, w folderach „Pobrane" i w koszu, nie tylko w centralnych systemach?

Trzecie: jakie dane przechowujemy mimo że cel ich przetwarzania już wygasł, i kto oraz kiedy je usunie? Czwarte: czy jesteśmy w stanie w ciągu 72 godzin rozpoznać, zgłosić i opanować naruszenie — i czy ktoś w ogóle zauważyłby, że „ważne" konto pobiera nagle setki plików? Jeśli odpowiedź na którekolwiek z tych pytań brzmi „nie wiem", masz przed sobą listę zadań ważniejszą niż większość rzeczy w tegorocznym planie. A jeśli Twoja organizacja podlega NIS-2, dołóż do niej piąte pytanie: czy zdążymy z samoidentyfikacją i wpisem do wykazu przed 3 października — i co dokładnie musi się do tego czasu wydarzyć.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: kara UODO dla kancelarii podatkowej za przejęte konto e-mail, wiosenna fala ransomware'u na szpitale, samorządy i MŚP, samoidentyfikacja NIS-2 i wpis do wykazu podmiotów kluczowych — jedno tematyczne spięcie o tym, jak jedno przejęte hasło i garść zapomnianych plików stają się problemem całej instytucji.