Slopoly: malware generowane przez AI wykorzystane w ataku ransomware Interlock - Security Bez Tabu

Slopoly: malware generowane przez AI wykorzystane w ataku ransomware Interlock

Cybersecurity news

Wprowadzenie do problemu / definicja

Slopoly to nowo opisany backdoor uruchamiany jako skrypt PowerShell, powiązany z kampanią ransomware Interlock. Szczególną uwagę badaczy zwrócił fakt, że próbka nosi wyraźne ślady wygenerowania lub współtworzenia przy użyciu modelu językowego. To ważny sygnał dla zespołów bezpieczeństwa: generatywna AI nie musi tworzyć bardzo zaawansowanego kodu, aby realnie przyspieszać rozwój narzędzi ofensywnych i wspierać operacje wymuszeniowe.

W skrócie

Slopoly został użyty w późniejszej fazie incydentu prowadzonego przez grupę powiązaną z klastrem Hive0163, działającą w ekosystemie Interlock. Malware zapewniał trwały dostęp do zainfekowanego serwera przez ponad tydzień, komunikował się z infrastrukturą C2, wykonywał komendy systemowe i umożliwiał dostarczanie kolejnych ładunków.

Choć technicznie Slopoly nie należy do najbardziej zaawansowanych zagrożeń, jego znaczenie wynika z roli operacyjnej oraz z potwierdzenia, że AI może skracać czas tworzenia niestandardowego malware wykorzystywanego w realnych atakach ransomware.

Kontekst / historia

Zaobserwowany incydent rozpoczął się od techniki ClickFix, czyli socjotechnicznego scenariusza nakłaniającego ofiarę do uruchomienia złośliwego polecenia PowerShell. Taki model wejścia jest coraz częściej spotykany w kampaniach wymierzonych w środowiska korporacyjne, ponieważ omija klasyczne schematy dostarczania malware i opiera się na ręcznym działaniu użytkownika.

W analizowanym łańcuchu ataku po uzyskaniu dostępu uruchamiano dodatkowe komponenty, w tym NodeSnake oraz InterlockRAT. Dopiero w późniejszym etapie operatorzy wdrożyli Slopoly, co sugeruje użycie tego narzędzia jako pomocniczego, ale praktycznego elementu utrzymania dostępu i obsługi poleceń na już przejętym systemie. Sam Interlock jest aktywny co najmniej od 2024 roku i był wcześniej wiązany z kampaniami przeciwko dużym organizacjom oraz z wykorzystaniem niestandardowych technik początkowego dostępu.

Analiza techniczna

Slopoly został zidentyfikowany jako klient prostego frameworka command-and-control. Malware miał być wdrażany do katalogu C:\ProgramData\Microsoft\Windows\Runtime\ i utrwalał się przez zaplanowane zadanie o nazwie „Runtime Broker”. Taki wybór ścieżki i nazwy ma znaczenie maskujące, ponieważ przypomina legalne elementy systemu Windows i może utrudniać szybką ocenę artefaktów przez administratora.

Z perspektywy funkcjonalnej Slopoly realizował typowe zadania backdoora:

  • zbieranie podstawowych informacji o systemie,
  • wysyłanie cyklicznego beacona typu heartbeat do serwera C2,
  • odpytywanie infrastruktury o nowe polecenia,
  • wykonywanie komend przez cmd.exe,
  • odsyłanie wyników do operatora,
  • prowadzenie lokalnego pliku logów,
  • obsługę aktualizacji i zakończenia własnego procesu.

Według analizy heartbeat był wysyłany co 30 sekund, a polling poleceń odbywał się co 50 sekund. Malware zapisywał także log persistence.log, rotowany po osiągnięciu określonego rozmiaru. Z punktu widzenia obrońców obecność takich cyklicznych żądań HTTP i powtarzalnych interwałów beaconingu może stanowić użyteczny wskaźnik detekcyjny w telemetrii EDR, proxy i NDR.

Najciekawszy element dotyczy genezy kodu. Badacze zwrócili uwagę na cechy wskazujące na udział modelu językowego: rozbudowane komentarze, czytelnie opisane funkcje, sensowne nazwy zmiennych i przewidywalny styl obsługi wyjątków. W kodzie pojawiały się również deklaracje sugerujące większą „inteligencję” niż rzeczywista funkcjonalność. Przykładowo skrypt opisywał siebie jako klient „polimorficzny”, jednak nie wykazywał zdolności do rzeczywistej samomodyfikacji podczas działania.

