Catching the intrusion
on first contact.

01Abstract

Detection that has no good reason to be wrong.

02The detection gap

Why intrusions still go unseen for days.

Prevention and detection have improved for a decade, yet attackers still operate inside networks long enough to matter. Two structural problems explain why.

Dwell time is still measured in days, not seconds

An intrusion is only as bad as the time the attacker spends undetected. Mandiant's annual M-Trends reporting has tracked global median dwell time falling sharply, from well over a year a decade ago to roughly ten days in recent reports^[1]. Ten days is progress, and it is also an eternity: ample time to enumerate a directory, move laterally, and stage data. Worse, a median hides the tail; many intrusions, especially those that abuse valid credentials and built-in tools, are found only when something detonates or an outside party makes the call.

Prevention hunts for known-bad, and the unknown gets through

Signature engines and most behavioural models are trained on what attacks have looked like. Novel tooling, living-off-the-land technique, and the use of stolen but valid credentials all look enough like normal administration to pass. Verizon's Data Breach Investigations Report has repeatedly placed the use of stolen credentials among the most common ways into an organisation^[2]. A logon with a real password is not, on its face, malicious, which is exactly the problem: the strongest signal a prevention stack has is often a weak one.

And the noise has its own cost

The price of guessing is false positives. A detection layer that fires on probability produces a stream of maybes, and the scarce resource in any security team is the attention to triage them. Alert fatigue is not a soft problem; it is how real alerts get closed as noise. A method that is wrong far less often is not just more pleasant, it changes what a small team can cover.

03The deception thesis

A decoy has no legitimate reason to be touched.

Deception sidesteps the hard question. Instead of deciding whether observed activity is malicious, it places objects in the environment whose only purpose is to be touched by the wrong person. A decoy host, service, credential or document does no work for the business. No user, script or scanner that belongs there has any reason to interact with it.

From that single property follows the whole value proposition. If nothing legitimate touches a decoy, then any interaction with one is, by construction, anomalous. There is no model to train, no baseline to learn, no threshold to tune. The decoy converts a hard classification problem into a trivial one, and in doing so collapses the false-positive rate toward zero. An alert is a footstep, not a guess.

This is an old idea, honeypots and honeytokens predate modern EDR^[3], but it has historically lived in research networks and one-off traps. What has changed is making it operational: decoys faithful enough to survive an attacker's inspection, deployable at fleet scale across many networks, and wired into the places a defender already watches.

Where it sits relative to prevention

Deception does not replace firewalls, patching or EDR; it complements them. Prevention reduces the number of attackers who get in. Deception assumes some will anyway and makes their first move expensive, because the move that helps them, looking around, is the move that gives them away. The two layers fail in different ways, which is the point of running both.

04Threat model

Where on the kill chain a decoy fires.

An intruder who has gained a foothold has to learn the network before they can act on it. That learning phase, reconnaissance, discovery and lateral movement, is unavoidable, and it is where deception is strongest. On the Lockheed Martin intrusion kill chain^[4], decoys fire in the stages before actions on objectives, while the attacker is still mapping and reaching, not after the data is gone.

Concretely, the table below maps common attacker behaviour, in MITRE ATT&CK terms^[5], to the decoy that catches it.

One intrusion, step by step

An attacker lands on a workstation with phished credentials. Their first instinct is to look around: they sweep the local segment for live hosts and services. The sweep reaches a Klaxon sensor wearing the skin of a network appliance, and the alert fires before they have touched a single real system. Curious, they open the appliance's login page, which is a faithful clone, and try the credentials they have. That second contact is captured too, with the source, the username and the exact moment. They never reach a real asset; the defender's response has already started. The attacker's earliest, unavoidable move is the one that gives them away.

05Architecture

One console, a fleet of hardened sensors.

Klaxon is a single console that drives many sensors. The console is the brain and the system of record; the sensors are the decoys on the wire. They are joined by an encrypted tunnel so a sensor can sit on a segment the console can never reach directly, including networks behind NAT or with no inbound path at all.

The pieces

• Console. Enrolment, sensor configuration, the alert pipeline and the audit record. In the licensed edition it is multi-tenant, with each organisation isolated and an audited support hand-off so an operator can act for a client as themselves.
• Sensor nodes. A small board, virtual machine or container on a segment. Each runs the decoys and watches for contact. Nodes hold no standing secrets worth stealing and expose no general-purpose access (see Sensor security).
• The tunnel. Sensors enrol outbound over WireGuard, so the console manages them without an inbound route into the customer network. A sensor can live anywhere it can reach the console once.
• The alert path. Detections leave over DNS, webhook, push and, in the licensed edition, SIEM and email, including out of segments where ordinary egress is blocked.

