A walkthrough of the seeding pipeline end to end: how a decoy credential ends up on a paste site, what happens in the moments after someone tries to use it, and what lands in your alert channel.
Credential stuffing is an economy of scraped lists. Combo lists circulate on paste sites, someone feeds them into a tool, and the tool tries every pair against login pages until something works. The defenders' problem is that all of this happens off your infrastructure — by the time a stuffed credential hits your login page, you are already at the last step of the attack chain.
A paste-site canary moves your tripwire to the first step. CanaryVaults generates decoy credentials in believable tiers — a social account, an email account, a financial lure — and seeds them onto paste platforms with staggered timing. The delay between generating a canary and seeding it is deliberately randomized and measured in days, not seconds, so the paste doesn't correlate with anything on your side. The pastes themselves are short-lived; scrapers work faster than expiry.
Each seeded credential is unique to one paste. That is the entire trick. Nobody types these strings by accident, and no legitimate service will ever try to log in with them. The only way a canary credential comes back to us is that someone harvested that specific paste and put it into a tool.
When a canary is used, the tripwire endpoint decodes the tracking token and captures the event: which canary, which paste it was seeded to, source IP, and request metadata. Then the enrichment fan-out runs in parallel — AbuseIPDB for abuse history, IPInfo for network and geography, Shodan's InternetDB for exposed services on the source, VirusTotal for known-bad infrastructure. The result is an attacker profile attached to the event, not a bare IP in a log line.
The alert that reaches you — email by default, Telegram if you've linked it — carries that whole picture, sealed with a SHA-256 content hash in the evidence log. If the event ever matters in a dispute or a post-incident review, you can re-verify that the record hasn't changed since the moment it was written.
One honest caveat: how often a paste-site canary fires depends entirely on where attackers happen to be harvesting. Some canaries get tried quickly, some sit quiet for months, and your mileage may vary. But the asymmetry is the point — a canary that never fires costs you nothing, and a canary that fires once has already told you which list you're on and who is working it.
This article is about a shipped surface: All product surfaces. Integration details live in the docs.
Continue reading
More notes from the CanaryVaults team.
Every page on our site was shipping an empty body
One call to useSearchParams() sat inside the root layout's only Suspense boundary, and deopted the entire application to client-side rendering. Twelve words of markup left our server. Nothing in the build said so.
EngineeringIt worked, it said so, and nothing happened
A contact form returned 201 and showed a green confirmation every time. Nobody was ever notified. We went looking for more of these and found about thirty, all with the same shape.
PostmortemWe were selling a proof that had never run
Several pages described CanaryAudit records as anchored on-chain. Not one record ever had been, and the code that would have done it was not in the deployed image. Here is what happened, and what we decided instead.