Ivanti Connect Secure: When the VPN Becomes the Foothold

Threat Intelligence

Two zero-days in Ivanti Connect Secure turned thousands of edge appliances into footholds for a PRC-nexus crew. The lessons are about appliance trust, not patch speed.

By Arjun Raghavan, Security & Systems Lead, BIPI · May 1, 2024 · 9 min read

On January 10, 2024, Ivanti and Volexity disclosed two unpatched flaws in Ivanti Connect Secure and Policy Secure: CVE-2023-46805, an authentication bypass in the web component, and CVE-2024-21887, a command injection in the admin API. Chained together they gave an unauthenticated attacker full code execution on the appliance. Within 48 hours, a PRC-nexus cluster Volexity tracked as UTA0178 (overlapping with Mandiant UNC5221) had compromised customers across defense, telecom, finance, and government.

Timeline of the burn

Volexity caught initial exploitation in early December 2023, more than a month before disclosure. The actor was already running an interactive operation: pulling configs, dumping the appliance database, harvesting cached credentials, and dropping webshells like GLASSTOKEN and GIFTEDVISITOR. Public disclosure on January 10 triggered mass scanning the same evening. By January 19, CISA issued Emergency Directive 24-01 ordering federal agencies to disconnect Connect Secure appliances. By the end of January, researchers were tracking thousands of compromised devices and at least five distinct webshell families.

Root cause: the appliance trust problem

The two CVEs are technically a parser bug and a missing input check. The deeper root cause is structural. Connect Secure is a network appliance: it terminates SSL VPN, holds AD credentials, sits at the perimeter, and is treated as infrastructure rather than software. Teams patch it on appliance cadence, not application cadence. There is no EDR, no central logging by default, and the integrity check tool Ivanti shipped during the incident was itself bypassed by the attacker within days.

Attacker actions on objective

UTA0178 used the foothold the way any mature operator would. They modified the appliance's component integrity tool to lie about itself. They patched legitimate Perl and Python files to hold persistence across upgrades. They proxied internal traffic through the VPN to reach Active Directory, then deployed KrustyLoader, a Rust downloader staging Sliver beacons on internal Linux hosts. They harvested every cached SAML and VPN session to ride existing trust deeper into the network. The appliance was a beachhead, not a target.

Detection and what worked

Volexity found this through outbound network telemetry, not endpoint signals. The appliance was beaconing to attacker infrastructure, and that traffic looked nothing like normal VPN flows. Customers who had pcap or netflow on their DMZ egress could retro-hunt. Customers who treated the appliance as a black box could not.

Lessons for the next edge zero-day

First, edge appliances need network-level observability you control. If the vendor's integrity tool is the only thing telling you the box is clean, you are trusting the attacker's first target. Second, credential exposure on a compromised VPN is total. Every AD password, every SAML session, every API token cached on that appliance is burned. Plan rotation procedures for that scenario before you need them. Third, factory reset is not remediation if persistence survives upgrade, which it did here. Rebuild on new hardware or new VMs from clean images.

The BIPI take

Network appliances are software with worse hygiene. The Ivanti incident is not an Ivanti story. It is a story about every device on the perimeter that cannot run an agent, cannot stream logs, and cannot be rebuilt from code. Until those three properties are true for your edge stack, your zero-day exposure is measured in weeks of dwell time, not hours of patch SLA.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.