Microsoft’s Copilot Studio has been weaponized in a new OAuth phishing technique — branded “CoPhish” by researchers — that uses legitimate Microsoft-hosted Copilot Studio agents to present convincing sign-in prompts, harvest OAuth tokens, and enable account takeover or broad Graph API access without needing passwords. Datadog Security Labs documented the attack chain and proof-of-concept, Microsoft has acknowledged the issue and is planning product updates, and the episode underscores persistent governance gaps in Entra ID consent, agent-enabled low-code platforms, and the UX cues users rely on when approving applications.
Background
What is CoPhish and why it matters
CoPhish leverages Microsoft Copilot Studio agents — low-code, user-configurable chatbots hosted on copilotstudio.microsoft.com — as a trusted distribution mechanism for OAuth consent phishing. An attacker can create a malicious agent (or compromise an existing one), publish its demo URL on a Microsoft domain, and configure the agent’s built-in “Login” workflow to redirect victims into an OAuth consent flow that issues an access token to attacker-controlled endpoints. The agent can then automate exfiltration or follow-on actions using that token. Because the initial page is served from Microsoft infrastructure and mimics familiar Copilot experiences, victims are significantly more likely to accept the requested permissions.This is not a theoretical quirk confined to lab demos. The mechanics combine several high‑value attack primitives — a legitimate hosting domain, an OAuth consent flow that issues long-lived tokens or privileges, and low-code automation that can immediately act on obtained tokens. That mix transforms what looks like a benign chatbot into an account takeover vector capable of reading mail, harvesting files, manipulating calendars, or even performing administrative actions depending on the granted scopes.
OAuth consent attacks in context
OAuth consent attacks are well-established: attackers register apps (or induce victims to interact with apps) that request broad delegated permissions. If users approve, the resulting token grants the attacker the effective privileges of the user, accessible via Microsoft Graph and other APIs. These consent-based compromises are cataloged in threat frameworks and have been exploited for tenant takeover and data exfiltration. The novelty here is the use of Copilot Studio as a trusted staging ground for the consent prompt, increasing the social-engineering credibility of the lure.Technical anatomy of CoPhish
Step-by-step: how the attack chain operates
- Attacker provisions or compromises a Copilot Studio agent and configures its topics and automations. The agent’s demo page is hosted on copilotstudio.microsoft.com.
- The agent’s Login topic is set to invoke an OAuth flow or redirect to an application consent URL that requests sensitive delegated scopes (Mail.ReadWrite, Calendars.ReadWrite, Files.Read.All, etc.). The victim—seeing a Microsoft domain and familiar Copilot-like UI—clicks the login button.
- The victim is redirected through legitimate Microsoft authentication endpoints (for example token.botframework.com as part of the bot framework flow) and is presented with an OAuth consent dialog. Because the page is initiated from Microsoft infrastructure and may display expected icons and labels, users can overlook the “not verified” publisher warning.
- After consent, Microsoft issues an access token that is redirected according to the OAuth flow. The Copilot agent (or a configured topic) can forward that token to a third-party endpoint, or immediately call Microsoft Graph to act on the user’s behalf. Because the hosting and redirection originate on Microsoft infrastructure, basic outbound traffic logs may not show a suspicious external POST from the user’s device.
Why Copilot Studio is an effective wrapper
- Copilot Studio pages live on Microsoft-controlled domains and can mimic first-party UX patterns, eroding visual trust cues that users rely on.
- Low-code “topics” can be configured to perform immediate automation — exfiltrating tokens or invoking Graph APIs without additional attacker infrastructure.
- The redirection endpoint sequence and token issuance use legitimate OAuth flows, which defeats defenses that only look for credential submission or anomalous domains.
The vendor and ecosystem responses
Microsoft’s consent policy changes and hardening
Microsoft has been iterating its Entra ID application consent policies to reduce these risks. The managed default consent policy (often referred to or implemented via a setting like “microsoft-user-default-recommended”) already blocks several high-risk Graph permissions from end‑user consent, and Microsoft has announced further policy updates that tighten what users can self-consent to in late October and November 2025. These updates are intended to reduce the attack surface by requiring administrator approval for broader or higher-risk permissions by default.However, these changes do not fully neutralize the problem. Two notable gaps remain:
- Privileged administrators (Cloud Application Administrator, Application Administrator, etc.) retain the ability to consent to any permissions for any application, making them high‑value targets.
- In many tenants, member users can still consent to certain delegated scopes such as Mail.ReadWrite or Calendars.ReadWrite — which are powerful enough to fuel malicious activity if misused. Microsoft’s policy tweaks narrow default consent but do not eliminate all tenant-level delegation risks without active admin configuration.
Microsoft acknowledgement and planned mitigations
Microsoft has confirmed it is investigating and planning product updates to address the underlying causes that make Copilot Studio usable for these flows, including governance changes to Copilot Studio and consent experiences. Vendor messaging emphasizes that the attack relies heavily on social engineering, while product hardening will reduce the platform's misuse potential. Public reporting cites Microsoft confirmation and a commitment to remediate.Cross‑verified facts and caveats
- Datadog Security Labs provided the proof-of-concept and detailed technical write-up demonstrating how a Copilot Studio agent’s Login topic can be configured to redirect to an OAuth consent flow and exfiltrate the resulting access token.
- Microsoft Learn documentation for managing app consent policies documents the default managed policy behavior and explicitly notes upcoming changes to Microsoft-managed consent defaults that take effect in late October 2025 (with further expansions in November). Administrators should read and map these changes to tenant policy.
- Independent security outlets (BleepingComputer, Tech press) reported Microsoft’s acknowledgement and the appearance of CoPhish in the wild as a credible threat vector; these reports corroborate Datadog’s findings and Microsoft’s stated intent to harden the platform.
Operational recommendations — immediate to long term
The following are prescriptive, prioritized steps organizations should take now to blunt the CoPhish vector and related OAuth consent threats.Immediate (hours — 48 hours)
- Enforce least-privilege for admin consent: Limit Cloud Application Administrator and Application Administrator roles to the smallest set of personnel and require out-of-band approval prior to granting consent to new applications.
- Disable or restrict tenant user app registrations: Configure Entra ID so that regular users cannot register or consent to high-risk delegated permissions. Apply the Microsoft-managed policy or a stricter custom policy.
- Block or audit Copilot Studio demo links: If possible, restrict access to Copilot Studio demo hosting or monitor for any external demo URLs shared in email/Teams. Treat demo URLs as suspicious in high-value workflows.
- Require phishing‑resistant MFA for admin roles: Implement FIDO2/WebAuthn or platform passkeys for privileged identities to reduce the success of adversary-in-the-middle and device-code social engineering attacks.
Short term (days — 2 weeks)
- Audit existing app consent history: Search the tenant for recently consented apps, service principals, and unusual redirect URIs. Revoke suspicious or unnecessary consents and re-evaluate scope justifications.
- Monitor Copilot and connector telemetry: Enable detailed logging for Copilot connectors, agent activity, and topic automation runs; alert on outbound POSTs in agent topics, unusual token redirections, and creation of new agents in the tenant.
- Harden app manifest and registration policies: Remove wildcard validDomains from trusted manifests, require explicit verified publisher status for high-scope apps, and block display-name homograph bypasses where possible.
Medium term (weeks — months)
- Integrate Copilot governance into IAM and DLP: Bring Copilot connectors and agent permissions into Purview/DLP policies, and require admin approval for connectors that expose Graph scopes to assistants.
- Run consent-phishing tabletop and red-team exercises: Simulate CoPhish-style attacks in test tenants to validate detection, verify telemetry coverage, and tune incident playbooks.
- Make least-privilege the default for connectors and apps: Where possible, prefer constrained, single-resource scopes rather than broad delegated permissions (avoid Sites.Read.All / Files.Read.All unless business-justified and admin-approved).
Detection, monitoring, and incident response
Signals to hunt for
- Newly created Copilot Studio agents with demo URLs or public sharing enabled.
- OAuth consent events granting high-scope delegated permissions, especially if issued shortly after a Copilot agent activity.
- Outbound requests originating from Copilot Studio service endpoints that include access tokens or redirect URIs pointing to uncommon external hosts.
- Unexpected application registrations or service principals with unusual display names (homograph-style names), wildcard manifests, or recently modified redirect URIs.
Rapid response checklist
- Immediately revoke tokens and session cookies for affected accounts; force global sign-out where required.
- Revoke the offending application’s consent and delete suspicious service principals. 3. Search audit logs and Graph usage for suspicious API calls, mailbox reads, or file downloads initiated around the time of the consent event. 4. Rotate any connector credentials and re-provision connectors with least-privilege scopes. 5. Notify legal/compliance and business owners if sensitive data may have been exposed.
Critical analysis: strengths, limitations, and systemic risks
Strengths in Microsoft’s approach so far
- Microsoft has been iteratively tightening the default managed consent policy and has demonstrated the capacity to apply tenant-protecting defaults in a managed policy that can be updated centrally. This is a powerful lever for defenders because it can reduce risk across tenants without requiring every organization to correctly configure every setting.
- Vendor responses to prior consent and homograph issues (zero-width Unicode bypasses and manifest hygiene fixes) show that platform hardening can close classes of simple abuses.
Limitations and persistent risks
- Human factors remain the Achilles’ heel. Consent dialogs are complex and users often click through when under time pressure or when a page looks legitimate. Any UX that relies primarily on visual trust cues is vulnerable to mimicry, especially when hosted on first-party domains. Datadog’s PoC shows how deeply that trust can be abused.
- Low-code and agent frameworks expand the attack surface. Copilot Studio’s very utility — rapid authoring of automated tasks and connectors — is what makes it attractive to attackers. Removing or restricting that utility to preserve security reduces productivity, and that tradeoff must be managed carefully.
- Administrative role concentration is a systemic risk. The fact that an Application Administrator can consent to any permission for any application means attackers disproportionately benefit from compromising a small number of high‑privilege users. This is a governance problem as much as a technical one.
What vendors and product teams should do next
- Make consent provenance and publisher verification louder and harder to bypass in the UX; normalize display strings and strip or normalize invisible Unicode characters server-side to defeat homograph tricks.
- Add safeguards to low-code agent platforms: require tenant-level whitelisting for demo/public sharing and restrict the types of redirects or outbound POSTs an agent may perform by default.
- Expand telemetry and alerting by default so tenant owners have easier, out-of-the-box detection for suspicious consent grants tied to Copilot/agent activity.
Conclusion
CoPhish demonstrates a predictable but dangerous interaction of three trends: the increasing use of AI-enabled low-code automation, the long-standing brittleness of OAuth consent UX, and the power of social engineering when attackers can leverage first-party hosting. Datadog’s disclosure shows the technique is practical; Microsoft’s policy changes and planned product updates help, but governance, least-privilege configuration, and phishing‑resistant authentication remain the most effective immediate defenses. Organizations must treat Copilot Studio and similar agent platforms as first-class security boundaries: harden permissions by default, reduce administrative consent scope, monitor agent creation and token flows, and run adversarial tests to validate detection. The balance between productivity and security will be tested as AI platforms continue to expand their reach — defending that boundary calls for vigilant engineering, clear governance, and disciplined operational controls.Source: Red Hot Cyber CoPhish is coming! Microsoft Copilot Studio used to steal accounts