Module 11 — Check My Knowledge (20 questions)
1. How does an AiTM proxy bypass MFA?
The proxy sits between the user and Microsoft's login page, forwarding the authentication in real time. The user completes MFA successfully against the real Microsoft service. The proxy captures the session token after MFA succeeds. MFA protected the authentication but not the token — the attacker replays the token without needing MFA again.
It cracks the MFA code using brute force
It disables MFA on the account
It intercepts the SMS MFA code in transit
AiTM captures the session token after MFA succeeds. MFA is completed — it just does not protect the token.
2. You reset a compromised user's password but do NOT revoke their tokens. Is the attacker locked out?
No. Active refresh tokens remain valid for up to 90 days regardless of password changes. The attacker continues accessing M365 services using the stolen token. Always revoke tokens AND reset the password.
Yes — password reset invalidates all tokens
Yes — but only after 1 hour when the access token expires
Only if conditional access is configured
Password reset does NOT revoke tokens. Revoke tokens explicitly or the attacker retains access.
3. Which preventive control definitively stops AiTM token replay?
Conditional Access Token Protection (token binding). It binds the session token to the device that completed authentication. Replayed tokens from a different device are rejected. FIDO2 security keys also prevent AiTM by refusing to authenticate to non-legitimate domains.
Standard MFA with Authenticator push
IP-based conditional access
Longer passwords
Token binding and FIDO2. Standard MFA does not prevent AiTM.
4. The first thing you do when investigating a potential AiTM incident is:
Run scoping queries: how many users received the phishing email, how many clicked, how many have sign-ins from suspicious IPs. This establishes the scope within 10 minutes and determines whether you are dealing with an isolated compromise or a campaign.
Disable the compromised user's account immediately
Read the phishing email in detail
Write a report for the CISO
Scope first. 10-minute scoping workflow: recipients → clickers → compromised accounts. Then decide on containment urgency based on scope.
5. UrlClickEvents shows ActionType = "ClickBlocked" for a user. Should you investigate this user?
Document as a targeted user but do not investigate for compromise. Safe Links blocked the navigation — the user did not reach the AiTM proxy and did not enter credentials. However, they were targeted and may receive future phishing attempts. No immediate investigation needed — lower priority than ClickAllowed users.
Yes — investigate fully as a potential compromise
Ignore — blocked means safe
Reset their password as a precaution
ClickBlocked = protected. Document as targeted, do not investigate for compromise. Prioritise ClickAllowed users.
6. Two sign-ins 2 minutes apart: one from the user's office IP, one from an unknown IP. Both show MFA satisfied. What is this?
AiTM token replay. The first sign-in is the user authenticating through the AiTM proxy (office IP because the proxy forwarded the auth). The second is the attacker replaying the captured token from their infrastructure. Both show MFA because the token already passed MFA.
Normal VPN failover
The user has two devices
A false positive
Classic AiTM signature: two IPs, rapid succession, both MFA satisfied.
7. An attacker created an inbox rule that deletes emails containing "security alert." You need to send a password reset notification to the user. What do you do first?
Remove the malicious inbox rule BEFORE sending the notification. Otherwise the rule deletes the password reset email before the user sees it. Alternatively, communicate the new password via phone or in person.
Send the notification — the user will see it
Disable the user's email access first
The inbox rule will not affect system emails
Remove the rule first, or use a non-email channel. Inbox rules affect all email regardless of sender.
8. The attacker registered a new Authenticator app on a compromised account. You revoked tokens and reset the password. Is containment complete?
No. The attacker's Authenticator registration survives token revocation and password reset. If they obtain the new password, they can authenticate using their own MFA method. Remove the attacker's MFA registration from the account's authentication methods.
Yes — all tokens are revoked
Yes — the password is different
Only if the account is disabled
MFA registration persists. Remove it or containment is incomplete.
9. Wave 2 used internal phishing from j.morrison's mailbox. Why did Safe Links not block these emails?
Internal emails from trusted senders receive less aggressive URL scanning by default. Safe Links policies may not apply to internal-to-internal email unless explicitly configured. The sender (j.morrison) is a trusted internal identity — the phishing URL in the email may not be scanned with the same rigour as URLs from external senders.
Safe Links was disabled during the incident
The URLs were on a different domain than Wave 1
Internal emails are never scanned by Safe Links
Internal sender trust reduces scanning rigour. Enable Safe Links for internal email to close this gap.
10. Your detection rule fires 23 minutes after the first compromise. How do you reduce this?
Convert the scheduled rule to an NRT rule. NRT rules evaluate data as it is ingested — detection latency drops from the schedule interval (typically 5-15 minutes + ingestion lag) to 1-3 minutes. For AiTM initial access detection, every minute of delay is a minute the attacker uses to establish persistence.
Reduce the scheduled rule interval to 1 minute
Detection lag cannot be reduced
Add more data connectors
NRT rules for critical detections. 1-3 minute detection vs 15-30 minutes for scheduled rules.
11. The CISO asks: "Could this happen again?" What is the correct answer?
Yes — until token binding or FIDO2 is deployed. Blocking the attacker's specific infrastructure does not prevent AiTM from a different attacker using different infrastructure. The root cause is the absence of token binding. Deploy it to definitively prevent recurrence.
No — we blocked the attacker's IP
Only if users click phishing links
More security training will prevent it
Yes, until the root cause (no token binding) is remediated. IOC blocking does not prevent technique reuse with new infrastructure.
12. You are containing the CFO's account during quarterly financial close. The CFO needs email access. What do you do?
Execute token revocation + password reset + IP block (lower-impact containment). Verify via Livestream that no new attacker sign-ins occur. If containment holds, the CFO re-authenticates with the new password and resumes work. Only disable the account if lower-impact actions fail. Document the risk decision.
Always disable the account regardless of business impact
Wait until financial close is complete to contain
Only reset the password — skip token revocation
Risk-based containment. Lower-impact actions first. Escalate to full disable only if needed. Document the decision. Operational judgment.
13. Your email analysis shows SPF pass, DKIM pass, and no DMARC policy on the phishing domain. ThreatTypes is empty. Is the email safe?
No. SPF and DKIM verify domain ownership — they do not verify legitimacy. An attacker who registers a domain and configures DNS correctly will pass SPF and DKIM. Empty ThreatTypes means no detection at delivery time — common for new infrastructure. The email is dangerous despite passing authentication checks.
Yes — SPF and DKIM pass means it is authenticated
Yes — no threats were detected
Maybe — check DMARC alignment
Email authentication = domain ownership, not legitimacy. Attackers configure DNS correctly. Empty ThreatTypes = no detection, not no threat.
14. What is the correct containment order for an AiTM compromise?
1. Revoke all refresh tokens (highest priority — cuts attacker's active access). 2. Reset password (prevents re-authentication with stolen password). 3. Block attacker IP via conditional access (prevents any remaining token use from that IP). 4. Disable account (only if steps 1-3 are insufficient). This order prioritises speed of impact: token revocation is immediate and addresses the most urgent threat (active token use).
Reset password first, then revoke tokens
Disable account first, investigate later
Block the IP first, then reset the password
Revoke tokens → reset password → block IP → disable account (if needed). Token revocation is the highest-priority action.
15. Deploy Rule 8 (AiTM Attack Chain) AND the individual rules (1-7). Why both?
Individual rules detect each attack stage independently — providing faster detection at each step but with more false positives. Rule 8 fires only when the complete chain occurs in sequence — providing near-zero false positives but later detection (only after all stages complete). Both together: fast detection from individual rules + high-confidence confirmation from the chain rule. Defence in depth for detection.
Rule 8 replaces all individual rules
Only deploy Rule 8 — fewer false positives
Only deploy individual rules — faster detection
Both. Individual rules = fast detection per stage. Chain rule = high-confidence multi-stage confirmation. Defence in depth applied to detection engineering.
16. What artifacts should you have after completing this module?
Four artifacts: (1) AiTM Investigation Playbook — step-by-step decision tree from alert to closure. (2) 8 AiTM Detection Rules — deployable KQL analytics rules. (3) IR Report Template — reusable executive report structure. (4) Hardening Checklist — post-AiTM hardening with blast radius, cost, and GRC mapping.
A certificate of completion
Notes from the module
A list of KQL queries
4 deployable artifacts. The playbook, detection rules, IR template, and hardening checklist are production-ready assets, not study notes.
17. The post-incident review identifies that containment took 34 hours. What is the process fix?
Define a containment trigger: on confirmed AiTM compromise, execute containment immediately for that account. Investigate the full campaign scope on a parallel track. Do not wait for complete scope assessment before containing known compromises.
Hire more SOC analysts for faster investigation
Complete the full investigation before any containment
Automate containment with no human review
Contain immediately on confirmation. Investigate scope in parallel. Every hour of delay = active attacker access.
18. Token protection costs £0 in licensing and requires ~4 hours to deploy. It would have prevented the entire incident. Why was it not deployed before the incident?
The risk was not prioritised. Available-but-not-deployed controls are a common security posture gap. The PIR action item: conduct a review of all available security controls in the tenant that are not deployed, assess each against the current threat landscape, and prioritise deployment. This is the value of post-incident reviews — they surface gaps that were invisible before the incident.
It was too expensive
It was not available until recently
IT was not aware of the feature
Risk prioritisation gap. Available-but-not-deployed controls are invisible until an incident proves their necessity. The PIR surfaces this gap and drives remediation.
19. You recommend blocking external inbox rule forwarding. The CFO forwards email to their personal Gmail. What do you do?
Notify the CFO before enabling. Explain the security risk. Recommend alternatives (Outlook mobile, OWA). If the CFO accepts the risk, create a documented exception and flag as a GRC compliance gap. Never block without communication. Never skip hardening because of one exception.
Create a silent exception for the CFO
Do not implement the recommendation
Block it immediately without notice
Communicate, explain, recommend alternatives, document the exception and its compliance impact.
20. What is the complete operational cycle this module demonstrates?
Detect → Investigate → Contain → Eradicate → Report → Harden → Engineer Detections → Hunt. The incident triggered detection. Investigation confirmed the compromise. Containment stopped the attacker. Eradication removed persistence. The report informed stakeholders. Hardening prevents recurrence. Detection engineering creates rules for future automated detection. Hunting validates the controls and searches for variants. Each step feeds the next in a continuous improvement cycle.
Detect → Contain → Close
Investigate → Report → Done
Alert → Respond → Forget
The complete cycle: detect → investigate → contain → eradicate → report → harden → detect (improved) → hunt. Continuous improvement driven by real incidents.
