CERT-UA Alert: Dahua IP Camera and DVR Hijacking via P2P Access — Detection and Hardening Guide

The Computer Emergency Response Team of Ukraine (CERT-UA), working with the State Special Communications Service of Ukraine (SSSCIP), has issued an alert on confirmed compromises of Dahua IP cameras and digital video recorders (DVRs). According to the SSSCIP, attackers have been observed gaining unauthorized remote access to video streams, altering device configurations, and — critically — creating third-party accounts on compromised devices to maintain persistence.

This is not a theoretical exposure. Confirmed in-the-wild compromise means any organization running Dahua surveillance infrastructure — especially devices reachable over the internet or enrolled in Dahua's P2P cloud service — should treat this as an active incident-response trigger, not a patching backlog item. In a conflict environment, hijacked surveillance systems are reconnaissance assets: they expose physical security postures, personnel movement, and facility layouts. Even outside Ukraine, the same tradecraft applies to any internet-exposed Dahua fleet.

Technical Analysis

Affected Products

• Dahua IP cameras (network surveillance cameras with internet connectivity)
• Dahua DVRs/NVRs (digital and network video recorders managing camera fleets)
• Devices enrolled in or reachable via Dahua P2P cloud access (serial-number-based remote access brokered through Dahua's P2P infrastructure, typically over UDP)

Attack Chain (Defender's View)

Based on the CERT-UA/SSSCIP reporting, the intrusion chain breaks down as follows:

1. Reachability via P2P or direct exposure. Dahua devices ship with P2P enabled by default. Once a device phones home to Dahua's P2P cloud, it becomes remotely reachable by anyone who knows — or can enumerate — the device serial number, bypassing NAT and perimeter firewalls entirely. Alternatively, devices with web/RTSP/admin interfaces directly exposed to the internet are trivially discoverable via Shodan/Censys-style scanning.
2. Authentication weaknesses. Weak, default, or previously leaked credentials allow attackers to authenticate to the device. P2P access combined with credential weaknesses collapses the two barriers defenders assume they have (network perimeter + authentication) into zero.
3. Post-compromise actions. CERT-UA documents three concrete post-exploitation behaviors:
   • Video stream access — live surveillance feeds viewed or exfiltrated (RTSP/HTTP streams).
   • Configuration changes — device settings modified, potentially including stream destinations, network settings, and recording behavior.
   • Rogue account creation — third-party accounts created on the device for durable access that survives password changes on the legitimate admin account.

Why P2P Is the Dangerous Default

P2P remote access on these devices means the camera maintains an outbound, persistent connection to a vendor cloud relay. From a network defender's perspective, this is an unmanaged covert channel: the device is reachable from the internet even if your firewall blocks all inbound traffic. Any detection strategy that assumes "the firewall blocks inbound, so the camera is safe" is invalid against this technique. Egress monitoring and P2P disablement are the correct controls.

Exploitation Status

• Confirmed active exploitation — CERT-UA states compromises have been recorded, not theorized.
• Persistence mechanism in use — rogue account creation indicates intent to maintain long-term access.
• No CVE identifier has been published in the alert; this is a campaign exploiting architectural exposure (P2P) plus authentication weaknesses, not a single patched flaw. Do not wait for a CVE to act.

Detection & Response

The observable artifacts defenders can hunt on are: (a) unexpected outbound P2P/cloud-relay traffic from camera VLANs, (b) account-creation and configuration-change events in device logs, and (c) authentication to camera management interfaces from unexpected source IPs. The detections below target those three layers.

Sigma Rules

---
title: Surveillance Device Outbound P2P Cloud Relay Connection
id: 3f8c2a71-6b4d-4e9a-b1c7-9d2e5f8a3c01
status: experimental
description: Detects IP cameras or DVRs/NVRs establishing outbound connections to vendor P2P cloud relay infrastructure, indicating P2P remote access is enabled and the device is reachable from the internet despite inbound firewall rules. Correlate with dedicated camera VLAN source addresses.
references:
  - https://thehackernews.com/2026/10/attackers-hijack-dahua-ip-cameras-in.html
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/10/20
tags:
  - attack.command_and_control
  - attack.t1071
logsource:
  category: firewall
  product: zeek
detection:
  selection_src:
    src_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  selection_port:
    dst_port:
      - 8800
      - 3478
      - 1935
  condition: selection_src and selection_port
falsepositives:
  - Vendor P2P mobile viewing apps legitimately enabled by the physical security team (treat as a finding to remediate, not a false positive to suppress)
level: medium
---
title: Account Creation or Configuration Change on Surveillance Device Syslog
id: 8a1d4e62-3c7b-4f2a-9e5d-1b6c8a4d2e09
status: experimental
description: Detects syslog messages from IP cameras/DVRs/NVRs indicating creation of a new user account or modification of device configuration, consistent with CERT-UA-reported attacker persistence via third-party account creation on Dahua devices.
references:
  - https://thehackernews.com/2026/10/attackers-hijack-dahua-ip-cameras-in.html
  - https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/10/20
tags:
  - attack.persistence
  - attack.t1136
logsource:
  product: linux
  service: syslog
detection:
  selection_msg:
    Message|contains:
      - 'Add User'
      - 'AddUser'
      - 'user added'
      - 'Create User'
      - 'New account'
      - 'Modify Config'
      - 'Save Config'
      - 'Config Change'
  filter_known_sources:
    Computer|contains:
      - 'camera'
      - 'nvr'
      - 'dvr'
      - 'ipc'
  condition: selection_msg and filter_known_sources
falsepositives:
  - Legitimate onboarding of new cameras by physical security staff (whitelist change windows, not hostnames)
level: high

KQL — Microsoft Sentinel / Defender

This query hunts Syslog/CEF-ingested camera and DVR logs for account creation, configuration changes, and successful admin logins from source IPs outside your approved management range. Adjust the ApprovedMgmtSources list to your environment.

let ApprovedMgmtSources = dynamic(["10.10.5.0/24", "192.168.20.0/24"]);
let SuspiciousEvents = Syslog
| where TimeGenerated > ago(7d)
| where Computer has_any ("cam", "nvr", "dvr", "ipc") or SyslogMessage has_any ("Dahua", "IPC", "NVR", "DVR")
| where SyslogMessage has_any ("Add User", "AddUser", "Create User", "New account", "Config Change", "Save Config", "Modify Config", "login")
| project TimeGenerated, Computer, HostIP, SyslogMessage, SeverityLevel
| extend EventType = case(
    SyslogMessage has_any ("Add User", "AddUser", "Create User", "New account"), "AccountCreation",
    SyslogMessage has_any ("Config", "Save Config", "Modify Config"), "ConfigChange",
    "Authentication");
SuspiciousEvents
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Computer, HostIP, EventType
| order by LastSeen desc;
// Second hunt: camera VLAN egress to non-RFC1918 destinations on vendor P2P/relay ports
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor has_any ("Dahua") or SourceIP startswith "192.168."
| where DestinationPort in (8800, 3478, 1935, 37777)
| where ipv4_is_private(DestinationIP) == false
| summarize Connections = count(), DistinctDests = dcount(DestinationIP) by SourceIP, DestinationPort, DeviceVendor
| order by Connections desc;

Velociraptor VQL — Hunt NVR/VMS Hosts for Unexpected Outbound Connections

For Windows or Linux hosts acting as video management servers (VMS) or NVR bridges, hunt for established outbound connections to surveillance vendor cloud relays or unexpected external peers.

-- Hunt VMS/NVR hosts for suspicious outbound connections to camera P2P relays
SELECT Pid, Name, Path, Status, Family,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Status =~ 'ESTABLISHED|CLOSE_WAIT|TIME_WAIT'
  AND RemotePort IN (8800, 3478, 1935, 37777, 554)
  AND NOT RemoteIP =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)'
  AND NOT Name =~ '(firefox|chrome|msedge|iexplore)\\.exe'
ORDER BY RemotePort

Remediation & Verification Script — Harden Dahua Devices and Egress Policy

Run this from a management host with SSH/API access to your NVRs and with rights to export the camera inventory. It enumerates accounts for rogue users, checks P2P state, and validates egress firewall coverage.

#!/usr/bin/env bash
# Dahua surveillance fleet hardening & rogue-account sweep
# Prerequisites: curl, jq. Export CAMERA_LIST with device IPs and set per-device creds via env.
set -euo pipefail

CAMERA_LIST="${CAMERA_LIST:-/opt/sec/cameras.txt}"   # one IP per line
ADMIN_USER="${DAHUA_USER:-admin}"
ADMIN_PASS="${DAHUA_PASS:?Set DAHUA_PASS env var}"
REPORT="/var/log/dahua_audit_$(date +%Y%m%d).log"

echo "=== Dahua fleet audit $(date -u) ===" | tee "$REPORT"

while read -r DEV; do
  [ -z "$DEV" ] && continue
  echo "--- $DEV ---" | tee -a "$REPORT"

  # 1) Enumerate local accounts - flag anything not in the approved list
  ACCOUNTS=$(curl -s --digest -u "${ADMIN_USER}:${ADMIN_PASS}" \
    "http://${DEV}/cgi-bin/configManager.cgi?action=getConfig&name=UserManager" || true)
  echo "$ACCOUNTS" | grep -i 'Name=' | tee -a "$REPORT"
  APPROVED="admin|operator|viewer"
  echo "$ACCOUNTS" | grep -i 'Name=' | grep -viE "Name=($APPROVED)" \
    && echo "[ALERT] Unexpected account on $DEV" | tee -a "$REPORT"

  # 2) Check P2P status - expect 'false' after hardening
  P2P=$(curl -s --digest -u "${ADMIN_USER}:${ADMIN_PASS}" \
    "http://${DEV}/cgi-bin/configManager.cgi?action=getConfig&name=P2P" || true)
  echo "$P2P" | tee -a "$REPORT"
  echo "$P2P" | grep -qi 'Enable=true' \
    && echo "[ALERT] P2P still ENABLED on $DEV - disable immediately" | tee -a "$REPORT"

done < "$CAMERA_LIST"

echo "=== Audit complete. Review [ALERT] lines in $REPORT ==="

# 3) Egress firewall verification: camera VLAN must not reach internet P2P relays.
# Example nftables egress deny for camera VLAN 192.168.50.0/24 (adjust to yours):
# nft add rule inet filter forward ip saddr 192.168.50.0/24 oifname "wan0" \
#   tcp dport { 554, 1935, 37777 } drop
# nft add rule inet filter forward ip saddr 192.168.50.0/24 oifname "wan0" \
#   udp dport { 3478, 8800 } drop

Remediation

CERT-UA and the SSSCIP recommendations, expanded with field-tested hardening steps:

1. Disable P2P immediately. On every Dahua camera and DVR/NVR, disable the P2P/Easy4IP cloud function (System → Network → P2P, or via configManager.cgi). P2P negates your perimeter; treat it as an unacceptable risk until the vendor threat model changes. Verify disablement with the audit script above — do not trust the UI alone.
2. Hunt for rogue accounts. Enumerate all local accounts on every device. Any account your physical-security team did not provision is an intrusion artifact: remove it, then treat the device as compromised (full config review, firmware reflash, credential rotation for every other account it could reach).
3. Rotate all credentials. Replace default and weak passwords with unique, strong per-device credentials. Assume any device that was P2P-reachable or internet-exposed has had its credentials harvested.
4. Isolate the surveillance VLAN. Cameras and DVRs should live on a dedicated VLAN with (a) no direct internet egress except to an approved update/VMS destination, (b) no inbound access except from the VMS/management subnet, and (c) deny-by-default lateral movement to user and server segments.
5. Block outbound P2P/relay ports at the perimeter. Deny camera-VLAN egress on UDP 3478/8800 and TCP 554/1935/37777 unless explicitly required for a sanctioned integration.
6. Update firmware. Pull the latest firmware for each model directly from Dahua's official support portal and apply it. Authentication and remote-access weaknesses in this device class are routinely fixed silently in firmware trains; running stale firmware on a wartime-targeted product line is indefensible.
7. Restrict management interfaces. Web admin and config APIs should answer only on the management VLAN. Disable UPnP on both the cameras and the gateway router — UPnP port-mapping is how many of these devices end up internet-exposed without anyone deliberately opening a port.
8. Enable and centralize logging. Forward camera/DVR syslog to your SIEM (the KQL and Sigma content above assumes this). Cameras that log only locally are cameras whose compromise you will never see.
9. Monitor the video streams themselves. Alert on new RTSP sessions, new stream destinations, or configuration changes pointing streams off-network — stream redirection is both an espionage and a staging technique.

Severity & Urgency

This is a confirmed, active campaign against a product line with a long history of remote-access weaknesses. If your organization operates Dahua devices with P2P enabled or any internet exposure, begin the account sweep and P2P disablement today, and review device configurations for unauthorized changes as part of the same sweep. Ukrainian entities should follow CERT-UA's reporting channel for suspected compromises; all other organizations should treat unexpected accounts or configuration drift on these devices as reportable security incidents.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub