Avalon malware i CrownX: od phishingu do ransomware

TL;DR

Avalon to nowo opisany framework złośliwego oprogramowania dla Windows. W analizowanym przez Blackpoint Cyber łańcuchu atak zaczynał się od wiadomości udającej przekazanie dokumentu prawnego. E-mail kierował odbiorcę do archiwum chronionego hasłem w legalnej usłudze Proton Drive. W środku znajdował się obraz dysku ISO, a w nim skrót LNK wyglądający jak plik PDF.

Uruchomienie skrótu prowadziło do użycia MSBuild.exe, legalnego narzędzia Microsoftu. Następne etapy ładowały kod do pamięci, próbowały ograniczyć widoczność dla narzędzi ochronnych i uruchamiały Avalon. Framework mógł kraść poświadczenia, pliki cookie, sesje, dane VPN i komunikatorów, szukać kolejnych systemów, utrudniać odzyskiwanie oraz uruchomić CrownX ransomware.

To nie jest tylko historia o szyfrowaniu plików. Notatka z żądaniem okupu mogła pojawić się dopiero po kradzieży danych dostępowych, rozpoznaniu środowiska i osłabieniu opcji przywracania. Dla firmy właściwym punktem reakcji jest więc podejrzany proces dostarczenia dokumentu, a nie dopiero widoczny ekran ransomware.

Publiczna analiza opisuje konkretny odzyskany łańcuch. Nie potwierdza masowej kampanii w Polsce, nie wskazuje wiarygodnie operatora i nie oznacza, że każdy link do Proton Drive jest złośliwy. Pokazuje jednak mechanizm, który może zostać łatwo przeniesiony na korespondencję prawną, finansową, kadrową lub urzędową.

Czym są Avalon i CrownX

Avalon nie jest pojedynczym szyfratorem plików. Według analizy Blackpoint Cyber to modularny framework, który koordynuje kilka etapów włamania na komputerze z systemem Windows. Obejmuje funkcje kradzieży danych dostępowych, komunikacji z serwerem atakującego, rozpoznania środowiska, zdalnego wykonywania działań, przemieszczania się do kolejnych systemów, utrudniania analizy oraz niszczenia możliwości odzyskiwania.

CrownX jest komponentem odpowiedzialnym za etap ransomware i wymuszenia. Szyfruje pliki i przygotowuje notatkę z żądaniem okupu. Jego obecność nie oznacza jednak, że wcześniejsze działania były wyłącznie przygotowaniem do szyfrowania. Skradzione sesje przeglądarki, hasła, dane VPN, zapisane połączenia zdalne lub tokeny komunikatorów mogą nadal dawać dostęp do usług firmowych nawet po odłączeniu pierwszego komputera.

To rozróżnienie jest ważne operacyjnie. Incydentu nie można zamknąć przez odtworzenie jednego urządzenia i usunięcie zaszyfrowanych plików. Trzeba ustalić, jakie dane dostępowe przejęto, gdzie mogły zostać użyte i czy atakujący dotarł do systemów współdzielonych, serwerów, środowisk wirtualnych albo infrastruktury kopii zapasowych.

Jak fałszywy dokument prawny uruchamiał atak

Pierwszy etap wykorzystywał zwyczajny proces biznesowy: przekazanie poufnego dokumentu. Wiadomość prowadziła do archiwum chronionego hasłem, umieszczonego w Proton Drive. Legalna usługa udostępniania plików podnosiła wiarygodność, a hasło utrudniało automatyczne sprawdzenie zawartości przed pobraniem.

Po rozpakowaniu odbiorca otrzymywał obraz ISO nazwany jak bezpieczny pakiet dokumentów. ISO jest plikiem obrazu dysku. Windows może go zamontować jako dodatkowy wirtualny napęd, dlatego użytkownik widzi jego zawartość podobnie jak pliki na pendrivie lub płycie.