06Detection mechanisms

How a decoy stays convincing, and how it tells you.

A decoy only works if an attacker cannot tell it from the real thing, and only matters if its detection reaches you. Four mechanisms carry most of the weight.

Clone over the wire

Rather than ship generic templates, a sensor reproduces a chosen real target as seen on the network: the login page of an appliance, the service banners, the certificate posture, down to the genuine response on a wrong password. Fidelity is the whole game. An attacker probing the decoy sees what they expect to see, which is why the interaction happens at all. Port-faithful services and matching TLS remove the cheap tells that give a generic honeypot away.

Services that answer

Beyond a login page, sensors stand up decoy services, SSH, SMB, HTTP, LDAP, RDP, databases and industrial protocols, that respond like the genuine article. A connection or authentication attempt against any of them is contact, and contact is the alert. The service does not need to be exploited; reaching for it is enough.

Credential and directory tripwires

Planted secrets, an API key in a config file, a password in a script, a saved session, are designed to be found and tried. Because the credentials are known to the system, their use anywhere lights up immediately. The directory variant goes further: decoy accounts are placed in a real directory and locked to a single sensor, so any attempt to use them, in particular a Kerberos service-ticket request for a decoy account (Kerberoasting, T1558.003), is caught at request time. The attacker harvests bait and reveals themselves the moment they use it.

The egress-resistant alert channel

The hardest place to get an alert out of is the place that most needs one: a segmented or air-gapped network with no outbound HTTP. Klaxon encodes a detection into DNS resolution, the one protocol such networks almost always still forward, so the alert travels out as ordinary name lookups along the path the network already permits. It is a one-way notification channel, not a tunnel: it carries the fact of a detection outward without opening an inbound hole or a route an attacker could ride.

DNS itself is plaintext, but the detection it carries is not exposed by it. The payload is sealed with authenticated encryption (AES-256-GCM) under a key unique to your console before it is encoded into the query name, so the channel carries confidentiality and integrity at once. Anyone watching the resolver path sees only an opaque lookup in a zone, never the source, the sensor or the credentials. And because every query carries an authentication tag, a console accepts only payloads that verify under its own key: a forged or altered lookup is rejected, so the unencrypted transport cannot be used to inject a fake alert or tamper with a real one.

07On false positives

What "zero by design" means, and where it bends.

The claim that a decoy produces no false positives is a statement about design, not a measurement. It holds because of the invariant: a decoy has no production role, so no legitimate workflow has a reason to reach it. Remove the legitimate reasons and you remove the false positives. This is a categorically different guarantee from a tuned threshold.

Honesty requires naming the boundary conditions, the cases where something benign touches a decoy:

• Authorised scanners. A vulnerability scanner or asset-discovery tool that sweeps the whole range will touch decoys too. This is real, expected, and handled by scoping: exclude sanctioned scanner sources, or treat their contact as the known event it is.
• Monitoring and management. A misconfigured monitoring probe pointed at a decoy address will trip it. The fix is placement and an allowlist, not a model retrain.
• Human error. An administrator who fat-fingers a decoy's address will set it off. That alert is arguably working as intended; it is rare, attributable and quickly dismissed.

The distinction that matters: these are enumerable, explainable events tied to known sources, not a statistical drizzle of maybes. You suppress them by naming them once, and what remains is signal. A probabilistic detector cannot make the same promise, because its noise is not a list, it is a rate.

08Sensor security

A trap that cannot become a foothold.

A sensor sits inside a customer network and invites attackers to interact with it. That makes its own security non-negotiable: a decoy that could be turned into a pivot would be worse than no decoy at all. The design assumes the sensor itself is a target.

• No inbound trust. Sensors connect outbound over WireGuard. There is no listening management port for an attacker on the segment to reach, and the console drives the node, not the reverse.
• Least privilege on the node. The management path is restricted to a validated set of operations rather than general shell or container access, and the account it runs under does not carry broad host privileges. A compromised console cannot turn into arbitrary command execution on the node.
• Signed, anti-rollback updates. The node agent accepts only signed updates and refuses to downgrade to an older, potentially weaker build.
• A trustworthy supply chain. The console ships as a single self-extracting installer carrying a signed manifest, verified before anything unpacks. Installed code is checked against a signed manifest at startup, and the licensing logic is compiled to a native module rather than left as editable source.
• Minimal standing value. Sensors hold no production secrets worth stealing. What an attacker finds if they reach one is more decoy, not the keys to the network.

