Attackers have used compromised camera management software to deploy malware on Windows systems, leveraging a legitimate Microsoft program to execute malicious code and maintain persistence.
These incidents illustrate how surveillance-management tools can become entry points into corporate networks. In each observed case, adversaries accessed the camera application, deployed a suspected reverse shell, and used DLL sideloading to contact an external command-and-control server.
As with other prior incidents that abused monitoring tools, this activity underscores the risks posed by software trusted for routine operations.
Researchers at Huntress observed this activity across multiple customer environments during September and October 2026.
Hackers Compromise Camera Management Software
The affected camera management application lacked embedded file version information, preventing researchers from confirming the product’s full name or its developer.
Investigators were also unable to locate application logs, so the precise method used to compromise the software remains unclear. The report does not identify a specific vulnerability or CVE.
Researchers found strings in the executable that referenced a domain tied to the Korean company 3R Global, and a camera management package available on another site contained matching strings. Huntress emphasized that these overlaps do not prove the vendor’s identity or establish where customers obtained the software.
After gaining access, attackers dropped an executable into a user’s application data directory. Its command line included a remote address, a connection port, and authentication values. Because the file resided in a writable folder and accepted remote parameters, researchers assessed it as a reverse shell. The attackers then copied the Windows Parental Control Monitor executable (WpcMon.exe) into another application data folder.
Huntress verified that the Parental Control Monitor file was a genuine Microsoft binary, but its atypical location revealed the abuse. This mirrors previous VLC and VMware sideloading cases that show a trusted executable alone does not guarantee the safety of nearby libraries.
In these incidents, the Microsoft executable loaded malicious DLLs placed alongside it. Those libraries resembled legitimate zlib compression components but were modified to periodically contact a command-and-control server. This DLL sideloading technique allows attackers to run their code through an otherwise legitimate application.
That distinction is important: the executable itself was not the malicious payload but a loader that loaded attacker-controlled libraries from the same folder. Checking the Microsoft file’s digital identity without examining its location, the DLLs it loaded, its parent process, and its network activity would omit key evidence that linked a seemingly normal Windows component to the broader compromise.
Persistence, Detection, and Defensive Priorities
Attackers achieved persistence by adding the relocated Microsoft executable to the user’s Run registry key so Windows would launch it each time the user signed in, reestablishing the loading chain.
All investigated incidents communicated with the same command-and-control IP address (listed below). For defenders, the most actionable signal is the connected sequence of events rather than any single filename.
Camera software launching an unexpected executable, followed by a Microsoft component running from a writable folder and making unusual outbound connections, deserves investigation. Huntress specifically recommends examining that process chain.
Organizations should inventory camera management applications, restrict access, and monitor their network activity. Earlier EggStreme DLL sideloading attacks also abused a Windows executable from an application data folder, reinforcing the value of verifying execution locations.
Where feasible, Huntress recommends application controls that block unapproved executables and DLLs in user-writable directories. The investigation also highlights limits on attribution: Huntress did not determine how the initial camera-software compromise occurred, and the available evidence does not justify calling this a confirmed vendor supply-chain breach.
The immediate, narrower lesson is clear: camera management applications require the same endpoint oversight and monitoring as other business software and should not be overlooked.
Indicators of Compromise (IoCs)
| Type | Indicator | Context |
|---|---|---|
| SHA256 | 1fb4af4862643dcab1459872f723f574f1a588855b020916b600df5c20681144 |
rs.win32.exe; suspected reverse shell |
| SHA256 | 8f8e88c54a9c56174974711eff99b4beb79536642fcca1902acdc3d4b1fd1035 |
Malicious samcli.dll |
| SHA256 | 70b2345302264c41504d59e6a63d6d908969740424b42b7373f10b4c8d74c87a |
Malicious IPHLPAPI.DLL |
| C2 address | 144.172.116[.]37 |
Shared across observed incidents |
| Application path | C:Program Files (x86)CMSCMS.exe |
Initial application; context required |
| Staging directory | C:Users<user>AppDataRoamingCMSRemoteSetup |
Dropped reverse shell location |
| Sideloading directory | C:Users<user>AppDataLocalMicrosoftWpcMon |
Relocated WpcMon.exe loading location |
| Execution parameters | -p "8000"; "admin"; "1234567a7654321" |
Observed port and authentication values |
| Embedded strings | developerslavery; d3e3v4e3l9o9p0e3r4s2l9a1v4e3r4y6 |
Software identification clues only |
| Embedded URL | hxxp://cloudapi.3r-dataware[.]com/sso/ |
Software provenance clue; not confirmed C2 |
| Related domains | 3r-dataware[.]com; kvision[.]ai |
Investigative context, not confirmed malicious |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Give your SOC the alert context to stop incidents quickly. Integrate threat intelligence from 16K SOCs.
