Azure and Entra ID Security

#How Azure Is Organised

What is this?One tenant is one organisation's instance of Entra ID: its users, groups, applications and policies. Azure resources hang off that tenant in a hierarchy.

Entra ID tenant (contoso.onmicrosoft.com)        ← identities, apps, Conditional Access, Entra roles
└── Root management group
    ├── Management group: Production             ← Azure Policy and RBAC set here inherit downwards
    │   └── Subscription: prod-payments           ← billing and blast-radius boundary (like an AWS account)
    │       └── Resource group: rg-api             ← lifecycle container
    │           └── Resources: VM, Storage account, Key Vault, SQL
    └── Management group: Sandbox

Why it mattersThere are two separate permission systems, and confusing them is a classic interview trap:

#Identities and How They Get Tokens

What is this?Everything in Entra ID signs in and receives OAuth tokens: an access token for one API (Microsoft Graph, Azure Resource Manager, Exchange), often with a longer-lived refresh token. Four kinds of identity matter:

In practiceOn a VM with a managed identity, any process (or an SSRF bug) can ask the metadata service for a token:

$ curl -s -H "Metadata: true" \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
{"access_token":"eyJ0eXAiOiJKV1Qi…","expires_in":"86399",
 "resource":"https://management.azure.com/","token_type":"Bearer"}      ← valid for the identity's RBAC roles

The required Metadata: true header blocks the simplest SSRF (one that can't set headers), much like AWS IMDSv2's token. It does not help if the attacker can run code on the VM, so keep the identity's roles narrow.

📰

Real incident — Microsoft AI research SAS token (2023). Microsoft researchers shared AI training data on GitHub using a link to an Azure Storage account. The link carried a shared access signature (SAS) token that granted full control of the entire storage account, not one folder, and didn't expire until 2051. Wiz found it exposed 38 TB, including workstation backups with secrets and internal Teams messages. SAS tokens are signed outside Entra ID, so they don't show up in identity reviews. Prefer user-delegation SAS with short expiry, or disable account-key access.

#Conditional Access, MFA and Privileged Access

What is this?Conditional Access is Entra ID's policy engine: if a sign-in matches conditions (user, app, location, device state, risk), then block it or require something (MFA, a compliant device, phishing-resistant authentication). It is the main control between a stolen password and your data.

How it works

Baseline policies interviewers expect you to name:

• Block legacy authentication (old protocols like IMAP and POP can't do MFA, so password spraying targets them).
• Require MFA for all users; phishing-resistant MFA for admins.
• Require a compliant or hybrid-joined device for admin portals.
• Block or restrict the device code flow where it isn't needed (see Storm-2372 below).
• Two or more break-glass accounts excluded from Conditional Access, with long random passwords or FIDO2 keys, monitored by alerts on any sign-in.

Privileged Identity Management (PIM) makes admin roles eligible rather than permanent: an admin activates Global Administrator for one hour, with a justification and possibly approval, and the activation is logged.

Last verified2026-10

Microsoft now enforces MFA for Azure management. Phase 1 (Azure portal, admin centres) reached all tenants in March 2025. Phase 2 (Azure CLI, PowerShell, infrastructure-as-code tools and REST API create/update/delete calls) began rolling out on 1 October 2025. Managed identities and service principals are excluded, which is one more reason attackers go after workload credentials.

#How Entra ID Gets Attacked

#Password spray and legacy test tenants

📰

Real incident — Midnight Blizzard at Microsoft (2024). Russia's SVR-linked group password-sprayed a legacy, non-production test tenant account that had no MFA. In that tenant they found an old test OAuth application that had elevated access to Microsoft's corporate tenant. They used it to create more malicious apps and grant them the Exchange full_access_as_app role, which can read every mailbox, then read email of senior leadership and security staff. Lessons: old test tenants and apps are in scope, app permissions are as powerful as admin roles, and they persist through password resets.

#Consent phishing (illicit consent grant)

The attacker registers a multi-tenant app called something like "Document Viewer" and sends a link to Microsoft's real consent page. The user clicks Accept, granting it Mail.Read and offline_access. No password is stolen and MFA is satisfied, but the attacker's app now reads the mailbox with a refresh token. Defences: restrict user consent to verified publishers and low-risk permissions, use the admin consent workflow, and review new grants.

#Device code phishing

The device code flow exists for TVs and command-line tools: the device shows a code, and you type it at microsoft.com/devicelogin on another device. An attacker starts the flow, sends the victim the code in a fake Teams meeting invite, and the victim signs in to the real Microsoft page, with MFA, on the attacker's behalf.

📰

Real incident — Storm-2372 (2025). Microsoft reported in February 2025 a campaign, active since August 2024, that used fake WhatsApp, Signal and Teams invitations to get government, defence, telecom and energy staff to enter attacker-generated device codes. With the captured tokens they read mail, and later switched to a client ID that let them register their own device in Entra ID for lasting access. Microsoft later linked the group to Midnight Blizzard. Defence: a Conditional Access policy blocking device code flow for everyone who doesn't need it.

#Token theft and hybrid identity

#Logging and Detection

What is this?Identity attacks show up in identity logs, not in VM logs. Know which log answers which question:

Last verified2026-10

Entra keeps sign-in and audit logs for 7 days on the free tier and 30 days with P1 or P2. For investigations, export them to a Log Analytics workspace or a SIEM from day one.

In practiceTwo Microsoft Sentinel (KQL) hunts worth knowing by heart:

// New consent grants to applications: consent phishing and Midnight Blizzard-style persistence
AuditLogs
| where OperationName == "Consent to application"
| extend Who = tostring(InitiatedBy.user.userPrincipalName), App = tostring(TargetResources[0].displayName)
| project TimeGenerated, Who, App, Result

// Successful device-code sign-ins: rare for normal users, Storm-2372's technique
SigninLogs
| where AuthenticationProtocol == "deviceCode" and ResultType == 0
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location   ← who really needs this?

🎯

On the job. In an Entra ID review, check these first:

• Who holds Global Administrator and Privileged Role Administrator, and is it permanent or PIM-eligible?
• Which apps hold high-impact Graph permissions (RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All, Mail.ReadWrite, full_access_as_app), and who owns them?
• Can users consent to apps themselves?
• Is legacy authentication blocked, and is device code flow restricted?
• Are break-glass accounts excluded from Conditional Access and alerting on use?
• Are there forgotten test tenants or test apps with production permissions?

#Responding to a Compromised Entra Account or App

A password reset alone is not enough: refresh tokens, app credentials, registered devices and consent grants all survive it.