On April 10, 2026, Finnish police arrested a 19-year-old as he tried to board a flight to Japan. He was carrying two two-terabyte hard drives. According to a superseding criminal complaint unsealed in the Northern District of Illinois, that traveler is Peter Stokes, a dual US and Estonian citizen, and the drives were the least of it. The FBI alleges he is a member of Scattered Spider, the group Microsoft tracks as Octo Tempest, and that he helped run intrusions the government links to more than 100 network compromises and over $100 million in ransom payments.
I read the complaint in full. It is 35 pages, and it is the clearest primary-source account of a Scattered Spider help-desk attack I have seen in public. Most of what we know about this group comes from vendor blogs and incident summaries written after the fact. This is different. It is a sworn federal affidavit that walks the attack step by step, names the tools, and cites the logs.
Two caveats before I go further. A complaint is an allegation, not a conviction, and the government has not proven any of this in court. And the victims are anonymized, so I will not guess at who "Company F" is. What matters here is the tradecraft, and the tradecraft is documented.
The attack, in the order it happened
The centerpiece is a May 2025 intrusion at Company F, described in the affidavit as a multibillion-dollar luxury retailer. Here is the chain, drawn straight from the network logs the FBI cites.
It started with phone calls. On or about May 12, 2025, threat actors called the Company F IT help desk from two Google Voice numbers, posing as employees, and asked to reset their credentials, including the password and the mobile device used for multifactor authentication. Within roughly two to three hours, they had compromised three user accounts. No exploit. No malware. A phone call and a reset.
Two of those three accounts belonged to IT administrators. The attackers used the standard accounts they had just stolen to pull the admins' high-privilege credentials, and with those they reached the platforms that control Company F's virtual servers and cloud computing.
From there they needed persistence and a way out. They installed ngrok on a Company F server, a legitimate developer tool that opens a secure tunnel from inside a private network to the internet, a clean way to bypass perimeter defenses without tripping them. Then they used Teleport.sh, another legitimate remote-access utility, together with Amazon S3 storage, to move the data out. Over three days they exfiltrated at least 77 gigabytes.
They tried to finish with ransomware. Company F's security team stopped that part and eventually evicted them. But by then the data was gone. On May 15 the attackers sent a ransom note from a mailbox they had compromised, subject line "IMPORTANT: WE STOLE THE DATA, CONTACT UMMEDIATELY [sic]." Negotiations through a third party led to a demand: "$8million seems like a good price."Company F did not pay. Reported losses from disruption and mitigation ran to around $2 million.
The complaint also places the group inside the ransomware-as-a-service economy. On a server tied to Stokes, investigators found chats in a window labeled DragonForce, a RaaS brand, including an affiliate griping about being charged $500 for a new login "after we made you over 1 million." DragonForce is not a fixed crew; it is code and infrastructure that affiliates rent, built on the same Conti and Black Basta lineage I traced in From Conti to Black Basta to DevMan: The Endless Ransomware Rebrand.
The brand on the ransom note changes. The behavior does not.
Why prevention had nothing to flag
Walk back through that chain and notice what never happened. No failed login. No malware signature. No exploit against an unpatched service. Every door that opened, opened with a valid key.
The attacker calls in as the employee and the help desk resets the credential, so the next sign-in is a real user with a real password and a real MFA device. Authentication succeeds. The privilege escalation uses the account's own legitimate path to a temporary password, so the identity system records an authorized elevation. The tunnel out runs over ngrok and Teleport, tools a developer might use on any given Tuesday. The data lands in Amazon S3, an endpoint millions of companies talk to all day. This is Gap 2, authentication succeeds, sliding straight into Gap 3, movement isn't visible. The audit log waved them through, and the exfiltration hid inside traffic that looked ordinary.
This is the part I want security leaders to sit with. Company F's team was not asleep. They caught the ransomware stage and they forced the attackers out. Prevention and endpoint controls did their job at the stage those controls are built for. The loss happened earlier, in the window between a successful help-desk reset and the moment 77 gigabytes finished uploading. That window is behavioral. A stolen identity and a real one both authenticate. The only thing that separates them is what they do next: an admin account reaching systems it never touches, a first-ever ngrok tunnel from a production server, a sudden S3 upload measured in tens of gigabytes. None of that is a signature. All of it is a pattern.
The 2024 hardening playbook is still correct, and it no longer covers this access path. Phishing-resistant MFA matters. But a help-desk reset hands the attacker a fresh, legitimate MFA enrollment, so the control that should have stopped a stolen password gets reissued to the wrong person on request. I have written before about why MFA resets and SMS codes are the soft underbelly of an otherwise hardened identity stack.
The gap is not the MFA. The gap is the reset, and everything the attacker does once the reset succeeds.
The tools were all legitimate
There is no custom implant in this story. Ngrok, Teleport.sh, and Amazon S3 are tools built for engineers, and that is precisely why they work for attackers. Nothing to scan, nothing on a blocklist, nothing that screams malware.
Track the behavior, not the brand.
The question is not whether ngrok is malicious, because it isn't. The question is whether a tunnel opening from inside your data center to the public internet, from a server that has never done that before, is something you would see and challenge in time.
How a teenager got caught
The other half of the complaint is the investigation, and it is worth reading on its own, because the method the FBI used mirrors the method defenders need.
Stokes, according to the affidavit, was not quiet about the money. Snapchat and Facebook images placed him in Paris, New York, Bangkok, and Dubai between ages 17 and 18, staying in luxury hotels, holding stacks of cash and watches, wearing a diamond chain that read "HACK THE PLANET". He sent a message on his birthday about a database he had just pulled that held wire-transfer data going to crypto exchanges, and the date of that message matched his date of birth in State Department records. He photographed an Estonian police station with a caption comparing himself to a character who turns himself in to the FBI.
These are the operational-security mistakes that hand defenders their leads, the same pattern I traced in OPSEC failures: how threat actor mistakes help defenders.
But the technical attribution is the interesting part. The account that set up the ngrok used in the Company F attack was tied to a Microsoft Global Device ID, a persistent identifier for a Windows installation. The FBI correlated that device's IP activity, over time, against the IPs used to log into accounts they had already tied to Stokes: Snapchat, Apple, Facebook.
The same addresses in Tallinn, in New York, in Thailand, on the same days, sometimes within hours. He used a VPN proxy for the attack infrastructure. It did not matter, because the correlation was built across his whole digital life, not from any single connection.
The detail that lands hardest: on January 8, 2025, that device logged into the online game Growtopia through a Ubisoft account from a Tallinn IP, and the day before, that same IP had accessed one of his Apple accounts and that Ubisoft account two minutes apart.
One IP is noise. A VPN hides one connection. What convicts, in the investigator's logic, is the pattern of many signals correlated across planes and across time. That is the same logic that separates a stolen identity from a real one inside a network.
The FBI did to Stokes exactly what a good detection strategy does to an intruder: it stopped looking for a single smoking gun and started correlating behavior.
This is not a distant threat
One more thing the complaint makes plain. Scattered Spider is not a faraway state program. Stokes is 19. The co-conspirator named alongside him in the complaint was a US-based juvenile at the time of the conduct, charged locally. Another member the complaint references, Noah Urban, known as "Sosa" and "King Bob," was sentenced to 120 months for a SIM-swapping scheme.
These are young, native English speakers who are very good on the phone and very comfortable in the systems they are attacking. That is what makes the help-desk vector so effective. The person calling your service desk sounds exactly like the employee they are pretending to be.
And Stokes is not the last of them. In April 2026, Tyler "Tylerb" Buchanan pleaded guilty to the group's 2022 SMS-phishing spree. In June 2026, Thalha Jubair and Owen Flowers pleaded guilty in London on the first day of their trial, over the August 2024 attack that crippled Transport for London. Jubair, who prosecutors say co-ran a SIM-swapping-for-hire channel called Star Chat that phished credentials from wireless-carrier employees, is separately charged in New Jersey over 120 intrusions at 47 US companies and at least $115 million in ransom payments. Same brand, many operators, one method: talk past a human, then use valid access.
I have written about the wider ecosystem these actors move through, The Com, and why it outlives any single arrest, in Scattered Lapsus$ Hunters announce they are going dark but the threat remains.
What to check
If you run a security program, the Stokes complaint is a free tabletop exercise. A few questions worth asking against your own environment:
- If someone social-engineered your help desk into resetting an employee's password and MFA today, what would alert, given that the next sign-in authenticates cleanly?
- Do you have a behavioral baseline per identity, so a standard user drawing privileged credentials and then reaching new systems stands out as unusual?
- Would a first-time ngrok or Teleport tunnel from a production server, or a large outbound transfer to S3, surface as something to investigate before the upload finishes?
This is the same post-authentication pattern I traced across the ShinyHunters campaigns in ShinyHunters isn't a group. It's a pattern: different actor, different entry point, the same sequence of access, persistence, exploration, and exfiltration once the login works. The Stokes complaint is one more data point for the same thesis, this time written under oath.
At Vectra AI, this is the work we focus on: the behavior that follows a successful login, across identity, SaaS, and cloud, where signatures and prevention have nothing left to catch.
If you want the full anatomy of a Scattered Spider intrusion and where the early behavioral signals appear, that is Chapter 2 of Mind Your Attack Gaps, on Gap 2: authentication succeeds.