W zamontowanym obrazie znajdował się skrót Secure Document CA-283505.pdf.lnk. Nazwa sugerowała dokument PDF, a ikona przypominała plik otwierany w Microsoft Edge. Rozszerzenie .lnk oznaczało jednak skrót systemu Windows. Po kliknięciu nie uruchamiał się zwykły dokument. Skrót wywoływał cmd.exe, odnajdywał ukryty projekt i przekazywał go do MSBuild.exe.

Obok skrótu umieszczono pliki tekstowe i XML, które miały wyglądać jak elementy bezpiecznego pakietu. Nie odpowiadały za wykonanie kodu, ale wzmacniały narrację o zweryfikowanym dokumencie. To istotny element socjotechniczny: odbiorca nie widział jednego podejrzanego programu. Widział spójny katalog udający procedurę dostarczenia chronionych materiałów.

Podobny wzorzec PHISHLY opisywało przy Operation GriefLure i plikach LNK. Tam również wiarygodne materiały zawodowe miały skłonić odbiorcę do uruchomienia skrótu. W przypadku Avalon dalszy łańcuch prowadził jednak do frameworka zdolnego łączyć kradzież tożsamości, ruch boczny, sabotaż odzyskiwania i ransomware.

Dlaczego użycie MSBuild utrudnia ocenę zdarzenia

MSBuild.exe jest legalnym narzędziem Microsoftu używanym do budowania projektów programistycznych. MITRE ATT&CK opisuje jego nadużycie jako technikę uruchamiania kodu przez zaufane narzędzie deweloperskie. Projekt MSBuild może zawierać zadanie z kodem C# i wykonać je bez uruchamiania typowego pliku EXE z załącznika.

W analizowanym łańcuchu projekt odtwarzał zaszyfrowany etap .NET, ładował go do pamięci i przekazywał wykonanie dalej. Kolejny moduł próbował ingerować w Event Tracing for Windows oraz Antimalware Scan Interface, czyli mechanizmy wykorzystywane przez system i narzędzia ochronne do rejestrowania oraz sprawdzania aktywności. Następny ładunek był pobierany przez HTTPS i uruchamiany z pamięci.

Dla zespołu bezpieczeństwa oznacza to, że brak klasycznego pliku wykonywalnego na dysku nie świadczy o braku infekcji. Istotny jest cały łańcuch zachowań: skrót z zamontowanego obrazu, uruchomienie interpretera poleceń, projekt MSBuild w katalogu tymczasowym, połączenie sieciowe oraz nietypowa aktywność procesu, który zwykle nie powinien występować na komputerze użytkownika.

Microsoft wskazuje, że organizacje, które nie potrzebują MSBuild.exe na danej klasie urządzeń, powinny rozważyć jego blokowanie w politykach kontroli aplikacji. Na stacjach programistycznych całkowity zakaz może być nierealny. Wtedy potrzebne są reguły oparte na kontekście: lokalizacji projektu, procesie nadrzędnym, połączeniu sieciowym, użytkowniku i dalszych działaniach na hoście.

Co Avalon mógł zrobić przed uruchomieniem CrownX

Największym ryzykiem nie był sam moment szyfrowania. Analiza wykazała szeroki zestaw funkcji, które mogły zostać użyte wcześniej.

Avalon zawierał logikę zbierania haseł, plików cookie, historii i zapisanych danych z przeglądarek Chromium oraz Firefox. Odwoływał się także do danych z Windows Credential Manager, profili Wi-Fi, zapisanych połączeń RDP, konfiguracji VPN, materiałów SSH, komunikatorów i wybranych portfeli kryptowalutowych. Taki zakres zwiększa ryzyko przejęcia kont i dalszego dostępu poza pierwotnym urządzeniem.

Framework rozpoznawał systemy mogące zwiększyć wpływ ataku, w tym serwery, kontrolery domeny, platformy wirtualizacyjne i rozwiązania kopii zapasowych. Potrafił korzystać z udziałów administracyjnych, zadań zaplanowanych i usług zdalnych. Nie oznacza to, że każda funkcja została użyta w każdym zdarzeniu. Pokazuje jednak, jakie hipotezy powinien sprawdzić SOC po uruchomieniu podejrzanego pliku.

