Help-Desk Social Engineering — Critical Infrastructure

Transport for London: a four-day help-desk call that became the UK's biggest cybercrime case

Nobody broke any encryption to get into Transport for London. Somebody picked up a phone, read out a stolen employee's name, and asked for a password reset. Two years later, the two men behind that call were in a UK courtroom — not a settlement hearing, an actual sentencing — and TfL was still explaining to customers why its first public statement about the breach turned out to be wrong.

Attack duration

4 days (Aug 31 – Sept 3, 2024)

Confirmed cost

£39 million (TfL's own figure)

Customers notified

7.1 million

Staff required to reset in person

About 28,000–30,000

Sentences

5.5 years each, two defendants

Legal first

First UK conviction under CMA 1990 s.3ZA

Background

Transport for London runs the Underground, buses, Dial-a-Ride and the Oyster and contactless payment systems that most of the city uses to get around every single day. It is also, like most large organizations, built around a help desk whose entire job is to make locked-out staff productive again as fast as possible — which is exactly the job Scattered Spider has spent several years learning to exploit. The group doesn't write custom malware or hunt zero-days as a rule. It calls people, and asks nicely, with just enough stolen detail to sound legitimate.

From one phone call to a national cybercrime case

Fig. 1 — Every box above this line is a phone call and a typed command. None of it required breaking anything technical.

What actually happened

The intrusion ran for roughly four days, from August 31 to September 3, 2024. It started the way a large share of Scattered Spider's intrusions start: someone called TfL's IT help desk, presented a TfL employee's stolen login details as their own, and asked for a password reset. The help desk didn't catch it — the same gap that had already been exploited against MGM Resorts and Caesars Entertainment the year before, a technique well enough known by then that CISA and the FBI had published a joint advisory naming it specifically.

With a reset, valid-looking credential in hand, the attacker escalated. By September 1, they had created a domain administrator account — the kind of access that, in most organizations, is supposed to require far more than a convincing phone call to obtain. From there they moved through TfL's internal systems, coordinating activity over Telegram, reaching staff email, the Dial-a-Ride booking platform, and the application systems behind Oyster photocards and the Zip card used by students and young people.

TfL caught the activity quickly by industry standards — within roughly a day of the domain admin account appearing — and went public on September 2, one day after first detecting it. Its initial public statement said no customer data had been compromised. That statement did not hold. Over the following two weeks, TfL's investigation found that 7,113,429 customers with a registered email address needed to be told their data may have been accessed, and roughly 5,000 customers specifically had bank details — a sort code and partial account number tied to Oyster refunds — potentially exposed.

What TfL did next is the part of this story that doesn't usually make it into a breach timeline: it required somewhere between 28,000 and 30,000 staff to physically show up at a TfL office to verify their identity and reset their passwords in person, rather than trust the same remote process the attacker had just walked through. Core transport operations — trains and buses actually running — were not disrupted at any point. Dial-a-Ride bookings, Oyster and Zip card applications, and refund processing were.

The criminal case took until July 2026 to conclude. Thalha Jubair and Owen David Flowers, both UK nationals and Scattered Spider members, pleaded guilty and were sentenced at Woolwich Crown Court on July 16, 2026, to five and a half years each — the first successful prosecution under Section 3ZA of the UK's Computer Misuse Act 1990. The National Crime Agency called it the biggest cybercrime case the UK has ever prosecuted. Flowers had separately been connected to the 2023 MGM Resorts and Caesars Entertainment intrusions; Jubair was tied, via a separate US federal indictment, to a pattern of Scattered Spider attacks against more than 100 organizations since May 2022, totalling over $115 million in ransom payments.

"No customer data compromised" — until it wasTfL's first public statement, issued the day after detection, said customer data had not been affected. That held for roughly two weeks. It wasn't a lie — it was almost certainly the honest state of the investigation at that moment, said out loud before the investigation was finished. The lesson isn't "don't communicate early." It's that an early statement about what wasn't touched needs to be phrased as a preliminary finding, not a conclusion, because the gap between the two is exactly where trust gets spent twice: once at the breach, and again at the correction.

Root cause

Confirmed

Initial access was obtained through TfL's IT help desk, where an attacker presented a stolen employee's login details and received a password reset with no verification beyond the caller's own claim of identity.
The reset credentials were used to create a new domain administrator account by September 1 — a genuine privilege-escalation event, not an assumption.
The attacker coordinated activity over Telegram and reached staff email, Dial-a-Ride, and Oyster/Zip card application systems before detection.

Reasonable hypothesis — not confirmed

That the underlying failure was specifically in the help desk's identity-verification and MFA-enrolment workflow is a reasonable reading of the confirmed facts, but it is an analyst's synthesis, not a root-cause finding TfL or the NCA has published in those exact words.
Whether multifactor authentication was present but routed around via the reset (Scattered Spider's standard playbook targets MFA re-enrolment rather than defeating MFA outright), or was simply absent on the affected account, has not been confirmed in public reporting.

Timeline

An attacker calls TfL's IT help desk using a TfL employee's stolen login details and requests a password reset. No verification beyond the caller's own claim catches it.

T1598.004 · Phishing for Information: Spearphishing VoiceT1566.004 · Phishing: Spearphishing Voice

Using the reset credentials, the attacker escalates privilege and creates a domain administrator account — the single moment real, lasting access was gained.

T1078.002 · Valid Accounts: Domain AccountsT1199 · Trusted Relationship

The attacker moves through staff email, Dial-a-Ride's booking platform, and the Oyster/Zip card application systems, coordinating over Telegram.

TfL's internal security identifies the suspicious activity roughly a day after the domain admin account appears — fast, relative to how long these intrusions typically run undetected elsewhere.

TfL discloses an ongoing cyber security incident publicly, one day after detection. The initial statement says customer data has not been affected.

Rather than trust the same remote reset process the attacker had just used, TfL requires an estimated 28,000–30,000 staff to physically attend a TfL office to verify identity and reset credentials.

Investigation corrects the earlier statement: 7,113,429 customers with a registered email address are told their data may have been accessed; roughly 5,000 are told bank details tied to Oyster refunds may be exposed too.

Thalha Jubair and Owen Flowers are sentenced to five and a half years each at Woolwich Crown Court — the first successful UK prosecution under Section 3ZA of the Computer Misuse Act 1990.

Fig. 2 — Four days of actual intrusion, roughly two weeks to find the real scope, and nearly two years to reach a courtroom.

Detection

How it was discovered

TfL's own internal security team identified the suspicious activity roughly a day after the domain administrator account was created on September 1, 2024 — public sources don't specify the exact technical alert or signal that surfaced it, only the timing.

Time to detect

About one day from the domain admin account's creation (Sept 1) to internal detection, and about one more day to public disclosure (Sept 2) — fast by the standard of comparable intrusions, though the help-desk call that started the intrusion on August 31 itself generated no alert at the time it happened.

Warning signs that were missed

The help-desk password reset itself — granted on a stolen employee's claimed identity alone, with no independent verification — was the one disclosed point where the intrusion could have been stopped before any access was gained, and it produced no alert.
Scattered Spider's help-desk social-engineering tradecraft had already been publicly documented by CISA and the FBI in a joint advisory a year before this attack, following its use against MGM Resorts and Caesars Entertainment — a known pattern that wasn't specifically defended against at TfL's help desk.

What to monitor for in your own environment

A password reset or MFA re-enrollment request approved over the phone with no verification beyond the caller's claimed identity

Help-desk call logs and identity-verification records

Creation of a new domain administrator or other privileged account

Active Directory / identity provider privileged-account creation logs

Unusual access to multiple distinct business systems (staff email, booking platforms, card-application systems) by a single recently created privileged account

Cross-system access and audit logging tied to account-creation events

Containment, eradication & recovery

Containment

Sept 1–2, 2024

Identified the suspicious activity internally within roughly a day of the domain admin account's creation.
Disclosed the incident publicly on September 2, one day after detection.

Eradication

Sept 2024

Required an estimated 28,000–30,000 staff to physically attend a TfL office to verify their identity and reset credentials in person, rather than trust the same remote reset process the attacker had used.
Took the Dial-a-Ride booking platform and Oyster/Zip card application systems offline temporarily while the compromise was addressed.

Recovery

Sept 2024 – Jul 2026

Corrected its initial "no customer data compromised" statement roughly two weeks later, confirming 7,113,429 customers needed notification and about 5,000 had partial bank details exposed.
Core train and bus operations were never disrupted at any point throughout.
Cooperated with law enforcement over nearly two years, leading to the July 2026 sentencing of Thalha Jubair and Owen Flowers — the first UK conviction under Section 3ZA of the Computer Misuse Act 1990.

Security control analysis

Failed

Help-desk identity verification

A password reset was granted on a stolen employee's claimed identity alone — the precise gap Scattered Spider is known to target, and the one that let the entire intrusion begin.

Partial

Multifactor authentication

Not confirmed as present-and-bypassed or simply absent in public reporting. Scattered Spider's standard playbook targets MFA re-enrolment during a help-desk reset rather than defeating MFA cryptographically, so even a present MFA control may not have stopped this specific path.

Failed

Privileged access controls

A domain administrator account was created during the intrusion window without apparently triggering a block or an immediate alert — privileged-account creation wasn't gated tightly enough to stop it in real time.

Held

Network segmentation between operational and administrative systems

Trains and buses kept running throughout. Whatever separated live transport operations from the systems the attacker reached, it worked.

Held

Detection and internal monitoring

TfL identified the suspicious activity within roughly a day of the domain admin account appearing, and disclosed publicly within a day of that — fast by the standard of comparable incidents.

Held

Post-incident identity remediation

Requiring in-person verification for tens of thousands of staff is expensive and disruptive, but it is a genuinely strong response to "we can no longer trust our own remote reset process."

Controls that would have prevented or limited this

Fix

Require a verification step beyond caller-claimed identity for any password reset or MFA re-enrollment request received by phone — a callback to a number already on file, or a second independent factor the caller can't simply state

Would have stopped the entire intrusion at its starting point — the reset was granted on the caller's claim alone.

Closes: Help-desk identity verificationCIS Control 6 — Access Control Management

Fix

Gate domain administrator and other high-privilege account creation behind a real-time, actively monitored alert and a second-person approval, not just a log entry reviewed later

Would have surfaced the September 1 domain admin account creation immediately rather than roughly a day later, shrinking the attacker's window of unmonitored access.

Closes: Privileged access controlsCIS Control 5 — Account Management

Fix

Treat MFA re-enrollment requested during a help-desk interaction as its own high-risk event requiring independent verification, since Scattered Spider's standard playbook targets re-enrollment rather than defeating MFA cryptographically

Would close the specific gap this group is known to exploit even when MFA is nominally present.

Closes: Multifactor authenticationCIS Control 6 — Access Control Management

Blast radius

What was hit

Staff email and internal systems, reached via a domain administrator account
Dial-a-Ride booking platform, taken offline temporarily
Oyster photocard and Zip card application systems, paused
7.1 million customers' personal data, and roughly 5,000 customers' partial bank details

What stayed protected

Core train and bus operations — service was never disrupted
Passport-equivalent travel documents and full payment card numbers
The bulk of TfL's 30,000-plus workforce's access, once in-person resets were enforced

Fig. 3 — The line that held mattered most: a transport network that moves millions of journeys a day kept running through an active domain-admin-level compromise.

The reported cost of the attack, two ways

Fig. 4 — Early cost estimates almost always understate a breach's real total. TfL's own confirmed damage-and-disruption figure, reported alongside the July 2026 sentencing, is a third higher than the number that circulated in the weeks after the attack.

What they got right

Detection was fast. TfL identified the suspicious activity within roughly a day of the domain administrator account being created, and went public with an initial disclosure within a day of that — a genuinely tight window compared to intrusions that run undetected for weeks or months before anyone notices.

TfL didn't quietly patch the help desk process and move on. It required an estimated 28,000 to 30,000 staff to physically attend an office to verify their identity and reset credentials in person — an expensive, disruptive decision that said, in effect, "we no longer trust the exact process the attacker just used," rather than assuming a policy memo would be enough.

Core operations were protected. Whatever separated the systems an attacker with domain admin access could reach from the systems that actually run trains and buses, it held for the full duration of the intrusion. That's not automatic — a domain admin account is a lot of access, and a flatter network would have let that access go a lot further.

Law enforcement engagement led somewhere. This isn't a story where the attackers simply moved on to the next target. Two years later, both men were convicted and sentenced to real prison time under a law rarely successfully used — which required TfL's cooperation and evidence to stand up.

Why this keeps happening

Scattered Spider's core tradecraft is not technical in the way most breaches are. CISA and the FBI's joint advisory AA23-320A, published in November 2023, describes a group that researches an organization's actual help-desk procedures first — sometimes through earlier reconnaissance calls — then executes a second call that exploits exactly the verification gap it found. TfL fits that pattern precisely.

This wasn't an isolated attempt against an unlucky target. The same group, or members closely tied to it, had already been connected to the 2023 intrusions at MGM Resorts and Caesars Entertainment — incidents that cost MGM an estimated $100 million in losses and led Caesars to pay a disputed but substantial ransom. A separate US federal indictment ties Jubair to a pattern of attacks against more than 100 organizations since May 2022, totalling over $115 million in ransom payments across that campaign alone.

The reason this keeps working against security-mature, well-resourced organizations isn't a lack of investment — it's that the vulnerability sits in a process, not a product. A help desk exists specifically to be fast and helpful to someone who sounds like they belong. Scattered Spider's entire method is built around sounding exactly like that.

The sentencing itself is part of why this case is worth studying, not just the breach. Real prison time for cybercrime, especially cybercrime of this scale, is still the exception rather than the rule — most of the financial and operational damage done by groups like this one is never followed by a courtroom outcome at all.

Lessons for your own environment

A help desk's speed is also its attack surface
The entire intrusion started with a phone call that exploited the help desk's actual job: resolving a lockout quickly. A verification process that's fast enough to be convenient is, by definition, fast enough for an attacker who sounds convincing to exploit.
Privileged-account creation needs to alert in real time, not just log
A domain administrator account was created during the intrusion without stopping it. If creating that level of access doesn't trigger an immediate, actively-monitored alert, the account exists and is usable long before anyone reviews a log that shows it happened.
Segmentation between operations and administration is what actually limited this
Domain admin access is a lot of access. The reason trains and buses kept running anyway is that whatever separates live operational systems from the rest of the network held. That separation is worth auditing on its own, specifically against the question "if an attacker had this exact level of access, what could they reach."
An early "no customer data compromised" statement needs a built-in caveat
TfL's early statement wasn't dishonest, but it didn't hold, and the correction two weeks later cost trust it didn't need to spend twice. Phrase early findings as preliminary, explicitly, so a later correction reads as the investigation continuing — not as a walk-back.
Sometimes the right fix is physical, not technical
Requiring in-person identity verification for tens of thousands of staff is not a scalable long-term control, but as an immediate response to "our remote verification process was just exploited," it's a genuinely sound call. Not every post-incident fix has to be a new tool.
A conviction took two years — plan your incident response assuming it might, or might not, ever come
The criminal case concluded in July 2026, nearly two years after the attack. An organization's own recovery, customer trust rebuilding, and control improvements can't be built around the assumption that a conviction is coming, or coming on any particular timeline.

CISO & board lessons

Help-desk identity verification is a board-level risk decision, not an IT-operations detail. The control that failed here is cheap to describe and genuinely hard to implement without adding friction every employee will complain about — that tradeoff deserves an explicit, documented risk decision from leadership, not an assumption that IT has it handled.
Ask specifically: what does our help desk actually require before resetting a credential or enrolling a new MFA device, and when was that last tested by someone trying to break it, not just trying to use it correctly?
A domain administrator account being created is one of the highest-value real-time alerts an organization can build. If your SOC would find out about that the next morning in a report rather than within minutes, that's a gap worth funding ahead of almost anything else on a security roadmap.
Plan the public-communications sequence for a breach assuming the first statement will need a correction. "No evidence of X as of this moment, investigation ongoing" protects credibility in a way "X did not happen" cannot, if the investigation isn't actually finished yet — and it rarely is, this early.
Budget for the physically disruptive version of incident response, not just the technical one. TfL's in-person reset program for tens of thousands of staff was expensive and inconvenient — and it was also the decision that mattered most for actually re-establishing trust in its own identity systems afterward.

Action plan

First 24 hours

Audit exactly what your help desk requires to approve a password reset or MFA re-enrolment, and whether that process has ever been tested by an internal red-team call, not just documented in a policy.
Confirm that privileged-account and privilege-escalation events (new domain admin accounts, new global admin roles) generate a real-time, actively monitored alert — not a log entry reviewed days later.
Review your draft breach-notification language for any absolute claim ("no customer data was accessed") and replace it with a preliminary-finding framing before anything is published.

First 7 days

Walk through what an attacker with domain administrator access could actually reach in your environment, and whether operational systems are genuinely segmented from administrative ones — not just logically separated on a diagram.
Identify your highest-value, most time-sensitive systems (the equivalent of TfL's live transport operations) and confirm they would survive an admin-level compromise elsewhere in the network.
Brief the board and executive team on the help-desk social-engineering threat model specifically — this is a different conversation than generic phishing awareness.

First 30 days

Implement call-back verification or a comparable out-of-band step for any credential reset or MFA re-enrolment request that arrives by phone.
Build and rehearse a tabletop exercise specifically modelling a help-desk-originated compromise, including the decision to require in-person identity verification if remote processes can no longer be trusted.
Establish a relationship with law enforcement and a forensic retainer ahead of time — the eventual prosecution in this case depended on evidence and cooperation gathered from day one, not assembled after the fact.

Could this happen in your organization?

Could someone get a password reset or MFA device re-enrolled on your systems using only a name, an employee ID, and a convincing phone manner?
Would the creation of a new domain administrator or global admin account trigger a real-time alert at your organization, or only show up in a log reviewed later?
If your help desk's remote verification process were compromised tomorrow, do you have a plan for in-person or out-of-band re-verification at scale?
Are your most critical operational systems genuinely segmented from the systems an admin-level account could reach — and when was that last tested, not just diagrammed?
Does your draft breach-notification language make any absolute claim about what wasn't affected, before the investigation is actually complete?
Do your frontline help-desk staff receive training specifically on multi-call social-engineering patterns, not just generic phishing-email awareness?
Do you have a forensic and legal relationship already in place, so that evidence supporting a future prosecution is being preserved from the first hour of an incident?

If this happened to you: what to ask, and what to say

Knowing the lesson isn’t the same as knowing what to do with it Monday morning. A security lead, a CISO, and a customer-facing team each need something different from this incident.

Ask your security teamTell your leadershipTell your customers

"Could our help desk be talked into a password reset the way TfL's was?"
Have someone attempt it internally, as a red-team exercise, rather than assuming the documented policy is actually what happens on a busy Tuesday.
"Would we catch a new domain admin account in minutes, or find it in a report next week?"
Name the actual alerting mechanism. If the honest answer is "we'd notice during a routine review," that's the gap to close first.
"If we had to force everyone to re-verify their identity in person, could we actually do that?"
TfL managed this for roughly 30,000 staff. Walk through whether your organization has the physical and logistical capacity to do the same if it had to.
"Is our breach-notification language ever going to need correcting?"
Review draft public statements for absolute claims made before an investigation is complete. A preliminary-finding framing protects credibility far better than a confident statement that later needs walking back.

Say what happened, in one plain sentence.
A board member should hear the actual mechanism, not a euphemism.
"An attacker called our help desk, convinced them to reset a stolen employee's password, and used that access to create an administrator account. No encryption was broken and no system was hacked in the traditional sense — a process was talked past.
Own that the first public statement didn't hold.
This will come up in any serious review. Address it directly rather than let it surface as a credibility problem later.
"Our first statement reflected the honest state of the investigation at that hour, and it needed correcting two weeks later. We're changing how we phrase preliminary findings so that correction reads as the investigation continuing, not as a reversal.
Name the control that failed, specifically.
"We're reviewing security" is not an answer a board should accept.
"The failure was in our help desk's identity-verification process for password resets. That's the specific control we're rebuilding first, not a general security refresh.
Commit to a concrete, dated remediation step.
Vague reassurance doesn't survive scrutiny the way a specific, dated commitment does.
"Call-back verification for any phone-based credential reset will be in place within 30 days. We'll report back to this board on its implementation specifically.

Correct the earlier statement plainly, without burying it.
Customers who read the first statement deserve to know it changed, stated directly rather than implied.
"Our initial statement said customer data had not been affected. Our investigation has since confirmed that some customer data was accessed. We're telling you this directly because you deserve the accurate picture, not the first one."
Tell affected customers exactly what data was involved.
Vague language about "potentially affected information" leaves people assuming the worst.
"If you're one of the approximately 5,000 customers we've contacted individually, your sort code and partial account number tied to an Oyster refund may have been exposed. For the broader group, the data involved was [name it specifically].
Explain the practical fix in terms a customer can evaluate.
"We've improved our security" tells a customer nothing they can act on.
"We've required our own staff to re-verify their identity in person before regaining system access, and we've rebuilt the process an attacker used to get in. The specific gap that let this happen no longer exists the way it did.
Warn customers about the scams that follow a breach this size.
A high-profile incident draws copycat phishing within days.
"We will never call or email you asking you to reset a password or confirm account details because of this incident. Treat any message that does as fraudulent and report it to us directly."

References & confidence

ConfirmedCrown Prosecution Service — Cyberhackers who targeted TfL jailed for more than five years each
ConfirmedNational Crime Agency — Two sentenced for hacking Transport for London in UK's biggest ever cyber crime case
ConfirmedTechRadar — TfL admits 2024 cyberattack may have affected over 10 million people — The 7,113,429-customer figure and the £39 million cost figure are TfL's own stated numbers; a separate, looser "10 million" figure appearing in some coverage is not as precisely sourced.
ConfirmedTech Monitor / Cyber Daily — TfL directs 30,000 employees to verify identities and reset passwords in person
ConfirmedInside Croydon — Bank details for 5,000 TfL passengers accessed in cyber attack
ConfirmedCISA/FBI Joint Advisory AA23-320A — Scattered Spider — Primary source for the group's help-desk social-engineering tradecraft pattern.
ReportedKrebs on Security — Feds Tie Scattered Spider Duo to $115M in Ransoms — The $115M figure and 100+-victim count come from a federal indictment as reported by this outlet, not a court finding yet entered into the public record in full.
DisputedEarlier £29 million cost estimate, circulated shortly after the attack — Superseded by TfL's own later-confirmed £39 million figure, cited alongside the July 2026 sentencing; both figures appear in reporting and are presented here rather than silently picking one.
DisputedClaim that the intrusion involved "exploiting a vulnerability in a third-party IT system" — This claim appears in one secondary source and contradicts the same source's own help-desk social-engineering narrative elsewhere. Not used in this case study.

This case study is built entirely from public reporting on this incident — see References & confidence above for what's confirmed, reported, or still unconfirmed. Nothing here is an estimate or an illustrative placeholder.