Breaking Down CoPhish: How Copilot Studio Became a Phishing Platform

Microsoft has spent the last year pushing Copilot Studio into enterprise hands as the low-code way to build and ship AI agents. The rollout has moved fast, and the security conversation has mostly centered on prompt injection and data leakage from the agents themselves.

In October 2025, security researchers documented a different failure mode. Instead of attacking the agent, attackers abuse the platform itself to stage OAuth consent phishing. The phishing surface looks and feels like a real Microsoft 365 Copilot interface, served from copilotstudio.microsoft.com. The victim sees nothing unusual and continues using the agent normally.

Security researchers tracked OAuth-based compromise campaigns hitting nearly 3,000 accounts across 900-plus Microsoft 365 environments in 2025. CoPhish makes that pattern cheaper to run and harder to detect, because every indicator defenders have been trained to watch for, domain reputation, MFA enforcement, password rotation, is already neutralized by design.

CoPhish is OAuth consent phishing delivered through legitimate Microsoft infrastructure. The attacker builds a Copilot Studio agent in their own Entra ID tenant, adds a single HTTP action that forwards the authentication token to their server, and publishes the agent via Copilot Studio’s built-in demo website feature. The resulting URL lives on copilotstudio.microsoft.com.

Standard OAuth consent phishing has existed since at least 2019. Defenders learned to flag unfamiliar domains and to train users to inspect the URL bar before approving consent. CoPhish removes that entire signal category. The domain is Microsoft’s, the TLS certificate is Microsoft’s, the visual branding matches Microsoft 365 Copilot, and the authentication flow itself is genuine. Every intermediate request during the consent flow is served from Microsoft IP space.

The only thing that changes is what happens after the token is issued. Instead of the token staying inside the chat session, a single appended HTTP action forwards it to an attacker-controlled endpoint. From that point, the attacker holds a valid Graph API token for the victim’s account, and the agent continues to function normally so the victim has no reason to suspect anything.

The attack requires no malware or custom infrastructure at all. A Microsoft 365 trial license is enough to configure the entire chain, and no elevated permissions are needed at any step.

Step 1: Building the Agent

The attacker creates a Copilot Studio agent in their own Entra ID tenant. Every agent ships with a built-in sign-in system topic, a low-code workflow that fires when the agent needs the user to authenticate. The topic displays a Login button, redirects the user to the configured sign-in provider, and stores the resulting token in the User.AccessToken variable.

The attacker appends one HTTP request action immediately after the Authenticate step. That action forwards the token to a URL they control. No elevated permissions are required to add it, and the change is invisible to the victim during the chat session.

Step 2: Configuring the OAuth App

The attacker registers a multi-tenant application in their Entra ID tenant and wires it to the agent’s authentication settings. For standard user targets, the app requests scopes still permitted under Microsoft’s default consent policy: Mail.ReadWrite, Mail.Send, and Notes.ReadWrite.

For Application Administrator targets, any delegated Microsoft Graph permission can be requested, including Files.ReadWrite.All, Sites.ReadWrite.All, and Application.ReadWrite.All. Policy restrictions on user consent do not apply to these roles.

Step 3: Distributing the Link

Activating the demo website publishes the agent to a copilotstudio.microsoft.com URL. The attacker distributes the link through phishing email, Teams messages, or search engine positioning. Standard email security filters do not flag it because the domain is genuinely Microsoft’s.

Step 4: Collecting the Token

The victim opens the link and sees a chat interface styled to resemble Microsoft 365 Copilot. They click Login, approve an OAuth consent screen, and enter a numeric validation code issued by token.botframework.com, a legitimate Microsoft domain. This is standard Copilot Studio authentication behavior.

Once the code is submitted, the backdoored sign-in topic fires and forwards the token to the attacker. The exfiltration request originates from Copilot Studio’s backend using Microsoft IP addresses, so nothing anomalous appears in the victim’s web traffic. The victim can continue chatting with the agent and receives no notification that their session was forwarded.

The typical, and traditional enterprise defense against OAuth phishing depends on three layered assumptions, and CoPhish neutralizes every one of them in sequence:

1. Perimeter controls cluster defenses around domain reputation, which delivers nothing useful when the phishing page itself lives at copilotstudio.microsoft.com and carries a legitimate Microsoft TLS certificate.
2. MFA is positioned as the hard authentication gate, but the consent screen only appears after authentication has already succeeded, so MFA is satisfied long before the token is captured.
3. Network inspection doesn’t contribute much here because the exfiltration request originates from Microsoft IP space, which already sits inside every enterprise’s allow-list by default.

This is the pattern traditional security tools consistently miss: the perimeter is bypassed, the identity gate is satisfied, the credential response is irrelevant, and the data layer has to pick up what the earlier layers cannot. Detection has to move to the Entra ID audit layer, which most organizations do not monitor with the same scrutiny as their SIEM content for network and endpoint signals.

Once an attacker holds a valid Graph API token, the rest of the attack is indistinguishable from a legitimate third-party application operating under consent. They can read mail, send mail, pull files from SharePoint and OneDrive, and harvest calendar entries, all through authenticated Graph API calls originating from a registered application.

This is one of the core characteristics of living off AI attacks. Traffic that uses trusted infrastructure looks identical to legitimate activity at every layer of conventional monitoring. The endpoint is clean, the outbound destination is authorized, and the authentication pattern is entirely normal.

Bulk exfiltration is the natural next step. An attacker with Mail.ReadWrite and Files.ReadWrite.All can export years of sensitive correspondence and documents before anyone audits consent grants and notices an application that should not be there. Because each request is individually shaped to look like normal application usage, rate limiting and anomaly detection on the Microsoft side, unfortunately, rarely fires in time to prevent the loss.

For organizations defending against CoPhish, domain-based and credential-based controls provide limited coverage against an attack that deliberately operates within trusted boundaries. The more durable control sits at the data layer, not the authentication layer.

Once a token is issued, the question shifts to whether outbound movement of sensitive content can be spotted and stopped before large volumes leave the tenant. Anti data exfiltration technology is built for exactly this position in the kill chain.

BlackFog ADX Vision monitors endpoint activity for unauthorized AI and API access, catching session-forwarding behavior of the kind CoPhish relies on. BlackFog ADX Protect monitors outbound transfers and blocks unauthorized data movement at the endpoint, stopping exfiltration even when it flows through authorized Microsoft API channels.

You can try it out at https://www.blackfog.com/adx-product-suite/.