Technical Security Audit. Video Surveillance System

 Contents

1Scope and methodology

Scope. The surveillance network 10.1.8.0/24 and the site's internet-facing IP 162.255.94.170, performed with owner authorization as a defensive security audit. Methods. ICMP host discovery; TCP port scanning (internal and external); MAC/OUI vendor identification; authenticated Dahua HTTP API queries (magicBox.cgi, configManager.cgi over HTTP Digest/Basic); authentication-realm fingerprinting to map exposed ports to internal devices; on-site console and web-UI inspection; and CVE cross-referencing against NVD, CISA KEV, and Dahua PSIRT affected-model lists.

Coverage. Firmware was read from 39 of 68 cameras plus the NVR and one XVR. At the time of the initial pass, 29 cameras and 3 exposed recorders were not readable (different per-device credentials, non-standard ports, or no HTTP) and were recorded as unassessed. Credentialed access to the three remaining exposed recorders (.31/.32/.33) was subsequently obtained and is reflected throughout this document; the 29 unread cameras remain unassessed.

Note on timeline. Safely obtaining credentials for each of the three remaining recorders, mapping external ports to internal devices, cataloguing the accounts present on each, and identifying exactly which camera channels each device could see was hands-on, on-device work spanning parts of two days (analysis on 23 July, device-by-device confirmation on 24 July), roughly ten hours in total. This was deliberate: the priority was confirming the exposure precisely and without disturbing evidence, not a quick scan.

2Asset inventory

3Findings

4Vulnerability assessment

4.1  Cameras (representative models)

4.2  NVR. DHI-NVR608H-64-XI, V4.000.0000000.4.R (2023-08-31)

No known exploitable CVE.   Patched against the 2021 auth-bypass (post-fix platform); out of scope for the 2024 (NVR4XXX / IPC-HX8XXX) and 2026 (per Dahua Affected-Models PDF) advisories. Risk is exposure and configuration, not firmware.

4.3  XVR. DH-XVR5216A-4KL-I3, V4.001.0000002.1.R (2024-08-06)

No known exploitable CVE.   Verified by exact-model matching against Dahua PSIRT affected-model lists:

Caveat. Not affected by these CVEs is not the same as hardened. This device remains internet-exposed with Anti-DoS disabled (F1, F4).

4.4  Recorders 10.1.8.31 / .32 / .33 (X72A3A), V4.001.0000000.15 (2021-10-13)

Confirmed compromised.   All three recorders share the same platform and firmware: X72A3A, System Version V4.001.0000000.15, build 2021-10-13, the oldest firmware and lowest security-baseline generation of any recorder in the fleet (Security Baseline V2.1, versus V2.3 on the NVR and the .34 XVR). The build date sits close to Dahua's mid-2021 fix window for CVE-2021-33044/-33045, but the version string does not cleanly map to a confirmed-patched baseline the way the newer .34 XVR does. Regardless of which specific CVE was the entry vector, unauthorized administrator accounts are already present on all three devices (Finding F10), so the vulnerability question is secondary to the confirmed compromise: these units must be treated as a live incident, not a patching exercise.

5Risk assessment (high-rise residential context)

The system records residents, guests, and deliveries throughout the lobbies, elevators, corridors, amenity areas, and parking. This is no longer a hypothetical. Outside parties already hold standing administrator access to three internet-exposed recorders (Finding F10), with attacker accounts tied to the CamhubfreeTG camera-hijacking operation, so live and stored footage, and every credential stored on those devices, must be treated as already exposed. In this residential context that means real resident harm: covert surveillance of individuals' comings-and-goings and daily patterns (enabling burglary timed to an empty unit, stalking, or extortion), the ability to disable or blind cameras during a physical intrusion, and a view into the building's own network infrastructure (the .32 MDF-room camera). It exposes the board directly to privacy and fiduciary liability, and breach-notification obligations may already be in force (see Section 6).

6Remediation plan

6.1  Cleaning versus replacing a compromised recorder: method and sources

The three compromised recorders (.31/.32/.33, Finding F10) cannot be treated as trustworthy again simply because their passwords are changed or a factory reset is run. This subsection sets out what a defensible remediation actually requires, why replacement is the recommended route for these three units, and the published sources behind that conclusion. It is written so the Board and whichever equipment vendor performs the work share one reference, rather than relying on a partial verbal summary of what is needed.

