CyphrQ

Medibank Data Breach 2022: What Happened and the OAIC's Court Case

How the 2022 Medibank data breach happened, who was affected, what the OAIC alleges in its Federal Court case, and what security teams should check.

What was the Medibank data breach? In October 2022, a criminal got into the network of Medibank, an Australian health insurer, and accessed personal data on about 9.7 million current and former customers, including health claims data for some of them. Australia's privacy regulator, the OAIC, then sued Medibank in the Federal Court. As of 25 October 2026, that case has not been decided.

This is a case file. It sets out what the official sources say and what is still only alleged. It ends with what to check in your own organisation.

Case file

Field Value
Organisation Medibank Private Limited (brands: Medibank, ahm)
Region Australia
Breach date October 2022. Medibank says no further suspicious activity was detected after 12 October 2022 (Medibank)
Disclosed ASX release the day after Medibank "detected unusual activity on its network" (Medibank)
People affected About 9.7 million current and former customers and some authorised representatives (Medibank)
Data types Names, dates of birth, addresses, phone numbers, email addresses; Medicare numbers (ahm); passport numbers and visa details (international students); health claims data for some customers. No credit card or banking details (Medibank)
Penalty/action OAIC civil penalty proceedings, filed 5 June 2024. Maximum A$2,220,000 per contravention of section 13G (OAIC)
Regulator Office of the Australian Information Commissioner (OAIC)
Status Pending. No penalty ordered; the OAIC says penalty and amount "are matters before the court" (OAIC)

When did the Medibank data breach happen, and what happened?

Medibank's first ASX release said: "Yesterday the Medibank Group detected unusual activity on its network." At that point it said there was "no evidence that any sensitive data, including customer data, has been accessed" (Medibank).

That changed over the following weeks. In its November 2022 update, Medibank confirmed the scale of what had been accessed. It also said: "No further suspicious activity inside our systems has been detected since 12 October 2022" (Medibank).

Medibank refused to pay. Its words: "Medibank will not pay any ransom demand for this data theft" (Medibank).

The OAIC later said the personal information the attackers accessed "was subsequently released on the dark web" (OAIC).

How many Medibank customers' records were taken, and what was in them?

Medibank's November 2022 update gives the breakdown (Medibank):

