How to Outwit Attackers with Cyber Deception

I spent several years as a magician and mentalist, and the thing people always got wrong about magic is that they thought the trick was about manual dexterity. Mostly, it isn't. It's about psychology. Get someone looking in the right direction and you can do almost anything in plain sight.

I think about that a lot in the context of cybersecurity, because attackers use exactly the same principles. Phishing is misdirection. Social engineering is cold reading. A well-crafted attack makes the target feel in control right up until the moment they aren't.

The interesting question is whether defenders can turn those same principles back on attackers. I think they can, in the right circumstances. That's what cyber deception is.

The magician's toolkit, applied to security #

Magicians have a technique called the force. You offer a subject what appears to be a free choice (pick any card, choose any envelope), but through careful setup and subtle steering, they almost always pick the one you want. They feel certain they chose freely. That's the point.

A well-designed honeypot works the same way, but the mechanism is indirection. You don't drop a fake server on your network and hope an attacker stumbles into it. You leave traces that lead them there: a credential in a config file, a reference buried in a log, a share name that looks slightly more interesting than it should. The attacker follows the trail and concludes, entirely on their own, that they've found something worth investigating. They feel like they discovered it. That feeling is the trap.

Misdirection is the other core technique. In magic, you don't hide what you're doing. You give the audience something more interesting to watch instead. In security terms, a deceptive environment doesn't just trap attackers; it occupies them. While they're spending hours exploring fake systems and chasing false leads, your real assets stay untouched and your security team is watching every move they make.

Mentalists also have many methods for gathering intelligence about a person well in advance, then revealing it during a performance in a way that appears completely spontaneous, as though the information is arriving in real time. The audience never suspects the groundwork was laid long before they walked in the room. The security equivalent is using threat intelligence to understand who is likely to come after you and what they expect to find. A threat actor that routinely targets Active Directory will be looking for domain controllers; one after financial data will be hunting for database servers and file shares with promising names. That knowledge shapes everything: the systems you build, the data you seed, the trails you lay. A generic honeypot is a speed bump. One built around a specific attacker's expectations is a trap they'll walk into confidently.

