Armored Likho: phishing z BusySnake i loaderami AI

TL;DR

Kaspersky opisał aktywną kampanię przypisaną z umiarkowaną pewnością grupie Armored Likho. Ataki były wymierzone głównie w administrację publiczną i sektor elektroenergetyczny w Rosji, Kazachstanie oraz Brazylii. Początek łańcucha stanowił ukierunkowany e-mail z archiwum zawierającym plik EXE albo skrót LNK dopasowany nazwą do pretekstu wiadomości.

Po uruchomieniu załącznika ofiara widziała pozornie właściwy materiał: formularz testu psychologicznego, wniosek o pomoc humanitarną albo dokument dotyczący zobowiązań. Równolegle uruchamiany był kod pobierający kolejne składniki i przygotowujący środowisko dla BusySnake Stealer. Wyświetlenie oczekiwanego dokumentu nie potwierdzało więc bezpieczeństwa pliku, lecz maskowało działanie w tle.

Badacze uznali, że loadery i stagery pierwszego etapu prawdopodobnie powstały ze wsparciem modeli językowych. Wskazali na nietypowo rozbudowane komentarze i charakterystyczny styl kodu. Nie oznacza to jednak, że cały zestaw narzędzi grupy został automatycznie wygenerowany przez AI. To ważne rozróżnienie zarówno dla oceny ryzyka, jak i dla komunikacji wewnętrznej.

Dla organizacji najcenniejszy jest nie sam przydomek grupy, ale powtarzalny mechanizm: wiarygodny temat, archiwum, plik wymagający działania użytkownika, dokument-przynęta oraz pobranie kolejnych elementów. Każdy z tych etapów daje możliwość zatrzymania ataku.

Czym jest kampania Armored Likho

Armored Likho to nazwa nadana przez Kaspersky klastrowi aktywności kojarzonemu na podstawie pośrednich przesłanek z grupą Eagle Werewolf. Badacze przypisali opisywaną kampanię z umiarkowaną pewnością, dlatego nie należy przedstawiać tej atrybucji jako bezspornego ustalenia.

Według analizy grupa łączy operacje finansowe wymierzone w osoby prywatne z ukierunkowanym cyberszpiegostwem wobec organizacji. W badanej kampanii potwierdzone ofiary znajdowały się w Rosji, Kazachstanie i Brazylii. Szczególnym celem były instytucje publiczne oraz podmioty związane z energią elektryczną.

Taki wybór odbiorców wpływa na treść wiadomości. Zamiast ogólnego komunikatu o paczce atakujący wykorzystywali motywy oficjalnych zawiadomień, programów społecznych, pomocy humanitarnej albo dokumentów administracyjnych. Pretekst miał pasować do obowiązków osoby, która otrzymała e-mail.

Spear phishing różni się od kampanii masowej stopniem dopasowania. Wiadomość może odnosić się do stanowiska, instytucji, aktualnego projektu albo rodzaju dokumentów obsługiwanych przez odbiorcę. Więcej o podstawowym mechanizmie wyjaśniamy w artykule co to jest phishing.

Jak działał łańcuch z załącznikiem EXE

W jednym wariancie archiwum zawierało samorozpakowujący się plik EXE. Po jego otwarciu wyświetlany był fałszywy test psychologiczny. Ten element spełniał funkcję przynęty: użytkownik otrzymywał treść zgodną z tematem e-maila i mógł uznać, że nic podejrzanego się nie wydarzyło.

W tle dropper uruchamiał kolejne składniki. Analiza Kaspersky opisuje wykorzystanie legalnego procesu jako osłony dla loadera, pobranie pakietów z repozytoriów GitHub oraz przygotowanie lokalnego środowiska Pythona. Następnie instalowane były zależności potrzebne do uruchomienia głównego modułu.

Atak nie kończył się po jednorazowym wykonaniu. Komponenty tworzyły zadanie harmonogramu, dzięki któremu BusySnake mógł być uruchamiany ponownie. Dla zespołu SOC istotne są więc nie tylko sam e-mail i hash załącznika, ale również sekwencja procesów, pobrania plików, zapis w profilu użytkownika oraz utworzenie zadania systemowego.

Jak działał wariant ze skrótem LNK

Drugi wariant wykorzystywał skrót Windows umieszczony w archiwum. Nazwa pliku odpowiadała treści przynęty, na przykład wnioskowi o pomoc. Skrót LNK może wyglądać jak dokument, ale technicznie potrafi uruchomić polecenie, program albo skrypt.

Po otwarciu złośliwego skrótu uruchamiane było ukryte lub zaciemnione polecenie prowadzące do PowerShella. Następnie pobierany był loader oraz prawdziwie wyglądający dokument DOCX. Użytkownik widział formularz lub zaświadczenie, podczas gdy system przygotowywał kolejne etapy infekcji.

