Caught on Day 1: Scattered Spider Members Fold in TfL Case

It’s rare to see them fold that quickly unless the digital footprint was undeniable. We’ve seen a massive uptick in 'MFA fatigue' attempts in our environment recently. One additional check we run is looking for new device enrollment immediately following a batch of failures, which is their classic move.

Get-MsolDevice -RegisteredOwner UPN | Where-Object {$_.ApproximateLastLogonTimestamp -gt (Get-Date).AddHours(-2)}


If you see a device pop up right after a failed login storm, lock the account immediately.

This plea might be tactical for them, but I doubt it stops the affiliates. The 'brand' of Scattered Spider has proven too profitable in the initial access broker market. Regarding detection, we've had success moving strictly to FIDO2 keys for admins; it completely negates the push-spam vector they rely on. Until organizations enforce phishing-resistant MFA, these TTPs will remain effective regardless of who gets arrested.

The speed of the plea implies the evidence chain was unbreakable, likely linking the initial social engineering session directly to the exfiltration events. Since they often use session hijacking tools like AiTM, checking for impossible travel or concurrent sessions is crucial.

Here is a query I use to spot potential session hijacking based on device changes:

SigninLogs
| where ResultType == 0
| summarize Count = count() by UserPrincipalName, bin(TimeGenerated, 5m), DeviceDetail
| where Count > 1

Since the group thrives on MFA fatigue, enforcing "Number Matching" for push notifications is a critical hardening step. It disrupts the rapid-fire spamming tactics they use to trick users into approving. If you are on Azure AD, ensure this is enabled in your Authentication Methods policy. You can verify the policy configuration via:

Get-MgPolicyAuthenticationMethodPolicy -Expand AuthenticationMethodConfigurations | Select-Object -ExpandProperty AuthenticationMethodConfigurations


It’s a small configuration change with a high impact on stopping these social engineering attempts.

That plea is a stark reminder that telemetry is king. While everyone focuses on the login, I’m worried about what happens next in the cloud. Scattered Spider loves IAM manipulation for persistence. We implemented a daily drift check using a script to compare current role policies against a baseline. Any deviation triggers an immediate alert. Here’s the basic Python snippet we use for AWS:

import boto3
# Compare inline policies of production roles
client = boto3.client('iam')
# ... comparison logic against known good state

It catches the lateral movement that logs might miss.

Their early plea definitely underscores the weight of the digital forensic chain. Beyond hardening MFA, we’ve seen success shifting to FIDO2 Passkeys, which render session hijacking tools useless by removing the shared secret. It’s a heavier lift but eliminates the fatigue vector. To audit who might still be vulnerable, you can run this to identify users lacking per-user MFA:

Get-MsolUser -All | Where-Object { $_.StrongAuthenticationRequirements.Count -eq 0 } | Select-Object UserPrincipalName

Beyond MFA hardening, enforcing Device Compliance is often the deciding factor. These actors typically operate from hosted environments or residential proxies that fail corporate health checks. By blocking access from non-compliant or unmanaged devices, you sever the link even if they possess a valid session token. To quickly audit for sign-ins from unmanaged devices, run:

SigninLogs | where DeviceDetail.isCompliant == false and ResultType == 0

Something I haven't seen mentioned: while number matching helps against MFA fatigue, it doesn't stop session token theft via adversary-in-the-middle proxies. Scattered Spider has used kits like EvilProxy that intercept the session cookie after authentication succeeds. The strongest counter is phishing-resistant MFA — FIDO2/WebAuthn keys like YubiKeys, which cryptographically bind auth to the legitimate origin.

For detection, here's a KQL query I use to flag accounts authenticating from multiple geographies in a short window:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| summarize locations = makeset(Location), ips = makeset(IPAddress) by UserPrincipalName
| where array_length(locations) > 2
| order by array_length(locations) desc

Has anyone gone FIDO2-only for admin accounts yet? Curious about adoption pushback from leadership.