The Vastaamo breach exposed 33,000 Finnish psychotherapy patients to direct extortion, concealed it for 18 months, two people died by suicide. The deeper failure: 40 years of ignored security lessons. 

TL;DR: The Vastaamo breach exposed 33,000 Finnish psychotherapy patients to direct extortion using "root" credentials and concealed it for 18 months—two people died by suicide. The deeper failure: 40 years of ignored security guidance from NIST, DoD, OWASP, PCI DSS, and GDPR. Every organizational layer failed—technicians, managers, executives. This wasn't sophisticated hacking. It was systematic negligence across people, process, and technology that made the breach inevitable.

Core Facts

• What happened: 33,000 psychotherapy patients had their therapy records stolen and weaponized for individual extortion demands

• Root cause determined as: "root" database credentials with no password, accessible to the entire internet—no encryption, no data anonymization.

• Cover-up duration: 18 months between breach discovery (March 2019) and public disclosure (October 2020)

• Human cost: Two confirmed suicide deaths linked to the breach; 25,000+ criminal offenses reported

• Financial penalty: €608,000 GDPR fine for intentional failure to notify authorities

This wasn't just another healthcare data breach. This was 33,000 psychotherapy patients whose most intimate secrets became extortion material because a company used "root/root" as their system credentials.

Two people died by suicide after their therapy records surfaced online.

Finland's data protection authority called the company's actions in concealing the breach for 18 months intentional. The €608,000 GDPR fine followed. More than 25,000 criminal offenses were reported to police, making this Finland's largest criminal case in history.

The numbers tell a story that extends far beyond one company's catastrophic security failure.

What Was the Technical Weakness That Led to the Breach?

The breach was not the result of a sophisticated zero-day exploit or advanced malware. Instead, it was caused by negligent database management:

Open Internet Exposure: Vastaamo's MySQL database was connected directly to the public internet without a firewall to restrict access.

No Root Password: The "root" (administrator) account for the database had no password set. This allowed anyone who found the server to log in with full administrative privileges.

Unencrypted Data: The sensitive therapy notes, social security numbers, and personal details were stored in plain text. They were not encrypted or anonymized, making them immediately readable once accessed.

Insecure Remote Access: IT administrators intentionally enabled remote access to the database to troubleshoot issues from home, effectively leaving the "front door" unlocked.

Key Lesson: Scanning tools can probe every IP address (3.7 billion IPv4) on the internet in under 10 minutes. There is a lesson here for everyone—think about how long you wait between scans of all your publicly routable IP addresses to identify mistakes and/or abuses, and adjust your frequency accordingly.

What Guidance Was Available to Prevent This?

History does not look favorably on those involved with the compromised systems—from low-level technicians to support staff, designers, developers, management oversight, testers, and risk managers. No one caught it.

40 Years of Ignored Database Security Guidance:

The "Decades of Defense" Timeline

1977 NIST SP 500-9 First guidelines on using passwords for controlled access to computer resources.

1985 The "Orange Book" (DoD) Mandated that "default accounts" be removed or changed before systems go live.

1995 MySQL Initial Release The creators immediately documented the need to secure the root user during setup.

2003 OWASP Top 10 (v1) "Security Misconfiguration" (including default passwords) debuted as a top critical risk.

2004 PCI DSS v1.0 Requirement 2.1: "Always change vendor-supplied defaults... before installing a system on the network.”

2005 NIST SP 800-53 Released the first comprehensive catalog of security controls for federal and commercial databases.

2010 CIS Benchmarks for MySQL The Center for Internet Security released specific "hardening" checklists for MySQL.

2015 MySQL 5.7 Auto-Generation MySQL began automatically generating random passwords for root to force security by default.

2016 GDPR Adopted Mandated "Data Protection by Design and Default" for all EU entities.

2018 The Vastaamo Breach Begins: A 40-year-old lesson was ignored.

The list of human failures is undeniable whether staff were experienced old hands or young recruits. Its not rocket science to ‘have a password’ or the ‘change the default password’.

Key Intelligence: Vastaamo ignored 40 years of database security guidance spanning NIST, DoD, OWASP, PCI DSS, and GDPR—every fundamental security measure established between 1977 and 2018 failed simultaneously. 

Key Takeaways

• Basic credentials defeated enterprise security: "root" credentials and unencrypted data—fundamental security hygiene matters more than advanced tools and staff personal convenience.

• Only takes 10 minutes to find vulnerability: Once the change was implemented to expose the database, it can take as little as 6 to 10 minutes to find such weaknesses using free scanners and no skill.

• Vulnerabilities are not just technical: Weaknesses in people, process, and technology can lead to a data breach. All of these were at the heart of this data breach. The problem occured long before someone misconfigured the database.

• The simplest guidance for decades ignored: The lack of awareness of advice, guidance, good practice, and the inability to understand why they are important is the real threat. Everyone at all levels is responsible. Executives and governance should be insisting on it, technicians should be confirmed to know it, and managers should be reporting on configuration compliance for their crown jewels and whether they remain protected.

• You can't protect what you don't understand: Those with a security responsibility need to demonstrate they understand databases if they are to advise on securing them, checking they are secure, and understanding that the people, process, and technologies are appropriate to keep the data secure. Otherwise, who are they to advise anyone? Everybody can google the same info.

Author: Hackerstorm.com