Build1 publisher3 min readPublished
Patching NetScaler to 14.1-73.37 leaves planted webshells and persistence in place
Attackers using two NetScaler zero-days since early September left webshells that patching to 14.1-73.37 or 13.1-64.23 does not remove. Operators have to search every appliance for those traces, patched or not, and move OT remote access onto a jump host of its own.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Mandiant links the campaign to PHP webshells including WHIPSHOT, a tunneling tool called SLAPSHOT, and credential theft inside victims' internal networks.
- Persistence comes from added handler entries in httpd.conf and a SUID bit set on /bin/sh, according to Mandiant's findings as summarized in a dev.to checklist.
- The checklist says to preserve evidence before rebuilding a compromised appliance, then rotate every credential that went through the gateway.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Being on a fixed build does not clear an appliance, so a gateway upgraded early still needs its file system, httpd.conf and logs checked back to early September.
- exposure Where one gateway carries both office VPN and remote maintenance into plants, an attacker on the appliance has a path toward control systems.
- cost A confirmed find means rotating every account that crossed the gateway, service providers' remote-maintenance logins included, after evidence is preserved.
- constraint NIS2 operators face short reporting deadlines after a find, so the hunt has to be documented while it runs, not reconstructed afterwards.
"A patch closes the door, but it doesn't throw out anyone who's already inside," the author of a NetScaler checklist posted on dev.to wrote [7]. The instruction that follows is to check every appliance for the traces Mandiant describes, including appliances already on the fixed builds [8]. The post says plainly that a patch does not remove webshells or backdoors [8].
Most of the hunt is file and config inspection. Start with unknown PHP files and unexpected .deb or .sig files under /var/netscaler/gui/vpn/scripts/linux/ and its vista/ and mac/ siblings, /netscaler/ns_gui/vpn/media/ and /var/vpn/theme/ [9]. Mandiant has published IoCs for this [10]. Next, read /etc/httpd.conf for AddHandler or AliasMatch entries nobody recognizes. Check whether /bin/sh has the SUID bit set, and look for /tmp/.uxdport, /tmp/.uxdlock and unexpected Python processes [11].
Log review goes back to early September [12]. The checklist names NSPPE crashes, including ssl_handshake_failure with DTLS and pitboss messages in /var/log/messages, and unusual 404 responses with a large body in the httpaccess and httperror logs [12]. A 404 with a large body is a server saying the page is missing while sending a lot of it. The last check is whether the appliance opened connections into the internal network that are not part of normal operations [13]. Mandiant's description of the campaign includes credential theft inside the internal network [3].
Once something turns up, order matters. The post warns against simply rebuilding the appliance and gives this sequence [14]:
1. Preserve evidence. 2. Start incident response. 3. Rotate every credential that went through the gateway.
Citrix has released fixed builds: 14.1-73.37 and 13.1-64.23, plus the corresponding FIPS/NDcPP builds [2]. They go on every ADC and Gateway instance, test and emergency systems included, and out-of-support firmware branches get replaced [16]. The author also recommends, as general best practice, terminating all active sessions after patching so that stolen sessions lose their validity [15].
The checklist ties the campaign to two zero-days, CVE-2026-88771 and CVE-2026-88772, exploited since early September 2026 [1]. For one of them, the record is thinner. According to the post, Mandiant knows about exploitation of CVE-2026-88771 only from vendor information [5]. Mandiant does not attribute the activity to a specific actor, and it names targeted sectors in North America and Europe [6].
At utilities, municipal utilities and machine builders, the same NetScaler gateway frequently handles remote maintenance, control center access and service-provider connections alongside office IT [17]. The checklist maps the response to SANS controls. OT remote access should go through a dedicated jump host with MFA and per-session approval, never straight through the corporate gateway (CC4) [18]. A firewall with clear rules belongs between IT and OT so a compromised gateway cannot reach the control systems (CC2) [18]. Connections from IT into OT should be monitored, since that is where lateral movement shows up first (CC3) [18]. "If you also use your NetScaler gateway for OT, you've turned an IT problem into a plant problem," the author wrote [19].
I think the jump host is the right tradeoff wherever a service provider reaches a plant through the gateway. It adds a hop and an approval to every session [18]. In exchange, a credential stolen from the gateway does not open a session into OT on its own, because the jump host still demands MFA and a per-session approval [18].
For operators under NIS2, finding a compromise brings reporting obligations with short deadlines. The post therefore advises documenting the check itself: what was checked, when, and what was found [20].
What to watch
- Whether Mandiant publishes its own evidence of CVE-2026-88771 exploitation beyond what the vendor reported.
- Whether Mandiant or Citrix attributes the campaign or publicly lists the targeted sectors in North America and Europe.
- Updates to Mandiant's IoCs for the VPN directories and /tmp/.uxd* files that would widen what operators have to search for.