Ivanti VPN Zero-Days Let UTA0576 Reach Root and Steal Credentials

A Connect Secure VPN running the latest patch available at the time, 22.8R2.4 Build 19097, gave an unauthenticated intruder root access in early October. Volexity’s incident investigation traced repeated exploitation from October 3, followed by credential collection and Active Directory searches. The appliance gave the intruder a route into the customer’s network.

The group Volexity tracks as UTA0576 took credentials stored on the VPN, including those used for LDAP, and queried directory attributes containing LAPS passwords and BitLocker recovery information. Ivanti’s October 13 update says it is aware of limited exploitation and urges affected customers to upgrade. Volexity investigated its monitoring customer with its Volcano memory-analysis product.

Public login routed to private code

The VPN’s public welcome.cgi login route admitted unauthenticated requests. The request’s X-DSCGI-PATH header could then point the back-end handler at a different CGI file, including the protected wu.cgi. In plain terms, the front door checked the public address while the internal dispatcher followed a different address in the request. Volexity identified this routing mismatch as the authentication bypass.

The second flaw was a brief file-write window in wu.cgi: it placed an uploaded file in /home/runtime/tmp/ before checking its ZIP format and removing it. An attacker who reached the transient file through the same routing flaw could execute code as cgi-server. Volexity says the actor used a Perl stage to launch a Bash stage and an in-memory Python stage. These authentication-bypass and remote-code-execution components are tracked together as CVE-2026-104935.

A third flaw raised that access to root. The privileged dsinvoked service reads maintenance-task configuration from DSCache; the attacker temporarily changed what one task ran, invoked it, and restored the configuration. Volexity found the supporting library patch in the process’s memory, rather than on disk. Its report says Ivanti was still developing a fix for this separate privilege-escalation flaw when it published. Patching the bypass and execution path stops the described unauthenticated entry chain; investigate past access separately.

Credentials moved through the VPN

Volexity found the actor using the VPN’s Active Directory service account to search for LAPS passwords, BitLocker recovery keys and password-bearing attributes. The actor wrote LDAP and Kerberos helper scripts under /tmp/, including /tmp/ml.py, /tmp/rq5.py and /tmp/mk.py; the custom Kerberos tool included Kerberoast capability, although Volexity says the accompanying script did not use that capability. The actor also ran password spraying and wrote results to /tmp/sp_out.txt and /tmp/spray_hits.json.

One particularly useful lead is /data/.icscap/dsstatmond, a renamed packet-capture tool Volexity found sniffing the VPN’s traffic. It targeted plaintext protocols and wrote rotating captures under /data/.icscap/cap*. The actor used /data/.icscap/h.py to parse captures for LDAP, HTTP Basic Authentication and NTLM material; Volexity observed exfiltration of raw capture data. The operation’s infrastructure included 108.165.147[.]64, an Evoxt VPS that Volexity observed running OpenVPN from September 30 through October 7. Correlate that historical address with appliance and directory activity before treating a connection as suspicious.

Volexity assesses with high confidence that directory data was exfiltrated. The response interrupted the operation; its investigators assessed that the activity was preparation for lateral movement and a broader compromise.

Log deletion hid the entry

Volexity found that the actor deleted evidence from /home/runtime/dlogs/debuglog and /var/log/audit/audit.log. Recovered payloads also attempted to restore the changed task configuration and erase temporary files; Volexity could not establish how completely every cleanup step ran. Commands and results traveled in the exploit’s HTTPS requests. Volexity found no installed web shell or first-stage backdoor on the appliance, so a hunt restricted to persistent implants would miss this case. It reconstructed the route from memory, disk images and core dumps after the incident surfaced.

Ivanti recommends regular runs of its Integrity Checker Tool as part of layered monitoring. Volexity gives this case an important limit: the temporary library change lived in memory and the task setting was restored. Its wording is direct: “The Ivanti Integrity Checker may not be able to identify device compromise.” Review appliance-to-directory traffic and volatile evidence when the VPN has shown suspicious behavior, even after an ordinary integrity check passes.

Upgrade and investigate past access

Locate Connect Secure appliances and record both their current versions and versions run since October 3. For the 25.x branch, Volexity calls out 25.1.1 and prior and 25.1.2 for upgrade; it also calls out 22.8R2.4. The Ivanti-assigned CVE record lists 25.1.3.0, 25.1.3.1 and 22.8R2.5 as unaffected for the tracked bypass/RCE, and specifically excludes 22.7R2.14 and prior from its affected scope. Match the installed branch to Ivanti’s fixed release and verify the running version on each appliance.

Look for a burst of requests to /dana-na/auth/url_default/welcome.cgi with X-DSCGI-PATH pointing at a different CGI file, especially wu.cgi or a temporary file under /home/runtime/tmp/. Correlate that with VPN-originated LDAP queries to the domain controller, password-spray results, new files under /tmp/ and /data/.icscap/, and lateral movement from the appliance. Review retained perimeter and domain-controller telemetry because the attacker changed local logs. Preserve memory and disk evidence and investigate any exposed LDAP service-account credentials, LAPS passwords and BitLocker recovery material if an appliance matches the behavior.

Keep the VPN out of recovery

Upgrade the affected Connect Secure branch to its fixed release, then compare historical appliance traffic with domain-controller authentication and LDAP logs. If the VPN sent suspicious directory queries or moved laterally, isolate its network access, preserve volatile evidence and rotate credentials exposed through its service account as part of incident response. A successful upgrade removes the known entry route for future requests; the historical traffic and credential exposure determine the recovery work.