Tylerb Guilty Plea: Examining Scattered Spider's SMS Phishing Techniques
Just saw the news about Tyler Robert Buchanan (aka 'Tylerb') pleading guilty to wire fraud and aggravated identity theft. It’s a good reminder that sophisticated initial access vectors (IAVs) often don't require zero-days—just really good social engineering.
For those who don't remember, Scattered Spider caused massive damage in 2022 primarily through SMS phishing (SMiShing) targeting Okta and MFA tokens. They didn't just spam; they tailored the lures to specific employees using OSINT.
Technical Takeaways:
- Context-aware Attacks: The attacks weren't generic "Your account is locked" messages. They used urgency and context relevant to the victim's specific role.
- MFA Fatigue Exploitation: They bombarded targets with push notifications until they approved the login.
Detection Logic:
If you are looking for signs of SMS-based phishing infrastructure, you can monitor for suspicious link-shortening patterns often used in these campaigns. A basic Python script to analyze potential malicious shorteners in your logs might look like this:
import re
def check_shorteners(url_list):
suspicious_patterns = [r'bit\.ly', r'tinyurl', r'do\.yy']
detected = []
for url in url_list:
if re.search('|'.join(suspicious_patterns), url):
detected.append(url)
return detected
Additionally, review your identity provider logs for impossible travel events correlating with successful MFA challenges.
Given that the human element remains the weakest link, what specific technical controls are you guys implementing to stop MFA fatigue attacks? Is FIDO2 the only real answer here?
FIDO2 is definitely the gold standard, but getting 100% adoption across an org is a nightmare. We've had luck implementing 'Number Matching' in our MFA policies. It forces the user to type a number displayed on the login screen into the authenticator app. It stops the accidental 'approve' spam attacks effectively. It's not a silver bullet, but it raises the bar significantly.
From a SOC perspective, we've started alerting specifically on 'Anomalous Token Usage'. If a token that usually authenticates from New York suddenly tries to authenticate from Moldova within 5 minutes, we block and revoke. Here is the KQL query we use for Sentinel:
SigninLogs
| where ResultType == 0
| where isnotempty(DeviceDetail.model)
| project Time, UserPrincipalName, Location, AppDisplayName
| evaluate geo_distinct(Location)
It's noisy, but it catches the SIM swapping/redirect attempts often associated with these crews.
Hardening MFA is great, but we can't ignore the OSINT source. We started injecting honeytokens into our public 'About Us' page and LinkedIn profiles. If a login attempt or password reset occurs against these specific accounts, we know it's a targeted SMiShing campaign immediately. Here’s a quick snippet to generate unique honeytoken emails for tracking:
import uuid
print(f"zara.honey.{uuid.uuid4().hex[:6]}@yourcompany.com")
While honeytokens catch the attempt, minimizing the OSINT footprint is step zero. We audit our public-facing metadata regularly to remove fodder for tailored lures. This bash snippet helps identify PII leaks in public HTML/JS assets before the scrapers do:
grep -R -i -E "([a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]|phone)" ./public_html/ --exclude-dir=node_modules
It won't stop everything, but cleaning this data forces attackers to use generic templates, which are much easier for users to spot.
Great points on OSINT. Another tactic Scattered Spider often employs is MFA fatigue—bombarding the user until they approve. We track rapid MFA failures in our logs. Here’s a KQL query I use to flag potential fatigue attacks targeting specific users:
SigninLogs
| where ResultDescription contains "MFA" or Status == "Failure"
| summarize Count = count() by UserPrincipalName, bin(TimeGenerated, 2m)
| where Count > 5
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access