14,530 Cameras Compromised in 35 Days: It’s Time to Rethink Remote Video Access

by David Erickson

September 3, 2026

Key Takeaways

14,530 cameras were compromised in just 35 days, showing how quickly insecure remote-access methods can be exploited at scale.
Port forwarding, DDNS, weak credentials, and outdated firmware continue to create avoidable exposure for internet-reachable video devices.
Manufacturer-managed P2P access can also introduce risk, especially when devices can be reached through serial-number-based discovery or weak recovery controls.
Password changes and firmware updates are necessary but not enough if the underlying remote-access architecture remains exposed.
Security companies should review how remote video access is delivered and move toward centrally managed, encrypted models that avoid unnecessary inbound exposure.

Port forwarding, weak credentials, outdated firmware, and poorly secured P2P services can turn remote access into remote exposure with compromised cameras.

A new Hunt.io investigation should get the attention of every security dealer, systems integrator, and monitoring provider.

Between June 17 and July 22, 2026, a single threat actor compromised more than 14,500 IP cameras in just 35 days. While confirmed, geolocated compromises were heavily concentrated in Ukraine and Russia, the underlying reconnaissance swept across the globe, capturing significant targets in Mexican and Vietnamese ISP ranges as well.

The lesson here reaches far beyond one region, one manufacturer, or a single cyber campaign.

Too many commercial video deployments still rely on remote-access architectures designed primarily for installer convenience. When cameras, recorders, credentials, and manufacturer-managed cloud services are improperly secured, that convenience turns into exposure. The electronic security industry needs an urgent, foundational review of how remote video access is delivered.

What Researchers Discovered

HuHunt.io recovered and analyzed the threat actor’s active working environment—including over 2,600 files across 234 directories recovered from an exposed server. The forensic analysis revealed multiple automated attack vectors running simultaneously:

14,530+ unique devices compromised in 35 days.
12,324 unique IP addresses breached through automated credential brute-forcing.
1,923 cameras breached via authentication-bypass exploits and implanted with a persistent backdoor account.
283 cameras penetrated directly through Dahua’s cloud P2P relay using only a serial number—without needing public IP addresses and, in most cases, without requiring credentials.
Offline recovery codes capable of generating administrative access based solely on serial numbers, entirely independent of normal device credentials.

While the numbers are alarming, the architectural flaws behind them demand our immediate focus.

Attack Path 1: Internet-Exposed Video Devices

The primary attack method relied on devices reachable via open firewall ports—commonly implemented through manual port forwarding. While this setup simplifies remote access and system management, it directly exposes edge devices to public surveillance and automated exploitation.

Bypassing perimeter firewalls forces an embedded video device to defend itself against internet-scale threats. In this campaign, threat actors leveraged internet-wide scanning tools (such as Masscan on port 37777) to map responsive endpoints before launching large-scale credential-stuffing and brute-force attacks. The toolkit also targeted unpatched hardware using two known authentication-bypass flaws (CVE-2021-33044 and CVE-2021-33045).

Relying on an IP camera or network video recorder (NVR) as a perimeter defense is a critical architectural flaw:

Shifts the Trust Boundary: Port forwarding transfers the defensive burden from an enterprise firewall to lightweight IoT firmware rarely hardened for continuous direct exposure.
Misinterprets Dynamic DNS (DDNS): While DDNS simplifies device management by resolving dynamic IP addresses, it acts solely as a locator. It provides zero encryption, access control, or perimeter filtering.
Guarantees Persistent Exposure: The threat is not simply an instantaneous breach; it is the perpetual window of opportunity. An exposed device faces uninterrupted scanning, fuzzing, brute-forcing, and zero-day testing by automated adversaries.

A compromised camera undeniably threatens privacy and physical security on-site. However, the far greater risk lies in network exposure. That camera is no longer just a monitoring tool; it is an open door into the customer’s internal private network. From there, an attacker can move laterally across other connected devices to target financial systems, confidential company files, or critical operational infrastructure.

