When "Reset the Password" Isn't a Fix: Breaking Down the Dahua Camera Backdoor
If you've ever handled incident response for IoT or embedded devices, you know the instinct: compromise detected → reset credentials → maybe factory-reset for good measure → close the ticket. That workflow just failed against a real-world campaign, and the reason why is worth understanding at the architecture level.
Researchers at Hunt.io uncovered a campaign — Operation CameraSwarm — that compromised over 14,530 internet-exposed Dahua IP cameras across a 35-day window. The discovery itself came from an operator mistake: an exposed HTTP directory containing 2,616 files (407MB) of the attacker's own scanning engines, exploit tooling, and logs.
Three attack paths ran in parallel:
- Credential brute-forcing against Dahua's Easy4IP management protocol on TCP/37777, hitting 12,324 unique IPs with default/weak credential lists.
- Authentication bypass via CVE-2021-33044 and CVE-2021-33045 — two flaws that let an attacker construct malicious packets to skip identity verification entirely, no valid password needed.
- P2P relay abuse, reaching 283 cameras behind NAT purely by querying Dahua's cloud relay with a device serial number — no port forwarding, no public IP required.
Here's the architecture detail that makes this genuinely interesting from a security-engineering standpoint: on 1,923 devices, a tool called p2pwn planted a new administrative account through the camera's RPC-based remote-management interface. Because that account lives in a separate store from the standard admin credentials, a password change never touches it. On most affected firmware, neither does a factory reset — the persistence mechanism sits outside the reset's scope entirely.
The toolkit also included an offline recovery-code generator. Since recovery codes are derived server-side by Dahua rather than validated purely against local device state, deleting the backdoor account doesn't necessarily invalidate codes already generated.
One detail worth flagging for anyone doing CVE-based detection engineering: the toolkit itself mislabels its own techniques, tagging the persistent-account method as CVE-2024-39943 (actually an unrelated Rejetto HFS bug) and the relay abuse as CVE-2025-31702 (a narrower, authenticated Dahua flaw). If your detection rules are keyed to CVE identifiers pulled from threat intel without cross-checking the vendor advisory, this is exactly the kind of mismatch that causes a rule to miss the real behavior.
None of the underlying flaws are novel — this is a patchable-vulnerability story, not a zero-day story. The interesting engineering lesson is about persistence design: any account-management system with credential stores that don't fully unify under a single reset/reflash path creates this exact failure mode, camera or otherwise.
Full writeup with IOCs and a detection/hardening checklist (including nmap and iptables commands for isolating exposed devices):
https://www.xpert4cyber.com/2026/09/dahua-camera-backdoor-survives-reset.html
Top comments (0)