6 mistakes that make a honeypot useless

Installing a honeypot on your network is a very effective way to detect attacks and respond quickly. However, it must be deployed and configured correctly. A poorly designed honeypot will attract no one, or worse, become a gateway to your real network.

Here are the 6 most common mistakes to avoid so that your honeypot truly fulfills its purpose.

Error 1: Over-isolating your honeypot from the rest of the network

Paradoxically, this is one of the most frequent mistakes: isolating your honeypot too much. A machine placed alone, on a separate segment, without any traffic around it, is unlikely to generate many alerts.

In most cases, an attacker won't even see the machine. And if they do stumble upon it, the fact that it's an isolated machine with no traffic will immediately tell them it's a honeypot.

Therefore, the machine must be placed on the same network as your live systems, integrated into Active Directory using a machine account with strictly limited privileges, assigned IP addresses consistent with the rest of your network, and able to communicate with other machines. The goal is to make the honeypot legitimate and fully integrated into your network, without turning it into a foothold for the attacker.

Error 2: Too easily identifiable

A poorly configured honeypot can be quickly identified by an attacker: inconsistent fake banners, a suspicious machine name, an empty SMB share, etc. It is all these small configurations that make your honeypot look realistic and therefore capable of attracting attackers to it.

Here is an example of a misconfigured honeypot, and therefore easily detectable:

The inconsistency of the services offered is noticeable, a mix of Linux and Windows components that makes no sense on the same machine.

Here is a properly configured honeypot:

Here the illusion is far more convincing, and stands a real chance of deceiving an attacker.

Error 3: Incorrectly configured monitoring and alerts

A honeypot is only valuable if the interactions it records are actively monitored. Without centralized logs (SIEM or equivalent) and properly calibrated alerts, traces of intrusion can go completely unnoticed, or conversely, overwhelm the team with false positives.

Error 4: No breadcrumbs

A honeypot left to its own devices remains passive. To make it effective, it's not enough to simply deploy it and wait: you must actively direct attackers towards it. This is where breadcrumbs come in.

These are small artifacts scattered across your network (scripts, command history, text files, etc.) whose purpose is to lure a malicious actor to the honeypot, usually using fake credentials associated with the IP address of the decoy machine. An attacker who has already compromised a machine on the network and stumbles upon these clues will naturally be tempted to use them, leading them directly to the honeypot.

Without breadcrumbs, the honeypot relies solely on the luck of an attacker discovering it on their own. These artifacts are therefore essential to significantly increase its effectiveness.

Error 5: Choosing the wrong type of honeypot

There are different types of honeypots, classified according to their level of interaction, and not all are suitable for every use.

High-interaction honeypots, such as T-Pot, emulate a system in far greater depth, with real services and sometimes even a real operating system. They are primarily used in research settings to observe and analyze attacker behavior in detail. This depth comes at a cost: they require more resources, more configuration time, and stricter containment measures.

Low/medium interaction honeypots, such as Trapster or Thinkst Canary, emulate only a few services in a lighter way. They are largely sufficient, and even preferable, in the context of protecting an information system, where the main objective is to quickly detect an intrusion and trigger an alert, rather than to study the attacker's methods in depth.

Deploying a high-interaction honeypot for simple detection purposes is a waste of resources and adds unnecessary complexity. Conversely, using a low-interaction honeypot in an advanced research context will severely limit the quality of the data collected. Therefore, the choice of honeypot type should always be driven by the specific objective.

Error 6: Lack of a response plan

Detecting an attack is useless if no one knows what to do next. Without a clear procedure (who is alerted, what actions to take, how to analyze the collected data), the honeypot becomes a mere data collection tool with no operational value.

For step-by-step implementation, see our guide to deploying a honeypot in production.

In summary

An effective honeypot depends on all the aspects mentioned above. It is not enough to deploy it on a network and then wait: it must be made credible, its integration with the rest of the network perfected, it must be made visible in the right places, and it must be accompanied by active monitoring, in order to actually trap an attacker.