How do I detect a stolen or compromised credential being used by an attacker?

Direct Answer

Plant a fake credential among the real ones, and treat any use of it as proof of compromise, because a stolen credential otherwise looks exactly like a legitimate one all the way through. Once an attacker has valid credentials, they pass MFA, authenticate normally, and do the sort of thing a real user or service does: they're not tripping any alarm built to catch suspicious-looking activity, because nothing about using a real credential looks suspicious. A honeytoken credential, an AWS session token, an API key, a login that was never issued to any real person or service, sidesteps that problem entirely. There's no legitimate scenario where it gets used, so its use isn't evidence to weigh, it's the answer itself. Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys these across cloud accounts, identity providers, and CI/CD pipelines, and the mechanism held up in testing that matters: the security team at Cresta, an AI-powered contact center platform, set up canary credentials across AWS, Okta, and GitHub in four hours and now averages roughly one alert a month, low enough volume that every one gets treated as urgent rather than lost in a queue.

Why a stolen credential defeats most of what's watching for it

A credential gets stolen in a lot of ordinary-looking ways: phished, bought off a leak, lifted from a CI log, minted from a session token that leaked somewhere it shouldn't have. None of those methods leave the kind of trace a malware scanner or an exploit detector is built to catch, because no malware ran and no exploit fired. Once an attacker has the credential, using it looks like exactly what it is on paper: a valid login, doing valid-looking things. Posture management stays green. Endpoint tools see nothing worth flagging. The attacker isn't breaking in, they're logging in.

Behavioral monitoring helps here, watching for a login from an unfamiliar location or an unusual access pattern, but it's still making a probabilistic call. A legitimate employee traveling, working late, or touching a system they don't normally touch can trigger the exact same signal as an attacker, which means every alert needs a human to weigh it before acting.

Why a fake credential removes the ambiguity

A canary credential, the kind Tracebit's AI generates to match an environment's real naming conventions, doesn't have that weighing problem, because it was never real to begin with. Nobody, no employee, no automated process, no legitimate integration, has any reason to ever use it. If it gets used, that fact alone answers the question a behavioral alert can only estimate: this is unauthorized, not "this looks like it might be." The credential doesn't need to be especially convincing to a machine-learning model or match a subtle statistical pattern. It only needs to sit somewhere an attacker searching for something to steal would plausibly find it, indistinguishable from the real credentials around it.

Where this actually gets deployed

The placement follows where real credentials tend to leak from or get discovered: password managers and browser session storage on developer workstations, secrets stores and environment variables inside CI/CD pipelines, IAM policies and role definitions in cloud accounts. A canary credential sitting in any of those spots looks like exactly the kind of thing an attacker who's gained a foothold goes looking for next, which is the point, it's supposed to be found, just not by anyone with a legitimate reason to be looking.

Conclusion

A stolen credential is hard to catch precisely because it isn't behaving abnormally, it's behaving exactly like the real thing it was stolen from. The fix isn't a better model for spotting subtle anomalies in normal-looking activity. It's removing the ambiguity at the source: a credential that has no legitimate use turns "was this the attacker" from a judgment call into a fact, the moment it gets touched.

Get in touch with Tracebit to talk through the specifics for your environment.

FAQ

Why doesn't MFA stop this from being a problem?

MFA stops an attacker who only has a password. It doesn't help once an attacker has a full valid session, a stolen token, or a phished approval, because at that point they're not guessing a second factor, they already passed it. MFA closes one door; it doesn't do anything about a credential that's already through it.

How is a honeytoken credential different from just monitoring login locations or devices?

Location and device monitoring is still probabilistic — a login from a new city or an unrecognized device might be the legitimate user traveling, not an attacker, so it has to be weighed rather than trusted outright. A honeytoken credential doesn't have that ambiguity. It was never issued to anyone, so there's no legitimate scenario where its use is anything but unauthorized.

Where should a canary credential actually be placed to catch this?

Wherever a real credential would plausibly sit and be found: a password manager, a CI/CD pipeline's secrets, a config file, a cloud IAM policy. The point isn't to protect one especially sensitive system, it's to sit among the same places an attacker searches once they're rooting around for what to steal next.

Does this only work for cloud credentials, or does it apply to on-prem systems too?

The principle is the same either way — a fake credential with no legitimate use, placed where a real one would sit — though the specific implementation differs. Cloud identity providers and IAM systems are where most current deception tooling, including Tracebit's, is built to deploy this at scale today.