Scattered Spider Guilty Pleas: Dissecting the TfL Attack Vector
Saw the news that two key members of Scattered Spider pleaded guilty on day one of their trial regarding the TfL attacks. While it’s good to see some accountability, the tactics they used to cripple Transport for London’s network are unfortunately still very effective against many orgs.
Scattered Spider is notorious for their blend of aggressive social engineering (vishing help desks) and technical MFA bypass. For those defending against this profile, identity monitoring is critical. We've been refining our detection around rapid MFA modifications and unusual session token issuance.
Here is a KQL query we use to hunt for rapid MFA enrollment or device changes, which often precedes data exfiltration in these scenarios:
AuditLogs
| where Category == "UserManagement"
| where OperationName has "StrongAuthentication" or OperationName has "Update"
| summarize Count = count() by TargetResources[0].displayName, bin(TimeGenerated, 10m)
| where Count > 3
| project OrderBy Count desc
The weakest link remains the human element—specifically the help desk interaction.
How are you handling the 'verify the user' process for password resets over the phone? Are you using out-of-band verification or sticking to knowledge-based answers?
FIDO2 hardware keys are the only real defense against the MFA fatigue these groups push. We moved to passkeys for all admins last quarter. It's not cheap, but seeing the chaos at TfL, it's worth it. If you can't do phish-resistant MFA, you're leaving the door open for these guys.
Good query @op. We also track specific user-agent strings associated with the info-stealers they often drop, like Lumma or StealC. Additionally, checking for multiple 'Password Reset' events within a short window across different IP geolocations is a solid trigger.
import pandas as pd
# Simple logic to flag rapid resets from distinct IPs
flags = df.groupby('user')['ip_address'].nunique() > 1
The vishing angle is terrifyingly effective. In our red team exercises, we still bypass 90% of help desks by just sounding stressed and using a target's personal data found on OSINT. KBA (Knowledge Based Authentication) is effectively dead against groups this sophisticated.
While passkeys help, session hijacking bypasses MFA entirely if the cookie is stolen. We’ve had success focusing on detection via 'Impossible Travel' logic to catch token theft. If you're using Sentinel, this KQL query helps flag users accessing resources from geographically distant locations within minutes, forcing a re-auth:
SigninLogs
| where ResultType == 0
| summarize count(), Locations = make_set(Location) by UserPrincipalName, bin(TimeGenerated, 10m)
| where array_length(Locations) > 1
Solid insights on the attack vector. While detecting token theft is vital, we also need to watch for what happens next: privilege escalation. Scattered Spider often aims to create new Global Admins for persistence. We run this scheduled query to alert on any unauthorized role additions:
AuditLogs
| where OperationName == "Add member to role"
| extend TargetRole = tostring(TargetResources[0].DisplayName)
| where TargetRole contains "Admin"
If you catch the role addition, you can often lock them out before they hit your backup repositories.
To build on the session hijacking discussion, enabling Token Protection (Device Binding) in Entra ID is a game changer. It binds the refresh token to the specific device, rendering stolen cookies useless on attacker machines. You can audit its coverage with this KQL query to ensure it's rolling out effectively:
SigninLogs
| where ConditionalAccessStatus == "success"
| project Time, UserPrincipalName, DeviceDetail, TokenProtectionStatus
| where TokenProtectionStatus != "enabled"
It adds a critical layer against the token theft methods Scattered Spider loves.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access