Services that look worth attacking and are not real, a maze of plausible nothingness to hold an intruder in, and decoy credentials that raise the alarm when somebody uses them.
The intruder who matters is not the one setting off alarms. It is the one who already has valid credentials and looks like a member of staff.
Conventional defences answer the question “is anything unauthorised happening?” — and a quiet intruder using a stolen password is, to every system watching, authorised. That is why intrusions are routinely measured in months before discovery, and why the African Union’s headquarters transmitted data to Shanghai nightly for five years before one person happened to notice.
Labyrinth answers a different question: is anybody touching things that only an
intruder would touch? Nobody legitimate opens a file called
credentials-backup in a share they have no business in. Nobody legitimate
requests /.env from a web server. When somebody does, there is no
ambiguity to triage — which is why this is the highest-confidence signal in the tool
and why it produces almost no false alarms.
Each one is a service an attacker expects to find on a neglected internal machine.
An SSH host that holds a connection open indefinitely without ever completing the handshake. Cost to you: one socket. Cost to them: a stalled tool, often for hours — and their software identifies itself before anything else happens.
Every folder exists and every folder opens into more. The contents are the same on every visit, which matters: a decoy that renders differently each time is identified in two requests.
Credential files, configuration, database dumps, private keys. Each returns plausible, poisoned content and raises a high-confidence alert. No legitimate user requests any of them.
Each decoy carries a credential that alerts when it is used, naming which decoy it was taken from — so the signal arrives even if the file was copied off the machine entirely.
File-transfer and terminal logins that always succeed, slowly, recording every username and password tried. On a system with no real accounts, every credential sprayed at it is intelligence about the attacker.
Findings go to your own operations centre, not to a file on the host the intruder is standing on. A tripwire nobody hears is not a tripwire.
The question everybody asks, and three different things get called trapping. The answers are not the same, and the difference is worth being precise about.
A crawler is not held by a lock. It is held by arithmetic: every page it fetches yields more links than the one request it spent fetching it. Measured against this implementation, a sequential crawler spent 75.9 seconds to make 42 requests and reach a depth of three — and finished with 175 links still unexplored, a backlog growing by roughly four links for every request served. Responses also slow down the deeper they go, which reads as an overloaded internal server rather than a trap. A complete search is not slow. It is impossible, and the only exit is to give up.
Nothing here controls their machine, their process or their route out; they can disconnect whenever they choose. Building anything that tried to prevent that would mean acting on a machine that is usually a third party’s compromised equipment. Any supplier who tells you they can hold an intruder against their will is describing either a fantasy or a crime.
Place the deception host on a network segment with no route to anything real. Then the trap is not a claim about software, it is a fact about your network: what they are working on leads nowhere, and every hour spent on it is an hour not spent on a system that matters. That is what the time actually buys — a window in which you know and they do not.
Not a log file. A reconstruction, per intruder, of how far they got — where each stage is the furthest point there is actual evidence for.
Connected to something that is not real.
Stayed, or came back — this is no longer a passing scan.
Working through the structure, looking for something specific.
Trying logins — which reveals the breach corpus they are working from.
Requested something no legitimate user requests. Effectively conclusive.
Used a credential stolen from a decoy. Confirms both the theft and the intent.
Alongside it: their tooling, how long they were held, which decoy each stolen credential came from, and the evidence behind the assessment printed next to it — because a confidence score with no reasoning attached is one an analyst can neither check nor defend.
We are asked whether the decoy can locate the intruder, or serve them something. The answer is settled, written down, and governs every future change.
No scanning, no probing, no response traffic. Every signal it holds arrived because they reached it. The code is audited against this: the only outbound connections in the process go to the alert collector the operator configured.
False documents, yes — that is the product. Payloads, responses designed to crash their tooling, and anything that runs on the other machine, never. Deception is content; a payload is a weapon, and the difference is not one of degree.
The first reason is practical rather than principled: the machine attacking you is usually a third party’s compromised equipment — a hospital, a university, a small business in another country. Attribution from a single address is wrong often enough that acting on it means acting against another victim. The second is that acting on what is found belongs to your own operators, under your own legal authority, and does not transfer to a tool you bought.
Each of these is checkable, and each is better heard from us first.
An intruder who touches none of the decoys is not detected. It complements monitoring, firewalls and patching; it replaces none of them.
Timing, the absent key exchange and the maze’s unlimited depth are all tells under close inspection. It buys time and signal, not invisibility — and anyone selling a deception system as undetectable is wrong.
Copying a decoy file produces no signal; using the credential inside it does, and names the decoy. We would rather say this than let an evaluator discover it.
93 local tests, including a suite that plays the attacker, is not a deployment record. It will not be described as proven in the field until something has actually tried it.