Attack Path 2: Manufacturer-Managed P2P Access

The second attack path challenges a pervasive industry assumption: that a camera sitting behind a NAT router is automatically protected from remote intrusion.

In this campaign, the operator reached 283 cameras through Dahua’s cloud relay without needing the cameras’ public IP addresses. Devices were identified solely by serial number. According to the operator’s own logs, 89.4% of live serial numbers returned an open tunnel that required no authentication.

Even more concerning, researchers found that account recovery codes could be generated offline using nothing more than serial numbers. These derived codes granted administrative access regardless of whether local passwords had been changed.

No inbound firewall rules were needed. The devices remained reachable because outbound tunnel mechanisms were permanently built into the manufacturer’s firmware and cloud relay services.

This does not mean cloud relays are inherently unusable, but it does mean security professionals must critically examine how third-party services discover devices, handle session authentication, encrypt streams, and control administrative recovery.

“Behind the router” should never be confused with “unreachable.”

Why Changing the Password Isn’t Enough

After exploiting the authentication-bypass vulnerabilities, the attacker automated the creation of an unauthorized backdoor account named p2pwn (with the password p2password) across nearly 1,900 cameras.

According to Hunt.io, this credential was injected over RPC and stored independently of standard administrator accounts. Consequently, the backdoor persisted through administrator password changes and, across most affected firmware builds, even survived a factory reset.

This reality breaks the traditional security playbook:

Routine password rotations and reactive patching are necessary, but they are individual controls applied to a broken foundation. They cannot fix an architecture that relies on inherently exposed endpoints or poorly controlled cloud-tunneling services.

Cybersecurity must begin with network architecture, not credential management.

Practical Action Steps for Security Integrators

If your organization installs, services, or monitors IP video surveillance, use this finding to immediately audit your installed base:

Eliminate Inbound Port Forwarding: Audit firewalls for publicly exposed NVRs, DVRs, and cameras. Terminate inbound port rules immediately.
Decommission DDNS Used for Direct Exposure: Dynamic DNS creates convenience at the expense of an exposed public target. Remove DDNS records tied to open device ports.
Disable Unverified P2P Cloud Relays: Disable manufacturer P2P/cloud-relay features at the device level whenever they are not strictly required. If cloud access is necessary, ensure the platform provides end-to-end encryption, strict role-based access control, and zero reliance on public serial-number discovery.
Audit for the p2pwn Backdoor: On deployed Dahua hardware and Dahua OEM systems, review user account tables immediately. Treat any device that had port 37777 exposed during this window as compromised. Rotate all local passwords and remove unauthorized accounts.
Enforce Coordinated Firmware Patching: Verify camera firmware against current vendor CVE advisories. Dahua noted that updated firmware invalidates older offline recovery algorithms and addresses the 2021 authentication flaws.
Stop Sharing Direct Device Credentials: Monitoring centers and third-party dispatchers should never hold master root credentials to edge video hardware. Access should be mediated through secure session gateways.
Audit Connection Architecture: Evaluate the fundamental data path: How does video leave the site, and what had to be opened to allow it? If the answer involves open inbound ports, port forwarding, or unmanaged cloud relays, your architecture requires an immediate overhaul.

A More Secure Model for Remote Video Monitoring

Remote access is essential for professional video monitoring services. The objective is not to eliminate remote connectivity, but to eliminate uncontrolled exposure.

At CHeKT, our platform was engineered around this exact principle.

The CHeKT Video Control Panel bridges cameras to the CHeKT Cloud through an outbound-only, TLS-encrypted connection. This enables real-time alarm monitoring, video verification, and camera health checks without introducing the risks highlighted in the Hunt.io report:

Zero Inbound Ports: No firewall holes, NAT adjustments, or port-forwarding rules required.
No DDNS Dependency: Endpoints are never registered on public DNS lookups.
No Shared Device Credentials: Central stations verify incidents through secure cloud sessions rather than logging into local camera accounts.
End-to-End Encryption: Communications between the protected site and the cloud remain encrypted in transit.
Centralized Access Control: Permissions are governed through verified enterprise roles rather than shared device passwords.
Broad Hardware Compatibility: Integrates with leading ONVIF and manufacturer cameras without relying on insecure manufacturer P2P protocols.

Unlike traditional port forwarding, this architecture never publishes edge firmware to internet scanners. Unlike unmanaged P2P relays, access can never be hijacked simply by harvesting a hardware serial number.

CHeKT has previously outlined this approach in our guidance on secure remote video monitoring and discussed the risks of port forwarding in greater detail on Coffee Break With Jake.

The Bottom Line

The compromise of 14,500 cameras in 35 days is not just a reminder to patch firmware or change default pasThe compromise of more than 14,500 cameras in 35 days is not just another reminder to patch firmware or change default passwords. It is an indictment of outdated remote-access architectures.

Port forwarding is not a security strategy.
DDNS is not a security strategy.
Shared passwords are not a security strategy.
Unsecured manufacturer P2P access is not a security strategy.

They are simply ways to open a connection. When that access is not properly authenticated, encrypted, centrally controlled, and continuously maintained, connection becomes exposure.

Security dealers, integrators, and monitoring providers should not wait for the next large-scale compromise before reviewing how their systems communicate. The electronic security industry must move beyond convenience-first remote access and adopt architectures designed around security from day one.

Remote access is necessary. Uncontrolled exposure is an unacceptable business risk.

If your remote video offering still depends on port forwarding, DDNS, shared credentials, or unmanaged manufacturer P2P services, contact CHeKT to learn how you can deliver professional remote video monitoring through a more secure, centrally managed connection model.

Conclusion

The Hunt.io findings make one thing clear: remote video access must be designed with security in mind from the start.

Convenience-driven methods like port forwarding, DDNS, shared credentials, and poorly secured P2P services can create unnecessary exposure for both dealers and customers. Now is the time for security companies to review their installed base, tighten remote-access practices, and adopt architectures built to deliver professional video monitoring without exposing devices to avoidable risk.

FAQ

1. Why is port forwarding risky for IP cameras?

Port forwarding makes a camera, NVR, or DVR reachable from the public internet by opening an inbound path through the router or firewall. Once exposed, that device can be discovered by automated scanning and targeted with credential attacks, vulnerability testing, and exploitation attempts. Port forwarding may simplify remote access, but it also increases exposure.

2. Is DDNS a secure way to access security cameras remotely?

DDNS is not a security control by itself. It simply gives an internet-exposed device a consistent hostname even when the public IP address changes. If the underlying remote-access method depends on port forwarding or another exposed service, DDNS does not reduce that risk.

3. Are manufacturer P2P or cloud camera services secure?

Some manufacturer P2P and cloud services may be implemented more securely than others, but security companies should evaluate them carefully. Important questions include how devices are discovered, how users are authenticated, how credentials and recovery processes are protected, whether traffic is encrypted, and how vulnerabilities are disclosed and remediated. A camera being “behind the router” does not automatically mean it is unreachable.

4. Are password changes and firmware updates enough to secure remote video access?

No. Strong passwords and current firmware are essential, but they do not fix an inherently risky remote-access architecture. If cameras or recorders are still being exposed through port forwarding, DDNS, shared credentials, or weakly secured remote-access services, the overall deployment may remain vulnerable even after passwords are changed and updates are applied.

5. What is a more secure way to provide remote access to IP cameras?

A more secure model is one that avoids exposing camera management interfaces directly to the public internet and minimizes credential sharing. Security companies should look for centrally managed, encrypted connection methods that use controlled authentication and reduce the need for open inbound ports, DDNS, and direct device-level exposure.