Status: developing story. Last updated 16 July 2026. I will keep this post current as the legal and forensic picture fills in — the newest entries are logged under "Updates" below, and the "what we know" section reflects the latest confirmed position.

Reporting this week has put a name to the root cause of one of last year's largest data breaches, and it is worth sitting with, because it is not the name most people expect. The Qantas breach that exposed 5.7 million customers was not, at its root, a clever exploit or an unpatched server. It was a phone call. A tech-support scam — social engineering, done down a telephone line — got someone to open a door that no firewall was ever going to close.

I am writing this as a living account. The forensic and legal detail is still landing, so I have been careful below to separate what is confirmed from what is reported-but-unproven, and to flag what is still open. I will update it over the coming fortnight as the picture sharpens.

Updates

What we know

On 30 June 2025, a threat actor targeted one of Qantas's airline contact centres and gained access to a third-party customer-servicing platform holding service records for around six million people. Qantas detected the unusual activity and contained it. It has never publicly named the platform; external reporting consistently identifies it as a Salesforce-based system, operated through a contact centre in Manila. That distinction matters for precision, so I will keep the parts Qantas has confirmed separate from the parts the press has filled in.

After removing duplicates, Qantas confirmed that 5.7 million unique customers had data in the system. The exposure was tiered. Around four million records were names, email addresses and frequent-flyer details — of which roughly 1.2 million were name and email only, and 2.8 million also included a frequent-flyer number, some with tier, points balance and status. A further 1.7 million records carried more: about 1.3 million addresses, 1.1 million dates of birth, 900,000 phone numbers, 400,000 gender entries, and 10,000 meal preferences.

Qantas states that no credit-card details, financial information or passport numbers were held in the platform and so none were taken, and that no passwords, PINs or login details were accessed. That is genuinely better than many breaches — but read it precisely. It is Qantas's own assessment, and the reassurance about cards and passports rests on those fields not being stored in this particular system, not on an independent forensic finding that the attacker failed to reach them. It is a statement about scope, not a clean bill of health.

The stolen data did not stay quiet. On 11 October 2025 it was released on the dark web by the extortion crew, after the ransom route ran its course.

Who did it, and how

The intrusion is linked to the loose cluster that reporting variously calls Scattered Spider, ShinyHunters, or "Scattered Lapsus$ Hunters" — with the specific operators behind the 2025 wave of Salesforce thefts tracked by Google's Mandiant as UNC6040. The labels overlap and are used loosely; the tradecraft is what matters, and it is consistent.

These are not sophisticated exploit developers. They are talkers. The CISA and FBI advisory on the group documents their signature move plainly: impersonate IT or help-desk staff by phone and SMS, talk a real employee or an outsourced agent into handing over credentials, and get the help desk to reset passwords and multi-factor tokens. They do not break multi-factor authentication. They ask someone to turn it off for them. I have written before about what these teenagers taught the Fortune 500; Qantas is the same lesson, told again.

One important honesty note on the mechanism. Across the 2025 Salesforce campaign, the common method was tricking a contact-centre agent into authorising a malicious connected application — often a rogue version of Salesforce's own Data Loader — which then quietly exported the customer database. Whether Qantas was compromised that way, or through a more traditional credential-and-MFA reset, has not been confirmed by any primary source I can find. The phone call is confirmed. The exact keystrokes at the other end are not, yet.

The legal and regulatory thread

Qantas notified the Office of the Australian Information Commissioner of an eligible data breach under the Notifiable Data Breaches scheme, and the OAIC has been engaging with it on compliance. The law firm Maurice Blackburn lodged a representative complaint with the OAIC under the Privacy Act 1988, alleging Qantas failed to take reasonable steps to protect personal information, and seeking compensation for the affected customers. Qantas is also reported to have secured a court injunction restraining anyone from accessing or sharing the stolen data — a move several breached firms now make, and one worth being honest about: an injunction against anonymous offshore criminals who have already published the data is close to symbolic. It signals seriousness to customers and courts; it does not un-leak a 153-gigabyte file.

What is still unclear