A factory reset is not a firmware reflash, and neither on its own evicts an established intruder. On Dahua equipment, “restore defaults” and “firmware update” are separate operations (ref. a). A reset clears the configuration partition (settings and the visible account list) but does not rewrite the firmware or operating-system image, so anything an attacker planted below that layer, a modified firmware binary, a re-enabled telnet or debug shell, a startup hook, survives the reset untouched. Dahua's own procedure is to factory-default after flashing firmware, not instead of it. Documented real-world cases bear this out: a rogue administrator account that survived both a reset and a firmware update, cleared only by attaching a serial console, performing a low-level configuration erase, and re-imaging the full firmware over TFTP (ref. b). Backdoor analyses show the same class of operating-system-level footholds, telnet services, static root credentials, and user-database dumps, that a configuration reset cannot reach (ref. e, ref. f).

The compromise also re-installs itself while the device stays online. For the CVE-2021-33044 botnet class, which matches the mass-hijack pattern seen on these recorders, a deleted rogue account reappears within roughly 30 to 60 minutes through the vendor peer-to-peer / cloud channel (P2P / Easy4ip) unless that channel is disabled and the device is isolated from the internet (ref. c, ref. d). A defensible clean, were a unit to be kept, is therefore an ordered procedure rather than a single button: isolate the device, preserve evidence, reflash verified firmware obtained only from Dahua's own portal (ref. a), factory-default again after the flash, disable P2P / UPnP / telnet and remove all port-forwards, rotate every credential, then confirm no rogue account returns after a period of monitored uptime. Any account or setting that returns escalates straight to serial-console re-imaging or replacement.

For these three units the correct answer collapses to replacement. All three are the oldest, end-of-life generation (2021 X72A3A build). For an end-of-life device there is no current, patched official firmware to reflash to, so even a perfect clean cannot close the vulnerability that let the intruders in: standard guidance is to retire network equipment that no longer receives firmware rather than nurse it (ref. g). Layered on top, the labor to forensically clean a low-cost recorder, serial-console work that ordinary integrators do not perform, routinely exceeds the cost of replacing the unit, and a new device carries provenance the Board can trust. A final caveat reinforces the point: even a correct reflash can miss a bootloader-level implant, which cannot be ruled out without serial-console verification. The accepted standard for a fully-compromised embedded appliance is reimage-from-known-good or replace, and for these three end-of-life recorders that means replace.

