Ivanti Connect Secure Zero-Day Under Active Exploitation Since October — CISA Urges Immediate Patching: Detection and Remediation Guide

If you run Ivanti Connect Secure (ICS) VPN appliances at your perimeter, stop what you're doing. CISA has issued an urgent warning that an ICS vulnerability is being exploited in the wild as a zero-day, with observed attack activity dating back to at least October 1st. That timeline matters: if your appliance has been internet-facing and unpatched during that window, you cannot treat this as a simple patch-and-move-on event. You have to assume potential compromise and hunt accordingly.

This pattern is painfully familiar to anyone who worked the Ivanti incidents of the past several years. ICS appliances sit at the most privileged position in your network — the front door through which all remote access flows. When adversaries gain code execution on the appliance itself, they get a beachhead that bypasses endpoint controls entirely, pre-authentication access to internal networks, and a platform from which to harvest credentials, intercept VPN sessions, and pivot inward. These are exactly the appliances that nation-state operators and sophisticated criminal groups prioritize, and CISA's decision to push out an emergency directive-style warning tells you the exploitation is neither theoretical nor opportunistic.

This post breaks down what's known, how to hunt for compromise on and behind your ICS appliances, and what remediation actually looks like when patching alone isn't enough.

Technical Analysis

Affected Products

The flaw affects Ivanti Connect Secure (ICS) — the SSL VPN gateway product widely deployed for remote workforce access. ICS is a hardened Linux-based appliance, typically internet-facing by design, which makes any remotely exploitable flaw in it a critical perimeter exposure. Organizations running Ivanti Policy Secure gateways should also review the associated vendor advisories, as related components have historically been implicated in the same campaigns.

Key exposure characteristics:

