Hunting the Invisible Edge: Detecting Ivanti Connect Secure Exploitation When the Integrity Checker Says Clean

On October 13, 2026, Ivanti disclosed that a zero-day in its Connect Secure VPN appliance was being exploited in the wild. That alone would be a bad week. What made it worse was the detail: the appliance under attack was fully patched, the attacker reached root without logging in, and the vendor's own Integrity Checker Tool — the instrument built specifically to catch this kind of compromise — reported nothing wrong.

The incident, investigated by Volexity, is the clearest recent example of a pattern defenders keep running into: edge devices that fail silently. When the box at the perimeter is compromised, the telemetry most teams rely on either lives on the compromised box itself or never existed in the first place. This article walks through what the attacker did, why the standard checks miss it, and a hunt you can run this week against your own edge fleet — whether or not you run Ivanti.

What happened: three bugs, no malware, no web shell

Volexity tracks the attacker as UTA0576, a previously unknown actor. Exploitation had begun by October 3 against an appliance running Connect Secure 22.8R2.4, then the latest release. (Another firm, Defused, reported seeing the earliest signs of exploitation starting October 1.) Ivanti has said it is aware of limited exploitation in the wild; CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 13 and gave federal civilian agencies until October 16 to address it.

The attack chained three flaws:

1. Authentication bypass (CVE-2026-104935). The public login page, welcome.cgi, checks the request URL to decide whether authentication is required — but routes the request based on a header, X-DSCGI-PATH. An attacker sends a request to the public page carrying a header that points at a protected internal script. The URL check passes; the header decides where the request actually goes. One crafted header is enough to reach functionality that should require a login.
2. Remote code execution (also CVE-2026-104935). A file-upload handler writes an uploaded file to disk before validating that it is a proper ZIP archive. The attacker races that validation window to execute a Perl script. Together, the bypass and the RCE give code execution as the appliance's cgi-server user.
3. Privilege escalation (unpatched at time of writing). The attacker tampers with a shared configuration store in memory, tricking a root-privileged maintenance service into running attacker code. Ivanti patched the first two flaws on October 13 in versions 22.8R2.5, 25.1.1.2, 25.1.3.0, and 25.1.3.1; the privilege-escalation fix is promised in the coming weeks. Versions 22.7.x and earlier are not affected by this CVE.

What followed is what makes this case worth studying. UTA0576 deployed no malware and left no web shell. Instead, the actor re-ran the entire exploit chain for every command it wanted to run, reading results back in the HTTPS response. The exploit patches library code in memory only and restores the configuration data it alters. The actor also wiped matching entries from the appliance's debug logs and Linux audit logs. On disk, there is essentially nothing to find.

Once inside, the focus was credentials. The actor used the appliance's own Active Directory service account to search AD for LAPS administrator passwords and BitLocker recovery keys, ran password-spraying attacks, tested credentials with a custom Kerberos tool, and ran a renamed packet-capture tool from a hidden folder to harvest passwords and NTLM hashes from plaintext LDAP, HTTP, FTP, and telnet traffic crossing the VPN. Volexity also reported scanning, collection of the appliance's configuration data, and parsing of authentication logs to identify valid usernames. The firm assessed the activity as preparation for lateral movement and broader compromise of the victim network.

This is not a one-off for this product family. Ivanti patched an authentication bypass (CVE-2023-46805) and command injection (CVE-2024-21887) under active exploitation in January 2024, a server-side request forgery (CVE-2024-21893) two weeks later, an RCE (CVE-2025-0282) in January 2025, and another RCE (CVE-2025-22457) exploited since at least mid-March 2025. CISA has flagged 36 vulnerabilities across Ivanti products as actively exploited since November 2021, 12 of them also abused by ransomware gangs. Shadowserver counts more than 5,500 Connect Secure instances exposed to the internet.

Why the usual checks fail

The Integrity Checker Tool compares on-disk files against a known-good state. This chain never leaves a modified file: the code patching happens in memory, the configuration changes are reverted, and the logs are scrubbed. A clean ICT result is therefore not evidence of a clean appliance — it is evidence that nothing was written to disk, which is exactly what this attacker arranged. CISA's advisory says the same thing plainly: determining compromise requires network and memory forensics.

Patching has a similar blind spot. Installing the fixed build closes the hole. It does nothing about the credentials already taken: the appliance's service account, any LAPS passwords and BitLocker keys read from AD, any credentials harvested from plaintext traffic, and any valid usernames enumerated from auth logs. "Fully patched" describes the appliance. It says nothing about what already left it.

The third failure is architectural. On many networks, the VPN appliance's own logs are the only record of what hit it — and those logs live on the box the attacker controls. If the attacker can edit them, your timeline has a hole exactly where the intrusion is. Any detection strategy that depends on the appliance telling the truth about itself will miss this class of attack.

The hunt: four checks, in order

Work from the outside in. Every check below assumes the appliance itself is untrustworthy as a witness and leans on telemetry the attacker could not reach.

Hunt 1: The edge, from upstream logs

The one thing the attacker cannot avoid is talking to the appliance over the network. If a WAF, reverse proxy, load balancer, or full-packet capture sits in front of your VPN, that is your ground truth.

What to look for: a high volume of requests to the public login path /dana-na/auth/url_default/welcome.cgi, especially requests carrying an X-DSCGI-PATH header whose value does not match the request URL. That header-to-URL mismatch is the fingerprint of the bypass — legitimate clients have no reason to send that header at all. Volexity published these indicators from the single incident it investigated, along with a /data/.icscap/ directory and one attacker IP address; treat those as starting points from one intrusion, not as a complete indicator list.

A Sigma-style rule for proxy or WAF logs captures the core of it:

title: Ivanti Connect Secure Auth Bypass Attempt
logsource:
  category: webserver
detection:
  selection:
    cs-uri-path|contains: '/dana-na/auth/url_default/welcome.cgi'
    cs-header|contains: 'X-DSCGI-PATH'
  condition: selection
level: high

Practical notes: first baseline how often that header appears in your normal traffic — the answer should be never, but confirm it before you alert. Second, look for the pattern across your whole edge fleet, not just Ivanti: the same query (public login page + unusual routing header + burst volume) generalizes to other appliances.

Hunt 2: The directory, from the domain controller's side

The attacker used the appliance's AD service account to hunt for LAPS passwords and BitLocker recovery keys. That activity is visible from the domain controllers — if you audit it.

In Microsoft Sentinel, against Windows Security events forwarded from your DCs, a first pass looks like this:

SecurityEvent
| where EventID == 4662
| where ObjectType == "ms-Mcs-AdmPwd" or ObjectType == "msLAPS-Password"
    or ObjectType == "msFVE-RecoveryPassword"
| where SubjectUserName contains "ivanti" or SubjectUserName contains "vpn"
| project TimeGenerated, Computer, SubjectUserName, ObjectName, ObjectType
| sort by TimeGenerated desc

Event 4662 (directory service object access) only fires if you have directory-service access auditing enabled — many environments do not, which is itself a finding worth fixing. The equivalent in Splunk against forwarded Windows logs:

index=wineventlog EventCode=4662 (ObjectType="ms-Mcs-AdmPwd" OR ObjectType="msLAPS-Password" OR ObjectType="msFVE-RecoveryPassword")
| stats count by SubjectUserName, ObjectName, _time
| sort -count

What you are looking for is not one read. It is a burst: a service account that normally reads nothing suddenly reading LAPS and recovery-key attributes across many computer objects in a short window. Compare against the account's own baseline — the appliance's service account should have a narrow, boring pattern.

Hunt 3: The plaintext you forgot you had

One of the ugliest details in Volexity's report is the packet capture: the attacker harvested credentials from plaintext LDAP, HTTP, FTP, and telnet traffic passing through the VPN. That only works if plaintext protocols are still crossing your network. Treat this incident as the justification for an inventory you have probably been postponing: which systems still authenticate over plaintext, and which of them traverse the VPN? Every one of them is a credential the next edge compromise collects for free. If you cannot eliminate a protocol, segment it off the VPN path and alert on its presence.

Hunt 4: Memory and packet capture, when the first three hunts hit

If Hunts 1–3 return anything, stop hunting in logs and escalate to forensics: memory images and full packet capture from around the suspicious window. This is what Volexity needed to reconstruct the chain — the evidence lives in RAM and on the wire, not on the appliance's disk. Snapshot the appliance, capture memory, and keep the upstream packet capture for the full exposure window before anything is rotated out.

If you confirm compromise, CISA points to Ivanti's recovery procedure: back up the configuration, factory-reset and upgrade (rebuild the virtual instance for cloud/virtual deployments), then restore the configuration from the backup. And regardless of what forensics finds, rotate everything the appliance could have touched: the AD service account credentials, any LAPS passwords and BitLocker keys in scope, stored certificates and keys, and any credentials that crossed the VPN in plaintext.

What to take away

Three lessons generalize well beyond Ivanti:

1. Treat every edge appliance as a credential store. A VPN gateway holds service-account credentials, sees authentication traffic, and can query your directory. It deserves the same monitoring rigor as a domain controller: logs shipped off-box in real time, alerting on log gaps, and no standing access it does not need.
2. A clean integrity check is not a clean bill of health. Filesystem checks catch filesystem attackers. Memory-only chains, log wiping, and re-exploitation per command are all designed to leave nothing on disk. Pair integrity tooling with upstream network telemetry and memory-forensics capability — and know in advance who performs the latter, because you will not be building that muscle mid-incident.
3. Patch the hole, then hunt the blast radius. The patch closes the vulnerability. The credential theft, enumeration, and traffic capture that happened before the patch are a separate incident with a longer tail. Every edge zero-day response should have two tracks: remediate the device, and assume the credentials it held are burned until proven otherwise.

The uncomfortable truth of this incident is that the attacker did everything right from their side — no persistence to find, no malware to signature, logs scrubbed, evidence confined to memory. The defenders who catch the next one will not be the ones with the best appliance tooling. They will be the ones who never trusted the appliance to report on itself.

Further reading

• CISA, "CISA Urges Patching Newly Exploited Vulnerability in Ivanti Connect Secure" (Oct 13, 2026): https://www.cisa.gov/news-events/alerts/2026/10/13/cisa-urges-patching-newly-exploited-vulnerability-ivanti-connect-secure
• BleepingComputer, "Ivanti warns of Connect Secure zero-day exploited in attacks": https://www.bleepingcomputer.com/news/security/ivanti-warns-of-connect-secure-zero-day-exploited-in-attacks/
• BleepingComputer, "CISA warns admins to immediately fix Ivanti flaw exploited as zero-day": https://www.bleepingcomputer.com/news/security/cisa-warns-admins-to-immediately-fix-ivanti-flaw-exploited-as-zero-day/
• The Hacker News, "CISA Urges Immediate Ivanti Connect Secure Updates as Honeypots Log 105 Exploit Attempts": http://thehackernews.com/2026/10/cisa-urges-immediate-ivanti-connect.html
• Help Net Security, "Attackers chained three Ivanti zero-days to gain root on fully patched VPN appliances": https://www.helpnetsecurity.com/2026/10/14/ivanti-zero-days-gain-root-patched-vpn-appliances/