It Took Five Minutes to Turn a Standard User Into a Global Admin
Huntress demonstrated that a standard Microsoft 365 user with no admin privileges can be escalated to Global Administrator in under six minutes by exploiting common identity misconfigurations — specifically, an over-privileged service account owning an enterprise application, lack of MFA enforcement, and standard users being permitted to access the Azure portal. Analysis of 12,000+ M365 tenants revealed that over 60% were missing at least half of recommended security controls, with MFA gaps, over-privileged accounts, and admin restriction failures being the most prevalent issues. The article argues that continuous, automated identity posture management is essential because configuration drift creates exploitable windows far shorter than the 24-hour scan cycles of traditional tools.
Detection / Hunteropenrouter
What Happened
Security researchers at Huntress showed that a regular Microsoft 365 user account — the kind an attacker might steal in a phishing email — can be turned into a full administrator in about five minutes. They did this not by using advanced hacking tools, but by taking advantage of common security settings that were left misconfigured, such as a service account with too many permissions and no multi-factor authentication (a second login step). After reviewing over 12,000 Microsoft 365 organizations, they found that more than 60% were missing at least half of the recommended security settings. This matters because attackers don't need sophisticated techniques when basic security gaps are left open — they just walk through an unlocked door. Organizations should review their Microsoft 365 identity settings, enforce multi-factor authentication for all accounts, restrict admin privileges, and consider using automated tools that continuously monitor and fix security gaps rather than relying on periodic manual checks.
Key Takeaways
- A standard Microsoft 365 user with no admin access was escalated to Global Administrator in 5.5 minutes using only basic misconfigurations and an AI-assisted script — no novel exploits required.
- Across 12,000+ M365 tenants assessed by Huntress, 60%+ were missing at least half of recommended identity security controls; 66% lacked recommended MFA configurations, 55% allowed standard users to perform admin-level functions, and 59% had insufficiently restricted admin accounts.
- The attack chain exploited an over-privileged service account tied to an enterprise application, created new credentials for it, and used an AI model to generate a privilege escalation script.
- Approximately 35% of identity-based incidents Huntress SOC responded to in the past six months could have been prevented by fully deployed ISPM policies; Huntress expects that figure to reach 80%.
- Configuration drift in M365 is an exposure problem, not just maintenance — Microsoft reports the average time from initial intrusion to lateral movement is 48 minutes, while many posture tools only rescan on 24-hour cycles.
Affected Systems
- Microsoft 365 / Microsoft Entra ID (Azure AD) tenants
- Enterprise applications registered in Entra ID with excessive API permissions
- Service accounts with over-privileged application roles
Attack Chain
An attacker obtains credentials for a standard (non-admin) Microsoft 365 user, likely through phishing. Using those credentials, the attacker accesses the Azure portal (permitted because standard users were not restricted from it), identifies a service account tied to an enterprise application with excessive permissions, and creates a new credential (secret or certificate) for that application. The attacker then uses an AI assistant to generate a privilege escalation script in plain English, which leverages the application's elevated API permissions to assign the attacker's standard account the Global Administrator role. The entire chain from initial access to full admin took approximately 5.5 minutes in the demonstration.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules, queries, or signatures are provided in the article. The article is a product awareness and research findings piece focused on identity posture management rather than providing specific detection logic.
Detection Engineering Assessment
EDR Visibility: Low — This is a cloud identity attack — EDR agents on endpoints would not directly observe the privilege escalation within Microsoft Entra ID. EDR might capture the initial phishing payload or the execution of the AI-generated script on a user's workstation, but the core abuse happens through cloud APIs. Network Visibility: Low — The attack uses legitimate Microsoft Graph API and Azure portal traffic over HTTPS. Network monitoring would see connections to Microsoft endpoints but could not distinguish malicious API calls from normal administrative activity without application-layer inspection of Graph API operations. Detection Difficulty: Hard — The attack uses legitimate Microsoft 365 functionality and APIs, making it difficult to distinguish from normal administrative activity. Detecting the creation of new application credentials, role assignments via API, and unusual privilege escalation patterns requires deep Entra ID audit log analysis and behavioral baselining that most organizations do not perform continuously.
Required Log Sources
- Microsoft Entra ID (Azure AD) audit logs
- Microsoft Entra ID sign-in logs
- Microsoft 365 audit logs (Unified Audit Log)
- Azure activity logs for application registration and credential changes
- Conditional Access policy change logs
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Hunt for new credentials (secrets or certificates) added to existing enterprise application service principals, especially by non-admin users or outside of normal change windows — this would indicate T1098.001 activity. | Microsoft Entra ID audit logs filtered for 'Add service principal credentials' and 'Update application' events | Privilege escalation | Medium — legitimate application credential rotation by admins would trigger this; correlate with change management records and user role. |
| Hunt for Global Administrator or other highly privileged role assignments made via Microsoft Graph API rather than through the Entra admin center UI, especially by accounts that were recently standard users. | Entra ID audit logs for 'Add member to role' events, cross-referenced with the actor's prior role assignments | Privilege escalation | Low to Medium — legitimate admin role assignments via API are less common and should be correlated with approved change tickets. |
| Hunt for standard (non-admin) users accessing the Azure portal or Microsoft Entra admin center — this indicates the 'Restrict access to Microsoft Entra admin center' control is not enforced. | Entra ID sign-in logs filtered for resource 'Microsoft Azure Management' or 'Windows Azure Service Management API' with non-admin user principal names | Discovery and initial access | Medium — some developers or IT staff may legitimately access the Azure portal without admin roles. |
| Hunt for enterprise applications with excessive Microsoft Graph API permissions (e.g., Application-level RoleManagement.ReadWrite.Directory or Directory.ReadWrite.All) that have recently had credentials added. | Microsoft Graph API application permission inventory and Entra ID audit logs for credential addition events | Privilege escalation preparation | Low — applications with Directory.ReadWrite.All or RoleManagement.ReadWrite.All at Application level should be rare and closely monitored. |
| Hunt for Conditional Access policy modifications or MFA enrollment exceptions that were created and never reverted — look for policies in report-only mode beyond 30 days or per-user MFA exclusions that remain open. | Entra ID audit logs for Conditional Access policy changes and per-user MFA configuration changes | Defense evasion / persistence | High — legitimate policy tuning and temporary exceptions are common; focus on aged exceptions beyond a defined SLA. |
Control Gaps
- MFA not enforced for all users including standard accounts — allows phishing-obtained credentials to be used directly
- Standard users permitted to access the Azure / Entra admin center — enables reconnaissance of service accounts and applications
- Users allowed to register applications — enables creation of rogue apps with attacker-controlled credentials
- Service accounts with excessive enterprise application permissions — provides a privilege escalation path via credential creation
- No continuous monitoring for configuration drift — gaps introduced by changes go undetected for days or weeks
- Conditional Access policies left in report-only mode indefinitely — controls exist but are never enforced
Key Behavioral Indicators
- Non-admin user accounts accessing Microsoft Entra admin center or Azure management API endpoints
- New application credentials (secrets/certificates) created on existing service principals by users who are not the application owner
- Role assignment events where the actor was a standard user within the preceding 24 hours
- Enterprise applications with Application-level Graph API permissions exceeding what the app's function requires
- Conditional Access policies remaining in report-only mode beyond a defined threshold (e.g., 30 days)
- Per-user MFA exclusions that remain open beyond a ticket SLA
- Guest users configured with the same access level as member users
False Positive Assessment
- Medium — The attack uses legitimate Microsoft 365 administrative functionality and APIs, making it difficult to distinguish from normal admin activity. Detection of new application credentials, role assignments, and portal access by standard users will generate false positives in environments where developers or IT staff legitimately interact with Entra ID applications. Behavioral baselining and correlation with change management records are necessary to reduce noise.
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting. Review all Microsoft Entra ID user role permissions and identify any standard users with the ability to register applications or access the Azure/Entra admin center.
- Consider enforcing MFA for all users in the tenant, including standard accounts — review the Entra ID authentication methods policy and disable weak methods (SMS, voice) where supported by your licensing tier.
- Audit all enterprise applications and service principals for excessive Microsoft Graph API permissions, especially Application-level RoleManagement.ReadWrite.Directory and Directory.ReadWrite.All; remove unused credentials from service principals.
- If your licensing tier supports it, consider enabling the 'Restrict access to Microsoft Entra admin center' control to prevent non-admin users from browsing directory objects.
Infrastructure Hardening
- Evaluate whether Conditional Access policies can be deployed to restrict Azure management API access to privileged roles only.
- Consider implementing continuous identity posture monitoring rather than relying on periodic manual reviews — configuration drift creates exploitable windows measured in minutes, not days.
- Review and tighten default user role permissions in Entra ID: set 'Users can register applications' to No, 'Users can create security groups' to No (if not needed), and restrict guest user access levels.
- If applicable to your environment, consider implementing Privileged Identity Management (PIM) for just-in-time admin access rather than standing Global Administrator assignments.
- Evaluate whether a formal onboarding checklist for new M&A tenants or inherited environments should include a baseline Secure Score assessment and remediation sprint.
User Protection
- Consider rolling out phishing-resistant MFA methods (e.g., Authenticator with number matching, FIDO2 security keys) for all users, prioritizing admin and service accounts.
- Evaluate whether legacy authentication protocols (SMTP, IMAP, POP, etc.) can be fully blocked in your tenant to reduce phishing-driven credential theft effectiveness.
- If your organization supports bring-your-own-device scenarios, consider implementing Conditional Access policies that block downloads on unmanaged devices.
Security Awareness
- Consider incorporating cloud identity misconfiguration scenarios into existing security awareness training — emphasize that attackers escalate from standard user to admin using basic gaps, not advanced exploits.
- If your team manages M365 environments for multiple clients or business units, consider establishing a shared baseline hardening checklist that is applied on every new tenant onboarding.
- Evaluate whether your change management process includes a security review step for MFA exceptions and Conditional Access policy changes, with automated reminders for exceptions that exceed a defined age.
MITRE ATT&CK Mapping
- T1078.004 - Valid Accounts: Cloud Accounts
- T1098.001 - Account Manipulation: Additional Cloud Credentials
- T1098 - Account Manipulation
- T1069.003 - Permission Groups Discovery: Cloud Groups
- T1525 - Implant Internal Image
- T1078 - Valid Accounts
Additional IOCs
- Command Lines:
- Purpose: Privilege escalation script generated by an AI assistant to escalate a standard M365 user to Global Admin | Tools:
AI assistant,Microsoft Graph API| Stage: Privilege escalation
- Purpose: Privilege escalation script generated by an AI assistant to escalate a standard M365 user to Global Admin | Tools:
