LevelBlue adds a fourth NetScaler web shell disguise. Citrix says an update is not a cleanup

Six reports, four disguises

Six vendor reports now describe web shells on NetScaler appliances attacked through the two zero-days that Citrix fixed on 27 September. Sorted by what the request looks like and where the hidden file sits, they describe four different disguises: a package file, an icon and two stylesheets. The newest, in a report LevelBlue published on 30 September, is a hidden file called .local_journal that is served at URLs resembling a NetScaler stylesheet. Not one file name in any of the four will help you find another.

What that does not establish. It does not say how many appliances carry any of them. It does not say whether six reports mean six operators or one. LevelBlue gives no date for anything it saw and no count of the customer environments it came from, and it describes the web shell and the account without saying on how many appliances either was found. And it does not say what an update does to a web shell already in place. On that, Citrix's own page, last updated on 30 September, is the clearest source: an update "does not remove potential compromise artifacts".

This briefing covers only what LevelBlue's report adds. The timeline and the federal clock are in the earlier briefing on the 22 days before the patch, and the eight-flaw bulletin is in the briefing on the three-day clock. It stays at defender level: it names the artefacts vendors publish for hunting, and gives no commands, no payload content and no exploit steps.

What LevelBlue published, and what it left out

The post comes from LevelBlue's Threat Hunt Operations and Research team and is by analyst Sean Shirley with three contributors. It concerns CVE-2026-88771, the flaw Citrix describes as improper input validation that lets an unauthenticated attacker run arbitrary commands on every NetScaler ADC and Gateway in its default configuration. Citrix scores it 9.5 on CVSS 4.0, and NVD scores it 9.8 on CVSS 3.1. The post does not mention CVE-2026-88772, the flaw behind Mandiant's report.

In the order the post gives them, it reports login events whose username field carries attacker-controlled text, built around the watchdog-message words pitboss and NSPPE. It reports variants that only test a command, that fetch a script with curl or wget, or that copy or archive the configuration into a web directory. It analyses two second-stage payloads, a Python script and a Perl script. And it lists 23 indicators.

What LevelBlue's post states and does not state. Read in full on 1 October 2026; wording in quotation marks is the post's own.

Topic	Stated	Not stated
Which flaw	CVE-2026-88771, a "critical pre-authentication command-injection vulnerability".	Any link to CVE-2026-88772 or to the activity in Mandiant's report.
Where	Activity found while hunting "across multiple customer environments".	How many environments or appliances, or in which countries or sectors.
When	Nothing. The post is dated 30 September.	A first or last sighting. A LevelBlue post of 29 September, by a different author, says only that unconfirmed reports suggest exploitation "as early as Sept 24th".
Outcome	Its introduction says observed activity "included" payload retrieval, configuration staging, reverse shells, persistence and web-shell installation; its takeaways say others "attempted" to create privileged accounts and deploy web shells. A failed authentication event is not evidence that the attempt failed.	How many attempts worked. On how many appliances the account, the web shell or the archive was found. Whether any upload completed.
Who	Nothing.	An actor, a motive, or whether this is the activity Mandiant describes.
Fix	Patch affected appliances, and review historical telemetry for exploitation that may predate remediation.	Fixed builds. Whether patching removes the account, the shell or the configuration edits.
Indicators	23: 11 IPv4 addresses, 5 URLs, 4 file paths, 2 SHA-256 hashes and 1 account. LevelBlue says they are not exhaustive.	A hash of the web shell itself: both hashes are of downloaded scripts. The text of the web server change. Any log pattern for requests to the stylesheet lookalikes.

Counts from elsewhere. No count of victims comes from LevelBlue. Rapid7 reported on 30 September that it had identified two organisations compromised through CVE-2026-88771. Help Net Security quotes researcher Kevin Beaumont as tracking over 100 victim organisations; we did not find his own post. Neither number says how many appliances carry the files LevelBlue names.

Commercial interest. LevelBlue sells managed detection, threat hunting and incident response, and its page carries a demonstration offer beside the research. That is not a reason to doubt what its hunters saw. It is a reason to read the post as one vendor's observations of its own customers, which is why the table above matters more than the headline.

The payload, and where it sits in the week

The Perl script, update_c08937.pl, is the part of the post that matters for detection. LevelBlue says the injected command fetched it and piped it straight into Perl, so it ran without first being saved to a fixed place on disk. The diagram shows what LevelBlue's analysis says the script does and what each change leaves behind.

Three details are worth stating plainly. First, the account, the permission change, the web shell and the web server edit are changes to things that persist; LevelBlue lists them as the artefacts that show whether the payload ran. Second, the script deletes itself and the configuration archive, so finding neither proves nothing. Third, the archive holds the whole configuration directory. Rapid7's post says that directory contains the device configuration with encrypted administrator passwords, the LDAP, RADIUS and TACACS bind passwords, and TLS certificates with their private keys.

