DEV Community

Max Bayern
Max Bayern

Posted on Originally published at ot-cyber.de

Securing Citrix NetScaler: A Checklist for Operators, Including OT

#cybersecurity #iot #networking #security

If you run Citrix NetScaler ADC or Gateway, you need to do three things now:

  1. Install the fixed builds (14.1-73.37 or 13.1-64.23, or the corresponding FIPS/NDcPP builds).
  2. Check the appliance for webshells and other traces of compromise.
  3. Separate OT remote access from the corporate gateway.

This affects organizations that run vulnerable NetScaler builds. Mandiant names targeted sectors in North America and Europe. At utilities and industrial companies, NetScaler is often the path service providers use to reach control centers and plants.

Infographic: Securing NetScaler – patching alone is not enough

What happened?

Since early September 2026, a threat actor has been exploiting two zero-days in NetScaler (CVE-2026-88771, CVE-2026-88772). Mandiant does not attribute the activity to a specific actor. Mandiant knows about the exploitation of CVE-2026-88771 only from vendor information. Mandiant describes an exploitation campaign with reconnaissance and credential theft that uses:

  • several PHP webshells (including WHIPSHOT)
  • a tunneling tool (SLAPSHOT)
  • persistence via handlers in httpd.conf and an SUID bit on /bin/sh
  • credential theft in the internal network

Citrix has released fixed builds.

My assessment: A patch closes the door, but it doesn't throw out anyone who's already inside. So check every appliance for the traces Mandiant describes, even if it is already patched.

Step 1: Patch the right way

  • Install the fixed builds (14.1-73.37, 13.1-64.23 or the corresponding FIPS/NDcPP builds) on every ADC and Gateway instance, including test and emergency systems.
  • My recommendation as general best practice: terminate all active sessions after patching. That way, sessions that may have been stolen lose their validity.
  • Replace older firmware branches that are out of support. Don't keep running them.

Step 2: Check for compromise

A patch does not remove webshells or backdoors. Check every appliance, even if it's already patched:

  • File system: Look for unknown PHP files and unexpected .deb or .sig files in the VPN directories, especially under /var/netscaler/gui/vpn/scripts/linux/ (also vista/ and mac/), /netscaler/ns_gui/vpn/media/ and /var/vpn/theme/. Mandiant has published IoCs for this.
  • Persistence: Check /etc/httpd.conf for unknown AddHandler or AliasMatch entries, check whether /bin/sh has the SUID bit set, and look for /tmp/.uxdport or /tmp/.uxdlock and unexpected Python processes.
  • Logs: Go back to early September. Watch for NSPPE crashes (ssl_handshake_failure with DTLS, pitboss messages in /var/log/messages) and check the httpaccess and httperror logs for unusual 404 responses with a large body.
  • Follow-on access: Check whether the NetScaler opened connections into the internal network that aren't part of normal operations.

If you find something, don't just rebuild the appliance. Preserve evidence first, then start incident response and rotate every credential that went through the gateway.

Step 3: Protect your OT

At utilities, municipal utilities (Stadtwerke) and machine builders, NetScaler often fronts more than office IT. Remote maintenance, the control center and service providers' access also run through it. That means:

  • Secure Remote Access (SANS CC4): Never route OT remote access straight through the corporate gateway. Use a dedicated jump host with MFA and per-session approval.
  • Defensible Architecture (SANS CC2): Put a firewall with clear rules between IT and OT. A compromised gateway must not be able to reach the control systems.
  • Network Visibility & Monitoring (SANS CC3): Monitor connections from IT into OT networks. That's where lateral movement shows up first.

If you also use your NetScaler gateway for OT, you've turned an IT problem into a plant problem.

Diagram: Securing NetScaler step by step

What this means for NIS2 and critical infrastructure (KRITIS)

If you fall under NIS2 and find a compromise, you have reporting obligations with short deadlines. So document the check itself carefully: what you checked, when, and what you found.

Quick checklist

  • [ ] Fixed builds (14.1-73.37 / 13.1-64.23 or FIPS/NDcPP builds) installed on all ADC/Gateway instances, including test and emergency systems
  • [ ] All active sessions terminated after patching (best practice)
  • [ ] Unsupported firmware branches replaced
  • [ ] VPN directories (/var/netscaler/gui/vpn/scripts/, /netscaler/ns_gui/vpn/media/, /var/vpn/theme/) checked against Mandiant IoCs
  • [ ] /etc/httpd.conf, SUID bit on /bin/sh, /tmp/.uxd* files and Python processes checked
  • [ ] Logs reviewed back to early September (NSPPE crashes, httpaccess/httperror, 404 responses with a large body)
  • [ ] Unexpected outbound connections into the internal network checked
  • [ ] OT remote access separated from the corporate gateway (jump host, MFA, per-session approval)
  • [ ] All checks documented for NIS2

Further resources

Original (German): https://ot-cyber.de/blog/netscaler-absichern-checkliste-fuer-betreiber-in-dach.html

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).

Top comments (0)