Threat intel

Hacked camera software opened a door into company networks

By Yaali. November 2, 2026, 6 min read, Threat intel, Windows, Resilience.

Huntress traced several intrusions to a compromised CCTV management app that dropped a reverse shell and sideloaded DLLs. How to hunt for it and clean up.

Huntress, the managed detection and response provider, investigated a handful of intrusions in September and October 2026 that all started in the same place: a Windows camera management application, CMS.exe, installed under C:\Program Files (x86)\CMS\. In every case the attacker used that program to drop a reverse shell, then hid a beaconing implant behind a genuine Microsoft binary and set it to start at every sign-in. Huntress published the findings on October 27.

Huntress could not identify the vendor or work out how the software was compromised, because it found no logs for the application. That gap is the reason to act now. If any workstation in your estate runs a client for viewing CCTV cameras or managing digital and network video recorders (DVRs and NVRs), check it against the indicators below this week. Those PCs often sit at a guard desk or reception, outside anyone's patching and monitoring routine.

How the attack works

Camera management clients are desktop programs that log in to recorders and cameras across the network so a guard or office manager can watch live feeds and pull footage. They tend to be installed once, left running, and rarely updated or monitored. The CMS.exe that Huntress found carries no File Version Information section, so the usual fields that name the product and publisher are blank.

The first malicious step was a file called rs.win32.exe, written to C:\Users\<user>\AppData\Roaming\CMS\RemoteSetup\ and launched by CMS.exe itself. Its command line passed a remote IP address, port 8000, two file arguments, the username admin and a password value of 1234567a7654321. Huntress assesses it as a reverse shell: a program that connects out from the victim to the attacker, which gets through firewalls that block inbound connections. Because the parent process was the camera software, the new process looked at first glance like part of the application.

The second step was persistence through DLL sideloading. A DLL (dynamic link library) is a code file that a Windows program loads at start-up, and Windows looks for many of them in the program's own folder before it looks in System32. The attacker copied WpcMon.exe, the genuine Windows Parental Controls monitor that normally lives in C:\Windows\System32, into C:\Users\<user>\AppData\Local\Microsoft\WpcMon\. Next to it they placed two DLLs named IPHLPAPI.DLL and samcli.dll, the names of real Windows libraries. The copied WpcMon.exe loads the attacker's versions instead of the system ones.

Both DLLs look like ordinary zlib compression libraries but were modified to call home to a command and control (C2) server at 144.172.116[.]37 on a timer. A value under the user's Run registry key points at the relocated WpcMon.exe, so the implant restarts every time that user signs in. Huntress saw the process tree CMS.exe to rs.win32.exe to WpcMon.exe, which was the first point at which WpcMon.exe appeared on those hosts.

What Huntress knows and what it does not

The same C2 address appeared in every incident, which points to a single operator or toolset. Huntress has not attributed the activity to any group and has not said how many organisations were affected beyond "a handful" of incidents.

Strings inside CMS.exe, including a URL for a cloud single sign-on endpoint, point to a possible South Korean company that sells analog and IP cameras and DVRs and NVRs. A camera software package downloaded from a second site contained the same strings. Huntress is explicit that this overlap does not prove who made the program, how victims obtained it, or whether a vendor was breached. Treat any report calling this a supply chain attack as unconfirmed.

What is known is enough to hunt with. Huntress published SHA-256 hashes for the three malicious files:

• rs.win32.exe: 1fb4af4862643dcab1459872f723f574f1a588855b020916b600df5c20681144
• samcli.dll: 8f8e88c54a9c56174974711eff99b4beb79536642fcca1902acdc3d4b1fd1035
• IPHLPAPI.DLL: 70b2345302264c41504d59e6a63d6d908969740424b42b7373f10b4c8d74c87a

What to do

There is no CVE and no patch, because the flaw that let the attacker in has not been identified. The work is inventory, detection and containment.

1. Find every camera client. Search your software inventory or EDR (endpoint detection and response) for CMS.exe and for any folder named CMS under Program Files or Program Files (x86). Ask facilities and security staff which PCs they use to view cameras, since some will not be enrolled in your EDR.
2. Hunt for the chain. Look for WpcMon.exe running from anywhere other than C:\Windows\System32, for rs.win32.exe under AppData\Roaming\CMS\RemoteSetup\, and for any child process of CMS.exe. In Microsoft Defender for Endpoint, DeviceProcessEvents | where FileName =~ "WpcMon.exe" and not(FolderPath startswith @"C:\Windows\") covers the first case. Search file events for the three hashes above.
3. Check persistence. On each candidate host run Get-ItemProperty HKCU:\Software\Microsoft\Windows\CurrentVersion\Run as each user who signs in there, and look for a value pointing into AppData\Local\Microsoft\WpcMon\.
4. Check the network. Search firewall, proxy and DNS logs for connections to 144.172.116.37 and block it at the perimeter. Outbound connections from a camera client PC to port 8000 on an address that is not one of your recorders also deserve a look.
5. Contain a hit. Isolate the host, then remove the Run value, the WpcMon folder in AppData\Local\Microsoft\ and the RemoteSetup folder. Since the attacker had an interactive shell, a rebuild is safer than cleaning in place.
6. Rotate what the PC could reach. Change the passwords of the Windows account used on that PC, the admin accounts on every camera, DVR and NVR the client was configured to log in to, and any domain account cached on the host.
7. Do not reinstall the same package blindly. Until the source is known, get the client from the camera vendor directly, compare the installer hash with what the vendor publishes, and prefer a version that is code-signed.

Put camera PCs on a leash

The attacker got a foothold through software that most teams never think of as an IT asset. A camera client needs to talk to recorders and, sometimes, a vendor cloud service. It does not need to reach file servers, domain controllers or the open internet on arbitrary ports.

Put camera clients and recorders in their own network segment, allow only the ports the vendor documents, and run the client under a standard user account on a machine that holds no other data. Application control such as Windows Defender Application Control or AppLocker, set to block executables and DLLs in user-writable paths like AppData, would have stopped both rs.win32.exe and the sideloaded DLLs in this campaign.

Our attack surface management work finds forgotten devices and software like camera clients, and our security operations team hunts for chains like this one on endpoints. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: Huntress, Camera Management Software Compromise Leads to Malware Deployment, Help Net Security, Cyber Security News, GBHackers, TechRadar.