October 31, 2026 14 min to read

Ivanti Connect Secure Zero-Day Chain: A Hunt and Harden Guide

No web shell, scrubbed logs, a clean integrity check. Here is how to hunt it anyway

Most VPN compromises leave something behind: a web shell, a backdoored binary, a modified file the vendor’s integrity checker flags. The Ivanti Connect Secure (ICS) intrusion that Volexity has been documenting this month left almost nothing. The attacker ran commands in memory, passed results back through the exploit’s own HTTPS requests, patched a library in memory and then put it back, and carefully cut their entries out of the appliance’s debug and audit logs. Ivanti’s Integrity Checker Tool, the usual first step for ICS incidents, “does not detect any modifications,” according to Volexity.

On 29 October Ivanti expanded its advisory to three CVEs and shipped a fix for the root privilege escalation in the chain. On 30 October CISA added that privilege escalation, CVE-2026-111357, to its Known Exploited Vulnerabilities catalog with a 2 November deadline (OpenCVE KEV history). If you run ICS, this is the weekend to patch and go hunting.

This guide covers what the chain does, who is affected, and how to hunt for it in places the attacker could not scrub: your edge and SIEM logs, and your Active Directory.

TL;DR / Key takeaways

• A threat actor Volexity tracks as UTA0576 chained ICS zero-days from at least 3 October 2026 to get unauthenticated code execution and then root on fully patched appliances (22.8R2.4).
• The CVEs: CVE-2026-104935 (authentication bypass to remote code execution, patched 13 October, in CISA KEV), CVE-2026-111357 (privilege escalation to root, patched 29 October, in CISA KEV since 30 October) and CVE-2026-118527 (predictable file names on upload, reported at CVSS 4.3).
• After getting in, the attacker went after Active Directory: LAPS passwords, BitLocker recovery keys, Kerberoasting and password spraying, using the appliance’s own AD service account.
• A clean Integrity Checker result does not prove you are clean. CISA warns that commands ran in memory. Hunt in your perimeter logs and domain controller logs instead.
• Upgrade to the latest fixed release now. If you find signs of compromise, factory reset or rebuild the appliance and rotate every credential it held.

What happened (quick timeline)

Sources: Volexity, BleepingComputer, GBHackers, OpenCVE.

How the chain works (conceptually)

Volexity’s write-up is unusually detailed. Here is the short version, without the exploit mechanics:

1. Authentication bypass. A request to a public, pre-login page (/dana-na/auth/url_default/welcome.cgi) carries an internal routing header, X-DSCGI-PATH. The appliance checks authorisation against the URL, but uses the header to decide which CGI program actually runs. That mismatch lets an unauthenticated request reach an internal upload handler (wu.cgi).
2. Code execution through a race. The upload handler writes the file to a temporary location before checking that it is a real ZIP, then deletes it. The attacker sends many parallel requests so one of them executes the file in that brief window. The payload is a Perl script that launches a Python stage.
3. Root. The attacker patches the cgi-server process’s in-memory copy of a system library, alters a cached maintenance task, and asks the dsinvoked broker (which runs as root) to execute it. This is CVE-2026-111357. Afterwards the original task and library bytes are restored.
4. No separate C2. Volexity found no web shell or first-stage malware. The attacker “passed commands and results through the exploit chain’s HTTPS requests rather than a separate command-and-control (C2) channel.”

What they did once inside

This is the part that should worry every ICS owner. According to Volexity, UTA0576:

• Extracted credentials stored on the appliance, including domain credentials used for LDAP.
• Used the appliance’s AD service account with a custom Python LDAP tool to search for LAPS passwords, BitLocker recovery keys and userPassword/unixUserPassword attributes.
• Ran a custom Kerberos tool with Kerberoasting functionality and ran a password spray from the appliance.
• Ran a renamed tcpdump (dsstatmond) from a hidden directory to capture traffic, then parsed it for plaintext LDAP, HTTP Basic and NTLM challenge-response material.
• Pulled usernames out of the appliance’s event logs and read configuration directories.
• Truncated and rewrote /home/runtime/dlogs/debuglog and /var/log/audit/audit.log to remove entries from the time window they were active.

