Inside the Entra ID Exploit: How Hackers Hijacked MSPs

My terminal started screaming at 2:00 AM while I was running off tethered cellular data in a train station. Three separate alerts flashed across my monitoring dashboard. Different client companies. Different industries. But every single incident led back to a single shared root: their Managed Service Provider (MSP). Attackers had compromised the MSP's administrative tenant in Microsoft Entra ID, and from that central perch, they strolled directly into dozens of downstream corporate environments without cracking a single endpoint password.

This isn't a theoretical threat model sketched on a whiteboard. It just happened. Cybersecurity Dive confirmed that attackers abused Microsoft Entra ID partner configurations to target downstream MSP clients, pivoting quietly across tenant boundaries. If your organization relies on an MSP to handle IT, cloud infrastructure, or helpdesk tickets, your perimeter didn't break. Your identity architecture betrayed you.

We need to talk about what actually went wrong under the hood, how the exploit chain unfolded, and the exact telemetry you must inspect right now to verify whether someone is camping inside your tenant.

The Illusion of Tenant Isolation in Microsoft Entra ID

Microsoft sells Entra ID—formerly Azure Active Directory—as a multi-tenant identity fabric where cryptographic boundaries separate organizations. On paper, Company A cannot inspect or modify Company B's objects. That isolation holds up until you introduce delegated partner relationships.

MSPs run lean. They cannot afford to maintain individual named credentials across hundreds of client directories. To solve this, Microsoft built the Cloud Solution Provider (CSP) ecosystem. Through Delegated Admin Privileges (DAP) and its newer successor, Granular Delegated Admin Privileges (GDAP), MSPs gain cross-tenant administrative rights. Technicians log into their primary employer's Entra ID tenant, switch directories through the Partner Center portal, and instantly gain Global Admin or privileged role access inside your downstream tenant.

Think about that blast radius for a second.

A single tier-1 support desk employee at an IT service provider holds the digital keys to banks, regional hospitals, logistics hubs, and defense contractors. If a threat actor pops that single tier-1 technician's identity, they don't just own the MSP. They own everyone who signed a managed support contract with them. That is not zero trust. That is blind transitive trust.

Deconstructing the Attack Vector: Step-by-Step

How did the adversaries actually pull off this downstream intrusion? They didn't burn a seven-figure zero-day on hypervisor escapes. They used classic identity weaponization techniques combined with enterprise misconfigurations.

1. Adversary-in-the-Middle (AiTM) Phishing & Session Hijacking

The campaign began where modern cloud breaches usually start: session token theft. Attackers deployed an Adversary-in-the-Middle reverse proxy framework, such as Evilginx or Modlishka, spoofing the Microsoft 365 authentication portal. When the MSP technician typed their credentials and completed their push notification on Microsoft Authenticator, the proxy silently intercepted the HTTP response header containing the session cookie and the Primary Refresh Token (PRT).

Number matching didn't save them. Push notifications didn't save them. Because the proxy sat transparently between the user and Microsoft's legitimate servers, the authentication sequence succeeded cleanly. The attacker walked away with an authenticated session cookie and a valid bearer token valid for hours.

2. Partner Center Pivoting via Delegated Credentials

With a valid session token in hand, the adversary accessed the Microsoft Partner Center API (`api.partnercenter.microsoft.com`). Because the compromised account belonged to the MSP's "AdminAgents" security group, Entra ID granted the attacker automatic administrative delegation rights across all linked customer tenants.

The attacker queried the customer tenant directory through Microsoft Graph API using standard REST calls:

GET https://graph.microsoft.com/v1.0/tenantRelationships/delegatedAdminRelationships

Within seconds, the script returned a complete manifest of every downstream enterprise connected to that MSP: tenant IDs, subscription levels, verified domain names, and active administrator roles. The attacker cherry-picked targets based on company size and industry value.

3. Bypassing Downstream Conditional Access

Here is the fatal flaw that many engineers overlook: by default, downstream customer tenants often exempt partner tenant admins from their internal Conditional Access Policies. If your security team configured a policy mandating compliant corporate laptops or specific trusted egress IP ranges, those policies frequently fail to evaluate foreign administrative principals entering via DAP or GDAP unless explicitly enforced under External Identities settings.

The attacker pivoted from the MSP tenant into the downstream customer environments without tripping geographic anomaly alerts or device compliance blockers. To the downstream SIEM, the inbound traffic looked like standard, scheduled maintenance from the outsourced IT provider.

4. Establishing Ghost Persistence: Malicious Service Principals

Smart attackers know that MSP account sessions get terminated eventually. The moment they landed inside high-value customer tenants, they established independent persistence. They didn't create new human accounts with flashy names like "temp_admin"—that lights up audit logs immediately.

Instead, they registered a stealth Service Principal (an enterprise application) inside the victim's Entra ID directory. Using the compromised delegated admin privileges, they assigned the application terrifying Graph API permissions:

• Role: RoleManagement.ReadWrite.Directory (allows the app to grant itself any role silently)
• Role: Mail.ReadWrite (enables real-time harvesting of executive communications)
• Role: Directory.ReadWrite.All (full programmatic control of users, groups, and credentials)

They generated a custom RSA key pair, uploaded the public certificate as an application credential, and walked away. Even if the MSP discovered the phishing attack, revoked the technician's tokens, and rotated all passwords, the attacker's backdoor application remained active inside the customer tenant. Total severance between the original compromise and the active backdoor.

