Ivanti Connect Secure Zero-Day Chain Enables Unauthenticated Root Access

Published on October 28, 2026 | By Focused Hunts

A still-unidentified group broke into a company's network through the VPN appliance employees use to log in remotely. The attackers chained two separate flaws together: one let them in without a password, and the second let them act as the system's most powerful user. Researchers who caught the activity assess with medium confidence that the group used AI tools to help build its attack code.

A package sorting center that waves through any box carrying the right internal routing sticker never checks who printed it. The attackers' web requests carried the internal marking the VPN appliance trusts from its own software, so it routed them straight to restricted functions with no login required. A second flaw let those same requests edit the center's employee roster, so the intruder's traffic started looking like it came from trusted staff instead of a stranger.

Once inside, the attackers collected domain passwords, drive recovery keys, and the passwords used to manage local administrator accounts. They also pulled directory data and network details attackers use to plan deeper moves into a network. The intrusion was caught and disrupted before the group could use what it stole, but any organization running the affected VPN software faces the same theft until it patches.

Hunting Controls & Observations

Organizations can detect this activity through telemetry on the appliance's host, the network perimeter, and the identity infrastructure it reached:

Appliance & Endpoint Controls: ICS appliance debug and authentication logs, Linux audit logs (auditd), and process telemetry on any Linux host running a general-purpose EDR agent
Network Controls: perimeter firewall and reverse-proxy logs for the VPN's public web interface, NetFlow, and DNS resolution logs
Identity & Access Controls: domain controller Security event logs (Event ID 4768, 4769, 4625) and Entra ID sign-in logs for any hybrid-joined accounts
Privileged Access Management: LAPS console logs and BitLocker recovery key retrieval auditing in Active Directory

Behavioral Indicators of Attack

Specific behaviors Volexity documented in this campaign:

An uploaded file named like a .zip archive is actually a Perl script that the web interface executes directly, the entry point for the rest of the chain.
That Perl script launches a Bash script, which decodes and runs a Python payload from Base64 and zlib-compressed text using Python's exec() function, so the payload never exists as a file on disk before it runs.
A copy of a standard packet-capture utility runs under the name dsstatmond, a name that matches the appliance's own status-monitoring processes rather than any capture tool, and sniffs network traffic continuously.
The appliance's own CGI-serving process has its in-memory copy of a shared library patched to alter a cached data entry, which a separate privileged helper process then trusts when asked to run a script as root.
Automated password-spraying attempts against domain accounts are followed by pulling valid usernames straight out of the authentication log rather than guessing them.
LDAP directory query results are compressed, Base64-encoded, and packaged as JSON before leaving the appliance over the same web session used for everything else.
Debug logs, audit logs, and authentication logs are repeatedly truncated or rewritten, and every temporary file the actor creates is deleted immediately after use.
Kerberos service ticket requests consistent with Kerberoasting are issued from the compromised appliance against the broader Active Directory domain.

MITRE Enterprise ATT&CK Tactics and Techniques

MITRE ATT&CK mapping for UTA0576's exploitation chain:

Initial Access (T1190 – Exploit Public-Facing Application): Volexity states the group reached an unauthenticated appliance function through crafted requests to the VPN's web login interface, exploiting CVE-2026-104935 before a patch existed.
Execution (T1059.004 – Unix Shell): Volexity observed an uploaded Perl script run a Bash script, which decodes and launches a Python payload entirely in memory on the compromised appliance.
Defense Evasion (T1027 – Obfuscated Files or Information): The in-memory Python payload is decoded from Base64 and zlib compression before execution, a step Volexity documented as how the actor avoided leaving a readable script on disk.
Privilege Escalation (T1068 – Exploitation for Privilege Escalation): A second, still-unpatched flaw lets the attacker alter a cached data structure the system's privileged background process trusts, which Volexity observed being used to run a malicious script as root.
Defense Evasion (T1036 – Masquerading): The actor renamed a packet-capture utility to dsstatmond, a name resembling the appliance's own status-monitoring processes, as directly observed during the investigation.
Defense Evasion (T1070.004 – File Deletion): Volexity documented the actor truncating and rewriting debug and authentication logs and deleting its own temporary files after each step.
Credential Access (T1040 – Network Sniffing): The renamed capture utility ran continuously to sniff appliance network traffic, a capability Volexity confirmed was active during the intrusion.
Credential Access (T1110.003 – Password Spraying): Volexity states the actor ran password-spraying attempts against domain accounts directly from the compromised appliance.
Credential Access (T1558.003 – Kerberoasting): The source documents the actor requesting Kerberos service tickets, consistent with Kerberoasting, to obtain crackable credential material for domain accounts.
Discovery (T1087 – Account Discovery): Volexity observed the actor pulling valid usernames directly out of the appliance's own authentication logs rather than guessing them, narrowing its password-spraying targets.
Exfiltration (T1041 – Exfiltration Over C2 Channel): LDAP query results, a packet capture excerpt, and the appliance's DNS configuration file were compressed and encoded for transfer back over the same HTTPS session used for every other step, a pattern Volexity says left no separate command-and-control channel to find.

