On August 18, threat-intelligence firm Hunt.io published Operation CameraSwarm, an account of a campaign it says compromised more than 14,530 Dahua cameras and recorders between June 17 and July 22, 2026. The research was reconstructed from a 407 MB working directory the operator left exposed on a web server — 2,616 files across 234 subdirectories of tooling, logs, shell history and campaign records. The Hacker News covered it the following day, and BleepingComputer and SecurityWeek picked it up the same week. Confirmed compromises were concentrated in Ukraine and Russia.
Most of the campaign is the ordinary story with an ordinary fix: internet-facing devices on port 37777, credential brute-forcing, and two authentication-bypass flaws from 2021 — CVE-2021-33044 and CVE-2021-33045 — that Dahua patched years ago and that still sit in CISA's Known Exploited Vulnerabilities catalogue. Roughly 12,300 unique addresses were reached that way.
The number worth reading twice is the smallest one in the report. 283 cameras were reached without an address at all.
The serial number was doing the work of a password
Hunt.io describes three attack paths running in parallel, and only two of them involve your network in any way a scanner would notice. The third goes through the vendor's own cloud.
Dahua's P2P feature, Easy4IP, exists so that a camera behind NAT can be reached without anyone configuring a router. The device registers itself, and the relay finds it later by serial number. Per Hunt.io's writeup, cloud-registered cameras also auto-register a DDNS subdomain in the form {serial}.dahuaddns.com — which means a collection script can harvest serial numbers, in the researchers' words, "without contacting a camera" at all. Twelve Shodan queries and a subdomain list.
The relay then does what it was built to do. ITRES Labs, analyzing an earlier incident response in October 2025, put the mechanism plainly: on firmware before mid-2024, "the relay establishes the route without prior authentication, leaving login checks to the device's web application." Reachability and authorization are two separate steps, and the first one only ever needed the serial.
Hunt.io says the operator's recovered code recorded 89.4% of live serials returning an open channel with no authentication. That figure deserves a caveat the reporting itself supplies: The Hacker News notes it has not been independently reproduced by ITRES Labs, by Dahua, or by any public CERT advisory. Treat it as a campaign-specific claim from recovered attacker material rather than a measured rate across the install base.
The toolkit went further than reaching devices. One script replicated part of Dahua's own account-recovery flow offline — generate candidate serials, test each against the relay, derive a recovery code for every live device. Hunt.io says those codes grant cloud-level administrative access by serial number, independently of whatever password is set on the device, and calls this transferable-access design the strongest indicator that the toolkit was built to hand access to a third party.
Two different reasons "just reset it" doesn't land
There are two separate persistence stories here and they're easy to blur together.
The first is a backdoor account. Hunt.io says 1,923 cameras were given a persistent account installed over RPC after either bypass; because it is stored independently of the admin password, the researchers say it survives a password change and, on most firmware, a factory reset.
The second is the recovery codes, and it's the one that outlives the incident. Dahua states that once firmware is updated, attackers can no longer generate valid codes, and that previously issued codes are periodically refreshed and eventually invalidated. Until that firmware update happens, a code minted weeks ago is still a live credential — one that lives in the vendor's cloud, not on the device, and that no amount of resetting the camera touches.
An inbound path you did not configure
If you set up a port forward, you know it exists. It is a line in your router, you put it there, and you can delete it. It shows up in exactly the place you would look.
A vendor relay is the inverse of that in every respect. Nobody chose it — it is on because being reachable from a phone is the feature people actually buy. Hunt.io notes the cloud path is "invisible to any address-based scanner," and that the relay routes across a pool of backend addresses, so address-based blocking is not a reliable control. There is nothing in your firewall log to notice and nothing at a fixed address to block. The path is a property of the product, and the only place it is visible is a settings screen most owners have never opened.
This is not an argument that cloud is bad. Remote access has to come from somewhere. It's that when you don't build the path yourself, you inherit a design decision you can't inspect — and you find out its terms when somebody else publishes them.
If you own one of these
To their credit, this was handled properly. Hunt.io notified the relevant national CERTs on August 10 and notified Dahua's PSIRT, held publication until August 18 under TLP:AMBER, and credits Dahua PSIRT's engagement in reviewing parts of the research before publication. Dahua's advisory rates the two 2021 bypasses 8.1 on CVSS and lists fixed firmware; NVD scores them 9.8. ITRES Labs says its testing found the P2P relay path was reinforced in firmware released after mid-2024. Fixes exist. The gap is deployment, which is where it usually is.
The concrete steps, from Hunt.io and ITRES Labs:
- Update firmware from the vendor's own download site. This is the step that closes the recovery-code path, not just the CVEs.
- Disable P2P under Settings → Network unless you actively use it. With it on, the device is reachable by serial number alone.
- Assume any recovery code issued before you updated is still live, and treat it as a credential you cannot revoke by resetting the device.
- Rotate credentials and remove unused accounts — including any you don't recognize.
- Segment your video devices onto their own network segment.
Where we sit, and what it costs
I build Background Camera RemoteStream, an Android app that turns a phone into a camera. Recordings are stored on the device. There is no account, no vendor cloud holding your footage, and no relay — mostly because we don't operate one. Nothing about your phone gets registered into a directory keyed to an identifier printed on the back of it, and there is no cloud-side reset flow for anyone to replicate offline, because there is no cloud side.
That is a genuinely different shape, and I want to be straight about the half of it that isn't a win.
We do not solve remote access for you. Viewing on your own network is a small web server on the phone; reaching it from outside is your problem — a VPN back into your own network, or a port forward you configure and own. Easy4IP exists because that problem is real and annoying, and "do it yourself" is a cost, not a feature. We've written the honest version of remote access and what "local-only" does and does not buy you, which closes exactly one ring of the threat model and leaves the others to you.
Our optional YouTube Live streaming path is itself a cloud dependency: the stream goes to Google, on Google's terms, with Google's availability. And no account also means no reset link and nobody to call — the same property as "no cloud-side recovery flow," seen from the side where it costs you something. We made that argument against ourselves the last time a vendor cloud had a bad night.
The lesson from CameraSwarm isn't that one architecture wins. It's narrower and more useful: find out what your camera is reachable by, and whether that thing is a secret. A password is a secret. A serial number printed on a sticker is not, and it was never designed to be.
Background Camera RemoteStream is a free Android app for turning a spare phone into a recording camera — local storage, screen-off recording, no account required. Google Play · superfunicular.com
Top comments (0)