A public breach claim is now an attack technique in its own right, and it should be treated as a trigger for disciplined verification rather than either panic or dismissal. On Sunday, 26 July 2026, a threat actor posted on a hacker forum claiming to have breached MTN and exfiltrated customer and employee credentials. Within a day, analysis reported by Daily Maverick found that the “customer” data consisted largely of registration details for MTN developer portals, and that the employee records were likely historical, duplicate or test data, probably recycled from an earlier breach. MTN said the material “does not point to any new compromise of MTN’s systems”.
The claim was framed as part of #OpSouthAfrica, a hacktivist campaign that Daily Maverick reports began in early May 2026 and has previously targeted Sita, Sassa, the Civil Aviation Authority, the National Space Agency and the Department of Correctional Services. Most regulated mid-market firms will never be the subject of such a post. Some will, and the way MTN handled it is a useful template.
Why do attackers publish claims that turn out to be exaggerated?
Hacktivism is cyber activity carried out for political or ideological reasons rather than direct financial gain. Its currency is attention. A forum post naming a well-known organisation generates headlines whether or not the data is new, and the target pays a cost in staff time, customer anxiety and media handling either way.
The same logic applies to criminal extortion groups. Recycled breach data, information stolen in an earlier incident and repackaged as new, costs the attacker nothing. Old credential lists, scraped public data and records from a supplier’s past breach can all be presented as a fresh compromise. The aim is to provoke a payment, a panicked public statement, or simply disruption.
That does not make every claim false. Some are the first public sign of a genuine breach. The point is that neither the claim nor the instinct to deny it is evidence.
How should a claim be verified?
Verification is a structured, time-boxed process. In the first 24 to 48 hours, a competent incident response team will typically work through five questions:
- What exactly is being offered? Obtain the sample or listing through safe channels, without paying or engaging the actor, and catalogue what it contains.
- Is it ours? Match fields, formats and identifiers against your own systems. Developer portals, marketing platforms and test environments often hold data that looks like customer data but is not.
- Is it new? Compare against known historical incidents, including suppliers’ breaches and public credential dumps. Timestamps, account statuses and password formats often date a dataset.
- Is there corroborating evidence internally? Review logs, alerts and access records for the systems the data would have come from. An absence of evidence is only meaningful if logging was in place.
- Does anything need to happen now regardless? If credentials appear, even old ones, reset them, check for reuse and confirm multi-factor authentication is enforced.
Each step should be documented as it happens. The record of what was checked, when and by whom is what you will rely on if the Regulator, a client or an insurer later asks why you did or did not notify.
When does a claim become a POPIA notification?
Section 22 of POPIA requires notification to the Information Regulator and, in most cases, to data subjects where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person. Notification must be made as soon as reasonably possible after discovery.
A forum post alone is a reason to assess urgently. If verification confirms new personal information was taken, or cannot rule it out within a reasonable time, the threshold is likely met. If verification shows the data is recycled from a breach that was already notified, or is not personal information at all, a documented decision not to notify is defensible. As we noted in our analysis of the June enforcement notices, the Regulator treats failure to notify as a contravention in its own right, so the decision must be reasoned and recorded.
What does this reveal about data you no longer need?
The MTN analysis pointed to developer-portal registrations and historical or test records. Every organisation accumulates data like this: old accounts, test copies of production databases, exports left on file shares, registrations for services no longer in use.
Section 14 of POPIA requires that records of personal information are not retained longer than necessary for the purpose for which they were collected, subject to specific exceptions. Data that should have been deleted can still be stolen, still be leaked and still generate a notification. Reducing what you hold is one of the few controls that shrinks every future incident.
What to do this quarter
- Write a claim-verification playbook covering who assesses a public breach claim, the five verification questions and the decision record.
- Agree a holding statement in advance: short, factual, confirming awareness and investigation, and avoiding premature denial.
- Monitor for your organisation’s name and domains on paste sites and criminal forums through a reputable threat-intelligence service, so you hear about claims early.
- Find and remove stale data. Test databases holding real personal information, old exports and dormant accounts are the usual sources of “recycled” leaks.
- Enforce multi-factor authentication on every account, including developer, partner and test portals.
- Confirm logging coverage on the systems that hold personal information, so you can prove what did not happen as well as what did.
- Run a tabletop exercise starting from a forum post rather than a ransomware screen.
Frequently asked questions
Does a hacker’s claim of a breach trigger POPIA section 22 notification?
Not automatically. A claim is a reason to assess urgently. If verification confirms or cannot rule out unauthorised access to personal information, notify as soon as reasonably possible, and record the reasoning either way.
What is recycled breach data?
It is information from an earlier incident, often years old, repackaged and presented as a new breach. It is common in hacktivist and extortion campaigns because it costs the attacker nothing.
What is hacktivism?
Cyber activity carried out for political or ideological reasons rather than direct financial gain, typically through defacement, denial-of-service attacks, data leaks and public claims designed to embarrass the target.
Should we respond publicly to a breach claim?
Usually with a short holding statement confirming you are aware and investigating. Avoid confirming or denying details you have not yet verified.
How Rhentech can help
Our incident response service includes claim verification, evidence handling and section 22 assessment, and our managed IT and cybersecurity service provides the monitoring and logging that make verification possible in hours rather than weeks.
If you would like to test how your organisation would handle a public breach claim, book a free initial consultation. The consultation costs nothing; response planning and managed services are paid engagements scoped to your organisation.
Sources
- Daily Maverick, “Claims of an MTN hack have been greatly exaggerated, but the hacktivists won’t stop”, 27 July 2026.
- Protection of Personal Information Act 4 of 2013, sections 14, 19 and 22.
This article is for informational purposes. It does not constitute legal advice. Consult qualified legal counsel for compliance matters specific to your organisation.
Reviewed 20 October 2026.