Controls' Observables

Identity & Access Controls

Domain controllers log every Kerberos ticket request and every logon attempt, so this activity is fully visible if anyone is watching the right events.

Service ticket requests from an appliance's service account, not a person: domain controllers record Event ID 4769 for every ticket issued, but most organizations never baseline which accounts request service tickets from which source, so a burst of requests for many different services from one non-interactive account blends into routine Kerberos traffic.
Related MITRE Techniques: T1558.003
Detection Difficulty: MODERATE
Failed logons spread across many accounts from one source: domain controllers record every failed logon, but most lockout and anomaly alerting is tuned to repeated failures against a single account, not a handful of attempts against many accounts, so spraying patterns need a distinct-account threshold to surface.
Related MITRE Techniques: T1110.003
Detection Difficulty: EASY

Network & Perimeter Controls

Firewall and reverse-proxy logs capture every inbound request to the VPN's public login page, but most organizations treat that traffic as routine and do not inspect it closely.

A single external address generating the exploit traffic: the address is a plain data-center VPS with no legitimate business reason to reach the appliance, so any logged connection from it is a near-certain positive once an organization knows to look.
Related MITRE Techniques: T1190
Detection Difficulty: EASY

Appliance & Endpoint Controls

Few organizations run a general-purpose EDR agent on a VPN appliance, since it is sold and managed as a closed virtual appliance rather than a general server; that absence is the real gap this threat exposes.

A renamed network-capture process running continuously: a process allowlist built from approved binary names would reject this one on sight, since its name was never on that list, but the control only has eyes on the problem where an agent is actually installed, which most VPN appliances lack.
Related MITRE Techniques: T1036, T1040
Detection Difficulty: HARD

Privileged Access Management Controls

LAPS and BitLocker both log every time their stored secrets are read, which most organizations collect but rarely alert on.

Retrieval of local administrator passwords or drive recovery keys tied to the VPN appliance's own domain computer account: a read of these values from an account or process that does not normally manage endpoints is unusual enough to alert on directly.
Related MITRE Techniques: T1552
Detection Difficulty: MODERATE

Insights and Recommendation

Organizations that miss this exposure face theft of domain account passwords, LAPS local administrator passwords, and BitLocker recovery keys pulled directly from Active Directory, the exact material an attacker needs to move laterally and unlock encrypted endpoints without ever deploying malware a security tool would flag. Volexity disrupted this specific operation before the actor could use what it collected, but the LDAP queries, packet capture, and Kerberos activity all point toward preparation for deeper access into the network. Any organization that has not patched the authentication bypass and remote code execution flaw, or that has no mitigation for the still-open privilege escalation bug, faces the same exposure today.

Security teams should patch Ivanti Connect Secure to the fixed builds immediately for the authentication bypass and remote code execution flaw, and treat the still-open privilege escalation bug as unresolved risk until Ivanti ships a fix, since the first flaw alone does not require it to grant unauthenticated access. Hunt for Kerberoasting and password-spray patterns originating from the VPN appliance's own service account, not just from end-user accounts, and route LAPS and BitLocker key retrieval events to the same alerting that covers administrator password use. Forward appliance debug, audit, and authentication logs to a central log store in real time, since this actor truncates and deletes them locally within the same session it uses them.

As of 2026-10-18, AbuseIPDB lists the attacker's staging host, 108.165.147.64, with a 36 percent abuse confidence score across 10 reports, tagged as data center and web hosting infrastructure consistent with Volexity's identification of it as an Evoxt-hosted VPS. As of 2026-10-28, AlienVault OTX carries five separate threat-intelligence pulses referencing this exploit chain, one of which records that CISA added CVE-2026-104935 to its Known Exploited Vulnerabilities catalog with an October 16, 2026 remediation deadline for federal civilian agencies.

Source and Credits

This summary is based on Volexity's research article "A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days" published on October 13, 2026.

Darknet CTI corroboration (Focused Hunts) adds infrastructure and vulnerability-status context from AbuseIPDB and AlienVault OTX, checked October 18, 2026 and October 28, 2026 respectively.

