The practice manager called on a Tuesday morning. It was not quite 7am. Every computer in the practice was locked. The server was locked. The backup drive connected to the server was locked. A text file on every desktop read: "Your files have been encrypted. Pay 0.8 BTC within 72 hours or they will be permanently deleted."
0.8 Bitcoin at the time was approximately R180,000.
The practice had cyber insurance. Their insurer told them to pay. So they paid. Three things then happened that nobody told them to expect.
This is a real case. The practice name, location specifics, and identifying details have been changed. The sequence of events is accurate. We were involved in the post-incident investigation.
What the attack looked like
The attack started weeks before that Tuesday morning. It started with a phishing email that a billing administrator received on a Friday afternoon. The email appeared to come from their practice management software provider. It asked the administrator to log in to confirm updated banking details. She logged in on what turned out to be a cloned page. Her credentials were captured.
The attacker used those credentials to access the practice's remote desktop connection over the following weekend. With access to the server, they spent several days moving through the network, identifying data, and preparing the encryption payload. The encryption ran on Tuesday morning at 3am, while no one was in the building.
By the time staff arrived at 7am, every patient record, every billing file, every accounting document, and every medical image stored locally was encrypted. The ransom note was waiting on every screen.
The decision to pay
The practice had a cyber insurance policy they had taken out 18 months earlier. The policy explicitly covered ransomware events. The insurer deployed a response team within 24 hours.
The insurer's team assessed the situation. The practice had no usable backups. The external hard drive connected to the server was encrypted along with everything else. The cloud backup service the practice had subscribed to had not been configured correctly, and it had not actually been backing up patient records for the past four months. No one had tested it.
Without backups, the insurer determined that paying was the least costly path to recovery. They negotiated the demand down slightly. The Bitcoin was purchased and transferred. The attacker provided a decryption key.
The three things that nobody told them to expect
First: the decryption was incomplete. The attacker's decryption tool did not recover all files. Approximately 15% of encrypted files could not be decrypted, including several months of patient records. Some of the undecryptable files were corrupted beyond recovery. The practice could not explain gaps in patient histories to affected patients or their medical aids without disclosing the breach.
Second: the data had already been exfiltrated. Approximately six weeks after the payment, data from the practice appeared on a dark web forum. Patient names, ID numbers, and medical aid details. The attacker had exfiltrated a copy before encrypting. Paying the ransom had bought the decryption key. It had not bought back the data.
The practice was now obligated under POPIA Section 22 to notify the Information Regulator and all affected patients. The notification process cost more in time, legal fees, and reputational damage than the original ransom.
Third: the attacker came back. Six weeks after the initial incident, the practice received a new ransom demand. The same or an affiliated group had retained a persistent access point that was not identified or removed during the initial recovery. The attackers threatened to release additional data if a second payment was not made.
The second demand was refused. We conducted a full forensic investigation, identified and removed the persistent access, and assisted with the breach notification. But the practice spent the second half of 2025 managing POPIA notifications, patient queries, medical aid investigations, and an Information Regulator inquiry.
What Ubuntu Guard did during the post-incident investigation
We were brought in after the second demand. Our work covered four areas.
Forensic analysis to identify how the initial access occurred, what data was accessed and exfiltrated, whether the persistent access had been fully removed, and whether any other systems in the practice had been compromised that were not initially identified.
Remediation, including removal of the persistent access mechanism, credential resets across all systems, implementation of multi-factor authentication on all remote access points, and reconfiguration of the backup system.
Breach notification support, including working with the practice's attorneys to draft compliant notifications for the Information Regulator and all affected patients.
Hardening recommendations, covering the specific vulnerabilities that enabled the initial attack: the phishing susceptibility, the unprotected RDP, the inadequately configured backup.
What the practice changed after recovery
They now have multi-factor authentication on every login that accesses the practice from outside the local network. They run monthly phishing simulation tests for all staff. They have a properly configured 3-2-1 backup with an immutable offsite copy that is tested quarterly. They have an incident response plan in writing, with assigned responsibilities and contact numbers, that every manager has read.
None of those changes are expensive. All of them would have prevented the original attack.
Why paying a ransom is almost never the right call
The promise of a decryption key is not a guarantee of full recovery. The payment does not prevent data from being published. It does not remove the attacker from your network. It funds the next attack and the one after that.
Paying also does not remove your POPIA breach notification obligations. If patient data was accessed by an unauthorised party, you are required to notify regardless of whether you paid a ransom. The payment does not make the breach go away legally.
The right call, if you are in a ransomware incident, is to call a cybersecurity incident response team before you engage with the attacker. Preserve your evidence. Isolate the affected systems. Assess whether you have usable backups. Understand what you are dealing with before you make any payment decision.
If you are hit right now, contact our incident response team immediately at /services/incident-response/.
If you want to know whether your practice is prepared for a ransomware event, a cybersecurity assessment will tell you. Book it at /services/cybersecurity-assessment/.
For context on the current ransomware threat to South African healthcare, see our healthcare cyber threats article. For guidance on building a proper backup strategy, see the backup guide.
Reach us at [email protected].
Sources: - INTERPOL: INTERPOL Africa Cyberthreat Assessment Report 2025 (Published: May 2025) - Information Regulator South Africa: POPIA Section 22 Breach Notification Requirements (Published: 2024-2026) - South African Government: Protection of Personal Information Act 4 of 2013 (Published: 2013)
© 2026 Ubuntu Guard Cybersecurity | Durban, South Africa ubuntuguard.co.za