Breach Teardown
What Caused the Qantas Breach?
On a Saturday in June 2025, a caller posing as “Qantas IT help” walked a contact-centre agent through what sounded like closing a support ticket. Those steps connected the agent’s CRM session to the attacker’s data extraction tool. Australia’s privacy regulator later found that the vulnerability arose from a platform default that let any end user approve a third-party app connection, and about 5.67 million customer records were compromised.
By Vidyaa Ganesh, Founder, Identara
- Scale
- ~5.67M customer records; ~5.12M Australians affected (per OAIC)
- Attack vector
- Vishing call led an agent to unknowingly link an attacker’s app to the CRM
- IAM domains implicated
- Cloud, Security
- Domino controls hit
- 0 of 3
The Incident
What Happened
Qantas publicly disclosed the incident on July 2, 2025. A year later, on July 16, 2026, the Office of the Australian Information Commissioner published the report of its preliminary inquiries, and it is unusually specific about the mechanism.
Per the OAIC, on Saturday June 28, 2025, a threat actor impersonating “Qantas IT help” called an agent at an overseas contact centre run by a third-party provider. The caller directed the agent to a website associated with the CRM platform and guided them through steps framed as closing an IT support ticket. Those steps connected the agent’s CRM session to a data extraction tool operated by the attacker, which could reach the customer contact profiles the agent had access to. The vulnerability arose from a default configuration that allowed an end user to approve a third-party application connection, a default the CRM provider has since changed for all its customers.
About 5.67 million customer records were compromised, affecting approximately 5.12 million Australians. No credit card, financial, or passport details were stored in the platform, and no passwords or PINs were accessed. Staff noticed alerts generated by an unusual number of failed login attempts and escalated them on the morning of Monday June 30, and Qantas revoked the account’s access that day. The OAIC noted that Qantas ran cyclical audits of the contact-centre provider and tracked its training compliance. It concluded its preliminary inquiries without opening an investigation, saying they did not indicate a likelihood that Qantas had failed to take reasonable steps, while stressing that the report makes no concluded findings. It also noted that stronger role-based access controls would not have prevented the attack.
Attack Chain
How the Attack Compounded
Each step below marks the AXIS control that failed at that point in the chain, where one applies. Steps without a control marker were outside the victim's direct span of control.
On Saturday June 28, 2025, a caller posing as “Qantas IT help” phones an agent at an overseas contact centre run by a third-party provider.
The caller guides the agent through steps on a CRM-related website, framed as closing an IT support ticket.
A platform default lets any end user approve a third-party app connection, so the agent’s actions link the CRM session to the attacker’s extraction tool.
CLOUD-03
The connected tool extracts from the customer contact profiles the agent can reach; about 5.67 million records are compromised.
CLOUD-02
Alerts on failed login attempts begin on the Saturday; staff escalate them on Monday morning and revoke the access that day, after the data is gone.
SEC-03
Control Mapping
The IAM Controls That Failed
Every failure point below is a capability in the AXIS IAM capability model: the same 3 controls an IAM maturity assessment would have scored before this incident.
| Control | Domain | Capability | How it failed here |
|---|---|---|---|
| CLOUD-03 | Cloud | SaaS Application Discovery & Shadow IT Control | Per the regulator, the vulnerability arose from a platform default that let an end user approve a third-party application connection. SaaS governance includes deciding who may authorize new apps against customer data, and for a contact-centre seat the safe answer is nobody. |
| CLOUD-02 | Cloud | Non-Human Identity (NHI) Governance | Once approved, the attacker’s tool became a non-human identity with the agent’s data access and none of a human agent’s natural limits on speed or volume. Connected-app grants need inventory, scoping, and an alert the moment a new one appears, not discovery after the export. |
| SEC-03 | Security | User Behavioral Analytics (UBA) | A single agent session feeding millions of records to a newly connected tool is a volume anomaly that post-authentication analytics can catch while it is happening. Here the signal was alerts on failed login attempts, acted on after the weekend. |
The Maturity Lesson
What Would Have Changed the Outcome
The Domino Effect
None of the three controls here is a domino, and the OAIC’s inquiries did not indicate that Qantas had failed to take reasonable steps; the regulator noted its audits of the contact-centre provider and its tracking of training compliance. That is what makes the case instructive: every foundational control can hold while a platform default quietly grants any user the power to connect an outside app. The regulator’s note that role-based access controls would not have helped points to where the gap was. It was not in who could see the data, but in what that user could authorize on the data’s behalf.
The Maturity Level That Mattered
At level 3 on CLOUD-03, SaaS governance is risk-tiered: on high-sensitivity platforms such as a CRM holding millions of customer profiles, user consent for third-party apps is disabled and new connections route through admin approval. At level 2 or higher on CLOUD-02, every connected app is inventoried with an owner and scope, and a new one appearing on a weekend raises an alert.
The question this breach adds to SaaS and outsourcing reviews: on each platform holding customer data, who can approve a new connected app, and does anything happen when they do? The OAIC’s report shows the answer to the first can be “any agent,” even in a program whose regulatory inquiries raised no reasonable-steps concerns.
Related Compliance Frameworks
The controls implicated in this breach carry citations in these frameworks within the AXIS bank:
Put a Number on It
What Would a Breach Like This Cost You?
The breach cost calculator turns a failure pattern like the one above into a dollar figure. Set your identity count, pick your industry, give an honest read of your IAM maturity, and see the annualized loss exposure it implies.
Run the Breach Cost CalculatorSources
About This Analysis
This teardown is based exclusively on public disclosures, regulatory findings, and reporting cited above; it makes no claim of insider knowledge about the internal environment at Qantas. Control mappings express how the publicly documented failure points correspond to capabilities in the AXIS methodology, for educational purposes. AXIS is not affiliated with Qantas.
More From the Breach Radar
Would Your Program Have Caught This?
The 3 controls that failed here are questions in the AXIS assessment. Score your organization against them, and the rest of the bank, in about 20 minutes. No signup required to start.