msaRAT grupy Chaos ransomware ukrywa komunikację C2 w przeglądarce i utrudnia detekcję

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Nowoczesne kampanie ransomware coraz częściej odchodzą od klasycznych, łatwych do wykrycia połączeń malware z infrastrukturą atakującego. Zamiast tego operatorzy nadużywają legalnych narzędzi systemowych i popularnych aplikacji, aby ukryć aktywność w zwykłym ruchu organizacji. Tak właśnie działa msaRAT, złośliwe oprogramowanie przypisywane grupie Chaos ransomware, które przenosi komunikację command-and-control do lokalnie uruchomionej przeglądarki Chrome lub Microsoft Edge.

To podejście znacząco utrudnia pracę zespołów bezpieczeństwa, ponieważ z perspektywy sieciowej ruch wygląda jak normalna aktywność przeglądarki, a nie jak połączenia inicjowane przez podejrzany proces malware.

W skrócie

msaRAT to trojan zdalnego dostępu napisany w Rust, wykorzystywany w działaniach powiązanych z operacjami Chaos ransomware. Jego najważniejszą cechą jest brak bezpośrednich połączeń sieciowych wykonywanych przez sam proces malware. Zamiast tego zagrożenie uruchamia przeglądarkę w trybie headless, steruje nią przez Chrome DevTools Protocol i przekazuje komunikację C2 za pośrednictwem WebRTC.

proces malware komunikuje się głównie lokalnie, przez localhost,
ruch zewnętrzny generuje legalna przeglądarka,
kanał C2 ukrywany jest w komunikacji WebRTC,
dane są dodatkowo szyfrowane poza standardową ochroną transportową.

Efekt jest taki, że klasyczne mechanizmy monitoringu sieciowego, takie jak firewalle, IDS czy NDR, mogą mieć ograniczoną widoczność rzeczywistej aktywności atakującego.

Kontekst / historia

Chaos jest obserwowany jako operator działający w modelu ransomware-as-a-service i prowadzący ataki ukierunkowane na większe organizacje. W tego typu operacjach etap poprzedzający szyfrowanie danych zwykle obejmuje rozpoznanie środowiska, utrzymanie dostępu, eskalację uprawnień oraz przygotowanie do eksfiltracji informacji. To właśnie w tej fazie badacze zaobserwowali wykorzystanie msaRAT.

Istotne jest to, że nie mamy do czynienia z prostym downloaderem ani typowym backdoorem. msaRAT reprezentuje bardziej dojrzałe podejście do ukrywania kanału C2 poprzez wykorzystanie zaufanej aplikacji obecnej niemal w każdym środowisku korporacyjnym. To kolejny etap ewolucji technik „living off the land”, w których przestępcy nie muszą już bezpośrednio wychodzić do sieci jako osobny proces.

Analiza techniczna

Łańcuch infekcji rozpoczyna się od pobrania pliku MSI z infrastruktury kontrolowanej przez atakujących. Instalator podszywa się pod aktualizację systemową i wykorzystuje własną akcję instalacyjną do załadowania komponentu RAT bezpośrednio do pamięci. Następnie malware sprawdza, czy w systemie dostępna jest przeglądarka Chrome lub Edge, korzystając ze zmiennych środowiskowych i wpisów rejestru.

Po odnalezieniu odpowiedniej przeglądarki msaRAT uruchamia ją w trybie headless z włączonym zdalnym debugowaniem. Kolejnym krokiem jest połączenie z lokalnym portem debugowania i użycie Chrome DevTools Protocol do sterowania sesją przeglądarki. Dzięki temu malware może manipulować kontekstem przeglądarki, wstrzykiwać kod JavaScript i przenieść właściwą komunikację sieciową do procesu browsera.

Najważniejszy element tej architektury polega na rozdzieleniu aktywności lokalnej i zewnętrznej. Sam proces msaRAT komunikuje się lokalnie, najczęściej przez adres 127.0.0.1, natomiast wszelki ruch wychodzący do internetu realizowany jest przez Chrome lub Edge. Dla narzędzi monitorujących oznacza to, że podejrzany binarny komponent nie inicjuje bezpośrednich połączeń do infrastruktury C2.

Do zestawienia sesji wykorzystywany jest mechanizm sygnalizacyjny, a następnie komunikacja przechodzi do kanału danych WebRTC. Badacze wskazali, że autorzy zagrożenia celowo unikają bezpośrednich połączeń peer-to-peer i wymuszają użycie serwerów pośredniczących TURN. Taki model dodatkowo zaciera ślady infrastruktury atakującego i utrudnia analizę źródeł ruchu.

