Lion Cipher Lab
Detect MFA push fatigue in sign-in logs, then stop it with number matching and rate limits
- Identity & Access Management
- Intermediate
- ~50 min
- Free · no account required
Why it matters
Multi-factor authentication (MFA) is the control everyone is told to turn on, and the most common kind is the push notification: you type your password, your phone buzzes, you tap Approve. The trouble is the button. An attacker who has already stolen or bought your password can make your phone buzz again and again -- at 2am, twenty times in ten minutes -- until you tap Approve just to make it stop, or because you assume IT is testing something. MITRE ATT&CK tracks this as T1621, Multi-Factor Authentication Request Generation, and it has been used in real intrusions against large companies. It…
What you'll learn
- explaining MFA push fatigue (MITRE ATT&CK T1621) -- an attacker who already holds the password floods push prompts until a tired user taps Approve -- and why it is a second-factor problem, not a password problem
- writing a pure-standard-library Python detector for the fatigue signature: N denied or timed-out pushes inside W minutes, followed by an approval
- sweeping N and W and scoring every setting as true positives, false positives and false negatives against labelled ground truth, instead of guessing a threshold
- recognising the benign look-alikes that make a loose rule over-fire (a fat-fingered Deny, an app that re-sends a push, a phone with a dead battery) and the patient attacker that makes a tight rule miss
- adding a second signal (failed pushes from an IP the user has never approved from) and measuring that it catches all three attacks with no false positives on this data
- comparing controls with a seeded simulation: plain push, number matching, additional context, a per-user push rate limit, and FIDO2 -- and reading the lockout column as the denial-of-service cost of rate limits
- stating the honest limits: number matching does not stop a real-time phishing proxy, rate limits hand attackers a lockout lever, log detection only fires after the approval, and FIDO2 only helps once the push fallback is turned off
Steps in this lab
- What push fatigue is -- every term, defined once
- How this differs from the password-spraying and credential-stuffing labs
- Set up a folder and generate the push log
- Write the detector
- Run one rule, then sweep N and W
- The patient attacker, and the signal a pro adds
- The hard truth about detection: it fires after the door opened
- The controls: number matching, context, rate limits, FIDO2
- Simulate every control with the same attacker
- The honest negatives in that table
- When to use which -- and how a pro rolls it out
- What you built -- and the reflex to keep