ForumsGeneralIdentity at the Core: Scattered Spider's Tylerb and the SMS Breach Wave

Identity at the Core: Scattered Spider's Tylerb and the SMS Breach Wave

CloudSec_Priya 4/26/2026 USER

Just saw the news on Krebs about Tyler Robert Buchanan (aka Tylerb) pleading guilty. For those tracking Scattered Spider (0ktapus), this confirms the operational security breakdowns we saw in 2022. It’s a massive win for law enforcement, given how aggressive their campaigns were against tech firms.

The guilty plea highlights their heavy reliance on SMS phishing to bypass initial controls. What makes Tylerb's group particularly dangerous is their speed. Once they got the creds via smishing, they moved immediately to session hijacking and MFA fatigue tactics.

If you're hunting for this type of activity, don't just look at sign-in failures. You need to correlate the "MFA denied" events with the "Success" event from the same IP within a short window.

Here is a basic KQL query to spot the fatigue pattern in Entra ID:

SigninLogs
| where ConditionalAccessStatus == "failure" or ResultDescription has "MFA"
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress, AppDisplayName
| where FailedAttempts > 3
| join kind=inner (SigninLogs | where ResultType == 0) on UserPrincipalName, IPAddress
| project UserPrincipalName, IPAddress, FailedAttempts, Timestamp

The plea mentions they stole tens of millions in crypto, but the real damage was the access to the internal email of those tech employees. Has anyone moved away from SMS-based 2FA entirely for their privileged admin accounts yet?

EM
EmailSec_Brian4/26/2026

Great post. We’ve been seeing a massive uptick in 'push bombing' attempts since last year. The Tylerb crew was notorious for this. Beyond just the KQL, we implemented a 'number matching' requirement for our MFA prompts, which significantly lowered the success rate of these automated fatigue scripts.

Also, keep an eye on your telecom logs. They often ported SIMs or used VoIP services to bypass carrier filters.

RE
RedTeam_Carlos4/26/2026

It’s wild to see the face behind the handle. I consulted on a case similar to this last year. The scary part wasn't the initial phishing, it was the persistence. Once Tylerb's group was in, they used RMM tools like AnyDesk and ScreenConnect to maintain access, blending in perfectly with normal admin traffic.

I'd recommend blocking consumer-grade remote access tools at the firewall if you can afford the operational overhead.

PE
Pentest_Sarah4/26/2026

The vishing angle is critical here. Beyond the initial smishing, this group frequently pivoted to calling service desks to bypass MFA or enroll new devices. From a detection standpoint, we started flagging rapid Okta events where a credential fill is followed immediately by an MFA factor addition. Here’s a snippet to help identify suspicious enrollment velocity:

EventType in ("user.account.mfa.factor.add", "user.session.start")
| where Result == "SUCCESS"
| summarize count() by ActorAlternateId, bin(TimeGenerated, 10m)
| where count_ > 3

This helps catch the 'credential stuff -> enroll new phone' flow before they establish persistence.

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created4/26/2026
Last Active4/26/2026
Replies3
Views79