Każdego dnia analitycy zespołu SOC360 przechodzą przez setki zgłoszeń pochodzących z systemów klientów lub przekazywanych bezpośrednio przez pracowników organizacji. Musimy mierzyć się z nowymi technikami i taktykami, mającymi na celu jak najskuteczniejszą ingerencję w systemy informatyczne klientów.

Od lat atakujący przykładają dużą uwagę do omijania mechanizmów narzędzi bezpieczeństwa. Objawia się to zarówno w wieloetapowości ataków, obfuskacji kodu, wykorzystywania procesów i stron tzw. Living of the Land (LOL) czy eksfiltracji danych za pomocą narzędzi administratorskich. Do tego należy pamiętać o AI, które zmniejsza próg wejścia dla atakujących poprzez wsparcie w pisaniu odpowiedniego oprogramowania czy przygotowywaniu wiadomości oraz stron phishingowych.

Analiza tego typu aktywności staje się coraz trudniejsza i wymaga nie tylko odpowiednich narzędzi, ale też doświadczonych, świadomych inżynierów potrafiących wykorzystać możliwości systemów. Skuteczna i szczegółowa analiza nierzadko wychodzi poza narzędzia bezpieczeństwa będące źródłem detekcji a celem jest nie tylko stwierdzenie czy coś jest złośliwe czy nie (to często jest prostym zadaniem), ale przede wszystkim do czego doszło w trakcie ataku i jakie kroki należy podjąć dalej.

Nowoczesne zagrożenie: stealery w przeglądarkach

Każdemu specjaliście cyberbezpieczeństwa muszą być doskonale znane tzw. stealer’y: czyli złośliwy kod (w formie skryptu lub pliku wykonywalnego) mający na celu wykradanie danych wrażliwych z zainfekowanego hosta ofiary.

W świecie zespołu SOC360 trudno znaleźć dni, w których nie analizujemy tego typu malware’u. Najczęściej są to stealer’y dystrybuowane w formie SaaS (Stealer as a Service) takie jak LummaC2 (mająca w ostatnim czasie pewne trudności z infrastrukturą) czy Rhadamanthys. Złośliwy aktor wykupuje dostęp do infrastruktury chmurowej pozwalającej na wygenerowanie złośliwego kodu i zarządzanie danymi uzyskanymi w ramach prowadzonej aktywności. Funkcjonalność standardowego stealer’a obejmuje m.in.:

• enumerację informacji systemowych,
• wykradanie danych zapisanych w przeglądarkach internetowych,
• wykradanie ciasteczek i tokenów sesji,
• wykonywanie zrzutów ekranów,
• wykradanie danych portfeli kryptowalutowych,
• dostęp do schowka,
• wysyłanie zdobytych danych na serwery C2 (np. chmura LummaC2, Telegram API, Google Calendar).

Środowisko cyberprzestępczości i cyberbezpieczeństwa działa zgodnie z hipotezą Czerwonej Królowej. Jest to wyścig zbrojeń między analitykami i przestępcami, który napędza zarówno opracowywanie nowych technik i taktyk wykorzystywanych przez złośliwych aktorów jak i ulepszanie procesów stosowanych po stronie inżynierów zajmujących się bezpieczeństwem.

Przykładem interesującej wariacji stealer’ów pozwalającej na jeszcze lepsze przechodzenie pod radarem i kompleksowe wykradanie danych jest złośliwe oprogramowanie pod postacią fałszywej wtyczki do przeglądarek internetowych imitującej legalne oprogramowanie. Jest to forma ataku, która wymusza nieszablonowe podejście zarówno do analizy jak i rekomendacji krótko i długoterminowych.

Standardowa analiza zaczyna się w systemie bezpieczeństwa, najczęściej klasy EDR, pozwalającym na potencjalne wykrywanie około 80% technik i taktyk zdefiniowanych w matrycy MITRE ATT&CK®. W przypadku analizy tego stealer’a wstępne oględziny nie dały jednak jednoznacznych rezultatów. Miało to miejsce z kilku powodów:

1. Instalator wypakowany przez użytkownika z archiwum za pomocą WinRAR oraz pliki poboczne oznaczone były przez źródła CTI jako bezpieczne lub nie były rozpoznawane
2. Instalator faktycznie instalował na hoście aplikację (o enigmatycznie brzmiącej nazwie Heizer Kroop nierozpoznawanej przez Google)
3. Indykatory automatycznie przypisane przez system klasy EDR nie wskazywały jednoznacznie na funkcjonalność i cel oprogramowania

System klasy EDR, zbierający szczegółową telemetrię z hosta, pozwolił na dokładną weryfikację działań użytkownika przed pobraniem złośliwego pliku. Jak się okazało, użytkownik był zdeterminowany do pozyskania oprogramowania związanego z miksowaniem muzyki bez płacenia za licencję.

Tego typu działania stosunkowo często zaprowadzają użytkowników na strony, gdzie, oprócz pożądanej aplikacji, na komputer ofiary trafia złośliwy kod. Tak było i w tym przypadku, gdzie na jednej ze stron odwiedzonych wcześniej przez nieświadomego użytkownika zajmującej się hostowaniem plików ukazał się komunikat o naruszeniu zasad portalu.

Również drzewo procesów uzupełniające kontekst potencjalnie podejrzanego pliku sugerowało konieczność dalszej analizy. Oprócz instalacji oprogramowania i wykorzystania skryptów oznaczonych przez źródła CTI jako bezpieczne zauważyć można było zobfuskowaną, uruchomioną bez wyświetlenia okna komendę PowerShell.

Taki kod musi być dla każdego analityka czerwonym alarmem i wymaga szczegółowej weryfikacji. W tym przypadku szybko okazało się, że jest to pierwszy z wielu etapów mających na celu doprowadzenie po cichu do wywołania na hoście złośliwej aktywności. Standardowa analiza obejmuje deobfuskację, m.in. dekodowanie z Base64.

W tym momencie ktoś mógłby zasugerować wykorzystanie sztucznej inteligencji do pomocy przy deobfuskacji kodu. Jest to stwierdzenie, z którym mogę zgodzić się połowicznie.

Faktycznie, dla osoby, która wie czego można oczekiwać po kolejnych etapach (tzw. stage’ach) może być to ułatwienie w uzyskaniu danych z kodu – np. adres URL, ścieżka do zapisu pliku etc. Kluczowe jest także zrozumienie tzw. promptingu czyli stworzenie odpowiedniego zapytania, tak aby sztuczna inteligencja nie wymyśliła nam różnych dziwnych nieprawdziwych stwierdzeń.

W tym przypadku deobfuskacja kodu z pomocą LLM nie pozwoliła na uzyskanie kolejnych etapów ataku – ze skryptu wyciągnięta została domena lokalizacji kolejnego stage’a, lecz nie pełen URI. Bez pełnego URI nie można pobrać kolejnego pliku a tym samym analiza funkcjonalności nie może się odbyć. Jest to kolejny z wielu przykładów na to, że (przynajmniej na tym etapie) AI to pomoc dla specjalistów, a nie ich zamiennik.

W przypadku opisywanego ataku mieliśmy do czynienia z 4 kolejnymi etapami, dociąganymi, ładowanymi i uruchamianymi w pamięci jednego procesu PowerShell. Każdy z etapów składał się ze złożonego, zobfuskowango kodu mającego na celu zmylić zarówno systemy bezpieczeństwa jak i samych analityków. Ponieważ w tym przypadku mieliśmy do czynienia ze skryptem a nie skompilowanym kodem, najprostszym rozwiązaniem było przechodzenie przez kod linijka po linijce i weryfikowanie zadeklarowanych zmiennych i wywoływanych na nich funkcji.

W tym przypadku ostatni stage był stosunkowo łatwy do zauważenia. Charakterystyczna i odmienna była zarówno jego długość jak i sama struktura i złożoność kodu (złożone definicje funkcji, długie tablice).

