Ivanti Connect Secure Zero-Day Exploited After Vendor Deferred Fix — Detection and Emergency Response Guide

This story should be required reading for every vulnerability management team and every vendor risk program: Ivanti internally discovered a portion of the defect in its Connect Secure VPN appliance during routine security checks in June — and concluded it didn't meet the threshold for an out-of-band patch release. Threat actors disagreed. The vulnerability was subsequently weaponized and exploited in the wild as a zero-day, turning a fixable internal finding into active compromise of customer edge infrastructure.

If you run Ivanti Connect Secure (ICS), Ivanti Policy Secure, or Ivanti Neurons for ZTA gateways, treat this as an active incident until proven otherwise. Edge VPN appliances are the single most attractive initial-access target in enterprise environments right now: they sit at the perimeter, terminate authenticated sessions, run with elevated privileges, and historically ship with weak logging and no EDR coverage. When one falls, the attacker owns the front door.

Why This Matters Beyond the CVE

The technical vulnerability is only half the story. The other half is a governance failure that defenders need to internalize:

• Vendor triage thresholds are not your risk thresholds. Ivanti's internal scoring said 'wait for the regular release cycle.' The threat landscape said otherwise. If your patch prioritization blindly mirrors vendor severity ratings, you inherit their blind spots.
• Edge appliances remain defense-in-depth deserts. No EDR, minimal telemetry, proprietary OS images, and (in many environments) internet-facing management interfaces. Detection depends almost entirely on network-side observation and the vendor's own Integrity Checker Tool (ICT).
• Post-exploitation on ICS follows a predictable playbook. Web shells dropped into the appliance filesystem, log tampering or selective log deletion, credential harvesting from the VPN session store, and lateral movement into internal segments the appliance can reach.

Technical Analysis

Affected Products

Based on the reported exploitation and Ivanti's advisory history for this product line, organizations should immediately verify exposure across:

• Ivanti Connect Secure (ICS) — VPN gateways, all supported version trains pending the vendor patch
• Ivanti Policy Secure (IPS) — NAC appliances sharing the codebase
• Ivanti Neurons for ZTA gateways

