Aeternum C2: botnet, którego „serce” mieszka w blockchainie Polygon (i dlaczego to komplikuje takedown) - Security Bez Tabu

Aeternum C2: botnet, którego „serce” mieszka w blockchainie Polygon (i dlaczego to komplikuje takedown)

Wprowadzenie do problemu / definicja „luki”

Aeternum C2 to loader botnetowy, który przenosi kluczowy element infrastruktury C2 do publicznego łańcucha Polygon. Zamiast klasycznego serwera C2 (domena/IP), operator publikuje polecenia jako dane w smart kontraktach, a zainfekowane hosty pobierają je, odpytując publiczne endpointy RPC. W praktyce oznacza to C2 odporne na typowe działania typu sinkhole, przejęcie domen czy wyłączanie serwerów.

W skrócie

  • C2 na Polygonie: polecenia trafiają do smart kontraktów i są odczytywane przez boty via publiczne RPC.
  • Panel operatorski: webowy panel (opisywany jako aplikacja w Next.js) służy do wyboru kontraktu, typu komendy i URL payloadu, a następnie zapisuje komendę w blockchainie jako transakcję.
  • Szyfrowanie: komendy są szyfrowane AES-GCM, a klucz wyprowadzany PBKDF2 (100k iteracji) z adresu kontraktu – co może umożliwiać defensywną dekrypcję historycznych poleceń, bo adres kontraktu jest publiczny.
  • „Ekonomia ataku”: niski koszt operacyjny – w doniesieniach pada, że ok. 1 USD w MATIC wystarcza na 100–150 transakcji z komendami.
  • Model „crimeware”: oferta sprzedaży dostępu do panelu/kompilacji oraz źródeł (C++) pojawia się w opisach kampanii.

Kontekst / historia / powiązania

Aeternum C2 wpisuje się w trend „decentralizacji” C2: brak jednego hosta do przejęcia. Media branżowe porównują ten schemat do wcześniejszych przypadków, np. Glupteba, gdzie blockchain był wykorzystywany jako kanał zapasowy do pobierania właściwego adresu C2. W Aeternum blockchain ma być kanałem pierwotnym, co zwiększa odporność na takedown.

Analiza techniczna / szczegóły działania

1) Architektura: loader + smart kontrakt + publiczne RPC

  • Loader (Windows, buildy x86/x64) pobiera instrukcje nie z domeny, tylko z kontraktu na Polygonie.
  • Odczyt poleceń odbywa się przez wywołanie funkcji kontraktu (np. getDomain()), a aktualizacja poleceń przez updateDomain(), co generuje zdarzenia/logi w łańcuchu.

2) Format komend i targetowanie

W analizie panelu opisano prosty język poleceń:

  • all:url:<URL> – uruchom na wszystkich hostach
  • hwid:<...>:url:<URL> – uruchom tylko na hoście o wskazanym HWID
  • warianty z args: oraz savestartupname: (pod kątem uruchomienia payloadu i „dopalenia” trwałości).

Ciekawy detal: HWID ma wynikać z MD5 numeru seryjnego dysku C: (co upraszcza selektywne „dozowanie” ładunków).

3) Szyfrowanie poleceń i potencjalna słabość projektu

Komendy przechowywane w kontrakcie są szyfrowane AES-GCM, a klucz ma być wyprowadzany przez PBKDF2 (SHA-256, 100 000 iteracji) z materiału powiązanego z adresem kontraktu. W praktyce, jeśli schemat derivacji opiera się o publiczny adres (a tak opisano w analizie panelu), obrońcy mogą dekodować historyczne polecenia dla danego kanału C2.

To ważne: „blockchainowe C2” utrudnia wyłączenie, ale przez swoją transparentność potrafi ułatwiać telemetrię i rekonstrukcję działań operatora – o ile znamy kontrakty i schemat kryptograficzny.

4) Panel operatorski i OPSEC

W badaniu panelu podkreślono, że panel prosi o klucz prywatny Polygon i deklaruje jego szyfrowanie AES-256-GCM po stronie przeglądarki (localStorage), bez wysyłania klucza na serwer. To poprawia OPSEC operatora (mniej elementów do przejęcia), ale nadal zostawia artefakty po stronie urządzenia operatora.

5) Anti-analysis i „commodity” funkcje

Doniesienia branżowe opisują mechanizmy utrudniające analizę (np. wykrywanie środowisk wirtualnych) oraz weryfikację „niewykrywalności” buildów przez usługi typu skan AV (wskazywano m.in. Kleenscan).

Praktyczne konsekwencje / ryzyko

  1. Takedown jest trudniejszy: nie ma „serwera”, który można wyłączyć – polecenia siedzą w publicznym łańcuchu.
  2. Detekcja sieciowa musi się zmienić: klasyczne IoC (domena/IP C2) przestają wystarczać; trzeba patrzeć na ruch do endpointów RPC i specyficzne wzorce zapytań.
  3. Ryzyko wieloładunkowe: według opisu, operator może zarządzać wieloma kontraktami/payloadami (stealer/RAT/miner/clipper), co sprzyja szybkiej monetyzacji infekcji.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC / Blue Team

  • Monitoring egress: zidentyfikuj i profiluj ruch do publicznych Polygon RPC (HTTP/S). Szukaj cyklicznych zapytań (polling) z nietypowych hostów użytkowników/serwerów.
  • Detekcje oparte o zachowanie: koreluj: nowe procesy + pobieranie binariów z URL + nietypowy ruch do RPC + mechanizmy trwałości (np. uruchamianie przy starcie).
  • Threat hunting po blockchainie: jeśli w telemetryce (EDR/proxy) znajdziesz adres kontraktu, możesz pivotować po zdarzeniach/logach kontraktu i odtwarzać sekwencję komend (w analizach pokazano, że bywa to wykonalne).

Dla IR / Incident Response

  • Szybkie odcięcie pobierania payloadów: nawet jeśli nie wyłączysz C2, możesz blokować domeny/hostingi, z których Aeternum ściąga payload (URL jest elementem komendy).
  • Zabezpiecz artefakty sieciowe: pełne PCAP/proxy logs z okresu infekcji mogą pozwolić na identyfikację kontraktu i rekonstrukcję poleceń.

Dla IT / prewencji

  • Hardening stacji/serwerów: ogranicz uruchamianie niepodpisanych binariów, włącz reguły ASR (tam gdzie możliwe), kontroluj persistence (startup/run keys/scheduled tasks).
  • Segmentacja i least privilege: loader jest „bramą” do kolejnych ładunków – minimalizuj skutki przez ograniczanie uprawnień i dostępu lateralnego.

Różnice / porównania z innymi przypadkami

  • Glupteba (2021): blockchain jako kanał pomocniczy do odzyskania „prawdziwego” C2.
  • Aeternum C2 (2025/2026): blockchain jako kanał główny – bez klasycznego C2 do przejęcia.

W skrócie: wcześniejsze kampanie traktowały blockchain jako mechanizm odporności; Aeternum przesuwa go do roli „kręgosłupa” operacji.

Podsumowanie / kluczowe wnioski

Aeternum C2 to praktyczny przykład, że decentralizacja C2 przestaje być teorią: smart kontrakty na Polygonie mogą utrzymywać kanał poleceń długo po tym, jak klasyczna infrastruktura zostałaby wyłączona. Jednocześnie transparentność łańcucha (logi, zdarzenia) daje obrońcom nowe opcje analityczne – zwłaszcza gdy schemat szyfrowania/derywacji klucza jest przewidywalny. Największa zmiana po stronie defensywy to przejście z „blokowania domen” na polowanie na zachowania i telemetrię RPC/blockchain.

Źródła / bibliografia

  1. The Hacker News – opis Aeternum C2 i modelu C2 na Polygonie (26 lutego 2026). (The Hacker News)
  2. Ctrl-Alt-Int3l – analiza panelu, funkcji smart kontraktu, szyfrowania AES-GCM/PBKDF2 i formatu komend. (Ctrl-Alt-Int3l)
  3. SecurityWeek – omówienie odporności na takedown i elementów „crimeware” (sprzedaż, panel). (SecurityWeek)
  4. SC Media (SCWorld) – streszczenie techniki C2 przez smart kontrakty i cech anty-analizy. (SC Media)
  5. MITRE ATT&CK – technika „Credentials in Registry” (kontekstowo, jako typowy wzorzec polowania; nie jako potwierdzenie dla Aeternum). (attack.mitre.org)