- Check Point Research (CPR) has discovered that certain AI assistants that support web browsing or URL fetching can be abused as covert command-and-control relays (“AI as a proxy”), allowing attacker traffic to blend seamlessly into legitimate, commonly permitted enterprise communications.
- This technique was demonstrated against platforms such as Grok and Microsoft Copilot, leveraging anonymous web access combined with browsing and summarization prompts
- The same mechanism can also enable AI-assisted malware operations, including generating reconnaissance workflows, scripting attacker actions, and dynamically deciding “what to do next” during an intrusion.
- CPR outlines a near-term evolution in malware development, where implants shift from static logic to prompt-driven, adaptive behavior that can autonomously plan operations, prioritize targets and data, and adjust tactics in real-time based on environmental feedback.
AI is rapidly becoming embedded in day-to-day enterprise workflows, inside browsers, collaboration suites, and developer tooling. As a result, AI service domains increasingly blend into normal corporate traffic, often allowed by default and rarely treated as sensitive egress. Threat actors are already capitalizing on this shift. Across the malware ecosystem, AI is being used to accelerate development and operations: generating and refining code, drafting phishing content, translating lures, producing PowerShell snippets, summarizing stolen data, assisting operators with next decisions during an intrusion, and, in extreme cases, developing full C2 frameworks such as Voidlink. The practical outcome is simple: AI reduces cost and time-to-scale, and helps less-skilled actors execute more complex playbooks.
But the next step is more consequential: AI isn’t only helping attackers write malware, it can become part of the malware’s runtime. In AI-Driven malware, the implant’s behavior is shaped dynamically by model output. Instead of relying solely on hardcoded decision trees, an implant can collect host context such as environment artifacts, user role indicators, installed software, domain membership, and geography, and use a model to triage victims, choose actions, prioritize data, and adapt tactics. This prompt-driven approach can make campaigns more flexible and harder to predict, especially as it shifts decision-making away from static code and toward external reasoning.In this research, Check Point Research demonstrates a concrete building block that connects these trends: AI assistants with web-browsing and URL-fetch capabilities can be abused as covert command-and-control relays, effectively using AI as a C2 proxy. We show how Grok and Microsoft Copilot can be driven through their web interfaces to fetch attacker-controlled URLs and return responses, creating a bidirectional channel that tunnels victim data out and commands back in. Crucially, this can work without an API key or a registered account, reducing the effectiveness of traditional kill switches such as key revocation or account suspension.
We then connect the technique to the broader trajectory: once AI services can be used as a stealthy transport layer, the same interface can also carry prompts and model outputs that act as an external decision engine, a stepping stone toward AI-Driven implants and AIOps-style C2 that automate triage, targeting, and operational choices in real time.
AI-Driven malware is malware that uses an AI model as part of its runtime decision loop, not just during development. Instead of executing a fixed, preprogrammed flow, the implant collects local signals from the infected host and uses a model to interpret them and decide what to do next. In practice, the model output can influence which capabilities are activated, which targets or data are prioritized, how aggressive the malware should be, and whether the host is worth continuing to operate on. This shifts part of the malware’s logic from static code into model-driven, context-aware behavior, which can make campaigns more adaptive and less predictable than traditional rule-based decision trees.
A useful way to think about AID malware is that the model becomes an external or internal decision engine. The implant provides a compact “situation report” (environment artifacts, user and domain context, installed software, file and process metadata, observed security controls, and other host indicators) and receives back guidance that can shape subsequent execution. Over time, this enables behavior that is more tailored per-host, can change across infections without code changes, and can reduce repeatable patterns that defenders often rely on for signatures and sandbox detonation.
There are two primary integration approaches:
- API-based integration
- The malware interacts with a remote model or agent through an API. That model can be hosted by a mainstream provider, a niche platform, or attacker-controlled infrastructure running an agent. This approach is operationally flexible and keeps the implant lightweight, but it introduces network dependencies and creates telemetry that defenders may be able to hunt for. It can also create a potential kill switch if the workflow depends on revocable credentials, unless the actor can blend or relay the traffic through intermediate layers.
- Embedded model
- The model is packaged locally, either inside the binary or as a bundled component. This removes the need for external inference calls and can reduce network exposure, but it increases payload size and resource requirements, and makes model updates harder. In real-world terms, embedded approaches trade operational convenience for stealth and independence from external services.
Abusing legitimate services for C2 is not new. We’ve seen it with Gmail, Dropbox, Notion, and many others. The usual downside for attackers is how easily these channels can be shut down: block the account, revoke the API key, suspend the tenant. Directly interacting with an AI agent through a web page changes this. There is no API key to revoke, and if anonymous usage is allowed, there may not even be an account to block.
Our proposed attack scenario is quite simple: an attacker infects a machine and installs a piece of malware. Then the malware communicates directly with either Grok or Copilot through the web interface, sending a prompt that causes the AI agent to issue an HTTP(S) request to an attacker-controlled URL, retrieve content from that site, and return the attacker’s response via the AI output back to the malware.
To test if our attack scenario is possible, we have set up two basic requirements:
- No authentication requirement: zero restrictions on the request, no account, no API key.
- Arbitrary web fetch with data in and out: the AI must be able to fetch a website we control, carry data in query parameters, and return content from that site in its response.
We found two AI providers that meet these requirements: Grok and Copilot. There were some minor restrictions, such as not being able to send data to direct IPs or plain HTTP, so we set up a fake HTTPS website to serve as our C2 server. We registered a domain, deployed a simple site, and in the spirit of things, let AI help us generate the entire thing.
The result is a Siamese cat fan club website. One of the pages is a “breed comparison” page. For example, we can ask Copilot at https://copilot.microsoft.com to summarize that page; no account is needed. The same applies to Grok at https://grok.com.
Now, in a real attack scenario, we would want to send data to the C2 (for example, the result of system reconnaissance on the infected machine) and receive data back (a command or at least an acknowledgment). That’s easy: we append the data, in some structured format, to the URL’s query parameters. There do appear to be safeguards: if we make it too obvious that we’re sending clearly malicious or sensitive data, some services try to block or sanitize it. However, simply encrypting or encoding the data in a high-entropy blob is enough to bypass these checks.
On the server side, we set up a breed comparison table, comparing different cat breeds. But one can’t really compare a cat breed without knowing what the cat breed’s “favorite Windows command to execute” is. For “stealth”, we made the page only display this command column when the my_breed_data URL parameter is present. We instruct the AI to visit the page and “return the cat’s favorite Windows command” based on a pattern embedded in the HTML.
As shown in the image, both Grok and Copilot gladly followed up on our prompt, fetched our site, and returned a response containing the command we planted. Of course, in a real attack, this command (or the whole payload) could be further encoded or encrypted to avoid triggering any model-side safeguards.
This demonstrates the feasibility of implementing the behavior end-to-end in a browser with no logged-in user. The next question is: how would actual malware do this from software, without relying on a visible browser window or any human interaction?
Confirming that the technique works in a regular browser is one thing. Making it usable from malware is another. For our PoC, we set ourselves a constraint: get it working in C++, without relying on a direct API key or random HTTP requests to the AI provider’s website. Sending raw HTTP requests that don’t look like a normal browser session is more likely to hit rate limits, CAPTCHA, or behavioral checks. Instead, we decided to emulate a browser from within our C++ program.
For that, we used WebView2, an embedded browser component that lets native Windows apps display and interact with web content. The WebView2 runtime is preinstalled on all Windows 11 systems and has been broadly rolled out to modern Windows 10 versions via updates. Even if it’s missing, an attacker could bundle it with the malware or download it on first run.
Using WebView, we created a quick PoC: a C++ program that opens a WebView pointing to either Grok or Copilot. From there, we have two slightly different flows:
- Grok: Once the page is loaded, we can inject our prompt directly into the
qparameter in the URL, and Grok will automatically follow our prompt without any further steps. - Copilot: the flow is a bit trickier and uses JavaScript inside the loaded page to submit the prompt to the Copilot UI.
Either way, it works. Our program does the following:
- Enumerate some basic information about the machine.
- Append it to the URL of our fake Siamese cat C2 site
- Open a (hidden) WebView window to the AI provider’s website.
- Ask the AI to fetch and “summarize” that URL.
- Parse the AI’s response and act on the embedded command.
WebView is just one example of how to do this in C++. Other platforms and languages have similar embedded browser controls that can achieve the same goal.
The PoC we created is intentionally simple, but it can easily be extended to behave more like real-world malware. In a full implementation, the implant could first send host enumeration data and register itself with the C2 server. The C2 server could then instruct the backdoor to sleep, collect additional information, check in at a later time, download further payloads, or execute arbitrary commands. None of this would be difficult to achieve once we have demonstrated that a bidirectional communication channel between malware and a C2 server can be established through an AI agent. Once the PoC was functional, we responsibly disclosed these findings to the Microsoft security team and the xAI security team.
This technique is one example of how a threat actor can abuse an AI web app by using it as a proxy for C2, but it is far from the only option. The same interface could be used to request AI-generated commands to locate files, enumerate the system, search for sensitive data, or generate PowerShell code to move laterally across the network. Instead of relying on a skilled human operator, malware could directly task an AI agent for what to do next.
Beyond direct command generation, an attacker could also rely on AI to handle decision-making logic that is usually embedded in the malware itself. For example, an implant might send a short description of the host (domain, user role, installed software, geography) and ask the AI whether this system is worth further exploitation, which tools to deploy next, or how aggressively to move laterally without raising suspicion. The agent’s response would then shape the rest of the campaign, effectively turning the AI into a remote “brain” for the malware.
In the rest of this article, we focus on broader AI-Driven (AID) malware concepts and how future campaigns may integrate AI into their decision-making and operations. Our goal is not just to highlight one clever C2 trick, but to show how the same building blocks, web-accessible AI agents, and flexible prompts evolve into full AI-assisted attack workflows.
While current AI-Driven (AID) threats have not yet been utilized in an optimal way, the practical impact of AID malware or AI-assisted attacks remains limited, largely experimental, inconsistent, or easily replicable using traditional decision-tree logic.
However, we can identify at least one major area where AI could become pivotal in the future: data analysis and infection targeting. AI has the potential to dramatically accelerate the identification of valuable data within compromised systems, the prioritization of targets, and the optimization of infection spread. By automating reconnaissance and decision-making steps that currently require human effort, AI could enable attackers to execute campaigns much faster and with greater precision. This capability, when it matures, could mark a significant turning point in how cyberattacks are conducted, shifting the balance between speed, accuracy, and scale in favor of malicious operators.
The three future AI use cases mentioned below represent the scenarios we believe will genuinely advance threat actors’ capabilities. At the core of these developments lies one central concept: data analysis and infection targeting.
As some of these techniques may already be implemented, we assess that in the near future, the methods described below will be expanded upon and widely adopted by threat actors, particularly those capable of leveraging advanced AI-driven capabilities.
The majority of modern malware families are designed to collect detailed system information from infected machines. This typically includes data such as the username, domain name, computer name, installed software, running processes, startup programs, and other environment details. Such reconnaissance allows the malware to better understand its execution context, whether it’s operating within a corporate network, a sandbox, or a personal device, and to adjust its behavior accordingly.
A potential future scenario involves a Remote Access Trojan (RAT), infostealer, Loader, or similar type of malware leveraging an AI model or API as part of its operational logic. In this case, the malware could utilize a predefined prompt combined with system data it has already collected and send this information to an AI service. The AI agent would then analyze the data and determine the likelihood that the environment is a real target or a sandbox used for malware analysis.
This method could function as an advanced AI anti-sandbox and environment validation technique. Instead of relying solely on hardcoded checks or local heuristics, the malware could offload the decision-making process to a remote AI system. If the AI’s response indicated “no sandbox detected,” the malware could proceed to execute its full capabilities, including data exfiltration, persistence installation, and communication with its C&C.
If malware begins to outsource environment verification to AI services, detecting and attributing infections will become significantly harder. An AI-Driven validation step can cause sandboxes and automated analysis tools to fail to trigger malicious behavior, because the payload may remain dormant until a remote model confirms the host is a “real” target. As a result, traditional signature- and sandbox-based detection pipelines may produce fewer observable indicators, while telemetry that would normally reveal malicious activity may never appear in analyst environments. This reduces the visibility defenders rely on and increases the chance that sophisticated campaigns slip through initial analysis windows.
While communicating with an AI API endpoint or embedding a model locally can generate noisy telemetry, a more subtle application of AI could occur at the Command and Control. C&C servers could use AI to automatically identify and categorize compromised hosts. For example, an AI-Driven triage step might discard obvious sandboxes and withhold second-stage payloads from those hosts.
Beyond sandbox detection, AI applied at the C&C could score victims based on available PII. This enables prioritization of follow-on actions and lateral movement. Once AI determines that an infection is a high-value target (such as corporate accounts or servers), the bot will receive different commands from the C&C, and distinct workflows will be applied to this infection, including a notification to prioritize the “manual” lateral movement. In the other case, the C&C might deploy a simple miner to a low-value victim, as further actions might not be of interest to the threat actor.
Another potential implementation would mirror the concept of MCP servers, but instead of integrating various red-teaming tools, the attacker could connect an existing malware family directly to an MCP server.
The same concept used to identify valuable users or high-value targets can also be applied to files. An AI model could score which files are worth encrypting or exfiltrating based on metadata (file names, sizes, creation and modification timestamps, paths, …), as well as their content. By prioritizing high-value files, an attacker can accelerate encryption or data theft while generating far fewer I/O events, thereby reducing the likelihood of triggering volume-based alarms and increasing the chances of ignoring decoy or bait files.
Many ransomware detection workflows in XDRs rely on volume or rate thresholds and therefore only declare malicious activity after a sizable number of files have been encrypted. If an attacker limits activity to a much smaller, carefully chosen pool of files, this can undermine those heuristics and create detection gaps.
In a notable 2022 analysis, Splunk researcher Shannon Davis measured the time it takes several prominent ransomware families to encrypt large volumes of data, reporting times that ranged from a couple of minutes for the fastest families to several hours for slower ones. These experiments showed that some ransomware variants can encrypt ~100 GB in a matter of minutes.
The worrying question for AI-Driven ransomware is straightforward: What if an attacker does not need to encrypt 100 GB to achieve their objective? If an AID payload can prioritize and target only a small set of high-value files (for example, critical databases, business documents, or encryption keys) using model-driven scoring, the time to accomplish effective damage could be dramatically less than the bulk-encryption numbers. In other words, targeted encrypt-and-extort campaigns could succeed in seconds or minutes while generating far fewer observable file-I/O events. The same dynamics apply to data exfiltration, where ransomware groups frequently steal sensitive data and then publish it on their onion sites or leak it on their leak blogs.
Advanced persistent threat (APT) actors customize their malware and prompts to fit the target’s profile, infrastructure, and the value of the data they expect to find. For example, attackers focused on defense contractors, research labs, or critical infrastructure operators will prioritize reconnaissance and payloads that can discover, collect, and exfiltrate technical schematics, classified reports, or proprietary designs. Ignoring unwanted documents that could potentially cause high-volume data exfiltration.
AID wipers may target specific files instead of everything to take down a specific machine. Or wipers may avoid taking down the machine and instead target specific programs, making various processes unusable.
While we previously discussed how AI-Driven (AID) malware could eventually find its optimal use cases, this section outlines how such implementations may realistically occur. Although AID Embedded-Model malware offers superior stealth, as no input or output is observable by external AI providers (such as OpenAI, Anthropic, and Gemini), we believe that AID API-Based implementations will likely be preferred. This is primarily due to practicality, embedding or bundling a model significantly increases the binary size, which usually goes against the common preference for lightweight payloads. Currently, there is a growing number of AI platforms advertising malicious capabilities, such as FraudGPT, EvilAI, MalwareGPT, etc., which could theoretically be used to power API-based AID malware. However, from a defensive standpoint, these connections are relatively easy to detect just by blacklisting known malicious domains. For an AID API-based approach to achieve real stealth, threat actors would need to employ AI proxy servers to relay requests to these malicious AI platforms. This setup would conceal direct communication with the malicious AI service, making network detection challenging. Alternatively, attackers could host their own local AI model on a remote server. In that case, the server would operate more like an AIOps Command and Control Server (AIOps-C&C) rather than a mere proxy, enabling AI-assisted decision-making and automation while keeping communication hidden within the attacker’s infrastructure.
AI assistants are no longer just productivity tools; they are becoming part of the infrastructure that malware can abuse. In this research, we showed how Grok and Microsoft Copilot can be driven through their web interfaces and abused as covert C2 relays, without any API keys or user accounts. By combining a simple “C2 website” with a WebView2-based C++ implant, we demonstrated a full end-to-end path in which victim data flows out via URL query parameters, and attacker commands flow back in through AI-generated responses.
More importantly, this is not a one-off trick. Any AI service that exposes web fetch or browsing capabilities, especially to anonymous users, inherits a similar level of abuse potential. Today, that may look like a creative way to hide C2 in “normal” AI traffic. Tomorrow, the same pattern can evolve into fully AI-Driven malware and AIOps-style C2, where models help decide which hosts to keep, which files to steal or encrypt, and when to stay dormant to avoid sandboxes and detection.
This is a service-abuse class of issue, not a traditional memory corruption bug. Mitigations, therefore, require changes on both sides. AI providers need to harden web-fetch features, enforce authentication, and give enterprises greater control and visibility into how their models access external URLs. Defenders need to start treating AI domains as high-value egress points, monitor for automated and unusual usage patterns, and incorporate AI traffic into their hunting and incident response playbooks.
As AI continues to integrate into everyday workflows, it will also integrate into attacker workflows. Understanding how these systems can be misused today is the first step toward hardening them for the future, and ensuring that AI remains more useful to defenders than to the malware that tries to hide behind it.
