The Fall of Tylerb: Scattered Spider Guilty Plea & The Reality of MFA Fatigue

Nice KQL snippet. We implemented a similar threshold, but we found it generated a lot of noise for executives who travel frequently. We had to layer it with conditional access policies requiring location trust before the MFA prompt even triggers.

The real issue with Scattered Spider wasn't just the technical bypass; it was the vishing. They successfully talked help desks into resetting MFA factors. Technical controls like FIDO2 stop the automated fatigue, but they don't stop a help desk agent from overriding a lockout.

We moved entirely to FIDO2/WebAuthn hardware keys for critical admins last year. It completely negates the MFA fatigue vector because you can't spam a 'push' notification on a YubiKey—it requires a physical touch.

While Tylerb's group was sophisticated, a lot of their initial access relied on legacy auth protocols that didn't support strong MFA enforcement. Blocking legacy authentication (Basic Auth) in Exchange and ADFS is the single most effective firewall against these groups.

From a pentester's perspective, the 'Tylerb' method is brutally effective because it targets the human, not the machine. I've used similar social engineering simulations where I call the help desk claiming to be the CEO locked out of a hotel Wi-Fi.

The success rate is terrifyingly high if the OSINT on the target is good. Your code snippet is great for detection, but prevention has to start with help desk training. If an admin can override 2FA based on a phone call, no amount of KQL will save you.

While FIDO2 is the endgame, monitoring for MFA spam patterns helps catch attacks in progress. We set up an alert for users receiving >5 MFA prompts within a 2-minute window.

If you're using Splunk, this search helps identify the targets:

splunk index=mfa_logs | bucket _time span=2m | stats count AS attempts by user | where attempts > 5

This gives the SOC a chance to lock the account before the user gives in to fatigue. Does anyone know if Tylerb's plea included cooperation on other group members?

For orgs struggling to move to FIDO2 immediately, enforcing Number Matching is a solid stopgap that disrupts the reflex-accept behavior. Beyond fatigue, don't forget to monitor for 'Fast Pass' or password reset tokens. We use this KQL to spot suspicious reset activity following a password change:

AuditLogs
| where OperationName == "Reset user password"
| join kind=inner (SigninLogs | where ResultDescription == "MFA denied") on TargetResourceId
| summarize count() by bin(Timestamp, 5m), UserPrincipalName

This caught a few attempts mimicking the Tylerb style recently.

Don't overlook the Help Desk vector mentioned in the OP. Scattered Spider frequently bypassed MFA fatigue by simply convincing support staff to reset tokens. We implemented a strict verification workflow requiring a callback to a known number for any reset request.

To monitor for attempts to abuse this, we query the help desk ticketing system for resets originating from external IPs:

SELECT ticket_id, user, requestor_ip FROM helpdesk_logs WHERE action='mfa_reset' AND requestor_ip NOT IN (SELECT ip FROM office_ranges)

This helps distinguish between genuine user lockouts and external social engineering attempts.

To build on the alerting strategy, we automated the remediation to stop the attack loop in real-time. When MFA spam is detected, a Logic App triggers a 'High Risk' sign-in policy, forcing a password reset from a compliant device. This stops the attacker's persistence immediately. We use this PowerShell snippet to verify the user's current risk state before initiating the callback:

Get-MgRiskyUser -UserId $user_id | Select-Object RiskDetail, RiskLastUpdatedDateTime

Building on the alert logic, we coupled that threshold with an automated response to stop the bleeding in real-time. If a user hits the >5 prompt limit, we trigger an Azure Automation runbook to temporarily disable their account and notify the SOC. It acts as a circuit breaker.

Disable-AzureADUser -ObjectId $UserUPN


It's drastic, but it buys the security team crucial time to verify the user's identity via a second channel (like a phone call) before the attacker finally wears them down and gets that "Yes" click.