The Credential Harvest
Incident Brief
Incident ID: SOC-2026-04-001 Date/Time: Wednesday, 15 April 2026, 09:42 UTC Alert Source: DET-SOC-002 (MFA fatigue detection) Assigned to: You
At 09:42 UTC, DET-SOC-002 fires for a.rahman@northgateeng.com (Senior Procurement Manager). The detection shows 8 MFA push denials followed by 1 approval within a 4-minute window. The successful authentication originated from IP 198.51.100.77 (ASN 14061, DigitalOcean, Netherlands).
The user’s normal sign-in pattern shows UK residential IPs exclusively.
Your Investigation
Work through each phase using the investigation methodology from Module 7 (PB-SOC-001). Document your KQL queries and findings at each step.
Phase 1: Triage (15 minutes)
Run DET-SOC-002’s query to confirm the MFA fatigue pattern. What are the exact timestamps of the denials and the approval?
Check
SigninLogsfor the successful authentication. What application did the adversary access? What was the user agent?DET-SOC-001 should also have triggered for this sign-in. Confirm: does the IP 198.51.100.77 appear in the user’s 14-day sign-in baseline?
Triage decision: Is this a True Positive, False Positive, or Benign Positive? What severity do you assign? Justify your decision.
Phase 2: Scope Assessment (30 minutes)
Check
OfficeActivityfor the compromised user within 2 hours of the successful sign-in. Did the adversary create any inbox rules? What do the rules do?Check
MailItemsAccessedfor the user. How many emails were accessed from the adversary IP? Over what time window?Check
AuditLogsfor OAuth consent grants by this user during the compromise window. Were any applications consented to?Check
AADServicePrincipalSignInLogs— is any application authenticating independently of the user?Run DET-SOC-008 through DET-SOC-014 queries for this user manually. Which email detection rules would have fired?
Additional information: At 10:15 UTC — 33 minutes after the initial compromise — DET-SOC-001 fires for j.blake@northgateeng.com (Finance Director) from the same IP address 198.51.100.77. No MFA fatigue detected for this user — the sign-in succeeded on the first MFA attempt.
How did the adversary authenticate as j.blake without triggering MFA fatigue? What are the possible explanations?
Check j.blake’s mailbox for inbox rules and email access from the adversary IP. Is the scope expanding?
Phase 3: Containment (20 minutes)
List every containment action you would take, in order. For each, specify who approves it and the expected blast radius.
The adversary compromised a Senior Procurement Manager and a Finance Director. What is the business risk of this combination? What specific BEC scenario should you warn the finance team about?
Write the user notification for a.rahman. What do you tell them? What actions do you ask them to take?
Phase 4: Documentation (30 minutes)
Write the executive summary for this incident using the template from Module 8. Include: what happened, what was the impact, what was done, and what improvements are recommended.
Does this incident require notification under GDPR Article 33? Apply the assessment framework from Module 8, subsection 8.5.
Solution Walkthrough
Reveal Phase 1 answers
Q1: The MFA fatigue pattern shows 8 push notifications denied between 09:38 and 09:41, with approval at 09:42. The 4-minute window with 8 denials before approval is the classic fatigue pattern.
Q2: The adversary accessed Microsoft Office 365 portal (Outlook Web Access). User agent indicates a Chrome browser on Windows — not the user’s normal device profile if you check historical UserAgent values.
Q3: The IP does not appear in the 14-day baseline. It belongs to DigitalOcean (hosting provider) in the Netherlands. DET-SOC-001 would have flagged this independently of DET-SOC-002.
Q4: True Positive, High severity. MFA fatigue (8 denials → approval) from a hosting provider IP with no baseline presence is confirmed credential compromise. Escalate immediately.
Reveal Phase 2 answers
Q5: The adversary created two inbox rules at 09:47: (1) Forward all email containing “invoice” or “payment” to an external address, (2) Move emails from the external address to the Deleted Items folder (evasion rule to hide the forwarding).
Q6: 340 emails accessed between 09:43 and 10:12. The adversary spent 29 minutes reading email — studying communication patterns, vendor relationships, and payment processes (BEC reconnaissance).
Q7-8: An OAuth application called “OneDrive Sync Service” was consented at 09:55 with Mail.ReadWrite permissions. Check AADServicePrincipalSignInLogs — the application is authenticating every 15 minutes from a different IP (the adversary’s second infrastructure node).
Q10: j.blake’s successful first-attempt MFA suggests the adversary used a different technique: likely a session token replayed from an AiTM proxy, or the adversary used the OAuth application consented through a.rahman’s account to send a targeted internal phishing email to j.blake. Check EmailEvents for internal email from a.rahman to j.blake between 09:50 and 10:15.
Reveal Phase 3 answers
Q12: Containment order: (1) Revoke tokens for both users (immediate, T2 authority), (2) Delete the malicious OAuth application service principal (immediate, T2 authority), (3) Remove inbox forwarding rules from both mailboxes (immediate, T2), (4) Force password reset for both users (immediate, T2), (5) Block IP 198.51.100.77 at the firewall (SOC Manager approval), (6) Purge any phishing emails sent by the adversary from j.blake’s account to other users (SOC Manager approval, broad blast radius).
Q13: The adversary compromised procurement (payment authority) and finance (payment approval). This enables a BEC payment diversion: the adversary can send a payment change request from procurement that finance would approve because it appears legitimate. Alert the finance team immediately to verify any payment change requests from a.rahman or j.blake through an out-of-band channel (phone, not email).