The historic risk of honeypots comes from one specific fact: the decoy sits inside your network. We put it somewhere else.
It's the question every IT manager asks, and it's a fair one: a honeypot is, by definition, a system that someone has to be able to attack. In most products that system sits in your network, and the risk that follows is real. In ours, the decoy can't open connections toward your network. Here you'll find why, and above all how to check it, with us and with any other vendor.
In brief
- The historic risk of honeypots is that a compromised decoy becomes a foothold inside the network. It comes from the decoy living in your network.
- They bring the decoy into your network. We bring the threat into ours, and the road runs one way only.
- That's why the decoy can't open connections toward your network. You don't have to take our word for it: these are things you can verify, and below you'll find how.
The historic risk
A honeypot, or decoy, is a system that no legitimate user has any reason to touch: when someone touches it, that's a signal (we explain why it works in Honeypots are much more effective at Detecting Threats than you might think). The more realistic the decoy, the more convincing it is, and the more deeply a threat can exploit it. Evans (2002) sums it up this way: realistic decoys are usually real systems, and they carry a high level of risk for the organization hosting them. The same picture emerges from Pickett (2003), who draws on Spitzner's work. The risks they describe, for a decoy hosted in the network of whoever uses it, are these:
- Foothold. A decoy with a real operating system, if deeply compromised, can serve a threat as a base to move into the rest of the network or toward third parties. It's the most cited risk.
- Its own vulnerabilities. An emulated service can have flaws in its implementation; a real system has those of its operating system if it isn't kept up to date.
- Attention and retaliation. Evans observes that a threat may focus its attention on the block of addresses where the decoy sits, looking for other interesting systems, and that whoever realizes they've wasted their time can take revenge on the organization, up to a denial of service attack. He also recalls that, after the publication of their research, the Honeynet Project's systems suffered severe, coordinated attacks.
- Decoy recognized and bypassed. If the threat realizes it's a decoy, it avoids it, and the decoy detects nothing.
The literature adds a liability theme: if the decoy is used to hit third parties, the organization that installed it may have to answer for it. It's a question to take up with a lawyer.
Recognizability has been measured, too. A University of Cambridge study (Vetterl and Clayton, 2018) showed that low- and medium-interaction honeypots built with commonly used libraries can be told apart from real systems with a single packet, and with internet-scale scans it found thousands of them, on protocols such as SSH, Telnet and HTTP. The same study found that about 27% of the SSH honeypots hadn't been updated in 31 months: a decoy needs to be kept up to date like any other system.
The topic is recognized by standards as well: NIST SP 800-53 includes, in the family of system and communications protection controls, control SC-26 (Decoys), dedicated to decoys.
Why, for us, it isn't a question of containment
Containment is the usual vendor answer: isolation, segmentation, hardening around a decoy that stays in your network. It usually holds, but it's a control, and you maintain it.
With our architecture, the decoy isn't in your network. It runs in our cloud, and all that's in your network is the device that makes it reachable. Traffic is carried into our infrastructure before anything needs to be contained.
Containment happens on our side, on infrastructure built for this alone. The hypervisors that host the decoys are not clustered and are treated as untrusted by the rest of the platform, which is designed to absorb their compromise. If containment fails at another vendor, the incident is the customer's. With us, the incident is ours.
Five questions to ask any vendor, and our answers
They're the same five as in our deception and honeypot guide, here with our answers and sources. The guide's rule applies: not every question needs a positive answer. What counts is consistency. Accept honest limits and reject inconsistencies, because your security is at stake.
1. Do you update the decoys? How do updates arrive?
The easy answer: "We don't update them, they have to be vulnerable."
Why it matters. A decoy with outdated software is spotted at once: the University of Cambridge study (Vetterl and Clayton, 2018) found that about 27% of SSH honeypots hadn't been updated in 31 months. But updating a decoy that sits in your network can open a road into your network.
What to listen for: who chooses the updates and which components are deliberately left exposed.
Our answer. The decoys are built, updated and replaced by us, in our cloud. In your network there's only the device that makes them reachable. We don't manage it remotely and we can't send it updates that change its behavior: it's immutable, with a read-only filesystem.
2. How do you contain a compromised decoy?
The easy answer: "It's isolated."
Why it matters. Containment decides whether the decoy is an advantage or a risk. Virtual machines, containers and non-interactive decoys carry very different risks, and the most cited risk in the literature (Evans, Pickett) is that the compromised decoy becomes a foothold.
What to listen for: what isolates the decoy, where containment happens and what happens if it fails.
Our answer. The decoy runs in our cloud. The device forwards traffic to the decoy and lets only the responses come back: any request that starts from the decoy is blocked. Containment happens on our side, on infrastructure built for this alone, and if it fails the incident is ours.
3. How effective is the decoy at holding the threat?
The easy answer: "It's fully interactive."
Why it matters. A few emulated services detect a first contact, but they're quickly recognized: low- and medium-interaction honeypots based on common libraries can be told apart from a real system with a single packet. You need a complete, coherent system that holds up even after the threat is in.
What to listen for: a concrete demonstration of what someone finds when they get a shell on the decoy.
Our answer. The decoy is a real system, not an emulated service, so it doesn't have the typical fingerprints of emulation. We don't say it's invisible.
4. What access do you have to my company, and what supply chain risk do you bring?
The easy answer: "None, the decoys connect outward."
Why it matters. Connecting outward isn't the same as having no access: every component that downloads updates is a possible way in.
What to listen for: who can send code to which systems, in which direction connections open and what you can verify on your side.
Our answer. We have no access to the device you install in your network.
5. After a compromise, how is the decoy restored?
The easy answer: "We reinstall it."
Why it matters. The decoy is made to be compromised, and the threat might stay in it. Restoration shouldn't require access to your network, and any credential the decoy uses to communicate with the vendor should be considered potentially stolen.
What to listen for: how a clean image arrives, how long it takes and which credentials are rotated.
Our answer. Destroying and recreating a decoy is an ordinary operation of our platform: it happens in our cloud and requires no intervention in your network.
The guide also flags two warning signs to look for: command responses generated by artificial intelligence, and multiple addresses for the same decoy. You'll find them at /deception.
For the details of the mechanism we won't repeat what's already explained elsewhere: the Hoxey Security Model describes the device and the isolation, the Hoxey System Architecture Overview the platform's components, and What's a Honeypot - and how we improved the technology tells how the tunnel works.
Frequently asked questions
Can a honeypot be used to attack my network?
If the decoy sits inside your network and is deeply compromised, it can become a foothold: it's the historic risk of the category. With our architecture the decoy isn't in your network, and any request that starts from the decoy is blocked by the device.
What happens if the decoy is compromised?
What the decoy exists for: you get the signal that there's a threat. The decoy is in our infrastructure, where containment is our job, and it can't open connections toward your network.
Does a honeypot attract more threats to my company?
The literature flags the risk that a threat concentrates its attention on the decoy's block of addresses or reacts when it realizes it has wasted its time. That's why it matters where and how the decoy is placed, and that it's managed.
Can a threat recognize a honeypot?
It depends on how it's built. Low- and medium-interaction honeypots based on common libraries can be recognized with a single packet, as the research shows. A decoy that is a real system doesn't have those fingerprints, but no decoy is invisible by definition.
Does a honeypot replace antivirus or EDR?
No, it adds to them. The tools you already use keep doing their job: antivirus and EDR are necessary, but on their own they aren't enough. The decoy covers what those tools can't see, namely the presence of a threat already inside the network, the topic of Mighty Walls. No Alarm. To see how a breach that has already happened shows up, read How to tell if your company network has been breached.
Sources: Evans, Honeypots - Weighing up the Costs and Benefits (GIAC, 28 October 2002); Pickett, A guide to the honeypot concept (GIAC, 2003); Vetterl and Clayton, Bitter Harvest: Systematically Fingerprinting Low- and Medium-interaction Honeypots at Internet Scale (USENIX WOOT, 2018); NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations.