A request for a NetScaler Gateway icon returned a 404, took unusually long to process, and carried a multi-kilobyte response. In Mandiant and Google Threat Intelligence Group’s September 29 intrusion report, that was a sign of a disguised PHP web shell on Citrix NetScaler ADC and Gateway appliances after attackers exploited CVE-2026-88772. In at least one intrusion, the attackers used a companion proxy to reach internal systems for reconnaissance and credential theft.
GTIG says the campaign has run since at least early September and likely affected organizations in North America and Europe across government, finance, education, legal and professional services. Its report adds appliance-level compromise evidence to Nulltap’s earlier build and exposure guide: defenders now have specific packet-engine logs, web-server changes and tunneler files to check, including on appliances already updated.
A packet crash opens the appliance
During the pre-authentication DTLS handshake over UDP/443, the NetScaler Packet Processing Engine (NSPPE) parses incoming records. GTIG has not obtained exploit code. From frontline telemetry, it assesses that malformed or fragmented record headers corrupt heap memory and divert control flow to root-level code execution on the underlying FreeBSD system. Use the observed packet-engine logs and host artifacts to prioritize investigation of an affected node. The NetScaler CNA record classifies CVE-2026-88772 as a memory overflow with code-execution and availability impacts.
Look for SSL_HANDSHAKE_FAILURE with ClientVersion DTLSv1.0 and Reason "Handshake failure-Internal Error" in the appliance SSL/audit logs. GTIG says a failure followed within minutes by an NSPPE exit in /var/log/messages is “a strong exploitation signal.” The latter log can contain exit with orphan rings and pitboss NOT restarting NSPPE; an unexpected new core under /var/core/ warrants the same investigation. Standard ns.log forwarding does not include /var/log/messages, so collect that system log separately and correlate events on the same appliance. Small amounts of traffic can be enough; traffic-volume alerts alone are a weak tripwire here.
Icon paths conceal PHP shells
After initial root access, attackers changed /etc/httpd.conf so that .deb or .sig files execute as PHP. One variation used AliasMatch to map requests ending in .ico under /vpn/media/ to a corresponding .sig shell in /var/netscaler/gui/vpn/scripts/linux/. A request that resembles a harmless static icon can therefore reach executable server code. Other observed shell paths include /netscaler/ns_gui/vpn/scripts/linux/. Treat unexpected plain-text PHP in these client plug-in directories as compromise evidence.
The installer also set the SUID bit on /bin/sh, giving subsequent web-server activity a route back to root privileges. Check root ownership and permissions on /bin/sh: -rwsr-xr-x is the suspicious mode GTIG describes. Inspect /etc/httpd.conf, /nsconfig/httpd.conf and /flash/nsconfig/httpd.conf for unauthorized AddHandler, AddType, php_flag engine on, AliasMatch or RewriteRule changes; compare them with known-good appliance configuration before treating a match as malicious. In /var/log/httperror*, look for missing .sig files and PHP execution errors. Correlate /var/log/httpaccess.log* entries for /vpn/media/*.ico or /vpn/scripts/ with 404 responses that have large bodies or unusually long processing times. Legitimate clients routinely request /vpn/media/ assets, so the path alone is insufficient.
WHIPSHOT bridges to SLAPSHOT
GTIG recovered WHIPSHOT, a PHP shell disguised as a Debian package, and SLAPSHOT, a Python TCP proxy. WHIPSHOT accepts chunked data in HTTP_X_UX and HTTP_X_UX_0 through HTTP_X_UX_95 headers, then relays it to SLAPSHOT on the appliance’s loopback interface. Standalone shells used HTTP_NSC_LDAP or HTTP_NSC_CLIENTTYPE. WHIPSHOT can return 404 while carrying proxy data in the response body. SLAPSHOT writes its listening port to /tmp/.uxdport and uses /tmp/.uxdlock for its process lock; investigate either file and anomalous Python processes while collecting evidence. GTIG also supplies the G_APT_Backdoorwebshell_WHIPSHOT_1 and G_APT_Tunneler_SLAPSHOT_1 YARA rules for file-based triage.
The published network indicators are scanning/staging address 143.198.7[.]94 and exploitation-and-installer address 157.254.167[.]12. Search historical firewall and appliance logs for those values, then investigate unexpected outbound connections from NetScaler NSIP and SNIP addresses toward credential vaults, PAM systems, domain controllers and other internal destinations. Those internal flows matter because GTIG observed an attacker manually using the proxy for internal reconnaissance and credential theft. A shell found on a gateway calls for investigation beyond the gateway itself.
Patch both flaws and contain access
The NetScaler CNA record for CVE-2026-88771 separately describes unauthenticated command execution from improper input validation. For both exploited vulnerabilities, install the latest applicable fixed build: 14.1-73.37 or later on the 14.1 track, 13.1-64.23 or later on the 13.1 track. The CNA records also name 14.1-73.37 FIPS and 13.1.37.279 FIPS and NDcPP as ADC branch thresholds; confirm the correct branch-specific build with Citrix support when needed. Verify the running build on each appliance, including both nodes in an HA pair.
If upgrading must wait, disable DTLS on an internet-facing Gateway virtual server where operations permit, or drop inbound UDP/443 at the upstream firewall where DTLS is unnecessary. GTIG warns that local appliance ACLs let packets reach the vulnerable NSPPE before dropping them. These DTLS controls address CVE-2026-88772, not CVE-2026-88771; the fixed build addresses both. Broad IP allow-listing can break remote workforces with changing residential addresses, so plan any upstream restriction against actual access needs.
Verify recovery on each node
When the logs or files point to compromise, preserve appliance evidence, isolate the affected node, and assess both HA peers before re-enabling synchronization. GTIG recommends stopping HA configuration sync during that assessment because a compromised node could replicate its malicious httpd.conf edits. After the appliance is patched and recovered, terminate administrative and VPN sessions, rotate appliance secrets and connected LDAP, RADIUS, TACACS, SNMP and NITRO credentials, and examine downstream StoreFront, Delivery Controllers and privileged-access systems for suspicious use.
NetScaler Console’s IOC scan documentation lists Potentially Compromised, No Compromise Detected, Skipped, Failed to Execute and Execution in Progress as possible results, and says product usage telemetry is required to run it. Its detection logic can miss compromises. Use the scan as another lead while comparing the live web-server configuration and /bin/sh mode against a clean baseline. On each recovered node, verify the fixed running build, normal PHP handler and alias configuration, absence of the unauthorized SUID bit and tunneler files, and restored system, web and egress logging. A patched version blocks the reported entry route; the appliance and connected systems still need their own compromise investigation.