Choosing replacement is also a procurement decision, not only a security one. The three recorders sit on a shared camera fleet alongside a retained main NVR (Section 2), so any replacement units, and whichever integrator installs them, must be compatible with the existing cameras and recording architecture (ONVIF support and the retained NVR's channel capacity). Selecting that equipment and a qualified integrator who can work on the current system is part of the decision the Board should plan for. I have completed the preliminary research summarized here and am glad to investigate specific replacement options and integrators further to form a concrete recommendation; detailed execution is best carried out by the equipment vendor performing the work.

6.2  Locking down the cameras

What is confirmed and what is not. The compromise is confirmed on the three recorders (Finding F10): rogue administrator accounts are visible on the devices themselves. The cameras are a different status: reachable and at risk, but not yet individually confirmed. That distinction should be stated plainly to the Board so no one over- or under-reacts. A camera can be examined the same way the recorders were (see the confirmation procedure below), but until each is read it should be treated as potentially accessed rather than either proven clean or proven breached.

Why the cameras are exposed even though they are not port-forwarded. A common assumption is that because the cameras are not individually published to the internet, an attacker who took over a recorder cannot reach them. That is not correct. Two facts make the cameras reachable from an owned recorder: the recorder stores the cameras' credentials (it has to, in order to pull their streams), and the recorder sits inside the same flat LAN as the cameras (10.1.8.0/24). Not being port-forwarded only blocks a stranger from reaching a camera directly from the internet; it does nothing to stop an attacker who is already standing inside the network on a device that holds the keys. From a compromised recorder the cameras are reachable over their web interface, ONVIF, the Dahua service port (37777), RTSP, and in some builds telnet.

The cameras run the same class of software as the recorders. These are not passive sensors: Dahua IP cameras run an embedded Linux operating system of the same class as the recorders, and can hold the same kind of persistent foothold. The mass-hijack botnet documented in the remediation sources targets Dahua and EZ-IP cameras directly, not only recorders (ref. c, Section 6.1). Five cameras (.113, .117, .206, .224, and .115 pending evaluation) are the end-of-life generation carrying unauthenticated critical-severity takeover vulnerabilities with no fixed firmware available; like the three recorders, these are replace, not clean.

Lock-down sequence. Once the recorders are contained (Section 6, P0) the cameras follow in order:

• Rotate every camera credential, on the assumption that anything the recorders held is leaked. Do this only after the recorders are off the network, so new passwords are not simply re-harvested.
• Replace the five end-of-life cameras rather than attempting to clean them; there is no patched firmware to reflash them to.
• Move the cameras onto an isolated segment (Section 6.3) so a future foothold on any one device cannot reach the internet or the rest of the building network.
• Bring the remaining cameras to current firmware from the vendor's own portal, and retire any that cannot be updated.
• Re-credential and re-add the cameras to the recorders last, once the recorders themselves are trustworthy (replaced or verifiably clean).

Confirming whether a given camera was accessed. The same evidence that established the recorder compromise applies per camera, strongest first:

• Account audit (definitive). Read the camera's user/account list for accounts nobody created, the single clearest signal, exactly as on the recorders.
• Configuration and service check. Look for enabled telnet/SSH/ONVIF that should be off, altered network or push settings, and unexpected DDNS / P2P / cloud targets.
• Firmware check. Compare the running firmware and build date against the vendor's known-good release; an unexpected or downgraded build is a red flag.
• Log review (weak on its own). Device logs are small, roll over quickly, and can be cleared by an intruder, so a clean log is not proof of a clean device; use it only as corroboration.
• Egress watch. With the segment isolated, watch for any device still trying to reach the internet; a camera phoning out is a strong sign of a foothold.

The honest limit, as with the recorders: a device carrying an operating-system-level implant cannot be proven clean from its own interface. Where certainty matters, replacement is the only guarantee.

6.3  Network segmentation

What is already in place. The camera network is already separated from the building's resident wifi: it was placed on its own segment (subnet 10.1.8.0/24) several years ago, after the internet provider flagged unusually heavy traffic on the line. The gateway is a TP-Link Omada ER7206, which is VLAN-capable, so the segmentation control this needs is already within the existing equipment; whether that separation is enforced with 802.1Q VLANs or simply a separate subnet has not been confirmed and is one item to settle on obtaining the router login. Two cautions come with that history. First, separating the cameras from resident devices is not the same control as denying them internet access, and it is internet access that this incident turned on. Second, the reported “heavy traffic” is consistent with peer-to-peer or botnet activity; it cannot be confirmed without reading the gateway's configuration and logs, but if it was botnet chatter it would mean this exposure predates the current assessment by years. Confirming or ruling that out is an open item, tied to obtaining the router login (Section 6.4 and the P3 remediation row).

Where the segment is still flat, and still exposed. Within the camera network the devices remain on one flat segment, 10.1.8.0/24: the cameras, all three compromised recorders, the clean NVR and .34 XVR, the IntuVision analytics PC, and, importantly, two devices that do not belong there, the unexplained Raspberry Pi at .196 (Finding F8) and a consumer Roku cabled into the camera switch (Finding F9). So the segment is walled off from residents but is neither internet-denied nor clean. On a flat segment any device that is taken over can attempt to reach every other device on it, which is why a single compromised recorder became a whole-segment problem rather than a one-device problem.

The two controls that actually close the exposure. Deny the camera segment both inbound and outbound internet, and remove the devices that do not belong on it. Picture the segment as a locked room: the cameras and their recorder stay inside and talk to each other exactly as they do now, but the door to the internet is shut and the door to the rest of the network is shut. Remote viewing is not a hole cut in the wall (a port-forward) but a key handed to trusted staff from outside (a VPN such as Tailscale or WireGuard, which admits an authorized viewer into the room without ever exposing the cameras to the open internet). This also answers the natural question of how the cameras still reach the recorder: they stay on the same dedicated segment as before; what they lose is the route to the internet and to the rest of the building, which is the exact path the attackers used.

Going further: segment by trust level, not just cameras versus residents. Because old, compromised equipment will co-exist with clean and replacement equipment during the transition, it is worth sub-dividing the camera network by how far each device can be trusted rather than treating it as a single pool. A practical three-tier layout:

• Quarantine tier – the old, end-of-life, compromised Dahua units (the three recorders, the five end-of-life cameras, and anything not yet verified). Isolated with no internet and no route to the other tiers. This tier exists only as long as those units must keep running during the changeover; ideally they are powered off the moment replacements are live.
• Verified-clean tier – the retained main NVR, the .34 XVR, and current-firmware cameras that pass the Section 6.2 check.
• Future (non-Dahua) tier – the clean replacement build.

Two points make this more than cosmetic. The control that matters is deny-internet plus no routing between tiers, so a compromised old unit cannot re-infect or pivot to a clean one. And there is a real reason to keep the future non-Dahua build on its own tier beyond age: the documented Dahua backdoor class is vendor-wide (Section 6.1, ref. e and ref. f), so a Dahua-level event would reach new and old Dahua alike, and a separate non-Dahua segment contains it. One caveat so the design is not over-built: three tiers is a migration architecture. Once the old gear is decommissioned it collapses to a single clean camera segment plus the VPN.

Equipment. The ER7206 already supports the VLANs and inter-segment access rules this needs. The remaining hardware question is whether the camera switch is a managed, VLAN-capable unit; the consumer Roku found cabled into it (Finding F9) is exactly the kind of stray device the segmentation removes. Confirming the switch is managed, or replacing it with one that is, is the one item to settle before the work.

6.4  Full device inventory and smart-device triage

A recurring lesson from this assessment is that the network contains devices nobody can currently account for (the Raspberry Pi at .196, the Roku at .137). Before the rebuild, every device on 10.1.8.0/24 should be inventoried: its owner, its purpose, its firmware version, and whether that firmware is still supported. The governing rule for anything that talks to the network (any “smart” device) is simple: bring its firmware current, or take it off the network. A device that cannot be updated, or that no one can explain, is a candidate foothold and does not belong on the same wire as the cameras.

This inventory also settles the open question of exactly how many cameras belong to each recorder, which the “suggested resolution” below depends on.

6.5  Suggested resolution

This subsection is deliberately high-level: it frames the decision for the Board rather than specifying a full bill of materials, which follows once the inventory (6.4) is complete and the Board sets direction. It reflects the option raised in discussion, treating the compromised half of the system as one unit to be rebuilt rather than nursed.

Rip-and-replace the compromised cluster as one unit. The three compromised recorders (.31 / .32 / .33) and the cameras they record, roughly fifteen channels across the parking decks, elevator lobbies, interior hallways, the lobby and front desk, the MDF room, and the Rumson lots (exact membership to be fixed by the 6.4 inventory), are the oldest, end-of-life generation and are being replaced anyway. Rather than clean each piece in place, the cleaner path is to remove that cluster wholesale and rebuild it on a new, isolated subnet from day one: internet-denied, remote access by VPN only (6.3). Building it isolated from the start avoids ever re-creating the exposure that caused this incident.

Standardize the replacements on a currently-supported, non-restricted product line. To be precise about the reasoning, so the Board is not misled: the brand did not cause this breach. Internet exposure and weak passwords did, and the same mistakes would compromise any brand. But since these units are being replaced regardless, are end-of-life, and, as noted in Section 5 and Finding F5, carry U.S. procurement constraints (NDAA Section 889, the FCC Covered List, and Entity List restrictions), the replacement is the natural moment to move to a vendor that is both currently supported and free of those constraints. That is a reliability and procurement decision, not a claim that the old brand was the vulnerability.

What can stay. The retained main NVR and the .34 XVR tested clean and do not need replacing; they can remain in service provided they are moved onto the isolated segment and fully re-credentialed (6.4). The goal is not to discard everything, only the compromised and end-of-life equipment, and to ensure whatever remains lives behind the same isolation.

Next step. This is the preliminary shape of the recommendation. Once the Board indicates it wants to proceed, I can develop a concrete phased plan, a specific replacement product line, candidate integrators qualified to work on the current system, and a bill of materials, for the Board's review before any purchase or work is authorized.

7Evidence index

Full evidence log and screenshots: evidence/EVIDENCE-LOG.md (E1 to E20). Key items: E1 NVR System Info (photo); E2 XVR P2P Online; E3 XVR UPnP port-mapping; E4 XVR TCP/IP config; E5 external port scan; E6 realm-fingerprint mapping; E7 XVR firmware; E11 internet egress test.

Recorder .31 (port 88): E17 system info/firmware; E18 rogue-account list (CONFIRMED COMPROMISE); E19 live-view exposed channels (parking deck P1–P5, elevator hallway).

Recorder .32 (port 89): E8 system info/firmware; E9 rogue-account list (CONFIRMED COMPROMISE, includes hackedBy/CamhubfreeTG); E20 live-view exposed channels (MDF room, interior hallways, P5/P6 parking).

Recorder .33 (port 90): E10 system info/firmware; E10-ACCT rogue-account list (CONFIRMED COMPROMISE); E12 live-view exposed channels (lobby, front desk, gallery, entries, Rumson lots, compactor room).

Recorder .34 (port 91): E13 account list (clean).

Port 93 / main NVR: E14 system info (identifies port 93 as the NVR, resolving the earlier "unlocated fifth device"); E15 account list (clean); E16 storage/RAID configuration.

8Citations

• NDAA §889 (names Dahua): eac.gov/what-section-889-fy-2019-ndaa
• FCC Covered List and 2022 ban: fcc.gov/supplychain/coveredlist; CRS LSB10895
• BIS Entity List, Oct 2019: Federal Register 84 FR 54002
• China National Intelligence Law (2017), Art. 7: chinalawtranslate.com
• CVE-2021-33044 / -33045 (9.8, CISA KEV 2024-08-21): NVD 33044 / 33045; CISA KEV catalog
• CVE-2021-33046 / CVE-2020-9502 (9.8): NVD 33046 / 9502
• CVE-2025-31700 / -31701 (affected models = cameras only): Dahua PSIRT advisory; Affected-Models.pdf
• CVE-2026-29116 / DHCC-SA-202606-001 (XVR list = XVR1B04H-I/T, XVR4232AN-I/T only): Dahua PSIRT advisory; Affected_Models.pdf
• CVE-2022-30564 (lists XVR5216A; fixed Nov-2022): NVD CVE-2022-30564
• Dahua P2P/Easy4ip phone-home: ipvm.com/reports/hikvision-home

9Confidence and limitations

• CVE facts verified against NVD and CISA; model scope verified against Dahua's official Affected-Models PDFs (exact-SKU matching).
• The NVR being patched against the 2021 CVEs is a platform and build-date inference, not a verbatim vendor line-item.
• Latest-firmware version strings could not be machine-verified (the Dahua download center blocks automated access); confirm on-device before any upgrade sign-off.
• Camera internet egress is unconfirmed; a host on the subnet reached the internet, but per-device router filtering was not verifiable without the router login. Recorder egress and ingress are confirmed (E2, E5, E11).
• Coverage: 29 of 68 cameras remain unassessed (different per-device credentials); treated as unknown, not clear. All five internet-exposed recorders have now been read and account-checked.
• The literal administrator password is intentionally excluded from this document and should be rotated.

10Open questions and next steps

Two items remain unresolved. Neither changes the Priority 0 actions above; both represent additional verification and coverage that would complete the picture. (The status of the three previously-unread exposed recorders and the identity of the fifth internet-exposed device have since been resolved, see Finding F10 and Section 2.)

1. Camera internet egress is unconfirmed. A host on the camera subnet reached the public internet directly, and that subnet's gateway is the primary internet path, so the signs suggest the cameras are not blocked. Confirming whether the router applies a per-device block requires the router (TP-Link) administrator login to review its egress/ACL and port-forwarding configuration. Recorder egress and ingress are confirmed (E2, E11).
2. Inventory of the remaining 29 cameras is incomplete. These use different per-device credentials and were not inventoried; they remain unassessed, not clear.
3. Unidentified Raspberry Pi (F8) not physically located. Four networking closets and the AV room were searched (2026-07-24) without finding it; owner and function remain unconfirmed pending its outbound traffic (router login) or the switch MAC-address table.

Closing these requires the router login (item 1) and continued device access (item 2). Until then, the unassessed cameras should be treated as unknown rather than clear.