Atak ransomware Akira krok po kroku. Jak połączyć logi firewall i Windows, by go powstrzymać?

Nowa analiza ataku ransomware Akira pokazuje, że klucz do obrony leży w połączeniu logów z firewalla i systemu Windows. Administratorzy mogą wykryć włamanie na długo przed szyfrowaniem plików – pod warunkiem, że wiedzą, czego szukać.

Dlaczego większość firm nie widzi ataku na czas?

Większość analiz ransomware skupia się na notatkach okupu lub samym procesie szyfrowania. Jak zauważa Manuel Humberto Santander Pelaez z SANS ISC, „do czasu, gdy pojawią się te sygnały, najciekawsza praca kryminalistyczna jest już zakończona”. Prawdziwe pytania dla obrońców brzmią: jak napastnicy weszli, kiedy uzyskali uprawnienia administratora domeny i co robili przed uruchomieniem ransomware. Odpowiedzi kryją się w logach z firewalla obwodowego i kanałach zdarzeń Windows – dwóch źródłach, które rzadko są ze sobą łączone.

W opisywanym przypadku środowisko stanowił pojedynczy las Active Directory za nowoczesnym firewallem nowej generacji. Do analizy wykorzystano wyłącznie syslog z firewalla (okres siedmiu dni przed szyfrowaniem) oraz eksporty EVTX z kontrolerów domeny i trzech serwerów członkowskich. Bez EDR, bez przechwytywania pamięci, bez logów proxy. To typowy punkt wyjścia dla wielu małych i średnich organizacji.

Etap 1: dostęp początkowy – brute force na koncie SSLVPN

Pierwszy sygnał pochodził z logów uwierzytelniania firewalla. Filtrując zdarzenia SSLVPN z 72 godzin przed szyfrowaniem, badacze natknęli się na wyraźny wzorzec brute force. Atak wymierzony był w jedno lokalne konto SSLVPN, które – jak potwierdził klient – zostało wyłączone w Active Directory, ale pozostało aktywne jako lokalny użytkownik firewalla. Każda nieudana próba pochodziła z jednego adresu IP w zakresie dostawcy hostingu. Po udanym uwierzytelnieniu napastnik nie czekał – wszedł od razu. To cecha charakterystyczna ataku typu credential stuffing. Konto nie miało włączonego MFA, a hasło przetrwało sześciogodzinny atak online.

Etap 2 i 3: odkrywanie i kradzież poświadczeń

Po wejściu do sieci przez VPN napastnik uzyskał dostęp do sieci VLAN użytkowników. Kluczowym dowodem było połączenie logów NAT firewalla z kanałem Security systemu Windows. Pierwsze zdarzenia wewnętrzne to logowania EID 4624 z adresu IP przypisanego przez VPN na serwer przesiadkowy (jump host). Następnie, w zdarzeniach EID 4688 (tworzenie procesów), pojawiły się polecenia: nltest /dclist:, net group „Domain Admins” /domain, whoami /all oraz uruchomienie zmienionego pliku o zachowaniu AdFind. Około 24 godziny później zarejestrowano serię zdarzeń EID 4769 (żądania TGS) dla trzech kont serwisowych – wszystkie z szyfrowaniem RC4, z tego samego jump hosta, w ciągu 90 sekund. To klasyczny wzorzec Kerberoastingu, jeden z najtańszych do wykrycia w każdej organizacji z Active Directory.

Etap 4: ruch boczny i eskalacja uprawnień

Ruch boczny trwał dwa dni i opierał się prawie wyłącznie na RDP. Wzorzec EID 4624 Logon Type 10 (logowanie zdalne) wskazywał na udane połączenia z jump hosta do serwera plików, obu kontrolerów domeny i serwera kopii zapasowych. Po każdym logowaniu do kontrolera domeny pojawiał się EID 4672 (przydzielenie specjalnych uprawnień). Napastnik utworzył nowe konto w niestandardowej jednostce OU i dodał je do grupy wbudowanej przy użyciu dobrze znanego SID – to sygnał, że działał za pomocą skryptów, a nie interaktywnie. Kilka sesji PowerShell używało flagi -EncodedCommand; po dekodowaniu okazało się, że zawierały rozpoznanie infrastruktury kopii zapasowych i stanu kopii w tle. To bezpośrednie przygotowanie do etapu szyfrowania.

Etap 5 i 6: zacieranie śladów i szyfrowanie

Ostatnie 12 godzin to szybka sekwencja: wyczyszczenie dziennika Security na jump hoście (EID 1102), zatrzymanie usług ochrony endpointów za pomocą sc.exe i net stop (EID 7036), a następnie wykonanie vssadmin delete shadows /all /quiet na wszystkich dostępnych hostach. Szyfrowanie nastąpiło w ciągu kilku minut. Jak podkreśla autor analizy, „zdarzenie szyfrowania to zaledwie około 5% całkowitego czasu przebywania napastnika w sieci. Pozostałe 95% to okno dla obrońców”. Prawie cała ta aktywność była widoczna w logach, które klient już posiadał.

Co łączenie logów zmienia w praktyce?

Większość zespołów IT traktuje logi firewalla i logi zdarzeń Windows jako osobne problemy, obsługiwane przez różne osoby. W tym przypadku każdy etap ataku był widoczny z wysoką pewnością tylko w jednym z tych źródeł. Analityk pracujący wyłącznie na syslogu firewalla wychwyciłby brute force i udane logowanie – nic więcej. Analityk pracujący tylko na EVTX zobaczyłby anomalię wewnętrzną, ale bez punktu zaczepienia wskazującego wejście. Połączenie obu widoków daje pełny łańcuch ataku. Kluczowym polem łączącym jest źródłowy adres IP, a osią – znormalizowany czas. Samo połączenie jest trywialne, ale wymaga odpowiedniego czasu retencji logów i synchronizacji zegarów.

Praktyczne zalecenia dla administratorów

• Lokalne konta SSLVPN – zinwentaryzuj je, wymuś MFA i uzgodnij z katalogiem głównym. Konto wyłączone w AD, ale wciąż aktywne w firewallu, to najczęstsza droga wejścia w tej klasie ataków.
• Progi nieudanych uwierzytelnień – alertuj przy więcej niż 50 nieudanych logowaniach SSLVPN z jednego źródła w ciągu godziny. W opisywanym przypadku próg zostałby przekroczony w 30 minut.
• Audyt procesów EID 4688 – włącz na każdym hoście Windows. Ustaw rozmiar dziennika Security na co najmniej 1 GB. Domyślne rozmiary powodują, że aktywność odkrywania znika, zanim responderzy zdążą zareagować.
• Detekcja Kerberoastingu – alertuj na żądania TGS z szyfrowaniem RC4 dla wielu SPN w krótkim oknie czasowym z jednej stacji roboczej. To najtańsza detekcja tego ataku.
• Wyczyszczenie dziennika Security (EID 1102) – każde wystąpienie jest incydentem. Przekaż to zdarzenie poza host przed wszystkim innym.
• Audyt poleceń vssadmin i wmic shadowcopy – alertuj na każde wykonanie. Uzasadnione użycie jest rzadkie.

Szczegółowy opis całego łańcucha ataku wraz z diagramami dostępny jest w analizie SANS ISC. Warto przestudiować go, by lepiej zrozumieć, jak wygląda rzeczywisty atak ransomware i jak przygotować środowisko na podobne zdarzenia.

Najważniejszy wniosek: nie czekaj na notatkę okupu. Zainwestuj w retencję logów i naucz się łączyć sygnały z firewalla i systemu Windows. To może uratować twoją organizację przed kosztownym przestojem.