To ten sam wzorzec decyzyjny, który pojawia się w innych ukierunkowanych kampaniach: prawdziwy lub wiarygodny dokument zostaje użyty jako zasłona dla szkodliwego działania. Podobny problem opisaliśmy przy Operation GriefLure, gdzie dokument i skrót LNK prowadziły do zdalnego dostępu.

Co potrafi BusySnake Stealer

BusySnake jest narzędziem napisanym w Pythonie i przeznaczonym dla systemów Windows. Badacze opisali kilka wersji oraz osobny moduł służący do pozyskiwania ciasteczek przeglądarki. Kod był zaciemniony, co miało utrudnić analizę statyczną i wykrycie jego funkcji.

Zakres możliwości obejmował zbieranie danych ze schowka, inwentaryzowanie plików, wysyłanie dokumentów, wykonywanie zrzutów ekranu oraz oczekiwanie na zadania z infrastruktury dowodzenia. Analiza wskazuje też na kradzież haseł i ciasteczek z Firefoksa oraz przeglądarek opartych na Chromium.

Ciasteczko sesyjne może mieć znaczenie porównywalne z hasłem. Jeżeli serwis akceptuje aktywną sesję, napastnik może próbować uzyskać dostęp bez ponownego przechodzenia całego logowania. Dlatego reakcja na infekcję nie może ograniczać się do zmiany jednego hasła. Potrzebne jest unieważnienie sesji, przegląd urządzeń i kontrola aktywności kont.

BusySnake miał również funkcje zdalnego wykonywania zadań i tunelowania połączeń. Daje to operatorom możliwość dostosowania dalszych działań do roli ofiary oraz wartości przejętego urządzenia. Komputer pracownika może stać się źródłem dokumentów, punktem wejścia do sieci albo narzędziem do dalszego rozpoznania.

Co oznacza informacja o użyciu AI

Najbardziej nośny element tej kampanii dotyczy kodu pierwszego etapu. Kaspersky wskazał, że rozbudowane komentarze, powtarzalne bloki i punktory przypominające emoji były nietypowe dla ręcznie przygotowywanego malware. Na tej podstawie badacze uznali, że loadery prawdopodobnie zostały wygenerowane z pomocą dużego modelu językowego.

Jest to ocena analityczna oparta na cechach kodu, a nie ujawniony zapis rozmowy operatora z konkretnym modelem. Nie znamy też udziału człowieka w poprawianiu, testowaniu i wdrażaniu tych komponentów. Precyzyjne sformułowanie brzmi więc: badacze znaleźli przesłanki użycia AI przy payloadach pierwszego etapu.

Z punktu widzenia obrony pochodzenie kodu jest mniej ważne niż zachowanie. Loader nadal uruchamia procesy, pobiera pliki, zapisuje składniki, kontaktuje się z infrastrukturą zewnętrzną i przygotowuje wykonanie następnego etapu. Kontrole behawioralne mogą wykrywać te działania niezależnie od tego, czy kod napisał człowiek, model czy oba te źródła razem.

AI może natomiast skrócić czas przygotowania wariantów i ułatwić tworzenie prostych komponentów pomocniczych. Zespół bezpieczeństwa powinien zakładać większą zmienność plików, ale nie rezygnować z analizy całego łańcucha zdarzeń.

Dlaczego dokument-przynęta obniża podejrzliwość

Pracownik często ocenia wynik po tym, co pojawiło się na ekranie. Jeżeli otworzył załącznik i zobaczył oczekiwany formularz, może uznać proces za poprawny. W opisywanej kampanii właśnie ten moment był wykorzystywany do ukrycia działania loadera.

Bezpieczna ocena nie powinna opierać się na samym wyglądzie dokumentu. Liczy się pochodzenie wiadomości, typ pliku, obecność archiwum i zgodność kanału z procedurą organizacji. Instytucja publiczna może otrzymywać prawdziwe wnioski, lecz powinna określić, jakie formaty są dopuszczalne i jak weryfikuje pliki wykonywalne, skróty oraz archiwa chronione hasłem.

Dla odbiorcy prostym punktem zatrzymania jest pytanie: czy do wykonania zadania rzeczywiście potrzebne jest uruchomienie EXE lub LNK przesłanego e-mailem? Jeżeli nie, wiadomość należy przekazać do weryfikacji, a nie sprawdzać na własnym komputerze.

Jak ograniczyć ryzyko w administracji i sektorze energii

Organizacje obsługujące dużą liczbę dokumentów zewnętrznych potrzebują zasad, które nie blokują pracy, ale oddzielają materiały biurowe od plików zdolnych uruchamiać kod. Bramka pocztowa może odrzucać lub kierować do kwarantanny archiwa zawierające EXE, LNK, skrypty oraz nietypowe kombinacje rozszerzeń.