Avalon zawierał również funkcje wymierzone w lokalne mechanizmy odzyskiwania. Obejmowały zatrzymywanie usługi Volume Shadow Copy Service, usuwanie kopii w tle oraz ingerencję w środowisko odzyskiwania Windows. Badacze znaleźli także możliwość bezpośredniego dostępu do dysków fizycznych, co mogło prowadzić do uszkodzenia struktur potrzebnych do uruchomienia systemu.

CrownX szyfrował nie tylko typowe dokumenty biurowe. Lista formatów obejmowała także pliki projektowe, bazy danych, kod źródłowy i dyski maszyn wirtualnych. Dla firmy oznacza to potencjalny wpływ na produkcję oprogramowania, projektowanie, środowiska serwerowe i procesy operacyjne, a nie wyłącznie na katalog dokumentów jednego pracownika.

Dlaczego taki scenariusz może działać w polskiej firmie

Przynęta nie musi używać nazwy zagranicznej kancelarii. W polskich realiach podobny e-mail może udawać pozew, wezwanie do zapłaty, dokument do podpisu, materiał z audytu, zawiadomienie o naruszeniu, korespondencję od regulatora, plik od kancelarii albo dowód dotyczący pracownika czy kontrahenta.

Odbiorcą może być sekretariat, dział prawny, księgowość, compliance, HR, zakupy, zarząd lub ogólna skrzynka kontaktowa. Każda z tych funkcji regularnie otrzymuje pliki z zewnątrz. Atakujący wykorzystuje więc nie brak wiedzy technicznej, lecz presję zawodową: dokument wygląda jak coś, czego nie można zignorować ani opóźnić.

Osobnym problemem jest nadużycie rozpoznawalnej platformy do udostępniania plików. Nazwa legalnej usługi nie potwierdza, że konkretny folder i archiwum są bezpieczne. Z drugiej strony proste blokowanie całej usługi może zakłócić pracę i zostać szybko obchodzone. Lepsza kontrola uwzględnia nadawcę, kontekst wiadomości, typ pobieranego pliku, ochronę hasłem i zachowanie na urządzeniu.

PHISHLY opisywało już ransomware dostarczane przez fałszywą korespondencję od Interpolu. Tam głównym narzędziem nacisku był autorytet instytucji. Avalon dodaje do podobnej socjotechniki szczególnie niebezpieczny łańcuch techniczny: archiwum, obraz ISO, skrót udający PDF i uruchomienie kodu przez zaufane narzędzie systemowe.

Sygnały, które powinny zatrzymać odbiorcę

Pojedynczy element nie musi przesądzać o oszustwie. Ryzyko rośnie, gdy kilka elementów pojawia się razem:

• nieoczekiwany dokument prawny lub poufny materiał wymaga szybkiej reakcji;
• wiadomość kieruje do pliku w zewnętrznej usłudze zamiast do znanego portalu lub uzgodnionego kanału;
• archiwum jest chronione hasłem, a hasło znajduje się w tym samym e-mailu;
• po rozpakowaniu trzeba zamontować obraz ISO;
• „PDF” okazuje się skrótem LNK albo innym nietypowym typem pliku;
• nadawca nakłania do zignorowania ostrzeżenia systemu lub wykonania dodatkowych kroków technicznych;
• sprawy nie można potwierdzić przez znany numer telefonu, formalny obieg dokumentów lub wcześniejszy kontakt.

Pracownik nie musi sam analizować rozszerzeń i procesów. Powinien znać prostą zasadę: dokument prawny lub finansowy, który wymaga rozpakowania archiwum, zamontowania obrazu dysku i uruchomienia skrótu, należy zatrzymać i przekazać do weryfikacji.

Takie zachowanie jest praktycznym rozwinięciem zasad opisanych w materiale co to jest phishing. Atak nie kończy się na kliknięciu w link. Składa się z kolejnych decyzji, a każda z nich daje szansę na przerwanie procesu.

Co powinny sprawdzić IT i SOC