09Deployment

Placement is the program.

Deception only catches an attacker who touches a decoy, so where the decoys sit is the whole operational question. The goal is to make the paths an intruder must walk run through a tripwire.

Density and placement

A handful of well-placed decoys beats a sprawl of obvious ones. Put sensors on the segments an attacker has to cross, beside the assets they will look for: a decoy file server next to the real ones, a decoy appliance on the management VLAN, honey-accounts in the directory they will enumerate. Coverage is a function of placement against the routes that matter, not raw count.

Time to armed, and tuning

A sensor goes from enrolled to live in minutes, and because the detection logic carries no thresholds, there is little to tune after. Operational work is scoping known-benign sources (the sanctioned scanner, the monitoring probe) once, then leaving the traps silent until they matter.

Into the existing SOC

A Klaxon detection is meant to land where the team already works. Alerts route to webhooks and push for small teams, and, in the licensed edition, forward to a SIEM as CEF over syslog and to email per severity. For a managed provider, every client runs in one console with per-tenant isolation, so one team operates many networks without cross-contamination.

10Editions and licensing

One engine, two ways to run it.

The detection core is identical in both editions; what differs is scale and operations, never fidelity. Community is the full engine, self-hosted and free, sized for a small fixed number of sensors on one console. Enterprise adds the distributed fleet, multi-tenancy and enterprise alert routing a provider runs a practice on.

A clean open-core boundary

The line is not a runtime flag. A Community build ships without the Enterprise code on disk: the fleet, tenancy and integration modules are physically absent, so there is nothing to unlock and nothing to leak. Enterprise is activated by a signed license, a compact signed token verified locally against a built-in public key, so the console needs no call home to know what it is entitled to. Licenses carry an expiry and an explicit feature set, are node-locked to one console by a stable, non-secret machine fingerprint, and are priced per sensor: the token encodes the sensor entitlement, so growth is a number on the license, not a migration. Activation is self-service, read the install fingerprint, paste in the license, and it takes effect without a restart.

Running a homelab and wanting a specific Enterprise feature? Reach out with how you would use Klaxon in your lab; hobbyist licensing is handled case by case, happily.

11Limitations

What deception does not do.

A method is only trustworthy if it states its limits. Deception is a powerful detection layer, not a complete security program, and it has real edges.

• It only catches contact. An attacker who reaches their objective without ever touching a decoy is not seen by deception. Coverage is bounded by placement and density, which is why deployment, not deployment count, is the program.
• It is a complement, not a replacement. Deception detects; it does not patch, segment or block. It assumes prevention is also in place and is most valuable as the layer that catches what prevention missed.
• Fidelity is an arms race. A careful attacker may try to fingerprint decoys. Cloning real targets on the wire raises that bar substantially, but no decoy is perfectly indistinguishable forever, and the work to keep them convincing is ongoing.
• It detects, then it is your move. Klaxon raises a high-fidelity alert at the first footstep; containment and response are the defender's, ideally fast, because the early warning is what buys the time.

Stated plainly: deception gives you a trustworthy alert early, on the assumption an attacker will look around before they act. It does not promise to see an attacker who never does.

12Conclusion

Make the first move the tell.

Detection that guesses will always trade misses against noise. Deception refuses the trade by changing the question: not "is this malicious?" but "did someone touch what nothing legitimate should?" That property, a decoy with no production purpose, is what makes the alert trustworthy at three in the morning, and what lets a small team cover a large network. Klaxon's contribution is to make that property operational: decoys faithful enough to be touched, hardened so they cannot be turned, distributed across networks the console cannot otherwise reach, and wired into the places a defender already watches. An intruder's first, unavoidable move, looking around, is the move that gives them away.

13References

Sources.

1. Mandiant. M-Trends Report (annual). Global median dwell-time metrics. mandiant.com.
2. Verizon. Data Breach Investigations Report (DBIR), annual. verizon.com/dbir.
3. Spitzner, L. Honeypots: Tracking Hackers. Addison-Wesley, 2002.
4. Hutchins, E. M., Cloppert, M. J., Amin, R. M. Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains. Lockheed Martin, 2011.
5. MITRE. ATT&CK Knowledge Base. attack.mitre.org.