Na stacji roboczej pomocne są kontrola aplikacji, ograniczenie uruchamiania skryptów z katalogów użytkownika, Endpoint Detection and Response (EDR) oraz rejestrowanie tworzenia procesów. Alert powinien łączyć zdarzenia: otwarcie pliku z klienta poczty, uruchomienie programu systemowego, start PowerShella, pobranie danych i utworzenie zadania harmonogramu.

Zespół SOC powinien móc szybko wyszukać wszystkich odbiorców tej samej wiadomości, nazwę załącznika, domeny pobierania i podobne sekwencje procesów. Samo usunięcie e-maila z jednej skrzynki nie wystarczy, jeśli plik trafił do wielu osób albo payload zdążył się zmienić.

W podmiotach o podwyższonej krytyczności ważna jest segmentacja. Stacja obsługująca korespondencję nie powinna zapewniać niekontrolowanego dostępu do systemów operacyjnych, administracyjnych i zarządzających infrastrukturą. Ograniczone uprawnienia oraz osobne konta administracyjne zmniejszają konsekwencje przejęcia zwykłego profilu użytkownika.

Dla instytucji publicznych przydatnym punktem odniesienia jest także zakres cyberodporności administracji publicznej. Szkolenie i procedury nie zastępują filtrów, EDR ani segmentacji, lecz powinny być z nimi połączone w jeden proces reakcji.

Jak ćwiczyć decyzję użytkownika

Ćwiczenie nie powinno polegać wyłącznie na szukaniu literówek. Wiadomość może być poprawnie napisana, dotyczyć realnego zadania i zawierać dokument, który wygląda wiarygodnie. Pracownik powinien umieć rozpoznać niedozwolony typ pliku oraz wiedzieć, jak przekazać go do bezpiecznej analizy.

W programie security awareness warto zdefiniować konkretne reguły dla archiwów, skrótów i plików wykonywalnych. Odbiorca nie musi analizować poleceń PowerShell. Musi wiedzieć, że plik LNK z e-maila nie jest zwykłym dokumentem, a pojawienie się oczekiwanego formularza nie wyklucza infekcji.

Testy phishingowe dla firm mogą mierzyć trzy zachowania: czy pracownik uruchomił plik, czy przerwał proces oraz czy poprawnie zgłosił wiadomość. Wynik powinien prowadzić do poprawy procedury i zabezpieczeń, a nie do publicznego wskazywania osoby, która popełniła błąd.

Co zrobić, jeśli to już się stało

Po otwarciu podejrzanego EXE, LNK lub archiwum należy przerwać pracę i natychmiast zgłosić zdarzenie do IT albo Security. Urządzenie powinno zostać odizolowane zgodnie z procedurą organizacji. Samodzielne wyłączanie, usuwanie plików lub uruchamianie przypadkowych narzędzi może zniszczyć ślady potrzebne do analizy.

W zgłoszeniu trzeba podać czas zdarzenia, nadawcę, temat wiadomości, nazwę załącznika oraz informację, co pojawiło się na ekranie. Oryginalny e-mail należy zachować. Zespół powinien sprawdzić procesy, połączenia sieciowe, nowe zadania, pliki w profilu użytkownika i aktywność konta.

Jeżeli istnieje ryzyko kradzieży danych przeglądarki, trzeba unieważnić sesje i zmienić dane uwierzytelniające z czystego urządzenia, po uzgodnieniu z zespołem prowadzącym incydent. Należy też przejrzeć reguły poczty, urządzenia, metody MFA i ostatnie logowania. Sama zmiana hasła na potencjalnie zainfekowanym komputerze może przekazać nowy sekret napastnikowi.

Organizacja powinna ustalić zasięg kampanii: innych odbiorców, podobne załączniki, pobrane komponenty i możliwe połączenia z infrastrukturą zewnętrzną. Jeżeli naruszenie mogło objąć dane lub systemy krytyczne, dalsze działania powinny wynikać z planu obsługi incydentów oraz obowiązków prawnych właściwych dla podmiotu.

Liczy się cały łańcuch, nie tylko nazwa malware

Armored Likho wykorzystuje znany punkt wejścia, ale łączy go z dopracowanym maskowaniem, zmiennymi loaderami i modułowym narzędziem do kradzieży informacji. Dokument wyświetlony użytkownikowi może być prawidłowy wizualnie, a mimo to stanowić tylko zasłonę dla infekcji.

Skuteczna obrona łączy kontrolę poczty, ograniczenia wykonania, telemetrię endpointów, segmentację i szybkie zgłaszanie. AI zwiększa tempo tworzenia wariantów, lecz nie usuwa etapów, które można monitorować i zatrzymać.

Organizacje, które chcą przećwiczyć obsługę podejrzanych załączników oraz zweryfikować punkty eskalacji między użytkownikiem, IT i SOC, mogą skontaktować się z PHISHLY.