-> scanned the payload this is what it does: The payload is a shell script (about 800 lines) that turns a NetScaler into a permanent, hidden entry point into the network and steals the whole configuration. I only read it; I didn't run it. Step by step: 1. Webshells (remote control through the browser) • It writes the same PHP webshell three times in `LogonPoint/custom`:

.slap.receiver

,

.ctxs.receiver

and

receiver.deb

. • Each one always answers "404 Not Found", so it looks like a missing file. • It only acts when a cookie

CsrfToken

holds the attacker's fixed token (

072874c2…

). It then runs the command in the cookie

CsrfToken2

. Commands in cookies don't show up in the HTTP access logs. • Backup copies go to

/nsconfig/.slap/

, so the webshells can be put back. 2. Making the webshell reachable • It changes `/etc/httpd.conf`: ◦ switches PHP on (

php_flag engine on

) ◦ lets

.deb

files run as PHP ◦ adds an alias

/logon/LogonPoint/custom/receiver.v2.min.css

that points at the webshell, so requests look like an ordinary Gateway stylesheet • The original is saved as

/etc/httpd.conf.slap.bak

, and it tests the config before applying it. 3. Root rights •

chmod 6555 /bin/sh

makes the shell setuid root, so the webshell runs commands as root even if the web server doesn't. 4. Tunnels into the internal network • A Perl agent (

/nsconfig/.slap/agent.pl

+

bridge.pl

) listens locally (

/tmp/.uxdport

,

/tmp/.uxdlock

). • Two Python tunnels in `/var/tmp/.ux/`: ◦

slapshot.py

on

127.0.0.1:9909

◦

whipd.py

on

0.0.0.0:9910

, reachable from outside • The attacker sends tunnel commands base64-encoded in an

X-Cmd

header, and answers come back hidden in "404" pages. The server identifies itself as

NSGW

, so the traffic looks like normal Gateway traffic. • Connections leave from the NetScaler's own IP, so the attacker can reach internal servers as if they were the NetScaler. 5. Surviving reboots • Lines added to

/nsconfig/rc.netscaler

, which runs at every boot. • Root crontab: the agent every minute, and

boot.sh

every 5 minutes.

boot.sh

puts the

httpd.conf

changes back after each reboot. •

/nsconfig

is kept across reboots and upgrades, so a reboot or an upgrade alone does not remove it. 6. Data theft It packs and uploads to

213.209.159.55:443/t/380d56/

, with

curl

PUT: • all of `/nsconfig`:

ns.conf

, the keys `F1.key`/`F2.key`, certificates and private keys • the older saved configs

ns.conf.0

to

.4

and

.bak

• every system backup in

/var/ns_sys_backup/

•

httpd.conf

and a diagnostics file (

uname

, Python and

curl

paths) Its staging folder

/var/tmp/.s2loot

and logs in

/var/tmp/.slap-*

stay behind. What that means for anyone hit by it • The attacker has every secret in the config: LDAP bind passwords, RADIUS secrets, private keys, the KEK files and admin password hashes. Rotate all of them and revoke all certificates, as in CTX694799. • The box is a foothold into the internal network (port 9910 and the webshell). Check firewall logs for connections from the NetScaler to internal systems and to

213.209.159.55

. • Rebuild, don't clean up:

/nsconfig/.slap

and the cron jobs bring it back. On a fixed build, the SAML attack seems to fail and "only" crash

nsaaad

, which is why the appliances reboot. Whether the attack can succeed anywhere isn't public yet, so apply the workaround from Citrix Support.