What Happens When an Attacker Touches a Tero Decoy?

A Tero decoy is quiet by design. It sits inside an environment looking like infrastructure that belongs there — a database, API, VPN portal, Kubernetes service, file server or another system an attacker may expect to find. Legitimate users should have no reason to interact with it.

That is what makes the moment someone does so valuable. The first connection can begin a chain from interaction to evidence, alert, and investigation. Here is what that journey looks like.

1. The attacker discovers something worth exploring

Imagine someone has gained access to part of a network and begins reconnaissance. They scan available services and discover:

mongo-01.company.internal:27017

To them, it looks like an internal MongoDB service. It belongs to the surrounding environment. Its hostname makes sense. Its behavior looks familiar. Its data appears connected to other services they may discover.

The attacker does what attackers often do next: they investigate. This is why believability matters. A decoy that looks obviously fake may never generate meaningful interaction.

We explore that in more depth in How to Implement Decoys That Attackers Actually Believe.

2. The first interaction becomes an event

The moment someone connects to the decoy, Tero has something useful to observe. That might begin with:

connection opened

and develop into actions such as:

service discovery
authentication attempt
database enumeration
collection discovery
query activity
API exploration
file access

The important distinction is that this activity is happening against infrastructure that should not normally receive legitimate traffic. That gives the event immediate context. Tero does not need to decide whether an ordinary production request suddenly looks suspicious. The interaction itself is unusual.

3. Tero starts building evidence

A useful detection should answer more than:

“

Something happened.

The investigation needs context. Tero can associate the interaction with information such as the decoy that was touched, the Sensor that observed it, the environment it belongs to, when the interaction occurred, the source of the activity and what actions were performed. That starts building a timeline. For example:

21:14:03  Connection to MongoDB decoy
21:14:08  Database discovery
21:14:16  Collection enumeration
21:14:31  Query against synthetic customer data
21:14:42  Additional service exploration

Now the security team is not looking at a single isolated network connection. They are looking at behavior.

4. An event becomes something worth investigating

Not every technical event should become another noisy alert. The goal is to surface activity when the context makes it meaningful. If someone simply connects to infrastructure nobody should be using, that may already justify attention. If they continue exploring, the confidence increases.

An attacker who discovers a MongoDB decoy and then begins enumerating databases is showing more intent than a random network probe. Someone who follows clues from MongoDB toward an API, registry or Kubernetes service is giving the defender even more information about what they are trying to accomplish. That progression is what makes decoy-based detection powerful.

For more on the difference between volume and confidence, read Why High-Confidence Detection Matters More Than More Alerts.

5. The alert arrives with context

By the time Tero surfaces an alert, the objective is to give the security team a useful starting point. Instead of:

“

Suspicious network activity detected.

the team should be able to understand:

What was touched?
MongoDB decoy

Where?
Cloud / VPC environment

Which Sensor observed it?
Barcelona-01

What happened?
Connection followed by database and collection enumeration

When?
21:14

Where did it come from?
Observed source

What happened next?
Additional queries against synthetic data

That dramatically changes the first few minutes of an investigation. The team already knows what system was involved and why the interaction deserves attention.

6. The investigation follows the attacker, not the decoy

The decoy is not the end of the investigation. It is the beginning. Once a security team knows that someone interacted with infrastructure they should not have touched, they can pivot into the rest of their security stack. They can check:

• endpoint telemetry
• identity activity
• firewall logs
• cloud audit trails
• SIEM data
• network activity

The Tero event provides a high-confidence point in time around which the rest of the investigation can be organized. That is why Tero is designed to complement existing security systems rather than replace them.

Read Add Protection Without Replacing Everything Else for more on that approach.

The attacker sees infrastructure. The defender sees intent.

From the attacker's perspective, the interaction may look simple:

discover service
→ connect
→ enumerate
→ investigate

From the defender's perspective, the same sequence becomes:

interaction
→ event
→ evidence
→ alert
→ investigation

That is the value of putting believable decoys into places an attacker may explore. The attacker believes they have found something useful. The defender gains an opportunity to see what they are doing before they reach something real.

See the entire journey

The easiest way to understand Tero is to watch the full path happen:

See the complete detection journey in a Tero demo →