Tylerb's Downfall: Scattered Spider TTPs and the Crypto Heist Mechanics
It’s fascinating to see the legal fallout from the 2022 Summer campaign. Tylerb’s plea confirms what many of us suspected about the operational structure of Scattered Spider (aka 0ktapus). While the news focuses on the guilty plea, I want to unpack the TTPs that allowed them to bypass MFA at major tech firms.
We know they relied heavily on SMS phishing (smishing) targeting Okta and SSO credentials, but the real damage came from the subsequent social engineering (vishing) to push MFA approvals. They weren't just hacking systems; they were hacking the helpdesk support staff.
For those monitoring for similar activity, looking for failed MFA followed by immediate success is a baseline detection. However, Scattered Spider often bypassed standard thresholds by spacing out attempts or switching devices. I’ve been using a KQL query in Sentinel to catch rapid succession failures that might indicate a 'MFA fatigue' attack:
kusto
SigninLogs
| where ResultDescription == "MFA verification failed" or Status has "50057"
| summarize FailedAttempts = count(), TimeWindow = bin(TimeGenerated, 5m) by UserPrincipalName, AppDisplayName, IPAddress
| join kind=inner (
SigninLogs
| where ResultDescription == "Success"
) on UserPrincipalName
| where TimeGenerated between (TimeWindow - 5m) .. (TimeWindow + 5m)
| where FailedAttempts > 3
| project UserPrincipalName, IPAddress, AppDisplayName, FailedAttempts
The crypto heist aspect is interesting too. It suggests that once they had access to the tech company's VPN/SSO, they leveraged that trust to pivot to crypto exchanges or wallets.
Given the sophistication of their social engineering, does anyone have success stories moving completely away from push-notification MFA to FIDO2 hardware keys to stop this 'fatigue' vector?
We started seeing similar 'MFA fatigue' attempts last quarter. The KQL query is a solid baseline, but we found attackers were smart enough to space the pushes out by 15-20 minutes to avoid time-window detection. We ended up implementing number matching in our MFA solution. It adds a friction layer for users, but it effectively kills the automated push-spam scripts these groups deploy.
Great breakdown. The vishing angle is exactly what makes this group so dangerous. They don't just rely on the initial phish; they patiently build a profile. We enforce FIDO2 keys for all admin accounts, which helps, but getting buy-in for the general user base is a struggle. If you have a good executive summary or whitepaper on forcing YubiKeys for non-technical staff, please share.
The crypto connection is huge. Once they compromise a tech org, they often look for developers or DevOps engineers who might have access to CI/CD pipelines or cloud keys. If you aren't rotating your cloud credentials regularly, you're basically leaving the vault door open after they get the initial foothold.
Omar is spot on about the targeting. One thing we noticed is their shift to pure session hijacking once they get an initial foothold, bypassing MFA entirely by reusing valid session tokens. We track session IDs across IPs to detect this reuse behavior.
If a session_id hops geographies or distinct subnets in a short window, we kill the session. Here’s the Splunk logic we use:
splunk index=okta | stats dc(src_ip) as IP_Count, values(src_country) as Countries by session_id | where IP_Count > 1
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access