Module 14 — Check My Knowledge (20 questions)
1. What is the default lifetime of an M365 refresh token?
90 days. The refresh token persists for up to 90 days — independent of password changes. It can obtain new access tokens without re-authentication. This is why stolen refresh tokens provide persistent access for weeks or months after the initial compromise.
60 minutes
24 hours
7 days
90 days. This is why token revocation is essential — password reset alone does not invalidate the refresh token.
2. You reset a user's password. Their stolen refresh token is still valid. Why?
Password reset invalidates the password — not existing tokens. The refresh token has its own lifecycle independent of the password. It was issued before the password change and remains valid until it expires (90 days) or is explicitly revoked via Revoke-MgUserSignInSession.
The password reset failed
MFA was not configured
Password reset always revokes tokens
Password ≠ token. Independent lifecycles. Always revoke tokens AND reset password.
3. What is the "revocation gap"?
The period (up to 90 minutes) after refresh token revocation where active access tokens remain valid. The access token was issued before revocation and cannot be directly invalidated under standard configuration. It expires naturally. During this gap, the attacker retains access. CAE strict mode or temporary account disable closes the gap.
The time it takes to revoke a token
The delay between password reset and MFA prompt
The gap between two sign-in events
Up to 90 minutes where access tokens survive after refresh token revocation. CAE or account disable closes it.
4. Token replay via API appears in which log table?
AADNonInteractiveUserSignInLogs. API-based token replay generates non-interactive sign-in events — NOT interactive sign-in events. An analyst who only queries SigninLogs misses all API token replay. Always check both tables.
SigninLogs only
AuditLogs
CloudAppEvents
AADNonInteractiveUserSignInLogs. Always check both interactive and non-interactive tables.
5. A sign-in shows AuthenticationRequirement = "singleFactorAuthentication" from a non-corporate IP in an MFA-required tenant. What does this indicate?
Token replay. The session used a token that already passed MFA — no new MFA challenge was required. In a tenant that requires MFA for all users, a single-factor auth from an external IP means the attacker is using a pre-authenticated token.
MFA was bypassed by a CA exclusion
The user has an MFA exemption
The sign-in failed
Token replay. Pre-authenticated token — no new MFA needed. SingleFactorAuth + external IP + MFA-required tenant = replay.
6. 20 days after containment, the attacker accesses the mailbox again. What is the most likely persistence mechanism?
An OAuth application consent granted during the original compromise. OAuth apps authenticate with their own client credentials — independent of the user's password and tokens. They survive password reset, token revocation, and MFA re-registration. Must be specifically revoked in Entra ID Enterprise Applications.
The refresh token was not revoked
The attacker guessed the new password
CAE was not enabled
OAuth application persistence. Independent credentials. Survives all standard containment. Must be specifically revoked.
7. What does CAE strict mode do that standard CAE does not?
CAE strict mode enforces IP location evaluation on every access. If the token was issued from one IP and is used from a different IP, strict CAE triggers re-evaluation and may block the access. Standard CAE evaluates critical events (password change, account disable) but does not check IP changes. Strict mode catches token replay where the attacker's IP differs from the user's original IP.
Standard and strict are identical
Strict mode blocks all external access
Strict mode requires FIDO2
IP location evaluation on every access. Catches token replay from different IPs. Standard CAE does not check IP changes.
8. Token protection requires devices to be:
Entra ID joined (or hybrid joined) with TPM 2.0. The token is bound to the device's cryptographic key stored in the TPM. Unmanaged/BYOD devices without Entra join cannot satisfy token binding — they are blocked from protected applications. Assess your managed vs unmanaged device ratio before deploying.
Running Windows 11 only
Any device with a browser
Enrolled in Intune only
Entra ID joined + TPM 2.0. Unmanaged devices cannot satisfy token binding.
9. 40% of sign-ins come from BYOD devices. Can you deploy token protection tenant-wide?
Not immediately. Deploy to managed devices first using a device filter in the CA policy. Plan BYOD enrollment. Expand coverage as enrollment progresses. Do not block 40% of your workforce without an alternative access path.
Yes — security overrides convenience
Token protection works on any device
BYOD devices are not at risk
Staged deployment. Managed devices first. BYOD enrollment plan. Do not block 40% of sign-ins.
10. You revoke tokens at 15:00. Non-interactive sign-ins continue until 15:45, then stop. What happened?
The revocation gap. The access token issued before revocation remained valid until 15:45 (its natural expiry). After expiry, the application tried to use the revoked refresh token — and failed. Containment worked with a 45-minute delay. CAE strict mode or temporary account disable would close this gap.
The revocation failed for 45 minutes
The attacker re-authenticated
A different token was in use
Revocation gap. Access token valid until natural expiry. Containment worked — with delay.
11. What is the correct containment sequence for token-based attacks?
1. Revoke all refresh tokens. 2. Reset password. 3. Revoke OAuth application consents. 4. Close the revocation gap (CAE or temp disable). 5. Remove device registrations. Step 3 is what most containment procedures miss — OAuth apps survive steps 1 and 2.
Reset password only
Disable account only
Revoke tokens only
5-step sequence. OAuth consent revocation (step 3) is the most commonly missed step.
12. A non-interactive sign-in shows UserAgent = "python-requests/2.28" from a non-corporate IP. What is this?
Scripted token abuse. The attacker is using a Python script to access M365 resources via API using a stolen token. Legitimate M365 applications use recognisable user agents (Outlook, Edge, Chrome). Python/curl/empty user agents from external IPs are attacker tools. This is conclusive evidence of programmatic token replay.
A legitimate Python application
A browser extension
Non-interactive sign-ins are always benign
Scripted token abuse. Python user agent from non-corporate IP = attacker tool using stolen token.
13. Eradication gaps cascade. Explain using Modules 11-13.
Module 12: AiTM compromise. Eradication missed an inbox rule on a.patel. Module 13: The surviving inbox rule enabled a BEC attack 3 weeks later. Module 14: A surviving OAuth consent enabled token replay 20 days after containment. Each eradication gap enables a subsequent attack. The eradication verification checklist and 7-day follow-up check exist to prevent this cascade.
Each module is an independent incident
Eradication gaps do not affect future incidents
Only Module 12 had eradication gaps
Each gap enables the next attack. M11 gap → M12 BEC. M11 gap → M13 token replay. Eradication verification prevents the cascade.
14. What artifacts should you have after completing this module?
Four artifacts: (1) Token investigation playbook — identifying replay, tracing lifecycle, 5-step containment. (2) 5 token detection rules — deployable KQL analytics. (3) Token containment checklist — revocation sequence with gap handling. (4) CAE/Token Protection deployment guide — staged rollout with blast radius, prerequisites, and verification.
A certificate
Study notes
A list of queries
4 deployable artifacts: playbook, detection rules, containment checklist, deployment guide.
15. Rule 3 (Token Used After Password Reset) detects what specific pattern?
A successful sign-in that occurs after a password reset but uses single-factor authentication (no new MFA). This means the sign-in used a pre-existing token issued before the reset. If the user genuinely re-authenticated with their new password, MFA would be required. Single-factor after reset = token replay with a pre-reset token that was not revoked.
Failed password reset attempts
Password reuse detection
MFA bypass detection
Single-factor auth after password reset = pre-existing token that survived the reset. Token not revoked.
16. How does token protection prevent AiTM token replay?
Token protection binds the token to the device's TPM-stored cryptographic key. When the attacker replays the token from a different device, the resource server checks the device binding — the attacker's device does not match, so the token is rejected. The token is valid but unusable from any device other than the one that completed the original authentication.
It blocks the AiTM proxy domain
It requires re-authentication every 5 minutes
It encrypts the token
Device binding via TPM. Token valid only on the original device. Attacker's device fails the binding check.
17. You need to close the revocation gap immediately. CAE is not enabled. What do you do?
Temporarily disable the user account. Account disablement forces resource servers to reject the access token within 5-15 minutes — much faster than the 90-minute natural expiry. Re-enable the account after the access token's natural lifetime has passed. The user re-authenticates with the new password.
Wait 90 minutes
Reset the password again
The gap cannot be closed without CAE
Temp account disable. Forces token rejection within minutes. Re-enable after access token expiry.
18. What is the relationship between Modules 11, 12, and 13?
Sequential phases of the same attack chain. M11 (AiTM) = initial access and credential theft. M12 (BEC) = financial fraud using the compromised access. M13 (Token Replay) = the persistence mechanism that maintains access across all phases. Each module teaches a different investigation skill set for a different phase of the attack. Together they cover the complete lifecycle from entry to impact to persistence.
Three independent, unrelated incidents
M13 replaces M11 and M12
They all teach the same skills
Sequential attack chain. M11 = entry. M12 = objective. M13 = persistence. Different phases, different skills, one attacker.
19. AppId in a non-interactive sign-in matches an OAuth app consented during the compromise. What does this confirm?
The attacker's persistence mechanism. The OAuth application was consented during the original compromise and is now authenticating with its own credentials — independent of the user. The application has direct API access to the mailbox. This survives password reset and token revocation. Revoke the consent in Entra ID Enterprise Applications immediately.
A legitimate application is accessing the mailbox
The user re-consented to the app
AppId is not relevant to investigation
OAuth persistence confirmed. Independent credentials. Revoke the consent immediately.
20. What is the complete set of detection rule packs across Modules 11-13?
M11: 8 AiTM detection rules (phishing click→signin, token replay, inbox rule, MFA modification, mass email read, internal phishing, CA policy modification, AiTM chain sequence). M12: 6 BEC detection rules (financial keyword inbox rules, thread hijacking, mass email read, bank detail change, evidence destruction, BEC chain). M13: 5 token replay rules (multi-IP session, non-interactive from external, token after password reset, new device refresh token, bulk resource access). Total: 19 deployable detection rules covering the complete attack chain.
8 rules total across all three modules
Each module has the same rules
Detection rules are only in Module 10
19 detection rules total: 8 AiTM + 6 BEC + 5 token replay. Complete kill chain coverage from initial access through persistence.