Volexity assesses with high confidence that the operation was preparing for lateral movement, and with medium confidence that the actor used LLMs for exploit development and post-exploitation tooling. It holds low confidence that the motivation is criminal rather than espionage.

Am I affected?

You should treat yourself as in scope if:

• You run Ivanti Connect Secure on the 22.8 or 25.1 branches and were not on a fixed release before mid-October. The compromised appliance Volexity examined ran 22.8R2.4 (Build 19097) and was “fully patched at the time.” According to SecurityOnline, 22.7.x and earlier are not affected.
• Your ICS web interface was reachable from the internet (that is the point of a VPN, so almost everyone). Shadowserver tracks “over 5,600 Internet-exposed hosts with ICS fingerprints” (BleepingComputer).
• The appliance holds an LDAP/AD service account. If it was compromised, assume that account and everything it can read are exposed.

Fixed versions. Ivanti’s 13 October releases for CVE-2026-104935 were 22.8R2.5, 25.1.3.0, 25.1.3.1 and 25.1.1.2 (BleepingComputer). The 29 October update “lists versions 25.1.1.3 and 22.8R2.6 as resolving the disclosed vulnerabilities” (GBHackers). Secondary sources disagree on some details, so confirm the exact build for your branch in Ivanti’s advisory and install the newest release it lists. A build that was patched on 13 October is not enough: it does not include the 29 October privilege-escalation fix.

Severity. Reported scores: CVE-2026-104935 is rated CVSS 8.6. CVE-2026-111357 is 7.0 in the MITRE CVE record (local vector, because it needs a foothold first), while some outlets report 8.8. CVE-2026-118527 is reported at 4.3. Don’t let the middling numbers fool you. Chained, they mean unauthenticated root on your network edge.

Step 1: Patch, and know what patching doesn’t do

Upgrade every ICS node, including standby cluster members, to the latest fixed release for your branch. Patching closes the door. It does not evict anyone who already came in, and it does not give back stolen credentials. That’s why the hunting below matters even if you patched on day one.

Step 2: Hunt at the edge

UTA0576 cleaned the appliance’s logs, not yours. Anything that records requests in front of the appliance (a reverse proxy, load balancer, WAF, NDR sensor with TLS inspection) or syslog the appliance already forwarded to your SIEM is evidence they could not edit.

Indicators published by Volexity

IP (attacker VPS, OpenVPN 30 Sep ~|-| 7 Oct 2026):  108.165.147[.]64
Pre~|-|auth URL abused:                            /dana~|-|na/auth/url_default/welcome.cgi
Routing header values seen:                     X~|-|DSCGI~|-|PATH: /home/webserver/htdocs/dana/fb/smb/wu.cgi
                                                X~|-|DSCGI~|-|PATH: /home/runtime/tmp/~|<|md5 of filename>
On~|-|appliance artefacts:                         /data/.icscap/ (h.py, cap*, dsstatmond)
                                                /tmp/ml.py /tmp/rq5.py /tmp/mk.py /tmp/rr.py
                                                /tmp/sp_run.py /tmp/sp_out.txt /tmp/spray_hits.json /tmp/pu.txt
                                                /home/runtime/tmp/ics~|-|root~|-|run~|-|inband~|-|*.pl
                                                /home/runtime/tmp/ics~|-|root~|-|result~|-|inband~|-|*

Volexity also publishes machine-readable indicators on its threat-intel GitHub. Pull them into your TIP rather than copying by hand.

Detection logic

Volexity’s two network detections are simple: watch for high volumes of requests to welcome.cgi (the race needs many parallel attempts) and alert when the URL path and the X-DSCGI-PATH header don’t match. A legitimate client has no reason to send that internal header at all.

Splunk, against proxy/WAF/load-balancer logs (adjust index and field names to your data):

