25’000 lies, and no idea what happened next
A fake key just fails – or is never used. The attacker tries it, AWS says “does not compute”, and they move on. We learn nothing, they potentially think “what junk” (but keep coming back!!) We could see who took the bait, but never who bit on it – did they try the key at all? From the same machine? Within seconds, or weeks later, after it had been sold on? After all, we want to know what the harvesting is for.
Like The Banana Skin in Cloudflare Tunnel and The Polite Redirect, this was a blind spot: the most interesting part of the attack was happening somewhere The MIRE couldn’t see.
Enter the canaries
Tracebit offers a free Community Edition of its canary platform. Their canary credentials are “real” credentials that exist to be “misused”. Nobody legitimate should ever use one, so the moment anyone does, Tracebit raises an alert – with the attacker’s IP, the tool they used and what they tried to do with it.
The Community Edition hands out four kinds through its API, and each one maps neatly onto bait The MIRE already serves:
- AWS keys – for the .env files and cloud-metadata traps
- SSH keys – for the .ssh decoys
- Logins – for leaked Git credential files
- Session cookies – for a developer’s saved cookie jar
The MIRE’s fake cloud-metadata endpoint used to hand out a permanent-style key in the synthesized responses with an expiry date in 2024 – a giveaway to anyone paying attention. In reality, short-lived keys with a session token look and feel real, which is exactly what a Tracebit AWS canary is.
One key per visitor – and never break the trap
Each visiting IP gets its own AWS key per day. A scanner pulling ten different files sees the same key ten times – consistent, as a real leak would be – and that key identifies who took it. A ledger records every key: who got it, from which site, from which file, and when.
✓ The canary never breaks the bait
If Tracebit is slow, unreachable or out of quota, The MIRE hands out the freshest real canary it still holds – and only when there is none, the old fake key. An attacker never sees an error or an empty file – just a key.
A switch, not a rewrite
The new release went live on 9 October with the canaries disabled – functionally identical to the previous version. The switch lives in the service’s configuration, not in the code. A few minutes later, I flipped it and unleashed the “real fakes”.
Proven, quickly
Then the first real visitor arrived: 35.241.202.92, a Google Cloud address. Over the next 11 seconds it pulled credential files from 36 different paths. The MIRE gave it one key, every time.
# time client event path 07:55:29 35.241.202.92 issued aws key ████████████ 07:55:29 35.241.202.92 served /.aws/.env 07:55:30 35.241.202.92 served /.claude/settings.json 07:55:30 35.241.202.92 served /.env.anthropic 07:55:32 35.241.202.92 served /.aws/credentials … 31 more paths, same key … 07:55:40 35.241.202.92 served /.github/workflows/deploy.yml
Look at what it asked for: .env.anthropic, .env.openai, .claude/settings.json. In the first hour, paths like these were pulled 11 times. The scanners aren’t only after cloud keys any more – they’re hunting for AI keys too.
100 slots and a three-year memory
There is a catch with the Community Edition; the free tier allows 100 active canaries of each type, and each type stays active for a very different length of time: AWS keys for 12 hours, SSH keys for 30 days, session cookies for a year, and logins for three years.
The maths is unforgiving. The MIRE’s Git credential bait is requested by around 13 different IPs a day. One login canary per visitor would burn through all 100 slots in about eight days – and then sit there, holding them, until 2029.
On launch day only the AWS keys were live; their 12-hour lifetime means the slots keep freeing themselves. Update: the fix for the rest followed the same day. The long-lived canaries are now shared over time instead of handed out one per visitor, every type keeps its own budget with headroom to spare, and trouble with one kind of key never stops the others. SSH keys went live that afternoon, and by the end of the day the Git logins and session cookies had joined them – all four kinds are out there now.
The trade-off is attribution – a shared key tells you when it leaked rather than exactly who took it. The ledger still records every IP that took one, and when a key is used, Tracebit names the IP that used it. Joining the two is the next part of the story.
Seeing it
The statistics page now has a Live Canary Credentials panel: keys harvested, by how many IPs, and how often they were served, over 24 hours, 7 days, 30 days and all time. Underneath, it now shows when a key is used: how many were tried, by how many IPs, and how long after they were taken. The daily Mastodon post picks up the numbers too.
The first bite: five minutes
This post was meant to end on a question: will anyone use these keys? I didn’t have to wait long. Shortly after 11 o’clock, a Google Cloud address pulled /.env.dev.local from mire.cc and got its own AWS key. Five minutes later, somebody used it.
# time who what 11:15:02 2600:1900:0:3803::100 harvested aws key ████████████ … five minutes of silence … 11:20:06 49.204.228.191 sts get-caller-identity success 11:20:47 49.204.228.191 s3 ls AccessDenied 11:20:54 49.204.228.191 iam list-users AccessDenied
Not by the scanner, though. The key was tried from a different machine entirely, 49.204.228.191, with the AWS command-line tool – on Kali Linux, running inside Windows; the tool’s own user agent gives it away. And the order is textbook: first who am I?, then what buckets can I see?, then which users are there? – all within 48 seconds. The canary gave them the first answer, as a real key would, and refused the rest.
So the questions this post started with have their first answers. Someone else entirely. Minutes, not weeks. And the first thing an attacker does with a fresh AWS key is check that it works – then go straight for the data and the people.
What happens next
That is one bite, from one key. All four kinds of canary are out there now, and the statistics page counts every use as it comes in. When the picture gets bigger than one bite, you’ll read about it here.
Since February, The MIRE has handed out AWS keys more than 25’000 times, to more than 3’400 different IPs. They came wrapped in .env files, .aws/credentials, fake cloud metadata and phpinfo pages – everything a scanner hopes to find on a careless server.
Every single one of them was synthesized: a random string that happened to look like a key.