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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers token, secret, and NHI abuse patterns that enable Graph proxying. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access control applies to stolen-token API activity in cloud tenants. |
| NIST Zero Trust (SP 800-207) | AL3 | Zero Trust assumes tokens can be abused and requires continuous verification. |
| NIST SP 800-63 | IAL2 | Assurance guidance helps distinguish strong identity proofing from replayable token use. |
| OWASP Agentic AI Top 10 | LLM-04 | Agentic tool access and token misuse overlap with proxy-based cloud abuse patterns. |
Constrain tool access and audit delegated actions when agents or automations touch Microsoft APIs.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
