How to Detect Ivanti Connect Secure Exploitation

To detect Ivanti Connect Secure exploitation from the October 2026 chain, look in three places: request logs in front of the appliance, network traffic leaving it, and the appliance's own logs and file system. Volexity, which found the attacks, warns that the Ivanti Integrity Checker can miss this compromise because the root step lived in memory. This guide covers the signals Volexity published and how to work through them before and after you upgrade.

Why upgrading alone does not answer the question

The fix for the full chain is ICS 25.1.1.3 or 22.8R2.6, released October 29, 2026. Upgrading closes the flaws. It does not tell you whether the actor, tracked by Volexity as UTA0576, already used them. That actor deployed no web shell or malware, ran commands through the exploit requests themselves, harvested credentials and then cleaned up logs. A box can be patched, pass an integrity check and still have handed over your LDAP bind account in October.

Background on the vulnerabilities is in our report on the Ivanti Connect Secure CVE-2026-111357 fix.

How do you detect Ivanti Connect Secure exploitation?

You detect it by correlating unusual requests to the appliance's public login CGI with outbound traffic, unexpected processes and gaps in the appliance logs. No single signal is conclusive, so collect all of them for the window from late September onward.

Exploitation started no later than October 3, 2026, according to Volexity. Defused reported decoy hits from October 1. Use September 30 as the start of your review window.

Step 1: Review requests to the login endpoints

Volexity's network guidance focuses on the authentication bypass stage:

• A high volume of requests to welcome.cgi (the public login page under /dana-na/auth/url_default/) from one source.
• Requests carrying an X-DSCGI-PATH header, especially values that point to wu.cgi or to paths under /home/runtime/tmp/.
• Any mismatch between the requested URL path and the path named in that header. Legitimate traffic should not produce one.

Where you can see this depends on where TLS ends. If a load balancer, reverse proxy or WAF terminates TLS in front of the appliance, its request logs can show headers and paths. If the appliance terminates TLS itself, a network sensor sees only encrypted sessions, so you are limited to request volume, timing and source addresses.

Check sources against the actor infrastructure Volexity published, including 108.165.147[.]64, and the full list in Volexity's GitHub indicator repository.

Step 2: Look for traffic the appliance should not generate

UTA0576 spent its time on credential theft and reconnaissance. From the network side, that shows up as:

• LDAP queries from the appliance's service account for attributes a VPN never needs, such as LAPS passwords and BitLocker recovery keys.
• Kerberos service ticket requests for many accounts in a short window from the appliance (Kerberoasting).
• Failed logins across many domain accounts originating from the appliance (password spraying).
• Unusual DNS lookups of internal names.
• Large or regular HTTPS responses back to the same external source that sent the exploit requests, since output was exfiltrated through that channel.

Your domain controller security logs and your SIEM are the best place to find these. The appliance itself may have had its local logs edited.

Step 3: Check the appliance itself

Volexity listed host artifacts. Look for:

• Files in /tmp/ that do not belong to the product, including scripts named ml.py, rq5.py, mk.py, rr.py or sp_run.py, and output files such as spray_hits.json or pu.txt.
• Packet capture files under /data/.icscap/, and a process named dsstatmond, which the actor used as a renamed tcpdump.
• A process running from a hidden directory, or unexpected raw socket sniffing.
• A Python 3.6 virtualenv execution path used by the actor's tooling.

Most organizations cannot browse the appliance file system freely. Use Ivanti's supported collection methods or open a case with Ivanti or your incident response provider, and say which artifacts you need checked.

What logs did the attackers tamper with?

They removed selected entries from the appliance debug log and the Linux audit log, according to Volexity. Gaps or missing time ranges in those logs during October are a signal in themselves.

Volexity names the two files as /home/runtime/dlogs/debuglog and /var/log/audit/audit.log. If you forward appliance logs to a syslog server or SIEM, compare the forwarded copy with what is still on the box. Entries present in the SIEM but missing locally point to tampering. If you do not forward these logs today, start now.

Step 4: Decide, then act

Work out which of three outcomes applies to each appliance:

1. No exposure. The appliance was not reachable from the internet during the window, or ran a branch outside the affected list. Upgrade and record the evidence.
2. Exposure, no signals. Upgrade, keep monitoring, and rotate the LDAP bind account anyway. The cost is low and the actor cleaned up after itself.
3. Signals found. Treat it as an incident. Preserve memory and network evidence before rebuilding, follow Ivanti's recovery steps, and assume every credential the appliance could read is exposed.

For outcome 3, follow how to contain Active Directory exposure after a VPN appliance is compromised. For why a passing integrity check is not evidence of a clean box, see why a clean integrity check cannot clear a compromised appliance.

Keep watching after the upgrade

Plan the next round too. Ivanti fixed this chain in two releases two weeks apart. Our guide on why partial security patches mean upgrading twice covers how to keep a ticket open until the whole chain is closed. For the upload bug's class, see what a predictable identifier vulnerability is.