NewIncident brief / 01 · Incident of 29 October 2026 / Attack analysis
What happened at Binance?
The attack chain from a fake interview to wallet signing, what defenders can check at each stage, and where deception fits.
See the trail, not just the trigger
Deception your SOC can investigate.
Know the moment someone uses a stolen credential. Legitimate users have no reason to touch these traps, so an alert means something. Then follow every step the attacker takes after it.
- Detect immediatelyThe first use of a planted credential creates a finding
- Follow provable lineageSteps taken with material FalseTrail issued join that finding
- Investigate what happened nextEvery linked step, recorded as it was observed
Why now
Attackers try more paths, faster. Make sure one of them is yours.
AI makes attacks cheap to automate. A well-placed false trail gets found sooner, and when it does, your team needs more than an alert: what happened next, and what is proven.
Every config gets read.
Enumeration and credential testing cost almost nothing now. Every host and every file gets looked at.
Credentials get tried.
A key found in a config is a key used. One planted value, unique to its place, is all it takes.
Baselines are too slow.
No weeks of tuning. The first use of a planted credential is a finding.
Nothing tells it to stop.
Nobody warns automation that db-replica-02 isn’t real. The synthetic path holds, and records every step.
Human or AI, it doesn’t matter.Nobody legitimate uses what you planted. FalseTrail catches whoever, or whatever, follows it, the same way.
How it works
From first interaction to evidence trail.
More than a canary. Less than a deception environment to run.
- 1
Plant
False credentials, unique to where they sit.
Your own tooling puts them in place. Each one learns what legitimately touches it before it arms.
In the productPlacement Fabric
- 2
Detect and continue
First use, instant finding.
No dead end. Synthetic services answer like the real thing and hand out credentials that only work there, so every next step is observed.
In the productDeception Runtime
- 3
Investigate
Linked by proof, not guesswork.
Steps that use material FalseTrail issued join the finding. Everything else is context, never the path.
In the productOperations · Findings
Coverage
Where attackers look. Not only where engineers work.
Every trap is unique to where it sits and believable to the people who work there. Your own tooling, or your MDM, puts it in place.
- Servers and CI
Build hosts, runners and clusters
- kubeconfig
- deploy .env
- a fresh decoy per pipeline run
- Placed by
- Ansible, Kubernetes, GitHub Actions, GitLab CI
- Leads to
- Cluster API, auth service, admin API
- Cloud
The AWS accounts that matter
- access-key canary
- decoy secret in Secrets Manager
- Placed by
- Keys you mint, with the Terraform included
- Leads to
- Your own CloudTrail
- Engineering laptops
Developers and operations
- .mcp.json for AI tools
- deploy .env
- kubeconfig
- Placed by
- Jamf Pro or Intune: one script per group
- Leads to
- MCP server, auth service, admin API
- Finance and HRNew
Payments and payroll
- AP payment run procedure.docx
- Payroll calendar and systems.xlsx
- Placed by
- Jamf Pro or Intune: one script per group
- Leads to
- A business portal sign-in
A finding
One trail. Every step accounted for.
From a planted cluster token to a privileged synthetic action, each step is joined to the finding by something FalseTrail issued. Refused attempts are kept, and labelled as attempts.
Finding · R3 privileged synthetic actionR3high
- Placement FabricFalse opportunity plantedci-runner-07:/srv/ci/kubeconfig · a cluster token unique to this placement
- 1Cluster APICredential presentedR2first use of the planted token · opened the finding, SOC notified
- ↳ causal link · read a synthetic Secret · issued a synthetic downstream credential
- 2Auth serviceControlled synthetic continuationexchanged the issued credential for an admin token · via the issued credential
- 3Admin APIDecision point: opportunities shownfive synthetic opportunities, offered side by side
- 4Admin APIRefused synthetic actionattempt, not R3took “Audit log settings” · refused
- 5Admin APIPrivileged synthetic actionR3took “Data export” · performed in the synthetic world
Investigate: observed path · issued material · hunt pivots · Export JSONDelivered to your SOC with stable IDs
Why the evidence holds
Every link has a reason you can check.
A finding is only as good as what it proves. FalseTrail draws a step into the path only when the evidence supports it.
- 01
It starts from something you planted
Every finding names its placement. The first interaction that proves use of a planted opportunity opens the finding.
- 02
Links come from what FalseTrail issued
A step joins only when it uses a credential, token or reference FalseTrail issued. That material is the link, shown on the finding.
- 03
Correlation stays context
Same address, same session: useful, not proof. Shown beside the path, never drawn into it.
- 04
Observed, not inferred
What was taken and what was attempted, on record. No guesses about intent or identity.
- 05
Reuse links findings, not actors
Issued material seen from a new source links the findings. It never claims the same actor.
- 06
History stays as recorded
Testers and known automation apply going forward. Existing findings are never rewritten.
Deception Runtime
Not a dead end. A controlled synthetic trail.
Synthetic services answer like the real thing and hand out material for the next step. The actor keeps moving, on a path you control.
- enters from .mcp.json→ a tool discloses a client secret01MCP server
A real MCP server that AI clients connect to. Its tools answer from the synthetic world.
enters from kubeconfig context→ a synthetic Secret holds a client secret01Cluster APIA Kubernetes API with read-only access to one namespace. Writes are refused, and recorded as attempts.
- enters from .env or a disclosed secret→ issues an admin token02Auth service
Trades a client secret for an admin token that only works here.
- enters from service reference03Admin API
The decision point: five privileged opportunities side by side. What the actor takes is performed, in the synthetic world.
Bounded: one synthetic world from a versioned template, holding no real data.Reachable only through what you planted; never in your production path.The Cluster API is optional, chosen at install.Finance and HR documents lead to their own business portal: one sign-in, then the trail ends.
See the platform →Integrations
Lands in your SIEM. Lives in your cloud.
Built-in integrations for the SIEM and SOAR your SOC runs. Decoys for AWS, Kubernetes, CI pipelines and MCP clients.
- SplunkSplunk
- QRadarIBM
- SentinelMicrosoft
- Cortex XSIAMPalo Alto Networks
- Cortex XSOARPalo Alto Networks
- FortiSIEMFortinet
- AWS
- Kubernetes
- GitHub Actions
- GitLab CI
- MCP
- Jamf Pro and Intune
Deployment and trust boundary
Your environment. Your evidence.
Customer-hosted today. Your placements, your evidence and your environment’s context never leave your network. No telemetry, and never a connection back to us.
Your network · on-prem, private or hybrid
- Your deployment toolingYour staff deploy each bundle, or your MDM runs one script per groupplace
- 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
Attack telemetry, deception state and environment context stay inside this boundary
0
agents
Your own tooling places the files, or your MDM runs a script that exits. FalseTrail needs access to its own host, nothing else.
0
connections to us
No telemetry, no phone-home. Raw evidence stays on your host; only the findings you forward leave it.
0
production traffic through it
FalseTrail is not a proxy. The only way in is something you planted.
0
automatic actions on real systems
Your EDR, XDR and SOAR keep that authority.
FAQ
What your security team will ask.
What is FalseTrail?
FalseTrail is deception your SOC can investigate. It plants believable false opportunities, such as credentials and service references, each unique to where it was placed. The first interaction with one creates a finding immediately. What follows stays inside bounded synthetic services and is linked to that finding through the credentials and references FalseTrail issued, so your team gets an evidence trail rather than a single event.
Where does FalseTrail run?
Today FalseTrail is a customer-hosted deployment: the control plane, decoy services and evidence run inside your environment, on-prem, in private cloud or across a hybrid estate. Sensitive evidence stays local, and you choose what is forwarded to your SIEM.
How is this different from honeytokens?
It starts from the same idea: something planted that nobody legitimate should use. FalseTrail adds a managed placement lifecycle, bounded synthetic services for the actor to continue into, and an evidence model that links later steps only through material FalseTrail issued, keeping correlated activity separate as context.
Do we need an agent on every endpoint?
No. For servers and CI, FalseTrail produces a bundle for each placement, and your own tooling puts it in place and records a receipt: Ansible, Group Policy, Kubernetes or your infrastructure-as-code. For workstations, your MDM (Jamf Pro or Intune) runs one script per group on its usual schedule. Each run checks in, installs or removes that device’s own files and exits. Nothing stays resident.
Can it cover people who are not engineers?
Yes, finance and HR to start with. FalseTrail plants a genuine Word or Excel document, a payment-run procedure or a payroll calendar in your organization’s name, holding a sign-in and a link for a synthetic business portal. Opening it in Word, Excel or LibreOffice is recorded, and using its password or link opens a finding that names the workstation.
Will scanners, backup and DLP set it off?
A finding opens only when an interaction proves use of something you planted, so a scanner reaching a decoy port proves nothing on its own. Placements start in Learning, where FalseTrail identifies legitimate automation and authorized testers and records them as narrow, expiring patterns. Interactions it cannot explain still alert.
Does FalseTrail detect AI attackers?
FalseTrail doesn’t classify attackers as human or AI, and doesn’t need to. An opportunity you planted has no legitimate user, so whoever or whatever uses it is detected the same way. Automation tends to find planted opportunities sooner because it looks at more of the environment.
If an issued credential is reused from somewhere else, is it the same attacker?
Not necessarily, and FalseTrail doesn’t claim it is. When material FalseTrail issued turns up again from another source, the findings are linked by that material, so your team can see the connection and decide what it means.
What does “continuation” mean?
Once a planted opportunity is used, bounded synthetic services answer convincingly, so the actor’s next steps land on synthetic assets and are recorded. It buys your team time and context. FalseTrail does not hack back or act against real systems, and it does not guarantee containment, which stays with your response tools.
Does it replace our SIEM, EDR or SOAR?
No. It feeds them. FalseTrail produces findings with context and leaves correlation, response and containment to the stack you already run.
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