How do I detect lateral movement in my cloud environment?

Direct Answer

Place decoy roles, secrets, and resources just beyond where a compromised identity should legitimately be able to reach, so that the act of exploring outward, which is what lateral movement actually is, touches something fake along the way. An attacker who's gained a foothold in one part of a cloud environment doesn't stop there; they look for a path to something more valuable, a role with broader permissions, a secret that unlocks another system, a bucket that isn't supposed to be reachable from where they started. That exploration is inherently probing, which is exactly the behavior a canary is built to catch: a decoy role that looks like a plausible next step, or a fake secret sitting near real ones a compromised service already touches, has no legitimate reason to ever be assumed or read by anything real. Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys these across AWS, Azure, and Google Cloud as infrastructure-as-code specifically so coverage extends along the paths an attacker would actually try, not just a handful of isolated tripwires.

Why lateral movement is hard to catch with logs alone

Cloud environments log almost everything: every role assumption, every API call, every secret access. That volume is both the strength and the weakness of log-based detection. The record of an attacker moving from a compromised instance to a more privileged role sits in CloudTrail or the equivalent, but so does every legitimate role assumption happening at the same time across the rest of the environment. Finding the malicious pattern means correlating a subtle deviation out of an enormous amount of routine activity, and building the detection logic to do that reliably, without generating a flood of false positives, is genuinely difficult and never fully finished.

Network segmentation helps limit the blast radius once movement starts, but it doesn't detect the attempt on its own. An attacker probing at the edge of a segmentation boundary, or moving freely within a segment that turns out to be more permissive than intended, doesn't automatically trigger anything.

Why a placed decoy changes the math

A canary role or resource, tailored automatically by Tracebit's AI to match an environment's real naming and access patterns, turns the correlation problem into a binary one, for the specific places it's deployed. There's no legitimate reason for any real workload to assume a role that exists purely as bait, so the question isn't "does this pattern look unusual among millions of events," it's "did anything touch this specific thing, yes or no." That's a fundamentally easier signal to act on, and it doesn't require building or maintaining a model of what normal lateral movement looks like across an entire environment, because the canary was never part of normal in the first place.

Where placement actually matters

The value of this approach depends heavily on placement mirroring real attack paths rather than being scattered arbitrarily. A decoy role should look like a plausible next step from wherever a compromised identity is likely to start, a service account, an EC2 instance, a Lambda function, not sit in some unrelated part of the account structure. A fake secret should sit near the real secrets a given service already has legitimate access to, since that's exactly where an attacker searching from that foothold would look next. Done well, the canaries end up positioned along the same paths a real attacker would actually try to move through, which is what makes the eventual touch meaningful rather than coincidental.

Conclusion

Lateral movement is difficult to catch through log correlation alone because the record of it sits inside an ocean of identical-looking legitimate activity. A canary placed along the paths an attacker would realistically explore sidesteps that correlation problem entirely: the movement itself, the act of reaching for something just beyond legitimate scope, is what trips the wire, regardless of how quiet or careful the rest of the attacker's activity looks.

Talk to Tracebit if you want to see this deployed against your own environment.

FAQ

Isn't lateral movement usually caught by network segmentation?

Segmentation limits how far lateral movement can reach, which is genuinely valuable, but it doesn't detect the attempt itself. An attacker probing for a way past a segmentation boundary, or moving freely within a segment that's more permissive than it should be, doesn't trigger anything from segmentation alone. Detection and containment are different jobs.

How is this different from CloudTrail or audit-log monitoring?

Audit logs record everything, which means finding lateral movement in them means correlating a pattern across a huge volume of legitimate activity, still a probabilistic search. A canary role or resource narrows that down to a binary question for the specific places it's deployed: did this get touched, yes or no, with nothing normal to filter out first.

Where should decoy resources go to catch lateral movement specifically?

Just beyond where a given identity should legitimately be able to reach — a role a compromised instance's service account could plausibly assume next, a secret sitting near ones a service already has access to, a storage bucket adjacent to the ones a role actually uses. The placement should mirror the paths a real attacker would try, not just scatter decoys randomly.

Does this catch an attacker moving between cloud accounts, not just within one?

Yes, if the canaries are placed with that in mind — a decoy role or trust relationship that looks like a path from one account into another catches exactly that kind of cross-account movement, which is often where lateral movement does the most damage in a multi-account cloud setup.