Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / How CISOs Use Cyber Deception to Trap Attackers
Transcript
- Lucas: You spend millions on firewalls, endpoint detection, and SIEMs. An attacker is inside your network for an average of 204 days before anyone notices. That is the median dwell time from the latest Mandiant report. So what if you could not just detect them faster, but make them think they are stealing something real when actually they are wandering through a fake environment designed to trap them? Luna: You are talking about cyber deception. Honeypots and lures. I know this has been around in academic circles for a while, but it is getting real commercial traction now. Is it actually working in the field? Lucas: It is, and the adoption curve is steep. Gartner predicts that by 2027, 30 percent of large enterprises will use deception technology as part of their defense-in-depth strategy. Today it is probably closer to maybe 10 to 15 percent, but we are seeing it pop up in financial services, healthcare, and increasingly in mid-market firms that cannot staff a 24-7 SOC. Lucas: Before we dive deeper, I want to mention something quickly. If conversations like these are useful for what you are building or running, listener support is what keeps this show ad-free. You can help at buy me a coffee dot com slash fexingo. That is buy me a coffee dot com slash fexingo. No pressure at all, just wanted to put it out there. Luna: Yeah, and it really does make a difference. We keep the show independent that way. Okay, back to deception — what does a real deception deployment look like? Give me a concrete example. Lucas: Sure. I spoke with the head of threat detection at a mid-size European bank — about 15,000 employees. They deployed a deception layer across their Windows domain. They created fake Active Directory users with realistic names, weak passwords, and stale-looking accounts. Then they scattered breadcrumb documents labeled 'Q3 financial projections' on a few file shares that only attackers would find. Luna: So the breadcrumbs are the bait. What happened when someone bit? Lucas: Within three weeks, the deception platform alerted on a user account trying to enumerate those fake shares from a compromised workstation. The attacker had been inside for less than six hours. The bank's SOC isolated the machine, kicked the attacker out, and found the initial infection vector — a phishing email — all before any real data was touched. Compare that to the 204-day median dwell time we opened with. Luna: Six hours versus 204 days. That is a dramatic reduction. But how do you ensure the attacker actually finds the bait? If they are sophisticated, they might ignore those stale-looking folders. Lucas: Great question. That is where the art of lure design comes in. The bank's team planted the breadcrumbs on paths that mimic real business workflows. For instance, a shared drive labeled 'Budget_2026_Final' in a folder that was historically used by finance. They also used honeytokens — fake credentials that look like a privileged service account. When an attacker runs a tool like Mimikatz to dump passwords, they grab those tokens and try to use them. The moment the token is used, an alert fires. Luna: So it is not just about putting a honeypot server in the DMZ. It is about embedding deception into the normal fabric of the network. Makes sense. But what about cost? A mid-market company might look at this and think, 'I already pay for EDR and a SIEM. Do I really need another tool?' Lucas: Fair point. Deception is not a replacement for endpoint detection or your SIEM. It is a complementary layer that fills a specific gap. EDR is great at detecting known malware signatures and suspicious process behavior. But a lot of attackers now use living-off-the-land techniques — they use legitimate tools like PowerShell and WMI. Deception catches the behavioral anomaly: why is a domain controller account accessing a file share that nobody has touched in two years? Luna: I have also heard that deception can generate a lot of false positives if not tuned properly. Did the bank struggle with that? Lucas: They did initially. Their first deployment had too many lures that were too obvious to real users but not obvious enough to attackers. A legitimate admin triggered an alert by connecting to a decoy server during maintenance. They learned to tag their lures in their CMDB so that any interaction from an untagged system is suspicious. After a month of tuning, their false positive rate dropped below 2 percent. Luna: That is impressive. So the key is careful planning and integration with existing tools. I imagine this also gives you threat intelligence — you can see the attacker's tactics and tools in real time because they are interacting with your controlled environment. Lucas: Exactly. That is one of the biggest secondary benefits. The bank captured the attacker's entire toolset — they were using a modified version of Cobalt Strike, which is a legitimate penetration testing tool but often weaponized. They also logged the specific commands the attacker ran, which they then used to update their detection rules across their EDR and firewall. So deception becomes a sensor for the rest of the security stack. Luna: Let me play devil's advocate again. Some CISOs I talk to say deception is just a fancy tripwire. If your detection is good enough, you do not need it. Why not just invest more in your SIEM rules? Lucas: I think that view underestimates the difficulty of writing good SIEM rules. A SIEM is only as good as the logs you feed it and the correlation rules you write. Deception is inherently low-noise and high-signal because any interaction with a decoy is almost certainly malicious. There is no legitimate reason for a user to log into a fake admin account. So it cuts through the noise. Plus, SIEM rules can be evaded if the attacker knows what you are looking for. Deception is harder to evade because you do not know where the fake assets are. Luna: True. And I suppose the ethical hackers in red teams have been using deception for years — setting up honeypots to see how defenders respond. Now the tables are turned. So what is the typical deployment model? Is it software-based, or do you need dedicated hardware? Lucas: Most modern deception platforms are software-based and deploy as virtual appliances or agents. You can spin up a decoy server in your VMware environment in minutes. Some vendors like Illusive Networks, Attivo Networks — now part of SentinelOne — and TrapX offer full deception platforms. There is also an open-source tool called KFSensor that smaller shops use. For the bank, they deployed about 50 decoy systems across three data centers, plus hundreds of breadcrumbs and thousands of honeytokens. Luna: That sounds like a lot of management. Do you need a dedicated engineer to maintain this? Lucas: It depends on the size. For the bank, one security analyst spent about 20 percent of their time on deception maintenance after the initial setup. Most platforms automate lure rotation and cleanup. For example, if an attacker deletes a breadcrumb file, the system automatically recreates it in a slightly different location. The key is to keep the environment looking alive so the attacker does not realize it is fake. Luna: Let me ask about legal and ethical concerns. If you deploy a honeypot that contains fake data that looks like real customer information, could that cause issues if an attacker exfiltrates it and it gets leaked? Lucas: That is a critical point. You must ensure that decoy data does not contain any real personally identifiable information. The bank used synthetic data generators to create fake names, account numbers, and transaction records that are realistic but entirely fictional. From a legal standpoint, it is no different from creating a fake user account for testing. However, some jurisdictions have laws around entrapment or privacy, so you should involve legal counsel. But in practice, deception is a defensive measure, not a trap to lure attackers into committing crimes they otherwise would not. It is just a detection mechanism. Luna: That makes sense. So the deception layer sits passively until an attacker interacts with it. It does not actively probe or entice them beyond what already exists. So it is like putting a fake Rolex in your car — it might get stolen, but you are not inviting the thief to break in. Lucas: Perfect analogy. And the data from these platforms feeds into a broader threat intelligence program. For instance, after the bank's incident, they shared the attacker's indicators of compromise with an information sharing and analysis center in their sector. That allowed other financial institutions to block the same Cobalt Strike beacon before it ever reached their networks. Luna: So deception has a community benefit too. I am starting to see why adoption is growing. What about cloud environments? Can you deploy deception in AWS or Azure? Lucas: Absolutely. In fact, cloud deception is a rapidly growing use case because cloud environments are more dynamic. You can create decoy S3 buckets with fake keys, fake Lambda functions, or fake RDS instances. When an attacker scans for open ports or enumerates buckets, they find these decoys. The detection is nearly instant. A company called Cymmetria — now part of Cybereason — demonstrated a cloud deception deployment that detected an AWS credential compromise within 30 seconds of the attacker using the key. Luna: Thirty seconds. That is insane. Compare that to the typical time to detect a cloud breach, which I think is still measured in days. So it seems like deception is especially powerful in hybrid environments where the attack surface is large and complex. Lucas: Exactly. And it is becoming more accessible. Several vendors now offer deception as a service, where you pay a monthly subscription and they manage the decoys. That lowers the barrier for mid-market companies. I spoke to a regional hospital chain — about 2,000 employees — that uses a managed deception service. They have no dedicated security team; their IT manager handles it. The service detected a ransomware reconnaissance attempt within hours and blocked it before encryption. Luna: That is the kind of story that makes CISOs pay attention. So what would you say to a CISO who is on the fence about adding deception to their stack? What is the one reason to prioritize it? Lucas: I would say this: deception is the closest thing to a cheat code for early detection. It does not rely on signatures, behavioral baselines, or threat feeds. It relies on the simple fact that no legitimate user has any reason to interact with a decoy. That epistemic guarantee is powerful. Every other detection method has blind spots. Deception fills the biggest blind spot — the period between initial access and lateral movement. If you can catch an attacker in that window, you prevent the breach. Luna: And it makes your existing investments in EDR and SIEM more effective because it gives them better data to work with. I think we are going to see a lot more of this. Lucas, any final thoughts on where this is heading? Lucas: I think we will see deception embedded into the network itself — switches and routers that can serve up fake ARP responses or fake DNS entries. Some vendors are already experimenting with ai generated lures that adapt to the attacker's behavior in real time. Imagine a decoy that, when probed, generates a fake database schema that looks exactly like your real one, but any data returned is synthetic. That is the next frontier. For now, the basic breadcrumbs and honeytokens are a no-brainer for any organization that wants to move from reactive to proactive defense. Luna: I am convinced. And I think our listeners have a lot to think about. Thanks for breaking it down, Lucas. Lucas: Thanks, Luna. And to our listeners, if you want to see how deception might fit your environment, start small. Deploy a few honeytokens in a non-critical network segment. You might be surprised what you catch.