Przejdź do treści
Infrastruktura

Atak Akira na firmę z Polski? Z logów dowiesz się więcej, niż myślisz

Nowe szczegóły operacji ransomware Akira pokazują, jak atakujący wykorzystują lokalne konta SSLVPN i brak podstawowej telemetrii. Większość śladów była widoczna w logach, które firma już posiadała.

4 min read
A dimly lit server room where tangled network cables form a web, and a single glowing keypad lock overlays a firewall device. A translucent shield floats above two separate streams of light (yellow and blue) converging into one bright beam, symbolizing the unification of log sources for threat detection.

Atak ransomware, który paraliżuje firmę, nie zaczyna się od szyfrowania. To ostatnie kilka procent długiego łańcucha zdarzeń. Nowa, szczegółowa analiza autorstwa badacza z SANS ISC opisuje cały przebieg włamania grupy Akira, opierając się wyłącznie na logach firewalla i systemu Windows – bez drogiego EDR. Wnioski są zaskakująco proste i pokazują, że wiele firm ma w swoich rękach narzędzia do wczesnego wykrycia zagrożenia, ale ich nie używa.

Opisany przypadek to średniej wielkości organizacja z pojedynczym lasem Active Directory i zaporą sieciową nowej generacji. Pracownicy zdalni łączyli się przez SSLVPN. Firma nie miała systemu EDR, a jedynie standardowe logi z firewalla oraz dzienniki zdarzeń Windows. To scenariusz bliższy polskim realiom niż idealny, w pełni monitorowany SOC.

Początek ataku: słabe hasło i brak uwierzytelniania wieloskładnikowego

Pierwszym sygnałem ostrzegawczym był wzorzec w logach uwierzytelniania SSLVPN. Przez 72 godziny poprzedzające szyfrowanie doszło do oczywistego ataku siłowego na jedno lokalne konto VPN. Jak wynika z analizy: „każda porażka pochodziła z jednego źródłowego adresu IP”, a udane logowanie nie wykazało żadnej pauzy – atakujący od razu uzyskał dostęp.

Konto, które padło ofiarą, było dezaktywowane w Active Directory, ale nadal aktywne w lokalnej bazie firewalla. Nie miało włączonego uwierzytelniania wieloskładnikowego (MFA). Jak podkreśla autor analizy: „konto dezaktywowane w AD, ale nie w firewallu, to najczęstszy wektor początkowego dostępu w tej klasie włamań”.

Eskalacja uprawnień i lateral movement widoczne w logach

Po dostaniu się do sieci atakujący wykonał standardowe czynności rozpoznawcze. Wszystko to było widoczne w zdarzeniach EID 4688 (tworzenie procesu): uruchomiono cmd.exe, nltest.exe (lista kontrolerów domeny), net.exe (wyszukiwanie grup uprzywilejowanych) oraz narzędzie przypominające AdFind.exe.

Około 24 godziny później na skoku host pojawiła się seria zdarzeń EID 4769 z szyfrowaniem RC4, w krótkim oknie czasowym. To klasyczny wzorzec ataku Kerberoasting, dzięki któremu przestępcy uzyskali hash haseł kont serwisowych. Jak zauważa badacz: „to najtańsza detekcja, jaką każda organizacja z AD może wdrożyć”.

Ruch lateralny odbywał się głównie przez RDP (zdarzenia EID 4624 z typem logowania 10). Atakujący dotarł do serwera plików, kontrolerów domeny i serwera kopii zapasowych. Ostatnim etapem przed szyfrowaniem było wyczyszczenie logów bezpieczeństwa (EID 1102), zatrzymanie ochrony antywirusowej oraz usunięcie cieni kopii zapasowych poleceniem vssadmin delete shadows /all /quiet.

Luka między źródłami danych, którą warto załatać

Kluczowym wnioskiem z analizy jest fakt, że logi z firewalla i dzienniki Windows dostarczały informacji o różnych etapach ataku. Osobno każdy zestaw był niepełny. Dopiero po ich połączeniu – według adresu IP i czasu – udało się zrekonstruować pełny łańcuch infekcji. Jak ujmuje to autor: „połączony widok zamienia dwa częściowe opisy w jeden pełny łańcuch ataku”.

W praktyce oznacza to, że administratorzy powinni zadbać o centralne gromadzenie logów z firewalla i kontrolerów domeny w jednym miejscu oraz o synchronizację czasu. Bez tego większość śladów ginie.

Konkretne działania, które można wdrożyć od zaraz

Analiza kończy się listą praktycznych zaleceń, które nie wymagają drogich narzędzi:

  • Inwentaryzacja lokalnych kont VPN – wymuś MFA i regularnie uzgadniaj je z Active Directory.
  • Alertowanie na dużą liczbę nieudanych logowań SSLVPN – np. 50 błędów z jednego źródła w ciągu godziny.
  • Włączenie audytu procesów (EID 4688) na wszystkich serwerach i ustawienie dziennika bezpieczeństwa na co najmniej 1 GB, aby uniknąć nadpisywania zdarzeń.
  • Detekcja Kerberoastingu – alert na żądania biletów RC4 dla wielu SPN z jednej stacji roboczej.
  • Monitorowanie czyszczenia logów (EID 1102) – każde takie zdarzenie powinno być natychmiast przekazane do zespołu bezpieczeństwa.
  • Audyt poleceń vssadmin i wmic – ich wykonanie poza planowanym backupem to niemal pewny znak przygotowań do ataku ransomware.

Przedstawiona przez SANS ISC analiza dowodzi, że nawet bez kosztownego EDR można skutecznie wykryć zaawansowane ataki. Warunkiem jest odpowiednie skonfigurowanie istniejących źródeł logów i ich połączenie. Dla każdej firmy, która chce podnieść poziom bezpieczeństwa, to jeden z najbardziej opłacalnych kierunków inwestycji.

Redakcja sekuret.pl

Redakcja sekuret.pl

AUTHOR