The SonicWall VPN Proxied the Attacker to Its Own Internal Database. The Password Was admin:admin. UTA0533 Lived There Three Weeks.
- Patrick Duggan
- 2 hours ago
- 5 min read
The appliance you buy to keep strangers out of your network handed one a tunnel to its own internal database, and the database was protected by the password admin:admin. That is not a metaphor for the SonicWall SMA1000 campaign Volexity published last week. That is the literal first two steps of the attack.
We are late to this one and we are going to say so up front, because the honest scorecard is the only one worth keeping. Volexity's Sean Koessel and Steven Adair published "Proxying to Compromise" on July 17. SonicWall disclosed on July 14. The actual exploitation started on June 22. We are writing on July 22 — five days behind the research and a full month behind the intrusion. This is us reading a live event carefully, not calling it early, and the receipts below are Volexity's work, credited to Volexity, not ours.
What we can add is the teardown, the beat this fits, and one thing a defender can pull from our feed right now.
The chain, because the chain is the lesson
Two vulnerabilities, chained. CVE-2026-15409 is a server-side request forgery in the SMA1000 Work Place interface, scored 10.0. CVE-2026-15410 is a command injection in the appliance management console, scored 7.2. Neither is interesting alone. Together they are a root shell on your VPN concentrator with no credential and no user interaction.
Here is how it actually ran, and it is worth slowing down for because every step is a system trusting the wrong thing:
An unauthenticated request hits the appliance's wsproxy endpoint carrying a "SMA Connect Agent" user-agent and a crafted parameter. That is the SSRF. It lets the attacker open a WebSocket tunnel from the outside to services that were only ever supposed to be reachable from the appliance to itself — localhost-only services. One of those services is a CouchDB instance listening on an internal port. The attacker, now tunneled in as if they were the appliance talking to itself, logs into that CouchDB with the default credentials admin:admin. From CouchDB they read the appliance's product_uuid. That UUID is the seed for the password to the SMA control service. They derive it, authenticate to the management service, and reach the sysCtrl.execRemoveHotfix RPC method — a function meant to remove a patch — which has a command-injection flaw. Through that they run commands as root.
Read that again as a trust story. The appliance trusted that anything reaching its localhost services was itself. The database trusted the default password nobody changed. The control service trusted that anyone who knew the UUID-derived secret was authorized. The hotfix-removal function trusted its own input. Four assumptions, each reasonable in isolation, welded end to end into unauthenticated root. This is what edge-appliance compromise looks like in 2026: not one dramatic buffer overflow, but a polite relay of small trusts, each door held open for the next.
What they left behind — and where to actually look
Once root, UTA0533 dropped a package Volexity named KNUCKLEBALL, which carried two agents: a build of the open-source suo5 tunneling proxy, staged as agent_wp8.jar, and a webshell Volexity calls ORANGETAIL, staged as agent_wp9.jar. They rewrote the appliance's NGINX Unit configuration to route two innocuous-looking URIs — the login and logout paths under an internal API — to those agents, so the webshell answered on paths that look like normal appliance plumbing. They planted a setuid binary at /usr/bin/xzfind, named rootrun internally, so an unprivileged user could become root on demand. Then they ran tcpdump to capture LDAP credentials in transit and started reaching into the customer network.
The operational point for a defender is this: the indicator that matters here is not an IP address. Volexity documented the attackers connecting through ExpressVPN and Mullvad exit nodes, which means blocking their source addresses buys you almost nothing and risks collateral on shared VPN egress. The real hunt is host-side, on the appliance itself. Look for a setuid binary at /usr/bin/xzfind. Look for agent_wp8.jar and agent_wp9.jar in /tmp. Look at whether /var/lib/unit/conf.json has routes you did not add. Look for a base64 blob at /tmp/hypdate.b64. These are things you check by getting on the box, not by watching a firewall log.
The receipt we can hand you
The four malware file hashes from this campaign — rootrun, KNUCKLEBALL, suo5, and ORANGETAIL — are in our feed right now, at confidence 80, and they flow through the hashes CSV that a SIEM or EDR can ingest. We want to be exact about the provenance: those hashes are in our index because our vendor-blog pipeline pulled them from Volexity's report on July 17, and the feed record says so — the source field reads vendor-blog/volexity, and the description cites their post by name. We did not observe this campaign on our own sensors, and dressing Volexity's indicators up as a DugganUSA catch would be the exact dishonesty we spend most of our time refusing to commit. Volexity found this. We are a distribution layer for their finding, and a place you can pull it in a format your tooling already speaks.
What we did not do is add their source IPs to our blocklist. They are in the index at confidence 75, below the threshold that flows to the edge-shield, and that is deliberate rather than an oversight: VPN-exit source addresses from a targeted espionage operation are the wrong thing to auto-block. The hashes are the durable, safe-to-hunt artifact. The IPs are a footnote about which VPN the operator paid for that week.
Why we keep writing about the boxes at the edge
This is the same story as Akira breaking in through SonicWall CVE-2024-40766, the same story as the Cisco ASA pre-auth chain, the same story as seven Cisco SD-WAN zero-days in thirteen months. The appliance at the perimeter is no longer a wall — it is a computer, running services, holding credentials, with a management plane that reaches into everything behind it. When it falls, the attacker does not get a foothold, they get the map and the keys at once. UTA0533 sat inside these appliances as a zero-day for roughly three weeks before anyone disclosed the bugs. Three weeks is not a patch window. Three weeks is a tenancy.
The action is the boring one and it is the only one that matters. If you run a SonicWall SMA1000, apply the July 14 firmware, and then treat the box as presumed-compromised for the June-to-July window rather than presumed-clean — because the exploitation predates the disclosure, and a patch closes the door without evicting anyone already inside. Get on the appliance and look for the artifacts above. Rotate the LDAP and service credentials that appliance could see, because tcpdump on the box means they may already have them.
We hold this at 95 percent, as always. The vulnerabilities, the timeline, the attack chain, and every indicator here are Volexity's disclosure and SonicWall's advisory, corroborated by the trade press — not our capture. The read is ours and it is simple: the way in was a default password behind a wall that trusted itself, the way to find them is on the box and not in the firewall log, and the four hashes that let you hunt are waiting in our feed with Volexity's name on them.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments