There is no good reason for that

Most of the work behind a security alert is not the response but the question that precedes it. Did somebody sign in from outside, or was that the colleague from the data centre? Is this access unusual or merely unfamiliar? A large part of what a security team does is sorting out events that have a harmless explanation.

Deception reverses that order. Instead of assessing real traffic, you place something that has no operational purpose, and wait.

What gets placed

Three layers work together. On dedicated hosts, decoy systems run emulated services that look like remote access, a file share or a web server but hold no data. On real workstations, breadcrumbs lead to those systems: a saved connection in the remote-access tool, a stored session, a mapped drive, a configuration file with credentials. And in the directory sits an account that sounds interesting and is used for nothing.

All of it stays invisible while you do your job. It only surfaces when someone systematically looks at what access is lying around on a machine. Which is precisely the moment you want to catch.

Not just that, but from where

Every breadcrumb gets a unique marker. That sounds like bookkeeping and is the actual yield: a warning says not only that someone took the bait but which breadcrumb it was and which machine it sat on.

So at that same moment you have the piece of information an incident most needs: the workstation probably taken over. Without breadcrumbs that is the question you spend the next few hours trying to answer.

The exception that keeps it honest

It does not work entirely without false alarms. Your own vulnerability scanner knocks on every port, including the decoys'. A commissioned penetration test does exactly what an attacker would and finds the breadcrumbs reliably. Both are expected triggers.

Exceptions handle that, time-limited for the test window or permanent for the scanner's address. What matters is what does not happen: the hit is not discarded. It is marked as expected and stays visible; it merely raises no alarm.

The difference looks small and is not. An exception that makes events disappear blinds a system exactly where someone would later need them, for instance when it turns out the supposed scanner was not one.

What the module deliberately does not log

Decoys check in regularly so you notice when one fails. Those heartbeats and the counters for repeated hits are explicitly kept out of the audit trail. They change by the minute and would flood it until nothing in it can be found.

What gets logged is what constitutes a decision: that a breadcrumb was placed, that an exception was granted, that someone assessed a warning.

Every warning names its technique

Since the latest expansion, every early warning also carries its MITRE ATT&CK technique. A sign-in attempt against the emulated remote access is recorded as T1021.001, a service ticket requested for the decoy account in the directory as T1558.003, an unspecific hit as network discovery T1046. If the ATT&CK catalog is imported, one click leads from the warning straight into it, pre-filtered to exactly that technique. The question from our article on visibility, how you would notice a technique, gets a particularly short answer here: by the decoy, and it names the technique as it fires.

When this pays off

Deception replaces no detection; it complements it where the other methods get expensive. An attacker already moving inside the network largely behaves like an employee, because they are using an employee's account. That is exactly where a decoy helps: it does not distinguish by behaviour but by whether someone knows the way around.

More on the deception module page.