Your chat app leaked your secrets
It was just Slack. So why does the attacker have a dozen of your passwords and API keys? Because of where your team kept pasting them. Here is the data-theft path, and how to govern it.
It was just your chat app. So why does the attacker now hold a fistful of your passwords and API keys?
What it is
Slack holds conversations, files, and the credentials and secrets people paste into channels and DMs. A stolen Slack token, leaked in code or phished, or an over-scoped OAuth app installed through social engineering, can read message history, list and download files, search the workspace for passwords and keys, and persist as a trusted app. Because it uses valid Slack APIs, it looks like a normal integration. This is T1528 (steal application access token) into T1213 (data from information repositories) and T1567 (exfiltration over a web service).
Why it works
Chat feels casual, so secrets get pasted there. But a valid token reading the workspace is a data-exposure incident, and every secret your team shared in a channel is still valid.
How to detect it
In the Slack audit log, look for a token or app reading content from a new origin at a breadth the identity does not normally use, bulk file downloads, searches for terms like password and token, and a newly installed app with broad scopes.
The fix that holds
Require admin approval for app installation, restrict apps to least scope, and keep tokens out of code. Audit installed apps, alert on broad-scope installs and bulk reads, and move secrets to a secrets manager so they never live in chat. When you respond, revoke the token, remove the app, and rotate every secret that was exposed in content.
Practice it
We built a Slack token-and-app data-theft scenario in GraphLattice Range so teams learn to treat chat as a sensitive data store and govern app installs before the secrets walk.