From Reconnaissance to Evidence

From Reconnaissance to Evidence

Attackers rarely begin with perfect knowledge of an environment.

They have to learn.

They scan.

They discover services.

They test authentication.

They enumerate what is available.

They query systems.

They follow clues from one service to another.

That activity is often described as reconnaissance.

But when it happens against infrastructure nobody should be touching, reconnaissance can become something more useful:

evidence.

Scanning is the first signal

A scan may be noisy on a normal network.

Security teams see legitimate discovery traffic, monitoring systems, vulnerability scanners, and application checks all the time.

But when a scan reaches a decoy, the context changes.

The service exists for detection.

It is not part of a legitimate workflow.

So even a basic connection can matter.

The question is no longer simply:

“

What responded?

It becomes:

“

Why was this system being looked for?

That gives the defender an early point of interest.

Discovery shows what the attacker values

Once a service is found, the next step is often discovery.

An attacker may ask:

• what service is running
• what version it appears to be
• what databases exist
• what endpoints are available
• what shares can be accessed
• what applications are exposed

Each action reveals a little more about intent.

Someone who connects to MongoDB and immediately asks for the database list is doing something very different from a random port scan.

Someone who discovers an API and starts enumerating routes is showing a different kind of interest again.

The more deliberate the exploration becomes, the more useful the evidence becomes.

Authentication attempts add another layer

Attackers often test whether a service can be accessed with credentials.

That might involve:

• username and password attempts
• token testing
• default credentials
• repeated login attempts
• access to restricted resources

In a production system, those attempts may need a lot of context.

A failed login might belong to a real user.

A token may have expired.

An application may be misconfigured.

On a decoy, the explanation is usually much narrower.

If nobody is supposed to authenticate to the service, authentication attempts carry more meaning.

They show that someone is not just discovering the system.

They are trying to use it.

Enumeration reveals intent

Enumeration is where attacker behavior starts to become particularly valuable.

Examples include:

show databases
list collections
enumerate shares
list API routes
query Kubernetes resources
inspect registry repositories
discover object storage buckets

These actions help reveal what the person is trying to understand.

A sequence like:

connection
→ database discovery
→ collection enumeration
→ query activity

is much more informative than a single connection event.

It begins to show intent.

The attacker is not simply present.

They are exploring.

Queries turn interest into behavior

Queries are another important step.

A database query.

An API request.

A file read.

A registry lookup.

An object access.

These are decisions.

They tell the defender what the attacker considered valuable enough to inspect.

For example:

MongoDB
→ lists databases
→ opens app_data
→ queries customer records

That sequence creates evidence about both the service touched and the path of exploration.

The data may be synthetic.

The behavior is real.

That distinction is central to how Tero turns decoy interaction into useful security context.

Read more in How Tero Turns Synthetic Infrastructure Into Real Security Evidence.

Service-to-service exploration tells a bigger story

Attackers rarely stop at one system.

A believable environment gives them clues.

A database may reference an API.

An API may reference Redis.

A Kubernetes deployment may reference a registry.

A registry may expose application images.

Object storage may contain related artifacts.

When someone follows those relationships, the defender gains visibility into the way the attacker is thinking.

That is valuable because the sequence becomes a narrative:

scan
→ discover MongoDB
→ enumerate data
→ find API reference
→ explore API
→ identify registry
→ investigate container images

Now the security team has more than a collection of isolated events.

They have a progression.

Evidence is strongest when actions are connected

The value of reconnaissance is not in any single event.

It is in the relationship between events.

Tero can help connect activity around:

• the decoy touched
• the Sensor that observed it
• the environment it belonged to
• the source of the activity
• the actions performed
• the order they happened in
• what service was explored next

That timeline gives the security team a much stronger starting point for investigation.

Instead of:

“

Something touched port 27017.

they can understand:

“

A source discovered MongoDB, enumerated databases, queried synthetic records, and then explored a related API.

That is evidence.

Reconnaissance can become an early warning

The important opportunity is timing.

If reconnaissance happens against a believable decoy before real production systems are touched, the security team gets a chance to investigate earlier.

That can mean:

attacker explores
→ decoy interaction
→ evidence captured
→ alert generated
→ investigation begins

instead of:

attacker explores
→ reaches production
→ accesses real systems
→ detection happens later

That is why decoy-based detection can be useful even before an attacker has caused visible impact.

Read more in The Cost of Waiting Until Production Is Touched.

From activity to evidence

Reconnaissance is often treated as background noise.

But the right context changes its value.

When someone scans infrastructure nobody should be using, discovers a service, tests authentication, enumerates resources, runs queries, and follows clues deeper into the environment, those actions begin to tell a story.

And that story can become evidence.

Scanning shows interest.

Discovery shows direction.

Authentication attempts show intent.

Enumeration shows focus.

Queries show action.

Service exploration shows progression.

Together, they give defenders something much more useful than another isolated alert.

They give them a view into what someone was trying to do.

See how Tero turns reconnaissance into investigation-ready evidence →