12,000 Passwords. All the Same One.

FulcrumSec claims 4.8TB from Global Schools Group.

Last week, FulcrumSec posted a 111GB highlights package from a larger 4.8TB exfiltration of Global Schools Group, the Singapore-based operator behind Global Indian International School and several other education brands across Asia. The group claims the data includes student passports, parent communications, employee records, applicant documents, transportation logs, and source code.

The breach, detailed in a post on BreachNews, allegedly began in April 2026 after FulcrumSec obtained access to GSG's AWS environment. The group says it found dozens of S3 buckets, multiple SQL Server and MongoDB instances, and AWS Secrets Manager entries — many wide open.

The numbers: 4.8TB total. 12,303 user accounts — all in plaintext. Nearly every account used the same password. 107,000+ transport user records. 183,000 trip records with GPS data. 221 million attendance records. 23,000 visitor photographs from school campuses. 47,000 job applicant folders with passport scans, visa documents, and medical certificates.

Three failure modes stacked on top of each other.

Every headline in this story is from a class you already know. The compounding is what makes it worth studying.

Failure one: credential hygiene. 12,000 plaintext passwords, all identical. This is not a sophisticated bypass. This is the digital equivalent of one key that opens every locker in the school. Whoever gained access to that database had credentials for every user, every system, every role that shared that password. The blast radius was the entire directory.

Failure two: cloud storage configuration. The S3 buckets had no public access block. In AWS, Block Public Access is a single account-level setting that prevents any bucket from being made publicly readable, regardless of its individual policy. It costs nothing. It takes 30 seconds to enable. The entire 4.8TB exposure would have been impossible with that one toggle turned on.

Failure three: incomplete incident recovery. FulcrumSec claims the MongoDB databases contained remnants of a 2022 ransomware infection — database names referencing ransom notes, credentials that had not been changed since the incident. This is the pattern that matters most. GSG got hit, restored from backup, and declared the incident over. They did not audit what changed. They did not rotate credentials. They did not investigate how the attacker got in before the encryption kicked in. They cleaned the visible mess and left the root cause untouched.

The 2022 ransomware was not the worst part. Not rotating after it was.

Getting hit by ransomware in 2022 is unfortunate. Not rotating credentials, not auditing access, and not closing the initial entry vector after the restore is a choice.

Three years later, credentials that were compromised in the first incident were still active. The same infrastructure that let the ransomware in was still configured the same way. The only difference was that the second attacker (FulcrumSec) chose exfiltration over encryption. The door was never locked. Different actor, same open door.

This is the most common post-incident failure we see. The visible damage gets cleaned up — files restored, systems rebuilt — and everyone moves on. The root cause investigation gets deprioritized because the immediate crisis is over. The next attacker walks through the same door the first one used.

The blocks repeat. The fixes are repetitive for a reason.

Block Public Access on every S3 bucket. AWS Organizations has a service control policy that enforces this at the account level. One policy, applied once, makes it impossible to create or modify a bucket that allows public access. If GSG had this, the 4.8TB dump would have been a failed curl command instead of a headline.

Password manager with unique credentials per user. GSG had 12,000 accounts. Even if every password was strong, one reused password means one breach compromises every account that shares it. A password manager generates unique credentials per service and stores them behind a single master credential. That is the entire fix for password reuse.

Post-incident credential rotation and access audit. After any breach — ransomware, phishing, whatever — rotate every credential the affected systems could have seen. Not just the ones that were definitely compromised. Every API key, every database password, every service account token. Then audit who has access and whether they still need it. The window between incident and rotation is when the second attack happens.

Audit our cloud infrastructure for the Global Schools failure modes.

1. Check S3 bucket public access settings.
   Run `aws s3api list-buckets` then for each:
   `aws s3api get-public-access-block --bucket <name>`.
   Flag any bucket without BlockPublicAcls, BlockPublicPolicy,
   IgnorePublicAcls, or RestrictPublicBuckets set to true.

2. Check AWS Organizations SCP for s3:BlockPublicAccess.
   If no SCP enforces it, propose one.

3. Inventory our secrets manager entries. List every secret,
   when it was last rotated, and which services use it.
   Flag any secret not rotated in the last 90 days.

4. Check credential uniqueness across user database.
   Run a hash comparison on password fields (without reading values).
   Flag any reuse rate above 0%.

5. Review incident response playbook. Confirm it includes
   a mandatory credential rotation step as part of the
   recovery checklist, not as an optional post-mortem action.

The move.

Turn on S3 Block Public Access at the AWS Organizations level. It takes one CLI command and prevents every bucket in every account from being publicly readable. If GSG had done this, FulcrumSec's post would have been about the buckets they could not open.

Rotate credentials after any incident, not just the ones you are sure were compromised. The credential that was not in the attacker's logs is the one they used to get back in.

And if you had a breach in 2022 and never changed your database passwords afterward, change them today. The door was never locked.