Listen to this Post
Introduction:
Microsoft Intune’s Multi-Admin Approval (MAA) mode was designed as a critical control to prevent single administrators from making risky or unauthorized changes to managed devices and policies. The logic seems sound: require a second privileged account to approve any sensitive modification. However, this security feature harbors a fundamental architectural flaw. A compromised Global Administrator (GA) can simply create a new administrative account and use it to self-approve their own malicious changes, effectively rendering the entire approval process a theatrical exercise rather than a genuine security barrier.
Learning Objectives:
- Understand the inherent bypass mechanism where a Global Administrator can circumvent Intune’s Multi-Admin Approval.
- Learn how to detect this privilege escalation and self-approval pattern using Entra ID and Microsoft 365 audit logs.
- Implement proactive mitigations, including Privileged Identity Management (PIM) and conditional access policies, to close this security gap.
You Should Know:
1. The GA Self-Approval Bypass in Action
The core of the vulnerability lies in the role hierarchy. Multi-Admin Approval is designed to restrict standard Intune administrators, but it does not prevent a Global Administrator from creating or managing other administrators. A threat actor who compromises a GA account can follow a simple, undetectable-by-MAA process.
Step‑by‑step guide explaining what this does and how to use it:
– Step 1: Create a Secondary Admin. Using the compromised GA account, navigate to the Microsoft Entra admin center (entra.microsoft.com) → Identity → Users → All users. Create a new user account, or add an existing unprivileged user to an administrative role such as “Intune Administrator” or even a second GA.
– Step 2: Perform Malicious Action. As the original compromised GA, initiate a change that requires Multi-Admin Approval, such as deploying a custom configuration profile that disables security settings or pushes a backdoored application.
– Step 3: Self-Approve the Change. Log out of the original GA session and log in with the newly created or promoted admin account. Navigate to Intune → Tenant administration → Multi-Admin Approval → Pending approvals. Approve the request initiated in Step 2.
– Step 4: Clean Up. The attacker can optionally delete the temporary secondary admin account or leave it as a persistent backdoor.
2. Detecting the Bypass with Audit Logs
Since MAA provides no alert for this workflow, detection relies on correlating standard Entra ID and Intune audit logs. The key is identifying the “Create User” or “Add member to role” event immediately preceding a “Multi-admin approval completed” event.
Step‑by‑step guide explaining what this does and how to use it:
– Access Audit Logs: Go to Microsoft 365 Defender → Audit. Alternatively, use Entra ID → Audit logs.
– KQL Query for Detection: In Advanced hunting, run the following Kusto Query Language (KQL) query to identify the pattern of a user creation followed by an approval action within a short time window.
// Find user creation events let UserCreates = AuditLogs | where OperationName has "Add user" | project TimeCreated, UserId, OperationName, TargetUser = tostring(TargetResources[bash].userPrincipalName); // Find MAA approval events let Approvals = AuditLogs | where OperationName has "multi-admin approval completed" | project ApprovalTime = TimeCreated, ApproverId = UserId; // Correlate UserCreates | join kind=inner Approvals on $left.UserId == $right.ApproverId | where (ApprovalTime - TimeCreated) between (0min .. 30min) | project SuspiciousTime = TimeCreated, CreatorAccount = UserId, NewAdminAccount = TargetUser, ApprovalTime
- PowerShell Method: For a quick manual check, use the `Search-UnifiedAuditLog` cmdlet after connecting to Exchange Online PowerShell.
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) -Operations "Add user", "Multi-admin approval completed" -ResultSize 5000 |
Where-Object { $_.CreationTime -gt (Get-Date).AddMinutes(-30) }
3. Mitigation: PIM and Approval Workflow Hardening
The only way to prevent a GA from exploiting this is to ensure no permanent GA accounts exist and to enforce approval for role activation itself.
Step‑by‑step guide explaining what this does and how to use it:
– Implement Privileged Identity Management (PIM): Ensure all Global Administrator and Intune Administrator roles are eligible roles, not active. Navigate to Entra ID → Identity Governance → Privileged Identity Management. Configure roles to require approval and justification for activation.
– Configure Azure AD Conditional Access: Enforce a policy that requires a phishing-resistant authentication method (e.g., FIDO2 security key or Certificate-Based Authentication) and a compliant device for all users with privileged roles.
– Restrict Administrative Unit Scoping: Use Administrative Units to limit the scope of Intune administrators. A GA outside a specific unit cannot easily approve changes scoped to that unit without a role elevation that would trigger PIM alerts.
– Set up Alerting in Microsoft Sentinel: Create an analytics rule that triggers when a user is assigned a privileged role and that same user (or an account created by them) later completes a Multi-Admin Approval within a 1-hour window.
4. Windows/Linux Commands for Hardening Related Systems
While the bypass occurs in the cloud, the end result often involves deploying configurations to endpoints. Hardening endpoints prevents a successful attacker from moving laterally after the MAA bypass.
- Windows (Auditing & LAPS): Ensure Local Administrator Password Solution (LAPS) is deployed via Intune to prevent lateral movement. Use PowerShell to check LAPS status.
Get-LapsAADPassword -Identity "DeviceName" -IncludePasswords
- Linux (Intune Management): For Linux devices managed by Intune, restrict sudo access. Deploy a custom configuration profile that enforces a hardened `/etc/sudoers` file.
Example /etc/sudoers.d/intune_hardening %admins ALL=(ALL) ALL %sudo ALL=(ALL) /usr/bin/apt, /usr/bin/systemctl
What Undercode Say:
- Sovereignty of the GA Role: The Global Administrator role is the “keys to the kingdom.” Any security feature that relies on the GA being a benevolent actor is fundamentally flawed. Multi-Admin Approval is a control for standard admins, not a protection against a compromised GA.
- Defense in Depth is Non-Negotiable: Relying on a single control like MAA creates a false sense of security. Organizations must layer PIM with time-bound activation, conditional access policies requiring strong authentication, and continuous log monitoring to detect anomalous admin activity.
- Detection is the True Safety Net: Since prevention isn’t guaranteed (e.g., a phishing-resistant token can still be stolen via session cookie hijacking), organizations must prioritize detection logic that identifies the specific “create → approve” pattern, as this is the signature of this particular bypass.
Prediction:
As Microsoft continues to push Zero Trust principles, we will likely see a shift in how these administrative controls function. The future will likely involve “break-glass” workflows where even a GA cannot self-elevate without out-of-band approval from a separate system, or the introduction of “just-in-time” admin approvals that dynamically assign administrative rights for a single task. In the short term, the responsibility falls squarely on security architects to recognize that standard role-based access controls (RBAC) in Microsoft 365 require complex, layered configurations—not just a single checkbox—to be effective against modern identity-based threats.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Nathanmcnulty If – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
