foyl Scenarios / INV-2024-0086
High Identity Contained 5 tools ~20 min walkthrough

ATO-002 — MFA Fatigue

m.blake (Michael Blake, Director of Research) gets hit with a credential phishing email from microsoft-secure-signin.com, followed by MFA push bombing from 203.0.113.88 (Taipei, Taiwan). Three pushes are denied, then a fourth gets approved under fatigue. The attacker gets into the admin portal and tries to disable MFA for the pioneer account, but SOAR playbook PB-002 fires automatically and locks things down. There are signs this is linked to TA-001 IRON CHIMNEY, suggesting coordinated activity.

Attack chain
01
Phishing
Credential harvest via microsoft-secure-signin.com (MailGuard THREAT-005, blocked)
T1566.001
02
MFA Fatigue
3 push denials then 4th approved. SIEM ALT-7285
T1621
03
Account Access
Admin portal login from 203.0.113.88 Taipei. SIEM ALT-7288
T1078.004
04
Defense Evasion
Attempted MFA disable for pioneer account. SOAR PB-002 blocked it
T1556.006
Tool involvement
Identity
RISK-010 · m.blake risk score 82 · MFA push bombing · SI-039/040/041/042 Sign-ins ↗
SIEM
INV-2024-0086 · ALT-7285 (MFA failures) · ALT-7288 (admin login after burst) Investigate ↗
Email
ATO-002 (m.blake · risk 82) · THREAT-005 (credential phish, blocked) ATO Cases ↗
SOAR
CASE-2024-0142 · PB-002 MFA Fatigue Lockdown (blocked 203.0.113.88) Cases ↗
TIP
IOC-002 — 203.0.113.88 attributed to TA-001 · in CAM-001 timeline IOCs ↗
Key concepts covered

Techniques in this scenario

MFA fatigue Sending repeated MFA push notifications hoping the target approves one just to make them stop
Push bombing High-volume MFA push requests in a short window, often combined with social engineering
Risk score A number assigned to a user or sign-in based on anomalous behavior signals. High scores trigger policies or alerts
SOAR auto-block A playbook that automatically blocks the source IP and locks the account when specific conditions are met, without waiting for analyst action
Instructor walkthrough

Click each step to expand. Open the linked tool page, walk through what's there, then ask the discussion questions.

01 Identity Find the risky sign-in

Open Identity and go to Sign-ins. Filter by m.blake. Show the three MFA push denial events, then the fourth that was approved. Point out that the approved login came from 203.0.113.88 (Taipei), and m.blake had no history of logging in from Asia. The risk score jumped to 82 after the approval. This is the moment the attacker got in.

Open Sign-ins ↗
AskThree pushes were denied. Why did the person approve the fourth one? What psychological pressure is the attacker creating?
AskWhat controls would have prevented the fourth push from ever getting sent?
02 SIEM Check the SIEM investigation

Open the SIEM and go to Investigations. Open INV-2024-0086. Show the alert timeline: ALT-7285 fired when the third MFA push was denied (burst detected), then ALT-7288 fired when the admin portal login came in from the external IP. Point out the gap between the two alerts and ask students what they would have done if they saw ALT-7285 come in.

Open Investigation ↗
AskALT-7285 (MFA burst) fired before the attacker got in. If a Tier 1 analyst had responded to it immediately, what should they have done?
AskHow do you tune the MFA burst alert so it catches real attacks without generating too many false positives?
03 Email Show the blocked phishing email

Open MailGuard and go to ATO Cases. Find ATO-002 for m.blake. Then go to Threats and show THREAT-005, the credential phishing email from microsoft-secure-signin.com. MailGuard blocked the email but the attacker still had the credentials from a previous breach or separate phish. This is a good moment to discuss how blocking the email is not enough if the credentials were already out there.

Open ATO Cases ↗
AskMailGuard blocked THREAT-005 but the attacker still had the credentials. Where could they have come from?
AskShould a blocked phishing email automatically trigger an ATO investigation for the target user? What are the tradeoffs?
04 SOAR Walk through the automated lockdown

Open SOAR and go to Cases. Find CASE-2024-0142. Then go to Playbooks and open PB-002 MFA Fatigue Lockdown. Show the nodes: suspend the m.blake account, block 203.0.113.88 at the firewall, revoke all active sessions, and alert the identity team. The playbook ran automatically when ALT-7288 fired. The attacker's attempt to disable MFA for the pioneer account was blocked mid-action.

Open Cases ↗
AskSuspending a director's account automatically is a big deal. How do you build a playbook that is aggressive enough to be useful but doesn't cause too much disruption?
AskHow does the SOAR know when to fire PB-002? What conditions trigger it?
05 TIP Connect to IRON CHIMNEY

Open the TIP and go to IOCs. Find IOC-002 for 203.0.113.88. Show that this IP is attributed to TA-001 IRON CHIMNEY, the same threat actor behind the main ransomware campaign. Then go to Campaigns and show where this IP appears in CAM-001 Operation SMELTING. This is an important moment: two separate incidents turn out to be the same threat actor running parallel operations.

Open IOCs ↗
AskWhy would TA-001 run ATO-002 at the same time as the IRON CHIMNEY ransomware campaign? What are they trying to achieve?
AskHow does connecting incidents to the same threat actor change how you respond?