Threat Hunting IOCs & Queries

This section contains indicators of compromise from Volexity's report and threat hunting queries for the behaviors above.

Known Indicators of Compromise

IP Addresses: 108.165.147.64 - Evoxt-hosted VPS that ran UTA0576's OpenVPN server from September 30 to October 7, 2026, the window Volexity ties to this campaign's staging infrastructure (AbuseIPDB: 36% confidence, 10 reports, Data Center/Web Hosting, as of 2026-10-18; AlienVault OTX: 5 pulses referencing this campaign, as of 2026-10-28)
File Paths: /home/runtime/tmp/ics-root-run-inband-*.pl (malicious Perl script run as root), /home/runtime/tmp/ics-root-result-inband-* (result file from the root-run script), /data/.icscap/dsstatmond (renamed packet-capture binary), /data/.icscap/h.py (Python tooling staged in the hidden capture directory), /data/.icscap/cap* (packet capture files), /tmp/ml.py and /tmp/rq5.py (custom LDAP query tooling), /tmp/mk.py (custom Kerberos tooling), /tmp/rr.py and /tmp/sp_run.py (supporting scripts), /tmp/pu.txt, /tmp/sp_out.txt, and /tmp/spray_hits.json (output files from password-spraying and reconnaissance tooling)
Request Header Values: X-DSCGI-PATH: /home/webserver/htdocs/dana/fb/smb/wu.cgi (header value used to trigger the authentication bypass), X-DSCGI-PATH: /home/runtime/tmp/<MD5(filename)> (header pattern used against uploaded files)

These indicators are current to Volexity's October 13, 2026 report and the October 10, 2026 indicator sharing that preceded it; the live-status AbuseIPDB and OTX annotations above come from a separate darknet corroboration check on the dates shown next to each value. UTA0576's staging host was already offline by October 7, 2026 per Volexity's own timeline, so the file paths and the behavioral queries below will outlast this one IP by far. An appliance clean of these exact file names today says nothing about whether the same chain hits it tomorrow under a renamed set of files.

Kerberoasting Ticket Requests Targeting Non-Standard Service Accounts

Priority: High - explicitly named by Volexity as part of this campaign; Credential Access impact; Tier 1 Windows Security telemetry.
Behavior Targeted: Flags any account requesting Kerberos service tickets (Event ID 4769) for an unusually wide range of distinct services, excluding machine and krbtgt tickets, from one source address in a seven-day window.
MITRE ATT&CK: T1558.003
Telemetry Required: Windows Security Event ID 4769 (Kerberos TGS request) forwarded via Splunk_TA_windows, or the SecurityEvent table in Microsoft Sentinel from domain controllers.
Expected Results: One account/IP pair requesting tickets for many distinct service names in a short window, especially an account that does not normally request tickets at that volume.
False Positive Likelihood: MEDIUM - backup agents and some SPN-heavy applications request many service tickets; exclude known service accounts by name.
Tuning Guidance: Adjust the distinct-service threshold (currently 15) and the time window to match the environment's normal ticket-request volume.

Splunk SPL Query

index=* (source="XmlWinEventLog:Security" OR source="WinEventLog:Security") EventCode=4769 earliest=-7d
    NOT ServiceName="*$" NOT ServiceName="krbtgt"
| stats dc(ServiceName) AS distinct_services count min(_time) AS first_seen max(_time) AS last_seen by TargetUserName, IpAddress
| where distinct_services > 15
| sort - distinct_services
| convert ctime(first_seen) ctime(last_seen)

Microsoft KQL Query (Defender/Sentinel)

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4769
| where ServiceName !endswith "$" and ServiceName != "krbtgt"
| summarize DistinctServices = dcount(ServiceName), Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by TargetUserName, IpAddress
| where DistinctServices > 15
| order by DistinctServices desc

Password Spray Against Many Domain Accounts From a Single Source

Priority: High - explicitly named by Volexity as part of this campaign; Credential Access impact; Tier 1 Windows Security telemetry.
Behavior Targeted: Flags any source address producing bad-password failed logons (Event ID 4625, SubStatus 0xC000006A) against an unusually wide set of distinct target accounts in a seven-day window.
MITRE ATT&CK: T1110.003
Telemetry Required: Windows Security Event ID 4625 (failed logon) forwarded via Splunk_TA_windows, or the SecurityEvent table in Microsoft Sentinel from domain controllers or the authenticating endpoint.
Expected Results: One source address touching 10 or more distinct target accounts with failed logons, with few or no successes from the same address.
False Positive Likelihood: MEDIUM - a misconfigured service account or shared workstation can also fan out failed logons; exclude known service hosts and tune the distinct-account threshold.
Tuning Guidance: Adjust the distinct-account threshold (currently 10) and correlate with an eventual successful logon from the same source for higher-confidence alerting.

