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.

When I first read about this relatively new capability, I was immediately intrigued. The first thing I did was write an implant, which contained the code the agent would call to do things like poll for instructions and running its own local AI agent loop (calls Claude API, gets tool decisions back, executes them, loops). The implant in my examples was written in C#, which uses Windows APIs like SetCursorPos or SendInput. Additionally, it could also use the Python package pyautogui, which ends up calling the same APIs.

The delivery mechanism isn’t covered in this post, but for the sake of discussion, let’s assume this implant is already running on the target endpoint. There are two architecture problems to solve:

1. I needed an intermediary to communicate with the implant. Since the entire point of C2 is to command and control remotely, I needed a way to issue instructions to the implant.

2. Most tools require an API key to execute. Embedding that key directly in the implant or storing it as an environment variable on the endpoint was something I wanted to avoid.

For both solutions, I relied on my best friend: Azure. To address the C2 problem, I used an Azure Storage blob container as a dead drop system. I would put the instructions/commands into a text file, and the implant on the target machine would periodically poll the storage blob at a set interval, looking for new instructions. This accomplished two things:

1. Activity would come from Azure, which is inconspicuous network traffic for 99.9% of environments.

2. Using a SAS key, authentication could be built in without exposing the container publicly.

For the API key problem, I chose to use Azure Function Apps as a proxy. Instead of the implant making a direct REST API call from the endpoint to api.anthropic.com, it would first be sent to the function app, which would append the Anthropic API key to the request and forward it to the API endpoint. This approach ensured all communication appeared to originate from Azure, furthering increasing the stealth of the architecture.

Once Claude receives the instructions, it issues a response that flows back through the function app and forwards it to the target VM. Initially, Claude will take a screenshot to determine the target machines' resolution and other elements. From there, it will then determine positionally where to execute clicks or button presses, with each request and response being proxied through the function app.

Once an LLM has the ability to control a machine, several abuse scenarios become possible. One of the first primitives I explored involved browser interaction. Because password managers are very common, I instructed Claude to extract passwords from LastPass on the target machine.

Claude, understandably so, denied doing this. It responded with the expected reasoning: the request was unethical, immoral, and illegal in some cases. Even when I clarified that this was a proof-of-concept and the passwords were my own, it still refused.

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.

Creating an implant that uses traditional Windows API calls for filesystem access (Directory.GetFiles() / Directory.GetDirectories(), Process.Start()) means you do not need an interactive session and can therefore treat it like a traditional C2 implant. In addition, an LLM can assist with debugging or dynamic problem solving automatically. In the following example, I ask Claude to leverage the filesystem tool to search a filesystem for any secret files.

Currently, using computer use tool, if I were to ask Claude to get the IP address of the endpoint the implant is, the process tree would look like this:

1└─ implant.exe (PID 1234)2　└─ cmd.exe (PID 5678)3　　└─ ipconfig.exe (PID 2638)

This behavior is highly suspicious because a newly created process is spawning cmd.exe to run ipconfig. The custom filesystem tool is slightly different. It uses native .NET APIs directly for searching, reading, or listing files, so there’s no suspicious parent-child process relationships unless you call run_command, which calls cmd.exe and will have the suspicious process tree.

With the introduction of applications like Claude Code or OpenAI Codex, agents executing on endpoints have become more common. Even more so, seeing these agents spawning child processes like “bash.exe” or “cmd.exe” isn’t unusual either. This could serve as a more operationally secure way to execute commands on the endpoint as the new process tree would look like this:

1└─ implant.exe (PID 1234)2　└─ claude.exe (PID 3496)3　　└─ bash.exe (PID 3741)4　　　└─ ipconfig.exe (PID 6197)

This isn't unique to Claude, though; any legitimate agent framework (GitHub Copilot CLI, Cursor, Windsurf, etc.) could serve the same purpose. The industry trend of AI agents executing shell commands on endpoints is creating a new class of LOLBin-like behavior that defenders will need to adapt to. With Anthropic’s recent unveiling of computer use functionality in Claude code, this completely removes any suspicious processes and allows complete control over the remote machine using Claude Code, as shown in the following example:

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.

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.

Phantom Labs™ researchers "think like attackers" to expose privilege escalation paths and identity attack vectors, helping defenders proactively uncover misconfigurations and detect threats in complex hybrid and cloud environments.

Explore the latest research from Phantom Labs here.