How Tero Turns Synthetic Infrastructure Into Real Security Evidence

A Tero decoy is not a production system. Its data is synthetic. Its identities are synthetic. Its infrastructure relationships are synthetic. That is intentional.

What happens to it, however, is real. A connection from an unexpected device is real. An authentication attempt is real. A database query is real. An attacker enumerating services, following infrastructure clues, or attempting to move deeper into an environment is real. That distinction is central to how Tero works. The infrastructure can be fictional while the security evidence it produces is completely genuine.

Synthetic does not mean superficial

A useful decoy should not feel like a placeholder. It should behave like something that belongs in the environment. A Cloud/VPC environment might contain:

• MongoDB
• Redis
• Kubernetes
• Object Storage
• Container Registry
• Internal APIs

A Corporate Office may contain:

• VPN Portal
• File Server
• RDP
• WinRM
• Internal Web
• Domain Controller

The systems do not need real customer information to be believable. They need coherent names, realistic behavior, sensible relationships, plausible data, and enough depth that someone investigating them has a reason to continue. That is why Tero uses synthetic infrastructure rather than exposing real production systems as bait. The attacker gets something worth examining. The customer keeps real information out of the interaction.

The environment is fictional. The behavior is not.

Imagine someone discovers:

mongo-01.company.internal

They connect. They enumerate databases. They inspect collections. They query records. Perhaps they discover references to another service and begin investigating that too. The database itself may contain entirely synthetic information. But this sequence:

connection
→ enumeration
→ discovery
→ query activity
→ further exploration

represents real behavior performed by a real source. That is what matters to the defender. Tero is not trying to prove that the synthetic records are valuable. It is observing what someone does because they believe they may be valuable.

Every interaction adds context

A single network connection can mean very little. But activity becomes more useful as context accumulates. For example:

22:14:03  Connected to MongoDB decoy
22:14:09  Requested database list
22:14:17  Enumerated collections
22:14:29  Queried synthetic customer records
22:14:41  Probed related internal API

Now the security team can see progression. The source is not simply touching a port. It is exploring. That gives defenders evidence about intent, sequence, and interest. And because legitimate users should not depend on the decoy, that evidence starts with less ambiguity than activity against production systems.

Read more in Why High-Confidence Detection Matters More Than More Alerts.

Synthetic infrastructure creates a safe observation point

There is another advantage. If the system contains real customer data, every interaction creates risk. If the system contains synthetic data, the defender can observe much more safely. A decoy can present:

• fictional application records
• synthetic user accounts
• realistic infrastructure names
• artificial service relationships
• fake operational history
• believable configuration

without exposing production secrets. The attacker believes they are learning about the environment. The defender is learning about the attacker. That is the exchange Tero is designed to create.

Evidence becomes more useful when systems agree

The strongest synthetic environments do not exist as isolated services. They reinforce each other. For example:

Kubernetes
    ↓
references a container image

Registry
    ↓
contains that image

Application config
    ↓
references MongoDB and Redis

MongoDB
    ↓
contains matching service records

Object Storage
    ↓
contains believable exports

None of those assets need to be real. But the relationships between them should make sense. That allows attacker exploration to continue naturally and creates more opportunities to observe decisions along the way.

For more on this design philosophy, read Why Attackers Should Find Something Worth Investigating.

Tero turns interaction into evidence

The decoy is only the starting point. What matters is what Tero can capture around the interaction:

• which decoy was touched
• which environment it belonged to
• which Sensor observed it
• where the activity originated
• what actions were performed
• how the activity progressed
• what happened next

That evidence can then become part of the broader investigation. Security teams can compare it with endpoint telemetry, identity events, firewall records, cloud activity, and SIEM data. Tero does not replace that investigation. It gives the team a strong place to start.

See how this fits into the wider stack in How Tero Fits Into Your Existing Security Stack.

Fictional systems. Real intent.

A decoy does not need to protect valuable data to be valuable. Its purpose is different. It exists to create a safe place where unauthorized exploration becomes visible. The infrastructure is synthetic. The customer data is synthetic. The services are controlled. But the person interacting with them is making real decisions. And those decisions can become real security evidence.

That is the principle behind Tero: create something believable enough to investigate, then make the investigation visible to the defender.

To see the full journey from interaction to investigation:

What Happens When an Attacker Touches a Tero Decoy? →

Or watch synthetic infrastructure produce real detection evidence:

See Tero in action →