A Dahua IP camera hack labelled CameraSwarm by researchers at Hunt.io compromised more than 14,500 cameras across at least 35 days, running from 17 June to 22 July, targeting devices primarily in Ukraine and Russia through three distinct attack methods operating simultaneously. The scale is uncomfortable: 14,530 cameras in total, and the operator left enough evidence lying around for researchers to reconstruct the entire operation in detail.
Hunt.io discovered the campaign after finding a working directory on an HTTP server that the operator had left unprotected. From it, researchers recovered 407 MB of data spanning 2,616 files across 234 directories. The haul included source code, logs, credentials, captured camera images, shell history, and exploitation results, essentially a full audit trail of the operation, handed over by accident.
Three attack methods behind the Dahua IP camera hack
The CameraSwarm toolkit ran three parallel approaches. The most prolific was a brute-forcing system that scanned TCP port 37777 and compromised cameras at 12,324 unique IP addresses. That component captured usable camera snapshots, forwarded results to Telegram, and exported data formatted for Dahua’s SMART PSS platform, suggesting the operator wanted the footage organised and readily browsable, not just harvested in bulk.
The second method exploited two known CVE vulnerabilities (CVE-2021-33044 and CVE-2021-33045) using a tool called p2pwn. That tool installed a persistent backdoor account (username: p2pwn, password: p2password) on 1,923 cameras. The account is engineered to survive password changes and, on most firmware versions, factory resets. Wiping the device does not necessarily clean the infection.
Third was a cloud-relay attack targeting cameras sitting behind NAT, reachable only through Dahua’s cloud infrastructure. Using serial numbers and SDK credentials embedded in Dahua applications, the toolkit reached 283 cameras. Hunt.io’s analysis found that 89.4% of live serials exposed an access channel with no authentication required.
Layered on top of all three was a recovery-code mechanism. The toolkit derives new codes from a camera’s serial number alone, allowing the operator to reset credentials through Dahua’s standard password-recovery process without ever knowing the current admin password. Critically, Hunt.io warns that removing the backdoor account does not invalidate codes already generated, they remain usable until Dahua changes the derivation logic server-side.
Scanning scope, attribution clues, and what owners should do now
The scanning was global in reach, beginning with Russian address space before sweeping the full IPv4 range. Hunt.io noted that “the operator’s focus settled on Russian and CIS telecom netblocks.” Russian-language comments were also found in modified code inserted into repurposed public tools, a detail that points toward a Russian-speaking operator, though the researchers stop short of a firm attribution.
The toolkit also referenced two CVEs (CVE-2024-39943 and CVE-2025-31702) that Hunt.io found were not actually exploited in the observed attacks. Their presence in the toolkit appears to be misleading, possibly to confuse analysts or inflate the apparent capability of the operation.
Hunt.io notified national CERTs and Dahua’s PSIRT about CameraSwarm on 10 August. The remediation guidance is specific: any Dahua camera reachable on port 37777 between June and July should be treated as potentially compromised. Owners should check for the presence of a ‘p2pwn’ account and remove it, though that step alone is not sufficient given the persistence of recovery codes. Disabling P2P when it is not needed removes one attack surface entirely. Applying the Dahua SA-2021-0130 firmware update (which addresses CVE-2021-33044 and CVE-2021-33045) or any later firmware version, closes the vulnerability that allowed the persistent backdoor to be installed in the first place.
The operation is a useful illustration of how layered a relatively modest-seeming campaign can be. Brute force, known CVEs, and cloud-relay abuse were running concurrently, each feeding results back into a single organised archive. The operator’s operational security failure (leaving that directory exposed) is the only reason the full picture is visible now.