• Internet-facing by design: ICS appliances exist to terminate external connections. There is no 'internal-only' deployment model that mitigates reachability.
• Pre-authentication attack surface: Historically exploited ICS flaws (and consistent with this campaign's reported exploitation pattern) are reachable without valid credentials, meaning any exposed appliance is a target for mass scanning.
• Limited native logging and EDR coverage: The appliance does not support standard endpoint agents. Visibility depends on syslog forwarding, the built-in Integrity Checker Tool (ICT), and network telemetry downstream of the device.

How the Exploitation Works — Defender's Perspective

While vendor technical details continue to develop, the observed intrusion pattern in ICS zero-day campaigns follows a well-documented kill chain that your detection strategy should be built around:

1. Initial exploitation: The attacker sends crafted requests to the ICS web interface, exploiting the flaw to achieve remote code execution on the appliance — typically without authentication.
2. Persistence and tooling: Post-exploitation, actors modify appliance files, drop web shells or tampered binaries within the appliance's runtime directories (commonly under /home/, /data/runtime/, or web-accessible paths), and in prior campaigns have deployed persistence mechanisms that survive reboots and even some factory-reset scenarios.
3. Defense evasion: A hallmark of ICS intrusions is log tampering. Sophisticated actors disable or selectively wipe appliance logs (including the DSlog subsystem) to erase evidence of exploitation. Missing or gapped logs on an ICS appliance is itself a detection signal.
4. Credential theft and pivot: From the appliance, attackers harvest VPN session credentials, LDAP/AD bind credentials configured on the device, and session tokens — then authenticate legitimately into the environment as valid users, defeating perimeter alerts entirely.
5. Lateral movement: With harvested credentials and a trusted network position, actors move to domain infrastructure, often within hours to days of initial access.

Exploitation Status

• Active in-the-wild exploitation: CONFIRMED. CISA's public urging of immediate remediation is issued when exploitation is real and ongoing, not hypothetical.
• Observed attack activity since at least October 1st — a weeks-long exposure window that demands retrospective hunting, not just forward-looking patching.
• Treat any ICS appliance that was unpatched and internet-reachable during the exploitation window as potentially compromised until proven otherwise via integrity checking and log review.

Detection & Response

The hard truth about ICS appliances: you will not catch this with endpoint detection alone. Detection requires correlating appliance syslog, downstream authentication telemetry, network flow data, and file-integrity evidence. The detections below target the behaviors that are consistent across ICS exploitation campaigns: anomalous process execution under the appliance web service, log tampering, web shell artifacts, and follow-on credential abuse.

Sigma Rules

The first rule targets the appliance's web process spawning command shells — a near-universal post-exploitation behavior when an attacker achieves RCE on the appliance and executes follow-on commands. The second targets log clearing, the signature defense-evasion move in ICS intrusions.

---
title: Ivanti Connect Secure Web Service Spawning Shell or Command Interpreter
id: 3f8a2c41-9b6e-4d12-a7c5-8e1f4b9d2034
status: experimental
description: Detects the ICS web server process spawning shells or command interpreters, indicative of remote code execution post-exploitation on an Ivanti Connect Secure appliance. Requires syslog/process telemetry forwarded from the appliance or a monitoring host.
references:
  - https://www.bleepingcomputer.com/news/security/cisa-warns-admins-to-immediately-fix-ivanti-flaw-exploited-as-zero-day/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.execution
  - attack.t1059
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - '/home/bin/web'
      - '/home/bin/'
  selection_child:
    Image|endswith:
      - '/bin/sh'
      - '/bin/bash'
      - '/usr/bin/python'
      - '/usr/bin/perl'
      - '/usr/bin/curl'
      - '/usr/bin/wget'
      - '/usr/bin/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Vendor maintenance scripts executed during legitimate upgrades — verify against change windows
level: high
---
title: Ivanti Connect Secure Appliance Log Clearing or Tampering
id: 6c1d9e27-4a83-4f55-b298-7d3e5c1a9026
status: experimental
description: Detects deletion, truncation, or clearing of log files on an Ivanti Connect Secure appliance, a known defense-evasion technique used by actors exploiting ICS zero-days to erase forensic evidence.
references:
  - https://www.bleepingcomputer.com/news/security/cisa-warns-admins-to-immediately-fix-ivanti-flaw-exploited-as-zero-day/
  - https://attack.mitre.org/techniques/T1070/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.defense_evasion
  - attack.t1070.002
logsource:
  category: process_creation
  product: linux
detection:
  selection_rm:
    CommandLine|contains:
      - 'rm '
      - 'shred'
      - 'truncate'
  selection_paths:
    CommandLine|contains:
      - '/data/logs/'
      - '/var/log'
      - 'DSLog'
      - 'log.events'
      - 'log.access'
  selection_alt:
    CommandLine|contains:
      - '> /data/logs'
      - ': > /var/log'
  condition: (selection_rm and selection_paths) or selection_alt
falsepositives:
  - Automated log rotation — legitimate rotation uses mv/gzip patterns, not rm or truncation
level: critical
---
title: Web Shell File Creation in Ivanti Connect Secure Web Directories
id: 9e4b7d13-2c68-4a91-8f35-1b6c8d4e7512
status: experimental
description: Detects creation of executable or script files in ICS web-served directories, consistent with web shell deployment following exploitation of the appliance.
references:
  - https://www.bleepingcomputer.com/news/security/cisa-warns-admins-to-immediately-fix-ivanti-flaw-exploited-as-zero-day/
  - 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/webserver/'
      - '/data/runtime/'
      - '/tmp/'
  selection_ext:
    TargetFilename|endswith:
      - '.cgi'
      - '.pl'
      - '.py'
      - '.sh'
      - '.php'
  condition: selection_path and selection_ext
falsepositives:
  - Vendor upgrade packages extract files to these paths — correlate with approved maintenance windows
level: high

KQL — Microsoft Sentinel / Defender

ICS appliances forward logs via syslog, and any reputable deployment should have them landing in Sentinel. This query hunts across Syslog and CommonSecurityLog (CEF) for the core ICS compromise indicators: shell execution under the web service, log tampering references, and anomalous outbound connections from the appliance itself — an appliance has almost no legitimate reason to initiate outbound connections to arbitrary internet IPs beyond vendor update and OCSP endpoints.

// Hunt: Ivanti Connect Secure post-exploitation indicators via Syslog/CEF ingestion
// Covers: shell spawning, log tampering, suspicious outbound connections from the appliance
let ICSHosts = dynamic(["ics-vpn", "pulse", "ivanti"]); // adjust to your appliance hostnames
union isfuzzy=true
    (Syslog
    | where TimeGenerated > ago(90d)  // extend window to cover exploitation since Oct 1
    | where Computer has_any (ICSHosts) or HostIP has_any (ICSHosts)
    | where SyslogMessage has_any ("/bin/sh", "/bin/bash", "wget", "curl http", "base64 -d")
       or (SyslogMessage has_any ("rm ", "truncate") and SyslogMessage has_any ("log", "DSLog"))
    | project TimeGenerated, Computer, HostIP, ProcessName, SyslogMessage, SeverityLevel),
    (CommonSecurityLog
    | where TimeGenerated > ago(90d)
    | where DeviceProduct has_any ("Ivanti", "Pulse")
    | where DeviceAction == "Blocked" or Message has_any ("shell", "injection", "overflow")
    | project TimeGenerated, DeviceName, SourceIP, DestinationIP, RequestURL, Message);
// Companion hunt: outbound connections FROM the ICS appliance to non-vendor destinations
DeviceNetworkEvents
| where TimeGenerated > ago(90d)
| where DeviceName has_any (ICSHosts)
| where ActionType == "ConnectionSuccess"
| where RemoteIP !startswith "10." and RemoteIP !startswith "192.168." and RemoteIP !startswith "172.16."
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by DeviceName, RemoteIP, RemotePort, RemoteUrl
| order by FirstSeen asc

Tune the hostname matching to your environment. The 90-day lookback is deliberate — with exploitation dating to October 1st, you need retrospective depth, not a 7-day hunt.

Velociraptor VQL

The appliance itself can't run Velociraptor, but the infrastructure around it can. This hunt targets jump hosts and management servers used to administer ICS appliances, looking for interactive sessions originating from the appliance's IP — there is essentially no legitimate reason for the VPN appliance to initiate SSH or RDP sessions to your internal management hosts.

-- Hunt: Connections originating from Ivanti ICS appliance IPs to internal hosts
-- A compromised appliance pivoting inward is a critical finding
-- Replace the IP matches with your appliance addresses
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime,
       netstat_connections.RemoteIP AS RemoteIP,
       netstat_connections.RemotePort AS RemotePort
FROM pslist()
JOIN (
  SELECT Pid, RemoteIP, RemotePort, Status
  FROM netstat()
  WHERE Status = 'ESTABLISHED'
) AS netstat_connections
ON pslist().Pid = netstat_connections.Pid
WHERE RemoteIP =~ '^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[0-1]))'
  AND Name =~ '(ssh|putty|plink|cmd|powershell|wmi|psexec)'
ORDER BY CreateTime DESC

For a second-pass forensic artifact, deploy glob() against ICS backup/config-export shares for recently modified files with executable content — actors who steal appliance config backups gain every credential and certificate on the device.

Verification & Hardening Script

This script audits a management host for ICS reachability, pulls current appliance version info via the admin API where accessible, verifies log forwarding is intact (gapped logs = red flag), and documents exposure for the remediation ticket. Run it from a management workstation with network access to the appliance admin interface.

#!/bin/bash
# Ivanti Connect Secure exposure and log-integrity verification
# Run from a management host with reachability to the ICS admin interface

ICS_ADMIN="https://ics-admin.example.com"   # replace with your appliance admin URL
ICS_IP="203.0.113.10"                        # replace with appliance external IP
SYSLOG_HOST="siem.example.com"               # replace with your syslog/SIEM collector
REPORT="ics_exposure_audit_$(date +%Y%m%d_%H%M%S).txt"

echo "=== ICS Exposure & Integrity Audit: $(date -u) ===" | tee "$REPORT"

# 1. Confirm internet exposure of the appliance web interface
echo -e "\n[1] Checking external reachability of ICS web portal..." | tee -a "$REPORT"
curl -sk --max-time 10 "https://${ICS_IP}/" -o /dev/null -w \
  "HTTP %{http_code} — appliance reachable from this host\n" | tee -a "$REPORT"

# 2. Check TLS certificate age (stale certs often correlate with unmaintained = unpatched appliances)
echo -e "\n[2] Certificate details..." | tee -a "$REPORT"
echo | openssl s_client -connect "${ICS_IP}:443" -servername "${ICS_IP}" 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates | tee -a "$REPORT"

# 3. Verify syslog forwarding is alive — gapped ICS logs are a compromise indicator
echo -e "\n[3] Verifying recent syslog receipt from appliance..." | tee -a "$REPORT"
logger -n "$SYSLOG_HOST" -P 514 -p local0.info "ICS-AUDIT: syslog path verification $(date -u)"
echo "Sent test message to ${SYSLOG_HOST}:514 — confirm receipt AND confirm appliance logs" \
  "have no gaps since Oct 1. Any gap = treat as compromised." | tee -a "$REPORT"

# 4. Reminder of manual appliance-side checks
echo -e "\n[4] MANUAL STEPS REQUIRED on the appliance admin console:" | tee -a "$REPORT"
cat <<'EOF' | tee -a "$REPORT"
  a. Record current ICS software version — compare against the version listed in
     the Ivanti security advisory. If behind: patch per advisory immediately.
  b. Run the Ivanti Integrity Checker Tool (ICT) and the EXTERNAL ICT.
     ANY new/modified file flagged by ICT = assume compromise, begin IR.
  c. Review admin console logins since October 1st for unfamiliar source IPs.
  d. Review VPN user login logs for impossible-travel or off-hours anomalies.
  e. Check for unexpected local user accounts or changed admin credentials.
  f. If compromise confirmed or suspected: factory reset, apply patch, restore
     known-good config, rotate ALL credentials (device, LDAP bind, RADIUS,
     certificates, and every user who authenticated during exposure window).
EOF

echo -e "\n=== Audit complete. Retain ${REPORT} for the change/remediation ticket. ===" | tee -a "$REPORT"

Remediation

This is a CISA-flagged, actively exploited flaw — treat remediation as an incident, not a patch cycle.

1. Patch immediately. Apply the fixed ICS software version specified in Ivanti's official security advisory for this flaw. Pull the advisory and patch packages directly from the Ivanti Community/Security Advisory portal — never from third-party mirror links circulating during high-urgency events (typosquatted patch distribution is a real secondary risk in every Ivanti event).

2. Check CISA KEV and any applicable federal directive. Given CISA's public warning, this vulnerability will land (or has landed) in the CISA Known Exploited Vulnerabilities Catalog with a Binding Operational Directive deadline for federal agencies — typically days, not weeks, for edge-device zero-days. Use that deadline as your own internal SLA regardless of sector.

3. Run the Integrity Checker Tool before and after patching. Execute both the built-in ICT and Ivanti's external ICT. Do not patch over a compromised appliance blindly — patching removes the vulnerability but does not necessarily remove attacker persistence. Any ICT flag means you escalate to IR, not to the next ticket.

4. Hunt retrospectively to October 1st. Review appliance logs, VPN authentication logs, and downstream AD/IdP authentication for the full exposure window. Pay special attention to gaps in appliance logging — gapped logs on an ICS device is presumptive evidence of tampering.

5. Assume credential compromise if exploitation is suspected. Rotate: appliance admin credentials, LDAP/AD bind accounts configured on the device, RADIUS/TACACS secrets, device certificates, and — critically — the credentials of any user who authenticated through the appliance during the exposure window. Session token theft means passwords alone aren't the only risk; revoke active sessions and consider forcing re-enrollment of MFA for affected users.

6. If compromise is confirmed: factory reset, then patch, then restore from known-good config. This is the vendor-documented clean-slate procedure from prior ICS incidents. Restoring a config backup made after initial compromise can re-import attacker-planted accounts or settings — validate backup provenance.

7. Reduce future blast radius. Restrict admin console access to a dedicated management network, enforce MFA on all VPN access, enable continuous syslog forwarding to an off-box collector (so appliance-level log tampering can't erase evidence), and put ICS version currency on a tracked SLA in your vulnerability management program. Edge appliances are the highest-velocity exploitation targets in your estate — they cannot ride a 30-day patch cycle.

Reference: BleepingComputer — CISA warns admins to immediately fix Ivanti flaw exploited as zero-day

Related Resources

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