Why Modern Zero-Trust Architectures Stumbled

Let's strip away the corporate buzzwords. Vendors love selling zero trust as a magic software suite you buy off a shelf. You can install all the agents you want, but if your trust boundaries ignore external relationships, you don't have zero trust.

Zero trust mandates continuous validation: verify explicitly, apply least-privilege access, and assume breach. In this incident, organizations violated every single principle:

• Transitive Trust: Clients assumed the MSP's internal identity controls were as rigorous as their own. They weren't.
• Standing Privilege (DAP): Thousands of MSPs still run legacy DAP, which grants permanent, unmonitored Global Admin privileges rather than time-boxed, just-in-time access.
• Unmonitored Foreign Principals: Security Operations Centers (SOCs) religiously monitor internal user sign-ins while ignoring partner tenant service principals and cross-tenant sync events.

Running this blog on Dev Dominion taught me early on that outsourcing identity trust without continuous cryptographic verification is a fatal gamble. If you don't verify the infrastructure carrying your workload down to the individual session token, someone else will dictate your uptime and your security posture.

The Forensic Checklist: How to Audit Your Tenant Right Now

Stop reading for a moment, open your administrative terminal, and run these checks. Do not wait for your MSP to send you an all-clear email. Service providers often take days or weeks to uncover the full scope of a compromise.

Check 1: Audit Active Delegated Relationships

Log into the Entra admin center or run the Microsoft Graph PowerShell SDK to inspect active partner relationships. You are looking for deprecated DAP relationships that carry excessive permissions.

Run this command in an elevated PowerShell session:

Get-MgTenantRelationshipDelegatedAdminRelationship | Select-Object Id, DisplayName, Status, AccessDetails

If you see relationships with status Active and roles mapped to Company Administrator (Global Admin) without an expiration date, you are running legacy DAP. Terminate them immediately or force a transition to GDAP with zero standing privileges.

Check 2: Hunt for Newly Created Service Principals

Search your unified audit log for application registrations or credential additions performed by foreign security principals over the last 30 days. Run this KQL query in Microsoft Sentinel or Defender for Cloud Apps:

AuditLogs
| where OperationName in ("Add service principal", "Add service principal credentials", "Add app role assignment to service principal")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend TargetApp = tostring(TargetResources[0].displayName)
| where InitiatedBy.user.userPrincipalName has "#EXT#" or isempty(Actor)
| project TimeGenerated, OperationName, TargetApp, Actor, AdditionalDetails

Any service principal generated without an associated change ticket or approved deployment pipeline must be treated as hostile until proven otherwise.

Check 3: Inspect Cross-Tenant Access Settings

Review your External Identities configuration under Entra ID. Navigate to Cross-tenant access settings. Under Inbound access settings, inspect what you trust from your partner organizations.

Do you automatically trust their Multi-Factor Authentication? Do you trust their compliant devices? If your partner's technician authenticates with simple SMS MFA or an unmanaged personal phone, and your policy blindly trusts their MFA claims, their weak controls become your vulnerability. Enforce strict requirements or demand FIDO2 hardware tokens.

Four Mandatory Hardening Steps for Downstream Clients

If you manage an enterprise network that interfaces with third-party vendors, take these four defensive steps before the end of the week.

1. Eliminate Legacy DAP Completely

Microsoft introduced Granular Delegated Admin Privileges (GDAP) to replace DAP. GDAP operates on least privilege: you grant the MSP access to specific workloads (e.g., Exchange Administrator or Helpdesk Administrator) for a finite duration, such as 90 or 180 days. If your MSP insists on permanent Global Admin rights via DAP, push back. Refuse the contract terms until they comply with GDAP specifications.

2. Lock Down Cross-Tenant Inbound Policies

Configure Conditional Access to evaluate partner accounts with the same scrutiny applied to internal users. Mandate Phishing-Resistant MFA (FIDO2 or certificate-based authentication) for any privileged role, regardless of whether the account originates inside your directory or an external partner tenant.

3. Monitor the Graph API for AppRole Assignments

Set up automated alerting for high-risk application permissions. High-risk permissions include:

• AppRoleAssignment.ReadWrite.All
• RoleManagement.ReadWrite.Directory
• Directory.ReadWrite.All
• Mail.Read / Mail.ReadWrite

Whenever an enterprise application receives these rights, an alert must fire directly to your incident response team via an out-of-band channel like Signal or an isolated alerting system.

4. Implement Break-Glass Cloud Architecture

Always maintain two dedicated, cloud-only break-glass emergency accounts protected by hardware security keys stored in separate physical safes. These accounts must never sync from on-premises Active Directory, must bypass standard federated identity pipelines, and must trigger high-severity SIEM alerts whenever a technician touches them. If an attacker disables your primary identity federation or locks out your MSP, these accounts represent your only lifeline to recover your environment.

The Bottom Line

The Entra ID MSP campaign is a stark warning. The perimeter didn't dissolve when everyone started working remotely; it contracted down to the identity provider. When you outsource administrative tasks to a managed vendor, you aren't offloading operational risk. You are multiplying it across every other client on that vendor's roster.

Audit your partner relationships. Revoke standing privileges. Stop trusting external MFA claims without cryptographic hardware verification. Your cloud security is only as resilient as the weakest contractor holding an administrative token to your kingdom.