Deployed inside your environment.
FalseTrail is available today as a customer-hosted deployment. This page is for the engineer reviewing it: what runs where, what it can reach, what leaves the host, and how it is upgraded.
- Your deployment toolingYour staff deploy each bundle and record a receiptplace
- Your estatePlacements on endpoints, CI, servers and sharesfollowed
- FalseTrail Deception RuntimeSynthetic services that answer convincingly and hold no real dataevidence
- FalseTrail control planePlacement state, evidence, Learning and findings, on a host you runfindings
- Your SOC / SIEMFindings arrive through forwarding you configure and own
Not a production proxy
Production traffic never routes through FalseTrail. The only way to reach a decoy is to follow something you planted.
No broad access to your estate
Your own tooling places and removes bundles. FalseTrail can run with access limited to its own host.
Evidence stays local
The raw evidence behind every finding stays on the FalseTrail host you run.
You own forwarding and response
You choose what is forwarded to your SIEM. FalseTrail takes no automatic action against real systems; your EDR, XDR and SOAR keep that authority.
One host. A small surface.
The control plane, the synthetic services and the evidence store run together on a single host you provision and own.
| Footprint | One Linux host you run. Python 3.12 or later, standard library only; no third-party runtime dependencies. |
| Install | A release tarball with a SHA-256 checksum, unpacked into /opt/falsetrail and run by an unprivileged falsetrail user. |
| Service | A systemd unit with UMask=0077, ProtectSystem=strict, NoNewPrivileges and an empty capability set. All ports above 1024. |
| Data | A private data directory (0700). Configuration and secrets files are owner-only, and readiness checks that they stay so. |
| Decoys | Served on the names you choose, with a certificate from your internal CA. TLS 1.2 or later. |
| Console | Bound to loopback and reached through your own SSH tunnel. Local accounts with viewer and operator roles, lockout after repeated failures, idle and absolute session limits, CSRF protection and a strict content security policy. |
Your tools place it. Your tools report it.
FalseTrail never logs in to your endpoints. It produces a bundle per placement; the deployment system you already trust puts it in place and records a receipt.
- What a bundle contains: the file to place, a manifest with its path, mode and SHA-256 (never the value), a create-only install script, Ansible tasks and a receipt template.
- Create-only. The install script refuses to overwrite an existing file and refuses a missing directory, with distinct exit codes your tooling can act on.
- Any tool that can place a file. Ansible tasks are included. Intune, Group Policy, MDM or your configuration management can deploy the same files or run the same script.
- Receipts: deployed, verified and removed. Checksums must match the manifest, and a receipt can name the asset in your inventory.
Bundle ready
Created from a pack for one host and path, inside your plan’s target groups and outside its prohibited zones.
Deployed
Your job places the file and records a deployed receipt with the checksum.
Verified
A later check confirms the file on the host still matches.
Removed
On retirement, your tooling removes it and records that too.
No proxy. No broad access.
FalseTrail sits beside your environment, not in front of it.
Not in the production path
Production traffic never routes through FalseTrail. The only way to reach a decoy is to follow something you planted.
No reach into your estate
It never touches other hosts, directory services, EDR, MDM, SIEM APIs or real credentials. Its own host is the extent of its access.
Answers never echo requests
Synthetic responses are never built from request bytes. Forwarded-for headers are trusted only from proxies you configure; none by default.
Internal traffic stays on loopback
Components talk to each other over loopback, push-only, each with its own token. Facts are append-only, and the service fails closed when the disk is full.
You own the forwarding. Evidence stays local.
FalseTrail makes no outbound connections and sends no telemetry. Findings reach your SOC through a file your own forwarder ships.
- Notification export: one JSON line per SOC notification (
openedorescalated), with stable IDs, the interaction level and the finding’s strongest level. - Its own directory and group, readable by your forwarder and nothing else. Appended and synced line by line, and safe to rotate.
- Raw evidence stays on the host. Full findings can be exported as JSON from the console when an investigation needs them.
- No outbound connections, tested. A test checks at the socket layer that every connection goes to the installation’s own loopback ports and that only local names are resolved.
Observable with the tools you run.
Everything you need to operate FalseTrail is local: health, logs, metrics and an end-to-end self-test.
| Health and readiness | Loopback health endpoints for every internal service, a console health endpoint and pilot status, which exits non-zero on failure. The service does not start unless readiness passes. |
| journald | Structured JSON lines under the falsetrail identifier: journalctl -t falsetrail. Operations only, never evidence or secrets. |
| Metrics | An optional Prometheus textfile, rewritten every 30 seconds, in its own group-readable directory for your node exporter. Labels come from fixed sets. |
| Self-test | Places a throw-away credential that is never deployed, presents it over TLS, waits for its notification and retires it: the decoy path checked end to end. |
| Audit trail | Console actions are recorded with the operator who made them, and pilot audit prints the trail. |
| Kill switch | Turns every decoy response off. Ports stay open and close connections without answering, and nothing is recorded while off. |
| Support bundle | Diagnostics for support that never include secrets, databases, bundles or notification contents. |
Back up, upgrade, roll back if needed.
Upgrades are explicit and reversible, and the data format protects you from running an older release against newer data.
Release upgrades
Install the new release tarball after taking a backup with the current one. The state format is versioned, so an older release refuses to read upgraded data instead of corrupting it.
Rollback
Restore the backup into an empty directory and run the previous release. Backups are cold and owner-only.
World template upgrades
Run offline with a mandatory backup. A new epoch starts with the same seed; material issued under the previous one keeps working. Only listed transitions are accepted; anything else changes nothing.
Put a false trail in front of your next attacker.
Evaluate FalseTrail on your own estate. We start with a walkthrough on a sample environment, then scope an evaluation inside your network.
- A finding followed from first interaction to evidence trail
- Where placements would fit in your estate
- How it deploys and what stays inside your network