Home > API Security Blog & Expert Insights > Learnings from the Optus Breach

Learnings from the Optus Breach

Apurva Prakash

Marketing Manager @ AppSentinels

June 20, 2024
• ⏱︎7mins Read

An Optus Store displayed an apology after the breach was disclosed

Courtesy — https://twitter.com/Jeremy_Kirk

Disclaimer: AppSentinels doesn’t have first-hand information about the cause of the Optus breach. This blog is based on information collected from various sources on the Internet. References are available at the end of the blog.

Chronology of events

Before we delve into the reasons behind the Optus breach, let’s see the chronology of events. Data breach updates are being followed up https://twitter.com/hashtag/OptusDataBreach and https://twitter.com/Jeremy_Kirk

22nd Sept 2022: Optus, one of Australia’s biggest telecom companies, suffered a breach resulting in the leak of sensitive information of 10M customers (https://www.bbc.com/news/world-australia-63056838).
26th Sept 2022: It was established that the equivalent of 100 points of identification had been extracted for 2.8 million Optus customers – a substantial subset of the total. (https://www.computerweekly.com/news/252525513/Optus-breach-casts-spotlight-on-cyber-resilience)
28th Sept 2022: The hacker released 10K of records in the dark web and demanded $1 million ransomware from Optus. Some customers whose data was released received a 2,000 Australian dollar ransom demand (https://www.insurancejournal.com/news/international/2022/09/28/687107.htm)
30th Sept 2022: Australian Government confirmed that Optus will foot the bill for replacement of passports, licenses, SIM’s and any other ID proof to be reissued to affected customers. (https://www.sbs.com.au/news/article/optus-to-pay-for-new-passports-taskforce-set-up-to-help-affected-customers/38bpharfm)

Cause of the breach

According to various reports, Optus customer data was accessed via an API interface that was not secure. (https://www.computerweekly.com/news/252525513/Optus-breach-casts-spotlight-on-cyber-resilience). Apart from unauthenticated API, there was another serious issue related to easily enumerated ID’s (identifiers). These are foundational controls that were found lacking in the API implementation.

a) An un-authenticated API exposing PII data — An unauthenticated API endpoint exposed via one of the subdomains of the telco was exposing PII data of the customers. This is like gate wild open with a message ‘valuables inside’. Any user on the internet can invoke the API and retrieve data by providing basic information like a parameter. Eg: to get details about a customer with mobile number 1234567890.

This attack is called BUA (Broken User Authentication and is number two in OWASP API Top-10 list).

b) The was another API had another parameter enumeration issue. For eg: parameter UserID were numbered 1, 2, 3,…. The API can be invoked by incrementing the identifier parameter and retrieve details about the User. There were NO checks in the API endpoint to ensure only authorized user is allowed access to his/her data.

This attack is called BOLA (Broken Object Level Authorization and is number one in OWASP API Top-10 list).

What is needed to prevent such breaches

Having an inventory of the APIs: You can’t protect what you can’t see. What is needed here is a platform that should discover all the API’s along with other characteristics about the API like authenticated, internal or public, dealing with sensitive info etc. If Optus had such an inventory, they could have discovered earlier that there exist weak APIs with access to sensitive data. OWASP API Top#9 [Asset Management]
Authentication of APIs: Leaving an API open to world for anyone to invoke can be catastrophic as Optus discovered the hard way. While every application needs API open to world, such APIs should be carefully validated by the organization. A platform that can provide insight to the customer about such a risk would have helped Optus understand their risk exposure. OWASP API Top#2 [Broken User Authentication]
Unauthorized Usage: A platform that can learn how the APIs are invoked and understand the application baseline as well as the user-context would have detected an easy target like allowing a user to change the identifiers and access information about the customers he/she isn’t authorized to use.

Conclusion

APIs are critical part of your software. Weak APIs can result into massive data breaches like what Optus saw, apart from huge brand and financial losses. Protecting APIs is critical for organizations of all sizes. Look for an API Security solution that provides protection against the gaps described in the paper.

Frequently Asked Questions

What was the precise sequence of events in the Optus breach, and what does the timeline reveal about detection failures?+–

The breach became public on September 22, 2022, when Optus disclosed sensitive information of 10 million customers was compromised. Shortly after, it was confirmed that data equivalent to 100 points of identification had been exposed and the most sensitive category of Australian identity documentation. The timeline’s critical revelation is that Optus didn’t detect the breach internally rather the company learned of it externally. This detection failure, where an attacker exfiltrated millions of records without triggering any internal alert, demonstrates how inadequate API monitoring combined with enumerable IDs and missing authentication creates a breach that’s effectively invisible until the attacker announces it.

Why is “100 points of identification” the specific Australian regulatory threshold that made this breach uniquely catastrophic?+–

Australia’s identity verification system requires “100 points of ID” for financial, legal, and government transactions, a combination of documents adding up to 100 points, with passports worth 70 points and driver’s licenses worth 40 points. The Optus breach exposed exactly these high-value identity documents for millions of people and giving attackers sufficient verified identity information to impersonate victims in high-stakes transactions. This wasn’t just a PII breach; it was a breach of the identity verification infrastructure underlying the entire Australian financial and legal system, which is why emergency government legislation was required to enable fast-tracked document replacement.

What systemic API security failures does the Optus breach reveal beyond the specific unauthenticated endpoint?+–

Beyond the unauthenticated endpoint, the Optus breach reveals: no continuous API discovery process (the vulnerable endpoint was unknown to the security team), no anomaly detection capable of flagging sequential enumeration patterns in API traffic, no data minimization enforcement preventing the API from returning full identity documents, no incident response triggers activated by the exfiltration activity, and no regular security testing of the full API surface that would have found the endpoint. It’s a systemic failure across the entire API security lifecycle and not a single control failure. Any one of these controls, properly implemented, would have either prevented or significantly limited the breach’s impact.

What regulatory and legal consequences followed the Optus breach, and what do they signal about API security liability?+–

Following the breach, the OAIC launched civil penalty proceedings for serious and repeated privacy violations, ACMA investigated communications regulatory compliance, multiple class actions were filed by firms including Slater & Gordon and Maurice Blackburn representing millions of affected customers, and Optus allocated AUD 140 million for breach-related costs. Potential fines could reach hundreds of millions of dollars. Collectively, these consequences signal that API security failures are not just technical incidents, but they’re regulatory liability events with consequences that dwarf the cost of preventive security investment. The CEO’s resignation underscores that API security failures can have career-level consequences for leadership, not just technical teams.

How does the Optus breach compare to other landmark API security incidents as a case study?+–

The Optus breach stands as a landmark case study because of its convergence of factors that individually appear in many API breaches but rarely all together: scale (10 million people, representing 40% of Australia’s population), sensitivity (government identity documents enabling identity fraud), simplicity of attack (no sophisticated techniques required), severity of consequences (national emergency legislation, CEO resignation, AUD 140 million in costs), and the public debunking of the “sophisticated attack” narrative. This combination makes Optus uniquely instructive as it demonstrates that devastating API breaches don’t require sophisticated attackers, and that organizations cannot spin their way out of accountability for basic security failures.

What should other large organizations with similar API architectures take away from the Optus breach analysis?+–

Large organizations with complex API portfolios should take away: API discovery must be automated and continuous and manual inventories are insufficient for fast-moving environments; every external-facing API must be verified for authentication as a routine security hygiene check; monitoring for sequential enumeration patterns is table stakes for any API exposing record-based data; data minimization must be enforced architecturally, not left as a developer implementation decision; and incident response plans must include API-specific scenarios with pre-drafted customer and regulatory communications. Most critically, Optus demonstrates that the cost of a breach dwarfs preventive investment and the calculus for API security spending has been permanently reset by this case.