Operators running Dahua IP cameras and DVRs should work through a short hardening checklist — disable or restrict the P2P cloud relay, rotate device credentials and audit for attacker-created accounts, verify firmware patching, place surveillance gear on its own VLAN, and watch its outbound traffic — after Ukraine's national CERT disclosed a campaign in which remote intruders took control of video surveillance devices.
The alert, reported by The Hacker News on 1 October 2026, is a reminder that the attack pattern it describes is not bound by geography. Surveillance infrastructure of this kind is commonplace in enterprises, residential buildings, and retail sites across the region, and the same exposure paths — a vendor cloud relay that reaches past the perimeter, stale or default credentials, and firmware that quietly falls behind — apply wherever these devices are deployed.
What the intruders did
According to the Computer Emergency Response Team of Ukraine (CERT-UA), attackers obtained unauthorised remote access to Dahua-manufactured video surveillance systems. The State Special Communications Service of Ukraine (SSSCIP) summarised the recorded activity as compromising IP cameras and DVRs with access to the video stream, changing device configuration, and creating third-party accounts.
That third item deserves the most attention. Reading a live camera feed is a privacy problem; writing new user accounts onto a device you do not own is a persistence problem. An attacker-created account on a camera survives credential rotations on the surrounding network, sits quietly outside typical endpoint monitoring, and can be re-used to return later. Treated strictly as a "camera issue," that foothold is easy to miss — which is the argument for treating surveillance hardware as first-class network assets with owners, inventories, and patch schedules.
The Ukrainian authorities framed the intrusion as leveraging peer-to-peer access and authentication weaknesses. Details on the specific vulnerability chain, including affected models, firmware versions, or CVE identifiers, remain limited in the public reporting; readers should treat this as an exposure-and-hygiene story rather than a single-patch fix until a fuller advisory is available.
Why the relay matters
The P2P cloud relay is the most easily overlooked part of the surface. It exists so that a phone app can reach a camera without port forwarding or a VPN, and it does so by having the device maintain an outbound connection to vendor infrastructure. In practice, that means the relay can bypass firewall rules that would otherwise block inbound connections, and it typically evades conventional asset inventories — no open port, no discovery scan result, nothing for a CMDB to record. Surveillance gear often remains enabled for P2P relay in the field, even where policy intends otherwise.
Hardening checklist
- Inventory the estate. List every Dahua (and other vendor) camera, DVR, and NVR, with location, owner, firmware version, and whether P2P relay is active — then alert on traffic from the surveillance VLAN to vendor relay domains or unfamiliar external IPs, which is often the only visible trace of an off-site session.
- Disable or restrict P2P cloud relay. On Dahua devices this is reachable from the web interface, generally under Configuration → Network → Platform Access (labelled P2P or Cloud), where the service can be switched off and any pairing QR codes invalidated. Where remote access is genuinely required, replace it with a site-to-site VPN or an authenticated reverse proxy instead.
- Rotate credentials and audit accounts. Change administrator passwords to long, unique values, delete any account you do not recognise, and review the device's user list for entries created after deployment — the tell-tale sign of the persistence described above.
- Verify firmware. Check the installed build against the vendor's current release for the exact model and apply updates; disable UPnP and unused services while in the interface.
- Segment the network. Put cameras on a dedicated VLAN with egress filtering, allowing only the specific management stations and NVRs that need to talk to them.
None of these steps require waiting for a model-specific patch. Even if the full vulnerability chain is never publicly detailed, closing the relay, the credentials, and the flat-network path removes most of what an attacker needs — and the same checklist applies equally to Hong Kong deployments of this equipment.
營運大華（Dahua）IP 攝像機及 DVR 的管理員應按一份簡短的強化清單逐一處理——停用或限制 P2P cloud relay、更換設備憑證並審計是否存在攻擊者建立的帳戶、核實固件修補情況、將監控設備劃入獨立 VLAN，並監察其對外流量——此前烏克蘭國家 CERT 披露了一項攻擊行動，入侵者以遠程方式控制了多部視像監控設備。
The Hacker News 於 2026 年 10 月 1 日報道的這則警報提醒我們：其所描述的攻擊模式並不受地域限制。這類監控基礎設施在區內企業、住宅樓宇及零售場所隨處可見，而同樣的暴露途徑——可穿越網絡邊界的廠商 cloud relay、過時或預設的憑證、以及悄然滯後的固件——在任何部署這些設備的地方都同樣適用。
入侵者做了甚麼
根據烏克蘭電腦緊急響應小組（CERT-UA），攻擊者取得了對大華製造的視像監控系統的未經授權遠程訪問。烏克蘭國家特別通訊及資訊保護局（SSSCIP）將已記錄的活動歸納為：入侵 IP 攝像機及 DVR 並獲取視像串流、更改設備配置，以及建立第三方帳戶。
第三項最值得關注。讀取即時攝像機畫面是私隱問題；在你並不擁有的設備上寫入新用戶帳戶，則是持久化（persistence）問題。攻擊者在攝像機上建立的帳戶，在外圍網絡完成憑證更換後仍然存在，安靜地避過一般端點監察，且可日後重用以再次入侵。若嚴格視為「攝像機問題」，這個立足點很容易被忽略——這正是應將監控硬件當作一等網絡資產來管理的理由：需有負責人、資產清單及修補時間表。
烏克蘭當局將此次入侵定性為利用 peer-to-peer 訪問及認證方面的弱點。有關具體漏洞鏈的細節，包括受影響型號、固件版本或 CVE 編號，在公開報道中仍然有限；在更完整的安全公告出台之前，讀者宜將此事視為暴露面與安全衛生（hygiene）的課題，而非單靠一次 patch 即可解決的問題。
為何 relay 是關鍵
P2P cloud relay 是整個攻擊面上最容易被忽略的部分。它的存在是為了讓手機 app 無需 port forwarding 或 VPN 即可連接攝像機，做法是讓設備維持一條連往廠商基礎設施的對外連線。實際上，這意味著 relay 可繞過本應阻擋入站連接的防火牆規則，而且通常會避過傳統的資產盤點——沒有開放 port、沒有 discovery 掃描結果、CMDB 也無從記錄。實地部署的監控設備往往一直啟用 P2P relay，即使政策另有規定。
強化清單
- 盤點資產。 列出每一部大華（及其他廠商）攝像機、DVR 及 NVR，註明位置、負責人、固件版本，以及 P2P relay 是否啟用——然後就監控 VLAN 流往廠商 relay 域名或陌生外部 IP 的流量設置警報，這往往是在站外會話中唯一可見的痕跡。
- 停用或限制 P2P cloud relay。 在大華設備上，可在 web 界面的 Configuration → Network → Platform Access（標示為 P2P 或 Cloud）中找到，可在此關閉服務並使所有配對 QR code 失效。若確實需要遠程訪問，應改用 site-to-site VPN 或經認證的 reverse proxy 取代。
- 更換憑證並審計帳戶。 將管理員密碼改為長而獨特的值，刪除任何你不認識的帳戶，並檢查設備的用戶列表中有否部署後才建立的帳戶——這正是上述持久化手法的典型跡象。
- 核實固件。 將已安裝的 build 與廠商針對該型號的最新版本比對並套用更新；同時在界面中停用 UPnP 及未使用的服務。
- 網絡分段。 將攝像機置於配備 egress filtering 的專用 VLAN，只允許確實需要與其通訊的指定管理站及 NVR 訪問。
以上任何一步都不需要等待針對特定型號的 patch。即使完整的漏洞鏈始終未有公開細節，關閉 relay、補上憑證防護及切斷扁平網絡路徑，已可消除攻擊者所需的大部分條件——而同一份清單同樣適用於香港本地部署的同類設備。