14,530 Dahua cameras in 35 days, and the only exotic tool was masscan

A single operator compromised more than 14,000 internet-exposed Dahua IP cameras between 17 June and 22 July 2026, according to Hunt.io, whose AttackCapture crawler recovered the operator's entire working environment, 2,616 files across 234 subdirectories and 407 MB, from an open HTTP directory the operator had exposed themselves ^[1][2]. None of the tradecraft was exotic: masscan sweeps for discovery, a toolkit credited to at least six upstream developers, and an estate that answered ^[5][12].

The totals carry the finding. Hunt.io counts 14,530 or more devices compromised in 35 days, of which the brute-force engine alone reached 12,324 unique addresses ^[3][4], roughly 85 percent of the haul ^[2] and about 415 devices a day ^[1]. Scanning ran against Russian address space first, then the full IPv4 range, and the largest single haul landed in Mexican and Vietnamese ISP ranges before the operator's focus settled on Russian and CIS telecom netblocks ^[5]. Confirmed, geolocated compromises concentrated in Ukraine and Russia, with Ukraine holding the largest share ^[6]. Three exploitation paths ran in parallel ^[20].

The part that outlives the incident is the backdoor. Hunt.io found 1,923 cameras carrying a persistent account, p2pwn / p2password, installed over RPC after either bypass ^[7]. It is stored independently of the admin password, survives a password change, and on most firmware survives a factory reset ^[8]. That moves remediation from credential rotation to firmware replacement, and it means an operator who rotated passwords in July may still be hosting a tenant.

A smaller set is more interesting architecturally. Hunt.io says 283 cameras were reached by serial number alone through Dahua's cloud relay, with no device address and in most cases no credentials, and that the operator's own code records 89.4 percent of live serials as requiring no authentication ^[9][10]. Offline recovery codes grant cloud-level administrative access by serial number, independently of device credentials, which Hunt.io calls the strongest indicator the toolkit was built to hand access to a third party ^[11]. Perimeter firewalling does not help against access brokered through the vendor's own relay.

Two CVE labels in the tooling do not survive inspection, per Hunt.io. CVE-2024-39943, the identifier p2pwn attaches to its persistence technique, belongs to an unrelated command-injection flaw in Rejetto HTTP File Server; the technique is verified from source, the label is wrong, and Hunt.io could not determine whether a correct identifier exists ^[13]. CVE-2025-31702, inherited from the upstream proof-of-concept behind the relay component, is described in Dahua's advisory as a post-authentication privilege escalation, CWE-732, CVSS 6.8, not in CISA KEV, which is not the unauthenticated relay abuse observed ^[14]. Anyone triaging by CVE score here will underrate the exposure.

Also staged on the same host: a UPX-packed Windows binary classified as SalatStealer with a five-method Defender bypass script ^[15]. Hunt.io flagged the host, 154.86.119.60, on TCP/37777, Dahua's Easy4IP management protocol, and traced the whole exposure to one command left in shell history, run twice from /root: a Python http.server bound to 0.0.0.0 on port 80 ^[16][17]. The operator's opsec failure was the same class of mistake as their victims'.

This is the second Dahua camera operation Hunt.io has traced to an exposed operator directory in two weeks; the previous one covered 58 cameras ^[18], roughly 250 times smaller ^[3].

Watch whether a correct identifier is assigned for the p2pwn persistence technique, since without one it will not appear in patch or KEV workflows ^[13][14]. Watch for reuse of the recovery-code path by a second party, which is what transferable access is for ^[11]. National CERTs were notified on 10 August 2026 and publication was held to 18 August under TLP:AMBER, so remediation timelines in Ukraine and Russia start there ^[19].