Check your exact firmware train against the current Ivanti security advisory at the Ivanti Security Advisories portal (https://www.ivanti.com/blog/security-update) and cross-reference CISA's Known Exploited Vulnerabilities catalog, which has historically added ICS flaws within 24-48 hours of confirmed exploitation.

Exploitation Pattern (Defender's View)

While Ivanti has not fully disclosed the defect mechanics, exploitation of this class of ICS vulnerability — and the observed post-compromise tradecraft on this platform — follows a consistent chain:

1. Initial access via the internet-facing web component of the appliance, often without valid credentials.
2. Arbitrary command execution or file write in the context of the web service, typically landing payloads in writable paths such as /home/runtime/tmp/, /data/runtime/, or overlay mounts used to persist across the appliance's read-only root.
3. Web shell deployment — historically lightweight Perl, Python, or shell scripts dropped under web-accessible directories (e.g., paths served by the appliance's internal web server), or legitimate system scripts modified in place (a technique Ivanti calls out in ICT guidance).
4. Defense evasion — log clearing or truncation in /home/var/log/ and /data/var/log/, disabling or bypassing the Integrity Checker Tool, and timestomping modified files.
5. Credential access and lateral movement — dumping cached credentials and session data, then pivoting over LDAP/SMB/RDP into the internal network the gateway serves.

Exploitation Status

• Confirmed active in-the-wild exploitation — this is a zero-day that was exploited before a patch existed. That is the entire point of the news item.
• Assume CISA KEV inclusion is imminent or already in effect; check https://www.cisa.gov/known-exploited-vulnerabilities-catalog and treat any listing's remediation deadline (typically 3 weeks for federal agencies, and a de facto standard for everyone else) as your outer bound — not your target.

Detection & Response

A candid note before the rules: an Ivanti appliance is not a Windows endpoint. Your highest-fidelity detection sources are (a) the appliance's own syslog forwarded off-box, (b) perimeter network telemetry, and (c) the Integrity Checker Tool. If you are not forwarding ICS syslog to your SIEM right now, that is gap zero — fix it before you deploy anything below.

Sigma Rules

These rules target the endpoint-side behaviors that follow appliance compromise — because once an attacker pivots off the VPN gateway, they land on your Windows and Linux estate. The first rule catches web-shell-style execution patterns on the appliance observable via forwarded syslog; the second catches the classic post-VPN-compromise pivot on internal Windows hosts.

---
title: Ivanti Connect Secure Web Service Spawning Shell or Script Interpreter
id: 4f7c2a91-8e3d-4b6a-9c15-2d8e6f1a3b47
status: experimental
description: Detects the ICS web service component spawning shell interpreters or script engines, consistent with web shell execution and post-exploitation activity on compromised VPN appliances. Requires ICS syslog or endpoint telemetry forwarded to the SIEM.
references:
  - https://cyberscoop.com/ivanti-connect-secure-zero-day-actively-exploited/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - '/home/bin/web'
      - 'dslogd'
      - 'httpd'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/perl'
      - '/python'
      - '/python3'
      - '/curl'
      - '/wget'
  condition: selection_parent and selection_child
falsepositives:
  - Rare legitimate appliance maintenance scripts invoked via the admin console
level: high
---
title: Ivanti Appliance Filesystem Write to Runtime or Web-Accessible Paths
id: 9b3e5d72-6a1f-4c48-b2d7-8e4a9f3c6d51
status: experimental
description: Detects file creation in writable runtime and web-served directories on Ivanti appliances, a hallmark of web shell deployment and persistence via overlay mounts. Match against forwarded ICS file/audit syslog.
references:
  - https://cyberscoop.com/ivanti-connect-secure-zero-day-actively-exploited/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/home/runtime/tmp/'
      - '/data/runtime/'
      - '/home/webserver/'
  selection_ext:
    TargetFilename|endswith:
      - '.pl'
      - '.py'
      - '.sh'
      - '.cgi'
      - '.php'
  condition: selection_path and selection_ext
falsepositives:
  - Vendor updates and ICT scans creating temporary artifacts; verify against change windows
level: high
---
title: Internal Lateral Movement Sourced From VPN Gateway Subnet
id: 2c8f4e61-7d3a-4b95-a6e2-1f5d8c3b9a74
status: experimental
description: Detects administrative protocol connections (SMB, RDP, WinRM) originating from VPN gateway or appliance network segments toward internal servers, consistent with post-compromise pivoting from a breached edge device.
references:
  - https://cyberscoop.com/ivanti-connect-secure-zero-day-actively-exploited/
  - https://attack.mitre.org/techniques/T1021/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.lateral_movement
  - attack.t1021
logsource:
  category: network_connection
  product: windows
detection:
  selection_port:
    DestinationPort:
      - 445
      - 3389
      - 5985
      - 5986
  selection_src:
    SourceIp|startswith:
      - '10.254.'
      - '172.31.254.'
  condition: selection_port and selection_src
falsepositives:
  - Legitimate gateway health checks and DNS/AD integration traffic; tune SourceIp ranges to your actual appliance subnets
level: medium

Tune the SourceIp prefixes in the third rule to your actual ICS appliance and VPN address-pool ranges before deployment — the placeholders will not match your environment as written, and that is intentional.

KQL — Microsoft Sentinel / Defender

This hunts forwarded ICS syslog (via CEF or Syslog ingestion) for exploitation indicators, then pivots to network telemetry for connections from the appliance into your internal estate. The first query looks for the exploitation and post-exploitation string patterns Ivanti and incident responders have documented in ICS syslog; the second identifies unusual outbound behavior from the appliance itself — a compromised gateway frequently initiates connections it never made before.

// Hunt 1: Exploitation and post-exploitation indicators in Ivanti ICS syslog
let lookback = 14d;
union isfuzzy=true
    (CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where DeviceVendor =~ "Ivanti" or DeviceProduct has_any ("Connect Secure", "Pulse Secure")
    | where Message has_any ("runtime/tmp", "web shell", "dsintegrity", "failed integrity",
                             "cmd=", "/bin/sh", "perl -e", "python -c", "base64 -d",
                             "log cleared", "compromised")
    | project TimeGenerated, SourceIP, DestinationIP, Message, DeviceProduct),
    (Syslog
    | where TimeGenerated > ago(lookback)
    | where HostName has_any ("ivanti", "ics", "vpn") or ProcessName has_any ("web", "dslogd")
    | where SyslogMessage has_any ("runtime/tmp", "/bin/sh", "perl -e", "python -c",
                                   "base64 -d", "integrity check", "failed to verify")
    | project TimeGenerated, HostName, ProcessName, SyslogMessage, SeverityLevel);

// Hunt 2: Appliance-originated connections into internal infrastructure (pivot detection)
let ics_subnet = dynamic(["10.254.0.0/16"]);  // <-- replace with your ICS appliance range
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where RemotePort in (445, 3389, 5985, 5986, 22, 389, 636)
| summarize ConnectionCount = count(), DistinctTargets = dcount(RemoteIP),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by LocalIP, RemotePort, InitiatingProcessFileName
| where ConnectionCount > 20 or DistinctTargets > 5
| order by DistinctTargets desc;

// Hunt 3: Rare outbound destinations from the VPN gateway itself (C2 staging)
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DeviceVendor =~ "Ivanti" or SourceHostName has_any ("ivanti", "ics", "vpn")
| summarize Hits = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by DestinationIP, DestinationPort, DestinationHostName
| where Hits < 10
| order by FirstSeen desc

Velociraptor VQL

For any host that the VPN gateway can reach — especially jump boxes, domain controllers, and file servers — hunt for the access pattern that follows a VPN pivot: authentication from the gateway subnet followed immediately by process execution under newly logged-on sessions. If you have Velociraptor deployed on servers adjacent to the VPN segment, this artifact surfaces the first-order artifacts of that pivot.

-- Hunt for processes spawned shortly after network logons sourced from the VPN gateway,
-- plus recently written executables/scripts in temp and profile paths (web shell droppers, tooling)
LET vpn_range <= '10.254.'  -- replace with your ICS/VPN source prefix

LET suspicious_procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(powershell.*-(enc|e )|cmd.exe.*/c|certutil.*-decode|bitsadmin|mshta|rundll32.*javascript)'
  AND CreateTime > now() - 1209600

LET staged_files = SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
  'C:/Windows/Temp/**/*.exe',
  'C:/Windows/Temp/**/*.ps1',
  'C:/Users/*/AppData/Local/Temp/**/*.exe',
  'C:/ProgramData/**/*.ps1'
])
WHERE Mtime > now() - 1209600
  AND Size < 5000000

SELECT * FROM suspicious_procs
UNION ALL
SELECT NULL AS Pid, NULL AS Ppid, 'STAGED_FILE' AS Name, FullPath AS Exe,
       '' AS CommandLine, '' AS Username, Mtime AS CreateTime
FROM staged_files

Verification and Containment Script

Run this on your ICS appliance console (or via your management jump host against the appliance admin interface) to snapshot integrity state, export logs before they can be tampered with, and confirm current version against the advisory. Do this before patching — if the appliance is already compromised, you want the forensic evidence and the ICT output first.

#!/bin/bash
# Ivanti ICS pre-patch triage and evidence capture
# Run from a management host with SSH access to the appliance admin CLI

ICS_HOST="<appliance-admin-ip>"
EVIDENCE_DIR="./ics_triage_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$EVIDENCE_DIR"

echo "[+] Capturing system version and build..."
ssh admin@"$ICS_HOST" "show version" > "$EVIDENCE_DIR/version.txt"

echo "[+] Running Ivanti Integrity Checker Tool (ICT) and saving output..."
# Download the latest ICT from Ivanti's portal first; a tampered appliance may ship a forged ICT result.
ssh admin@"$ICS_HOST" "show system integrity-checker status" > "$EVIDENCE_DIR/ict_status.txt"

echo "[+] Exporting logs OFF-BOX before any remediation (attacker may clear them)..."
scp -r admin@"$ICS_HOST":/home/var/log/ "$EVIDENCE_DIR/home_var_log/" 2>/dev/null
scp -r admin@"$ICS_HOST":/data/var/log/ "$EVIDENCE_DIR/data_var_log/" 2>/dev/null

echo "[+] Snapshotting active sessions and connections..."
ssh admin@"$ICS_HOST" "show system active-users" > "$EVIDENCE_DIR/active_sessions.txt"
ssh admin@"$ICS_HOST" "show arp all" > "$EVIDENCE_DIR/arp.txt"

echo "[+] Checking for unexpected files in runtime/tmp and web paths..."
ssh admin@"$ICS_HOST" "find /home/runtime/tmp /data/runtime -type f -mtime -30" > "$EVIDENCE_DIR/recent_files.txt"

echo ""
echo "=== TRIAGE COMPLETE ==="
echo "Review $EVIDENCE_DIR/ict_status.txt FIRST."
echo "If ICT reports NEW or MODIFIED files you cannot attribute to a vendor update:"
echo "  1. Isolate the appliance (block inbound 443 at the perimeter, keep mgmt access)"
echo "  2. Revoke ALL VPN sessions and rotate ALL credentials that traversed the appliance"
echo "     (local users, AD service accounts, certificates, machine creds)"
echo "  3. Open a vendor case with Ivanti and reference the active-exploitation advisory"
echo "  4. Only then apply the patched build — or factory reset and rebuild if compromise is confirmed"

Remediation

1. Patch now — out of band, out of cycle. Apply the fixed Connect Secure build from Ivanti's advisory the moment it is available for your version train. Do not wait for your next maintenance window; the vulnerability is already weaponized. If the patch is not yet released for your train, apply Ivanti's published workaround/mitigation XML and verify it applied successfully.
2. Run the Integrity Checker Tool — the current version, from Ivanti's portal. A compromised appliance can return a clean result from a tampered on-box ICT. Use the external/updated ICT and treat any unexplained new or modified file as confirmed compromise.
3. If ICT or your hunts indicate compromise, patching is not enough. Web shells and credential theft persist across upgrades. The defensible path is: isolate, capture forensics, factory reset or rebuild from known-good image, then patch, then restore config from a pre-compromise backup.
4. Rotate everything that touched the appliance. All local admin credentials, all user VPN credentials, AD service accounts used for directory integration, RADIUS shared secrets, and any certificates/private keys stored on the device. Assume session tokens were harvested; force re-authentication globally.
5. Take the management interface off the internet. There is no defensible reason for the ICS admin console to be reachable from the public internet in 2026. Restrict it to a dedicated management VLAN reachable only from a PAW or jump host.
6. Forward all ICS syslog off-box, today. Admin log, user log, system log, and ICT output to a SIEM the appliance cannot write to. Local logs on a compromised edge device are evidence the attacker controls.
7. Watch CISA KEV and the Ivanti advisory for the formal deadline. Prior ICS KEV entries carried 3-week federal deadlines; treat that as your maximum, not your plan. Track the advisory at https://www.ivanti.com/blog/security-update and https://www.cisa.gov/known-exploited-vulnerabilities-catalog.
8. Fix the process lesson. Add a vendor-risk rule to your vulnerability management program: when an edge/internet-facing device vendor discloses that they knew about a defect and deferred it, that product goes to elevated monitoring and emergency-change readiness immediately — you no longer get to assume the vendor's timeline is safe.

The uncomfortable takeaway from this story is not that Ivanti shipped another vulnerable VPN box. It is that 'doesn't meet the threshold for out-of-band release' is a risk decision made on your behalf, with your perimeter as collateral. Build your program so that decision never goes unchallenged again.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub