Why Cyber Deception is a Failed Space

Why would we say this when there are plenty of commercial deception offerings that vary in their approach and many deception acquisitions? First, we won't name them, but look at those acquisitions: Did they proliferate widely and flourish, or did they die in the acquisition graveyard? Second, after 25+ years of commercial existence, cyber deception is not a fundamental security primitive like EDR, SIEM, firewalls, WAFs, IAM, or MFA. Sure, Gartner has bestowed a name on the space. However, in two decades of offensive operations, we can count on one hand the times we have seen them in the wild, and even then, they weren't realistic or useful enough for us to interact with them.

Even if we were gullible enough to fall for the trick, by the time we encounter deception technology, we have a foothold internally, access to multiple accounts, and have spread laterally enough that we have multiple machines to use as beachheads. The alerts that would have been generated, although useful, wouldn't have been enough for the blue team to stop us because the kill chain had advanced too far. This is like using a duck decoy to defeat the Hydra.

Even before we started our offensive consultancy in 2006, my co-founders and I would often discuss how the properties of cyber deception, fake assets to lure threats away from real ones, were uniquely ideal from a defensive standpoint. If I could boil those properties down, they are:

• Tipping the attacker/defender asymmetry: Deception uses what attackers don't know, what's a real asset, and what is not, against them.
• All signal, no noise: Deception provides a high-fidelity signal with no false positives since nothing legitimate should be interacting with them.

After all, deception has been used in warfare to great success for a long, long time. Numerous types of deception have also independently evolved in biology. Either we were missing something, or there had to be more to it beyond the research-oriented honeypots and limited commercial solutions available in the early 2000s.

Over the years, as we built our offensive consultancy, we observed a small deception space emerge. Every time a new take on deception was offered to the market, we would get a demo and inevitably be left underwhelmed. "We wouldn't touch this," and "Nobody will go through the required hoops to deploy this thing, much less manage it," were usually our feelings. It wasn't until much later that the necessary fundamental technology existed to do this space justice.

Divert: Cyber Deception Reimagined

Difficult to Deploy

Early solutions were a heavy lift, basically expensive honeypots, initially requiring hardware, then in later evolutions requiring the customer's VM infrastructure, and finally using the customer's cloud resources. Some progress has been made here, e.g., "run this Docker command," but there are still no turnkey solutions. By turnkey, I mean push a button, and decoys are running and seeded.

Internally focused, exposing decoys to the edge involved DNS entries, NAT, firewall ACLs, and the other painful configuration tasks inherent to exposing any service to the public in those days. As the space evolved, we observed the use of honey tokens seeded in Active Directory, various file-based tripwires intended to be seeded in myriad locations, and, eventually, cloud-based honey tokens.

Think about the real:fake asset ratio. Could you possibly seed enough decoys to tip the scales in favor of your adversary encountering them? How many machines, inboxes, accounts, file shares, code repositories, and cloud storage buckets would need to be seeded with decoys in order for you to feel certain that a threat was sure to step on a mine? Internal and post-authentication deployment of deception is almost a non-starter based on this premise alone.

Too Late

To this day, the vast majority of deception technology is deployed too late, whether it be a honeypot on a LAN, an account placed in LSASS on a machine or LDAP, a tracked document on a file share/email inbox, or a honey token placed in a CI/CD pipeline or a cloud storage bucket. By too late, I mean an attacker already has a foothold and/or credentials. Just as a thought experiment, think about what an attacker has in order to be in those positions. How wrong have things gone for an attacker to access your inbox on M365, regardless of whether that attacker is going to open salary_tracker.xlsx. The attacker has:

• Your username
• Your password
• MFA enrollment

They're in a position to access so much more than just email. This is even more true with the other deception deployment types. Are you really going to rely on deception to fight threats when they're in your CI/CD pipeline? That's rearranging deck chairs on the Titanic. As operators, we know letting things go this far puts defenders on their back foot. It's a bad spot to be in, and we have empathy because we've been there on both sides of the equation.

You might be thinking your edge is secure, likely due to negligent pen testing over the years. If the edge is so secure, then why are you in an "assumed breach" mindset? Why cede so much ground before you begin fighting?

Alert-Only

Almost every deception play out there only contributes to alert fatigue. We refer to this as "expensive visibility." It's 2026 and everyone has enough alerts and visibility; arguably too much. It often seems to us, even outside of deception, that most defensive solutions exist in some way to contribute to alert fatigue. Cybersecurity products have to do something. Not only that, but they probably need to do it without a single FTE required to manage them. We're just being realists.

Unrealistic

Most solutions' decoys are atomic and naive, not based on how realistic multi-service, multi-token kill chains manifest. Attackers think, "Ok, root, now what?" and then move on. Real kill chains involve breaching a service to gain initial access, then using that access to escalate privileges or spread laterally until privilege escalation is possible. These become fairly elaborate in the real world and certainly do not involve compromising a single machine and staying put.

Wrapping Up

You can probably read between the lines and guess how Divert works based on our criticism of the space here. We do believe deception should be a fundamental cybersecurity defense primitive and that no one has done it properly until now. Hit us up if you'd like a demo to see how Divert can work for you: sales@divert.cloud