Citrix NetScaler ADC & Gateway Zero-Days Under Active Exploitation — Detection, Isolation, and Hardening Guide

On September 26, 2026, security firm watchTowr disclosed that two new, unpatched vulnerabilities in Citrix NetScaler ADC and NetScaler Gateway are being actively exploited in the wild. Both flaws reportedly allow unauthenticated remote code execution — the worst-case scenario for an internet-facing edge appliance. As of this writing, Citrix has not confirmed the vulnerabilities, assigned CVE identifiers, or published a fix. Some administrators have already made the decision to take appliances offline entirely rather than leave them exposed while waiting for vendor guidance.

If you run NetScaler ADC or NetScaler Gateway — particularly as an SSL VPN, ICA proxy, or load balancer fronting internal applications — treat this as a drop-everything event. These appliances sit at the perimeter by design, hold session credentials and authentication material, and historically have been among the most aggressively targeted products in the enterprise stack. An unauthenticated RCE on NetScaler is not a vulnerability; it is a pre-positioned foothold on your network boundary.

This post covers what we know, how to hunt for compromise on the appliance and downstream, and what to do while there is no patch.

Technical Analysis

Affected Products

• Citrix NetScaler ADC (all roles: load balancer, content switching, gateway)
• Citrix NetScaler Gateway (SSL VPN / ICA Proxy deployments)

Because Citrix has not yet confirmed the flaws, no official affected-version list or CVE identifiers exist. Until vendor guidance lands, assume all currently deployed versions and builds are potentially affected, including appliances fully patched against prior NetScaler advisories. Do not take comfort in being "current" — this is precisely the trap that burned defenders during past NetScaler exploitation waves, where attackers targeted appliances before fixes were applied and persisted afterward.

How the Attack Works (Defender's View)

Based on watchTowr's reporting, the two flaws permit unauthenticated code execution against the appliance. The practical attack chain defenders should model is:

1. External reconnaissance: Mass scanning for exposed NetScaler management, gateway (typically TCP/443), and management interfaces (NSIP, typically TCP/443 on the management IP). NetScaler instances are trivially fingerprintable via HTTP response headers and login portal paths.
2. Unauthenticated exploitation: Malicious requests directed at the vulnerable component execute code on the appliance — historically in the context of the NetScaler FreeBSD-based operating system, often with high privileges.
3. Post-exploitation on the appliance: Deployment of webshells or scripts under the NetScaler web root (/netscaler/, /var/vpn/, /var/netscaler/gui/ paths), modification of the ns.conf configuration, cron-based persistence, and credential harvesting from memory or configuration.
4. Pivoting inward: Use of harvested session tokens, LDAP bind credentials stored in config, and the appliance's trusted network position to move into internal segments.

Exploitation Status

• Active in-the-wild exploitation: CONFIRMED by watchTowr as of September 26, 2026.
• Vendor patch: NOT AVAILABLE. Citrix has not confirmed the flaws.
• CVE assignment: NONE at time of writing. Do not trust sources citing specific CVE numbers until Citrix publishes them.
• CISA KEV: Not yet listed — but given the pattern with prior NetScaler zero-days, expect rapid KEV addition with a short federal remediation deadline once CVEs are assigned.

The uncomfortable truth: with no patch, your defensive options are detection, isolation, exposure reduction, and — for some organizations — taking the appliance offline. That last option is not hyperbole; administrators are already doing it, and if your NetScaler is not mission-critical this week, it is the safest posture available.

Detection & Response

Detection on NetScaler appliances is genuinely hard — they are network appliances, not endpoints with EDR. Your detection strategy must combine on-appliance forensic review, network telemetry, and downstream endpoint hunting for post-compromise activity.

Sigma Rules

The following rules target the post-exploitation behaviors most consistently observed when NetScaler appliances are compromised: webshell placement in the NetScaler filesystem (observable via forwarded syslog/file telemetry) and suspicious child process execution from the web server process on downstream systems that attackers pivot to.

---
title: NetScaler Webshell Artifact Creation in Web Directories
id: 3f8a2b71-9c4d-4e6a-b1f2-7d8e9a0b1c2d
status: experimental
description: Detects creation of script files in NetScaler web-serving directories, a hallmark of post-exploitation webshell deployment on compromised NetScaler ADC/Gateway appliances. Requires file-integrity or syslog forwarding from the appliance.
references:
  - https://thehackernews.com/2026/09/warning-two-unpatched-citrix-netscaler.html
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/09/27
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_paths:
    TargetFilename|contains:
      - '/netscaler/portal/'
      - '/var/vpn/'
      - '/var/netscaler/gui/'
      - '/netscaler/ns_gui/'
  selection_ext:
    TargetFilename|endswith:
      - '.php'
      - '.pl'
      - '.py'
      - '.cgi'
      - '.sh'
  condition: selection_paths and selection_ext
falsepositives:
  - Legitimate Citrix firmware updates or customization (verify against change windows)
level: high
---
title: NetScaler Shell Spawned from HTTP Service Processes
id: 8c1d4e52-6a7b-4f39-9d0e-2b3c4d5e6f70
status: experimental
description: Detects interactive shells or command interpreters spawned by web-related processes on NetScaler appliances or adjacent systems, consistent with code execution via an exploited web-facing service. Requires process telemetry forwarded from the appliance (e.g., via auditd/syslog) or observed on pivot targets.
references:
  - https://thehackernews.com/2026/09/warning-two-unpatched-citrix-netscaler.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/27
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/httpd'
      - '/nginx'
      - '/nshttpd'
      - '/php'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/csh'
      - '/tcsh'
      - '/python'
      - '/perl'
      - '/curl'
      - '/wget'
  condition: selection_parent and selection_child
falsepositives:
  - NetScaler health-check scripts (rare; validate against known admin activity)
level: critical
---
title: Outbound Connection from NetScaler Appliance to External Infrastructure
id: 5e6f7a8b-9c0d-4e5f-a6b7-8c9d0e1f2a3b
status: experimental
description: Detects unexpected outbound network connections from NetScaler appliances to external IP addresses. NetScaler appliances typically initiate outbound connections only for licensing, firmware checks, DNS, and configured monitors — novel outbound destinations warrant investigation during active zero-day exploitation.
references:
  - https://thehackernews.com/2026/09/warning-two-unpatched-citrix-netscaler.html
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/09/27
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: firewall
  product: netscaler
detection:
  selection:
    DeviceDirection: 'outbound'
    DestinationIP|cidr:
      - '0.0.0.0/0'
  filter_known:
    DestinationPort:
      - 53
      - 123
  condition: selection and not filter_known
falsepositives:
  - Citrix licensing and telemetry endpoints (maintain an allowlist of known-good destinations)
  - Configured LDAP/RADIUS backend traffic (these should be internal destinations only)
level: medium

KQL Hunt — Microsoft Sentinel

This query hunts NetScaler appliance syslog/CEF telemetry for indicators of exploitation and post-exploitation: unusual HTTP request patterns hitting gateway endpoints, and outbound connections from the appliance to rare external destinations.

// Hunt 1: Suspicious requests to NetScaler gateway/login endpoints with anomalous characteristics
let lookback = 14d;
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where DeviceVendor =~ "Citrix" or DeviceProduct has "NetScaler"
| where RequestURL has_any ("/vpn/", "/logon/", "/cgi/", "/ns_gui/", "/oauth/") or RequestURL contains ".."
| summarize RequestCount = count(), DistinctSources = dcount(SourceIP), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceIP, RequestURL, RequestMethod, DeviceAction
| where RequestCount > 50 or RequestURL contains ".."
| order by RequestCount desc;

// Hunt 2: Outbound connections FROM NetScaler appliances to rare external destinations
let NetScalerIPs = dynamic(["10.0.0.10", "10.0.0.11"]); // Replace with your NetScaler NSIP/SNIP addresses
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where SourceIP in (NetScalerIPs)
| where ipv4_is_private(DestinationIP) == false
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DestinationIP, DestinationPort, Protocol
| where Connections < 20  // Rare/novel destinations only — tune threshold for your environment
| order by Connections asc;

Velociraptor VQL

For organizations running Velociraptor on pivot-candidate systems (jump hosts, AD-joined servers reachable from the NetScaler segment), this artifact hunts for tooling commonly staged after edge-device compromise. Note: Velociraptor cannot run on the NetScaler appliance itself — this targets the downstream blast radius.

-- Hunt for post-compromise tooling on systems reachable from the NetScaler network segment
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(mimikatz|sekurlsa|procdump.*lsass|comsvcs.*MiniDump|ntdsutil.*snapshot)'
   OR Exe =~ '(?i)(psexec|paexec|remcom)'
   OR (Name =~ '(?i)powershell|pwsh' AND CommandLine =~ '(?i)(-enc|-e )' AND Username =~ '(?i)system')

Remediation

There is no patch. That changes the calculus — your options are exposure reduction, hardening, active hunting, and potentially shutdown.

Immediate Actions (Today)

1. Remove management interface exposure. Verify the NetScaler management interface (NSIP) is not reachable from the internet. It never should be, but audit it now — check firewall rules and the appliance's own ACLs.
2. Inventory and assess criticality. Enumerate every NetScaler ADC/Gateway instance, its version/build, its internet-facing VIPs, and what internal resources it fronts. If an appliance fronts non-essential services, take it offline until Citrix ships a fix — this is what peer administrators are already doing, and it is the only action that eliminates the vulnerability.
3. Restrict gateway access by source IP where business-feasible. If your VPN user population is known (e.g., corporate egress ranges), apply firewall-level source restrictions in front of the gateway VIP.
4. Capture forensic evidence before rebooting or reimaging. Memory-resident implants vanish on reboot. Pull /var/log/, shell history, ns.conf backups, running process lists, and active connections first.

Appliance Forensic Triage

Run the following from the NetScaler shell (drop to shell with shell from the CLI) to gather triage artifacts:

# Recently modified files in web-serving directories (webshell hunting)
find /netscaler/portal /var/vpn /var/netscaler/gui /netscaler/ns_gui -type f -mtime -30 -ls 2>/dev/null

# Unexpected script files in web roots
find /netscaler /var/vpn -type f \( -name "*.php" -o -name "*.sh" -o -name "*.pl" -o -name "*.py" -o -name "*.cgi" \) -ls 2>/dev/null

# Cron and persistence review
crontab -l
cat /etc/crontab
ls -la /var/cron/tabs/ 2>/dev/null

# Running processes and listening sockets — look for unfamiliar daemons
ps aux | head -50
netstat -an | grep LISTEN

# Active outbound connections from the appliance
netstat -an | grep ESTABLISHED

# Review recent CLI/shell command history and access logs
cat /var/log/ns.log 2>/dev/null | tail -200
cat /var/log/bash.log 2>/dev/null | tail -200
ls -la /var/log/http*access* 2>/dev/null

# Check for unauthorized local users / config changes
grep -i "add system user" /var/log/ns.conf* 2>/dev/null
show system user

Medium-Term Actions

• Monitor Citrix channels continuously. Watch the Citrix Security Bulletin page (https://support.citrix.com/article/CTX…) and watchTowr's advisories for CVE assignment, affected-version confirmation, and patches. Subscribe to the CISA KEV feed — prior NetScaler zero-days landed in KEV within days with 48–72 hour federal deadlines.
• Segment the NetScaler DMZ aggressively. Ensure the appliance's SNIP cannot reach domain controllers, management networks, or credential stores beyond what its configured services strictly require. Assume breach.
• Rotate credentials post-compromise-suspicion. If triage reveals any suspicious artifact, rotate LDAP bind accounts, service accounts stored in ns.conf, and all user credentials that transited the gateway. Treat sessions as compromised — force re-authentication and invalidate tokens.
• Plan for reimage. Once Citrix releases a fixed build, strongly consider a clean reimage rather than in-place upgrade for any appliance with unexplained artifacts. In-place upgrades have historically left attacker persistence intact on NetScaler.

If You Cannot Take the Appliance Offline

Place a properly configured WAF in front of the gateway VIP with strict request normalization, block requests containing path traversal sequences, and log full request bodies for the gateway endpoints. This is a speed bump, not a fix — but combined with source-IP restriction and aggressive outbound egress filtering on the appliance itself, it meaningfully raises attacker cost while you wait for Citrix.

The Bottom Line

Unauthenticated RCE on an internet-facing identity and access appliance, actively exploited, with no patch — this is the scenario tabletop exercises are built around. The defenders who fare best in the next two weeks will be the ones who treated September 26 as day zero of an incident, not day zero of a news cycle. Hunt now, reduce exposure now, and be ready to patch and reimage the moment Citrix ships.

Related Resources

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