SURIQ
A fleet of internet-facing cameras is an operating system nobody on the security team owns, patches, or watches. Operation CameraSwarm is what that blind spot costs. Between June 17 and July 22, 2026, one operator took control of more than 14,530 Dahua cameras in 35 days, and the flaws that opened the door were fixed back in 2021. The age of the bugs is not the story. How the cameras were reached is: for hundreds of them, the attacker never had to get past a firewall at all, because the vendor's own cloud service reached around it.
The campaign is public only because the operator made a mistake. Researchers at Hunt.io found a 407 MB working directory sitting on an unprotected web server, with 2,616 files of tooling, logs, and captured images. They reconstructed the whole operation from it and disclosed the findings to national CERTs and Dahua's product security team on August 10, before publishing on August 19. Most confirmed targets were in Ukraine and Russia, though the scanning eventually swept the entire public address space.
Three paths into the same fleet
CameraSwarm did not rely on one trick. It ran three access methods in parallel, and each one tells a different story about how exposed camera fleets really are.
| Access path | How it worked | Reach |
|---|---|---|
| Credential brute force | Password guessing against Dahua's proprietary control port, TCP 37777 | 12,324 unique IPs |
| Auth-bypass exploit | CVE-2021-33044 and CVE-2021-33045, followed by a planted p2pwn backdoor account | 1,923 cameras |
| Cloud relay | A serial number plus an embedded SDK key reached cameras sitting behind NAT | 283 cameras |
The brute-force path was the widest: 12,324 unique addresses hammered on TCP port 37777, the port Dahua's SDK and management tools speak on. Once in, the attacker pulled snapshots into Dahua's own SMART PSS management software and relayed results out through Telegram. The exploit path used the two 2021 flaws, CVE-2021-33044 and CVE-2021-33045, both authentication bypasses that let a crafted packet skip device login. Dahua rated them around 8.1; the National Vulnerability Database scores them as high as 9.8. On the 1,923 cameras taken this way, the tooling installed a local account named p2pwn.
NAT did not protect the cameras behind it
The 283 cameras reached through the cloud relay are the part every self-hosting operator should sit with. These devices were behind NAT. There was no port forward to brute force, no public 37777 to reach. The attacker used Dahua's peer-to-peer service, the same Easy4IP convenience feature that lets you view a camera from a phone without configuring your router. Per Hunt.io's reconstruction, with only a camera's serial number and an SDK credential embedded in Dahua's applications, the relay established a route to the device before the camera's web application ever checked a login. Hunt.io reported that 89.4% of live serials it tested exposed an access channel without authentication.
That is the uncomfortable lesson. Your perimeter did not fail. The vendor's cloud reached past it. Any device class that phones home to a manufacturer rendezvous service, cameras, doorbells, industrial gateways, inherits an access path that your firewall cannot see and your NAT cannot block. We have written before about how quickly exposed devices get swept into IoT botnets and even AI-assembled botnets; CameraSwarm shows the same exposure without a single open port on your side.
Why a factory reset will not evict this backdoor
Most incident response for a compromised appliance follows a reflex: change the password, wipe it, reset to factory defaults, move on. Hunt.io's findings break that reflex. A password change does not clear the p2pwn account it documented, and on most firmware builds neither does a factory reset. Worse, removing the account does not invalidate recovery codes the attacker already generated against the camera's serial number. Those codes keep working.
So the serial number is not a harmless identifier here. It is the seed for an access path, and once an operator has captured it and minted recovery codes, the device stays reachable through the vendor's own recovery mechanism regardless of what you do locally. For these cameras, the honest remediation is firmware first, then treating the serial as a leaked secret: rotate every credential the vendor ties to it, and where the device cannot be brought to patched firmware, replace it rather than trust a reset.
The cameras nobody patched
CVE-2021-33044 and CVE-2021-33045 have had fixes for roughly five years. Fourteen thousand cameras fell to them in a little over a month. That gap is the pattern worth naming: patch programs cover servers and workstations, and they routinely skip the camera, the network video recorder, the badge reader, and the gateway. Those devices run software, sit on the internet, and almost never enter the inventory that drives patching. An attacker who scans for a five-year-old bug is betting that the fixed version was never applied, and on this asset class that bet keeps paying off.
The other half of the story is defensive intelligence hiding in plain sight. This entire campaign was mapped because the operator left a working directory open to the world. Attacker infrastructure leaks the same way defenders' does, and the same exposure scanning that finds your forgotten camera can find an adversary's exposed logs. It is worth building that outward view into how you watch your own edge.
What to watch in your logs
Detection here does not need the exploit. It needs the aftermath. Watch for high-volume authentication failures against TCP 37777 on any camera or recorder subnet, the signature of the brute-force path. Alert on any new local account appearing on a device, with p2pwn as a known name from this campaign but not the only one to expect. Flag camera egress to Telegram's API and to SMART PSS collection endpoints, which is how snapshots left the network. A camera that suddenly talks to a messaging service is not doing its job.
Cameras rarely generate logs anyone reads, which is exactly why this ran for 35 days. Piping device and network telemetry into a managed detection service that flags new accounts and unusual egress turns a silent appliance into something that can page you. The behavior, a new account plus outbound traffic to a chat service, is visible even when the specific flaw is not.
Evict p2pwn, then treat the serial as leaked
If you run Dahua cameras, work the list in order. Bring every device to Dahua's 2021 fix (advisory SA-2021-0130) or later firmware. Audit for a p2pwn account, and any other local account you did not create, and remove it. Disable the peer-to-peer and Easy4IP relay features on any camera that does not truly need remote cloud viewing, since that path bypassed NAT entirely. Put surveillance devices on their own segment with no route to the rest of the network. And treat the serial numbers of any exposed camera as compromised: rotate the vendor credentials tied to them, because a reset alone leaves the recovery codes valid. The bugs are old, but the exposure they created is live right now.