Scattered Spider Update: Stokes Extradited – Analyzing the Help Desk Vector
Saw the news that Peter Stokes was extradited from Finland to face charges in Chicago. For those who have been tracking Scattered Spider (aka 0ktapus), this is a significant development. We know this group isn't just about "hacking" in the traditional sense; they are masters of the social engineering and MFA bypass game.
What concerns me most about their TTPs is the heavy reliance on vishing and SIM swapping to bypass Okta/MFA. They don't always need a 0-day; they just need to convince a help desk employee to reset an MFA factor. Since the DOJ mentioned Stokes faces charges for conspiracy and computer intrusion, I'm curious if we'll see more details emerge about their specific infrastructure.
In the meantime, has anyone else tweaked their detection logic specifically for rapid MFA failures followed by a successful 'Reset' event? We've been testing a KQL query in Sentinel to catch the 'MFA fatigue' attempts they often employ:
SigninLogs
| where ResultDescription has "MFA" and Status.errorCode in (500121, 50053)
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 10m)
| join kind=inner (
AuditLogs
| where OperationName == "User registered security info" or OperationName == "Reset user password"
| project UserPrincipalName, ResetTime=TimeGenerated, OperationName
) on UserPrincipalName
| where TimeGenerated between ((ResetTime-30m)..ResetTime)
| project-away UserPrincipalName1
It’s imperfect, but it highlights the pattern of hammering the portal until the social engineer succeeds on the backend. How is everyone else hardening the help desk against this specific vector?
Solid query. We actually implemented a stricter policy for password resets from unknown IPs. If the IP isn't in the registered range or the device isn't compliant, we require a manager's approval code generated on-site. It's caused some friction for remote staff, but it effectively killed the vishing success rate overnight. You can't automate the 'human' element out completely, but you can raise the bar.
This is exactly why we pushed hard for FIDO2 hardware keys across the org. Even if they SIM swap or trick the help desk, possession of the physical key is required for the enrollment of a new method. It costs more, but compared to the damage Scattered Spider does (ransomware, data theft), the YubiKey budget is a rounding error.
I've been testing detection on the endpoint side as well. They often drop RedLine or Lumma Stealer prior to the big intrusion. Looking for suspicious powershell child processes that don't match the usual admin scripts has helped us catch the recon phase before they even attempt the MFA bypass.
The human element remains the hardest control to harden. Beyond standard verification, we enforce a strict "known-number callback" policy: staff must call the user back at the number listed in the HR system, never the number provided by the caller. This thwarts spoofed callbacks.
To monitor for these patterns, we correlate excessive failed authentication attempts with help desk ticketing timestamps in the SIEM:
AuditLogs
| where Operation == "Reset password (by admin)"
| join kind=inner (SigninLogs) on CorrelationId
| where ResultType in ("500121", "50053")
| project TimeGenerated, UserPrincipalName, AppDisplayName
Great points on FIDO2. To layer on top, we enforce a "Challenge on Trusted Device" step before any reset is finalized. If they can't acknowledge a prompt on their current phone, the ticket stalls. We also monitor for insider threat patterns or compromised help desk accounts using SIEM queries to detect rapid resets:
AuditLogs
| where OperationName == "Reset user password"
| summarize count() by InitiatedBy, bin(TimeGenerated, 5m)
| where count_ > 5
This helps catch if a help desk account itself is being abused to push these resets.
While FIDO2 and callbacks are solid controls, we’ve added a layer at the endpoint data level. We tuned our DLP policies to flag when sensitive string patterns are copied to the clipboard during active tickets. This helps catch the moment an agent is socially engineered into leaking a reset code.
We use a rule similar to this to detect potential OTPs in transit:
regex (?i)(otp|code|reset).*\b\d{4}\b|\b\d{6}\b
Catching the clipboard action provides a safety net if the identity verification is bypassed.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access