SonicWall SMA1000: Volexity names UTA0533, IoC list out

Volexity’s writeup on Friday put a name to the actor who was inside SonicWall SMA 1000 appliances before SonicWall’s July 14 advisory went out: UTA0533, a previously undocumented cluster. Earliest observed compromise was June 22, three weeks before the CVEs went public. That’s the honest timeline — three weeks of quiet root access on internet-facing boxes.

That matters because until now the pre-disclosure detection was Rapid7’s MDR call and SonicWall PSIRT’s confirmation. Neither published a toolkit. Volexity’s Sean Koessel and Steven Adair did, and if you patched the unauthenticated SSRF and the command-injection chain and haven’t hunted the appliance since, this is the hunt list you didn’t have on Wednesday.

What UTA0533 dropped

Four named artifacts. Two are custom, two are open-source repurposed. Names, paths, sizes as Volexity published them:

• ROOTRUN — /usr/bin/xzfind, 13.1 KB. A small setuid ELF that gives the attacker root via setuid() on demand. Once dropped, they don’t need to re-exploit the chain to elevate — they just call the binary.
• KNUCKLEBALL — /usr/lib/python3.11/site-packages/deploy_new.py, 79.6 KB. Python script that injects two embedded JARs into legitimate SonicWall Java processes at runtime. The script is the delivery vehicle; persistence lives in the JARs.
• Suo5 — agent_wp8.jar, 33.7 KB. Open-source HTTP forwarding proxy. Reachable at /workplace/error.jsp on the appliance’s external interface. This is the tunnel: attacker traffic in, internal network out.
• ORANGETAIL — agent_wp9.jar, 21.3 KB. Custom Java web shell modeled on Behinder. Reachable at /workplace/dialogs/errorDialog.jsp on the external interface. This is the command shell.

The two JSP paths are the load-bearing detection. Both look like legitimate SonicWall paths, both are reachable pre-auth from the internet, and neither should be returning 200 in your access logs. If they are, and your appliance was on a vulnerable build before July 14 (12.4.3-03245, -03387, or -03434, or 12.5.0-02283, -02624, or -02800), assume UTA0533 or someone running the same tooling was on it.

The other appliance

Volexity worked two compromised boxes in the same engagement. On the second one, on top of the NGINX Unit config modification that Rapid7 and SonicWall already flagged, the attackers dropped /var/tmp/lib.sh and used it to run tcpdump — capturing unencrypted LDAP credentials off the wire. If your SMA1000 pointed at an on-prem AD that still speaks plain LDAP anywhere, rotate those service accounts before you rotate anything else. The credentials on the box are one problem; the credentials that walked past the box on the wire are another.

Priority call

If you patched to 12.4.3-03453 or 12.5.0-02835 by the CISA BOD 26-04 deadline of July 17 and stopped there, the honest question this weekend is whether ROOTRUN or ORANGETAIL is still sitting on the appliance. The order:

1. Check for the four artifact paths above — /usr/bin/xzfind, deploy_new.py, and the two JSP paths in access logs. Any hit is compromise, not exposure. Re-image, don’t patch over it. Rapid7’s IoC list from Wednesday covers the log signatures; Volexity’s covers the artifacts on disk. Use both.
2. Pull pcap or session history if you have it and look for LDAP traffic sourced from the appliance interface. If lib.sh ran on your box, LDAP creds are already out.
3. Rotate what actually crossed the box: LDAP service accounts, admin accounts on the appliance, MFA seeds for anyone whose token was issued through the SMA1000.

Volexity noted “available evidence suggests the threat actor was less successful moving laterally or gaining access to other systems.” That’s not a green light — that’s a note that they got root on the appliance and stalled at the perimeter. The weekend job is to keep it that way.