Hashed vs cleartext: how to spot a fake breach claim in 30 seconds

The Nullsec OpSouthAfrica campaign dropped 11GB of files on a hacker forum two weeks ago and claimed they came from inside SARS. Within 48 hours, three things had happened: SARS denied the breach, two independent monitors said the data looked recycled, and a quiet pattern showed up in the dumps that almost nobody outside the security community noticed.

The passwords were in plain text.

That single detail is the most useful tell in modern breach analysis, and one your finance director or board chair can learn in 30 seconds. Once you understand how it works, you can read the next "we hacked X" headline with calibrated eyes rather than the standard South African mix of panic and shoulder shrug.

What a real login does with your password

When you type your password into a website worth its certificates, the website does not save the password. It saves a one-way fingerprint of it. The technical term is a hash, and modern systems use functions called bcrypt, Argon2, or PBKDF2 to generate them. The hash is a long string of random-looking characters that is mathematically tied to your password, but the password cannot be read out of it.

If your password is "Durban2026", the hash might look like this:

$2b$12$LqB.K7n5OqW9ZxJ4Y3wT3uM8gQ7xR2vP6sN4kFmDcEaHpJsLnVoYq

To check whether you typed the right password next time, the system runs the same hash function on what you typed and compares the result. A match means login. No match means try again. The original password is never stored in a readable form anywhere on the server.

This matters because if an attacker breaks into the database, all they get is hashes. Turning those back into passwords requires one of two slow, expensive methods: guessing every possible password and hashing each guess to compare, or using a giant lookup table of pre-computed hashes. Both methods work against weak passwords and both methods fail against any password longer than about 12 characters that is not in a dictionary.

This is why modern breaches of hashed data are often less catastrophic than the headlines suggest. The attacker has the hashes, not the passwords.

Cleartext passwords: what the data reveals

When a leaked dataset shows up containing plain-text passwords, the data did not come from a modern login database. It came from one of three places.

Infostealer malware on the user's own laptop. Software like Redline, Lumma, StealC, Vidar, and Atomic gets onto a person's computer through cracked software downloads, fake browser updates, malicious email attachments, or compromised ad networks. Once installed, the malware watches every form the user fills in. When the user logs into eFiling, Office 365, or their banking app, the malware grabs the credentials at the moment of entry, before they are hashed. It then sends everything to the operator's server. Infostealer logs are sold and traded by the million on the same forums where Nullsec posts.

Older breaches at services that stored passwords poorly. Some legacy systems stored passwords as plain text or with reversible encryption. When those systems were breached, attackers walked away with the passwords themselves. Because most people reuse passwords across services, those credentials continue to try doors today. The original breach might have been a forum from 2017.

Phishing kits. A fake login page captures the password directly when the user types it. Whoever runs the kit receives a clean cleartext dump with no server breach required.

All three sources produce data that looks identical: a list of email addresses with passwords next to them. None of those sources require breaching the company whose name appears in the email domain.

When Nullsec posted "SARS eFiling cleartext credentials", the structurally honest interpretation was: somebody else got infected, those infections collected eFiling logins from real users on their personal laptops, and the data was repackaged under a SARS label to ride a news cycle.

Why it hits harder here

South Africa runs on shared accounts and reused passwords. The 2024 SABRIC fraud report flagged credential-stuffing attacks as one of the fastest-growing fraud vectors against SA banking customers, and the pattern is identical against SME tools. Someone at the firm uses the same password for their personal Gmail, the company Xero, the supplier portal, and their banking app. When that password leaks from anywhere, the attacker tries it everywhere.

POPIA's breach notification requirements do not distinguish between credentials that came from your system and those harvested elsewhere. The Information Regulator's enforcement guidance focuses on access to personal information regardless of the original vector. If credentials harvested from a third party are used to access your customer database, that is a notifiable breach. The seven-day clock starts when you have "reasonable grounds to believe" unauthorised access occurred, not when you have forensic certainty.

The local cost is real. The Standard Bank disclosure of April 2026 originated in a third-party supplier compromise rather than in Standard Bank's own systems. The Statistics SA ransom incident exposed administrative weaknesses that had nothing to do with hashing. Every SA business that ran a breach response exercise in the past 12 months found the same recurring issue: staff using their work password on other services.

What to do

Five concrete actions, in the order they pay back.

1. Check your domain in a breach lookup. Use Have I Been Pwned domain monitoring or an equivalent commercial tool. It tells you exactly which work emails appear in publicly indexed breach dumps. If a name appears, that person's work password is probably in a stealer log somewhere.
2. Force a rotation on every account that appears in the dumps. Through your identity provider. Block the old hash. Make the new one long. Do not merely ask staff to update at next login.
3. Turn on phishing-resistant multi-factor authentication on every admin interface. SMS codes can be intercepted by SIM swap fraud, which is not rare in SA. Use TOTP authenticator apps or hardware keys for any account that touches money, customer data, or email-sending capability.
4. Block credential reuse with a password manager and a policy that enforces it. Tools like 1Password Business or Bitwarden allow you to mandate unique passwords per service. Audit compliance quarterly.
5. Train your team to read cleartext claims with calibrated scepticism. When the next viral "we hacked X" post lands in the company WhatsApp, you want your people to ask "hashed or cleartext?" before they panic. This article is shareable for that purpose.

Where Ubuntu Guard fits

We run credential exposure audits for SA SMEs. We pull data from public breach indexes, dark-web monitors, and infostealer log aggregators, then map every exposure back to the staff and supplier accounts in your business. The output is a prioritised list of which accounts to rotate first, which suppliers to ask hard questions of, and which monitoring to put in place ongoing.

The next breach claim will come this week or next. The businesses that handle it well will spend 30 seconds checking the data shape and 30 minutes acting on the parts that are real. The test starts with one question: hashed or cleartext?

© 2026 Ubuntu Guard Cybersecurity | Durban, South Africa
ubuntuguard.co.za