Claude & Control: An Introduction to Agentic C2 with Computer Use Agents

As a cloud security researcher, I'll admit that AI security is relatively new territory for me. The field already moves quickly under normal circumstances, but AI has accelerated that pace dramatically and fundamentally changed how we approach problems as security researchers.

As I started getting up to speed, I dug through documentation from some of the major AI platforms—Anthropic, OpenAI, and Google—and came across references to something called a 'computer use' agent. Once I understood how it worked, I realized it was possible to build a surprisingly simple agentic command and control (C2) framework around it. This framework is what I'm calling Claude and Control.

Security research on any new technology usually comes down to three questions:

• How does it work?
• How can it be abused?
• How do we defend against it?

Before jumping into computer use agents, there’s some terminology to quickly cover:

1. Agent: In this context (distinct from C2 terminology), an agent is an autonomous software system that uses a large language model (LLM) to perceive its environment, reason about goals, and take actions in a loop, all without requiring step-by-step human instruction.
2. Tool: A capability exposed to the LLM that it can invoke during its reasoning loop. Examples include taking a screenshot, executing a shell command, or clicking a screen coordinate.
3. Implant: The software running on the target machine that executes the agent's tool calls and returns the results back to the agent.

In short, a computer use tool allows an agent to interact with the desktop environment by moving the cursor through screen coordinates and button inputs. Anthropic, Google, Microsoft, and several other AI vendors have agent capabilities that utilize “computer use tool” (CUT). OpenAI provides a similar capability through a specialized model they refer to as operator , which is their “computer use agent” (CUA). The distinction comes down to how the capability is used. If it operates in a loop, reasoning and executing multiple steps to complete a task, then the tool functions agentically, making it an agent. If it is only invoked once, it is a tool. This is a slight oversimplification, but for the purpose of this article, we’ll be focusing on how the agent utilizes the tool.

Computer use tool operates in the following order:

1. A screenshot is sent to the agent.
2. The agent analyzes the screenshot’s resolution, elements, OS
3. The agent issues commands back to the machine to move the cursor to a certain location and send a button input.

To be clear, the ability to programmatically control the cursor and issue button input isn’t new. However, coupling this capability with AI reasoning makes it significantly more usable and powerful.

There are many ways a CUA can be used for abuse, but here are some reasons why an attacker would choose use agentic-based implants over traditional C2 implants:

1. Minimized API Footprint: Instead of packing a binary with multiple Windows APIs that might be flagged for malice, a CUA uses:

• SetCursorPos(x, y) - Sets the cursor position
• SendInput() - Sends keyboard input
• VkKeyScanW() - To maps characters to virtual key codes
• GetSystemMetrics() - To scale coordinates for different screen resolutions

Since these are native to user32.dll and kernel32.dll, no third-party input libraries are required. In my testing, this approach generated no alerts from Microsoft Defender for Endpoint (MDE) or CrowdStrike.

2. Bypassing EDR Triggers: Interacting with a browser via the terminal can be tedious. Having to scrape DPAPI keys to decrypt browser secrets can also set off EDRs. A CUA can simply view sensitive data in a screenshot.

3. Circumventing Data Loss Prevention (DLP): Extracting sensitive data from documents on an endpoint can trigger DLP or network-based detections. A screenshot of those files increases the likeliness of circumventing those detections.

4. All communication occurs over trusted domains: In Claude & Controls example, all communication happens over Azure Function Apps. With the remote-control feature in Claude, all communication happens over Anthropic’s domains, meaning these domains will be trusted in basically every network and not raise suspicious when traffic is flowing to or from them.

Agentic implants are not without their faults. There are several limitations, such as:

1. Interactive Session Dependency: Because CUA relies on the SetCursorPos and SendInput Windows APIs, it requires an initial interactive session to interact with the desktop. After establishing connection, there are registry keys and services that can be made to keep the session persistent if the user locks their machine or closes their session.
   1. Filesystem tool, as mentioned in the next section, does not require an interactive session.
      
2. Agent Fallibility: Agents make mistakes. We’ve seen in testing that the model occasionally mistakes the Explorer icon for Copilot or closes out the implant’s execution window by accident. Typically, the agent can recover, but it does so at the expense of time, operational security, and tokens.
   
3. Resource Intensity: Agentic implants are token-intensive. Using the Claude Haiku model equated to roughly $.01 to $.05 worth of tokens for a task such as checking the password manager’s passwords. Claude Sonnet usage resulted in triple those values.
   
4. User Account Control (UAC) Restrictions: UAC still prevents elevation in some cases.

Detecting AI tool abuse isn’t fundamentally different from detecting human activity. AI agents don’t use special APIs as they rely on the same system mechanisms as any other program. However, there are challenges in detecting CUA activity abuse because cursor movements and activity do not generate events.

It is possible to get visibility into this behavior by monitoring the following API calls, as shown in figure 8.

This requires hooking into the DLL functions and intercept calls to the APIs themselves, which is not a trivial task. An alternative approach for detecting abuse is monitoring the events that occur during the staging period of the CUA using Sysmon. These events are:

• Event ID 1 — Process Creation
  • Unsigned binary spawning cmd.exe /c
• Event ID 3 — Network Connection
  • Outbound HTTPS from a non-browser process
• Event ID 7 — Image Load
  • A single process loading user32.dll and gdi32.dll suggests screen capture and input injection from a .NET app
• Event ID 11 — File Create
  • PNG files written to the screenshot’s directory

Filesystem tool abuse is not much different than typical operations. Currently, filesystem tool calls utilize cmd.exe or powershell.exe, which are heavily signatured by every EDR on the market today. Even without an EDR, filesystem tool abuse can be monitored by enabling script-block logging and auditing event ID 4104 (PowerShell) or event ID 4688 (cmd.exe).

The most insightful and important thing I learned during my AI security journey so far is that these systems are not magical. They are powerful tools that can dramatically improve efficiency, but under the hood they still rely on the same mechanisms attackers have been abusing for years. Even when an agentic C2 framework autonomously controls a machine, the underlying telemetry remains largely the same as if a human were performing the actions manually. Ultimately, the effectiveness of an agentic C2 framework depends on the operator. If the operator’s tradecraft is weak, the agent’s behavior will reflect that. AI can automate execution, but it doesn’t automatically improve operational security.

Click here to learn how BeyondTrust’s Identity Security Insights can give you visibility into identity relationships, privileges, and hidden Paths to Privilege™ across your environment—including those introduced by AI agents. Or sign up for the free Identity Security Risk Assessment today.