Dated observations on the NetScaler web shells, and where LevelBlue's report sits. Days are calendar days to 30 September, derived by us.

Date	Reported by	What it reports	Days before LevelBlue
21 Aug	Unit 42	Probing of a Gateway and more than 100 other systems: version fingerprinting, not exploitation.	40
4 Sep	Unit 42	Requests begin to the folder that held web shells, for the DTLS flaw (CVE-2026-88772).	26
5 Sep	eSentire	A CVE-2026-88771 web shell operated at one victim.	25
20 Sep	Rapid7	First injected login attempt it saw, logged as a failed login. Rapid7 says its first compromise involved this command.	10
21 Sep	Unit 42	A web shell dropped in three stages at a US target, CVE-2026-88771.	9
24 Sep	GreyNoise, Rapid7	A failed attempt on a GreyNoise sensor. Rapid7 sees a web shell at a compromised organisation.	6
27 Sep	Citrix, CISA	Bulletin, fixed builds and KEV listing, due 30 September.	3
29 Sep	Mandiant and GTIG	Report on CVE-2026-88772, with two web shell disguises of its own.	1
30 Sep	LevelBlue	Its report, on the federal due date. It gives no date for its own observations.	0

Counted from today, 1 October, the fix is 4 days old and the federal due date is 1 day behind us. LevelBlue's report arrived 3 days after the fix and on the due date itself. Unit 42's update also moves the earliest web shell activity it reports to 4 September, a day before the date used in the earlier briefing; it dates only probing to 21 August.

Four disguises, one playbook

Read across the six reports and the pattern is plain. Each shell is a PHP file that is not named like one, reached through a URL that looks like something a Gateway serves anyway: an installer, an icon, a stylesheet. GreyNoise describes the first stylesheet disguise as an attempt on a sensor, and Rapid7 and Unit 42 report the same hidden file, .ctxs.receiver, on compromised appliances. LevelBlue's differs in file name, in stylesheet name and in where it sits, the logon folder itself rather than its custom subfolder, but it asks the same things of the appliance.

The three steps underneath. Five of the six reports describe all three: PHP execution switched on or granted to a non-script file in the web server's configuration, a public URL mapped to the file, and special permission bits on /bin/sh. Rapid7 gives only the file path. Unit 42 notes that the appliance's web server ships with PHP switched off, so an "on" is a finding in itself. Two reports, LevelBlue's and Unit 42's, give the identical permission value, 6555, for the shell, across two different file names. That fits shared tooling or copying, and no source says which.

The indicator lists overlap less than the behaviour. Across the five reports that publish hashes in the open, nine SHA-256 values appear, and all nine are different, so no hash from one report finds anything in another. Mandiant's post lists no hashes in the open; its fuller indicator set is in a collection for registered users. Four of LevelBlue's eleven IPv4 addresses, the four it describes as hosting its payloads, also appear in eSentire's list of 29 September, where each is labelled a payload host. Two of eSentire's other addresses appear in Unit 42's list, and GreyNoise's single address appears in eSentire's. None of LevelBlue's appears in the lists of Mandiant, GreyNoise or Unit 42, or in Rapid7's sample. Shared infrastructure can mean one operator, shared hosting or copied tooling. None of the reports says which, and LevelBlue does not say that its activity is the one Mandiant describes.

Two gaps that appear when the lists are laid side by side. These are our comparisons of published material, not statements by any vendor.

• The file sweeps in Mandiant's post, and eSentire's file indicators, sit in the VPN client, media and theme folders. LevelBlue, GreyNoise, Rapid7 and Unit 42 report their shells under the logon directory, which Unit 42 calls the Gateway web interface root and whose custom subfolder it says is web-accessible by design and often not monitored. Mandiant's sweeps do not name that tree. Its checks of the web server configuration would still see an edit, though LevelBlue does not publish the text of the directive it adds, so we cannot say they would match it.
• Mandiant's check on the system shell describes the listing for a single permission bit. LevelBlue's 6555 sets both the setuid and setgid bits and removes owner write, which converts to a listing that reads differently. Check for either special bit, not for one string.

The lesson is the one the table of names teaches. A hunt built from one vendor's file names finds that vendor's shell. A hunt built from behaviour finds all four: a PHP switch that was off, a handler or alias that was not there, a permission bit that should not be set, a hidden file in a directory of static assets. Behaviour needs a known-good baseline to compare against, and that is a job done before an incident, not during one. The point about baselines is our reading.

Does an update remove it? What each source says

This is the question a response plan turns on. Every source that addresses it says no or is silent. None reports a test of updating an appliance that was already compromised.

What the sources say about updating an appliance that may already be compromised. Read between 28 September and 1 October 2026.

Source	Says	Does not say
Citrix, community blog, marked updated 30 Sep	An update "does not remove potential compromise artifacts" or prove that nothing happened before it. If compromise is suspected or confirmed, deploy a new, updated instance instead of treating the update as a cleanup.	Which artefacts. Any test on a compromised appliance.
eSentire, 29 Sep	Patches do not remove deployed payloads or persistence mechanisms. Treat an internet-facing appliance that was unpatched in early September as compromised until an integrity assessment shows otherwise.	How it knows. No test is described.
Unit 42, updated 30 Sep	Updating "will not remove access for attackers" who have already established persistence.	The basis for the statement.
CISA (27 to 28 Sep), NCSC and NHS England Digital (28 Sep)	CISA: preserve forensic evidence before updating, as updates may lose forensic visibility. NCSC: isolate and replace, investigate, then update. NHS England: assess before patching, as patching may delete evidence.	Whether an update removes anything. They address the order of work.
Mandiant, 29 Sep	Upgrading is its recommended option. Isolate appliances where indicators are found. Rotate credentials after patching.	Whether upgrading removes a shell.
LevelBlue, 30 Sep	Patch affected appliances and review historical telemetry for exploitation before remediation.	Anything about removal.

Our inference, which no source tests. LevelBlue's payload edits the saved configuration, the web server configuration, the permission bits of a system binary and a directory of web files. We found no source that says an in-place update reverts any of them, and Citrix says not to rely on one. Citrix's rebuild guidance adds a caution that bites here: restore a configuration backup only if it predates the compromise. Because the payload writes its account into the saved configuration, a backup taken after it ran may bring the account back. That last step is ours, not Citrix's or LevelBlue's.

Four labels that do the attacker's work

• "Patched." Citrix's own page says an update does not remove compromise artifacts or show that nothing happened before it. A closed ticket records the update, not the state of the appliance.
• "Failed login." LevelBlue says failed authentication events are not evidence that the attempt failed. Rapid7's sample for 20 September carries the result FAILED_BAD_LOGIN, and Rapid7 says its first compromise involved that command. eSentire says exploitation does not depend on the login succeeding. A rule that drops failed logins as noise drops the event that matters.
• "A stylesheet." A URL ending in .css is a claim about a file, not a property of it. What decides it is what the web server does with the request, and that lives in its configuration, not in the name. LevelBlue names one lookalike and says hexadecimal variants exist. GreyNoise's published pattern accepts any hexadecimal suffix on another.
• "sec_monitor." The account the payload creates is named like security tooling. That is our reading of the name, but an account list skimmed for things that look wrong would pass it. It is found by comparison with a list from before September, not by reading.

Fixed builds, and two traps in them

The builds below are from Citrix's bulletin and its community blog. Both flaws are fixed by the same builds.

Fixed builds for CVE-2026-88771 and CVE-2026-88772, from Citrix bulletin CTX697096 and its blog, last updated 30 September 2026.

Build track	Fixed in	Note
ADC and Gateway 14.1	14.1-73.37 and later	None in the bulletin.
ADC and Gateway 13.1	13.1-64.23 and later 13.1	Citrix: a known issue can cause a cyclic reboot on upgrade for some configurations. If the command it names lists variables, plan for 13.1-64.24.
ADC 14.1-FIPS	14.1-73.37 FIPS and later	None.
ADC 13.1-FIPS and 13.1-NDcPP	13.1.37.279 and later	NCSC and NHS England Digital write 13.1-37.279. Citrix writes 13.1.37.279; follow Citrix.
VPX 15.1 Technology Preview	No fix yet	Citrix says it is also vulnerable, that a fix is coming "shortly", and that it is not for production use.
12.1 and 13.0	End of life	NHS England Digital says they are likely vulnerable and must be migrated.

What to hunt and harden, in the order worth doing

The UK record. The NCSC alert of 28 September says the NCSC is working to understand the impact on UK organisations. We found no UK count. NHS England Digital's alert of the same day assesses further exploitation as almost certain. Both put assessing for compromise ahead of updating. Specific strings and paths are in the vendors' own posts; this list gives the order and the reason.

What we could not verify

The question this leaves

Every vendor named above has published the names of the files it found. That is four disguises and nine hashes with nothing in common, and nothing says the next intrusion will not bring a fifth. So the question for your own process: what do you hold today that would show a file you have never heard of does not belong on your NetScaler? A record, taken before September, of its accounts, its web server configuration and its web directories would answer it. A list of bad names would not.

Key facts