When a new user account is created and immediately assigned an administrative role, it can indicate that an attacker with existing admin access is establishing a backdoor — a secondary account they control that they can use to maintain access even if the primary compromised account is detected and remediated.

Legitimate user creation followed by admin role assignment does happen in normal operations, but it's a relatively rare combination that should always have a clear business justification. An attacker who has obtained Global Admin access will often create a new account with a plausible-sounding name, assign it admin rights, and use it as a persistent foothold that doesn't draw attention the way continued use of the original compromised account might.

This is particularly dangerous because the new account may not be subject to the same monitoring, MFA policies, or Conditional Access rules as established accounts, especially if it's created just before those policies would apply.

• Backdoor admin account created with a plausible display name — designed to blend in as an IT service account or newly onboarded employee
• New account gives the attacker persistent Global Admin access that survives full remediation of the originally compromised account
• Attacker uses the backdoor to undo remediation — re-enable disabled accounts, restore revoked sessions, or undo Conditional Access changes
• Conditional Access policies may not apply to the new account immediately if policy assignments require manual group membership updates
• Account created, role assigned, then disabled — invisible in active user reports but ready to enable at any time
• From the new admin account, attacker can modify Conditional Access policies, disable MFA, add federated domains, or grant OAuth app permissions
• New account activity appears as a legitimate admin performing standard operations, with no anomalous sign-in indicators on the new identity itself
• Multiple backdoor accounts created simultaneously as insurance — even if one is discovered and deleted, others remain active

Legitimate scenarios for creating a user and immediately assigning an admin role include:

• Onboarding a new IT administrator or security engineer who requires admin access from day one
• Creating a break-glass or emergency access account as part of a governance review
• Setting up a service account that requires admin permissions for a specific integration or automation task
• Provisioning an account for a new managed service provider technician

In all cases, there should be a corresponding onboarding ticket, change request, or approval record. The account should follow your naming conventions, be assigned to a real person or documented service purpose, and be subject to MFA and Conditional Access from the outset.

• Identify who created the account — check the Entra ID audit log for the create user event and note the initiating admin account
• Check whether the new account follows your naming conventions and corresponds to a real person or service with an onboarding record
• Verify with your IT team or HR whether this account creation was expected and approved
• Review the admin account that created the user for signs of compromise — unusual sign-in location, recent MFA changes, session anomalies
• Check what admin role was assigned and how broad the permissions are — Global Admin assignment is significantly higher risk than a scoped role like Helpdesk Admin
• Look at whether the new account has had any sign-in activity since creation — if it was created and used immediately from an unusual IP, this is an active compromise indicator

1. If the account cannot be immediately verified as legitimate, disable it in Entra ID to prevent sign-in while you investigate
2. Revoke any admin role assignments from the account until it is confirmed as legitimate
3. Investigate the admin account that created the user — if that account shows signs of compromise, treat it as a full account compromise and revoke sessions, reset credentials, and review all recent actions
4. If the new account has already been used to sign in, review the sign-in logs and all actions taken during those sessions
5. After confirming the account is malicious, delete it from Entra ID and document the incident
6. Review all accounts created in the past 30-90 days and verify each one has a corresponding onboarding record or approved change request
7. Implement a process that requires manager or HR confirmation before new admin accounts become active, and consider using Privileged Identity Management (PIM) to require just-in-time activation for all admin roles

Overe Auto-Response: The User Account Created and Made Admin alert can be configured in Overe to trigger automatic session revocation or account block when this combination of events is detected. Review your Auto-Response settings under Org Config > Auto-Response — given the backdoor risk, an automated response for this alert type is strongly recommended.

Microsoft: What is Privileged Identity Management?

Microsoft: Best practices for Entra ID roles

Microsoft: Audit logs in Entra ID

After investigating a new admin account creation alert, review these related risk areas:

• Admins with Risky MFA Settings — newly created admin accounts should immediately be assessed for MFA strength
• New Federated Domain Added — attackers with admin access who create backdoor accounts often also add federated domains for even deeper persistence
• Break-Glass Accounts — review your legitimate emergency access accounts to ensure none have been tampered with or duplicated
• Apps with Admin Roles — check whether the new account was also used to grant admin permissions to any service principals
• Unprotected Admin Portals — verify that Conditional Access policies covering admin portal access apply to newly created accounts