I Put a Canary Token on a WordPress Site. It Got Tripped in 4 Hours.
I deployed a single canary token on a plain, unremarkable WordPress site. No special security. No high-profile target. Just a vanilla WooCommerce install with default settings.
Four hours later, my phone buzzed. Someone found the bait.
Not a targeted hacker. Not a sophisticated APT. Just the automated, relentless machinery of the internet that probes every corner of your site 24/7. They sniffed out a fake config file, tried to weaponize it, and then moved on.
If you run a website, you are already being scanned. The question isn’t “if” someone finds your sensitive files. It’s “when.” Attackers don’t care about your business size. They care about your exposed secrets. And they have bots that work faster than your IT guy.
The Setup — A $6 WordPress Site
The target was a standard WordPress + WooCommerce site, running on a cheap VPS in the Netherlands. The kind of site thousands of Dutch MKB companies use every day. We didn’t change the default security posture. We just added one canary token.
That’s it. No email alerts. No intrusion detection. Just a dummy file that the site would never use, placed in a directory where attackers often look.
A canary token is a digital tripwire. A fake file, a bogus URL, or a phony API key that exists only to alert you when someone interacts with it. It’s named after the canaries coal miners used to carry — if the bird stopped singing, you knew danger was near.
The Timeline — 4 Hours to First Contact
File created. No special permissions. No indexing.
Scanners began hitting common paths:
/wp-admin, /xmlrpc.php, /.git/config, /backup.zip. Mostly automated vulnerability scanners and content scrapers.
An IP from Ukraine attempted to log in as “admin” with 23 different passwords. Failed. The canary remained untouched.
A scanner started fuzzing for hidden directories and files —
/backup, /old, /temp, /uploads. It found /wp-content/uploads/ and began listing files.
The scanner downloaded
config.env from /wp-content/uploads/config.env. Immediate alert triggered. The IP was from a known residential proxy pool — someone browsing through a compromised home router.
The attacker attempted to extract “credentials” from the fake file. When none worked, they pivoted to other common files (
.env, wp-config.php) before moving on to the next target.
4 hours from deployment to discovery. 4 minutes from discovery to attempted exploitation. All automated. All without a human ever looking at the logs until the alert fired.
Who Tripped the Canary? (Attacker TTPs)
- Origin: Residential proxy IP (Netherlands, but traced back to a compromised home router). The attacker hides behind real users’ connections.
- User‑Agent: A generic “Mozilla/5.0 (Windows NT 10.0; Win64; x64)” — clearly spoofed. No identifiable scanner signature.
- Tactics: Low‑and‑slow scanning. Didn’t hammer the server. Stayed under the radar.
- Techniques: Directory brute‑forcing → file discovery → credential extraction attempt → lateral movement to other common files.
- Goal: Find legitimate credentials, API keys, or database passwords to sell or use for further compromise.
This wasn’t a custom attack. It was a script. A botnet proxied through your neighbors’ routers. And it found our bait in 4 hours.
Imagine what it would find on a real site with real secrets. A stray
.env file. An exposed wp-config.php. A backup folder left open. Attackers don’t hunt — they vacuum. And your site is just another IP on the list.
Why Your Site Is Next
- You have files you forgot about. That old backup. That test script. That temporary config file from 2022. Attackers scan for them constantly.
- You trust
/uploads/is safe. It’s not. It’s one of the first places scanners look. - You think “security through obscurity” works. It doesn’t. Bots don’t care if your secret file is named
supersecret.txt. They’ll find it anyway. - You assume you’re too small to be a target. You’re not. You’re just small enough to be a soft target.
What the Attacker Was Looking For
Once they find one, they try to weaponize it. Database credentials lead to your customer data. API keys lead to your cloud infrastructure. SSH keys lead to your servers.
✅ Search your website directories for
.env, config, backup, *.sql, *.pem, id_rsa. Delete anything that shouldn’t be there.✅ Block
/wp-content/uploads/ from executing any PHP files.✅ Set up your own canary tokens. A simple fake
.env file can give you early warning.✅ Monitor your access logs for repeated 404s to suspicious paths.
✅ Deploy a real Web Application Firewall (WAF) — not just a plugin.
The Bottom Line
A fake file. Four hours. One alert that turned into a full recon report.
This wasn’t a sophisticated pentest. It was the internet doing what it does every day — scanning, probing, and waiting for someone to leave the door open.
Attackers don’t break in. They walk through unlocked doors. Your job is to find the unlocked doors before they do.
If a single canary token can reveal so much, imagine what a full pentest would uncover. Don’t wait for the alert that isn’t fake.
Want to see what’s lurking on your own site?
Website pentest: €299. Full manual audit: €799. Security retainer: €1,500/month.
📩 DM @StackOfTruths on XFree 15-min consultation. No hard sell. Just honest answers about your exposed secrets.
Leave a Reply