Back to Intelligence

Ivanti Connect Secure 22.8R2.4 Zero-Day Chain: Detection and Remediation Guidance for the Volexity-Disclosed Intrusion

SA
Security Arsenal Team
October 14, 2026
12 min read

Volexity's incident response team has disclosed a sophisticated intrusion that every organization running Ivanti Connect Secure (ICS) needs to treat as a five-alarm fire. Beginning October 5, Volexity investigated suspicious activity at one of its monitoring customers and traced the full attack chain back to an Ivanti Connect Secure VPN appliance running version 22.8R2.4 — the latest build available at the time of compromise. The attackers chained three unpatched vulnerabilities to achieve root-level access on the appliance, harvest credentials, actively evade detection, and position themselves for broader network compromise.

Let that sink in: the victim was fully patched. This is the worst-case scenario for edge device defense — a zero-day chain against a security product that sits at the network perimeter, terminates encrypted sessions, and holds a treasure trove of credentials, session tokens, and trusted pathways into the internal network.

Ivanti Connect Secure (and its sibling, Policy Secure) has been a favored target of state-nexus and financially motivated actors for years precisely because of this position. Edge VPN appliances are internet-facing by design, rarely support traditional EDR agents, and historically ship with limited logging visibility. When an adversary owns your VPN concentrator with root privileges, they own the front door, the key ring, and the security camera footage. This post breaks down what happened, how to hunt for it, and what to do about it.

Technical Analysis

Affected Products and Versions

  • Product: Ivanti Connect Secure (ICS) VPN appliance
  • Confirmed affected version: 22.8R2.4 (the latest available build at the time of the Volexity investigation — meaning no patch existed when exploitation began)
  • Exposure: Any internet-facing ICS appliance should be considered potentially targeted until vendor mitigations are confirmed deployed

At the time of reporting, the three vulnerabilities in the chain had no public CVE assignments and no available patches. Do not assume your environment is unaffected simply because you applied the most recent Ivanti update — the victim in this incident had done exactly that. Monitor the Ivanti security advisory portal and the CISA Known Exploited Vulnerabilities catalog continuously; Ivanti zero-days historically receive CVE identifiers and KEV entries within days of public disclosure.

Attack Chain Breakdown

Based on Volexity's findings, the intrusion followed a now-familiar but increasingly refined pattern for edge device compromise:

  1. Initial exploitation via chained vulnerabilities. Three separate flaws were combined to escalate from an unauthenticated or low-privilege position on the web-facing attack surface of the appliance to full root access. Chaining is the signature move here: individually, each bug may offer limited capability (e.g., an authentication bypass, a command injection, a privilege escalation), but together they deliver complete device takeover.
  2. Root access on the appliance. Root on ICS means the ability to read and modify any file on the device, including the web server components that render the administrative and user portals, the authentication subsystem, and stored configuration.
  3. Credential theft. With root, the attackers harvested credentials traversing or stored on the appliance — user VPN credentials, session material, and potentially administrative credentials. Stolen VPN credentials are the pivot point: they allow the attacker to re-enter the network later as a legitimate authenticated user, bypassing the very perimeter they just burned.
  4. Detection evasion. The actors took deliberate steps to evade the appliance's built-in integrity and logging mechanisms. This is consistent with prior ICS campaigns where attackers modified system components so that integrity checks report a clean bill of health on a compromised device, and where logs were selectively wiped or suppressed.
  5. Staging for wider compromise. The foothold was being prepared as a launchpad — the attackers were positioning to move from the edge device into the internal network using the stolen credentials and the appliance's trusted network position.

Exploitation Status

  • Confirmed active in-the-wild exploitation against a patched production environment, documented by Volexity's IR team
  • Zero-day at time of exploitation — no vendor fix existed when the victim was compromised
  • CVE identifiers: none publicly assigned in the initial disclosure; expect rapid vendor advisory and CISA KEV activity
  • Attribution: not publicly confirmed in the summary, but the tradecraft (zero-day chain against edge VPN, credential harvesting, anti-forensics, long-term staging) is consistent with well-resourced state-nexus intrusion sets that have historically targeted Ivanti appliances