Group People (Medibank's figures) Data accessed
Medibank customers about 5.1 million Name, date of birth, address, phone, email
ahm customers about 2.8 million As above, plus Medicare numbers (no expiry dates)
International customers about 1.8 million As above, plus passport numbers and visa details for international students (no expiry dates)
Total about 9.7 million Current and former customers and some authorised representatives

Health claims data, the most sensitive part, was accessed for a smaller group within each brand:

  • around 160,000 Medibank customers
  • around 300,000 ahm customers
  • around 20,000 international customers
  • around 5,200 My Home Hospital patients, plus contact details for around 2,900 of their next of kin

Medibank said the attacker "did not access credit card and banking details" (Medibank).

The OAIC uses the same headline figure. Its case alleges Medibank "seriously interfered with the privacy of 9.7 million Australians" (OAIC).

How did the attackers reach Medibank's systems?

The official account of the intrusion is the OAIC's concise statement, the document that sets out the regulator's case in court (OAIC concise statement, PDF). These are allegations. A court has not tested them, and Medibank is defending the case.

In outline, the OAIC alleges:

  1. A contractor's saved login. An employee of a third-party IT provider working for Medibank saved Medibank credentials in a personal browser profile on a work computer. The browser synced those credentials to the employee's personal device.
  2. Stolen by malware. A threat actor stole the credentials from that personal device using malware.
  3. A VPN without MFA. The attacker used the credentials to log in to Medibank's Global Protect VPN. The OAIC alleges that access to that VPN did not require multi-factor authentication (MFA). MFA means proving who you are in two or more ways, such as a password plus a code from your phone.

The lesson is simple. A password saved on a device nobody in security controls became the key to a health insurer's network.

On 5 June 2024, the Australian Information Commissioner filed civil penalty proceedings against Medibank in the Federal Court (OAIC).

What the OAIC alleges. From March 2021 to October 2022, Medibank failed "to take reasonable steps to protect their personal information from misuse and unauthorised access or disclosure". That is alleged to be a breach of Australian Privacy Principle (APP) 11.1, and a serious interference with privacy "in contravention of section 13G of the Privacy Act" (OAIC).

The OAIC points to what made reasonable steps more demanding here: Medibank's "size, resources" and "the nature and volume of the sensitive and personal information it handled".

The maximum penalty. In the OAIC's words, "the Federal Court can impose a civil penalty of up to $2,220,000 for each contravention of section 13G" for conduct in that period (OAIC). This post does not multiply that by the number of people affected. How many contraventions the court finds, and what penalty, if any, it sets, is for the court.

Medibank's response. Medibank told the ASX that "Medibank intends to defend the proceedings" (Medibank).

What is decided and what is still pending?

Question Status as of 25 October 2026
Did the breach happen, and how many people were affected? Stated by Medibank: about 9.7 million
Did Medibank breach APP 11.1 and section 13G? Pending. Alleged by the OAIC, not decided by the court
Will there be a penalty, and how much? Pending. "Matters before the court" (OAIC)
Judgment or settlement? None published on the OAIC's case page, and none found on the OAIC or Federal Court sites

Did the Australian government sanction the attacker?

Yes. On 23 January 2024, the Australian government imposed a targeted financial sanction and a travel ban on Russian national Aleksandr Ermakov, whom it linked to the compromise of Medibank's network. It was the first use of Australia's autonomous cyber sanctions framework (Minister for Foreign Affairs).

Going deeper: for security and IT teams

Threat model. A financially motivated actor wants bulk personal and health data to extort the holder, and to publish it if the holder won't pay. What it needs is not an exploit. It needs one working remote-access credential and an entry point that accepts it alone. What it gets, per Medibank's own figures, is identity data on about 9.7 million people and health claims data on hundreds of thousands.

The alleged attack chain, mapped to MITRE ATT&CK. The OAIC's allegations mapped to ATT&CK techniques, each linked to its page at attack.mitre.org:

Stage (as alleged by the OAIC) ATT&CK technique Tactic
Credentials saved in a browser profile, synced to a personal device, taken by malware T1555.003 Credentials from Web Browsers Credential Access (TA0006)
Logging in with a genuine username and password T1078 Valid Accounts Initial Access, Persistence, Privilege Escalation, Stealth
Entry through the corporate VPN T1133 External Remote Services Initial Access (TA0001), Persistence (TA0003)

Later stages (discovery, collection, exfiltration) are deliberately not mapped to technique IDs. Those parts of the concise statement were not checked closely enough to tie them to specific techniques.

Control failures alleged. Two failures stand out in the OAIC's case:

  • Remote access with a single factor. The OAIC alleges the Global Protect VPN did not require MFA during the relevant period (concise statement). MITRE's mitigation for T1133 is direct: M1032 Multi-factor Authentication, "use strong multi-factor authentication for remote service accounts."
  • Privileged credentials outside managed storage. A contractor's Medibank login lived in a personal browser profile and synced to a personal device. For T1555.003, MITRE's M1027 Password Policies says organisations "may consider weighing the risk of storing credentials in web browsers."

The concise statement also deals with how Medibank's monitoring responded. Its exact wording on alerting was not verified for this post, so no claim is made about it here.

Controls to put in place, with the identifiers.

  • MFA on every remote entry point (VPN, VDI, remote desktop gateways, admin portals), not just email. MITRE T1078 lists M1032 "across all account types". Prefer phishing-resistant methods for privileged and IT-support accounts.
  • Device posture as a second gate. MITRE M1036 Account Use Policies recommends "conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges."
  • Block browser sync of work credentials. Use your browser management policies to stop work profiles syncing to personal accounts. Put privileged credentials in a managed vault, not the browser.
  • Narrow what the VPN reaches. MITRE M1030 Network Segmentation for T1133: deny direct remote access to internal systems. A VPN session should not mean flat access to customer databases.
  • Contractor accounts as a separate risk class. Third-party IT staff often hold broad rights. Give them named, time-boxed accounts and review them on a schedule (MITRE M1018 User Account Management).

Detection signals. MITRE's detection strategy for T1133 (DET0354, analytic AN1004) describes the chain to alert on: unusual external remote access such as VPN, failed logins followed by a successful session from an uncommon location or outside business hours, then internal lateral movement or exfiltration (MITRE). In practice, alert on:

  • a VPN login for an IT or admin account from a new device, a new country or an unusual hour
  • the same account active from two locations at once
  • a VPN session followed by large outbound transfers or access to database servers that account rarely touches
  • infostealer detections on any endpoint, then a review of every credential that endpoint held

What to verify or ask.

  • Can anyone reach our VPN with a username and password alone, or only a device certificate? Test it, don't just read the policy.
  • Which contractors hold privileged access, and do their devices meet our standards?
  • Would a VPN login from a new device at 3am page someone, and who triages it within the hour?
  • If an endpoint gets an infostealer alert, does our playbook include resetting every credential it held?

What does Medibank mean for your plans this quarter?

  1. List every way into your network from outside: VPN, remote desktop, VDI, vendor portals.
  2. Confirm each one enforces MFA for every account, including contractors and service desk staff.
  3. Stop work credentials syncing to personal browser profiles, and move admin passwords into a managed vault.
  4. Make sure a VPN login from an unfamiliar device or location raises an alert that a person reviews.
  5. Map where your most sensitive data sits, and check that a normal VPN session can't reach it directly.

Key takeaways

  • The Medibank data breach exposed personal data on about 9.7 million current and former customers, including health claims data for about 480,000 across its three customer groups, per Medibank's own figures.
  • The OAIC alleges the entry point was a contractor's stolen credentials used on a VPN that didn't require MFA. Those are allegations, not court findings.
  • The OAIC filed civil penalty proceedings on 5 June 2024. The maximum penalty is A$2,220,000 per contravention of section 13G of the Privacy Act.
  • As of 25 October 2026, no judgment or settlement has been published. Whether Medibank breached the Act, and any penalty, is still for the Federal Court to decide.
  • Australia sanctioned a Russian national, Aleksandr Ermakov, over the attack in January 2024.
  • The cheapest lessons: MFA on every remote entry point, no work credentials in personal browsers, and alerts that someone actually reads.

Sources