Ghost Send: How M365 URL Decryption Enables OAuth Token Theft

What Is Ghost Send?

Ghost Send is a Microsoft 365 attack that turns a security feature into an attack mechanism. The vulnerability lives in M365 ATP Safe Links, which rewrites URLs in incoming email to check them for malware. When Safe Links decrypts an encrypted URL to inspect it, that decryption request can be captured and weaponized to trigger an OAuth authentication flow. If the victim is already signed into Microsoft 365, the attacker receives a valid access token.

There is no fake login page. No password entered. The victim receives an email. The attack fires silently through the security scanner itself.

The technique was demonstrated with a proof-of-concept tool called GhostSend, which shows how a feature designed to protect users can be used against them.

How the Ghost Send Attack Chain Works

1. The attacker sends an email containing an encrypted URL pointing to a server the attacker controls.
2. M365 ATP Safe Links intercepts the message and rewrites all URLs to pass through Microsoft's proxy for scanning.
3. Safe Links decrypts the URL to check it for malware. This causes Microsoft servers to make an outbound HTTP request to the attacker's domain.
4. The attacker's server receives the request and responds with an HTTP 302 redirect to a Microsoft OAuth authorization endpoint, requesting an access token for an application the attacker registered in Azure AD.
5. Because the victim is already authenticated to Microsoft 365, their session already holds a valid token. The OAuth flow completes without any credential prompt.
6. The attacker receives a usable access token scoped to the registered application. They can now access the victim's email, SharePoint, or Teams data through Microsoft Graph API.

The security scanner makes the request. The attacker's server redirects it. Microsoft's own OAuth infrastructure completes the flow. Nothing looks anomalous to the victim's session.

What Attackers Can Do With the Token

Access tokens obtained through Ghost Send are persistent and refreshable. An attacker can:

• Read, download, and exfiltrate email through Microsoft Graph API
• Access SharePoint files the victim has permission to view or edit
• Send email from the victim's account through authorized applications
• Maintain access after the victim changes their password, since the token operates through OAuth, not password authentication
• Use the token to pivot to other Microsoft cloud services the victim is signed into

The detection challenge is significant. There is no failed login, no unusual IP geolocation, no suspicious device. The token was issued legitimately through Microsoft's own OAuth infrastructure, triggered by a feature that was doing exactly what it was designed to do.

How to Detect Ghost Send Activity in M365 Sign-In Logs

Focus on OAuth consent events and token issuance patterns in Azure AD:

What to look for in sign-in logs: - OAuth app consent events that occurred within minutes of the victim receiving an email with a link from an unknown sender - Service principal sign-in events for apps that normally do not execute under the affected user's context - Token issuance with no corresponding interactive login event on the user's account in the preceding minutes - Consent grants to apps registered in Azure AD within days of the attack, with low or unverified publisher publisher info

Specific Azure AD Identity Protection signals: - Application-based risk events where the app was first seen only recently - User risk events that spike coincident with receiving a suspicious email - Sign-in activity where the user_agent matches Safe Links scanner behavior rather than a normal browser

Microsoft has published IOCs for the GhostSend proof-of-concept. These include specific OAuth client_id values and authorization request patterns visible in Azure AD logs. Security teams should search for these patterns in the hours immediately following suspicious email receipt.

How DMARCFlow Can Supplement Ghost Send Detection

Ghost Send is an OAuth attack. It exploits authentication flows, not email authentication protocols. DMARC cannot prevent it because DMARC validates SPF, DKIM, and alignment at the SMTP layer. OAuth token issuance happens after SMTP, through a different system entirely.

Where DMARCFlow fits: when an attacker uses a compromised OAuth token to configure mail forwarding rules or send on behalf of a compromised domain, DMARC aggregate reports will show the authentication results. If a token was used to set up a forwarding rule to an external address, DMARC reports may show the forwarding domain as a source of mail that your domain did not send.

Specifically, DMARCFlow aggregate reports can surface: - Unexpected sending patterns from your domain after a suspected OAuth compromise, which may indicate the attacker is using your domain to relay mail - SPF and DKIM failures for mail sent using OAuth-authenticated sessions that were configured through a compromised consent grant - Alignment failures that appear after an attacker configured forwarding rules using obtained tokens

This is not primary Ghost Send detection. That requires Azure AD sign-in logs and app consent monitoring. DMARCFlow provides domain-level mail authentication visibility that complements the app-level view Azure AD gives you.

Defensive Measures Beyond Email Security Scanning

1. Conditional Access policies for OAuth apps: Require phishing-resistant authentication for sensitive app permissions. Block legacy authentication protocols that tokens can be exchanged through. Prioritize apps that have high privilege access to email and SharePoint.

2. Restrict who can register Azure AD applications: Ghost Send requires an attacker to have an app registration in the tenant. Limiting app registration to administrators reduces the ability to complete the attack chain.

3. Audit OAuth app permissions quarterly: Use the Enterprise applications dashboard to review which apps hold Mail.Read, Mail.Send, or Files.Read permissions. Remove anything that is no longer actively used or has excessive scope.

4. Set up alerts for new app consent events: Configure Identity Protection alerts for consent grants to apps from non-verified publishers. Fast response to unexpected consent events can limit the window of opportunity.

5. Train users on OAuth consent prompts: Users approve app consents constantly and often without reading what they are granting. Specific training on what OAuth consent means, what the prompt looks like, and what to do when an unexpected consent screen appears is more effective than generic "be careful with email" messaging.

6. Consider disabling Safe Links for internal-to-internal mail: Transport rules can be configured to skip Safe Links rewriting for messages where both sender and recipient are within your organization. This reduces unnecessary Safe Links exposure while preserving protection for inbound external mail.

Safe Links is doing what it is designed to do. The practical response is not to disable it but to limit what an attacker can do if Safe Links is exploited in this way.