The Dahua break-in that a firewall cannot stop: a cloud relay keyed to serial numbers

Hunt.io reports that a campaign it calls Operation CameraSwarm compromised more than 14,530 Dahua cameras across Ukraine and Russia, running three intrusion paths in parallel ^[1][3]. The third path matters most for anyone who has already done the recommended hygiene: it reached cameras through Dahua's official cloud relay using only a device serial number, so keeping the camera off the public internet did not help ^[11][12][15].

Rank the vectors by how much of the fix sits inside your network. The first is ordinary: mass scanning of TCP/37777 with masscan, a short credential list, and a rule to back off when a device returns a lockout response ^[4]. On success the tooling grabbed a snapshot, discarded dark or blank frames, and shipped useful images and credentials to Telegram ^[5]. Compromised devices were exported as XML for bulk import into SMART PSS, which is a management convenience turned into an inventory of victims ^[6].

The second is patch debt. Unpatched devices got CVE-2021-33044 or CVE-2021-33045, followed by impersonation of a NetKeyboard client or a source IP spoofed to 127.0.0.1 to obtain an administrator session ^[7][8]. From there the attackers created a `p2pwn` account over RPC, which survived an administrator password change and, on some models, a factory reset ^[9]. They also pulled ONVIF credentials and the passwords cameras store for their NVR connections ^[10].

The third is the one that breaks the usual mental model. Serial number candidates were harvested from Shodan and DDNS names, then the relay was entered using common embedded SDK credentials and queried per device by serial ^[11][12]. According to Hunt.io, that opened a channel with no device-side authentication for 89.4 percent of the active serial numbers targeted, meaning roughly one in nine held ^[13][23]. Cloud management rights were then taken with recovery codes generated offline, and those rights could be re-acquired from the cloud side after accounts were deleted, as long as the codes remained valid ^[14].

Nothing in that sequence traverses a port you can close. The relay handles devices behind NAT by design, and relay traffic shares infrastructure with normal `easy4ipcloud.com` operations, so source IP alone will not tell you which session is hostile ^[15][16]. Hunt.io's own mitigation list is split accordingly: not exposing TCP/37777, applying SA-2021-0130 or later, disabling unnecessary P2P, and blocking `clientType=NetKeyboard` and `loginType=Loopback` are local, but fixing the recovery code mechanism is listed as server side ^[17]. Two of three vectors are yours to close. One is the vendor's.

Detection is weak in the same place. The usable signals are unauthorised accounts such as `p2pwn`, external logins claiming to be NetKeyboard or loopback, sudden spikes in recovery code generation and use, relay sessions initiated from serial numbers, and bulk SMART PSS imports on management PCs ^[18]. Cameras typically run no EDR, so unknown tools and credential files on the management terminal may be the first artefact you see ^[18]. Video keeps working throughout, so users have no reason to complain ^[19].

Two caveats from the report. SalatStealer sat on the same attack server as a separate capability with no confirmed link to the camera chain, and CVE-2024-39943 and CVE-2025-31702 appeared in the tooling but are not treated as entry vectors, one being for a different product and the other post-authentication ^[20][21]. No email was used anywhere in the chain ^[22].

Watch whether Dahua changes recovery code generation and relay-side device authentication, because that is the only place the third vector closes ^[17]. Then check whether your other P2P-enabled fleets, cameras or otherwise, have the same property: an identifier that is guessable, and a vendor channel that treats it as proof.