Hardening Ivanti Connect Secure: Blue Team Defense Guide

Overview & Defensive Context#

In our morning research breakdown, we dissected the technical mechanics of the Ivanti Connect Secure pre-authentication zero-day chain (CVE-2023-46805 and CVE-2024-21887). We demonstrated how threat cluster UNC5221 (associated with Volt Typhoon and UTA0178) chained an NGINX reverse-proxy path traversal vulnerability with an unescaped Python command injection flaw. By issuing crafted HTTP POST requests to /api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection, adversaries bypassed perimeter authentication, executed arbitrary shell commands as root, deployed persistent webshells (WIREFIRE, GLASSTOKEN), and harvested enterprise credentials directly at the network ingress.

For enterprise security architects and blue teams, defending edge VPN appliances against zero-day exploitation exposes severe structural vulnerabilities:

• The Endpoint Detection Vacuum: Ivanti Connect Secure operates as a closed, proprietary Linux-based appliance. Standard host-based Endpoint Detection and Response (EDR) sensors—such as CrowdStrike Falcon, Microsoft Defender for Endpoint, or SentinelOne—cannot be natively installed. As a result, once an adversary establishes code execution on the appliance, they operate in a total monitoring vacuum.
• The Failure of In-Band Integrity Checking: Threat actors actively compromised the appliance's built-in Integrity Checking Tool (ICT) (pyis-integrity-checker.py). By patching the scanning script and manipulating encrypted loopback filesystems, attackers suppressed alerts for their own webshells, causing the appliance to report a false "Clean" status to unsuspecting administrators.
• Overly Permissive Outbound Network Egress: In standard deployments, firewalls permit unrestricted outbound internet traffic (0.0.0.0/0) from VPN gateways to allow CRL/OCSP checking, cloud licensing, and software updates. Adversaries exploited this outbound trust to establish reverse shells, exfiltrate stolen Active Directory credentials, and download secondary staging payloads without triggering egress blocks.

[!WARNING] Because edge VPN gateways sit at the boundary between the public internet and internal core networks, an unauthenticated compromise of the gateway inverts the entire zero-trust model. A compromised edge gateway must be treated as a complete breach of all downstream authentication and enterprise identity systems.

This guide provides an enterprise blue team defense blueprint: edge reverse proxy path canonicalization, strict network egress isolation, production-grade Sigma and Suricata detection rules, and an out-of-band forensic verification and recovery playbook.

---

Architecture Hardening#

Securing Ivanti Connect Secure gateways against perimeter exploitation requires a defense-in-depth architecture: Edge Reverse Proxy Canonicalization, Strict DMZ Network Egress Filtering, and Out-of-Band Immutable Integrity Verification.

Defense Architecture Flowchart#

flowchart TD
    classDef external fill:#1e293b,stroke:#ef4444,stroke-width:2px,color:#f8fafc
    classDef waf fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef gateway fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef egress fill:#4c1d95,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
    classDef drop fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef success fill:#065f46,stroke:#34d399,stroke-width:2px,color:#a7f3d0

    WANClient[Inbound WAN Client Request]:::external --> EdgeProxy{Ring 1: Edge Reverse Proxy / WAF}:::waf
    
    EdgeProxy -- URI contains ../ or %2e%2e or unnormalized paths --> Drop1[Action: HTTP 403 Forbidden at Edge]:::drop
    EdgeProxy -- Request to /api/v1/ from Non-Admin IP --> Drop2[Action: Block Administrative Route]:::drop
    EdgeProxy -- Canonicalized Clean VPN Traffic --> Gateway[Ring 2: Ivanti Connect Secure Gateway]:::gateway
    
    Gateway --> EgressFirewall{Ring 3: Stateful DMZ Egress Firewall}:::egress
    EgressFirewall -- Direct Outbound Connection to 0.0.0.0/0 --> Drop3[Action: DROP Packet & Alert SIEM]:::drop
    EgressFirewall -- Explicit Proxy Egress to Whitelisted Licensing FQDN --> AllowedEgress[Verified External Cloud Update]:::success
    
    Gateway -.-> OutOfBandAudit{Ring 4: External Offline Integrity Verification}:::egress
    OutOfBandAudit -- Hash Mismatch Against Factory Manifest --> Incident[Declare Severity 1 Breach: Factory Re-Image]:::drop
    OutOfBandAudit -- Cryptographic Hashes Match Official ISO --> Verified[Gateway Verified Secure]:::success

