We Broke Into a Dutch SaaS Company in Under 4 Hours — They Had 15 Employees
Fifteen people. A nice office in Utrecht. A SaaS product that actually made money. They thought they were too small to be a target.
They were wrong.
Here’s the anonymized timeline of a real engagement. We went from zero access to full production exfiltration in under four hours. No zero-days. No nation-state resources. Just the gaps that exist in almost every Dutch MKB.
Small doesn’t mean safe. It means less oversight. Worse passwords. Exposed dev databases. No one watching the logs. Attackers don’t care about your headcount. They care about your weakest credential.
The Target — 15 Employees, €5M ARR, Zero Dedicated Security
The company built a B2B SaaS platform for logistics. They had customers. They had revenue. They had a CTO who was also the lead developer, the sysadmin, and the “security guy” — because at 15 people, you wear every hat.
Scope: external infrastructure only. No internal network access. No credentials. Just a domain name and permission to try.
The Timeline — Under 4 Hours from Start to Exfil
Subdomain enumeration, certificate transparency logs, Shodan, and basic OSINT.
→ Found a dev subdomain: dev.api.company.nl. No TLS. Responded on port 8080.
The dev subdomain was running a MongoDB instance with default credentials. No firewall. Bound to 0.0.0.0.
→ Connected with `mongo –host dev.api.company.nl`. No auth required.
The dev database contained: production API keys, hashed passwords (MD5, unsalted), and a table of cloud IAM credentials.
→ Decoded the hashes. Cracked the easy ones. Grabbed the IAM keys.
IAM keys had read-write access to production S3 buckets and EC2. Listed all instances. Found one with a public IP and SSH open.
→ Used a cracked password to SSH into a production app server.
The app server had a `.env` file with database passwords, API secrets, and Stripe keys. The database was the live production customer DB.
→ Dumped the customer table. 12,000 records. Names, emails, hashed passwords, payment metadata.
Compressed the data. Sent it to a staging server. Downloaded the archive.
→ Full customer database in our hands. Under 4 hours total.
1 exposed dev database + default credentials + IAM keys with excessive permissions + reused password = full production compromise in under 4 hours.
The fix would have cost less than €200 and taken a few hours to configure. They didn’t. Now they know.
Why They Thought They Were Safe
- “We’re too small to be targeted.” — Attackers don’t target you. They scan the entire internet. You’re just another IP.
- “Our dev environment is separate.” — Separate doesn’t mean secure. Exposed is exposed.
- “We use cloud, so it’s safe.” — The cloud provider secures the infrastructure. You secure your config. You didn’t.
- “We have backups.” — Great. So do we now. We copied them.
This isn’t a sophisticated attack. It’s a checklist. Default credentials. Exposed dev environment. Overprivileged IAM keys. Reused passwords.
Every Dutch MKB has at least one of these. Most have all four. Attackers know this. That’s why they scan.
The Gaps We See Every Time
- Dev databases exposed to the internet — With default credentials or no credentials at all.
- IAM keys in plaintext — In code repos, in dev databases, in Slack messages.
- No MFA anywhere — Not on cloud consoles. Not on SSH. Not on admin panels.
- Shared credentials — One password for everything. Root, dev, prod, all the same.
- Logs that nobody reads — The attacker is inside for weeks. The logs show it. No one looks.
🔍 External recon — subdomains, open ports, exposed services
💣 Simulated breach — no credentials, just public access points
🔗 Lateral movement — from dev to production in hours
📋 Report — not 200 pages of noise. A short list of what will actually get you breached.
🛠️ Fix plan — step by step. No jargon. No “just upgrade everything.”
What You Can Do This Week
- 🔐 Inventory every exposed dev environment. If it has a public IP, it’s a target.
- 🔄 Rotate every IAM key. Remove unused keys. Apply least privilege.
- 📱 Enforce MFA on everything. Cloud console. SSH. Admin panels. No exceptions.
- 🗑️ Audit default credentials. Search your infrastructure for admin/admin, root/root, and blank passwords.
- 📄 Get a pentest. Not a scan. A real human trying to break in. We’ll find what you missed.
You have 15 employees. You think you’re nimble. You think you’re under the radar.
Attackers don’t care about your headcount. They care about your exposed dev database. Your default credentials. Your IAM keys in a Slack channel.
You’re not too small to be hacked. You’re just too small to survive it.
The Bottom Line
Four hours. Fifteen employees. Millions in customer data.
The company didn’t have a security team. They didn’t have a budget for one. They thought being small made them invisible.
It didn’t. It just made them an easy target.
Small doesn’t mean safe. It means less oversight, worse passwords, and a false sense of security.
Attackers know this. That’s why they scan. That’s why they win. Don’t be the next story.
Think your small business is under the radar?
Website pentest: €299. Full manual audit: €799. Full infrastructure pentest: €3,000.
📩 DM @StackOfTruths on XFree 15-min consultation. No hard sell. Just honest answers about your real risk.












Leave a Reply