Pillar 1 Part 2 Case Study: Anatomy of a Data Exfiltration Attack Path: Optus, Medibank, and the…

Two real breaches, mapped against the controls that would have stopped them

Pillar 1: Information Protection, companion case study to Part 2

New to this series? The Series Overview lays out all four pillars and why they fit together.

This is a companion piece to The 10-Phase Information Protection Framework. The framework lays out what each phase does in principle. This piece is about what happens when several of those phases are missing at once, using two real, publicly documented breaches as the evidence.

Both cases are used here for one reason: they are matters of public record, established through regulatory investigation and Federal Court filings rather than insider knowledge or speculation, which makes it possible to walk the attack path with facts rather than composite guesswork. Neither is included to single out the individuals or organisations involved. The same sequence of ordinary gaps sits in plenty of programmes that simply have not been tested by an attacker yet, and the people closest to a breach when it happens are very rarely the ones who designed the gap.

Optus, 2022: What a Discovery Gap Costs

The Optus breach of September 2022 shows what a discovery gap costs. A coding error from 2018 had weakened access controls on an API endpoint. A fix was applied to the main Optus website in 2021, but that same control was never validated against an equivalent dormant test subdomain carrying the identical vulnerability, which remained exposed to the internet, unauthenticated, for years afterward. Sequential customer ID numbers meant an attacker could simply iterate through the database and pull records automatically. Around ten million current and former customers had personal information exposed, including passport and driver's licence numbers.

The root issue traces back to insufficient controls mapping and the absence of a periodic validation process to confirm that a fix applied in one place had actually been applied everywhere it needed to be, not to malice or incompetence on anyone's part. A scheduled control validation cycle, attack surface management tooling that flags new or forgotten internet-facing assets, and a documented control mapping tied to clear ownership would each have caught this independently of the others. That is a discovery and governance failure, not a sophisticated attack.

Medibank, 2022: The Full Attack Path

The Medibank breach of October 2022 is the more useful of the two for walking an attack path stage by stage, because the Federal Court filing lays out the sequence in detail.

The path began when login credentials belonging to a third-party IT contractor, including an account with admin-level access, ended up stored in a browser profile that synced across devices, a routine convenience feature working exactly as it was designed to. That profile reached a personal device that was infected with credential-stealing malware, and in early August 2022 the attacker harvested the saved credentials from it. No exploit, no zero-day. Just an everyday device-syncing feature, no policy preventing credential storage or requiring managed devices for third-party access, and a piece of commodity malware.

Storing privileged credentials in a browser is a basic control gap, not a personal failing, and it remains common practice among administrators and enterprise support staff who need fast access across multiple systems. A password manager with enforced multi-factor authentication (MFA), combined with a policy against browser-based storage of privileged credentials, would have removed this path entirely, regardless of what happened to the contractor's personal device.

From there, the path runs in five stages, and each one maps to a phase in the companion framework.

Initial access. The stolen admin credentials worked against Medibank's Exchange server and, soon after, its virtual private network (VPN), because remote access did not require MFA. This is an identity failure. MFA on that single login would have stopped the entire chain before it started, regardless of what the malware had harvested. Device compliance policy would have gone further upstream still: requiring managed, enrolled devices for third-party remote access would have prevented the personal laptop from being a viable access point in the first place, closing the path before the stolen credentials were ever attempted.

Lateral movement. The admin account had reach into network drives, management consoles, and jump box servers used to access core databases. Two identity failures compound here: least privilege would have limited what a single contractor credential could reach, and proper discovery would have flagged how much sensitive data sat reachable from one account regardless of who was logged in.

Staging and extraction. Once inside, the attacker searched for and pulled data from Medibank's claims and customer databases over several weeks. Reported volumes vary between accounts, with figures cited anywhere from roughly 200GB to over 500GB, but the order of magnitude tells the same story: a slow, sustained bulk extraction, not a smash-and-grab. Classification and DLP exist precisely for a scenario like this one. Flagged as high sensitivity, that database should have triggered DLP tuned to alert on, or block, that volume of data leaving in one direction.

Detection. Medibank's own endpoint detection and response (EDR) tooling raised alerts on the suspicious activity within days of the bulk extraction beginning. Those alerts were not properly triaged at the time. Telemetry without classification context, and without the analyst capacity to act on it, is just noise with a timestamp. The gap belongs to SecOps integration, not to the detection tooling itself.

Aftermath. The attacker demanded a ten million US dollar ransom. Medibank refused, and the data was published on the dark web in instalments. Whatever the right call on the ransom itself, an organisation that has run ransomware and data exfiltration exercises beforehand responds to that moment from a rehearsed position rather than an improvised one.

What the Pattern Actually Shows

Lay the five stages next to the framework and the pattern is obvious: four or five ordinary failures, stacked in sequence, each one making the next worse, rather than a single catastrophic one.

From an information protection standpoint, the resolution sits squarely in discovery, labelling, and DLP. Properly mapped data, classified at the point it mattered, with enforcement tuned to that classification, would have closed this off well before the extraction stage regardless of what happened earlier in the chain. Identity and detection both had a role in this incident too, and they matter; they belong to a different layer of the defence, one this piece is not the place to resolve in full.

That said, the chain itself is worth keeping intact, because it does not end with information protection. In an upcoming series on defence in depth, I will return to this same attack path and work through it from the perspective of layered defence: where identity controls, network segmentation, and detection would each have broken the chain if applied correctly, and what that tells us about how the layers are meant to back each other up rather than operate as independent checklists.

References

For Optus, the ACMA-referenced investigation is covered in iTnews's report, "Optus breach allegedly enabled by access control coding error", with a general incident overview available on Wikipedia and a technical breakdown from UpGuard.

For Medibank, the regulator's own account is laid out in the OAIC's alleged timeline (PDF), with reporting on the Federal Court filing covered by BleepingComputer and further detail from ACS Information Age.

Readers are encouraged to consult these sources directly rather than rely on any single summary, including this one.