Pierwsza warstwa dotyczy dostarczania plików. Organizacja powinna ocenić, czy poczta i brama internetowa potrafią analizować linki do zewnętrznych usług, archiwa chronione hasłem, obrazy ISO oraz skróty LNK. Dla części firm uzasadnione będzie blokowanie takich typów plików z zewnątrz. Inne potrzebują kwarantanny i ręcznej akceptacji, ponieważ podobne materiały występują w legalnych procesach.

Druga warstwa dotyczy kontroli wykonania. Na zwykłych stacjach biurowych warto ograniczyć narzędzia deweloperskie, których użytkownik nie potrzebuje. Jeżeli MSBuild.exe jest wymagany, monitoring powinien wykrywać uruchomienie projektu z katalogów pobierania, tymczasowych, profilu użytkownika lub zamontowanego obrazu. Szczególnie istotne jest połączenie tego zdarzenia z cmd.exe, ruchem HTTPS, krótkotrwałymi plikami i ładowaniem kodu do pamięci.

Trzecia warstwa dotyczy tożsamości i ruchu bocznego. Po podejrzanym wykonaniu trzeba sprawdzić logowania, aktywne sesje, tokeny, dostęp do VPN, RDP, udziałów administracyjnych, zadań zaplanowanych i usług zdalnych. Izolacja pierwszego hosta nie wystarcza, gdy napastnik zdążył przejąć dane dostępowe albo uruchomić zadanie na innym urządzeniu.

Czwarta warstwa to odporność na ransomware. CISA w przewodniku StopRansomware zaleca utrzymywanie kopii odseparowanych od środowiska źródłowego oraz regularne testowanie odtwarzania. W tym scenariuszu test powinien zakładać, że lokalne punkty przywracania, konta administracyjne i część infrastruktury backupowej mogą być celem atakującego przed rozpoczęciem szyfrowania.

Reguły i blokady trzeba wdrażać po testach. Nie każda organizacja może wyłączyć obrazy ISO, archiwa z hasłem albo MSBuild. Cel nie polega na włączeniu jednej polityki, lecz na połączeniu kontroli poczty, kontroli aplikacji, telemetrii endpointów, ochrony tożsamości, segmentacji i przygotowanego procesu reakcji.

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

Jeżeli użytkownik tylko otrzymał wiadomość, nie ma podstaw do uznania urządzenia za zainfekowane. E-mail należy zgłosić, zachować w formacie EML i sprawdzić, czy trafił do innych osób.

Jeżeli pobrano archiwum lub obraz ISO, ale nie uruchomiono żadnego pliku, nie należy otwierać go ponownie w celu samodzielnej weryfikacji. Zespół bezpieczeństwa powinien przejąć wiadomość, link i pliki do kontrolowanej analizy.

Jeżeli skrót LNK został uruchomiony, urządzenie trzeba potraktować jako potencjalnie przejęte, nawet gdy nie pojawiła się notatka ransomware. Należy odizolować komputer od sieci zgodnie z procedurą organizacji, ale nie kasować plików i nie wyłączać go bez decyzji zespołu obsługi incydentu. Pamięć operacyjna i aktywne procesy mogą zawierać ważne dane do analizy.

Z czystego urządzenia trzeba unieważnić aktywne sesje i zmienić dane dostępowe związane z użytkownikiem. Zakres powinien objąć pocztę, usługi chmurowe, VPN, komunikatory, konta administracyjne i inne systemy, do których dostęp był zapisany na komputerze. Sama zmiana hasła może nie wystarczyć, gdy nadal działają tokeny sesyjne.

SOC powinien równolegle wyszukać tę samą wiadomość i pliki na innych urządzeniach, przeanalizować uruchomienia MSBuild.exe, sprawdzić połączenia wychodzące, udziały administracyjne, zadania zaplanowane, usługi zdalne oraz zmiany dotyczące VSS, środowiska odzyskiwania i backupu. Dopiero taki zakres pozwala ocenić, czy zdarzenie pozostało na jednym hoście.

Podejrzaną wiadomość lub incydent można przekazać do CERT Polska przez formularz incydent.cert.pl. Organizacje objęte dodatkowymi obowiązkami sektorowymi powinny uruchomić własną ścieżkę eskalacji, oceny prawnej i zgłoszeń. Test phishingowy ani szkolenie nie zastępują planu reagowania i technicznego dochodzenia.

