Two days. That's all it took. SonicWall disclosed CVE-2026-15409 on July 14, 2026. By July 16, someone was already scanning for vulnerable appliances at scale. By July 17, they were inside real networks pulling Active Directory credentials.

Hunt.io caught the whole thing. Not because they were watching the victims. Because the attacker left their own working directory open on the internet.

Let me walk through what happened.

Quick Summary

What Is CVE-2026-15409?

It's a server-side request forgery flaw in the SonicWall SMA1000 WorkPlace interface. SonicWall gave it a CVSS score of 10. They also said it was being actively exploited.

The short version: the WebSocket proxy on the appliance can be tricked into reaching services bound to the local interface. One of those services is an Erlang distribution node on port 1050. It's not supposed to be reachable from the internet. But the SSRF lets you tunnel to it.

Once you're talking to the Erlang node, you can authenticate using a shared cookie and send RPC requests. The command runs as the couchdb user. That's your foothold.

How Fast Did This Move?

SonicWall disclosed on July 14. Rapid7 published a proof-of-concept on July 15. The attacker refactored it on July 16.

The modified script kept the exploitation core from Rapid7's PoC. It even credits Ryan Emmons and Rapid7 in the header. But the interface was changed for bulk, unattended use. Multithreaded. Repeated runs. No human in the loop.

At 07:40 on July 16, the scanner tested 2,197 target entries using 50 concurrent threads. The output recorded 163 successful checks. After removing duplicates, that was 112 unique endpoints.

The Council That Got Hit

On July 17, the Borough Council of King's Lynn and West Norfolk detected a cyberattack. The BBC reported it. Hunt.io assesses with moderate confidence that this incident is linked to the same campaign.

The timing lines up. Scanning started July 16. Active exploitation happened July 17. The attacker's open directory was cloned that same day.

The Toolchain

Once the attacker had command execution on an appliance, they followed a structured workflow.

Step 1: Extract LDAP configuration

They ran a script that read /usr/local/extranet/etc/policy_file.xml. That file holds LDAP bind settings. Of the 250 targets processed, 168 had LDAP configurations.

Collectively, those 168 appliances exposed 534 configuration records. That covered 160 unique Active Directory domain names and 255 internal LDAP server addresses.

The passwords in that file were encrypted. The attacker had a script to decrypt them in bulk. The AES key was static and stored in a Java class file.

Step 2: Drop secretsdump on the appliance

Here's where it gets interesting. The attacker didn't just use the LDAP credentials directly. They downloaded a standalone Linux build of Impacket's secretsdump to /tmp/secretsdump on the SonicWall appliance itself.

Then they ran it from the appliance. Using the decrypted LDAP credentials, they authenticated to internal Windows systems and dumped SAM and LSA secrets.

This is clever for two reasons. First, it's scalable. Second, it's evasive. Most organizations have way less visibility into the underlying OS of a firewall or VPN appliance than they do on managed Windows and Linux hosts with EDR.

Step 3: Test for DCSync privileges

Not every LDAP account can replicate the directory. Most are just service accounts with read access.

So the attacker tested. They tried requesting the built-in Administrator account through the Directory Replication Service. If the output contained Administrator:500:, they knew they had replication rights.

Step 4: Use machine account hashes

This is the part that really worked. When secretsdump pulled LSA secrets from a domain controller, it exposed the machine account's NTLM hash. Things like DOMAIN\DC01$.

Domain controller machine accounts have replication privileges as part of their normal role. So if you have that hash, you can authenticate as the domain controller and request directory secrets.

The attacker automated this. They parsed their earlier dump files, found account names ending in $, extracted the NTLM hashes, and used pass-the-hash to run DCSync.

The Numbers

Here's the funnel. It started broad and got narrow.

Confirmed credential theft hit environments in France, India, Italy, and the United States. The wider target list included named gateways in the UK, Canada, Germany, Sweden, Poland, Hungary, South Korea, and Hong Kong.

Sectors? Local government, law enforcement, healthcare, finance, universities, manufacturing, managed IT. It wasn't a targeted vertical campaign. The attacker picked targets because they had a vulnerable appliance. That's it.

Who Did It?

Hunt.io didn't attribute the campaign to any named group or country. Several scripts had extensive Chinese comments and logging. But that wasn't enough to make a call.

What Defenders Should Do

1. Patch or disable SSL-VPN

SonicWall disclosed this on July 14. If you haven't patched, do it. If you can't patch immediately, turn off SSL-VPN. SonicWall says turning off web mode alone isn't a valid workaround.

2. Look for secretsdump on your appliances

Check for /tmp/secretsdump. Check for outbound connections to 95.181.173[.]36. Check for unusual LDAP queries from your appliance.

3. Rotate everything

LDAP bind passwords. Domain controller machine account passwords. Any credential that could have been in policy_file.xml. Patching doesn't undo what was already stolen.

4. Check for DCSync activity

Look at your domain controllers. Are there replication requests you don't recognize? Look for DRSUAPI traffic from unexpected sources.

5. Watch your edge devices more closely

The whole reason this worked is that appliances are blind spots. You can't put EDR on a SonicWall. But you can monitor what it's doing on the network. Log outbound connections. Alert on unusual LDAP or SMB traffic originating from the appliance.

6. Preserve evidence

If you think you were hit, don't clean up yet. The attacker's scripts wrote output to /tmp on the appliance. That's evidence. Grab it before it's gone.

Indicators of Compromise

• IP address: 95.181.173[.]36 - hosted the exploitation directory and served the secretsdump payload.
• Payload URL: http://95.181.173[.]36:80/secretsdump
• File: /tmp/secretsdump — 9,983,640 bytes
• SHA-256: 690f5031deede7d3357d0ca24c89866ae8c60e6c63b3a2c8bba813a6ac10ae5b
• Erlang node: couchdb@127.0.0.1 on port 1050

The Bottom Line

SonicWall SMA1000 appliances got hit hard. CVE-2026-15409 was exploited within two days of disclosure. The attacker used modified Rapid7 tooling, dropped Impacket onto the appliances themselves, and pulled Active Directory credentials from at least nine domains. Five domains got fully DCSync'd.

The whole campaign was sitting in an open directory. Hunt.io captured it while the operator was still using it.

Quick Reference:

What to Do:

• Patch or disable SSL-VPN
• Look for secretsdump on appliances
• Rotate all credentials
• Check for DCSync activity
• Monitor edge device traffic
• Preserve evidence before cleanup

FAQ Section

What is CVE-2026-15409?

An unauthenticated server-side request forgery flaw in the SonicWall SMA1000 WorkPlace interface. It allows command execution on the appliance.

How was it exploited?

Attackers used a modified Rapid7 PoC to tunnel to an Erlang distribution node on port 1050 and execute commands as the couchdb user.

What did the attackers steal?

LDAP configurations, SAM and LSA secrets, and domain controller machine account hashes. Full replication was done on five different Active Directory domains using DCSync.

Which Council was attacked?

The Borough Council of King’s Lynn and West Norfolk reported the attack on July 17, 2026. Hunt.io evaluates this as being moderately associated with this campaign.

How was the campaign discovered?

Hunt.io found the attacker's open directory on 95.181.173[.]36 using their AttackCapture capability.

What should I do if I run SonicWall SMA1000?

Patch immediately. If you can't, disable SSL-VPN. Check for secretsdump on your appliances. Rotate all credentials. Look for DCSync activity.

Source: Hunt.io