// What is Entra ID?
Microsoft Entra ID (formerly Azure Active Directory / Azure AD) is Microsoft's cloud-based identity and access management platform. It provides authentication and authorisation for Microsoft 365, Azure resources, and thousands of third-party SaaS applications.
From a security perspective, Entra ID is one of the most targeted components of a Microsoft environment � compromising an account gives an attacker access to email, files, cloud resources, and potentially the entire tenant. Understanding how to investigate it is essential for any blue team analyst working in a Microsoft shop.
Entra ID is distinct from on-premises Active Directory (AD DS). Entra ID is cloud-native � it uses OAuth 2.0 and OpenID Connect, not Kerberos. Many organisations run hybrid identity � syncing on-prem AD to Entra ID using Microsoft Entra Connect. Attacks can pivot between the two.
// Tenant Architecture
Tenant
A dedicated Entra ID instance for an organisation. Each tenant has a unique Tenant ID (GUID). All users, groups, apps, and policies live inside a tenant.
Domain
Tenants have one or more verified domains (e.g. company.com). The default domain follows the pattern tenantname.onmicrosoft.com.
App Registrations
Applications registered to authenticate against Entra ID � each gets a Client ID. Compromised app credentials can grant persistent access without user interaction.
Service Principals
The runtime identity of an app registration within the tenant. Attacks targeting service principal credentials (client secrets, certificates) are equivalent to compromising an account.
// Users, Groups & Roles
User types
| Type | Description |
|---|---|
| Member | Internal user homed in the tenant � employees, service accounts |
| Guest | External user invited via B2B collaboration � often from partner organisations |
| Service Account | Non-interactive accounts for apps or automation � should have no MFA exemptions |
High-value Entra roles to monitor
| Role | Permissions | Risk |
|---|---|---|
| Global Administrator | Full control of the tenant � can reset any password, manage all settings | Critical � equivalent to Domain Admin |
| Privileged Role Administrator | Can assign any Entra ID role, including Global Admin | Critical � can elevate to Global Admin |
| Application Administrator | Can manage app registrations and service principal credentials | High � can create persistent backdoor apps |
| User Administrator | Can create and manage users, reset passwords | High � can create rogue accounts |
| Security Administrator | Manage security policies, read sign-in logs | Medium � read access to all security data |
// Sign-in Logs
Sign-in logs record every authentication attempt in the tenant. They are one of the most valuable sources for detecting account compromise, password spraying, and unusual access patterns.
Access via Entra admin centre ? Monitoring ? Sign-in logs or via Microsoft Sentinel (SigninLogs table).
Key fields
| Field | Description | What to look for |
|---|---|---|
| UserPrincipalName | The account that attempted sign-in | Accounts that don't normally sign in; disabled accounts |
| IPAddress | Source IP of the sign-in attempt | VPN, Tor, datacenter IPs; impossible travel |
| Location | Country/city derived from IP | Unusual countries; multiple countries in short window |
| ResultType | 0 = Success; non-zero = failure (specific error code) | Bulk failures from one IP � spray; success after failures � breach |
| ClientAppUsed | The app or protocol used | Legacy auth (IMAP, SMTP, MAPI) � bypasses MFA |
| ConditionalAccessStatus | success / failure / notApplied | notApplied = no CA policy matched � worth investigating |
| AuthenticationRequirement | singleFactorAuthentication vs multiFactorAuthentication | MFA bypassed � legacy auth or excluded user |
| DeviceDetail | OS, browser, device compliance state | Unmanaged or non-compliant devices accessing sensitive apps |
// Conditional Access
Conditional Access (CA) policies are Entra ID's Zero Trust enforcement engine. They evaluate signals at sign-in time � user, device, location, app, risk level � and decide whether to allow, block, or require additional verification.
Assignments (Conditions)
Who and what the policy applies to � users/groups, cloud apps, device platforms, locations, sign-in risk level.
Access Controls (Grant)
What the policy enforces � require MFA, require compliant device, require hybrid-joined device, block access.
Session Controls
Controls applied during the session � sign-in frequency, browser persistent sessions, app enforced restrictions.
Report-only mode
Evaluates policy without enforcing it � useful for testing impact before enabling. Check sign-in logs for what-if results.
CA exclusions are a common attack target. Attackers who compromise a Global Admin will add themselves (or a new account) to CA policy exclusions � bypassing MFA for their sessions. Audit CA exclusions regularly and alert on any changes.
// MFA & Authentication
MFA methods (strongest to weakest)
| Method | Phishable? | Notes |
|---|---|---|
| FIDO2 / Passkeys | No | Gold standard � hardware key or device biometric, cryptographically bound to the site |
| Windows Hello for Business | No | Device-bound biometric/PIN � not transferable |
| Microsoft Authenticator (number matching) | Resistant | Requires user to enter a number from sign-in screen � defeats blind push approval attacks |
| TOTP (Authenticator app code) | Yes | Can be phished via AiTM proxy in real time |
| SMS / Voice call | Yes | Vulnerable to SIM swapping and SS7 attacks � weakest MFA option |
Legacy authentication
Legacy authentication protocols (Basic Auth over IMAP, SMTP, MAPI, POP3, ActiveSync) do not support modern authentication or MFA. They are a common target for credential stuffing and password spraying � an attacker can authenticate with just a password even if MFA is enabled. Block legacy authentication with a Conditional Access policy.
// Identity Protection
Microsoft Entra ID Protection uses machine learning to detect risky sign-ins and risky users. It assigns risk levels (Low / Medium / High) based on behavioural signals.
| Detection | What triggers it |
|---|---|
| Atypical travel | Sign-in from two geographically distant locations in an impossible timeframe |
| Anonymous IP address | Sign-in from Tor exit node or known anonymising proxy |
| Unfamiliar sign-in properties | New device, location, or ASN not seen for this user before |
| Password spray | Pattern matching credential stuffing or low-and-slow spray |
| Leaked credentials | User's credentials found in breach database |
| Malware-linked IP | Sign-in from IP associated with a botnet or malware C2 |
| Suspicious inbox manipulation | Forwarding rules added or emails moved � post-compromise data collection |
// Privileged Identity Management
Privileged Identity Management (PIM) implements just-in-time privileged access. Instead of permanently assigning high-privilege roles (like Global Administrator), PIM lets users be eligible for a role and activate it on demand for a limited time with justification.
| Assignment type | Behaviour |
|---|---|
| Eligible | User must activate the role, provide justification, and go through approval/MFA � activation is time-limited (e.g. 1 hour) |
| Active | Role is permanently assigned � no activation needed. Should be minimised for high-privilege roles. |
Alert on PIM activations. Any Global Administrator or Privileged Role Administrator activation outside of a change window is worth investigating. Attackers who compromise an eligible account will activate the role before taking action.
// Common Attack Vectors
| Attack | Description | Detection signal |
|---|---|---|
| Password Spray | Low-and-slow attempts across many accounts with common passwords | Many 50126 errors across different UserPrincipalNames from same IP |
| AiTM Phishing | Adversary-in-the-middle proxy captures session token � bypasses MFA | Successful sign-in after suspicious link click; token used from different IP than user |
| MFA Fatigue | Flood user with push notifications until they accidentally approve | Multiple MFA denial events followed by approval from same user |
| Consent Phishing | Victim grants OAuth permissions to attacker-controlled app � gives persistent access without credentials | New app granted high-privilege consent; app not in approved list |
| Token Theft | Steal a valid access/refresh token and replay it from attacker infrastructure | Session from a new IP/ASN not matching user's normal pattern immediately after sign-in |
| Legacy Auth Spray | Use legacy protocols that bypass MFA | IMAP or SMTP authentication without MFA; many failures then success |
// KQL Hunting Queries
These queries run in Microsoft Sentinel against the SigninLogs and AuditLogs tables.
Password spray detection
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0
| summarize FailedAttempts = count(), TargetAccounts = dcount(UserPrincipalName) by IPAddress
| where TargetAccounts > 10
| sort by FailedAttempts descSuccessful login after multiple failures
let failures = SigninLogs
| where TimeGenerated > ago(1h) and ResultType != 0
| summarize FailCount = count() by UserPrincipalName, IPAddress;
SigninLogs
| where TimeGenerated > ago(1h) and ResultType == 0
| join kind=inner failures on UserPrincipalName, IPAddress
| where FailCount > 5
| project TimeGenerated, UserPrincipalName, IPAddress, Location, FailCountLegacy authentication sign-ins
SigninLogs
| where TimeGenerated > ago(24h)
| where ClientAppUsed in ("IMAP", "POP3", "SMTP", "Exchange ActiveSync", "Exchange Online PowerShell", "MAPI over HTTP")
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, ClientAppUsed, IPAddress, LocationGlobal Admin role assigned
AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName == "Add member to role"
| where TargetResources has "Global Administrator"
| project TimeGenerated, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
TargetUser = tostring(TargetResources[0].userPrincipalName)