Listen to this Post
Introduction: One Open Directory Exposed an Entire Operation
A single operational mistake can sometimes reveal more than months of traditional security research.
That is exactly what happened when researchers at Hunt.io discovered an exposed directory belonging to an attacker who had compromised thousands of Dahua surveillance cameras between June 17 and July 22, 2026. The operation, which Hunt.io reconstructed from leaked files and network telemetry, has been dubbed Operation CameraSwarm.
A Massive Camera Compromise
The campaign targeted more than 14,000 Dahua cameras, with victims concentrated primarily in Ukraine and Russia. Rather than relying on one sophisticated exploit, the operator combined several different techniques, including brute-force authentication, vulnerability-based access, cloud-relay abuse, credential recovery, and automated scanning.
The result was a toolkit capable of finding vulnerable cameras at scale and maintaining access even when defenders attempted to reset passwords.
The Mistake That Revealed Everything
The investigation began on July 23 when
The directory was not protected.
Researchers were able to retrieve 2,616 files spread across 234 subdirectories, consuming approximately 407 MB of data. What they found was effectively a blueprint of the attacker’s operation.
The exposed material included scanning software, exploitation components, credential-handling tools, data-exfiltration utilities, recovery-code generation mechanisms, and even a Windows information stealer.
For defenders, the incident demonstrates a familiar but powerful lesson: attackers can spend enormous effort hiding their victims while accidentally exposing the infrastructure used to compromise them.
Operation CameraSwarm Was Built for Scale
Hunt.io described this campaign as substantially larger than another Dahua-related operation it had recently investigated.
The operator did not appear to be manually selecting cameras one at a time. Instead, the recovered tooling showed a highly automated workflow designed to discover devices, test access methods, harvest credentials, and maintain persistence.
That distinction matters.
A single vulnerable camera is a security problem. An automated system capable of identifying thousands of vulnerable cameras becomes an infrastructure problem.
The Brute-Force Engine
One component of the toolkit scanned more than 12,300 unique addresses.
The purpose was straightforward: identify Dahua devices and attempt authentication against them.
Automated credential attacks remain effective against surveillance systems because cameras are frequently installed and forgotten. Administrators may change the password once, but the device can remain exposed to the internet for years.
Older cameras can be especially dangerous because their firmware may never receive the same level of attention as computers, smartphones, or servers.
A Persistent Backdoor Was Even More Dangerous
The operation also contained an authentication-bypass chain associated with two Dahua vulnerabilities from 2021.
According to the recovered data, this technique resulted in a persistent account known as p2pwn being placed on 1,923 cameras.
The significance of this account is persistence.
Changing the administrator password does not necessarily remove a separate unauthorized account. More concerning, the reported behavior indicates that the account could survive password changes and, on most affected firmware, even a factory reset.
That transforms a temporary compromise into something much harder to eradicate.
The Cloud Relay Problem
The most troubling component of Operation CameraSwarm may not have involved scanning IP addresses at all.
Researchers found that the attacker could reach cameras through Dahua’s cloud-based P2P relay infrastructure using device serial numbers.
This changes the traditional model of camera exposure.
A camera does not necessarily need to have an openly reachable public IP address to become interesting to an attacker. If a cloud relay can locate and connect to the device, network address translation is no longer the same protection many administrators assume it is.
Serial Numbers Became Attack Infrastructure
The recovered toolkit included mechanisms for harvesting camera serial numbers.
That makes the serial number more than an ordinary inventory identifier.
According to
That statistic is particularly alarming because it suggests that the attacker could discover potential targets without first compromising the local network containing the camera.
Authentication Was Not the Whole Story
There is an important qualification.
Reaching a camera through the relay does not automatically mean the attacker has unrestricted administrative control. Full administrative access can still require credentials or another authentication bypass.
However, the recovered telemetry reportedly suggested that many exposed devices did not require the final escalation step to become useful to the attacker.
This distinction is important when evaluating the incident. “Reachable” does not always mean “fully compromised,” but unauthorized remote reachability is still a serious security weakness.
The Recovery-Code Mechanism
Perhaps the most consequential discovery was an offline recovery-code generator.
The tool reportedly needed only a live camera serial number to derive a code used in Dahua’s cloud-level account-recovery process.
That creates a fundamentally different security problem.
If a malicious actor can derive a recovery mechanism without possessing the camera’s existing credentials, removing an unauthorized local account may not be enough.
Changing the device password may not be enough.
Resetting the camera may not be enough.
The underlying recovery mechanism itself would need to be changed by the vendor.
Why Factory Reset May Not Be a Complete Solution
Factory resets are often treated as the ultimate response to a compromised IoT device.
But a factory reset only works as intended when every persistence mechanism is actually erased.
If an attacker can regain access through a cloud-side mechanism, a deterministic recovery process, or another weakness outside the local configuration, resetting the hardware does not solve the underlying problem.
This is one of the biggest lessons from CameraSwarm.
The CVE References Need Careful Interpretation
Hunt.io also identified inaccuracies in some of the CVE references associated with the recovered toolkit.
The persistent-backdoor technique was linked in the toolkit to CVE-2024-39943, but that CVE actually concerns a command-injection vulnerability in Rejetto’s HTTP File Server rather than the Dahua technique described.
The relay abuse was also reportedly associated with CVE-2025-31702, although Dahua describes that vulnerability as a narrower authenticated privilege-escalation issue.
These differences are not merely academic.
Why Incorrect CVEs Can Hurt Defenders
Security teams often build remediation plans around vulnerability identifiers.
If an incident report points administrators toward the wrong CVE, defenders may patch the wrong product, search for the wrong indicators, or incorrectly conclude that their devices are protected.
CVE numbers should therefore be treated as identifiers requiring verification, not as unquestionable descriptions of an attack technique.
The underlying behavior should always be compared with the vendor advisory and affected firmware versions.
A Separate Windows Stealer Was Found
The exposed infrastructure contained another dangerous component that appears unrelated to the camera campaign itself.
Hunt.io discovered a UPX-packed Windows binary identified as SalatStealer.
The same server also contained a PowerShell script designed to disable Microsoft Defender through multiple mechanisms.
Researchers reportedly found five different Defender-disabling techniques, including a Group Policy modification designed to survive reboots and security updates.
Shared Infrastructure Does Not Mean Shared Campaign
It would be tempting to assume that the Windows stealer was another part of Operation CameraSwarm.
The evidence reportedly points elsewhere.
Hunt.io treated the stealer as a separate capability hosted on the same infrastructure rather than a direct component of the camera operation.
That distinction is important because attackers frequently reuse servers for multiple campaigns.
An exposed server can therefore reveal more than one operation, but the presence of multiple malware families does not automatically establish that they were created by the same attacker.
The Toolkit Was Mostly Reassembled, Not Invented
Another fascinating aspect of the investigation is the apparent origin of the tools.
The operator did not build every component from scratch.
Instead, researchers traced different pieces to multiple public repositories and developers.
At least six other developers appear to have contributed code that eventually found its way into the toolkit.
The operator then modified, patched, combined, and rewrote those components.
A Multilingual Code Trail
The code reportedly contained Russian comments layered over Spanish-language source material.
One component was recovered in three different stages of rewriting.
For researchers, these remnants can become valuable attribution clues.
Language artifacts, variable names, comments, copied functions, repository structures, and unusual implementation decisions can all help investigators understand how malicious tooling evolves.
Attackers may remove obvious identifiers, but inherited code often leaves fingerprints behind.
Stored Passwords Were Also Recoverable
The toolkit reportedly included functionality capable of recovering stored device passwords.
The recovery process derived a decryption key from information already available to the attacker, including the device class prefix and serial number.
According to Hunt.io, the routine did not require a secret stored exclusively on the camera.
That makes device identifiers considerably more sensitive than many organizations may realize.
OEM Brands Could Also Be Relevant
The problem may extend beyond cameras carrying the Dahua name.
Dahua technology and backend infrastructure have historically appeared across various OEM and rebranded surveillance products.
The original report specifically warns operators of systems associated with brands such as Amcrest, Lorex, Annke, and Swann to determine whether their equipment relies on affected Dahua technology or backend services.
The important point is not the brand printed on the front of the camera.
It is the underlying platform, firmware, cloud service, and authentication architecture.
What Camera Owners Should Do Now
Owners and administrators of potentially affected equipment should begin with an inventory.
Identify every Dahua-based camera, recorder, NVR, and related surveillance appliance.
Then determine the exact model, firmware version, network exposure, cloud/P2P configuration, and administrative accounts.
Remove Unauthorized Accounts
Administrators should check for unexpected accounts, including the reported p2pwn account.
Any account that cannot be positively explained should be treated as suspicious.
However, simply deleting the account should not be considered the end of the investigation.
Disable P2P Where It Is Not Required
If remote cloud connectivity is unnecessary, administrators should consider disabling P2P functionality.
Reducing unnecessary remote-access pathways is one of the simplest ways to shrink the attack surface of an IoT deployment.
A camera that only needs to communicate with an internal recording system does not necessarily need a globally accessible cloud relay.
Update Firmware
Affected devices should be updated to firmware versions that address the relevant authentication vulnerabilities.
Because CVE references in the recovered toolkit may be inaccurate, administrators should verify fixes against official vendor advisories and the exact camera model.
Rotate Credentials
Credentials stored or previously used by compromised cameras should be considered potentially exposed.
That includes:
Camera administrator passwords
NVR credentials
Cloud accounts
Service accounts
Remote-access credentials
Shared passwords used across multiple devices
Passwords should not be reused between cameras.
Investigate the Network
A compromised camera should not be treated as an isolated appliance.
Surveillance devices often exist on networks containing NVRs, workstations, storage systems, building-management equipment, and other IoT devices.
Network segmentation can prevent a compromised camera from becoming a stepping stone into more valuable systems.
Deep Analysis: How Defenders Can Investigate CameraSwarm-Like Activity
Start With Device Inventory
The first command in an investigation should often be an inventory command rather than an exploitation test.
For Linux-based network management systems, administrators can review known devices with:
ip neigh
For a broader local network inventory, use an authorized asset-management or network-discovery platform.
Check Listening Services
On Linux systems, administrators can review locally exposed services with:
ss -tulpen
This does not identify every vulnerable camera remotely, but it helps determine whether a monitoring or management host is unexpectedly exposing services.
Search Firewall Logs
Look for unusual outbound connections from camera VLANs:
grep -Ei 'camera|dahua|p2p|nvr' /var/log/ 2>/dev/null
Log locations differ between Linux distributions, appliances, and centralized logging platforms, so SIEM telemetry is preferable when available.
Look for Unexpected Internet Traffic
A surveillance VLAN should have a relatively predictable communication profile.
Unexpected outbound connections to unfamiliar infrastructure deserve investigation, especially when they originate from devices that normally communicate only with an NVR or approved cloud endpoint.
Examine DNS Requests
Repeated DNS requests from cameras can be useful indicators.
For example:
tcpdump -ni any port 53
This is a monitoring command, not an exploitation technique.
Use it only on networks you administer.
Monitor Authentication Failures
Repeated authentication attempts against cameras may indicate automated credential attacks.
A SIEM query can be structured around:
source_device = camera AND authentication = failed AND count > threshold
The exact syntax depends on the logging platform.
Search for Unexpected Accounts
Administrators should compare every device account against the organization’s approved configuration.
For Linux-based systems, a basic local account review is:
cat /etc/passwd
Dahua appliances do not necessarily use a conventional Linux account structure, so this command should not be interpreted as a universal Dahua detection method.
The broader principle is to compare device configuration against a known-good baseline.
Preserve Evidence Before Resetting
If a camera appears compromised, immediately performing a factory reset can destroy valuable evidence.
Where possible, preserve:
Configuration data
Logs
Account information
Firmware version
Network telemetry
DNS history
Firewall records
Cloud-access records
NVR logs
Then isolate the device from sensitive networks.
Segment Surveillance Systems
A strong architecture places cameras into dedicated VLANs.
For example:
Internet
|
Firewall
|
+–+-+
| |
Camera VLAN User VLAN
| |
Cameras PCs
NVR Servers
The camera VLAN should have only the outbound and east-west connectivity that is genuinely required.
Block Unnecessary Outbound Access
Where operationally possible, surveillance devices should not have unrestricted outbound internet access.
A firewall policy can allow only approved destinations and services.
This reduces the usefulness of a compromised camera as command-and-control infrastructure.
Hunt for Persistence
Security teams should search device configurations for accounts, services, scheduled tasks, or other settings that do not belong.
The goal is not merely to determine whether the original malware is present.
The goal is to determine whether the attacker left a mechanism for returning.
Validate Factory Reset Claims
A reset should be tested against the
After resetting and updating a device, administrators should verify:
Unauthorized accounts are gone.
Old credentials no longer work.
P2P settings match policy.
Firmware is current.
Cloud access is expected.
Administrative credentials have been rotated.
Network traffic matches the baseline.
Monitor After Remediation
A cleaned camera should remain under observation.
Attackers sometimes return to compromised infrastructure after administrators believe the incident is finished.
Monitoring for several weeks can reveal whether unauthorized traffic or authentication attempts continue.
What Undercode Say:
The Real Vulnerability Is Bigger Than One Camera
Operation CameraSwarm demonstrates that IoT security problems rarely remain confined to a single device.
Scale Changes Everything
A vulnerable camera becomes far more dangerous when an attacker has automation capable of discovering thousands of similar devices.
Cloud Changes the Attack Surface
Traditional network security often focuses on public IP exposure.
Cloud relay systems complicate that model because a device can become remotely reachable without appearing directly exposed on the internet.
Serial Numbers Can Become Security Tokens
Device identifiers are often printed on boxes, labels, invoices, and management dashboards.
Treating them as harmless metadata can become dangerous when backend systems use them to facilitate authentication or recovery.
Persistence Is the Critical Issue
A temporary compromise is serious.
A compromise that survives password changes is much worse.
A compromise that can survive factory resets or cloud-level recovery mechanisms is worse still.
IoT Devices Are Frequently Forgotten
Organizations tend to patch laptops and servers first.
Cameras, printers, routers, access-control systems, and other appliances often receive far less attention.
Attackers know this.
Security by Brand Is Not Enough
Buying a reputable brand does not automatically create a secure deployment.
The real security boundary includes firmware, cloud architecture, APIs, default configuration, update practices, authentication, and network segmentation.
OEM Relationships Matter
A device can carry a completely different commercial brand while sharing components or backend services with another vendor.
Security teams should therefore inventory technology by platform and firmware, not simply by logo.
Public Code Cuts Both Ways
Open-source code allows legitimate developers to build products faster.
It also gives attackers an enormous library of reusable components.
The CameraSwarm toolkit illustrates how a criminal operator can combine publicly available tools into a specialized attack platform.
Reuse Leaves Fingerprints
Code comments, languages, implementation patterns, copied functions, and debugging artifacts can help researchers connect different stages of an operation.
Attackers who modify public tools may still inherit traces of the original developers.
CVE Accuracy Matters
A wrong vulnerability identifier can produce the wrong remediation.
Security reporting should distinguish between a technique, its technical root cause, and the CVE officially assigned to the vulnerability.
Factory Reset Is Not Magic
Resetting a device is useful, but it should not automatically be considered a complete incident-response strategy.
Cloud dependencies can survive local remediation.
Password Rotation Is Still Essential
Even if a persistent mechanism is removed, credentials may already have been harvested.
Every credential associated with an affected device should therefore be reviewed and rotated.
Network Segmentation Is One of the Best Defenses
If a camera becomes compromised, segmentation can prevent it from reaching systems that matter more.
The security architecture should assume that individual IoT devices can eventually fail.
Surveillance Cameras Deserve Enterprise-Level Security
Cameras are not just passive video devices.
Modern cameras contain processors, operating systems, storage, network services, cloud integrations, and credentials.
They should be managed like computers.
The Cloud Relay Deserves Special Attention
Organizations frequently concentrate on firmware vulnerabilities while overlooking cloud architecture.
But a cloud relay can become an enormous centralized attack surface.
Recovery Mechanisms Need Threat Modeling
Password recovery systems should be designed with the assumption that identifiers can become public.
A recovery process based primarily on predictable device information is fundamentally risky.
Attackers Are Becoming More Efficient
The most important aspect of CameraSwarm may not be any individual vulnerability.
It is the automation connecting reconnaissance, exploitation, credential collection, persistence, and remote access.
Scale Makes Small Weaknesses Dangerous
A weakness affecting one device may appear manageable.
A weakness affecting millions of similar devices can become a systemic security problem.
Defenders Need Better Asset Visibility
Organizations cannot patch what they do not know they own.
Camera inventories should include model, firmware, serial number, network location, cloud dependency, and administrative ownership.
IoT Security Must Include Decommissioning
Old cameras often remain online long after their original purpose disappears.
Unused equipment should be removed from networks rather than simply forgotten.
Vulnerability Management Should Include Appliances
Patch programs that cover only Windows, macOS, Linux, and mobile devices are incomplete.
Routers, cameras, NVRs, printers, and access-control systems belong in the same vulnerability-management conversation.
Incident Response Must Include Cloud Services
A compromised endpoint may be clean locally while its associated cloud account remains exposed.
Investigations should therefore examine both device and cloud-side activity.
The Exposed Directory Was a Major Intelligence Failure
The attacker had apparently invested in automation and tooling but left the directory publicly accessible.
Operational security failures can undo sophisticated technical work in seconds.
Attack Infrastructure Is Evidence
The leaked server gave researchers access to tooling, logs, comments, binaries, and development artifacts.
That makes infrastructure monitoring an important part of threat intelligence.
Defenders Should Learn From the
The same way attackers automate reconnaissance, defenders can automate detection.
Unusual authentication patterns, repeated serial-number queries, unexpected cloud connections, and unauthorized accounts can become detection signals.
Camera Security Is Now Part of Cybersecurity
The era when cameras were considered isolated hardware is over.
Connected surveillance equipment is part of the
The Biggest Lesson
The most dangerous vulnerability may not be the one with the highest CVSS score.
It may be the combination of an exposed device, weak authentication, predictable recovery logic, cloud connectivity, and automated exploitation.
Security Must Be Designed Around Failure
Organizations should assume that individual cameras will eventually be compromised.
The objective is to make sure one compromised camera does not become the first domino in a much larger breach.
Prediction
(+1) Camera Networks Will Receive More Security Attention
The scale of Operation CameraSwarm is likely to push organizations toward treating surveillance infrastructure as a formal part of cybersecurity programs rather than merely physical-security equipment.
(+1) Network Segmentation Will Become Standard
More companies are likely to isolate cameras, NVRs, and IoT devices from employee and server networks, limiting the damage that follows a compromise.
(+1) Cloud Relay Security Will Face Greater Scrutiny
Security researchers are likely to investigate vendor-operated P2P and relay architectures more aggressively, especially where device identifiers influence access.
(+1) Firmware Inventory Will Become More Important
Organizations will increasingly track firmware versions alongside traditional software inventories.
(-1) Legacy Cameras Will Remain a Long-Term Risk
Older surveillance systems are unlikely to disappear quickly.
Many organizations will continue operating equipment that was designed before today’s cloud and IoT threat environment existed.
(-1) Attackers Will Continue Targeting Forgotten Devices
As traditional endpoints become better protected, attackers are likely to continue looking for overlooked cameras, routers, DVRs, printers, and other connected appliances.
✅ The Campaign Was Reconstructed From Exposed Infrastructure
Hunt.io’s investigation describes an exposed directory containing thousands of files and multiple components associated with the camera operation. The accidental exposure was central to reconstructing the campaign.
✅ The Operation Used Multiple Access Paths
The recovered tooling reportedly included brute-force scanning, an authentication-bypass mechanism, and a serial-number-based cloud relay path. This makes the campaign considerably more sophisticated than a simple password attack.
⚠️ Some CVE References Require Correction
The reported association between the recovered techniques and CVE-2024-39943 and CVE-2025-31702 should not be accepted without verification. Hunt.io itself identified problems with those references, highlighting why defenders should validate vulnerability identifiers against vendor documentation.
✅ The Windows Stealer Appears To Be Separate
The SalatStealer binary and Defender-disabling PowerShell tooling were found on the same infrastructure, but the investigation treats them as a separate capability rather than automatically attributing them to the CameraSwarm campaign.
⚠️ Exposure Does Not Automatically Mean Full Administrative Compromise
A camera being reachable through a relay is not identical to obtaining complete administrative control. The distinction between unauthorized reachability, authentication, privilege escalation, and persistent compromise is important when interpreting the reported numbers.
✅ The Broader Security Lesson Is Clear
Whether every individual technical detail ultimately survives further investigation or not, the campaign demonstrates a serious problem in connected-camera security: automated discovery, weak authentication, cloud dependencies, and persistent access mechanisms can combine to create a much larger threat than any single vulnerability suggests.
▶️ Related Video (78% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: securityaffairs.com
Extra Source Hub (Possible Sources for article):
https://www.quora.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
