AD6.13 Check My Knowledge

Reset the password — Password reset alone doesn't terminate active sessions. The attacker remains signed in until the token expires.

Contact the user to warn them — User communication is important but not the first step. Containment comes before communication.

Revoke all sessions (Revoke-MgUserSignInSession) — this terminates the attacker's active access immediately, then reset the password to prevent re-entry — Correct. Session revocation is step 1 because it terminates current access. Password reset is step 2 because it prevents future access. The sequence matters: revoke first, then reset.

Check the sign-in log to understand the scope — Understanding scope is important but containment takes priority. The attacker is active NOW. Contain first, investigate second.

Execute the full AD6.2 compromised account procedure — The user didn't enter credentials. Safe Links blocked the click before the phishing page loaded. Full containment is unnecessary.

Thank the user for reporting. Scope other recipients (who else got the email?). Block the sender domain. Purge the email from all mailboxes. Log it as a blocked phishing attempt — Correct. Safe Links contained the threat. Your response is preventive: ensure no other users are exposed, block the sender, and remove the email from mailboxes where it hasn't been opened yet. The user's credentials are safe.

No action needed — Safe Links handled it — The email is still in other users' inboxes. Scoping, blocking, and purging prevent additional clicks.

Reset the user's password as a precaution — The click was blocked. No credentials were entered. A password reset disrupts the user without security benefit.

Notify the finance team immediately — verify all payment changes by phone, not email. The attacker has vendor names, invoice amounts, and bank details. A fraudulent payment redirect request could arrive at any time — Correct. Financial fraud prevention is the most urgent BEC-specific step. The attacker may have already sent a payment redirect email that's sitting in the finance team's inbox. The notification needs to reach finance BEFORE they process any suspicious payment instructions.

Write the incident report — Important but not urgent. Financial fraud prevention takes priority over documentation.

Block the phishing sender domain — Prevents future phishing but doesn't address the current BEC risk.

Check for additional compromised users — Important for scope but doesn't prevent the immediate financial fraud.

Yes — stop the forwarding as fast as possible — Deleting destroys evidence. The rule's details are needed for the incident report, GDPR assessment, and potential law enforcement referral.

Yes — but screenshot it first — A screenshot is better than nothing but a CSV export is more comprehensive.

No — leave it active and monitor what gets forwarded — Leaving it active means the attacker continues receiving forwarded emails.

Export the rule details to CSV (Get-InboxRule → Export-Csv), then DISABLE the rule (not delete). Disabling stops the forwarding immediately while preserving the rule as evidence. Delete only after the incident report is complete and evidence is secured — Correct. Disable stops the harm. Export preserves the evidence. The rule's creation timestamp, conditions, and destination address prove what the attacker did.

Full investigation now — high severity can't wait — Full investigation at 22:00 risks mistakes from fatigue. Basic containment + SOC escalation is more effective.

Wait until Monday — the managed SOC will catch it — 60 hours of potential attacker access is too long. Even if the SOC catches it, basic containment from you takes 1 minute.

From your phone: revoke sessions immediately (1 minute). Forward the alert to the managed SOC for overnight investigation. Complete the full AD6.2 procedure at 09:00 Saturday or Monday morning — Correct. Minimum viable containment (session revocation) eliminates active access. The SOC provides overnight monitoring. Full investigation happens when you're at your desk with proper tools.

Disable notifications to avoid after-hours disruption — Removing visibility doesn't remove the threat.

Re-enable the account immediately — the user needs to work — Re-enabling before checking for persistence could give the attacker re-entry.

Automatic attack disruption detected a high-confidence attack and disabled the account automatically. Complete AD6.2 steps 3-5 (review MFA, remove persistence, document), then re-enable the account in the Action center once the account is clean — Correct. Disruption handled containment. You handle remediation. Don't re-enable until attacker persistence is removed.

The account was hacked and Microsoft locked it — reset the password and re-enable — Password reset alone doesn't address MFA persistence or inbox rules. Full AD6.2 steps 3-5 required.

Escalate to Microsoft support — automatic disruption is a system error — Automatic disruption is an intentional security feature, not an error. It detected a real attack pattern.

Potentially — vendor contact names are personal data, and bank details may relate to individuals (sole traders). Forward Section 5 (GDPR Assessment) of your incident report to your DPO or legal counsel for the notification decision within 72 hours of discovery — Correct. You identify the data exposure and assess the risk. Legal makes the notification decision. Your documentation enables them to decide within the 72-hour window.

No — vendor data is business data, not personal data — Named individuals' data (contact person names) is personal data regardless of business context.

Yes — immediately notify the ICO without consulting legal — ICO notification is a legal decision. Forward your assessment to legal/DPO first.

Only if money was actually transferred — GDPR notification is based on personal data exposure, not financial loss. Data was exfiltrated regardless of whether fraud occurred.

To assign blame for the incident — Post-incident reviews identify improvements, not blame. The goal is to make the next incident less likely or faster to contain.

To write a longer report for management — The incident report (AD6.9) serves management. The post-incident review serves the security program.

To justify the security budget — Budget justification is a secondary benefit, not the primary purpose.

To answer three questions: How did we detect it (improve monitoring), What could prevent it (improve controls), What would we do differently (improve procedures) — turning every incident into specific improvement actions that make the security program stronger — Correct. Each incident produces 2-5 improvement actions. After 4 incidents across a year, patterns emerge that drive strategic security investments backed by incident data.