The IA as command and control proxy: the new threat that hides instructions in legitimate traffic

Cybersecurity researchers have turned on an alarm light on a new way in which artificial intelligence assistants can be abused: converting their web navigation or URLs recovery capabilities into silent control and control channels (C2) that are mixed with a company's legitimate traffic. The technique, tested by researchers against services such as Microsoft Copilot and xAI Grok, has been documented by Check Point under the name "AI as a C2 proxy."

The core of the problem is simple and at the same time disturbing: when an IA wizard can access the web or recover content from a URL, that legitimate behavior can be redirected to transport malicious instructions and exfilter data. A team of attackers must first have compromised a machine - by phishing, unpatched vulnerability or any other classic vector - and installed a malicious software that invokes the IA assistant with indications designed for it to recover content from infrastructure controlled by the attacker. The answer the wizard offers can contain commands or code fragments that malware runs locally, thus closing a two-way control channel that is difficult to distinguish from the authorized traffic.

The threat is not limited to executing specific orders; researchers warn that the same axis can be used as an external decision engine. The attacker can send information from the system committed to the model and ask not only for commands, but also for escape strategies, additional recognition steps or decision on whether it is worth continuing to operate that equipment. In other words, IA can act as an additional layer of automation and decision-making for more sophisticated campaigns, approaching what experts call AIOps-style C2 operations.

What makes this technique particularly problematic is that the tests described do not require an API key or a registered account. This means that malicious responses can move through the endpoints of public services without going through victim or supplier-controlled credentials, which limits the effectiveness of traditional mitigation such as key revocation or account suspension.

This abuse of trust services recalls other modalities that the attackers have used for years to hide their activities within legitimate channels - a family of techniques to which they have been called living off trusted sites (LOTS)-. It is not an isolated phenomenon: weeks before, the Unit 42 team from Palo Alto Networks demonstrated how a seemingly harmless website can consult a real-time language model to generate malicious JavaScript that is assembled and run on the client, allowing to create dynamic phishing pages. The Unit 42 report on this method is available on your site: Real-time malicious JavaScript through LLMs.

There are also conceptual similarities with the so-called "Last Mile Reassembly" (MRL) techniques, where the attacker sends malware fragments through unmonitored channels (e.g. WebRTC or WebSocket) and reproduces them in the victim's browser, avoiding network security controls. An analysis of MRLs can be found at this technical exploration and serves as a reminder that vectors that mix legitimate behavior and assembly in running time are difficult to mitigate if controls focus only on the signature or reputation of the domain.

What does this mean for companies and security administrators? First, that IA models and their navigation capabilities are not just productivity tools: they are new services on the network that require specific governance and controls. Blinding the classic perimeter is no longer enough if attackers can make their communications travel on routes that seem legitimate. To meet this challenge, it is necessary to combine technical and policy measures: to limit the navigation capacity of IA assistants in sensitive environments, to apply egress controls that record and allow to audit calls to language model services, and to use network segmentation to reduce the reach of a committed team. In addition, endpoint controls should evolve to identify suspicious behaviors - such as processes that invoke IA web interfaces and then execute received commands - and not rely only on signature detection.

At the prevention level, the adoption of allowlists for critical domains or APIs, the monitoring of DNS records and the correlation between the activity of endpoint IA and telemetry models can help to detect anomalies. Organizations should also require providers of IA solutions to increase transparency and mechanisms to limit abnormal uses, such as stricter authentication for navigation capabilities, limits on the discharge of arbitrary content and traceability mechanisms to enable security teams to investigate incidents. For their part, internal policies should clearly define which IA assistants are authorized and with which permits; in high-risk environments, it may be preferable to disable the search / browsing function in corporate assistants.

The security community already faces similar scenarios from other optics: MITRE and the threat frameworks describe techniques where adversaries reuse legitimate environmental tools for their benefit, which reinforces the idea that reputation-based detection is insufficient ( see MITRE ATT & CK on living-off-the-land). At the same time, the findings of organizations such as Check Point and Unit 42 show that the border between "reliable" services and attack channels is becoming blurred.

In short, we are facing a new risk layer where IA models can serve both to accelerate attacks and to camouflage them. It is not a technological apocalypse, but it is a call to update defence, governance and education practices. Treating IA attendees as a new type of network service, with clear controls, monitoring and policies, will be key to prevent them from becoming unnoticed relays of malicious campaigns.