Detection & Response

A hard truth from the IR trenches: you cannot install your EDR agent on an Ivanti appliance. Detection for ICS compromise lives in three places — forwarded appliance syslog, integrity checker output, and internal network telemetry that catches the post-exploitation phase. The detections below target all three. Hunt for the appliance behavior and for what a root-level actor does next: reuse stolen credentials and pivot inward from the VPN gateway.

Sigma Rules

YAML
---
title: Shell or Scripting Interpreter Spawned by Ivanti Web Service Components
id: 3f8a2c71-9b4e-4d2a-a1c7-5e6f8d9b0c1a
status: experimental
description: Detects web server or CGI processes on an Ivanti Connect Secure appliance spawning shells, scripting interpreters, or download utilities — a hallmark of web-exploitation and web shell activity on the appliance. Requires host-level telemetry or forwarded auditd/process logs from the ICS device.
references:
  - https://securityaffairs.com/200895/hacking/volexity-uncovers-stealthy-ivanti-vpn-attack-using-three-zero-day-vulnerabilities.html
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/01/09
tags:
  - attack.execution
  - attack.t1059
  - attack.persistence
  - attack.t1505.003
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - '/home/perl'
      - '/home/webserver'
      - 'httpd'
      - 'monkey'
  selection_child:
    CommandLine|contains:
      - '/bin/sh'
      - '/bin/bash'
      - 'python'
      - 'perl'
      - 'curl '
      - 'wget '
      - 'base64'
      - 'openssl'
  condition: selection_parent and selection_child
falsepositives:
  - Rare legitimate Ivanti system maintenance scripts; validate against change windows
level: high
---
title: File Creation or Modification in Ivanti Connect Secure Web-Accessible Directories
id: 7c2e9f14-3a5b-4e8d-b2f6-1a9c4d7e0b3f
status: experimental
description: Detects creation or modification of executable/script content in Ivanti Connect Secure web server directories and temporary execution paths, consistent with web shell or implant deployment following exploitation of the appliance.
references:
  - https://securityaffairs.com/200895/hacking/volexity-uncovers-stealthy-ivanti-vpn-attack-using-three-zero-day-vulnerabilities.html
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/01/09
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/home/webserver/htdocs/'
      - '/home/perl/'
      - '/home/runtime/'
      - '/tmp/'
      - '/data/var/tmp/'
  selection_ext:
    TargetFilename|endswith:
      - '.cgi'
      - '.pl'
      - '.py'
      - '.sh'
      - '.so'
      - '.php'
  condition: selection_path and selection_ext
falsepositives:
  - Vendor software updates and hotfix installations; correlate with Ivanti patch deployment records
level: high
---
title: Ivanti Appliance Log Deletion or Anti-Forensic Activity
id: b1d4a8e2-6f3c-4a9d-8e5b-2c7f0a1d4e6b
status: experimental
description: Detects deletion or truncation of log files on an Ivanti Connect Secure appliance, or clearing of shell history — anti-forensic behavior observed in stealthy ICS intrusions where attackers evade detection after gaining root access.
references:
  - https://securityaffairs.com/200895/hacking/volexity-uncovers-stealthy-ivanti-vpn-attack-using-three-zero-day-vulnerabilities.html
  - https://attack.mitre.org/techniques/T1070/
author: Security Arsenal
date: 2026/01/09
tags:
  - attack.defense_evasion
  - attack.t1070
logsource:
  category: process_creation
  product: linux
detection:
  selection_rm:
    CommandLine|contains:
      - 'rm -f'
      - 'rm -rf'
      - 'shred'
      - 'truncate'
      - '> /dev/null'
  selection_target:
    CommandLine|contains:
      - '/data/var/log'
      - '/var/log'
      - '/data/var/logs'
      - 'bash_history'
      - 'message'
      - 'authlog'
  selection_hist:
    CommandLine|contains:
      - 'history -c'
      - 'unset HISTFILE'
  condition: (selection_rm and selection_target) or selection_hist
