On 23 July, at 11:45 UTC, a server in Hong Kong was answering ordinary web requests on port 80 with a directory listing. Behind it sat 407 MB of files: 2,616 of them, across 234 subdirectories. Scanner logs. A compiled Go binary. Shell history. Snapshots pulled off strangers' security cameras. The person who owned that server had, at some point, typed one line into a terminal and left it running: cd /root && sudo python3 -m http.server 80 --bind 0.0.0.0.
That is Python's built-in file server, pointed at the account's home directory and bound to every network interface. It published the whole operation.
Researchers at Hunt.io found it, and spent the next three weeks reading. What they reconstructed, and named Operation CameraSwarm, is a 35 day campaign that compromised more than 14,530 Dahua surveillance cameras between 17 June and 22 July 2026. The confirmed, geolocated victims cluster in Ukraine and Russia, with Ukraine holding the largest share. The team notified national CERTs and Dahua's product security team under TLP:AMBER on 10 August, and published on 18 August.
Three doors into the same camera
The interesting part is not that cameras got hacked. It is that the operator kept three completely different ways in, and the logs record exactly how much each one was worth.
The three access paths recorded in the operator's own logs. Diagram by IntelFusions.
The bulk of it was unglamorous. An asyncio brute-force engine hammered port 37777, the port Dahua's Easy4IP protocol listens on, scaling up to 4,000 parallel workers and working through a default list that starts with admin:admin and 888888:888888. That accounted for 12,324 unique addresses. The operator even wrote a filter that scored the resulting camera snapshots on brightness and edge density, to throw away the views that showed nothing worth looking at.
The second door needed no password at all, and it is the one that should worry anyone running this hardware.
A serial number is a password
The third door is the one with real engineering behind it. Dahua cameras support a peer-to-peer feature so owners can reach a camera sitting behind a home or office router without configuring anything. The operator worked out that the relay authenticates the session token the cloud issues, not the party doing the connecting. Supply a valid serial number and the relay will build a path to that device, wherever it is.
Hunt.io measured the consequence: 89.4 percent of live serial numbers required no authentication at all. The SDK credentials that unlock the first layer of encryption are hardcoded and identical across every client. One frame type in the tunnel protocol, 0x11, instructs the camera to open a connection to 127.0.0.1, itself, on a port of the attacker's choosing and hand back whatever comes out. The operator also generated offline recovery codes that grant cloud-level administrative access from a serial number alone.
Only 283 cameras were taken this way, which reads like a footnote until you notice what it means. This path does not care about your firewall. There is no address to block, because the device volunteers the connection outward. The operator had harvested serial numbers by enumerating Dahua's own dynamic DNS domains and querying Shodan, and had 13 specific serial prefixes on a target list.
CISA set a deadline for these bugs in 2024
The 1,923 cameras taken through door two fell to a pair of authentication bypasses: CVE-2021-33044, which trusts any client that announces itself as a NetKeyboard device, and CVE-2021-33045, which accepts a spoofed loopback source address. Neither needs credentials. Hunt.io notes both are exploitable in under a second. Once in, the operator used the camera's own RPC interface to add an account, p2pwn, with the password p2password, which survives a password change and, on most firmware, a factory reset.
Here is what our own records add. Both flaws were published on 15 September 2021 and both carry a CVSS score of 9.8. CISA's Known Exploited Vulnerabilities catalog lists them, added on 21 August 2024 with a federal remediation deadline of 11 September 2024. Their EPSS scores, which estimate the probability a flaw will be exploited in the wild, sit at 0.99871 and 0.99556, effectively the ceiling of that scale.
So this campaign ran roughly twenty-one months after the deadline by which US federal agencies were required to have fixed these exact bugs, against firmware that was nearly five years behind a published patch, using flaws the exploit-prediction models had already flagged at the top of the range. Nothing about the second door was a surprise to anyone who was reading. It simply kept working.
The toolkit was assembled, not authored
The directory undercuts the usual picture of a lone genius. Hunt.io's assessment is blunt: the toolkit is assembled, not authored, with components traceable to at least six upstream developers whose handles appear in the code. The bypass binary came from one public project, the async scanner framework from another, the fingerprinting scanner from a third. What the operator contributed was glue: a Telegram bot to push captured credentials out, an export script that batches results into XML for Dahua's own SMART PSS enterprise console, and a pipeline runner with the target quota hardcoded at five hits and twenty rounds.
The housekeeping tells its own story. Shell history shows masscan being driven at ten million packets per second. A PowerShell script in the same directory sets five independent Defender exclusions. One script carries a warning to whoever runs it next: use a rented server, never the local machine. That is somebody who understood operational security well enough to write it down, and then served their home directory to the internet anyway.
What it was being built toward
Hunt.io stops short of naming anyone, and is careful about motive. Its assessment, held at moderate confidence, is that the toolkit was built to hand access to a third party rather than to be used directly. The reasoning is structural: the recovery codes are transferable and work without the operator present, the export pipeline emits files in an enterprise format capped at 255 devices to match the vendor's own import limit, and the credential pipeline pushes to Telegram with a community link hardcoded into the notifications.
The report is equally clear about what that does not establish. In its own words, that reading is narrower than a confirmed commercial operation, which the evidence does not support. Russian-language comments in the code and infrastructure running since April 2025 tell you something about who built it and how long they have been at it. They do not tell you who was buying, or whether anyone was.
Delete any p2pwn account, then turn off P2P
If you run Dahua cameras, the checks are specific. Audit local accounts and remove any named p2pwn, then treat every credential on the device as exfiltrated and rotate it. Disable the peer-to-peer feature under Settings, then Network, unless you actively use it, because serial-based access ignores IP blocking entirely. Apply the vendor firmware that fixes the 2021 bypasses; Dahua states that once firmware is updated, attackers can no longer generate valid recovery codes. For detection, watch authentication logs for a loginType of NetKeyboard or Loopback, and for any login carrying the source address 127.0.0.1.
A handful of indicators, defanged: the operator's exposed host was 154[.]86[.]119[.]60, with a second sighting of an infostealer binary at 185[.]132[.]53[.]56. Legitimate Dahua infrastructure at easy4ipcloud[.]com was abused as the relay, and the vendor's dynamic DNS domains were used for enumeration rather than compromise, so their presence in logs is not by itself evidence of anything.
The cameras in this campaign were not chosen for what they film. They were chosen because they answer on a known port, ship with a short list of predictable passwords, and, if all else fails, will phone out to a cloud relay on the strength of a serial number. Every one of those is a convenience feature. This is the second story this week about ordinary hardware being conscripted by the software that was supposed to look after it, after the car head units turned into proxy bots by their own updater, and it will not be the last. The 14,530 figure is not the count of vulnerable Dahua cameras on the internet. It is the count that one person, working alone for 35 days, got around to.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.