The credential-leak playbook: how attackers find secrets in Slack and email
When an attacker gets into a mailbox or a Slack workspace, they rarely start by doing something clever. They start by searching. The uncomfortable truth about most credential leaks is that they aren't intercepted in transit — they're found later, at rest, by someone who shouldn't have access to the archive.
Step one is always search
Chat and email are, functionally, searchable databases of everything your team has ever said. That's what makes them useful — and what makes them a goldmine after a compromise. The standard opening moves are boringly effective: search for password, api key, secret, token, .pem, AKIA (the prefix of AWS access keys), BEGIN PRIVATE KEY, or the name of your cloud provider. Whatever your team pasted, the search box finds.
Automated tools do the same at scale. Secret-scanning engines that defenders use to catch leaks in code work just as well for an attacker sifting an exported mailbox — regex patterns for key formats, high-entropy strings, and known token shapes turn a dump into a tidy list of live credentials.
Why "we use TLS" doesn't help here
Transport encryption protects the message while it travels. It does nothing about the message sitting in the recipient's inbox, your sent folder, both providers' servers, every backup, and every device either party has signed into since. A password sent in 2023 is present in all of those places today. Compromise any one of them and the credential is exposed — years after you stopped thinking about it.
The offboarding problem
There's a quieter version of this that doesn't even require a breach. The contractor you stopped working with two years ago still has every credential you ever sent them, scattered across their inbox and chat history. You have no inventory of what they hold and no way to revoke a copy that lives in someone else's archive. The exposure didn't end when the engagement did.
Removing secrets from the archive
The fix isn't a better password or a stern policy — it's making sure the secret was never in the searchable archive to begin with. That means sending a one-time link instead of the credential itself. The secret is encrypted in your browser; the decryption key rides in the URL fragment, which never reaches any server; and the first open destroys it. What lands in Slack or email is a link that, once used, opens nothing. The channel's retention problem stops mattering, because there's nothing sensitive left to find.
Two habits make this robust:
- Treat a dead-on-arrival link as an incident. One-time delivery doubles as a tripwire — if a link reports "already viewed" before your recipient opened it, someone else did. Rotate the credential; you just caught an interception that a plain email would have hidden.
- Invert the flow when you're receiving. Ask for secrets via a request link rather than letting people reply with a password in plaintext. It encrypts in their browser and gives you a one-time read — so the secret never lands in your inbox either.
Credential leaks are rarely exotic. They're an old message, found later, by the wrong person. The remedy costs thirty seconds: share something that dies on arrival instead of something that lives in the archive forever.