How a FalseTrail finding is built.
A finding is only useful if your team can trust what it claims. This page describes exactly what FalseTrail records, what links one step to the next, and what it deliberately does not conclude.
The first interaction that proves use of a planted opportunity.
A finding opens when a request carries something only your placement could have supplied: the planted reference, the planted credential, or material FalseTrail issued further along that trail. Reaching a decoy without any of those proves nothing about your placements, so it opens nothing.
One finding, one trail. A finding groups requests from one placement, one source and one decoy. After five minutes without activity, the next use opens a new finding.
Severity follows the placement’s state at the moment of use, so a credential presented while its placement was still learning is visibly different from one presented while it was armed.
Your SOC hears about it once, then on change. The first use sends an opened line. Later uses in the same finding send an escalated line only when they raise its level or severity.
| Placement state at use | R1 | R2 | Issued material reused |
|---|---|---|---|
| Armed | medium | high | high |
| Learning | low | medium | medium |
| Retired | low | medium | medium |
Three different events. Kept separate.
A reference being followed, a credential being presented and a privileged synthetic action being performed tell you different things. FalseTrail never collapses them into one score.
A placement-specific reference was resolved or connected to, such as the service URL planted in a deploy file.
Opens a findingA placement-specific credential was presented to a decoy, or synthetic material obtained from it was presented at the next step.
Opens a finding, or continues oneA privileged operation was performed in the synthetic world: a data export, a credential rotation, a role grant or an audit-log change.
Escalates the finding that led thereSteps are linked by what FalseTrail issued.
As a trail continues, the synthetic services hand out material: a client secret read from a synthetic Secret, an admin token, an export job ID. Each is recorded before it is shown, and each remembers the chain that led to it, back to your placement.
A step joins the journey only when it presents material issued earlier on that trail. That is the causal link, and the console draws it: “causal link from request #11 · issued a synthetic downstream credential”.
Recorded before exposed. If FalseTrail cannot durably record what it is about to issue, it does not answer. There is no issued value without a record behind it.
Stable per source. The same source following the same trail receives the same continuation, so retries don’t multiply evidence. A different source gets its own.
A finding opened by a planted cluster token. The journey shows the placement, the first use (R2), and each later step joined by a causal link through issued material.
- “Opened by”: the first use of the planted artifact
- the orange causal link names the request that issued the next credential
- “via the issued credential” on every linked step
What was done. Not why.
Holding an admin token, a trail reaches a decision point: the synthetic admin API offers five opportunities side by side. FalseTrail records which ones were taken, in order, and how each one ended. It never turns those choices into a statement about intent.
Each choice ends one way: read, performed or refused. Performed privileged actions are R3; refused ones are attempts.
“Not taken” is only said when it is known. If the trail fetched the decision point’s index, the opportunities it saw and skipped are listed. If it didn’t, nothing is said about them.
- 01Service account credentialssecrets and data1disclosed
- 02Data exportsecrets and data4performed · R3
- 03Rotate a service account credentialpersistence3performed · R3
- 04Grant a role to a service accountaccess expansionoffered, not taken
- 05Audit log settingsdefense evasion2refused · attempt, not R3
- 1Service account credentialsdisclosed
- 2Audit log settingsrefused · attempt, not R3
- 3Rotate a service account credentialperformed · R3
- 4Data exportperformed · R3
What was done, not why. Recorded as evidence on the finding.
Related is not the same as linked.
Activity from the same address, the same session or the same placed artifact can matter to an investigation. It is not proof that one step led to another, so FalseTrail shows it beside the path, labelled for what it is.
Other uses of the placed artifact
Other requests that used the same planted credential. Each belongs to its own finding; here they are listed for context.
Correlation context
A session groups activity by source and time. It is a lead to follow, never a causal claim.
Material used from elsewhere
When issued material shows up from a different source, the journey stops there. What happens next belongs to that source’s own finding.
Material is proven. Identity is not.
Issued material sometimes travels. A credential issued on one trail may later be presented from a different source. FalseTrail treats that as evidence about the material, not about who holds it.
- A new finding opens for the new source, because presenting material that only a FalseTrail trail could have issued is proof of use.
- The two findings are linked, never merged. Each links to the other: “Issuing finding” from the new one, “Linked finding” from the original.
- Neither escalates the other. Actions on one source’s trail don’t raise the other source’s finding.
- No identity claim. FalseTrail does not say the two sources are one actor, that something leaked, or that anyone moved laterally. The console labels the link “provenance · not identity”.
- source
- 10.40.7.31
- planted at
- ci-runner-07:/srv/ci/kubeconfig
- source
- 10.40.22.140
- began at
- ci-runner-07:/srv/ci/kubeconfig
What the actor saw is not the evidence.
Synthetic services answer believably, and believable answers are sometimes fiction: an export can report “queued” after it has already been committed. FalseTrail keeps what the actor was shown apart from what it recorded, and both apart from what you can safely conclude.
| Step | What the actor was shown | What FalseTrail recorded | What you can conclude |
|---|---|---|---|
| Data export | HTTP 202 with a job in status “queued”. | The export was committed in the synthetic world before the response was sent: R3, performed. | The holder of an admin token issued on this trail performed a privileged synthetic export. Not that real data left. |
| Disable audit logging | HTTP 403 from the synthetic admin API. | A refused privileged write, kept as behaviour on that step. Not R3. | An attempt was made and refused. Nothing was performed. |
| Cluster write | HTTP 403: refused by RBAC. | A refused write on the Cluster API. Not R3. | The token holder tried to change cluster state and was refused. |
| Issued credential from a new source | A working answer, as for any holder of that credential. | Material issued during one finding was presented from a different source. A new finding opens for that source, linked to the first. | The material travelled from one trail to another source. Not that both sources are the same actor. |
Ready for the investigation in your environment.
Every finding carries an Investigate panel derived from the evidence: the observed path, the material issued on the trail, indicators, hunt pivots for your own logs, and defensible ATT&CK mappings. None of it contains a planted or issued value.
- Indicators are observed, not identity. Source address, client fingerprint, user agent and time window, as seen at the decoy.
- Hunt pivots are search suggestions for your real environment, from an hour before first sight to fifteen minutes after the last.
- ATT&CK mappings are limited to what the observed actions defensibly support, and attempts are marked as attempts.
- Export JSON gives the whole finding in one versioned document: finding, placement, evidence with material lineage, context and interpretation.
- Stable IDs throughout. Findings, facts and notifications keep the same IDs if evidence is rebuilt, so your SIEM can deduplicate safely.
{"notification_type": "escalated","notification_id": "ntf_e022a625f80e54c22968b7b5","finding_id": "fnd_7c2e91d04b3a5f6e8d1c2b3a","reason": "R3","interaction_level": "R3",← the interaction that caused this line"finding_level": "R3",← the strongest level the finding has reached"severity": "high","alert_version": "alert-v1","opening_alert_id": "alert_86835be25e6a05794c31af57","placement": {"location_label": "build-07:/srv/billing/deploy/.env", …},"finding": { "source_ip": "10.20.7.31", "surface_id": "S2", … },…}
Written locally, one line per notification. Your forwarder decides where it goes.
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