Threat intel
Ampath breach: reading the 80 million record claim
Ampath confirmed a breach and disputes an attacker's 80 million record claim. How to read record counts, and what labs and patients should check now.
Ampath Laboratories, a South African pathology provider, has confirmed a cyber incident that it detected on 2 October 2026. A criminal calling itself ByteToBreach has claimed the attack on a cybercrime forum and says it took an admissions table of more than 80 million records. In a statement on 14 October, Ampath said that figure appears to count database entries rather than people, and that personal demographic and administrative data, including South African ID numbers and medical aid details, may have been accessed.
If you are an Ampath patient or employee, expect phishing and fraud attempts that quote your ID number. If you run IT for a lab, clinic or any business with a patient or customer portal, this incident is a clear example of a common extortion pattern: data copied from an application's databases, a large number posted online, and a company left to prove a smaller one. No encryption of Ampath systems has been reported, and its laboratories and patient services stayed fully operational.
What each side says
The attacker's account reached the press through Dark Web Informer, a threat intelligence feed that says it has not verified any of it. According to that relay, ByteToBreach claims it fully copied 10 of about 375 databases in Ampath's environment, covering HR and employee records, patient data and financial data, and that one admissions table alone holds over 80 million records. TechCentral, which reported the claim, says it has not seen the forum post itself.
Ampath's statement is narrower. It says the information involved "appears limited to certain personal demographic and related administrative information", subject to forensic verification, and that there is no evidence patient medical records, diagnoses, pathology test results or banking information were taken. It has notified the Information Regulator, South Africa's data protection authority, and brought in independent forensic specialists and legal advisers. The investigation is still running.
None of Ampath's statements mention a ransom demand, and no source has confirmed one. Anyone contacted by a person claiming to hold Ampath data should not engage, pay or follow their instructions, and should report the contact to Ampath.
ByteToBreach is a known name. The threat intelligence firm KELA first profiled the handle in November 2025, describes it as a prolific data leak operator active since at least June 2025, and assesses that it is most likely one individual based in Algeria.
Records against people
A database record is one row in one table. In a lab system, a single patient produces a registration row, then rows for account updates, test requests, payment transactions and every repeat visit over the years. Ampath gave this as the reason the 80 million figure "materially overstates" the number of people affected. It has not yet published its own count of affected individuals.
When you read any breach claim, ask three things. Which table does the number come from? Is it rows, files, gigabytes or distinct people? And has anyone other than the attacker counted? Extortion actors quote the largest number they can find because it raises pressure on the victim and attention on the forum. A company's first statement often lacks a people count because de-duplicating tens of millions of rows by ID number, and working out which fields exist for each person, takes days of forensic work.
Even so, a smaller unique count can still mean millions of people, and Ampath has not given a figure, so patients should act as if their record is in the data until told otherwise.
What a web-to-database extortion breach looks like
Ampath's published containment steps describe the shape of the intrusion even without a full report. It blocked malicious IP addresses, removed unauthorised files, disabled exposed accounts and credentials, addressed identified vulnerabilities, strengthened application and access controls, added endpoint security controls and restored affected systems from clean backups.
Read together, that list fits a common pattern: an attacker finds a weakness in an internet-facing application, drops files on the server that runs it (often a web shell, a small script that lets them run commands through the web server), uses the application's own database credentials to read tables, and copies the results out. Nothing is encrypted, so services keep working, and the first sign may be a forum post. Ampath has not named the vulnerability or the systems, so treat this as the general pattern, not a finding about its network.
A restore from a clean backup removes whatever the attacker changed on that system. It proves nothing about data that already left, and it does not help if the attacker still holds working credentials elsewhere. That is why the credential and access-control steps in Ampath's list matter as much as the restore.
What labs and healthcare organisations should check
- List every internet-facing application that touches patient or staff data: portals, results lookups, booking and payment pages, and the database account each one uses. Anything missing from that list is unlikely to be patched or monitored.
- Limit what the web tier can read. Give each application its own least-privilege database account, with no read access to HR or finance schemas it does not need. The database should not be reachable from the internet at all; only the application servers should reach it, on the database port alone.
- Alert on bulk reads. Large SELECT queries or full-table exports by the application account, new archive files (.zip, .7z, .sql) in web directories, and outbound transfers far above the server's normal volume are the signals that separate theft from normal traffic.
- Hunt before you restore. Image the affected server first, then look for new or changed script files under the web root, scheduled tasks and new local accounts. Rotate the database passwords, service account secrets and API keys that server held, since a restore puts the old ones back.
- Count people before you notify, without waiting too long. Section 22 of POPIA, South Africa's Protection of Personal Information Act, requires notice to the Information Regulator and to affected people "as soon as reasonably possible" once there are reasonable grounds to believe data was accessed. It allows time to determine scope, but only a law enforcement request can delay telling data subjects, and nothing delays telling the Regulator. The notice must describe likely consequences, what you have done, what people should do and, if known, who did it. GDPR-style regimes elsewhere set similar duties with fixed deadlines.
What patients and staff should do
Treat unexpected calls, SMS and emails that mention Ampath, a test or your medical aid with suspicion, even when the caller already knows your ID number. Do not give banking or card details to anyone who contacts you about the breach. Check your bank and medical aid statements for transactions or claims you do not recognise, and consider a free protective registration with the Southern African Fraud Prevention Service (SAFPS), which flags your ID number so lenders take extra steps before opening credit in your name.
Getting help
Our web penetration testing work tests whether an internet-facing application can be used to read data it should never reach, and our security operations team watches for the bulk reads and outbound transfers described above. If you need to prepare for a POPIA-style notification, compliance and audit readiness covers the process. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: TechCentral, ITWeb, Cape Town ETC, Bizcommunity, Diario Bitcoin, KELA on ByteToBreach, POPIA section 22.