CERT-UA identified concrete evidence that defenders can look for on a Dahua camera or recorder: unknown accounts, unauthorized configuration changes and authentication events over the DVRIP protocol from 127.0.0.1. Those indicators do not cover every takeover method, but they give an incident-response team a starting point that is more specific than a product alert.

The agency reported cases in which attackers viewed video, changed settings and created third-party accounts. It linked the activity to Easy4IP, predictable serial numbers, weak or default passwords and authentication bypasses in older firmware. Hunt.io separately described a persistent p2pwn account that survived password changes and, on most tested firmware, factory resets. That finding matters during containment because changing the administrator password may not remove unauthorized access.

ZoomEye helps scope the response. On 2026-11-13, app="Dahua" returned 13,808,276 all-scope observations and the combination with port="37777" returned 2,398,637. These numbers identify candidate devices for ownership review. They do not identify which devices are involved in the incident. The response team still needs the organization's inventory, Easy4IP registration records and device logs.

Begin by defining the review population. Include all owned Dahua cameras and recorders, devices supplied by contractors, systems acquired through third parties and any public Dahua observations that cannot be linked to an owner. For each asset, collect the serial, model, firmware, site, network path, Easy4IP setting and current local accounts. Record the business purpose of remote viewing. A camera that supports safety or physical security may need to remain available, so containment has to preserve an approved operating path where possible.

Preserve volatile evidence before cleanup. Export audit logs, account lists, configuration backups, network flow records and cloud-registration history. Compare account creation and login times with approved maintenance. Investigate DVRIP sessions from 127.0.0.1 when no local process explains them. Check for changes to video settings, recording rules, network configuration and user permissions. If logs are incomplete, record the gap rather than treating it as a clean result.

Contain suspected devices by restricting management access and isolating them from unrelated networks. Reset credentials, remove unknown accounts and update to supported firmware. Review the cloud registration separately from the device account state. A factory reset may be necessary, but it can destroy evidence and should follow a documented decision. After recovery, verify that the persistent account and configuration changes are gone, that Easy4IP matches the approved design and that the device is no longer reachable by an unapproved path.

Recovery is not complete when a scanner no longer sees a port. The team should verify the device from the management interface, the network and the cloud account. Re-run an approved internal check for unauthorized users and settings. Confirm that monitoring can see future DVRIP and relay activity. Finally, update the asset inventory with the serial, owner and remote-access decision so the next review does not repeat the same blind spot.

References