Bardziej prawdopodobny scenariusz zakłada użycie generatora lub buildera, który tworzył kolejne warianty klienta z innymi parametrami konfiguracyjnymi, takimi jak identyfikator sesji, nazwa muteksu, adres C2 czy interwały beaconingu. W tym samym łańcuchu ataku wykorzystywano także InterlockRAT oraz loader JunkFiction. Końcowy payload ransomware Interlock działał jako 64-bitowy plik wykonywalny Windows, mógł uruchamiać się z uprawnieniami SYSTEM przez Harmonogram zadań i używał interfejsu Restart Manager API do zwalniania blokad na plikach przed szyfrowaniem.

Konsekwencje / ryzyko

Najważniejsze ryzyko związane ze Slopoly nie wynika z przełomowych technik ukrywania się, lecz z obniżenia bariery tworzenia użytecznego malware. Jeśli operatorzy mogą szybciej budować działające komponenty C2, backdoory i narzędzia pomocnicze, cykl przygotowania kampanii ulega skróceniu. To zwiększa skalę zagrożenia, zwłaszcza w atakach prowadzonych przez grupy nastawione na eksfiltrację danych i wymuszenia.

W praktyce oznacza to:

  • większą liczbę niestandardowych wariantów malware,
  • szybsze modyfikacje konfiguracji i nazw funkcji utrudniające detekcję sygnaturową,
  • częstsze użycie lekkich skryptów PowerShell jako elementów post-exploitation,
  • większą elastyczność operatorów ransomware w utrzymywaniu dostępu do sieci ofiary,
  • rosnącą presję na detekcję behawioralną zamiast wyłącznie na IOC.

Dodatkowo fakt, że Slopoly utrzymywał obecność na serwerze przez ponad tydzień, pokazuje operacyjne znaczenie nawet prostych narzędzi. W środowisku produkcyjnym taki okres wystarczy do rekonesansu, kradzieży danych, przygotowania ruchu lateralnego i koordynacji finalnego szyfrowania.

Rekomendacje

Organizacje powinny potraktować ten przypadek jako argument za wzmocnieniem detekcji działań post-exploitation, a nie tylko ochrony przed klasycznym ransomware.

  • blokowanie i monitorowanie nietypowych uruchomień PowerShell, cmd.exe oraz schtasks.exe,
  • wdrożenie zasad ograniczających wykonanie skryptów i egzekwowanie polityk Application Control,
  • monitorowanie tworzenia zadań harmonogramu podszywających się pod legalne komponenty systemowe,
  • analizę ruchu HTTP/HTTPS pod kątem regularnego beaconingu i krótkich, cyklicznych żądań do niestandardowych endpointów,
  • inspekcję katalogów systemowych i półsystemowych, w których mogą być umieszczane ukryte komponenty malware,
  • korelację zdarzeń związanych z ClickFix i podobnymi technikami socjotechnicznymi,
  • segmentację sieci oraz ograniczanie uprawnień administracyjnych i ruchu lateralnego,
  • rejestrowanie i analizę poleceń wykonywanych przez interpreter poleceń oraz PowerShell Script Block Logging,
  • ochronę serwerów plików i systemów krytycznych przez EDR/XDR z detekcją zachowań ransomware,
  • testowanie procedur reagowania na incydenty obejmujących jednoczesną eksfiltrację danych i szyfrowanie.

W środowiskach SOC warto uzupełnić scenariusze detekcyjne o korelację: uruchomienie PowerShell, utworzenie zaplanowanego zadania, komunikację C2 po HTTP oraz późniejsze użycie narzędzi administracyjnych lub binariów związanych z ransomware. Szczególnie cenne będą reguły oparte na sekwencjach zdarzeń, a nie tylko pojedynczych wskaźnikach kompromitacji.

Podsumowanie

Przypadek Slopoly pokazuje, że AI nie musi generować wyjątkowo zaawansowanego malware, aby zmieniać krajobraz zagrożeń. Wystarczy, że przyspiesza tworzenie działających komponentów ofensywnych, które następnie trafiają do realnych kampanii ransomware. Dla obrońców najważniejszy wniosek jest praktyczny: rośnie znaczenie detekcji behawioralnej, monitorowania skryptów i śledzenia aktywności post-compromise.

Źródła

  1. AI-generated Slopoly malware used in Interlock ransomware attack — https://www.bleepingcomputer.com/news/security/ai-generated-slopoly-malware-used-in-interlock-ransomware-attack/
  2. A Slopoly start to AI-enhanced ransomware attacks — https://www.ibm.com/think/x-force/slopoly-start-ai-enhanced-ransomware-attacks