Microsoft Graph Proxying

The use of a stolen Microsoft token to make API calls through an attacker-controlled backend rather than a separate tool. This lets the operator read mail, contacts, files, and tenant data from one interface while blending actions into normal Microsoft 365 traffic. It increases speed, scale, and concealment after token theft.

Expanded Definition

microsoft graph proxying is a post-compromise technique that uses a valid Microsoft token to route API activity through an attacker-controlled backend, then forwards requests into Microsoft Graph. The result is not a separate malware channel but a believable cloud session that can query mail, contacts, files, and tenant metadata.

This matters because Microsoft Graph is a central control plane for Microsoft 365 data, so abused tokens can create broad visibility without obvious password theft. In NHI security terms, it sits at the intersection of token abuse, delegated access, and API-driven reconnaissance. Definitions vary across vendors on whether the proxy is classified as command-and-control, identity abuse, or cloud-native exfiltration, but the operational pattern is consistent: the attacker keeps the Microsoft session alive while moving the work elsewhere. NIST Cybersecurity Framework 2.0 frames this kind of risk through identity governance, access monitoring, and anomaly detection, which is why it is a useful external baseline for understanding the exposure (NIST Cybersecurity Framework 2.0).

The most common misapplication is treating Graph proxy traffic as routine automation, which occurs when defenders fail to distinguish legitimate application calls from token replay through attacker infrastructure.

Examples and Use Cases

Implementing controls against Microsoft Graph proxying rigorously often introduces more telemetry, stricter token handling, and additional investigation overhead, requiring organisations to weigh detection fidelity against operational friction.

• A stolen OAuth token is used to enumerate mailbox folders and recent messages through a proxy backend while the attacker avoids logging in from a new device.
• Compromised delegated access is used to pull OneDrive files and SharePoint content, then the backend reshapes requests so they resemble normal Microsoft 365 API activity.
• Threat actors stage persistence by reusing a still-valid token to query tenant objects after the initial intrusion is contained, similar to patterns discussed in the Microsoft OAuth Breach.
• Attackers combine Graph proxying with consent abuse and application permissions, a pattern that is also relevant in the Microsoft Midnight Blizzard breach analysis.
• Defenders validate whether API requests are consistent with the expected app registration, tenant, and user context using Microsoft Graph documentation and security logging guidance from Microsoft Graph.

These use cases often appear after token theft from phishing, malware, session hijacking, or compromised developer tooling rather than from a direct password reset event.

Why It Matters in NHI Security

Microsoft Graph proxying is dangerous because it turns a single stolen credential into broad, low-noise access across a tenant. That makes it especially relevant to NHI governance, where service identities, tokens, and delegated application access often outlive the security assumptions that created them. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 96% store secrets outside secrets managers in vulnerable locations, conditions that make token theft and replay easier to miss (Ultimate Guide to NHIs). Once proxying is in play, weak rotation, excessive privilege, and poor offboarding become direct incident drivers rather than abstract policy issues.

In practice, this term matters because defenders need to correlate API activity, token issuance, and tenant behavior rather than trusting a single successful authentication event. The right response includes tighter conditional access, token lifetime discipline, secret hygiene, and monitoring for anomalous Graph usage patterns, including activity that originates from unfamiliar infrastructure but still presents valid Microsoft identity artifacts. Organisational teams typically encounter the true scope of Microsoft Graph proxying only after mailbox abuse, file theft, or tenant reconnaissance has already been confirmed, at which point the technique becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams limit destructive Microsoft Graph operations?
• How should teams validate permissions for agent identities in Microsoft Graph?
• Microsoft Graph Permission Scope
• Microsoft Graph