You Changed the Camera Password. The Attacker Account Was Still There.
CameraSwarm compromised more than 14,500 Dahua devices in 35 days. On 1,923 cameras the operator created a separate account that can survive an administrator password change and, on most affected firmware, a factory reset. Familiar recovery steps may leave the attacker in place.
An exposed operator directory revealed the campaign
Hunt.io reconstructed Operation CameraSwarm after an operator exposed a working directory over HTTP. Researchers recovered 2,616 files across 234 subdirectories and correlated the material with additional telemetry.
The corpus describes at least 14,530 compromised devices between 17 June and 22 July 2026. One credential-brute-force engine reached 12,324 unique addresses. A separate authentication-bypass chain compromised 1,923 cameras, while a cloud-relay path reached 283 devices without requiring a routable device address.
The confirmed and geolocated compromises concentrated in Ukraine and Russia, although the scanning was broader and early results included devices in other countries. Hunt.io does not identify a confirmed operator or final purpose for the access.
The attacker account was separate from the administrator password
The toolkit used CVE-2021-33044 and CVE-2021-33045 to obtain administrator sessions on unpatched cameras without valid credentials. The first bypass abuses trust in clients claiming to be NetKeyboard controllers. The second makes the device trust a loopback address supplied in the request rather than the source of the network connection.
After either bypass, the tool created the account p2pwn with the password p2password. Hunt.io says that account is stored independently of the normal administrator password. Changing the expected credential therefore does not remove the hidden account. On most affected firmware, even a factory reset does not remove it.
This changes the recovery question. A successful password rotation is not evidence that the camera is trustworthy. Responders have to enumerate accounts, remove the attacker-created identity, update firmware and verify the device’s configuration after remediation.
NAT did not make the cameras unreachable
The relay component reached cameras behind NAT using serial numbers through Dahua’s cloud service. The operator’s own code recorded that 89.4 percent of live serials opened a channel without device-level authentication.
That finding undermines a common deployment assumption. A camera without an internet-routable address can still be reachable through a vendor relay. Address-based scanning and perimeter blocking will not reveal every path when the management plane uses a cloud service to traverse NAT.
The operator’s CVE labels were not all reliable
Hunt.io found two incorrect labels in the recovered tooling. The persistent-account technique was tagged as CVE-2024-39943, but that identifier belongs to an unrelated Rejetto HTTP File Server issue. The technique was real, but the identifier was wrong.
The relay code also referenced CVE-2025-31702. Dahua’s advisory describes that issue as a narrower, post-authentication weakness requiring valid credentials. It is not the unauthenticated relay behaviour reconstructed in CameraSwarm.
Defenders should not copy vulnerability labels from attacker tools into incident records without checking them. A wrong identifier can send remediation towards the wrong vendor, product or control.
Recovery requires more than a password change
Hunt.io recommends that organisations:
- Audit Dahua account lists and remove any unexpected
p2pwnidentity. - Treat cameras reachable on TCP port 37777 during the June and July campaign window as possible compromise candidates.
- Apply Dahua SA-2021-0130 and current firmware updates.
- Remove port 37777 from internet exposure and disable P2P where it is not required.
- Assume credentials stored on an affected camera may have been collected and rotate them.
- Monitor for login requests using
NetKeyboardor a loopback login claiming127.0.0.1. - Verify that recovery codes and vendor-cloud access are invalidated through the current firmware process.
Dahua told Hunt.io that current firmware blocks generation of new recovery codes and causes previously issued codes to be refreshed and invalidated over time. Removing the backdoor account alone does not address that separate access path.
A reset is a procedure, not proof of recovery
CameraSwarm is operationally important because it defeats reasonable-looking remediation. A changed password and completed factory reset can produce a clean status screen while a separate account or cloud recovery path remains valid.
Recovery assurance has to inspect every management plane: local accounts, firmware, stored credentials, vendor relays and recovery mechanisms. The defender’s task is not to complete the reset. It is to prove that the attacker no longer has a path back.
