Designing Decoys That Fit the Environment

A decoy is only useful while it looks like it belongs. Attackers do not explore infrastructure in isolation. They look at hostnames, ports, services, credentials, data, network placement and the relationships between systems. A service can function perfectly and still fail as deception if everything around it feels artificial. That makes realistic deception partly a technical problem and partly a design problem.

The goal is not to build a perfect replica of production. The goal is to create something plausible enough that suspicious exploration continues long enough to become useful evidence.

Realism starts with context

A database called honeypot-db does not require much analysis. Neither does an isolated service with a hostname that does not match anything else in the environment. The strongest decoys begin with the context in which they will exist. That includes questions such as:

• What kind of company is this?
• What systems would reasonably exist here?
• How are production services normally named?
• Which protocols are common in this environment?
• What departments or applications might depend on them?
• What data would those systems plausibly contain?

A finance company, a software business and a manufacturer should not necessarily deploy the same deception environment. The infrastructure should tell a story that fits the organisation around it.

Naming creates the first impression

Names are often the first clue an attacker receives. A hostname such as:

BARCELONA-FINANCE-DB01

already communicates several things. It suggests:

• a physical or organisational location
• a business function
• a service role
• the possibility of additional related systems

A random name such as:

DECOY-1234

does the opposite. It immediately introduces doubt. Good naming conventions should resemble the patterns already used by the customer. If production infrastructure uses names such as:

BCN-FILE-01

BCN-DC-02

FIN-SQL-01

then deceptive infrastructure should follow the same structural language. The objective is consistency, not complexity.

Choose services that make sense

Not every environment needs every possible decoy. A realistic deployment should reflect the technologies an attacker would reasonably expect to discover. For example, an internal corporate environment might contain:

• Active Directory infrastructure
• RDP
• WinRM
• SMB
• Microsoft SQL Server
• internal web applications

A development environment might contain:

• PostgreSQL
• MySQL
• SSH
• internal APIs
• build infrastructure
• source-control related services

A cloud-heavy environment might justify a different mix again. Deploying every protocol everywhere can make deception less convincing rather than more convincing. The right question is not:

“

How many decoys can we deploy?

It is:

“

Which systems would make sense here?

Synthetic data should support the story

A database becomes more believable when its contents match its supposed purpose. If a decoy is presented as a finance database, an attacker should not find random tables called:

test1

foo

sample_data

Instead, they might encounter structures such as:

accounts_receivable

invoice_status

vendors

quarterly_reporting

The data does not need to be real. In fact, it should not be. But it should be coherent. Synthetic records should use believable formats, relationships and business terminology without containing genuine customer information. This gives the attacker something meaningful to explore while keeping real data outside the decoy.

Credentials also need context

Credentials are another important part of realism. A username such as:

admin

can exist anywhere.

A username such as:

finance.reporting

or:

svc_reporting

suggests a specific operational purpose. The same principle applies to passwords, configuration files, environment variables and service accounts. Deception becomes stronger when these details reinforce one another. A finance database with a reporting service account, plausible schemas and an internal hostname presents a more coherent environment than any of those components individually.

Network placement affects credibility

Where a service appears matters as much as what the service does. A decoy should be reachable from the places where suspicious discovery would realistically occur. At the same time, it should remain isolated from genuine production data and credentials.

That creates an important balance. The decoy needs enough visibility to be discovered. It should not have enough privilege to create a path into real systems. Tero's model keeps deceptive services controlled while allowing them to exist close enough to customer environments to attract meaningful interaction.

Behaviour matters after discovery

Realism does not end when the attacker connects. A service that accepts a connection and immediately behaves in an obviously artificial way loses much of its value. Attackers may test:

• authentication
• database queries
• file paths
• permissions
• error messages
• protocol behaviour
• system metadata

The more coherent those responses are, the longer the interaction can remain useful. This does not mean a decoy needs to reproduce every feature of a production product. It means the behaviours an attacker is likely to test should make sense.

Consistency matters across multiple decoys

A single convincing service can still feel suspicious if the surrounding systems contradict it. Imagine an environment containing:

• BCN-FIN-DB01
• random-windows-box
• mysql-decoy
• server123

Each one may work technically. Together, they do not describe a believable environment. A stronger deployment might instead use:

• BCN-FIN-DB01
• BCN-FIN-RDP01
• BCN-DC01
• BCN-FILES01

Now the systems begin to reinforce each other. An attacker can form a mental model of the environment. That is exactly what makes the deception more convincing.

Realism should never rely on real sensitive data

Believability does not require copying production secrets. Real credentials, customer records and confidential documents should not be used simply to make a decoy look authentic. The safer approach is to reproduce structure without reproducing sensitive content. For example:

• realistic table names
• synthetic customer records
• plausible filenames
• invented internal documents
• fictional employee identities
• controlled decoy credentials

This preserves the story while maintaining isolation. A useful decoy should increase visibility without increasing exposure.

The best deception is operationally sustainable

There is another side to realism that is easy to overlook. A decoy that takes hours to manually maintain may become stale very quickly. Names change. Infrastructure evolves. Applications move. Business units reorganise.

A deception platform therefore needs a way to keep realism manageable. Templates, personas and reusable service profiles can help teams deploy environments that are consistent without rebuilding everything by hand. The long-term goal should be realistic deception that can scale operationally.

Design for the attacker, operate for the defender

Good deception has two audiences. The attacker needs to see an environment worth exploring. The defender needs evidence worth investigating. Those requirements should reinforce each other. A believable decoy encourages interaction. More interaction creates richer telemetry. Richer telemetry gives the defender more context. That is why realism is not cosmetic. It directly affects the quality of the security signal.

“

A convincing decoy does not need to be identical to production. It needs to make the attacker believe it could be.

— Tero Engineering

Realistic deception is a system, not a single service

The strongest deception environments are built from many small details working together. Naming. Services. Synthetic data. Credentials. Network placement. Behaviour. Consistency. None of these alone creates realism. Together, they create an environment that feels intentional.

At Tero, that is the direction we are building towards: deception infrastructure that fits naturally into the environment around it while remaining isolated, observable and useful to the people defending it. Because the longer suspicious activity remains inside the deception layer, the more defenders can learn before real systems become the target.