Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Nowa aktywność grupy Chaos pokazuje wyraźną zmianę w sposobie ukrywania komunikacji command-and-control w operacjach ransomware. Zamiast łączyć się bezpośrednio z infrastrukturą operatora, implant msaRAT wykorzystuje lokalnie uruchomioną przeglądarkę Google Chrome lub Microsoft Edge w trybie headless, aby przekierować ruch C2 przez legalne mechanizmy przeglądarkowe. Taki model utrudnia wykrycie, ponieważ z perspektywy narzędzi monitorujących ruch wygląda on jak zwykła aktywność przeglądarki.
W skrócie
Chaos używa implantu msaRAT napisanego w Rust, uruchamianego przed etapem szyfrowania danych. Malware steruje przeglądarką przez Chrome DevTools Protocol, a następnie zestawia ukryty kanał komunikacyjny WebRTC DataChannel. Do sygnalizacji wykorzystywana jest infrastruktura Cloudflare Workers, a ruch relay przechodzi przez usługę TURN dostarczaną przez Twilio.
- implant nie łączy się bezpośrednio z Internetem,
- zewnętrzny ruch jest realizowany przez legalny proces przeglądarki,
- adres rzeczywistego serwera operatora nie pojawia się w standardowej telemetrii sieciowej,
- technika utrudnia detekcję opartą na IOC, reputacji domen i analizie procesu malware.
Kontekst / historia
Grupa Chaos została opisana jako operator ransomware-as-a-service aktywny co najmniej od lutego 2025 roku. Wcześniejsze działania tej grupy obejmowały kampanie spamowe, vishing, nadużywanie narzędzi zdalnego wsparcia oraz utrwalanie dostępu przy użyciu legalnych rozwiązań RMM. Pokazuje to model działania, w którym relatywnie prosty wektor wejścia jest łączony z bardziej zaawansowanym etapem postkompromitacyjnym.
W analizowanym scenariuszu msaRAT pojawia się po uzyskaniu dostępu do systemu i jeszcze przed uruchomieniem właściwego ransomware. Implant był dostarczany m.in. jako pakiet MSI pobierany poleceniem curl i podszywający się pod aktualizację systemową. Następnie uruchamiana była akcja niestandardowa, która ładowała osadzoną bibliotekę DLL bezpośrednio do pamięci.
Analiza techniczna
Kluczową cechą msaRAT jest rozdzielenie logiki malware od bezpośredniej komunikacji sieciowej. Sam implant ogranicza ruch do lokalnego adresu 127.0.0.1, a wszystkie połączenia zewnętrzne wykonuje uruchomiona przez niego przeglądarka. Malware wyszukuje Chrome lub Edge przez zmienne środowiskowe i rejestr systemowy, a następnie startuje przeglądarkę z parametrami trybu bezgłowego, zdalnego debugowania i osobnego katalogu profilu.
Sterowanie odbywa się przez Chrome DevTools Protocol. Implant pobiera listę dostępnych celów debugowania, zestawia połączenie WebSocket z interfejsem CDP, tworzy kartę przeglądarki, omija ograniczenia Content Security Policy i wstrzykuje własny kod JavaScript zapisany w danych binarnych. Ten skrypt odpowiada za budowę faktycznego kanału komunikacyjnego.
JavaScript pobiera konfigurację STUN i TURN z infrastruktury opartej na Cloudflare Workers, a nagłówki Origin i Referer są maskowane tak, by przypominały legalny ruch związany z usługami Microsoftu. Następnie wykonywana jest wymiana SDP Offer/Answer potrzebna do utworzenia połączenia WebRTC. Z opisu wynika, że brak kandydatów ICE wymusza przesyłanie całego ruchu przez przekaźnik TURN, co dodatkowo ukrywa właściwą infrastrukturę operatora.
Po ustanowieniu DataChannel dalsza komunikacja C2 odbywa się już wyłącznie przez WebRTC. Ruch jest dodatkowo chroniony podwójną warstwą szyfrowania: zewnętrznie przez DTLS przeglądarki, a wewnętrznie przez mechanizm oparty na ChaCha-Poly1305 i wymianie kluczy ECDH. Otrzymywane polecenia są przekazywane do cmd.exe, co umożliwia wykonywanie komend systemowych, transfer plików i realizację kolejnych etapów ataku.
Warto podkreślić, że nie jest to exploit przeglądarki, lecz nadużycie legalnych funkcji debugowania i WebRTC. Oznacza to, że sama aktualizacja Chrome lub Edge nie rozwiązuje problemu, jeśli organizacja nie monitoruje nietypowego wykorzystania przeglądarek w trybie headless.
Konsekwencje / ryzyko
Najpoważniejszym ryzykiem jest skuteczne ukrycie źródła ruchu C2. W wielu organizacjach połączenia przeglądarkowe do popularnych usług chmurowych są dozwolone, a komunikacja WebRTC nie zawsze podlega ścisłej inspekcji. W efekcie klasyczne detekcje oparte na domenach, adresach IP, portach i reputacji procesu mogą okazać się niewystarczające.
Dodatkowym problemem jest wykorzystanie legalnego procesu przeglądarki jako nośnika komunikacji. Dla systemów EDR, NDR czy serwerów proxy aktywność ta może wyglądać jak automatyzacja testów, narzędzia developerskie lub standardowe działanie aplikacji webowej. To zwiększa odporność atakujących na blokowanie infrastruktury i utrudnia szybkie przypisanie ruchu do złośliwego procesu.
Szczególnie narażone są środowiska Windows, w których Chrome lub Edge są obecne standardowo. Ponieważ msaRAT działa przed fazą szyfrowania, jego wykrycie może być ostatnią realną szansą na zatrzymanie incydentu, zanim dojdzie do destrukcyjnego etapu ataku ransomware.
Rekomendacje
Organizacje powinny analizować tę technikę przede wszystkim jako wzorzec zachowania, a nie tylko zestaw pojedynczych wskaźników kompromitacji. Kluczowe jest monitorowanie uruchamiania Chrome i Edge z parametrami wskazującymi na nadużycie funkcji developerskich.
- monitorować użycie parametrów takich jak –headless, –remote-debugging-port i niestandardowy –user-data-dir,
- korelować uruchomienie przeglądarki z procesami nadrzędnymi, takimi jak MSI, curl.exe, cmd.exe, skrypty i usługi systemowe,
- śledzić lokalny ruch do portu zdalnego debugowania oraz aktywność WebSocket powiązaną z CDP,
- wykrywać nietypowe sesje WebRTC inicjowane poza normalnym kontekstem użytkownika,
- ograniczać uruchamianie nieautoryzowanych instalatorów MSI przez AppLocker lub WDAC,
- monitorować akcje niestandardowe w instalatorach i pobieranie plików przez narzędzia wiersza poleceń,
- wzmacniać kontrolę nad narzędziami zdalnego wsparcia, RMM i dostępem uprzywilejowanym.
Na poziomie sieci lepiej postawić na analizę behawioralną, segmentację i wykrywanie anomalii niż wyłącznie na blokowanie pojedynczych domen czy usług relay. Szczególnej uwagi wymagają sytuacje, w których przeglądarka jest uruchamiana bez interakcji użytkownika lub przez proces nienależący do standardowego workflow pracownika.
Podsumowanie
msaRAT pokazuje, że nowoczesne operacje ransomware coraz częściej opierają się na nadużywaniu legalnych komponentów systemu zamiast klasycznych kanałów C2. W tym przypadku kluczową innowacją jest przeniesienie komunikacji do headless Chrome lub Edge sterowanych przez Chrome DevTools Protocol i wspieranych przez WebRTC z relay TURN. Dla zespołów bezpieczeństwa oznacza to konieczność odejścia od prostych IOC na rzecz analizy łańcucha procesów, nietypowych parametrów uruchomienia oraz behawioralnego wykrywania użycia legalnego oprogramowania.
Źródła
- https://thehackernews.com/2026/07/chaos-ransomware-uses-msarat-to-route.html
- https://blog.talosintelligence.com/chaos-msarat-living-off-the-browser-to-build-covert-c2-channel/
- https://blog.talosintelligence.com/new-chaos-ransomware/