Warstwa transmisji jest ponadto wzmacniana dodatkowym szyfrowaniem. Oprócz zabezpieczeń zapewnianych przez WebRTC, msaRAT stosuje własną ochronę danych przy użyciu ChaCha-Poly1305, a klucze sesyjne są uzgadniane z wykorzystaniem ECDH. W praktyce daje to podwójną osłonę kanału C2 i ogranicza możliwość inspekcji zawartości przez systemy bezpieczeństwa.

Wśród śladów behawioralnych szczególne znaczenie mają nietypowe flagi uruchamiania przeglądarki, aktywność lokalnych portów debugowania, użycie narzędzi takich jak certutil.exe lub curl.exe, a także artefakty pozostawiane w katalogach roboczych, w tym w ProgramData. Dodatkowym sygnałem ostrzegawczym mogą być żądania HTTP z identyfikatorem wskazującym na użycie HeadlessChrome.

Konsekwencje / ryzyko

Największe ryzyko związane z msaRAT wynika z jego zdolności do obchodzenia klasycznej detekcji sieciowej. W wielu organizacjach analiza ruchu wychodzącego nadal opiera się na reputacji domen, adresach IP, sygnaturach protokołów oraz korelacji procesu inicjującego połączenie. W tym przypadku zewnętrzny ruch generuje jednak legalna przeglądarka, a używane technologie są powszechnie dopuszczane w środowisku biznesowym.

ruch C2 może zlewać się z normalną aktywnością webową użytkowników,
blokowanie całych usług pośredniczących może być operacyjnie trudne,
analiza ograniczona wyłącznie do warstwy sieciowej może nie wykryć incydentu,
atakujący zyskują więcej czasu na rozpoznanie środowiska, eksfiltrację danych i przygotowanie etapu szyfrowania.

Szczególnie narażone są organizacje, które dopuszczają szeroki ruch przeglądarkowy, wykorzystują WebRTC w codziennej pracy i nie monitorują parametrów uruchamiania procesów. W takich warunkach msaRAT może skutecznie ukrywać się w tle legalnych operacji biznesowych.

Rekomendacje

Przypadek msaRAT pokazuje, że nowoczesna obrona przed ransomware nie może opierać się wyłącznie na telemetrii sieciowej. Konieczne jest połączenie analizy zachowań endpointów, monitoringu procesów oraz kontroli sposobu użycia przeglądarek.

monitorować uruchomienia Chrome i Edge z flagami headless oraz remote-debugging,
wykrywać nietypowe relacje procesów, na przykład instalator MSI uruchamiający przeglądarkę,
analizować lokalne połączenia do portów debugowania oraz aktywność związaną z Chrome DevTools Protocol,
korelować zdarzenia EDR/XDR z ruchem WebRTC wychodzącym z hostów, na których nie powinien występować,
ograniczać możliwość uruchamiania nieautoryzowanych instalatorów i skryptów z katalogów tymczasowych oraz ProgramData,
wdrażać application control i allowlisting dla instalatorów, interpreterów oraz narzędzi administracyjnych,
aktualizować reguły detekcyjne pod kątem HeadlessChrome, nadużyć WebRTC i nietypowego użycia certutil.exe oraz curl.exe,
regularnie testować scenariusze ransomware obejmujące etap przed szyfrowaniem danych.

W praktyce największą wartość będą miały reguły behawioralne na poziomie hosta, ponieważ to tam najlepiej widać powiązanie fałszywego instalatora, startu przeglądarki z nietypowymi parametrami, lokalnej komunikacji debugującej oraz późniejszego ruchu sieciowego generowanego przez proces browsera.

Podsumowanie

msaRAT pokazuje, jak szybko ewoluują techniki wykorzystywane przez operatorów ransomware. Zamiast klasycznych beaconów i oczywistych połączeń do serwerów C2, przestępcy wykorzystują legalne przeglądarki, Chrome DevTools Protocol i WebRTC, aby ukryć komunikację w zwykłym ruchu organizacji.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że skuteczna detekcja musi coraz mocniej opierać się na analizie zachowań procesów, telemetrii endpointów i korelacji wielu pozornie niegroźnych zdarzeń. W przeciwnym razie komponenty używane przed wdrożeniem właściwego ładunku ransomware mogą pozostać aktywne na tyle długo, by doprowadzić do pełnej kompromitacji środowiska.