Because this is a developing story, here is what I am not yet asserting as fact:

The precise nature of this week's new detail — whether it is a court filing, a statement of claim, an affidavit or a regulator finding — and exactly what it says the attacker impersonated and how the agent was induced to act. The "tech-support scam" characterisation is now firmly in the reporting; the underlying primary document is what I am waiting to read.

The exact technical vector at Qantas: malicious OAuth connected app versus credential and MFA reset. Both are documented for this group; neither is confirmed for this victim.

The current status of the OAIC investigation and the Maurice Blackburn complaint as of now, and whether the figures — six million records in the platform, 5.7 million confirmed affected, "over five million" actually leaked — have been fully reconciled.

I would rather leave those open than tidy them prematurely. I will close them here as they are answered.

Why this one matters

Strip away the airline and the size, and this is the most ordinary breach in the world, which is exactly why it should worry you. There was no zero-day. The attackers did not out-engineer Qantas. They phoned a help desk and were let in.

That is the uncomfortable centre of gravity in security right now. Organisations have spent a decade hardening the technical perimeter — patching, multi-factor, endpoint detection — and attackers have quietly responded by going around it, through the one component you cannot patch: a helpful human being on a support line whose entire job is to say yes to people who sound stressed and legitimate. Multi-factor authentication was almost certainly in place. It did not matter, because the attack was aimed at the process that resets it, not the factor itself.

And it was not one unlucky airline. The same crew ran the same play through a long list of large names across 2025, because a contact centre is a contact centre whether it belongs to an airline, an insurer or a luxury-goods house. When an attack technique is this repeatable and this cheap, it is not a Qantas problem. It is a help-desk problem, and almost everyone has a help desk.

What to actually do about it

The controls that would have blunted this are unglamorous and mostly free, which is the recurring theme of everything I write here.

Fix the help desk before you buy anything. The single highest-value change is a hardened identity-verification process for anyone requesting access, a password reset, or an MFA change — especially by phone. That means verification that a caller cannot simply talk their way through: a call-back to a known number, a one-time code issued through a separate channel, a manager approval step for privileged resets, and an explicit rule that agents never reset credentials or MFA on an inbound request alone. Write it down, and — this is the part people skip — test it with your own social-engineering attempt before an attacker does.

Adopt phishing-resistant MFA, but do not think it finishes the job. Moving to FIDO2 security keys and passkeys defeats the credential-phishing half of this problem, and it is worth doing. Salesforce itself is now mandating phishing-resistant MFA for privileged users, with production enforcement from 20 July 2026 — a direct response to this campaign. But be clear-eyed: a security key on your finger does nothing if the attacker persuades a help desk to enrol a new key for them. Phishing-resistant MFA and a phishing-resistant reset process are two different projects. You need both.

Govern the SaaS you have forgotten is a database. A CRM full of millions of customer records is a crown-jewel datastore that most boards think of as "the sales tool." Treat it like the database it is: least-privilege access so no single agent can export the lot, tight control and review of connected OAuth applications, and alerting on anomalous bulk exports — the Data Loader pulling a whole customer base at 3am is exactly the signal you want to catch. Data minimisation matters here too; a contact centre rarely needs every customer's date of birth to answer a query about a flight.

Assume the phone is now the front door. I have argued that email is the front door; the Qantas breach is the reminder that the telephone is the other one, and it is far less monitored. Social-engineering awareness for contact-centre and help-desk staff is not a compliance box; for these teams it is the primary control.

What to watch over the next fortnight

For anyone following this as it develops, the things worth tracking: the primary filing or finding behind this week's "tech-support scam" reporting, which should clarify the exact mechanism; the OAIC's position and any enforcement outcome under the Privacy Act; the progress of the Maurice Blackburn complaint and any parallel class action; and whether the affected-versus-leaked figures are ever fully reconciled. I will fold each of those into this post as it lands.

The headline will fade in a week. The lesson will not. The most expensive intrusion many organisations will suffer this year will not come through a firewall. It will come through someone doing their job politely on a phone, and the fix is not a product — it is a process, rehearsed, that lets a helpful person safely say no.