Scattered Spider: TfL Attackers Plead Guilty – Analyzing Identity TTPs
Just saw the breaking news regarding the UK trial for the Transport for London (TfL) attack. Two key members of Scattered Spider (also tracked as 0ktapus) pleaded guilty on day one. While the legal outcome is significant, I want to pivot this discussion to the technical fallout for the rest of us.
Scattered Spider is notorious for bypassing standard MFA through social engineering and SIM swapping, but they also have a history of exploiting specific identity provider flaws. While the TfL breach was heavily reliant on targeting the help desk (a vector we've discussed in the Stokes extradition thread), we shouldn't ignore their ability to leverage session hijacking once inside.
If you are running Okta or Azure AD, you should be hunting for "MFA Push Bombing" signs as a precursor to a help desk call. Here is a KQL query to help identify rapid MFA failures that often precede a successful vishing attempt:
OktaCL
| where EventType == "user.mfa.factor.verify" or EventType == "user.authentication.verify"
| parse Message with * "status: " Status "," *
| where Status == "FAILURE"
| summarize Count = count() by ActorAlternateId, bin(TimeGenerated, 5m)
| where Count > 5
| order by Count desc
Additionally, if you are forensic reviewing, look for anomalies in the User-Agent strings post-authentication, as they often use automated tools to push through the stolen session cookies.
Given their reliance on the "human element" at the help desk, are any of you implementing strict verification workflows for MFA resets, or have you moved entirely to FIDO2 hardware keys to mitigate this specific threat?
We pushed for FIDO2 keys for all admin accounts late last year after seeing similar TTPs in our threat feeds. It completely neutered the push-bombing attempts we were seeing. However, the help desk vector is still the weakest link. We implemented a mandatory callback verification to the number on file and a manager approval code for any MFA reset. It slows things down, but the noise from phishing attempts dropped to zero almost overnight.
Solid KQL query. I'd add a join to your SigninLogs to check for DeviceId mismatches. Scattered Spider loves to inject cookies into a session on a different device geographically than the original auth.
SigninLogs
| where ResultDescription == "MFA required" or Status == "Success"
| summarize Devices = dcount(DeviceDetail.deviceId) by UserPrincipalName
| where Devices > 1
Seeing multiple distinct devices in a short window with the same user is a massive red flag for session hijacking.
From a pentester perspective, the help desk is almost always an open door unless the culture supports saying 'no'. In our phishing sims, if we can't get the user to click the link, we call the help desk claiming a lost token and try to manipulate the agent using urgency. Training the staff to detect vishing is just as critical as the technical controls mentioned here.
Beyond DeviceId, watch for User-Agent switching within the same session. Scattered Spider often injects stolen cookies into new environments, leaving the browser signature inconsistent. I use this KQL snippet to hunt for those anomalies:
SigninLogs
| summarize make_set(UserAgent) by CorrelationId, UserId
| where array_length(set_UserAgent) > 1
It flags when a single session ID spans different browsers—a clear red flag for pass-the-cookie attacks. Have you found similar success correlating this with risk-based authentication triggers?
It's worth monitoring AuditLogs for immediate MFA tampering post-breach. Scattered Spider often disables MFA policies to ensure persistence. Looking for updates to Strong Authentication methods can catch them before lateral movement.
AuditLogs
| where OperationName contains "StrongAuthentication" or OperationName contains "ResetPassword"
| where Result == "success"
| project TimeGenerated, OperationName, InitiatedBy, TargetResources
Has anyone observed them adding fraudulent 'recovery' methods rather than a full disable in recent campaigns?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access