Jak przełożyć ten mechanizm na testy i awareness

Scenariusz nadaje się do ćwiczenia, ponieważ pokazuje różnicę między kliknięciem a wykonaniem pliku. Bezpieczna symulacja nie powinna zawierać działającego LNK, obrazu ISO ani kodu. Może jednak odwzorować proces: formalna wiadomość, zewnętrzny link, archiwum z hasłem i moment, w którym użytkownik powinien zatrzymać działanie oraz zgłosić sprawę.

W testach phishingowych dla firm warto mierzyć nie tylko kliknięcie. Znaczenie ma czas zgłoszenia, użycie właściwego kanału, weryfikacja z nadawcą, reakcja IT i szybkość ostrzeżenia pozostałych odbiorców. Scenariusz może też sprawdzić, czy pracownicy obsługujący korespondencję prawną wiedzą, kto ma podejmować decyzję o otwarciu nietypowego pakietu.

Szerszy program security awareness powinien łączyć takie ćwiczenia z jasną procedurą. Pracownik musi wiedzieć, gdzie zgłosić wiadomość i że szybkie zgłoszenie po błędzie jest lepsze niż ukrywanie zdarzenia. Zespół techniczny musi z kolei potrafić przejść od jednego zgłoszenia do wyszukania kampanii, izolacji urządzenia i kontroli tożsamości.

W jednostkach obsługujących formalną korespondencję, w tym w administracji publicznej, warto przećwiczyć ścieżkę przekazania dokumentu do kancelarii, działu prawnego lub bezpieczeństwa. Celem nie jest uczenie pracowników nazw MSBuild, ETW czy AMSI. Celem jest zatrzymanie nietypowego procesu przed uruchomieniem skrótu.

Ograniczenia publicznej analizy

Blackpoint Cyber opisał odzyskany łańcuch i możliwości znalezione w kodzie. Publiczne dane nie pozwalają określić liczby ofiar, skali aktywnej dystrybucji, konkretnych branż ani obecności kampanii w Polsce. Nie ma też podstaw, aby każdą funkcję uznać za użytą w każdym incydencie.

Badacze wskazali oznaki rozwoju wspomaganego przez sztuczną inteligencję, ale jest to ocena cech kodu, a nie dowód na użycie konkretnego modelu lub narzędzia. Z perspektywy obrony ważniejszy jest skutek: rozbudowany zestaw funkcji może powstać szybciej i trafić do operatorów o różnym poziomie doświadczenia.

Nazwy plików, domeny, rozszerzenia zaszyfrowanych danych i skróty mogą się zmienić. Trwalszą wartość mają zachowania: nieoczekiwane archiwum z hasłem, obraz ISO, LNK udający dokument, uruchomienie MSBuild z nietypowej lokalizacji, kradzież danych dostępowych, ruch do innych hostów i próby uszkodzenia odzyskiwania.

Wniosek dla pracownika i organizacji

Wiadomość z poufnym dokumentem nie powinna wymagać od odbiorcy montowania obrazu dysku ani uruchamiania skrótu z archiwum. Gdy proces dostarczenia pliku staje się nietypowy, pracownik powinien przerwać działanie i przekazać sprawę do weryfikacji oficjalnym kanałem.

Dla IT i SOC sygnałem incydentu nie jest dopiero notatka CrownX. Uruchomienie LNK i MSBuild z pobranego pakietu powinno rozpocząć izolację hosta, kontrolę tożsamości, wyszukiwanie ruchu bocznego i ocenę systemów odzyskiwania. Dzięki temu firma reaguje na włamanie, zanim jego najbardziej widoczny etap stanie się problemem całej organizacji.

Jeżeli potrzebujesz sprawdzić, czy pracownicy i procedury zatrzymają podobny scenariusz przed uruchomieniem pliku, zakres bezpiecznej symulacji i ścieżkę reakcji można omówić przez kontakt z PHISHLY.