Layer 1: Edge Reverse Proxy Normalization & Ingress URL Filtering#

Ivanti Connect Secure gateways must never be exposed directly to the public internet without an upstream reverse proxy or Web Application Firewall (WAF) enforcing strict URI path canonicalization.

Deploy NGINX or Envoy in front of the Ivanti appliance to inspect and normalize all incoming request paths, dropping directory traversal attempts before they reach the appliance:

NGINX

# /etc/nginx/conf.d/ivanti_edge_hardened.conf
upstream ivanti_gateway {
    server 10.200.1.10:443;
    keepalive 32;
}

server {
    listen 443 ssl http2;
    server_name vpn.company.com;

    ssl_certificate /etc/ssl/certs/vpn_gateway.crt;
    ssl_certificate_key /etc/ssl/private/vpn_gateway.key;

    # 1. Block directory traversal sequences across all encodings
    location ~* (\.\./|%2e%2e/|%252e%252e/|%2e%2e%2f) {
        return 403;
    }

    # 2. Block unauthenticated access to sensitive API endpoints
    location ~* ^/api/v1/(system/maintenance|license|configuration)/ {
        allow 10.100.0.0/16; # Internal Management Subnet
        deny all;

        proxy_pass https://ivanti_gateway;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # 3. Standard VPN and authentication portal routing
    location / {
        proxy_pass https://ivanti_gateway;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
    }
}

Layer 2: Strict Appliance DMZ Egress Filtering & Micro-Segmentation#

The vast majority of edge zero-day exploits depend on unrestricted outbound internet access to establish reverse shells or download staging malware. Placing the appliance in a tightly restricted DMZ neutralizes this attack phase:

1. Default-Deny Outbound Egress: Configure enterprise perimeter firewalls to drop all outbound TCP and UDP connections originating from the Ivanti appliance's management and internal interfaces to 0.0.0.0/0.
2. Proxy-Gated Updates: Route essential outbound connections (such as Ivanti cloud licensing servers and CRL/OCSP certificate validation endpoints) through an explicit, authenticating forward proxy that enforces domain allowlisting:
   • Whitelist strictly required domains (e.g., *.pulsesecure.net, *.ivanti.com).
   • Inspect TLS SNI headers and terminate non-compliant outbound connections.
3. Internal Interface Isolation: Restrict the appliance's internal interface (internal0) using stateful firewall rules. Only permit necessary traffic (e.g., RADIUS/LDAP on ports 1812/636 to identity servers), while denying the appliance direct routing access to sensitive server VLANs, virtualization management consoles, and domain controllers.

Layer 3: Out-of-Band Immutable Integrity Verification#

Because in-band integrity tools can be tampered with by adversaries with root privileges, blue teams must adopt Out-of-Band External Integrity Checking:

• Immutable Boot Media: Utilize Ivanti's External Integrity Checking Tool (External ICT) provided as an ISO image.
• Offline Verification Process:
  1. Gracefully power down the virtual appliance (VMware ESXi, Hyper-V, AWS AMI).
  2. Boot the virtual machine directly from the official, cryptographically verified External ICT ISO.
  3. The external tool mounts the appliance's encrypted disks as read-only and computes SHA-256 hashes of all system binaries against a trusted vendor manifest.
  4. Any anomalous, modified, or newly introduced file (such as backdoored .py or .cgi scripts) is flagged independently of the running operating system.

---

Production Detection Queries#

Blue teams must deploy detection covering reverse proxy access logs, network intrusion detection systems (NIDS), and file-level YARA signatures.

Production Sigma Rule: Ivanti Connect Secure Path Traversal & Command Injection#

The following Sigma rule detects path traversal attempts targeting the unauthenticated TOTP endpoint in web server access logs:

YAML

title: Ivanti Connect Secure CVE-2023-46805 and CVE-2024-21887 Exploitation Attempt
id: 3d1a8c92-7410-4f3b-821c-5219bc2a1802
status: production
description: |
  Detects exploitation attempts against Ivanti Connect Secure (CVE-2023-46805 and CVE-2024-21887)
  including path traversal patterns targeting /api/v1/totp/user-backup-code/../../ and subsequent command
  injection indicators in web server access logs and WAF telemetry.
references:
  - https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/
  - https://www.cisa.gov/emergency-directive-24-01

tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.004
  - cve.2023.46805
  - cve.2024.21887
logsource:
  category: webserver
  product: linux
detection:
  selection_traversal:
    cs-method: 'POST'
    cs-uri-stem|contains:
      - '/api/v1/totp/user-backup-code/../../'
      - '/api/v1/totp/user-backup-code/%2e%2e/'
      - '/api/v1/totp/user-backup-code/..%2f'
      - '/api/v1/totp/user-backup-code/%2e%2e%2f'
  selection_target_endpoints:
    cs-uri-stem|contains:
      - 'system/maintenance/archiving/cloud-server-test-connection'
      - 'license/keys-status'
  selection_command_chars:
    cs-uri-query|contains:
      - ';'
      - '|'
      - '`'
      - '$('
  condition: selection_traversal or (selection_target_endpoints and selection_command_chars)
fields:
  - c-ip
  - cs-method
  - cs-uri-stem
  - sc-status
falsepositives:
  - Unknown. Path traversal sequences should never appear in legitimate operational traffic.
level: critical

Suricata / Snort Network Signatures#

Deploy these Suricata rules on perimeter network taps and IDS sensors inspecting traffic entering or leaving the Ivanti gateway:

BASH

# Suricata Rule 1: Detect CVE-2023-46805 Path Traversal in HTTP Request
alert http any any -> [$HOME_NET] 443 ( \
    msg:"FAST_CYBER_DEFENSE - Ivanti Connect Secure Pre-Auth Path Traversal Attempt (CVE-2023-46805)"; \
    flow:established,to_server; \
    http.method; content:"POST"; \
    http.uri; content:"/api/v1/totp/user-backup-code/"; \
    content:".."; distance:0; \
    classtype:web-application-attack; \
    sid:10008401; rev:1; \
)

# Suricata Rule 2: Detect Outbound Callback / Shell Traffic from Edge Appliance
alert tcp [$IVANTI_GATEWAY_IP] any -> $EXTERNAL_NET any ( \
    msg:"FAST_CYBER_DEFENSE - Anomalous Direct Outbound Egress from Ivanti Gateway (Potential C2 Callback)"; \
    flow:established,to_server; \
    threshold: type limit, track by_src, count 1, seconds 60; \
    classtype:trojan-activity; \
    sid:10008402; rev:1; \
)

YARA Signature: Detecting WIREFIRE and GLASSTOKEN Webshells#

Deploy this YARA rule to inspect forensic disk images, memory dumps, and filesystem snapshots:

YAML

rule Detect_Ivanti_WIREFIRE_and_GLASSTOKEN_Webshells {
    meta:
        description = "Detects custom webshells and backdoors associated with UNC5221 exploitation of Ivanti Connect Secure"
        author = "Md Redwan Ahmed (Fast Cyber Defense)"
        date = "2026-09-26"
        reference = "CVE-2023-46805 / CVE-2024-21887"
        threat_actor = "UNC5221 / UTA0178"
    strings:
        // WIREFIRE specific decompression and execution sequence
        $wirefire_str1 = "zlib.decompress" ascii
        $wirefire_str2 = "base64.b64decode" ascii
        $wirefire_str3 = "req.params.get('gif')" ascii or $wirefire_str4 = "req.params.get(\"gif\")" ascii
        
        // GLASSTOKEN CGI injection and cookie evaluation
        $glasstoken_str1 = "HTTP_COOKIE" ascii
        $glasstoken_str2 = "eval(" ascii
        $glasstoken_str3 = "welcome.cgi" ascii
        
        // Characteristic ICT anti-forensic tampering strings
        $ict_patch1 = "pyis-integrity-checker.py" ascii
        $ict_patch2 = "EXCLUDES = [" ascii
    condition:
        (all of ($wirefire_str*)) or
        (all of ($glasstoken_str*)) or
        (all of ($ict_patch*))
}

---

Enterprise Mitigation Matrix#

When prioritizing defensive mitigations for edge remote access gateways, security leadership must balance rapid containment against operational continuity:

Remediation Strategy	Implementation Effort	Blast Radius & Operational Risk	Detection & Prevention Efficacy	Performance Overhead	Architectural Longevity
Workaround: Edge Reverse Proxy WAF Rule & Egress Block	15 - 30 Minutes (Deploy NGINX filter blocking .. and restrict firewall egress)	Low Legitimate user authentication does not rely on path traversal sequences.	High (95%) Stops unauthenticated traversal requests and severs reverse shells.	Negligible (< 0.5% proxy latency overhead).	Interim Protects perimeter while awaiting maintenance window for full firmware re-build.
Hotfix: Official Firmware Upgrade & CISA Directive Action	2 - 4 Hours (Factory re-image and upgrade to patched release)	Moderate Requires maintenance window and testing of client VPN profiles.	Absolute for Patched CVEs Permanently resolves URI parsing and command concatenation flaws.	Zero Baseline operational metrics maintained.	Mandatory Milestone Eliminates the specific known vulnerability code paths.
Architecture Fix: Zero Trust Network Access (ZTNA) Migration	3 - 6 Months (Transition from legacy edge VPN to identity-aware proxy ZTNA)	High Requires re-architecting remote access policies across the enterprise.	Comprehensive (100%) Eliminates public-facing edge listener attack surface entirely.	Zero Cloud-scale distribution.	Permanent State Zero-trust architecture immune to appliance-level RCE.

[!IMPORTANT] Because threat actors deployed persistent rootkits in encrypted loopback partitions that survive in-place firmware upgrades, CISA Emergency Directive 24-01 mandates a complete factory reset and clean firmware re-image before returning an appliance to production service.

---

Incident Response & Verification Playbook#

If your organization operated an internet-facing Ivanti Connect Secure gateway prior to applying mitigations, execute the following four-phase incident response playbook immediately:

flowchart TD
    classDef check fill:#1e293b,stroke:#f59e0b,stroke-width:2px,color:#fef3c7
    classDef alert fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef clean fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef triage fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd

    Start[Step 1: Network Egress & WAF Access Log Audit]:::triage --> AuditLogs{Anomalous Direct Outbound Egress Detected?}:::check
    AuditLogs -- Yes --> DeclareSeverity1[Declare Severity 1 Incident: Gateway Compromise]:::alert
    AuditLogs -- No --> OfflineScan[Step 2: Mount Disk and Run External ICT via Clean ISO]:::triage
    
    OfflineScan --> CheckHashes{Hash Mismatches or New Files Flagged by External ICT?}:::check
    CheckHashes -- Yes --> DeclareSeverity1
    CheckHashes -- No --> Step3[Step 3: Verify Factory Integrity & Patch Level]:::clean
    
    DeclareSeverity1 --> IsolateGateway[Disconnect Appliance from Corporate Network]:::alert
    IsolateGateway --> RevokeCerts[Revoke ALL TLS, SAML, and RADIUS Certificates]:::alert
    RevokeCerts --> ResetDomainCreds[Force Mandatory Enterprise-Wide Password Reset]:::alert
    ResetDomainCreds --> FactoryReimage[Step 4: Execute Full Factory Reset & Clean Firmware Flash]:::clean

Phase 1: Network Telemetry & Perimeter Log Triage#

1. Audit Outbound Firewall Connections: Query stateful firewall logs for outbound TCP connections initiated by the Ivanti appliance IP address over the past 30 days:

BASH

# Example query structure to detect anomalous outbound egress from Ivanti gateway
firewall_logs | where src_ip == "10.200.1.10" and dst_ip !in ("Known_Ivanti_Licensing_Subnets")

Any direct outbound connection to unfamiliar external IP addresses over ports 443, 80, 22, or ephemeral ports indicates active C2 beaconing.

2. Inspect WAF and Reverse Proxy Ingress Logs: Search for incoming requests containing .. targeting /api/v1/totp/user-backup-code/ or administrative endpoints.

Phase 2: Out-of-Band Forensic Verification (External ICT)#

Do not trust the internal integrity checker executing within the running operating system.

1. Take Live Memory and Disk Snapshots: Before powering off the appliance, capture a full RAM dump and virtual disk snapshot for forensic analysis.
2. Execute External ICT from Clean ISO:
   • Mount the official Ivanti External ICT ISO image.
   • Boot the virtual machine or physical hardware directly from the external optical drive.
   • Review the resulting cryptographic manifest comparison log:
     • Check /tmp/manifest/ and /tmp/scanner/ output.
     • Flag any modified core binaries (DSAuth.pm, api.py, welcome.cgi) or unmanaged files in /home/webserver/htdocs/.

Phase 3: Containment, Eradication & Enterprise Credential Revocation#

If compromise is confirmed or suspected:

1. Immediate Appliance Isolation: Disconnect the gateway from internal network interfaces immediately.
2. Execute Full Factory Reset:
   • Trigger a hardware/hypervisor-level factory reset (factory-reset from console recovery menu).
   • Re-flash the operating system using a trusted, verified firmware image provided directly by the vendor.
3. Revoke and Re-Issue All Gateway Cryptographic Material:
   • Revoke existing TLS web certificates and regenerate private keys.
   • Regenerate SAML identity provider signing certificates and metadata.
   • Change shared secrets for all connected RADIUS, TACACS+, and LDAP directories.
4. Mandatory Enterprise Identity Reset: Because attackers deployed credential harvesting filters in the authentication pipeline, all enterprise user accounts, service principals, and administrative passwords that authenticated via the VPN during the intrusion window must be force-reset.

Phase 4: Post-Remediation Hardening Verification#

Before restoring the gateway to production service:

• Verify that an upstream reverse proxy / WAF actively blocks .. and relative path traversals with HTTP 403.
• Verify that DMZ firewall egress rules block all direct outbound connections to 0.0.0.0/0.
• Confirm that the appliance is running patched firmware (e.g., version 22.6R2.1 or newer).
• Ensure Suricata/Snort network signatures are active on the inspection tap.
• Schedule recurring, automated offline integrity checks using external boot media.

---

Authoritative References#

1. Volexity Threat Research: Active Exploitation of Two Zero-Day Vulnerabilities in Ivanti Connect Secure VPN (CVE-2023-46805 and CVE-2024-21887) — Volexity Blog
2. Cybersecurity and Infrastructure Security Agency (CISA): Emergency Directive 24-01: Mitigate Ivanti Connect Secure and Policy Secure Vulnerabilities — CISA Directives
3. Google Cloud Mandiant Threat Intelligence: Cutting Edge: Suspected Chinese Cyber Espionage Campaign Exploiting Ivanti Zero-Days — Mandiant Research
4. Ivanti Product Security Advisory: CVE-2023-46805 & CVE-2024-21887 Security Advisory and Remediation Guide — Ivanti Security Portal