What a paste-site canary sees: the anatomy of a credential-stuffing hit

A walkthrough of the seeding pipeline end to end: how a decoy credential ends up on a paste site, what happens 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 three tiers (a social account, an email account, a financial lure) and seeds each one onto paste sites inside a fake combo list, a day or two after it is minted: 24, 36 or 48 hours, by tier.

A decoy credential belongs to no real person and appears nowhere except where CanaryVaults seeded it. That is the entire trick. Nobody types these strings by accident, and no legitimate service has a reason to log in with them. The only way a canary credential comes back to us is that someone harvested it from one of those places and used it.

A decoy fires by email: someone writes to the address, or a service someone tried it on writes to it. The mail reaches CanaryVaults, and the tripwire records the event: which canary, the platform the mail targeted when it is one we recognise, and the server that delivered it. Then the enrichment fan-out runs in parallel on that server's address, looking up its abuse history, its network and geography, the services it exposes, and whether it is known-bad infrastructure.

The alert that reaches you (email by default, Telegram if you've linked it) names that server for what it is: the mail server that delivered the message, which for a Gmail sender is Google's, not the attacker's own machine. CanaryVaults does not report it or share it. The event is sealed with a SHA-256 content hash in the evidence log, and if it ever matters in a dispute or a post-incident review, you can re-verify that the record hasn't changed since it was sealed.

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 shown you someone working those pastes.

This article is about a shipped surface: All product surfaces. Integration details live in the docs.