After the Alert: How Much Forensic Evidence Does Your Honeypot Actually Give You?

TL;DR

• An alert proves an intrusion happened. It rarely proves anything else.
• The gap shows up the moment someone has to write the incident report and answer: what did they do. Not just: did something happen.
• Four things determine whether your decoy is useful after the alert: session detail, credential capture, retention period, and export format.
• Retention is the most commonly overlooked. Intrusions are frequently discovered months after they begin; a decoy with 90-day logs cannot reconstruct a breach that started in March.
• Test this before you buy. Deploy a decoy, attack it yourself, and read what comes back.

Deception technology is sold on one promise: you find out early. That promise is real, and it is why decoys have earned their place in mid-sized security stacks.

But early warning is where the product's job ends and yours begins. At 03:40 the alert is useful. At 09:00, in a room with your CISO, your insurer's questionnaire and possibly a regulator's notification deadline, the alert alone is close to useless. What matters then is the evidence sitting behind it.

The four questions your incident report has to answer

Every serious post-incident write-up answers the same four:

• How did they get in?
• What did they do?
• What were they after?
• Are they still here?

A decoy that records only a source IP, a timestamp and a port answers question one partially and the rest not at all. If the source is an internal host, you have learned that host is compromised — genuinely valuable, and the reason deception works. But you have learned nothing about intent, method or scope.

Thin evidence versus rich evidence

A thin detection record reads roughly like this:

10.14.2.71 → decoy-fs01, SSH (22), 03:41:07

A rich one carries the session itself: the usernames and passwords attempted and in what order, the commands issued after connection, the files requested, the protocol quirks and timing that fingerprint the tooling.

That difference changes the next 48 hours. Credentials attempted against a decoy can be checked against your real directory — and if they match, you have just learned your directory has leaked and which account to reset first. Command sequences become the search pattern you hunt with across the rest of the estate. Timing and tooling signatures separate an opportunistic scanner from someone who knows what they are looking for.

Without that material you are hunting for an IP address, which any competent intruder has already changed.

Retention: the forgotten half

Depth is worthless if the data has expired.

Intrusions are routinely discovered long after they begin; dwell times of many months remain common. When you finally detect an attacker in October, the questions are about what happened in June. A platform retaining 90 days of detections cannot answer them.

This is a specification to check on the pricing page rather than a feature to discuss in a demo. SecurityHive retains detection data for one year on Core and two years on Advanced, which covers realistic dwell time rather than a comfortable quarter.

Can you get the evidence out?

Three practical tests, all easy to overlook:

• Export. Can you hand a forensic investigator a file they can work with, or only a screenshot of a dashboard?
• Integration. Can detections stream into your SIEM in near real time? Webhooks to custom HTTPS endpoints are the minimum bar.
• Independence. If you cancel the contract, what happens to the historical record?

Test it before you buy

The single most useful thing you can do during an evaluation takes twenty minutes:

• Deploy one decoy in a test segment.
• Attack it yourself — port scan it, attempt SSH logins with three invented credentials, browse its file shares.
• Open the detection record and ask whether you could write an incident report from it.

If the answer is no, you have learned that in twenty minutes rather than during your first real breach. This is also the fastest way to compare two products honestly, and it is why the availability of a self-service trial is a substantive criterion rather than a convenience.

Start free with SecurityHive — deploy a decoy, trigger it deliberately, and read what comes back.

Frequently asked questions

What data should a honeypot capture for forensic use?

At minimum: source and destination addresses, precise timestamps, the protocol and service engaged, and the full session content where the protocol allows — credentials attempted, commands issued, files requested, and the sequence of all of it. Sequence matters as much as content; it is what identifies tooling and intent.

How long should honeypot detection data be retained?

Long enough to cover realistic dwell time, which is measured in months rather than weeks. One year is a sensible floor; two years is safer for regulated sectors and for organisations whose insurance or contractual obligations require evidence after the fact.

Is honeypot data admissible as evidence?

That depends entirely on jurisdiction and on how the data was handled — integrity, timestamping and chain of custody all matter, and none of it is decided by the vendor. Treat decoy output as investigative material that supports an incident response process, and involve legal counsel early if you anticipate proceedings.

Does capturing more detail create privacy concerns?

Less than you might expect. A decoy has no legitimate users, so anything it records is by definition unauthorised activity rather than employee behaviour. That said, source IP addresses can be personal data under GDPR, so document your legal basis, your retention period, and where the data is held — which is also why the hosting jurisdiction of your platform is worth checking.