A sophisticated implant family called RESURGE was observed installed on vulnerable Ivanti Connect Secure appliances. RESURGE is not a noisy beaconing backdoor — it’s a dormant, boot-level-capable implant that waits for a very specific, attacker-initiated TLS handshake before it activates. The implant can survive reboots, manipulate boot images and integrity checks, create web shells, and proxy traffic into internal networks.
This combination of long latency, firmware-level persistence, and protocol-level authentication makes detection and removal difficult and raises the risk that compromised VPN appliances have been acting as persistent beachheads inside customer networks for months.
Technical Anatomy
- Files & components observed — CISA’s analysis and incident reports show a small set of artifacts extracted from compromised devices:
- `libdsupgrade.so` — the RESURGE implant (32-bit Linux shared object).
- `liblogblock.so` — log-tampering module (SpawnSloth-variant).
- `dsmain` — kernel/firmware extraction and manipulation helper (uses `extract_vmlinux.sh` and BusyBox).
- CISA published the observable IoC hashes for these files.
- Persistence model — initial implant modifies the Ivanti boot disk and coreboot/firmware images so it can survive a full reboot; it can alter integrity checks to hide changes. That makes recovery by re-starting services insufficient — firmware and boot media must be validated.
- Network-level stealth & activation — instead of outbound beaconing, the implant hooks the web process’s `accept()` call and inspects incoming TLS handshakes. It will only “wake up” for an inbound TLS connection that matches an attacker fingerprint (CRC32 of TLS handshake characteristics) and is accompanied by a forged Ivanti certificate the implant expects. If the fingerprint or certificate don’t match, connections are handed to the real web server — leaving the appliance looking normal. The attacker then initiates a Mutual TLS session (ECDH/ECDSA) to establish a secure C2 channel.
- Evasion & cleanup tricks — the implant includes log tampering (the `liblogblock.so` module) and utilities to modify firmware images, plus mechanisms to avoid detection by network monitoring tools by blending in with normal TLS/SSH traffic.
- Threat actor: publicly reported activity ties exploitation to a China-linked actor (UNC5221 / related clusters). They exploited pre-patched Ivanti zero-days to deploy RESURGE.
- Initial vector: remote code execution via Ivanti Connect Secure vulnerabilities (CVE variants disclosed in early 2025).
- Impact: persistent, covert remote access; credential theft via web shells; potential lateral movement from a trusted VPN appliance; altered firmware that prevents simple rollback fixes.
Actionable Runbook
- Isolate affected appliances
- Remove vulnerable devices from production networks and internet access immediately. Treat as compromised until proven otherwise.
- Collect forensic artifacts
- Capture full disk images of boot media and `/boot` partitions, memory if possible, and the running process memory for `web` processes. Export TLS session captures (pcap) for any suspicious inbound connections.
- Record device configuration, running processes, loaded kernel modules, and currently installed certificates.
- Hunt for known artifacts and IoCs
- Check for file names and SHA256 hashes observed by CISA: `libdsupgrade.so`, `liblogblock.so`, `dsmain` and their published hashes.
- Detect the forged TLS certificate / fingerprint
- Because the attacker uses a forged Ivanti certificate sent in the clear prior to establishing the mutual TLS channel, capture and inspect inbound TLS ClientHello/ServerHello data. The forged cert is a reliable network signature for active (not dormant) compromises.
- If compromise confirmed — rebuild not patch
- Reimage appliances from known-good images; fully reflash firmware. Replace any boot media that was modified. Rotate all credentials that transited or were stored on the appliance. Do not simply upgrade the OS and assume the device is clean.
- Patch & upgrade
- Apply Ivanti’s published patches and follow vendor guidance for supported platforms. But assume patching alone does not remove a firmware-level implant.
Host checks
- List suspect files and compute SHA256:
# search likely locations (adjust paths per device)
find / -type f -name 'libdsupgrade.so' -o -name 'liblogblock.so' -o -name 'dsmain' 2>/dev/null \
-exec sha256sum {} \;
- Check for modified boot disk contents and unexpected BusyBox/extract_vmlinux artifacts:
strings /boot/* | egrep -i 'extract_vmlinux|busybox|liblogblock'
Network checks
- Capture inbound TLS handshakes; extract presented certificates:
# capture traffic on appliance external interface
tcpdump -i eth0 -w /tmp/appliance_traffic.pcap 'tcp port 443'
# extract certs with tshark
tshark -r /tmp/appliance_traffic.pcap -Y 'ssl.handshake.certificate' -T fields -e x509af.subject
- Look for repeated inbound TLS handshakes that present a non-standard Ivanti cert or unusual CRC32 fingerprint signatures (if you have historic TLS fingerprints).
Detection tooling
- Deploy Zeek/Bro script to log TLS fingerprints and X.509 details. Alert on inbound certs that match known forged cert attributes or on handshakes that deviate from normal tempo for your environment.
Eradication & Recovery
- Full device rebuild: reflash firmware from known good vendor media or replace hardware if firmware cannot be fully validated.
- Reinstall from snapshot only when snapshot integrity is cryptographically verified and created before the suspected compromise window.
- Reissue all keys and certificates associated with the device and any upstream services the device authenticates to.
- Rotate privileged credentials and audit admin accounts created or modified during the compromise window.
- Apply continuous monitoring and blocklists for the IoCs — but treat network detection as supplementary: RESURGE can be dormant.
Detection Tactics
- Reduce attack surface: restrict management interfaces to out-of-band networks and VPNs; enforce strict ACLs on appliance interfaces.
- Immutable boot verification: use secure boot/enforced measured boot and cryptographic verification of firmware images where possible. Detect changes to coreboot or boot disks.
- TLS observability: log certificate chains and TLS fingerprint metadata at perimeter collectors; retain handshake data for retrospective hunts.
- Supply-chain & patch discipline: prioritize appliance patching and replace end-of-life devices; maintain a replacement schedule rather than indefinite support of legacy VPN gear.
- Assume breach for perimeter appliances: adopt the assumption that any internet-exposed appliance can be a beachhead; apply least privilege and zero-trust network segmentation.
Why this is a turning point for appliance security
RESURGE demonstrates a growing attacker preference for implants that stay quiet until specifically activated, and for persistence mechanisms that target boot firmware. That makes detection by conventional EDR and IDS much less effective. Organizations must change how they treat internet-facing appliances: they should be treated as high-impact endpoints, subject to the same firmware validation, immutable provisioning, and continuous cryptographic integrity checks applied to servers in high-security environments.