index~|=|edge (dest_host~|=|"vpn.example.com" OR dest_ip~|=|~|<|ICS_PUBLIC_IP>)
  uri_path~|=|"/dana~|-|na/auth/url_default/welcome.cgi"
| bin _time span~|=|1m
| stats count AS hits, dc(http_method) AS methods, values(http_user_agent) AS ua BY _time, src_ip
| where hits > 30
| sort ~|-| hits

index~|=|edge (dest_ip~|=|~|<|ICS_PUBLIC_IP>) "X~|-|DSCGI~|-|PATH"
| table _time src_ip uri_path http_header_x_dscgi_path http_user_agent status

Microsoft Sentinel (KQL), if your WAF or Application Gateway logs land in CommonSecurityLog or a custom table:

let ics ~|=| dynamic(["203.0.113.10"]); // your ICS public IPs
CommonSecurityLog
| where TimeGenerated > ago(45d)
| where DestinationIP in (ics) or SourceIP ~|=|~|=| "108.165.147.64"
| where RequestURL has "/dana~|-|na/auth/url_default/welcome.cgi" or SourceIP ~|=|~|=| "108.165.147.64"
| summarize hits ~|=| count(), first ~|=| min(TimeGenerated), last ~|=| max(TimeGenerated) by SourceIP, bin(TimeGenerated, 5m)
| where hits > 30 or SourceIP ~|=|~|=| "108.165.147.64"
| order by hits desc

A Sigma rule for webserver-style logs that capture request headers:

title: Ivanti ICS Internal Routing Header In External Request
id: e6bd408f~|-|3897~|-|45de~|-|9856~|-|9c58a2430f18
status: experimental
description: Detects requests carrying the internal X~|-|DSCGI~|-|PATH header, abused by UTA0576 (Volexity, Oct 2026)
logsource:
  category: webserver
detection:
  selection_uri:
    cs~|-|uri~|-|stem|contains: '/dana~|-|na/auth/url_default/welcome.cgi'
  selection_hdr:
    cs~|-|headers|contains: 'X~|-|DSCGI~|-|PATH'
  condition: selection_uri and selection_hdr
falsepositives:
  ~|-| None expected from legitimate clients
level: high

Look back at least to late September. Exploitation was seen from 1 October, and the attacker’s infrastructure was live from 30 September.

Step 3: Hunt in Active Directory (the part they couldn’t hide)

Because UTA0576 used the appliance’s AD service account, its post-exploitation activity shows up on your domain controllers. Start by noting two things: the name of the ICS LDAP/AD service account, and the internal IP(s) the appliance uses to talk to DCs. Then look for that account or IP doing things a VPN never does:

• Kerberoasting: a burst of Kerberos service ticket requests (Event ID 4769) from the appliance IP, especially requesting RC4 (ticket encryption type 0x17) for many different service accounts.
• Password spraying: many failed logons (Event IDs 4625 and 4771) across different usernames originating from the appliance IP, outside normal VPN authentication patterns.
• LAPS and BitLocker reads: if you audit directory service access (Event ID 4662), look for the service account reading LAPS password or BitLocker recovery attributes. Most VPN service accounts should never be able to read these at all; if yours can, that’s a finding on its own.
• Unusual LDAP volume: large subtree searches by the service account, if your DCs or an identity tool log LDAP queries.

KQL for Defender for Identity / Sentinel with Windows Security Events:

let icsIP ~|=| "10.10.10.5";          // ICS internal interface
let icsSvc ~|=| "svc~|-|ics~|-|ldap";       // ICS AD service account
SecurityEvent
| where TimeGenerated > ago(45d)
| where (EventID ~|=|~|=| 4769 and IpAddress has icsIP)
     or (EventID in (4625, 4771) and IpAddress has icsIP)
     or (EventID ~|=|~|=| 4662 and SubjectUserName ~|=|~ icsSvc)
| summarize events ~|=| count(), targets ~|=| dcount(TargetUserName) by EventID, bin(TimeGenerated, 10m)
| where targets > 10 or EventID ~|=|~|=| 4662
| order by TimeGenerated asc