falsepositives:
  - Automated log rotation daemons use dedicated tooling, not interactive rm; verify any hits immediately
level: critical

KQL — Microsoft Sentinel Hunt

This query hunts the post-exploitation phase: after the appliance is compromised and credentials are stolen, the attacker pivots inward. It looks for internal systems receiving administrative-protocol connections (SMB, RDP, WinRM, SSH) originating from your VPN gateway's IP, and pairs it with syslog anomalies from the appliance itself — admin logins from unusual sources and log-service restarts that may indicate tampering. Replace the gateway IP variable with your ICS appliance address.

KQL — Microsoft Sentinel / Defender
let VpnGatewayIP = "10.0.0.5"; // TODO: replace with your Ivanti Connect Secure internal IP
let AdminPorts = dynamic([22, 445, 3389, 5985, 5986, 135]);
// Part 1: Lateral movement originating from the VPN appliance itself
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where RemoteIP == VpnGatewayIP
| where RemotePort in (AdminPorts)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            ConnectionCount = count(), Devices = dcount(DeviceName)
  by DeviceName, RemoteIP, RemotePort, InitiatingProcessName
| where ConnectionCount > 0
| order by FirstSeen asc;
// Part 2: Anomalous administrative logons and service restarts in ICS syslog
Syslog
| where TimeGenerated > ago(14d)
| where Computer has_any ("ivanti", "ics", "pulse", "vpn")
| where SyslogMessage has_any ("admin login", "Admin login", "authenticated", "new administrator", "system restart", "log service", "factory")
| project TimeGenerated, Computer, Facility, SeverityLevel, SyslogMessage
| order by TimeGenerated desc;

Velociraptor VQL — Internal Endpoint Hunt for Gateway-Originated Pivoting

Deploy this hunt across internal servers (particularly domain controllers, jump boxes, and management hosts) to identify live or recent inbound connections from the VPN appliance on administrative ports. A VPN concentrator has almost no legitimate reason to initiate SMB, RDP, or WinRM sessions into your internal estate.

VQL — Velociraptor
-- Hunt for inbound administrative-protocol connections originating from the VPN gateway
-- Replace the gateway IP before deploying
LET gateway_ip = '10.0.0.5'

SELECT Pid,
       Name AS ProcessName,
       LocalAddr,
       LocalPort,
       RemoteAddr,
       RemotePort,
       Status,
       Family,
       Type
FROM netstat()
WHERE RemoteAddr =~ gateway_ip
  AND LocalPort in (22, 135, 445, 3389, 5985, 5986)

Remediation and Verification Script

Run the following from a hardened administrative workstation with SSH access to the appliance. It performs version verification, integrity-checker validation, and account/session review. Do not run commands directly on the appliance beyond vendor-supported operations — an attacker with root may have tampered with on-box tooling, which is exactly why Volexity-style memory and disk forensics matter.

Bash / Shell
#!/bin/bash
# Ivanti Connect Secure compromise verification checklist
# Run from an admin workstation. Replace variables before use.

ICS_HOST="ics-admin.example.internal"
ICS_ADMIN="readonly-admin"   # Use a dedicated read-only audit account where possible

echo "=== [1] Confirm appliance version ==="
echo "Record the running build and compare against the latest Ivanti advisory:"
echo "https://www.ivanti.com/blog/topics/security-advisory"
echo "Advisory portal: https://portal.ivanti.com/"
ssh ${ICS_ADMIN}@${ICS_HOST} "show version" 2>/dev/null || echo "[!] SSH check failed - verify via admin UI: System > Platform"

echo "=== [2] Download and run the CURRENT Ivanti Integrity Checker Tool (ICT) ==="
echo "[!] CRITICAL: Always pull a fresh ICT from the vendor - a stale or tampered ICT can report a compromised box as clean."
echo "Run the EXTERNAL ICT from a clean system, not only the on-box version."

echo "=== [3] Verify syslog forwarding is active and complete ==="
echo "Confirm logs reach the SIEM and check for GAPS in the timeline - missing log windows are a red flag for tampering."

