Kontekst scenariusza — Uniwersytet Techniczno-Przyrodniczy
Poniższy scenariusz opiera się na analizie rzeczywistych incydentów ransomware w sektorze edukacji i przedstawia typowy przebieg ataku na fikcyjną polską uczelnię — Uniwersytet Techniczno-Przyrodniczy (UTP) z 12 tysiącami studentów i 2 tysiącami pracowników.
UTP posiada typową dla polskiej uczelni infrastrukturę IT: serwery on-premise z systemami administracyjnymi (USOS, ERP, poczta), platforma Moodle dla e-learningu, sieć kampusowa z Wi-Fi dla studentów, kilka laboratoriów komputerowych i serwerownia z danymi badawczymi. Budżet IT pozwala na utrzymanie podstawowej infrastruktury, ale nie na zaawansowane rozwiązania bezpieczeństwa. Uczelnia posiada dwuosobowy zespół IT i IOD w ramach pół etatu.
Atak ma miejsce w październiku — na początku roku akademickiego, gdy systemy są obciążone rekrutacją, zapisami na zajęcia i konfiguracją kont dla nowych studentów. Dział IT pracuje pod maksymalną presją. To nie przypadek — atakujący świadomie wybierają momenty, gdy zdolność reakcji instytucji jest najniższa.
Celem ataku jest grupa ransomware „BlackAcademia” — fikcyjna nazwa inspirowana rzeczywistymi grupami atakującymi sektor edukacji. Ich model operacyjny to podwójne wymuszenie: szyfrowanie danych i groźba ich publikacji.
Dzień 1, godzina 9:00 — Wektor wejściowy: spear phishing
Atak rozpoczyna się od starannie przygotowanego e-maila spear phishing skierowanego do prof. Anny Kowalskiej z Wydziału Informatyki. Wiadomość podszywa się pod Narodowe Centrum Nauki i informuje o nowym konkursie grantowym OPUS 27 z terminem składania wniosków za 10 dni. E-mail zawiera link do „formularza wstępnej kwalifikacji” na stronie ncn-grants[.]pl (domena zarejestrowana dzień wcześniej, łudząco podobna do ncn.gov.pl).
Profesor Kowalska, aktywnie aplikująca o granty, klika w link. Strona wygląda identycznie jak system OSF (Obsługa Strumieni Finansowania). Loguje się swoimi danymi — system wyświetla komunikat o błędzie i prosi o ponowne logowanie. W tle dane zostały już przechwycone i przesłane do serwera atakujących.
O godzinie 9:15 atakujący logują się na konto pocztowe profesor Kowalskiej. Pierwsze, co robią, to konfiguracja reguły przekierowania — kopia wszystkich wiadomości jest wysyłana na zewnętrzny adres. Następnie przeglądają skrzynkę w poszukiwaniu informacji o infrastrukturze IT, danych dostępowych do innych systemów i listy kontaktów.
O godzinie 10:30 z konta profesor Kowalskiej wysyłana jest wiadomość do pięciu pracowników wydziału — „Proszę o pilną recenzję tego artykułu przed jutrzejszym deadline’em” — z załącznikiem .docx zawierającym makro pobierające backdoor. Dwie osoby otwierają plik i włączają makra. Atakujący mają teraz trzy przyczółki w sieci uczelni.
Dzień 1-3 — Rekonesans i lateral movement
Przez następne 48 godzin atakujący prowadzą cichy rekonesans sieci kampusowej, wykorzystując narzędzia takie jak BloodHound do mapowania struktury Active Directory, Mimikatz do ekstrakcji danych uwierzytelniających z pamięci zainfekowanych stacji i PsExec do zdalnego wykonywania poleceń.
Dzień 1, 14:00: Backdoor na stacji dr. Nowaka (jeden z dwóch pracowników, którzy otworzyli zainfekowany plik) eskaluje uprawnienia do poziomu administratora lokalnego, wykorzystując niezałataną podatność CVE w systemie Windows. Z pamięci procesu lsass.exe wyciągany jest hash hasła konta domenowego.
Dzień 1, 18:00: Atakujący odkrywają, że dr Nowak jest członkiem grupy „Wydziałowi Administratorzy IT” w Active Directory, co daje mu rozszerzone uprawnienia do serwerów wydziałowych. Wykorzystując te uprawnienia, uzyskują dostęp do serwera plików wydziału, gdzie znajdują się dane badawcze, prace dyplomowe i dokumentacja projektów grantowych.
Dzień 2, 02:00: W godzinach nocnych (gdy monitorowanie jest minimalne) atakujący skanują sieci kampusowe. Odkrywają, że segmentacja sieci jest szczątkowa — z sieci wydziałowej można dotrzeć do segmentu administracyjnego. Identyfikują serwer USOS, serwer ERP, serwer poczty Exchange i instancję Moodle.
Dzień 2, 11:00: Wykorzystując technikę Pass-the-Hash, atakujący uzyskują dostęp do konta administratora domeny. Mają teraz pełną kontrolę nad całą infrastrukturą Active Directory uczelni. Od tego momentu żadne dane nie są bezpieczne.
Dzień 3: Atakujący metodycznie eksfiltrują dane — 2 TB danych badawczych, bazy danych USOS z danymi 50 000 studentów (obecnych i byłych), dane kadrowe pracowników z numerami PESEL, dokumentację finansową. Dane są przesyłane na zewnętrzne serwery przez zaszyfrowany tunel, fragmentami, aby nie wzbudzić podejrzeń.
Dzień 4, godzina 03:00 — Detonacja ransomware
W piątek o 3:00 w nocy — kiedy kampus jest pusty, a najbliższy dyżurny informatyk nie jest dostępny — atakujący uruchamiają payload ransomware na wszystkich kontrolowanych maszynach jednocześnie.
03:00-03:15: Ransomware rozprzestrzenia się błyskawicznie przez Active Directory, wykorzystując Group Policy Objects do dystrybucji na wszystkie stacje robocze i serwery w domenie. Proces szyfrowania rozpoczyna się od plików o najwyższej wartości — bazy danych, dokumenty, pliki badawcze — i postępuje ku mniej krytycznym zasobom.
03:15-03:30: Zaszyfrowane zostają serwery USOS, ERP, Moodle i poczty Exchange. Kopie zapasowe na serwerze backupowym — podłączonym do tej samej domeny — również zostają zaszyfrowane. Atakujący celowo zidentyfikowali i zniszczyli backupy jako priorytet.
03:30: Na pulpitach wszystkich komputerów pojawia się notatka z żądaniem okupu: 50 BTC (równowartość ok. 15 milionów złotych) za klucz deszyfrujący i gwarancję niepublikowania skradzionych danych. Termin: 7 dni. Po tym czasie cena podwaja się, a po 14 dniach dane trafiają na dark web.
04:00: System monitoringu serwerowni generuje alerty o niedostępności usług, ale trafiają one na zaszyfrowany serwer poczty. Jedynym sygnałem jest SMS z alertu monitoringu wysłany do kierownika IT, który o tej porze śpi.
06:30: Ochrona kampusu zgłasza, że system kontroli dostępu do budynków nie działa. To pierwszy widoczny objaw ataku.
Dzień 4 — Reakcja i chaos
07:00: Kierownik IT przyjeżdża na uczelnię i odkrywa skalę katastrofy. Wszystkie systemy są niedostępne. Na monitorach serwerowni widnieje żądanie okupu. Pierwsza reakcja: próba uruchomienia backupów — ale serwer backupowy jest zaszyfrowany.
07:30: Kierownik IT informuje prorektora ds. informatyzacji. Zwołane zostaje nadzwyczajne posiedzenie kolegium rektorskiego. Nikt nie wie, jakie dane wyciekły, jak szeroki jest zasięg ataku ani czy atakujący nadal mają dostęp do sieci.
08:00: Uczelnia kontaktuje się z CSIRT NASK — zgodnie z KSC ma 24 godziny na zgłoszenie incydentu w podmiocie publicznym. CSIRT NASK rekomenduje natychmiastowe odłączenie wszystkich systemów od internetu i wezwanie zespołu Incident Response.
09:00: Studenci odkrywają, że nie mogą zalogować się do Moodle, USOS ani poczty uczelnianej. W mediach społecznościowych zaczynają krążyć zdjęcia notatki z żądaniem okupu, zrobione przez pracowników na swoich telefonach. Lokalne media podchwytują temat.
10:00: Uczelnia angażuje zewnętrzną firmę cyberbezpieczeństwa do prowadzenia śledztwa forensycznego. Równocześnie rektor musi podjąć decyzję o komunikacji — ukrywanie incydentu nie ma sensu, bo studenci już wiedzą. Przygotowany zostaje oficjalny komunikat.
12:00: Dziekanaty nie mogą obsługiwać studentów — brak dostępu do danych, systemu ocen i dokumentacji. Egzaminy poprawkowe zaplanowane na przyszły tydzień są zagrożone. Administracja finansowa nie może realizować przelewów — w tym wypłat dla pracowników.
Gdzie obrona mogła zatrzymać atak — analiza punktów krytycznych
Analiza scenariusza ujawnia co najmniej sześć punktów, w których odpowiednie zabezpieczenia mogłyby zatrzymać lub znacząco ograniczyć atak.
Punkt 1 — Phishing (Dzień 1, 09:00): Wdrożenie DMARC z polityką reject dla domen uczelnianych, szkolenie awareness z symulacjami phishingowymi i zaawansowany filtr anty-phishingowy wykrywający nowo zarejestrowane domeny mogłyby zablokować początkowy wektor.
Punkt 2 — Wykonanie makra (Dzień 1, 10:30): Polityka blokowania makr w dokumentach z zewnętrznych źródeł (Attack Surface Reduction Rules w Windows), izolacja załączników w sandbox lub EDR wykrywający podejrzane zachowanie makra mogłyby zapobiec instalacji backdoora.
Punkt 3 — Eskalacja uprawnień (Dzień 1, 14:00): Regularne aktualizacje systemów (łatająca podatność CVE), usunięcie uprawnień administratora lokalnego ze standardowych kont pracowników i monitoring prób eskalacji uprawnień mogłyby zatrzymać lateral movement.
Punkt 4 — Ruch lateralny (Dzień 2): Prawidłowa segmentacja sieci uniemożliwiająca dostęp z sieci wydziałowej do systemów administracyjnych, monitoring NDR wykrywający anomalne wzorce ruchu sieciowego i ograniczenie protokołów (wyłączenie SMB, RDP poza wyznaczonymi stacjami).
Punkt 5 — Eksfiltracja danych (Dzień 3): Monitoring DLP wykrywający masowy transfer danych na zewnątrz, alerty na nietypowy ruch sieciowy w godzinach nocnych, ograniczenie dostępu do internetu z serwerów krytycznych.
Punkt 6 — Kopie zapasowe (Dzień 4): Backupy offline (air-gapped) lub immutable, niedostępne z domeny AD, regularne testowanie odtwarzania — to jedyna gwarancja możliwości odzyskania danych bez płacenia okupu.
Lekcje z scenariusza i rekomendacje
Ten scenariusz ilustruje kilka fundamentalnych lekcji dla uczelni wyższych planujących wzmocnienie cyberbezpieczeństwa.
Po pierwsze: atak nie zaczyna się od ransomware. Zaszyfrowanie danych to finał wielodniowej operacji, która rozpoczyna się od prostego phishingu. Inwestycja w prewencję phishingu — szkolenia, filtry, MFA odporne na phishing — jest wielokrotnie tańsza niż obsługa incydentu ransomware.
Po drugie: segmentacja sieci to nie luksus, lecz konieczność. Brak segmentacji pozwolił atakującym na przemieszczenie się z pojedynczej stacji roboczej do wszystkich krytycznych systemów uczelni. Prawidłowa segmentacja ogranicza zasięg ataku do jednego segmentu.
Po trzecie: kopie zapasowe muszą być odporne na ransomware. Backup podłączony do domeny AD jest tak samo podatny na zaszyfrowanie jak dane produkcyjne. Minimum to jedna kopia offline, testowana regularnie.
Po czwarte: plan reagowania na incydenty musi istnieć PRZED incydentem. Uczelnia w scenariuszu nie miała opracowanych procedur — decyzje podejmowano ad hoc, tracąc cenne godziny na ustalanie, kto za co odpowiada.
Po piąte: czas detencji (dwell time) wynoszący 3 dni to w rzeczywistości krótki okres — w sektorze edukacji średnia to ponad 45 dni. Aktywny monitoring i SOC (wewnętrzny lub zewnętrzny) pozwalają na wykrycie ataku przed fazą detonacji.
nFlo pomaga uczelniom wdrożyć wszystkie wymienione zabezpieczenia — od audytu bezpieczeństwa, przez segmentację sieci, monitoring SOC, po szkolenia i plany reagowania na incydenty. Skontaktuj się z nami, zanim scenariusz z tego artykułu stanie się rzeczywistością na Twojej uczelni.
Cyberbezpieczeństwo w Twojej branży
Dowiedz się więcej o cyberbezpieczeństwie w Twojej branży:
