CISA ostrzega: malware RESURGE może „uśpić się” na urządzeniach Ivanti i czekać na ponowny kontakt atakującego - Security Bez Tabu

CISA ostrzega: malware RESURGE może „uśpić się” na urządzeniach Ivanti i czekać na ponowny kontakt atakującego

Wprowadzenie do problemu / definicja luki

CISA opublikowała zaktualizowane ustalenia dotyczące RESURGE – złośliwego „implantu” (komponentu osadzanego na urządzeniu brzegowym), używanego w kampaniach wykorzystujących podatność CVE-2025-0282 do kompromitacji Ivanti Connect Secure (ICS). Kluczowy wniosek jest bardzo praktyczny: RESURGE może pozostawać uśpiony (dormant) i niewykryty na urządzeniu tak długo, aż operator ataku ponownie spróbuje się z nim połączyć.

To istotne, bo w przypadku „edge device” (VPN / gateway) brak typowego „beaconingu” do C2 oznacza mniejszą szansę, że SIEM/NDR zobaczy podejrzany ruch wychodzący. W praktyce: możesz mieć pozornie „czyste” logi i brak alarmów, a urządzenie nadal jest zagnieżdżone.


W skrócie

  • RESURGE to 32-bitowa biblioteka współdzielona Linuksa (m.in. wskazywana jako libdsupgrade.so) znaleziona na skompromitowanych urządzeniach Ivanti ICS.
  • Implant działa jako pasywny C2: nie wysyła cyklicznych połączeń, tylko czeka na specyficzne połączenie przychodzące TLS.
  • Mechanizmy unikania detekcji obejmują m.in. fingerprinting TLS (CRC32) oraz elementy uwierzytelniania z użyciem fałszywego certyfikatu Ivanti, a po „rozpoznaniu” operatora – zestawienie szyfrowanej sesji (mTLS / kryptografia eliptyczna).
  • Kampanie łączono z aktorem powiązanym z Chinami (UNC5221) i ekosystemem malware „SPAWN”.

Kontekst / historia / powiązania

Wątek Ivanti ICS i podatności na urządzeniach brzegowych wraca regularnie, ale tutaj mówimy konkretnie o CVE-2025-0282 (stack-based buffer overflow), która była aktywnie wykorzystywana jako 0-day jeszcze przed udostępnieniem poprawek.

W raportach z 2025 r. pojawia się powiązanie z rodziną narzędzi „SPAWN” oraz wariantami/odnogami jak SpawnChimera, a RESURGE bywa opisywany jako wariant/powiązany komponent tej linii rozwojowej (wspólne funkcje i cele: utrzymanie dostępu, tunelowanie, backdoor).


Analiza techniczna / szczegóły luki

1) Pasywny C2 i „czekanie” na atakującego

Najbardziej niepokojący mechanizm opisany w aktualizacji: RESURGE nie musi generować ruchu wychodzącego, bo czeka w nieskończoność na odpowiednio spreparowane połączenie przychodzące TLS. To klasyczny wzorzec „low-noise persistence” na urządzeniach brzegowych.

2) Hookowanie accept() i selekcja ruchu

Według opisu technicznego, gdy implant jest załadowany w kontekście procesu web, hookuje funkcję accept(), aby analizować pakiety TLS zanim trafią do webserwera – i rozpoznawać, czy to „normalny” klient, czy operator ataku.

3) Fingerprinting TLS (CRC32) oraz fałszywy certyfikat

Ruch jest weryfikowany m.in. przez CRC32 TLS fingerprint hashing scheme – jeśli fingerprint się nie zgadza, połączenie jest obsługiwane jak legalny ruch do Ivanti. Dodatkowo pojawia się sfałszowany certyfikat Ivanti używany do potwierdzenia, że operator rozmawia z implantem, a nie prawdziwą usługą. Co ważne, w opisie podkreślono, że certyfikat ma rolę „identyfikacyjną/uwierzytelniającą”, a niekoniecznie służy do szyfrowania – co daje obrońcom potencjalny artefakt sygnaturowy na poziomie sieci.

4) Kryptografia eliptyczna i mTLS

Po udanej weryfikacji fingerprintu i „handshake’u” z operatorem, implant zestawia bezpieczny zdalny dostęp z użyciem mTLS i kryptografii krzywych eliptycznych, żądając klucza EC od operatora i weryfikując go względem wbudowanego klucza CA.

5) Funkcje: od rootkita po bootkit (w tym coreboot)

Opis funkcjonalny RESURGE jest szeroki: rootkit/bootkit/backdoor/dropper/proxy/tunneling. W materiale zwrócono też uwagę, że malware potrafi odszyfrować, zmodyfikować i ponownie zaszyfrować obrazy firmware coreboot oraz manipulować zawartością systemu plików w celu utrzymania się na poziomie rozruchu. To podnosi poprzeczkę IR: „zwykły” restart czy częściowe czyszczenie może nie wystarczyć.

6) Log-tampering i komponenty towarzyszące

W analizowanych artefaktach wskazano również wariant SpawnSloth (liblogblock.so) służący do manipulacji logami (ukrywanie aktywności), a także skrypt/binarne narzędzie związane z ekstrakcją kernela (dsmain).


Praktyczne konsekwencje / ryzyko

  1. Ryzyko „fałszywego poczucia bezpieczeństwa”
    Brak beaconingu i log-tampering oznaczają, że standardowe sygnały kompromitacji mogą być niewidoczne.
  2. Utrzymanie dostępu na urządzeniu brzegowym = klucz do sieci
    ICS zwykle stoi na styku Internet–intranet. Kompromitacja takiego węzła ułatwia pivoting, kradzież poświadczeń i długotrwałe operacje szpiegowskie.
  3. Potencjalnie trudna eradykacja
    Jeśli w grę wchodzą mechanizmy boot-level i modyfikacje związane z firmware, organizacja musi rozważyć scenariusze „bare metal / rebuild” i rygorystyczną walidację urządzeń.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które zwykle mają sens w organizacjach korzystających z Ivanti Connect Secure – szczególnie gdy urządzenie było narażone na eksploatację CVE-2025-0282 lub nie ma twardej pewności co do stanu kompromitacji:

  1. Natychmiastowa higiena podatności
  • Upewnij się, że ICS jest na wersji/konfiguracji z poprawką dla CVE-2025-0282 (oraz że nie ma „luk pobocznych” wynikających z zaległości w aktualizacjach).
  1. Polowanie na IoC i artefakty na urządzeniu
  • Szukaj wskazanych nazw/artefaktów typu libdsupgrade.so, liblogblock.so i powiązanych hashy/IoC z aktualizacji (ważne: część IoC może dotyczyć konkretnej próbki, więc traktuj to jako punkt startowy do threat huntingu).
  1. Detekcja na poziomie sieci
  • Włącz/rozszerz inspekcję połączeń przychodzących do ICS pod kątem anomalii TLS i nietypowych certyfikatów – opis wskazuje, że fałszywy certyfikat może posłużyć jako „network signature” przy aktywnym kontakcie operatora z implantem.
  1. Załóż kompromitację przy braku dowodów negatywnych
  • Jeśli urządzenie było podatne w okresie aktywnej eksploatacji, rozważ podejście: izolacja, pełny przegląd, a w razie wątpliwości wymiana/rebuild urządzenia i odtworzenie konfiguracji z zaufanego źródła.
  1. Rotacja poświadczeń i przegląd dostępu
  • Resetuj hasła kont uprzywilejowanych, kont serwisowych i integracji, które mogły być używane przez ICS (VPN, LDAP/AD bind, SSO), oraz przejrzyj konta lokalne/nieoczekiwane zmiany.
  1. Telemetry + retencja logów
  • Zwiększ retencję, wysyłkę logów poza urządzenie (syslog/SIEM), a także korelację z EDR/NDR – log-tampering na samym urządzeniu jest wtedy mniej bolesny operacyjnie.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W porównaniu do „typowego” backdoora, który odzywa się do C2 (HTTP/DNS beacon), RESURGE jest bardziej zbliżony do stylu „edge implantów” obserwowanych w kampaniach APT: minimalny hałas, pasywny kanał dostępu i nacisk na przetrwanie na urządzeniu brzegowym. Mechanizmy w rodzaju hookowania accept() i selekcji połączeń przychodzących są szczególnie problematyczne dla środowisk, które polegają głównie na wykrywaniu anomalii w ruchu wychodzącym.


Podsumowanie / kluczowe wnioski

  • RESURGE może „czekać” na urządzeniu Ivanti ICS bez generowania podejrzanego ruchu, co utrudnia wykrycie i zwiększa ryzyko długotrwałej kompromitacji.
  • Technicznie to nie jest prosty webshell: mówimy o komponencie z elementami rootkit/bootkit, zaawansowaną selekcją TLS i mechanizmami uwierzytelniania operatora.
  • Działania obronne powinny łączyć patch management, hunting po IoC/artefaktach, detekcję sieciową i gotowość do twardszych kroków (izolacja/rebuild/rotacja sekretów) w scenariuszach podwyższonego ryzyka.

Źródła / bibliografia

  1. BleepingComputer – opis aktualizacji CISA i detale techniczne (pasywny C2, TLS fingerprint, fałszywy certyfikat, coreboot). (BleepingComputer)
  2. Cybersecurity Dive – kontekst „latent/undetected”, odniesienie do analizy próbek z infrastruktury krytycznej. (cybersecuritydive.com)
  3. SecurityWeek – tło CVE-2025-0282, UNC5221 i ekosystem SPAWN/SpawnChimera. (SecurityWeek)
  4. SC Media – opis funkcji RESURGE oraz komponentów do log-tampering i narzędzi towarzyszących. (SC Media)
  5. Heise – szerszy kontekst eksploatacji Ivanti na przestrzeni 2025 r. (kontekst kampanii i aktorów). (heise online)