Dobrą praktyką w takiej sytuacji jest zweryfikowanie metadanych ostatecznego pliku w źródłach CTI oraz uruchomienie go niezależnie w dostępnych narzędziach typu sandbox (oczywiście pod warunkiem, że spodziewamy się, że kod nie jest zależny od poprzednich stage’y). Atakujący dynamicznie rotują plikami i infrastrukturą natomiast ostatni stage, w szczególności taki uruchamiany w pamięci procesu a nie zapisywany na dysku, potrafi się powtarzać a tagi czy zależności zdefiniowane w źródłach CTI pozwalają uwydatnić funkcjonalność aplikacji.

W tym przypadku metadane nie dały rezultatów, a dostępne narzędzia typu sandbox informowały jedynie o tagu – stealer. Tego już się oczywiście spodziewaliśmy natomiast nie wyczerpało to puli potrzebnych informacji.

Szczegółowa analiza kodu ostatniego stage’a rzuciła na zdarzenie nieco inne światło. Wśród wielu linijek zobfuskowanego i często bezsensownego kodu znaleźć można było pewne unikalne cechy.

• Po pierwsze, weryfikowana była obecność na hoście 4 popularnych przeglądarek internetowych.

• Po drugie, zaciągane i modyfikowane były pliki konfiguracyjne przeglądarek znalezionych na maszynie.

• Po trzecie, po odkodowaniu jednej ze zmiennych zauważyć można było konfigurację samodzielnie stworzonej wtyczki.

Dodatkowo, w jednej z tablic znajdowało się niemalże 100 par – nazwa oraz treść pliku. Były to obrazki, pliki json oraz przede wszystkim zobfuskowany i złożony kod w JavaScript, zapisywane w nowoutworzonym folderze w AppData/Local.

Analiza pliku konfiguracyjnego wtyczki, a także utworzone obrazki wskazały na podszywanie się wtyczki pod zapisywanie do Google Drive. Wtyczka miała nadane maksymalne uprawnienia (dostęp do historii, zapisanych haseł, ciasteczek, wszystkich otwartych stron). Widoczne były także skrypty uruchamiane każdorazowo przy uruchomieniu przeglądarki oraz skrypty szczegółowe – ładowane jedynie, jeśli spełnione były odpowiednie warunki np. wejście na adresy z domeny Outlooka lub Gmaila.

Stealer w takiej formie jest o tyle interesujący, że wymagane jest przygotowanie odpowiednich zaleceń i unikalne zaadresowanie problemu. Samo usunięcie plików instalacyjnych i skryptów, a nawet restart haseł i revoke sesji nie wystarczy. Gdy tylko użytkownik użyje nowych poświadczeń w skompromitowanej przeglądarce, złośliwa wtyczka prześle je na serwer C2. I tak każdorazowo, dopóki nie pozbędziemy się wtyczki.

Techniki atakujących: jak pozostać niewidocznym?

W trakcie analizy incydentu z utworzeniem i dodaniem złośliwej wtyczki do przeglądarek pojawiło się kilka technik i taktyk, na które chciałbym poświęcić nieco większą część artykułu. Przede wszystkim dlatego, że nie są unikalne dla tego zdarzenia a są chlebem powszednim dla specjalistów cyberbezpieczeństwa.

Atakujący bardzo często rotują infrastrukturę. Zarówno domeny, adresy IP jak i sumy kontrole złośliwych plików wystawionych do pobrania zmieniają się na tyle dynamicznie, że weryfikacja w źródłach CTI coraz rzadziej pozwala dać jednoznaczne rezultaty.

Analizę utrudnia również popularność tzw. narzędzi LOL, czyli Living-of-the-Land. Obejmują one nie tylko systemowe procesy pozwalające na pobranie i uruchomienie pliku bez uruchamiania podejrzanych procesów, ale także popularne strony internetowe, narzędzia administratorskie i zdalnego dostępu czy protokoły pozwalające na komunikację C2. Przykładowo, mówimy o pobieraniu i uruchamianiu plików za pomocą mshta.exe lub bitsadmin.exe wystawionych na github’ie, Google Docsach czy dropboxie. Pełen wykaz dostępy jest w projekcie „Living Off the Living Off the Land”.

