Check My Knowledge — The Identity Threat Landscape
1. Why does MFA alone not stop AiTM credential phishing?
AiTM attacks disable MFA on the target account before signing in
The attacker's proxy captures the session token after the user completes MFA, then replays the valid token
AiTM attacks exploit a vulnerability in the Authenticator app that bypasses the MFA prompt
MFA does stop AiTM — the attack only works against accounts without MFA enabled
AiTM works because the attacker sits between the user and Entra ID, forwarding everything including the MFA challenge. The user successfully completes MFA, and the proxy intercepts the resulting session token. The defense requires phishing-resistant authentication (which cannot be proxied), compliant device requirements, and token protection — covered in EI2, EI4, and EI7.
2. Which token type represents the highest risk if stolen from a device?
Access token — it provides direct access to resource APIs
ID token — it contains the user's identity claims
Primary Refresh Token (PRT) — it enables SSO across all applications and all resources on the device
Refresh token — it can obtain new access tokens for a specific application
The PRT is the master key. It is bound to the device and enables single sign-on across every application. Stealing the PRT gives the attacker the equivalent of the user's full authenticated session across all resources — not just one application. PRT protection through Credential Guard and TPM is covered in EI7.
3. What is the primary reason identity security provides the highest return on security investment?
Identity is the control plane — every other security control depends on identity being secure
Identity products are less expensive than endpoint or network security products
Identity attacks are the only attack vector in cloud environments
Compliance frameworks require identity security controls but not other controls
If an attacker controls the identity, they bypass every downstream control — endpoint protection, email security, DLP, and data access controls all depend on the identity being legitimate. Strong identity security reduces the load on every other security layer. It is the foundation, not just one layer.
4. In the authentication flow, at which point does Entra ID evaluate conditional access policies?
Before the user enters their username, based on the requesting application
After the access token is issued, as a post-authentication check
Only when Identity Protection detects a risk signal during the sign-in
After primary authentication succeeds but before tokens are issued
Conditional access evaluation occurs after the user completes primary authentication (and before tokens are issued). This is the enforcement point — it evaluates the user, application, device state, location, and risk level to decide whether to grant access, require additional authentication, or block. This is covered in depth in EI3.
5. What is the primary defense against consent phishing?
Requiring MFA before any application consent is granted
Blocking user consent and implementing the admin consent workflow so only administrators can approve application permissions
Deploying Defender for Office 365 to block phishing emails that contain consent links
Enabling Identity Protection to detect unusual application consent patterns
Consent phishing exploits the user's ability to grant permissions to applications. Blocking user consent entirely and requiring administrator approval through the admin consent workflow removes the attack surface. Email filtering and detection are useful supplementary controls but do not address the root cause — the user's ability to consent. Application security is covered in EI9.
6. What is the minimum Entra ID license tier required for conditional access policies?
Entra ID Free — conditional access is available at all tiers
Entra ID P2 — conditional access requires the premium tier
Entra ID P1 — included with M365 E3 and Business Premium
Microsoft 365 E5 — conditional access is an E5-only feature
Conditional access requires Entra ID P1, which is included in M365 E3 and Business Premium. P2 (included in E5) adds Identity Protection for risk-based conditional access and PIM. The free tier only supports Security Defaults, which provides a baseline but no policy customization. The licensing model is mapped in EI0.3 and revisited in EI17 with architecture guidance per license tier.
7. At which stage of the identity kill chain does the attacker establish access that survives a password reset?
Stage 2 — Initial Access, because the stolen session token remains valid after a password change
Stage 3 — Persistence, because mechanisms like OAuth app consent and service principal credentials are independent of the user's password
Stage 4 — Privilege Escalation, because elevated roles cannot be removed by resetting a password
Stage 6 — Data Exfiltration, because downloaded data cannot be recovered by changing credentials
Stage 3 is where the attacker establishes persistence that survives common remediation. OAuth application consent grants give the attacker's application its own credentials, completely independent of the user's password. Service principal credential additions survive password resets, session revocations, and even MFA re-enrollment. This is why the kill chain response checklist in EI0.6 requires checking every stage during incident response, not just resetting the password.
8. Which Zero Trust principle does PIM (Privileged Identity Management) primarily implement?
Use least privilege access — PIM provides just-in-time, time-limited role activation instead of standing assignments
Verify explicitly — PIM evaluates all available signals before granting role access
Defense in depth — PIM adds an additional authentication layer for all user accounts
PIM implements least privilege by replacing standing (permanent) role assignments with eligible assignments that require explicit activation for a limited time period. The user only has the privileged role when they actively need it. PIM does incorporate verification (requiring MFA and justification for activation) and supports assume breach (by reducing the window during which a compromised admin account has active privileges), but its primary contribution to Zero Trust is eliminating standing privileges.
9. In case study 2 (consent phishing), why did the organization's MFA and device compliance controls not prevent the breach?
The attacker bypassed MFA using an AiTM proxy to capture the session token
The attacker compromised the user's device first, which was already compliant
The organization's conditional access policies had a gap that excluded the consent phishing application
The user was never compromised — they voluntarily granted the malicious application access through the consent prompt, which is a different control plane than authentication
Consent phishing does not require stealing the user's credentials or bypassing MFA. The user authenticates normally with their own credentials on their own device and then voluntarily clicks "Accept" on the consent prompt. The malicious application receives its own credentials (delegated permissions) through the consent grant. MFA and device compliance protect the authentication flow; consent governance protects the authorization flow. These are different control planes, which is why blocking user consent (EI9) is a separate and critical defense.
10. Why should diagnostic settings route Entra ID logs to a Log Analytics workspace even if you can view them in the Entra admin center?
The Entra admin center logs are incomplete and do not show all sign-in events
Microsoft requires log forwarding for compliance with all major frameworks
The Entra admin center retains logs for only 7-30 days, while a Log Analytics workspace provides longer retention, KQL querying at scale, and the ability to build Sentinel detection rules
The Entra admin center cannot display sign-in logs from non-interactive and service principal sign-ins
The Entra admin center provides a visual interface for browsing recent logs but retains data for only 7 days (free tier) or 30 days (P1/P2). A Log Analytics workspace provides configurable retention (up to 2 years), KQL querying across millions of events, and most critically, the ability to build Sentinel analytics rules that detect attacks in real time. Every detection rule in EI13 depends on sign-in and audit log data being available in a Log Analytics workspace. The Entra admin center does show all log types, but the retention and querying limitations make it insufficient for operational security.
💬
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
You've mapped the identity threat landscape and learned to read sign-in logs.
EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.