Splunk SPL Query

index=* (source="XmlWinEventLog:Security" OR source="WinEventLog:Security") EventCode=4625 earliest=-7d
    (SubStatus="0xC000006A" OR Sub_Status="0xC000006A")
| stats dc(TargetUserName) AS distinct_accounts count min(_time) AS first_seen max(_time) AS last_seen by src_ip
| where distinct_accounts > 10
| sort - distinct_accounts
| convert ctime(first_seen) ctime(last_seen)

Microsoft KQL Query (Defender/Sentinel)

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4625
| where SubStatus == "0xC000006A"
| summarize DistinctAccounts = dcount(TargetUserName), Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by IpAddress
| where DistinctAccounts > 10
| order by DistinctAccounts desc

Legitimate Packet-Capture Binary Running Under a Disguised Process Name

Priority: High - observed directly in this campaign; Defense Evasion and Credential Access impact; Tier 1 endpoint telemetry once process monitoring covers the host.
Behavior Targeted: Flags a process carrying tcpdump-style capture arguments (interface or write-to-file flags) whose binary name does not match any known tcpdump-family tool, the pattern Volexity found in the renamed dsstatmond process.
MITRE ATT&CK: T1036, T1040
Telemetry Required: Endpoint process creation telemetry with command-line visibility (Sysmon, Microsoft Defender for Endpoint) on any Linux host or jump server an actor could pivot through; most closed VPN appliances do not expose this telemetry directly.
Expected Results: A process whose FileName/process_name is not tcpdump, tshark, dumpcap, or windump, but whose command line carries capture-style flags and a target interface or output file.
False Positive Likelihood: LOW - legitimate network tools rarely run under a disguised name with these specific flags; allowlist known custom monitoring agents by full path.
Tuning Guidance: Expand the expected-binary allowlist for the environment and extend the argument pattern to cover other capture utilities as needed.

Splunk SPL Query

| tstats summariesonly=false count min(_time) AS first_seen max(_time) AS last_seen
    from datamodel=Endpoint.Processes
    where earliest=-7d (Processes.process="*-i *" OR Processes.process="*-w *")
        NOT Processes.process_name IN ("tcpdump","tshark","dumpcap","windump")
    by Processes.dest Processes.process_name Processes.process Processes.parent_process_name
| rename Processes.* AS *
| sort - count
| convert ctime(first_seen) ctime(last_seen)

Microsoft KQL Query (Defender/Sentinel)

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("-i ", "-w ")
| where FileName !in~ ("tcpdump", "tshark", "dumpcap", "windump")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

IOC Sweep: UTA0576 Attacker Infrastructure

Priority: Medium - the only attacker-controlled address in the source; the underlying CVE is KEV-listed per AlienVault OTX corroboration (2026-10-28); kept for Initial Access tactic coverage despite indicator-only durability.
Behavior Targeted: Sweeps perimeter network telemetry for any connection to or from the single IP address Volexity tied to UTA0576's staging infrastructure.
MITRE ATT&CK: T1190
Telemetry Required: Perimeter firewall or reverse-proxy logs (Splunk Network_Traffic CIM data model) or CommonSecurityLog in Microsoft Sentinel.
Expected Results: Any logged connection at all should be treated as a near-certain positive, since the address is a dedicated attacker VPS with no legitimate business relationship to the organization.
False Positive Likelihood: LOW - hosting-provider VPS with no benign reason to appear in production traffic.
Tuning Guidance: Extend the sweep window once appliance-level access logs are forwarded centrally, and retire this indicator on schedule since UTA0576 is known to rotate its staging infrastructure.

Splunk SPL Query

| tstats summariesonly=false count min(_time) AS first_seen max(_time) AS last_seen
    from datamodel=Network_Traffic
    where earliest=-30d All_Traffic.src_ip="108.165.147.64"
    by All_Traffic.dest_ip All_Traffic.dest_port All_Traffic.action
| rename All_Traffic.* AS *
| sort - count
| convert ctime(first_seen) ctime(last_seen)

Microsoft KQL Query (Defender/Sentinel)

CommonSecurityLog
| where TimeGenerated > ago(30d)
| where SourceIP == "108.165.147.64"
| summarize Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DestinationIP, DestinationPort, DeviceAction
| order by Count desc

Note: These queries were generated with AI assistance and are a starting point for threat hunting and detection rule considerations.

Back to Hunting off the Red