The Scattered Spider Airline Wave: A Help-Desk Social-Engineering Drill

In late June 2025, the threat group known as Scattered Spider turned its attention to airlines — Hawaiian Airlines, Canada's WestJet, and Qantas were all hit in quick succession, and the FBI issued a public warning about the campaign. The break-in method was not a clever exploit. It was a phone call. The attackers called IT help desks, impersonated an employee or contractor, and talked an agent into resetting a password or registering a new MFA device on a high-value account. Mandiant's advice to clients was blunt: tighten help-desk identity verification now, before adding any new phone number or MFA device to an account. This post turns that advice into a 5-step drill an Indian support team can run this week. ## The answer in 60 words Scattered Spider gets in by calling your help desk and impersonating a staff member to trigger a password or MFA reset. The fix is a hardened verification ritual: never reset on caller-supplied info, require a second channel and a manager approval for any MFA-device change, and put a hard hold on new-device enrolment. Run a vishing simulation this month. Most of the defence is process, not product. ## Why this matters now (with sources) This isn't a hypothetical. In June 2025 the FBI publicly warned that Scattered Spider had shifted focus to the airline and transportation sector after the breaches at Hawaiian Airlines, WestJet, and Qantas. The group's tradecraft is well documented by CISA and Mandiant: social engineering of IT help desks to harvest credentials of high-value users — system admins, CFOs, COOs, CISOs — then data theft and often ransomware. CISA notes the actors even join incident-response calls to watch how defenders hunt them. The reason an Indian SMB or BPO should care: the exact same playbook works against any support desk that resets credentials on a phone call. You don't need to be an airline. You need to have a help desk and MFA — which is to say, you need to be almost any modern business. Read the primary reporting on the airline wave at CSO Online and the FBI warning coverage at TechRepublic. ## How the attack actually runs The whole chain hinges on step 3. If your help desk cannot be socially engineered into resetting credentials, the rest collapses. That's where the drill focuses. ## The 5-step help-desk verification drill ## What to harden, in priority order ## When a control is overkill (the honest limits) Not every team needs video identity proofing on every call. For a 10-person company with no admin help desk, the realistic control is simpler: turn on phishing-resistant MFA, enable user-notification on MFA changes, and agree that no one resets anyone's access without a callback. Over-engineering verification for a tiny team creates friction people route around — which is worse than a lighter control they actually follow. Scale the friction to the value of the account. The drill in this post is calibrated for a team with a real support function; shrink it sensibly if you're smaller. Equally, a vishing simulation run without consent and clear rules of engagement can blow up trust internally. Get written authorisation, brief leadership, and debrief agents as a learning exercise — never a gotcha. This is the same engagement discipline our team applies on any security review. ## A pattern we keep seeing in Indian support teams As Khushi, who runs our security reviews, points out, we've reviewed help-desk and support workflows for several Indian SMBs and BPOs, and the recurring gap is identical: MFA is enabled, everyone feels covered, and yet the help desk can reset an MFA device on a confident phone call with zero out-of-band check. MFA without a hardened reset process is a locked door with the key taped to the frame. The hardest-hit accounts are always the finance and admin ones — the same crown-jewel scoping we built into the audit trail for Radiant Finance. The fix costs almost nothing — it's a script, a callback rule, and a notification toggle. We saw the same festive-season pattern when phishing spikes around Indian holidays; the controls overlap heavily with our 30-minute Diwali-week hardening checklist and the access-review steps in our year-end cyber-hygiene sprint. For the conference-circuit view of how these groups operate, our DEFCON 33 debrief walks through the social-engineering village findings. ## Common mistakes (the wrong reactions seen in the wild) Symptom: "We added more security questions." Cause: treating researchable knowledge as authentication. Scattered Spider researches the answers. Fix: out-of-band verification, not more questions. Symptom: "We trust caller ID." Cause: caller ID is trivially spoofed. Fix: never let an inbound number be proof of identity; always call back on the record number. Symptom: "Only IT can reset, so we're fine." Cause: IT is the target. The attacker calls IT and impersonates a user. Fix: the verification ritual binds the IT agent, regardless of who they think they're helping. Symptom: "We turned on push MFA and called it done." Cause: push-approval can be bombed until a tired user taps "approve". Fix: number-matching at minimum; FIDO2/passkeys for high-value accounts. Symptom: "We ran a phishing email test, so we're covered." Cause: email phishing and voice phishing are different muscles. Fix: run a dedicated vishing simulation against the help desk specifically. ## Our take The airline wave is a gift in one narrow sense: it's a loud, named, recent example you can take to leadership to fund a boring control. The defence here is unglamorous — a script, a callback, a notification, a quarterly drill — and that's exactly why it gets deprioritised until a peer in your sector is in the headlines. Run the drill while the news is fresh. For the founder's-eye view on this beat, our founder writes about social engineering and supply-chain risk at viveksinra.com. And if you want to see how the security community dissects these groups, the discussion threads on Mandiant's and CISA's advisories are worth reading end to end. ## FAQ ### How does Scattered Spider break in? Primarily through social engineering of IT help desks. They research a real employee, call in impersonating them, and talk an agent into a password reset or a new MFA-device enrolment. Once in, they steal data for extortion and sometimes deploy ransomware. The initial vector is a phone call, not a software exploit. ### Why did they target airlines in June 2025? Airlines have large help-desk operations, many contractors, and high-value data — a good match for the group's playbook. After hitting Hawaiian Airlines, WestJet, and Qantas, the FBI issued a public warning that the sector was being actively targeted. The same method works against any organisation with a help desk and MFA. ### What's the single most important defence? A hardened help-desk verification ritual: never authenticate on caller-supplied information, require an out-of-band callback to a record-of-truth number, and put a hard hold with manager approval on any new MFA-device enrolment. Most of the defence is process, not a product you buy. ### Does MFA stop this attack? Not by itself. The attack abuses the MFA reset path. Phishing-resistant MFA like FIDO2 keys or passkeys shrinks the prize and resists relay and push-bombing, but you still need a hardened reset process — otherwise the help desk simply enrols the attacker's device. ### How do I run a vishing simulation safely? Get written authorisation from leadership, define clear rules of engagement, and use an authorised tester who calls your own help desk with the real attacker script. Measure how often agents deviate from policy under pressure, then debrief as a no-blame learning exercise. Repeat quarterly and after any policy change. ### Are Indian SMBs and BPOs at risk from this? Yes. The technique is sector-agnostic — any support desk that resets credentials over the phone is exposed. BPOs are especially relevant because they often run help desks for other companies, which makes a single compromised agent a path into multiple clients. The controls in this post apply directly. ### What should I tell my help-desk agents today? Give them a script: no credential or MFA changes without an out-of-band callback to the number on file, no exceptions for urgency or authority, and a no-blame escalation button. Make verification the routine, expected behaviour so saying "I'll call you back on your registered number" never feels rude.