Cisco Talos maps RMM, decoys and agent controls to disrupt attackers

Warlock ransomware used Zoho Unattended Agent, a legitimate remote-support tool that can give a technician elevated access even when the signed-in user lacks administrator rights. In an October 1 discussion, Cisco Talos asks how defenders can interrupt an attacker’s next move. On remote-managed endpoints, privileged Windows hosts and connected AI agents, check what each session can reach and how your team can stop it.

Talos asked eight researchers for one way to frustrate an adversary and the next step it would prevent. Their answers span decoy accounts, credential-access detection, approved remote tools and per-session controls for agents. Test whether your team can distinguish an approved support session from a new persistent access route.

Remote tools hide in routine support

A remote monitoring and management (RMM) agent gives a technician interactive control of a machine. The same session can give an intruder a durable foothold. MITRE ATT&CK’s remote-access-tools entry describes agents that establish interactive command-and-control, persist through a service and maintain an outbound connection. Its detection strategy follows the sequence from agent execution to persistence and interactive child processes. A product name alone is a weak alarm when your help desk uses that product every day.

Talos recommends listing the RMM products actually approved for your environment, then using application controls such as Windows Defender Application Control, AppLocker or an EDR policy to block or strongly alert on unapproved ones. Check the inventory against installed agents, service creation and sustained outbound sessions. Treat a new agent that launches a shell or file manager on a system outside the support roster as a triage lead, and reconcile it with an authorized ticket. MITRE also recommends limiting outbound access to remote-access services where those routes are unnecessary.

Zoho Unattended Agent is legitimate software that Talos says Warlock abused. Removing an unapproved remote-control path forces a different route to persistence; investigate any other access the attacker established.

Decoy accounts expose an early touch

Talos researcher Martin suggests honeypot email addresses on expired domains that had previously leaked, or fictional staff profiles seeded where spammers are likely to find them. An address with no employee behind it has a clean baseline. An inbound lure there can give defenders early warning and infrastructure to investigate before a message reaches real staff. Nick extends the same idea to false servers, shares, accounts and network space, where a connection gives the team an unusual signal.

Keep these accounts separate from production identities and route their inbound mail or authentication activity to an alert queue. Verify that test mail to a decoy creates an alert tied to that address, then review real hits for lures and sender infrastructure before changing filters for employees. A decoy is a tripwire for interaction with that decoy; your ordinary mailbox and sign-in detections still cover paths that pass it by.

Credential access survives a tool swap

“Attackers have enormous flexibility in how they operate, but far less flexibility in what they ultimately need to accomplish,” Talos researcher Ryan says. He uses Windows credential theft as an example: a rule keyed only to Mimikatz misses other implementations that seek the same credential material. Talos calls for behavior-based analytics that survive changes in tooling, syntax and obfuscation.

MITRE’s LSASS memory entry describes an analytic for abnormal process access to lsass.exe followed by a memory dump or suspicious file creation. That gives a Windows team a concrete chain to hunt: the process opening LSASS, its access level, a dump-like file and the account under which the sequence ran. Establish which administrative and security tools normally touch LSASS before escalating unusual access. On supported hosts, assess the applicable LSASS protections alongside the detection; MITRE notes that Credential Guard has platform requirements and covers only some credential-dumping paths.

Agent sessions need a stop switch

Connected AI agents add another place where an apparently legitimate tool can reach an unintended destination. Talos researcher David recommends a separate identity and short-lived credentials for each run, traffic through an independent egress control, and explicit limits on access to cloud metadata, Kubernetes interfaces and other sensitive systems. He puts it plainly: “make every agent session identifiable, restricted, and interruptible.”

Tie each session ID to its credentials and egress records. Watch for unexpected package-registry or dataset writes, repository creation, Kubernetes API calls and credential discovery followed by cross-account activity, the behaviors Talos names. Revoke the individual run’s credentials and cut its egress path during a controlled test; then confirm the run loses access while approved runs continue. A domain blocklist alone is a poor substitute for a session identity when an agent changes destinations or uses a public relay.

Make the next move observable

Start with your approved RMM roster and enforce it on endpoints; compare installed agents, new services and outbound remote-support connections against the tickets that authorize them. Give a decoy mailbox its own alert route, and build a Windows credential-access analytic around abnormal LSASS access followed by dump activity rather than a single tool name. For agents, issue per-run credentials and practice revoking one run at the egress control. A quiet decoy covers only its own address, and a sanctioned RMM agent still needs session-level review.

An attacker may find another account or another tool. Watch for that replacement while your team still has time to interrupt it.