In this section
Check My Knowledge
Scenario 1. Your organization deploys MFA using Microsoft Authenticator push notifications for all users. A security vendor demonstrates an AiTM credential phishing attack against one of your test accounts and successfully gains access despite MFA being enforced. Your CISO asks why MFA failed. What do you tell them?
AiTM attacks disable MFA on the target account before signing in a
AiTM does not disable MFA. The attack works precisely because MFA stays active — the user completes MFA normally, unaware that a proxy is relaying the entire session. Disabling MFA would require directory-level access the attacker doesn't have at this stage.
The attacker's proxy captures the session token after the user completes MFA, then replays the valid token b
Correct. AiTM works because the proxy sits between the user and Entra ID, forwarding everything including the MFA challenge. The user completes MFA successfully, and the proxy intercepts the resulting session token. The defense requires phishing-resistant authentication (FIDO2 or passkeys, which cannot be proxied), compliant device requirements, and token protection — covered in EI2, EI4, and EI7.
AiTM attacks exploit a vulnerability in the Authenticator app that bypasses the MFA prompt c
There is no vulnerability in the Authenticator app being exploited. The user approves the MFA prompt legitimately — they just don't know they're authenticating through a proxy. The weakness is in the MFA method (push notifications can be approved without verifying the destination), not in the application software.
MFA does stop AiTM — the attack only works against accounts without MFA enabled d
This is the dangerous misconception. MFA does not stop AiTM because the user completes MFA normally — the proxy relays everything transparently. AiTM specifically targets MFA-protected accounts because the proxy intercepts the post-MFA session token. Section 0.4 covers this attack pattern in detail.
Scenario 2. Your incident response team is investigating a compromised account. They've reset the password, revoked all refresh tokens, and re-enrolled MFA. The attacker regains access within hours. Which token type most likely enabled the attacker to persist despite these remediation steps?
Access token — it provides direct access to resource APIs a
Access tokens expire in 60-90 minutes. While an attacker could use a stolen access token briefly, it would not survive for hours after a password reset and token revocation. Access tokens are short-lived by design.
ID token — it contains the user's identity claims b
ID tokens are consumed by the client application during authentication and are not used for ongoing resource access. They do not provide the persistence mechanism an attacker needs to maintain access after remediation.
Primary Refresh Token (PRT) — it enables SSO across all applications and all resources on the device c
Correct. The PRT is device-bound and enables SSO across every application. If the attacker extracted the PRT before remediation, they can continue generating new access tokens for any resource without re-authenticating. PRT theft survives password resets and refresh token revocation because the PRT operates at a different layer. PRT protection through Credential Guard and TPM is covered in EI7.
Refresh token — it can obtain new access tokens for a specific application d
Refresh tokens for a specific application would be revoked by the token revocation the IR team performed. The attacker would lose access to that application. The PRT is the more dangerous token because it operates across all applications and isn't revoked by the same mechanism as application-specific refresh tokens.
Scenario 3. Your organization is deciding where to invest its next security budget. The CISO is comparing identity security controls against endpoint detection, email security, and network monitoring. She asks you to justify why identity should get priority funding. What is the strongest argument?
Identity is the control plane — every other security control depends on identity being secure a
Correct. If an attacker controls the identity, they bypass every downstream control. Endpoint protection trusts the identity to authorize remediation actions. Email security trusts the identity to set policy. DLP trusts the identity to determine access levels. Compromising the identity layer undermines the entire security stack. This is why identity provides the highest return on investment — it protects every other layer.
Identity products are less expensive than endpoint or network security products b
Cost is not the strongest argument. Entra ID P2 is included in E5 licensing but represents significant per-user cost at scale. The argument for identity investment is architectural — identity is the foundation — not financial.
Identity attacks are the only attack vector in cloud environments c
Identity attacks are the dominant vector but not the only one. Endpoint compromise, supply chain attacks, and application vulnerabilities all exist in cloud environments. The argument is that identity is the most impactful investment, not the only threat.
Compliance frameworks require identity security controls but not other controls d
Major compliance frameworks (NIST, ISO 27001, SOC 2, PCI DSS) require controls across multiple domains — not just identity. Compliance-driven arguments are weaker than architectural arguments because they position security as a checkbox exercise rather than a risk reduction strategy.
Scenario 4. A junior engineer asks you when Conditional Access policies are evaluated during the authentication flow. They've been troubleshooting a policy that doesn't seem to fire and want to understand the timing. What do you tell them?
Before the user enters their username, based on the requesting application a
CA evaluation cannot occur before authentication because the policy engine needs to know who the user is, what device they're on, what application they're accessing, and what risk signals apply. None of that information is available before the user authenticates.
After the access token is issued, as a post-authentication check b
If CA evaluation happened after token issuance, the user would already have access before the policy could block them. CA is an inline enforcement point — it must evaluate before the token is issued, not after. This is the key architectural distinction covered in Section 0.2.
Only when Identity Protection detects a risk signal during the sign-in c
CA evaluates on every sign-in that matches policy conditions, regardless of whether Identity Protection detects risk. Risk-based CA policies use Identity Protection signals as one input, but standard CA policies (like requiring MFA for all users accessing a specific app) fire without any risk detection.
After primary authentication succeeds but before tokens are issued d
Correct. CA evaluation occurs after the user proves their identity (username + password or passwordless) but before Entra ID issues any tokens. This is the enforcement point — the policy engine evaluates user, application, device, location, and risk signals to decide whether to grant, challenge, or block. If the policy requires MFA, the user completes the additional challenge before tokens are issued. This timing is critical for understanding why a policy might not fire — if the conditions don't match the sign-in context at evaluation time, the policy is skipped.
Scenario 5. A user reports receiving an email asking them to approve access for a "Microsoft Teams Integration" application. The user clicked the link and approved the consent prompt. Your SOC analyst discovers the application now has Mail.Read and Files.Read.All permissions on the user's mailbox. What should have prevented this?
Requiring MFA before any application consent is granted a
MFA protects the authentication flow, not the authorization flow. The user authenticated normally with MFA and then voluntarily approved the consent prompt. MFA cannot distinguish between a legitimate consent and a malicious one — the user is the one making the decision. These are different control planes, as covered in Section 0.7.
Blocking user consent and implementing the admin consent workflow so only administrators can approve application permissions b
Correct. Consent phishing exploits the user's ability to grant permissions to applications. Blocking user consent entirely and requiring admin approval through the admin consent workflow removes the attack surface. The user would see a message saying admin approval is required instead of a consent prompt. Application governance is covered in EI9.
Deploying Defender for Office 365 to block phishing emails that contain consent links c
Email filtering is a useful supplementary control but does not address the root cause. Consent phishing links can arrive through Teams messages, social media, or any communication channel — not just email. Blocking the consent mechanism at the identity layer is more effective than filtering at the email layer.
Enabling Identity Protection to detect unusual application consent patterns d
Identity Protection detects sign-in and user risk, not application consent anomalies. While Defender for Cloud Apps can detect unusual consent activity, this is a detection control (after the fact), not a prevention control. Blocking user consent prevents the attack entirely rather than detecting it after permissions have been granted.
Scenario 6. You're planning the EI course lab environment and need to decide which Entra ID license tier to use. Your developer tenant supports E5 licensing. A colleague suggests E3 would be sufficient. What capability gap would E3 create for the course exercises?
E3 does not include Conditional Access, which is required for every policy exercise a
E3 includes Entra ID P1, which provides Conditional Access. P1 is sufficient for standard CA policies. The gap is elsewhere — in the P2-exclusive features that E3 does not include.
E3 does not support Microsoft Sentinel integration for log analysis b
Sentinel integration depends on the Azure subscription and diagnostic settings configuration, not on the M365 license tier. E3 tenants can route logs to Sentinel identically to E5 tenants. The gap is in the identity features themselves, not the analytics layer.
E3 includes P1 but not P2 — missing Identity Protection risk-based policies, PIM, and access reviews c
Correct. E3 includes Entra ID P1 (Conditional Access, basic MFA, self-service password reset). E5 includes P2, which adds Identity Protection (risk-based CA policies, user and sign-in risk detection), PIM (just-in-time privileged access), and access reviews. Three core modules in this course (EI5, EI6, EI12) depend on P2 features. The licensing stack is mapped in Section 0.3.
E3 does not include the Microsoft Graph API permissions needed for PowerShell exercises d
Graph API access is governed by application permissions and admin consent, not by the M365 license tier. E3 tenants have full Graph API access. The gap between E3 and E5 is in the identity security features the API exposes, not in API access itself.
Scenario 7. You're explaining the identity kill chain to your SOC team. An analyst asks: "If we reset the compromised user's password immediately, doesn't that stop the attack?" At which stage 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 a
Session tokens from Stage 2 can be revoked through Continuous Access Evaluation (CAE) or explicit token revocation. While a stolen session token is dangerous in the short term, it does not provide the persistence that survives coordinated remediation. The more dangerous stage is where the attacker creates independent credentials.
Stage 3 — Persistence, because mechanisms like OAuth app consent and service principal credentials are independent of the user's password b
Correct. Stage 3 is where the attacker creates persistence mechanisms that survive standard remediation. OAuth application consent grants give the attacker's application its own credentials, independent of the user's password. Service principal credential additions survive password resets, session revocations, and MFA re-enrollment. This is why the kill chain in Section 0.5 emphasizes checking every stage during response — resetting the password addresses Stage 2 but leaves Stage 3 persistence intact.
Stage 4 — Privilege Escalation, because elevated roles cannot be removed by resetting a password c
Elevated roles can be removed by an administrator regardless of password state. Role assignments are directory objects, not credentials. Privilege escalation makes the attacker more dangerous while they have access, but it is not the persistence mechanism that survives remediation. The persistence is in Stage 3.
Stage 6 — Data Exfiltration, because downloaded data cannot be recovered by changing credentials d
Data exfiltration is an impact, not a persistence mechanism. Once data is exfiltrated, changing credentials doesn't recover it — but that's a consequence, not a reason the attacker maintains access. The question is about maintaining access, which is Stage 3 persistence.
Scenario 8. Your organization is implementing Zero Trust for identity. The security architect proposes deploying PIM for all administrator roles. Which Zero Trust principle does PIM primarily implement?
Use least privilege access — PIM provides just-in-time, time-limited role activation instead of standing assignments a
Correct. PIM implements least privilege by replacing standing (permanent) role assignments with eligible assignments that require explicit activation for a limited time. The administrator only has the privileged role when they actively need it. PIM does incorporate verification (requiring MFA and justification for activation) and supports assume breach (reducing the window of active privileges), but its primary Zero Trust contribution is eliminating standing privileges. This mapping is covered in Section 0.6.
Verify explicitly — PIM evaluates all available signals before granting role access b
PIM does require verification (MFA and justification) during activation, but this is a secondary characteristic. Conditional Access is the primary verify-explicitly control — it evaluates user, device, location, application, and risk on every sign-in. PIM's distinctive contribution is converting permanent access to just-in-time access, which is least privilege.
Assume breach — PIM detects compromised admin accounts and automatically revokes access c
PIM does not detect compromised accounts — that is Identity Protection's function. PIM supports assume breach indirectly by reducing the window during which a compromised admin account has active privileges, but its primary function is eliminating standing access, not detecting compromise.
Defense in depth — PIM adds an additional authentication layer for all user accounts d
PIM applies to privileged role activation, not to all user accounts. It is not an authentication layer — it is an authorization control that governs when and how long administrative roles are active. Defense in depth is a general security principle, not one of the three Zero Trust principles.
Scenario 9. You're analyzing the Midnight Blizzard breach from Section 0.7 with your team. An analyst says: "This wouldn't happen to us because we enforce MFA on all accounts." What is wrong with that assessment?
The attacker used an AiTM proxy to bypass MFA on the compromised account a
Midnight Blizzard did not use AiTM. The initial access was a password spray against a test tenant account that had no MFA configured. The attacker then pivoted through a legacy OAuth application that had excessive permissions. This is a different attack path than AiTM — covered in detail in Section 0.7.
MFA was enforced but the attacker compromised the MFA registration process b
The Midnight Blizzard breach did not involve MFA registration compromise. The initial compromise was a test account without MFA. The subsequent pivot used an OAuth application with its own credentials, which operates outside the user authentication flow entirely.
The attacker exploited a zero-day vulnerability in Entra ID that bypassed all authentication controls c
No zero-day was involved. Midnight Blizzard exploited configuration weaknesses — a test account without MFA and a legacy OAuth application with excessive directory permissions. These are governance failures, not platform vulnerabilities. Every defense that would have stopped this attack was available at the time.
The initial compromise was a test account without MFA, and the attacker then pivoted through a legacy OAuth application with excessive directory permissions — MFA on user accounts doesn't govern application-level access d
Correct. "We enforce MFA on all accounts" has two gaps this breach exploited. First, test and legacy accounts are often excluded from MFA policies — the Midnight Blizzard attacker found one. Second, once the attacker pivoted to the OAuth application's own credentials, user-level MFA was irrelevant because the application authenticates with its own service principal. Application governance (consent review, permission auditing, credential rotation) is a different control plane. Section 0.7 maps each defensive gap to the module that teaches the remediation.
Scenario 10. You've completed your lab setup and want to verify that Entra ID logs are flowing to Sentinel. You run a KQL query against SigninLogs and get zero results, but you can see sign-in events in the Entra admin center. What is the most likely cause?
The Entra admin center shows different data than Sentinel — they use separate log pipelines a
The Entra admin center and Sentinel receive the same underlying data. The admin center displays it through its built-in viewer; Sentinel receives it through the diagnostic settings routing. If both are configured correctly, they show the same events. The issue is likely in the routing configuration or timing, not in data separation.
Your Azure subscription is in a different region than the Entra ID tenant, preventing log routing b
Cross-region routing works — the Log Analytics workspace region does not need to match the Entra ID tenant location. Microsoft routes diagnostic data globally. Region mismatch can affect latency slightly but does not prevent log delivery.
Diagnostic settings were recently configured and initial log population takes 15-30 minutes to propagate to the Log Analytics workspace c
Correct. After configuring diagnostic settings, there is a propagation delay of 15-30 minutes (sometimes up to an hour) before data appears in the Log Analytics workspace. The Entra admin center shows data immediately because it reads from the identity platform directly. Sentinel reads from the Log Analytics workspace, which receives data through the diagnostic settings pipeline. This delay is a one-time setup issue — once flowing, data arrives within minutes. Section 0.10 covers this verification step.
The SigninLogs table requires Entra ID P2 licensing to receive data in Sentinel d
SigninLogs data flows to Sentinel regardless of the Entra ID license tier. P1 and P2 both support diagnostic settings routing. P2 adds additional tables (RiskyUsers, UserRiskEvents) but does not gate basic sign-in log routing. The issue is timing, not licensing.
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
Thank you — your feedback has been received.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.