haineypot: The Honeypot That Lies Like a Tired Linux Box

Google Research's high-interaction trap does more than fake a login prompt. It adds human-looking delay, captures every keystroke, and turns an intrusion into replayable evidence.

8 min read · google-research/haineypot

An attacker sits at a terminal inside a glass box while hidden mechanical arms and thin signal lines route the keystrokes to a researcher desk in the background. The image explains the article's core idea: a honeypot that looks ordinary to the intruder but stays fully instrumented for analysis. — A convincing shell is useful only if it keeps the session observable.

Key Takeaways

haineypot treats timing as part of the deception, not as an implementation detail.
Its value comes from letting an attacker spend time inside a believable shell while the session is captured at terminal fidelity.
The architecture separates live execution from logging and replay, which raises both the intelligence payoff and the operational risk.
Compared with low-interaction honeypots, the project is an argument for depth over convenience when the goal is serious observation.

The trap starts with time

Most honeypots are judged on how much they impersonate a service. haineypot is more interesting because it treats hesitation as a feature. If a login prompt answers too quickly, or a shell behaves like a toy, a skilled attacker notices. This project is trying to pass a harder test: can it feel like a tired Linux box long enough to keep the intruder in the room?

The repository reads like a Google Research prototype, not a productized security appliance. That matters. Its goal is not polished administration or broad deployment. It is to explore how much realism you need before a decoy stops looking like a decoy.

A keyboard cable passes through a small clockwork governor that visibly delays one command before the response returns. The image shows how timing can make a fake shell feel like a real machine under load instead of a scripted demo. — A believable shell needs believable pauses.

What a high-interaction honeypot buys you

Low-interaction honeypots are good at catching noise. They answer with scripts, banners, and canned failures. High-interaction systems go further. They hand the attacker a working environment, then watch what happens when the intruder starts exploring, editing, and poking at the machine.

That choice changes the kind of intelligence you get. Instead of a connection timestamp, you can capture a session narrative: command order, waiting patterns, terminal habits, and the moment the attacker starts trusting the environment. The value is not just in seeing that someone connected. It is in seeing what they tried to become once they believed they had a shell.

Low-interaction honeypot	haineypot style high-interaction honeypot
Looks like a service, not a machine.	Feels like a live system with state, delay, and feedback.
Catches broad scans and shallow probes.	Keeps a skilled attacker engaged longer.
Captures connection data and scripted inputs.	Captures keystrokes, shell behavior, and terminal flow.
Safer and easier to run.	Richer, but harder to contain and maintain.
Best for volume and reach.	Best for depth and forensic value.

Inside the deception stack

The interesting part is the split between what the attacker sees and what the analyst gets. The repository structure points to a pipeline with protocol handlers, a deception engine, a sandbox manager, and logging built for replay. The attacker gets a shell. The researcher gets a transcript with timing attached.

The same session is lived once by the attacker and again by the analyst.

The latency controller is the subtle part. A shell that responds instantly feels synthetic. A shell that pauses, jitters, and occasionally lags feels like a machine under load. haineypot treats that delay as part of the interface, not a bug to eliminate.

A terminal session unwinds like film across a translucent spool while a researcher reviews commands, edits, and pauses. The image shows why terminal-level recording captures behavior, not just text. — A breach becomes evidence when you can replay the whole session.

The difference between emulation and observation

The trade-off becomes obvious when you compare the two approaches directly. Emulation is cheaper, safer, and easier to maintain. Observation is richer, but it asks for more realism, more containment, and more discipline. haineypot sits on the hard side of that line on purpose.

That is why the project feels less like a honeypot demo and more like an argument: if you want better intelligence, stop thinking of the decoy as a banner and start thinking of it as an instrumented environment. A fake service can catch attention. A believable machine can hold it.

Why the project matters even as a prototype

As a prototype, haineypot is compelling because it reframes the job. The goal is not just to catch scanners. It is to hold a convincing conversation long enough to learn something worth keeping.

That is a different security posture. It is active defense through realism, a glass box that wins by being believable. The project suggests that the most useful honeypot may not be the one that looks perfect. It may be the one that behaves just badly enough to feel alive.