What happened
Huntress observed a handful of incidents during September and October 2026 that originated from camera management software running as CMS.exe. Huntress published the technical analysis on October 27, 2026. Independent reporting on October 28, 2026 surfaced the campaign and its huntable artefacts to a broader enterprise audience. The cited research did not locate application logs and did not establish how the attackers first compromised the camera management software.
Huntress observed CMS.exe at C:\Program Files (x86)\CMS\CMS.exe, rs.win32.exe under C:\Users<user>\AppData\Roaming\CMS\RemoteSetup\ and WpcMon.exe under C:\Users<user>\AppData\Local\Microsoft\WpcMon. The published reverse-shell command pattern is rs.win32.exe -i “
The published SHA-256 hashes are 1fb4af4862643dcab1459872f723f574f1a588855b020916b600df5c20681144 for rs.win32.exe, 8f8e88c54a9c56174974711eff99b4beb79536642fcca1902acdc3d4b1fd1035 for samcli.dll and 70b2345302264c41504d59e6a63d6d908969740424b42b7373f10b4c8d74c87a for IPHLPAPI.DLL. All observed incidents beaconed to command-and-control IP address 144.172.116[.]37. Huntress says 3r-dataware[.]com and kvision[.]ai indicate a possible source only and do not establish the software vendor.
Attribution posture: Huntress did not attribute the activity to a named threat actor, and the cited sources do not establish the operator’s identity or motive. The cited source did not publish the relevant log evidence described as Application logs and initial-access mechanism.
Why this matters now
Camera-management software is often deployed by physical-security teams, integrators or small-site administrators and may not appear in the normal enterprise software catalogue. That operating model creates weak ownership, uncertain patching, broad network reach and limited logging. Huntress’s observations show that such software can become an entry point into ordinary Windows endpoints and the wider corporate environment.
The campaign is unusually actionable despite the unidentified product and unknown initial-access mechanism. Defenders have filenames, paths, a command pattern, three SHA-256 hashes, a process lineage and one C2 address. Those artefacts support immediate endpoint and network hunting without requiring teams to accept the unconfirmed possible vendor connection.
The unresolved vendor identity changes the response priority. Organisations should inventory the executable by hash, path and signer rather than searching only for a product name. Any positive indicator should trigger incident response and scoping of adjacent camera, recorder, workstation and administrative networks, while a clean hunt should not be represented as proof that the software is safe.
The decision for security leaders
Assign endpoint engineering and physical security a joint inventory task. Discover CMS.exe by path, hash, signer, software inventory and process telemetry; do not wait for a confirmed vendor name. Record which networks, cameras, recorders and administrative credentials each installation can reach.
Convert the published sequence into behavioural detection: CMS.exe launching rs.win32.exe, WpcMon.exe executing from AppData, IPHLPAPI.DLL or samcli.dll beside that binary, Run-key persistence pointing to the abnormal path, and outbound communication with the C2 address. A single indicator should prompt correlation with the complete chain.
Where indicators are found, escalate to incident response before reinstalling or deleting the application. Preserve binaries, registry state, process history, network connections and authentication evidence. Rebuild or return the system only after the owning team can explain the initial-access path and the camera environment has been segmented.
Evidence of closure
- A software inventory identifies the owner, path, hash, signer and network placement of every CMS.exe installation.
- Endpoint and network searches return documented results for every published hash, path and IP indicator.
- Positive systems have preserved forensic evidence and an approved incident disposition.
- Returned systems enforce application control and segmentation validated by technical testing.
The Security.io assessment
This story warrants action because it provides a high-fidelity hunt for a class of software that frequently sits outside mature application governance. The unknown product identity is a limitation, but it also exposes the underlying control failure: organisations may not know which physical-security applications execute on Windows systems or what those applications can reach.
The evidence supports a malware campaign observed across multiple customer environments, not a confirmed supply-chain compromise by a named vendor. Security teams should preserve that distinction. The possible links to 3R Global and Kvision are investigative leads only and must not be converted into vendor culpability or a blanket compromise finding.
No AI system or agent was identified as material to the observed attack chain. No AI-enabled agent or framework was identified in the cited sources. No underlying AI model was identified in the cited sources. No AI operator configuration was identified in the cited sources. A clean indicator search reduces concern but cannot close the unidentified initial-access mechanism.
Questions for the morning meeting
- Where is CMS.exe installed, and can the organisation identify its owner, version and business purpose?
- Can endpoint controls block executables and DLLs from the published user-writable paths?
- Has the C2 address or published malware appeared on any endpoint or network sensor?