User Created and Made Admin

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.

A backdoor admin account gives an attacker persistent privileged access that survives remediation of the original compromise. From a newly created admin account, the attacker can: access all Microsoft 365 services, read any user's email, modify Conditional Access policies, add federated domains, disable MFA for other users, grant OAuth permissions, and — critically — undo any remediation actions taken against their primary access vector.

The account may be created with a display name designed to blend in (e.g., a fake IT service account, a common name format), and may initially appear inactive while the attacker waits to use it. Some attackers create the account, grant permissions, and then disable it until needed — so it won't appear in active user reports.

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