How to Implement Decoys That Attackers Actually Believe

Deploying a decoy is easy. Deploying one that belongs in your environment, behaves like real infrastructure and gives an attacker a reason to continue interacting with it is much harder. That difference matters.

A fake login page sitting randomly on a network may generate noise. A convincing database, VPN portal, file server or cloud service that fits naturally into the surrounding infrastructure can generate something far more valuable: high-confidence evidence that someone is somewhere they should not be. At Tero, we think about decoy implementation as part of a broader defence and detection strategy — not as isolated traps.

If you want the wider architecture first, read How Tero Works: From Organization to Investigation.

1. Start with the environment

A good decoy should make sense where it is deployed. A Corporate Office may reasonably contain:

• a domain controller
• an internal file server
• RDP or WinRM
• a VPN portal
• internal applications

A Cloud or VPC environment might instead contain:

• Kubernetes APIs
• Redis
• MongoDB
• object storage
• container registries
• internal APIs

A Development environment may expose Git services, CI/CD systems, staging applications and artifact repositories. The goal is not to deploy every possible service everywhere. The goal is to create infrastructure that looks plausible in context.

Tero Sensors provide that deployment point inside the customer's environment. You can learn more about that architecture in Introducing the Tero Sensor.

2. Make the service behave like the real thing

Visual similarity isn't enough. Attackers don't only look at screens. They use tools. A MongoDB decoy should respond to MongoDB clients. Redis should behave like Redis. A Kubernetes API should return recognizable Kubernetes resources. A web application should expose believable routes, authentication boundaries and errors.

The standard should be simple: If someone investigates the service with the tools they would normally use, the illusion should continue. That means realistic protocols, sensible response codes, appropriate authentication behavior and believable operational data.

3. Make your decoys agree with each other

The strongest decoys don't exist independently. Imagine an attacker discovers a Kubernetes deployment containing:

registry.company.internal/payments/api:2026.10.4

They investigate the container registry — and that image exists. The deployment references:

redis-cache-01.company.internal

They investigate Redis — and find application cache keys belonging to the same service. MongoDB contains orders created by the same fictional application. Object storage contains matching exports. The internal API reports the same environment and release version.

Now the attacker isn't looking at a collection of isolated traps. They're exploring what appears to be a real infrastructure estate. That consistency is one of the principles behind Tero's environment-based personas.

4. Keep the decoy isolated from production

Believability should never come at the cost of containment. A decoy can expose realistic synthetic information without having access to real customer data, production credentials or sensitive infrastructure. Tero's model is designed around isolated services, synthetic identities and controlled interaction. The attacker gets something worth investigating. The customer gets visibility without introducing another path into production.

This is also why Tero is designed to work alongside existing security tooling rather than requiring teams to replace everything they already use. Read Add Protection Without Replacing Everything Else for more on that approach.

5. Treat interaction as evidence

A real employee may legitimately connect to a production database. They should have almost no legitimate reason to interact with a decoy MongoDB server that exists only for detection. That changes the quality of the signal. Instead of asking:

“

Is this activity suspicious enough?

you can ask:

“

Why is anyone touching this system at all?

Tero captures those interactions so teams can investigate connections, authentication attempts, queries and exploration activity with context.

That complements the systems already monitoring legitimate infrastructure. Your Security Stack Watches Real Systems. Tero Watches What Nobody Should Be Touching. explains that distinction in more detail.

Build a decoy environment, not just a decoy

The objective isn't to fool someone forever. It is to create enough credible infrastructure that unauthorized activity becomes visible early — while the attacker is still investigating what they believe is valuable. That requires the right service, in the right environment, with believable behavior and consistent synthetic context. Tero is being built around exactly that model.

See how Tero deploys realistic decoys across your environments →

A short demo will show you how an environment is created, how a Sensor is deployed, how decoys are added, and how interaction becomes actionable detection evidence.