echo "=== [4] Review administrative and local accounts ==="
echo "In admin UI: Authentication > Auth Servers > [local] - enumerate ALL admin and user accounts."
echo "Look for: unexpected new accounts, changed group memberships, modified authorized keys."

echo "=== [5] Force global session revocation and credential rotation ==="
echo "In admin UI: sign out ALL active user and admin sessions."
echo "Rotate: local admin passwords, service accounts, bind accounts, API tokens, and ANY credentials that transited the VPN."
echo "Revoke and reissue device/SSL certificates if compromise is confirmed."

echo "=== [6] Restrict management plane exposure ==="
echo "Ensure the admin UI (default TCP/443 on the internal interface) is NOT reachable from the internet."
echo "Confirm with an external scan: nmap -Pn -p 443,8443 <external-ip>"

echo "=== [7] Preserve evidence BEFORE reboot or factory reset ==="
echo "Export full system snapshot/logs via: System > Maintenance > Troubleshooting > System Snapshot"
echo "Preserve SIEM-side syslog, firewall, and NetFlow records for the appliance for at least 90 days."

Remediation

1. Treat every internet-facing ICS appliance as potentially compromised until proven otherwise. The victim here was on the latest available build. Patching posture alone is not evidence of safety — run the integrity check.

2. Run the current Ivanti Integrity Checker Tool (ICT) — externally. Download a fresh ICT directly from Ivanti's official portal rather than trusting an on-box copy. Prior ICS campaigns demonstrated attacker modification of the on-box checker so that compromised appliances self-report as clean. Where possible, use the external ICT variant and review its full output, not just the pass/fail summary.

3. Apply Ivanti security updates the moment they ship. Monitor the official advisory channels around the clock until fixes for this chain land: the Ivanti Security Advisory blog (https://www.ivanti.com/blog/topics/security-advisory) and customer portal (https://portal.ivanti.com/). Watch the CISA Known Exploited Vulnerabilities catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) — actively exploited Ivanti flaws are consistently added with federal remediation deadlines, and CISA's Emergency Directive process has previously applied to ICS zero-days. Track whether the three vulnerabilities receive CVE assignments and map them into your vulnerability management workflow immediately upon publication.

4. If compromise is confirmed or suspected, rebuild — don't clean. The vendor- and CISA-endorsed pattern for compromised ICS appliances is: export configuration, factory reset, reflash to a known-good patched image, and restore configuration. Root-level persistence on these appliances survives casual remediation attempts.

5. Rotate everything the appliance touched. Assume all credentials that transited or were stored on the device are compromised: VPN user credentials, administrator accounts, LDAP/AD bind and service accounts, RADIUS shared secrets, API tokens, and device certificates. Force a global session revocation. Prioritize privileged accounts for immediate password resets and verify MFA enforcement on all VPN access.

6. Segment and restrict the management plane. The administrative interface must be reachable only from a dedicated management network — never from the internet or general user VLANs. Enforce this with firewall rules and validate with external scanning.

7. Forward and preserve logs off-box. Stream ICS syslog (authentication, admin access, system events) to a SIEM in real time. On-box logs cannot be trusted on a device where the attacker achieved root. Retain at least 90 days of appliance logs, perimeter firewall logs, and NetFlow for retrospective hunting.

8. Hunt for the downstream intrusion. Compromised VPN credentials are a means, not an end. Review authentication logs for VPN logins from unusual geographies, impossible travel, or logins outside user baselines in the 60–90 days preceding the disclosure. Hunt internally for lateral movement originating from the VPN gateway IP (see KQL and VQL above) and for use of harvested service accounts.

9. Reassess edge device architecture. This incident — like the Ivanti zero-day waves before it — is the strongest available argument for moving remote access toward zero-trust architectures with strong identity-aware proxies, hardware-backed MFA, and reduced reliance on monolithic VPN concentrators as the sole perimeter control. At minimum, ensure your IR retainers and playbooks explicitly cover edge appliance compromise, including memory/disk acquisition procedures for ICS-class devices.

Related Resources

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

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.