Same ataki są wieloetapowe. Zdarza się spotykać nawet 4 czy 5 kolejnych tzw. stage’y. Pierwszy skrypt najczęściej jest prostą, krótką komendą mającą na celu pobieranie kolejnych skryptów zapisywanych i uruchamianych w pamięci procesu. Kolejny skrypty również mogą nie być złośliwe i w skomplikowany sposób mają za zadanie prowadzić do kolejnych i kolejnych zasobów przygotowanych przez atakujących.

Jeśli dołożymy do tego obfuskację kodu w formie kodowania, szyfracji, skomplikowanych operacji, funkcji bez faktycznej funkcjonalności i wielu innych to analiza zarówno dla analityka jak systemu bezpieczeństwa staje się niemałą zagwozdką. Potrzebne są do tego nie tylko odpowiednie systemy, ale i świadomi, doświadczeni inżynierowie.

Dlaczego EDR jest niezbędny w analizie?

W przypadku wieloetapowych, zobfuskowanych i nieznanych źródłom ścieżkach ataku najważniejszym narzędziem w rękach analityka jest dobry system klasy EDR/XDR zbierający pełną telemetrię z monitorowanego hosta. Sam w sobie nie jest wystarczający do zapewnienia pełnego bezpieczeństwa organizacji, ale na pewno jest najlepszym punktem wyjściowym. W przypadku ścieżki ataku opisywanej w artykule pozwolił na uzupełnienie kontekstu kluczowego w zrozumieniu zaistniałej sytuacji.

Po pierwsze, dysponujemy drzewem procesów dokładnie pokazującym procesy i komendy uruchamiane przez użytkownika. Dzięki rejestracji zapytań DNS i podglądu URL odwiedzanych przez użytkownika dowiedzieć się można, jak wyglądały pierwsze momenty ataku. Jeśli widzimy, że użytkownik usilnie pobiera oprogramowanie i pliki z niezweryfikowanych źródeł możemy nie tylko potwierdzić czy w oknie czasowym działo się coś więcej, ale także przygotować potencjalne dodatkowe zalecenia np. przestrzegające przed korzystaniem z tego typu źródeł.

Dodatkowo, gdyby nie telemetria rejestrująca dokładne wywołanie komend nie dowiedzielibyśmy się o pojedynczym procesie PowerShell, który nie zapisywał żadnych dodatkowych plików i nie instalował dodatkowego oprogramowania.

Możliwości systemu EDR pozwalają na weryfikację zachowania przed, w trakcie i po wystąpieniu podejrzanej aktywności - nie tylko na jednym hoście, ale na wszystkich w organizacji. Możliwości przeglądania atomowych zdarzeń związanych z procesami, wywoływanymi skryptami, połączeniami sieciowymi, zmianami w rejestrach czy zapytaniami DNS to dla analityka dostęp do najcenniejszych artefaktów dających możliwość szczegółowego opisania całej historii związanej ze zdarzeniem. Wszystkie te działania są potrzebne do przygotowania adekwatnych rekomendacji dla użytkownika i samej organizacji.

Dalsza analiza kodu poza systemem była jedyną ścieżką pozwalająca na zweryfikowanie nie tylko, że coś się wydarzyło, ale przede wszystkim co dokładnie się wydarzyło. Po zweryfikowaniu kodu w środowisku laboratoryjnym mamy możliwość sprawdzenia czy na tym lub na innych hostach widoczna jest podobna, niepokojąca aktywność.

Weryfikacja zainstalowanych aplikacji i działania remediacyjne np. w formie poddania plików kwarantannie lub odizolowania hosta od sieci to dodatkowe walory często wykorzystywane przez zespoły bezpieczeństwa.