Any hit here is a reason to escalate to full incident response, not just patching.

Step 4: If you think you were hit

CISA’s guidance for compromised appliances, summarised by BleepingComputer:

1. Back up the appliance configuration (Ivanti KB44759).
2. Factory reset and upgrade to the latest version. For cloud or virtual appliances, rebuild the instance and upgrade.
3. Restore the configuration from the backup.
4. Reset passwords for all accounts, including domain, administrator and local accounts. Revoke and reissue stored certificates. Reset stored API keys and license server credentials.

Add to that, based on what UTA0576 targeted:

• Rotate every LAPS password and treat BitLocker recovery keys readable by the service account as exposed. Re-key affected devices.
• Reset the passwords of any service accounts with SPNs, prioritising those with weak or old passwords, since Kerberoasted hashes can be cracked offline.
• Capture memory and disk images before you rebuild if you want answers. GBHackers notes that “memory captures, disk images, and exploitation-related core dumps proved essential” in this case, and a clean integrity check “alone does not exclude compromise.”
• Hunt for lateral movement from the appliance’s internal IP to servers and workstations.

Prioritised checklist

Immediately (today)

• Upgrade all ICS nodes to the newest release in Ivanti’s 29 October advisory.
• Block 108.165.147[.]64 and load Volexity’s indicators into your SIEM/TIP.
• Run the welcome.cgi volume and X-DSCGI-PATH searches back to late September.
• Run the AD hunts against the ICS service account and appliance IP.

This week

• Restrict the ICS service account: remove rights to read LAPS and BitLocker attributes, and scope it to only the OUs it needs.
• Make sure ICS syslog is forwarded off-box in real time, so local log tampering can’t erase your evidence.
• Restrict the admin interface to a management network; never expose it to the internet.
• Review which other credentials, certificates and API keys live on the appliance, and document how to rotate them quickly.

Longer term

• Treat VPN appliances as tier-0 assets: monitor them with NDR, and alert on any connection from the appliance to DCs that isn’t authentication.
• Move service accounts to gMSAs or long random passwords with AES-only Kerberos to blunt Kerberoasting.
• Evaluate a migration path. Edge appliances with repeated zero-days deserve a hard look at ZTNA alternatives and at architecture that limits what a compromised gateway can reach.

OffensioX perspective

This case is a preview of where edge attacks are going. Ivanti appliances are familiar targets: per BleepingComputer, CISA’s KEV catalog lists 36 Ivanti vulnerabilities since November 2021, 12 of them used in ransomware. What stands out here is not the bug class but the tradecraft: no persistence on disk, no C2 beacon, surgical log editing, and an operator that went straight for the identity layer. If Volexity is right that the actor leaned on LLMs to build exploits and tooling, expect that tempo to become normal. The practical lesson is that you cannot rely on the appliance to tell you whether the appliance is compromised. The evidence lives in your edge logs and your directory, and the damage is limited by how little your VPN’s service account is allowed to see. For many organisations in Pakistan and the wider region, the SSL VPN is the perimeter, which makes this a board-level risk, not just a patching task.

If you’d like a second pair of eyes, OffensioX runs penetration tests and security assessments of remote-access infrastructure and Active Directory, including the attack paths an edge compromise would open.

References

• Volexity: A Series of Unauthenticated Events – Chained Exploitation of Ivanti Connect Secure Zero-Days
• Ivanti Security Advisory: Ivanti Connect Secure (CVE-2026-104935)
• BleepingComputer: CISA warns admins to immediately fix Ivanti flaw exploited as zero-day
• GBHackers: Hackers Exploit Ivanti Connect Secure Zero-Day Vulnerabilities to Gain Root Access and Steal Credentials
• OpenCVE: CVE-2026-111357 (CVE record and KEV history)
• SecurityOnline: Ivanti Connect Secure Vulnerability Exploited in the Wild via Zero-Day Chain
• Volexity threat-intel indicators on GitHub
• CISA Known Exploited Vulnerabilities Catalog