Why I started thinking about honeypots
The first time I ran a port scan, I treated every open port as a target. I did not ask whether the service was real. I just tried to connect. That changed when I found a service that responded to every request with a perfect answer. It was too perfect. I was talking to a honeypot, and I had already revealed part of my workflow.
This post is my personal study note on honeypot detection. I am writing it because deception is becoming a common part of network defense. A honeypot looks like a vulnerable service, but its real purpose is to capture attacker behavior. Recognizing the trap is an operational skill, not a party trick.
What a honeypot is trying to do
A honeypot is a decoy. It is placed in the network or on the internet to attract attackers. When an attacker interacts with it, the defender learns about the tools, the techniques, and the indicators of compromise.
The honeypot can be simple or complex. A simple honeypot might emulate a single service and return a fixed banner. A complex honeypot might run a full operating system with realistic services. The more realistic the honeypot, the harder it is to detect.
The goal of detection is to avoid wasting time and exposing my tools. If I send a real exploit to a honeypot, I have revealed my capabilities to the defender. If I use a real credential, I have exposed a credential that may be valid elsewhere.
Port and banner anomalies
The first signal is an unusual port combination. Real networks tend to have services that make sense. A web server might listen on port 80 and 443. A database might listen on 3306 or 5432. A host that listens on every common port with a different service may be a honeypot.
The banner is another signal. A service banner that is too old, too clean, or too generic can be suspicious. Real services accumulate configuration changes, error messages, and version quirks. An emulator may return the same clean banner for every connection.
I also look at the service version. If the version is from a very old release that no one runs anymore, the service may be simulated. If the version does not match the operating system or the surrounding services, something is off.
Response patterns
The response behavior is more reliable than the banner. I send a request that is normal for the service and compare it with a request that is unusual. A real service usually reacts differently to the two requests. A honeypot often returns a similar response to everything.
For example, I send an HTTP request to a service that should be SSH. A real SSH server would reject the HTTP request. A honeypot might return an SSH banner anyway or respond with a generic error. The inconsistency reveals the emulation.
The response time is another signal. Real services have variable response times based on the request, the load, and the network. A honeypot may respond with a fixed delay or an unusually fast answer. I repeat the same request and compare the times.
Interaction with the service
The interaction should be harmless. I do not want to trigger an alarm or expose a real credential. I use fake usernames, fake passwords, and generic commands. The goal is to see how the service responds, not to complete a real action.
If the service accepts a clearly fake login and returns success, it is probably an emulator. A real service would reject the fake credential and return an error. If the service returns the same success message for every command, it is definitely not a real application.
I also test the error handling. A real service has specific errors for invalid input, missing arguments, and bad authentication. A honeypot may return the same generic error for everything.
Look for the missing details
Real services are full of small details. They have version numbers that match the release date, configuration files that affect the behavior, and logs that show the history. A honeypot often lacks those details.
I ask questions that only a real service can answer. I request a file that exists on the service and compare it with a file that does not. I send a command that produces different output depending on the configuration. The responses reveal whether the service has a real state.
The filesystem and the process list are harder to check remotely, but the behavior gives hints. A service that cannot handle a simple state change is probably not running real code.
Ports that are too convenient
Honeypots are often placed on the ports that attackers scan first. Port 22, port 3389, port 8080, and port 6379 are common. A host that has an open database port and no other sign of a database server is suspicious.
The convenience is the trap. An attacker sees an open port and assumes it is a target. The honeypot is designed to be found. I slow down and check the surrounding evidence before I commit to the interaction.
The surrounding evidence includes the network, the hostname, the DNS records, and the other services on the same host. A host with one open port and no other network presence may be a decoy.
The value of the interaction
Even if I identify a honeypot, the interaction is not wasted. I record the fingerprint, the responses, and the behavior. The record helps me recognize the same honeypot in other environments.
The fingerprint can include the banner, the response headers, the error messages, and the timing. I compare the fingerprint with known honeypot projects. Many honeypots have recognizable defaults.
The operational value is that I avoid repeating the same mistake. If I know a network uses a particular honeypot, I can adjust my approach and avoid the decoy.
Avoiding the trap
The most important rule is not to expose real tools or credentials to a suspected honeypot. I use generic commands, fake credentials, and minimal tooling. The interaction should not reveal my real identity or my real capabilities.
I also keep the interaction short. The longer I stay, the more the defender learns. Once I have enough evidence to identify the service as a honeypot, I move on.
The engagement rules matter. Some engagements explicitly include deception and expect the red team to interact with it. Others require the team to avoid the honeypot. I check the rules before I decide how much interaction is appropriate.
Building a detection checklist
My checklist has a few simple items. First, note the port and the banner. Second, send a normal request and an unusual request. Third, compare the responses for consistency. Fourth, test the error handling. Fifth, look for state and configuration details. Sixth, record the fingerprint.
The checklist is not perfect. A well-built honeypot can pass all of these checks. The goal is not to guarantee detection. The goal is to increase the chance that I recognize a decoy before I reveal too much.
The network context
The context around the host is often more useful than the host itself. I look at the DNS records, the network range, and the other services on the same infrastructure. A host that appears in a range with no other live hosts may be a decoy.
I also look at how the host was discovered. If the host responds to every scan, it may be designed to attract scanners. A real service often has a specific response pattern that depends on the request.
The network context includes the response to the TCP handshake. Some honeypots respond instantly to every connection, while real services have a slight delay. The delay is not a reliable signal by itself, but it adds to the picture.
The hostname and the certificate can also reveal the deception. A certificate that is self-signed, uses a generic name, or matches a known honeypot project is a strong indicator.
Known honeypot patterns
Many honeypots are built from the same open source projects. The projects have default banners, default ports, and default behavior. Once I recognize the default, I can identify the honeypot even when the configuration has been changed slightly.
I keep a small reference of known honeypot fingerprints. The reference includes the banner text, the response headers, and the default ports. The reference is not perfect, but it speeds up the recognition.
The default behavior often includes a fixed response to common commands. A honeypot might return a fake version number for every command or accept a login that no real service would accept. The behavior is more reliable than the banner.
The fingerprint can also be found in the timing. A honeypot may respond in exactly the same amount of time for every request, while a real service varies. I repeat the same request and compare the timing.
Decoy credentials
The credentials that I use during the test are a risk. If I use a real password, the honeypot can capture it. The defender may then test the password against other systems.
I use decoy credentials for every interaction with a suspicious service. The decoy looks realistic, but it is not valid anywhere else. If the honeypot captures the decoy, no real system is exposed.
The decoy should be unique to the engagement. A password that is used in every test can be recognized by a defender who shares threat intelligence. I generate a random decoy for each interaction.
The same principle applies to the tools. I do not upload a real tool to a suspected honeypot. The tool itself can be analyzed and used to identify my methods.
When to interact
The decision to interact with a suspected honeypot depends on the engagement. In some exercises, the red team is expected to interact with the deception and learn from it. In others, the team should avoid the decoy to protect the operation.
I check the rules before I start. If the rules allow interaction, I use a low-risk method and keep the interaction short. If the rules require avoidance, I record the suspicion and move on.
The interaction is also a way to learn. A honeypot can teach me about the defender's monitoring. The response to my probe shows which actions trigger an alert. The lesson is useful for the rest of the engagement.
The risk is that the interaction reveals too much. I balance the learning against the exposure and stop when the value is gone.
One more thing to check
The honeypot might be part of a larger deception campaign. A single decoy service can be surrounded by decoy files, decoy credentials, and decoy network segments. I check whether the same fingerprint appears on other hosts in the range. If it does, the deception is not isolated to one port. The surrounding pattern helps me build a map of the traps and avoid the entire area. I also check whether the response changes after I interact with the service. A honeypot that adapts to the attacker is more dangerous than a static one.
Common mistakes I make
My biggest mistake is assuming that every open port is a real target. I now check the behavior before I send a real payload. My second mistake is using a real credential to test a login page. The credential may be captured by the honeypot. My third mistake is ignoring the surrounding network evidence.
The fourth mistake is spending too much time on the honeypot. Every minute spent on the decoy is a minute not spent on the real target. The fifth mistake is forgetting to record the fingerprint for future reference.
My quick checklist
- Note the port, the banner, and the surrounding network.
- Send a normal request and an unusual request.
- Compare the responses for consistency and realism.
- Test the error handling and the state changes.
- Use fake credentials and generic commands only.
- Keep the interaction short.
- Record the fingerprint for future recognition.
- Move on when the service looks like a decoy.
What I would do next time
Next time I want to spend more time on the surrounding evidence before I connect to a service. The network context often reveals the honeypot before the banner does. I also want to build a small reference of known honeypot fingerprints, because that is the fastest way to recognize a decoy. Honeypots are part of the modern attack surface. The question is not whether they exist. It is whether I can recognize them before I make a mistake.