What deception actually is (and isn't) #

Deception technology is more than scattering lures and decoys across a network. The real skill is in building a believable narrative. What would an attacker targeting your organisation expect to find? What does your network look like to someone who has just gained a foothold and is trying to work out where they are and what's valuable? Your deceptive environment needs to answer those questions convincingly, and then use the answers to shape the attacker's behaviour.

Crucially, deception works in both directions. Fake systems need to look real, but real systems can also be made to look unremarkable. A payment processing server with a name that gives nothing away is considerably harder to find than one called something obvious. Stripping away the signposts that help an attacker orient themselves is a form of deception in its own right.

The core tools are:

Honeypots are fake systems designed to look like real, valuable targets: a domain controller, a payment system, a file server full of sensitive documents. They're fully instrumented to log everything an attacker does, which means every technique they use, every vulnerability they probe, and every lateral movement they attempt is recorded. That intelligence can be used directly to build custom detection content tuned to the specific behaviour you've observed.

Honeytokens are fake credentials, API keys, documents, or data. Seeded in plausible locations, they act as tripwires: the moment anyone uses them, you know something is wrong, and you know exactly where that person has been.

Deceptive environments are broader deployments where deceptive elements are woven throughout a real network. Done well, an attacker moving through a deceptive environment has no reason to suspect anything is out of the ordinary. Every system they access, every credential they find, looks and behaves exactly like the genuine article.

There's also a subtler variant worth considering. Sometimes it makes sense to plant something that looks like a mistake: an overly permissive share, credentials that appear to have been left somewhere carelessly, a system that seems to have slipped through the patching process. The attacker finds it and feels lucky. They think they've found a genuine oversight, something the security team doesn't know about. That belief makes them slow down and proceed carefully, because they want to exploit the advantage without alerting anyone. They don't suspect a trap at all. They just think they got lucky, and that caution gives you time. The lure has to fit the narrative of the network, though: a believable mistake in the right place reads as human error; the same thing in the wrong place reads as something else entirely.

I want to be straight about the limitations: deception isn't a fit for every organisation. Setting it up properly takes thought and ongoing maintenance. Poorly designed decoys are either ignored or detected, and at that point you've told the attacker something about how your defences work. Done well, though, it's one of the few controls that actively benefits from an attacker being present. Most security tools try to keep attackers out. Deception works precisely because it assumes some of them will get in.

Why attackers fall for it #

Even skilled attackers are operating under pressure, in an unfamiliar environment, trying to move quickly and stay hidden. That cognitive load makes them vulnerable to exactly the biases that make magic work on audiences.

Familiarity bias means they'll trust things that look like what they expect. A honeypot with a plausible hostname, a realistic file structure, and aged-looking logs will be treated as a real system.

Overconfidence is a more interesting factor than it first appears. You might expect that skilled attackers would be harder to fool, but in my experience doing mentalism, the opposite was often true. Very intelligent people tend to follow a logical narrative: they see evidence, draw a reasonable conclusion, and move on. That same quality that makes them good at what they do means they sometimes skip over details that a less experienced person might stop and question. There's also a domain knowledge problem: a technically expert attacker knows a great deal about computer systems, but that expertise gives them no particular immunity to deception techniques. A brain surgeon is no harder to fool with a card trick than anyone else.

Confirmation bias rounds it out. Once an attacker believes they've found a genuine target, they'll interpret subsequent evidence in its favour. Seed a few additional deceptive elements that confirm their assumption and they'll dig deeper into the trap rather than questioning it. Their own intelligence works against them: the more the evidence fits the story, the more committed they become.

What it looks like in practice #

Here's an illustrative scenario that captures how this plays out. A financial services company suspects it may be targeted by a threat actor with an interest in payment systems. Rather than just deploying a honeypot and hoping for the best, the security team thinks about the narrative from both directions: what does a genuine payment environment look like, and how do they make the real one harder to find?

They rename the real payment systems to something unremarkable, strip away any obvious signposting, and build a cluster of honeypots with the kind of names and structure a real payment environment would have: plausible server names, realistic transaction logs, honeytokens seeded in the places a lateral-moving attacker would naturally look.

A few weeks later, an attacker who has gained a foothold via a phishing email starts moving through the network. They follow the trail the security team laid and find what looks like a payment server. They spend hours enumerating it, trying credentials, and attempting to exfiltrate data, triggering high-fidelity alerts the whole time. The security team watches, collects detailed intelligence on their tools, techniques, and targets, and uses that intelligence to build detection content before cutting them off. The real payment systems were never found.

The attacker never questioned whether the system was real. The narrative was convincing because it was built around what that attacker expected to find, and the thing they were actually looking for had been made to look like something else entirely.

Where to start #

If you're thinking about adding deception to your environment, I'd start small and focused rather than trying to build a full deceptive environment from the off. It's also worth knowing that you don't have to build everything yourself: commercial deception platforms exist that handle much of the deployment and management, and can generate convincing decoys at scale. They vary considerably in quality, but they're worth evaluating if you're serious about this as a sustained capability rather than a one-off experiment.

Honeytokens are the easiest entry point regardless of which route you take. Drop a few fake credentials or API keys in plausible locations: a config file, a shared drive, a code repository. Set up alerting on them. They cost almost nothing to deploy and the signal quality when they trigger is excellent: a honeytoken alert has almost no false positive rate, unlike most security alerts. If someone is using that credential, something is wrong.

From there, a honeypot or two placed near your most critical assets. The goal isn't to fake your entire network; it's to put something irresistible between an attacker and whatever you're actually trying to protect, and to make the path there feel like a natural discovery rather than a setup.

The force, applied to security: make the path to your real assets lead through the trap, and make the trap look more valuable than the truth.

It won't stop every attacker. Nothing does. But for the ones who get in, it's a way to slow them down, learn about them, and protect things that matter. If you've used deception in your environment, or you're thinking about it, I'd be interested to hear how you approached it.