Czynnik ludzki, czyli rola analityka w wykrywaniu ataków

Ostatnim, kluczowym elementem prowadzenia skutecznych analiz są ludzie. Systemy EDR, jakkolwiek wygodne i szybkie NIE DZIAŁAJĄ SAME. Zarówno polityki wymuszające automatyczne blokowanie procesów jak i zgłoszenia nie będące automatycznie blokowane wymagają czynnika ludzkiego, który zweryfikuje i przeanalizuje zgłoszenia lub dostroi systemy pod względem ilości i typów fałszywych alarmów.

W przypadku zdarzeń dotyczących np. stealer’ów kluczowe jest szybkie podjęcie analizy, w tym w niestandardowych godzinach – nocnych, weekendowych lub świątecznych. Zadaniem analityka jest nie tylko sprawdzenie historii potencjalnie złośliwego pliku, ale także podjęcie reakcji np. w formie odizolowania hosta od sieci.

Skuteczna analiza obejmuję komunikację z odpowiednimi osobami po stronie organizacji (lub klienta w przypadku zewnętrznych zespołów SOC) a także przygotowanie zaleceń na poziomie operacyjnym i strategicznym. Te pierwsze mogą obejmować reset haseł czy przywrócenie hosta do stanu fabrycznego, te drugie np. edukację użytkowników o dobrych praktykach korzystaniu z Internetu w sposób bezpieczny zarówno dla nich jak i organizacji.

Dobry analityk powinien dysponować zarówno doświadczeniem, tak aby skutecznie wychwytywać punkty zaczepienia, które na pierwszy rzut oka nie są oczywiste a także sporym zasobem wiedzy. Nie tylko dotyczącej samego systemu np. klasy EDR/XDR, z którym pracuje, ale też jak wykorzystywać narzędzia zewnętrzne, środowiska laboratoryjne, analizę kodu, korzystanie ze źródeł CTI i wiele więcej.

Dobry analityk jednocześnie powinien wiedzieć czego szuka, a z drugiej strony mieć świadomość o potencjalnych nowych technikach i taktykach wymagających uwagi, z którymi wcześniej mógł się nie spotkać. Jest to wymagające i czasochłonne zadanie.

Podsumowanie

Przykład analizy zagrożenia krótko opisanego w powyższym artykule pokazuje, że atakujący cały czas tworzą nowe, coraz skuteczniejsze sposoby na obchodzenie zarówno systemów bezpieczeństwa jak i samym inżynierów bezpieczeństwa. Do ich wyczerpującej analizy musimy pamiętać o dwóch bardzo ważnych kwestiach.

Bez dobrego systemu bezpieczeństwa, w szczególności systemu klasy EDR/XDR zbierającego pełną telemetrię z hosta, jesteśmy ślepi na współczesne zagrożenia. Potrzebujemy dokładnych danych i zaawansowanych mechanizmów detekcji, żeby móc choć spróbować wykryć nowoczesny malwar’e, np. stealer’y. Wykorzystanie Living-of-the-Land, rotacja IOC, obsfuskacja czy wieloetapowość to jedne z wielu przykładów zaawansowanych technik i taktyk, którymi dysponują cyberprzestępcy.

Do tego potrzebujemy świadomego analityka. Inżyniera, który zna nie tylko sam system bezpieczeństwa, ale przede wszystkim filozofię i specyfikę ekosystemu, które stoją za działaniami cyberprzestępców. Tylko takie połączenie pozwala na wykrywanie potencjalnych incydentów bezpieczeństwa, a następnie na ich szczegółową analizę mogącą zakończyć się adekwatnymi zaleceniami. A o to w tym wszystkim chodzi – aby na samym końcu działania podjęte przez organizację zapewniły ciągłość jej funkcjonowania bez strat finansowych i refutacyjnych.

Jeśli interesuje Cię zwiększenie ochrony Twojej firmy - napisz do nas.

Artykuł został w całości przygotowany przez eksperta cybersecurity – bez wsparcia narzędzi sztucznej inteligencji.