How to Detect Malicious Use of Your Own Remote-Access Tools

A remote-access tool that has been turned against you does not announce itself. The sessions look normal, the file transfers look like support work, and the processes it spawns carry the tool's own trusted name. That is precisely the problem the ScreenConnect wormWorm🛡️Malware that spreads on its own from one system to the next without a user launching it each time, typically by abusing a network service, shared credential, or trusted management channel. A worm's self-propagation is what makes containment, not cleanup, the first response priority. activity exposed: attackers used the product's legitimate features, so the malicious behavior hid inside ordinary-looking telemetry. Detecting that abuse is a learnable skill, and this guide walks through where to look and what should make you suspicious.

The context here is CVE-2026-84869, the ScreenConnect file-transfer flaw that let a session participant execute code on a connected machine without confirmation. Even after you patch, you need to know whether the tool was misused before the fix landed, and you need standing detection so the next abuse does not go unseen.

Start With the Tool's Own Audit Log

The most valuable data source for detecting misuse of a remote-access product is the product's own session and audit log. These tools record who connected, what was transferred, and what was executed. Attackers rely on you not reading them.

Look first for execution actions. A file being transferred is routine; a file being transferred and then run is the behavior the ScreenConnect flaw enabled, and it is the highest-signal event in the log. In ScreenConnect specifically, Huntress advised treating file-run actions initiated by the guest side of a session as suspicious, because a legitimate technician on the host side is the party who normally drives execution. The exact field names differ by product, but the principle carries: a run action attributed to the wrong participant, or one you cannot tie to a known support ticket, deserves investigation.

Correlate the log with time. Support activity clusters around business hours and known engagements. Execution events at odd times, or on machines nobody was scheduled to service, stand out once you have a baseline. Building that baseline is the unglamorous work that makes everything after it faster.

Watch What the Session Spawns on the Endpoint

Audit logs tell you what the tool did; endpoint telemetry tells you what happened next. The two together are far stronger than either alone.

The clearest endpoint signal is an unexpected process lineageProcess Lineage🛡️The parent-child chain of processes on a host, showing which process launched which. Hunting on lineage catches exploitation because compromised services spawn children they never would in normal operation.. When a remote-access client spawns a scripting engine, the Windows Script Host or PowerShell, and that engine in turn launches other processes, you are looking at the exact pattern the ScreenConnect loader used. Legitimate support does this sometimes, so the goal is not to alert on every instance but to know your normal and flag the deviations: a script host launched by the remote-access client on a machine that never runs scripts, a PowerShell process reaching out to a cloud file-sharing service, a chain that ends in an installer.

Persistence is the next place to look. The ScreenConnect campaign established itself through a registry Run key so its loader survived reboot. New autorun entries created shortly after a remote session, especially ones with generic or service-sounding names, are worth chasing. So are scheduled tasks and newly installed services that appear around the same window.

Finally, watch for masquerading. Attackers in this campaign renamed a tunneling proxy and a cryptocurrency miner to resemble ordinary Windows binaries. A process whose name matches a system utility but whose path, signature, or network behavior does not is a reliable tell. This overlaps with the broader discipline of authorization abuse we cover in how attackers turn a trusted file-transfer feature into a malware delivery channel, because the malicious binaries arrive through exactly that channel.

Hunt for the Foothold and the Spread

Detection is not only about catching the moment of execution. You also want to find footholds that are already established and, critically, to understand whether the compromise has spread.

For footholds, inventory your remote-access installations and compare them against what should be there. Rogue or unexpected instances of the client, especially user-level installs the campaign favored, are a strong indicator. Unknown relay or server addresses in a client's configuration are another; a legitimate deployment phones home to known infrastructure, and a rogue one does not.

For spread, remember that these tools can propagate. Because the ScreenConnect flaw let one infected host push payloads to every machine that connected to it, a single detection is a reason to check every endpoint that touched the same session infrastructure, not just the one that alerted. The instinct to scope outward from the first hit is what separates a contained incident from a prolonged one, and it is the reasoning behind why self-propagating malware forces you to contain before you clean.

Turn Detection Into Standing Coverage

One-time hunts find yesterday's compromise; standing detection finds tomorrow's. Convert what you learn into durable rules.

Forward the remote-access tool's audit logs into whatever platform your team already watches, so session and execution events sit alongside your other telemetry instead of in an isolated console nobody opens. Write detections for the patterns above: guest-initiated execution, remote-access clients spawning script hosts, script hosts contacting file-sharing services, new autoruns after sessions, and processes masquerading as system binaries. Alert on unexpected new installs of the client itself.

Then validate the coverage the way you would any control. Run a benign test that mimics the suspicious pattern, confirm it fires, and tune the noise down without tuning the signal out. The teams that detected the ScreenConnect activity early were the ones already treating their remote-access tooling as monitored, privileged infrastructure rather than a convenience that lives outside the security stack. That posture is what this incident, and the next one like it, rewards.