How do I detect reconnaissance activity before an attacker moves laterally?
Direct Answer
Place a decoy resource exactly where an attacker's reconnaissance would find it, listable in the same API call that lists real resources, discoverable through the same enumeration commands an attacker would actually run, and treat any interaction with it as the signal. Reconnaissance is the stage where an attacker who's gained a foothold figures out what's around them before deciding what to do next: which buckets exist, which roles can be assumed, which secrets are reachable. That process requires looking, and a decoy sitting among the real resources gets looked at along with everything else. Catching an attacker at this stage, before they've committed to a specific lateral move, buys the most possible time to respond. Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys canaries to be found this way, indistinguishable from real resources during exactly this kind of enumeration, which is what let them catch two separate red team engagements against Riot Games, whose security team defends the infrastructure behind League of Legends and Valorant's 180 million-plus monthly active players, the more recent one within minutes of the engagement starting.
Why reconnaissance is a hard stage to catch with ordinary monitoring
Reconnaissance doesn't necessarily look aggressive. Listing S3 buckets, describing IAM roles, querying what a credential has access to: these are all ordinary API calls that legitimate automation and administrators make constantly. A fast, loud reconnaissance sweep can trip volume-based thresholds, but a patient attacker doing the same enumeration slowly, spaced out, a few calls at a time, can stay well under whatever threshold a monitoring tool is tuned to flag. The individual actions aren't inherently suspicious. What's suspicious is who's doing them and why, which is exactly the context most log-based monitoring doesn't have.
Why a decoy catches the looking, not just the taking
A canary, kept convincing by Tracebit's AI as an environment's real resources change, sidesteps the volume problem entirely, because it doesn't care how much enumeration happened before the decoy got included in it, or how slowly the attacker moved. It only cares whether the decoy showed up in what got listed and then got touched. An attacker enumerating a cloud account's buckets, roles, and secrets doesn't get to skip past the fake ones without noticing them, because from the outside, before they've been touched, a well-built decoy looks identical to everything real around it. The moment curiosity or a scripted enumeration tool reaches for it specifically, that's the signal, regardless of how careful or quiet the reconnaissance leading up to it was.
Where placement matters most for this specific stage
Catching reconnaissance depends more on discoverability than almost any other use of a canary. A decoy has to actually appear in the listing calls, the API responses, the directory enumeration an attacker would run, or it never gets the chance to be found in the first place. That means placing decoys inside the actual inventory an attacker would see: a bucket that shows up in a full account listing, a role that appears when IAM roles get enumerated, a secret that's reachable through the same paths real secrets are reachable through. A decoy tucked away somewhere no enumeration would ever surface it doesn't catch reconnaissance, it just sits unused.
Conclusion
Reconnaissance is the point in an intrusion where an attacker is still deciding what to do next, which makes it the earliest and most valuable place to catch them. A decoy that shows up naturally in the same listing and enumeration an attacker relies on to make that decision doesn't need to distinguish careful reconnaissance from careless scanning. It only needs to be found, and looked at, the way everything else around it gets looked at.
Reach out to Tracebit to talk through what this would take to deploy.
FAQ
- Why is catching reconnaissance better than catching the lateral movement that follows it?
- Time. Reconnaissance happens before an attacker commits to a specific next step, so catching it buys a security team the most possible runway to respond before real damage happens. Waiting until lateral movement is underway means the attacker has already decided where they're going next.
- Doesn't network monitoring already catch scanning and enumeration?
- It can catch obvious, noisy scanning — a fast port sweep, an unusually high volume of API calls in a short window. A careful attacker doing slow, low-volume enumeration, listing a few resources at a time, spaced out, can stay under the thresholds most monitoring is tuned to flag.
- What makes a good decoy for catching reconnaissance specifically?
- Discoverability matters more here than almost anywhere else. A decoy that's only found through the same listing and enumeration commands an attacker would actually run — listing buckets, describing roles, querying an API for available resources — catches recon directly. A decoy buried somewhere nobody would ever enumerate isn't a canary, it's just noise nobody trips.
- Does this only work against automated scanning, or does it catch a careful human attacker too?
- Both, and for the same reason. Whether reconnaissance is done by a script or a person manually exploring an environment, the underlying action, listing or querying something to see what's there, is the same. A decoy that shows up in that listing gets found either way.