Network Service Discovery

Before an attacker can move anywhere or exploit anything, they usually need to know what's actually reachable. Network service discovery is that reconnaissance step: systematically probing a network to find out which hosts are alive and which services are listening on them, effectively drawing a map of what's available to attack next.

This is one of the most fundamental reconnaissance techniques there is, and it's also one of the hardest to hide completely, since finding services necessarily means generating network traffic to check for them.

Once inside a network, an attacker who doesn't already know its layout will typically scan it, sending connection attempts across a range of hosts and ports to see what responds. A response tells them a service is running there, which becomes a candidate for the next stage of the attack, whether that's exploitation, credential reuse, or lateral movement.

Doing this from inside the network is a deliberate choice as much as a necessity: scanning traffic that originates internally often faces far less scrutiny than traffic crossing the network's perimeter, since a lot of security tooling is built to watch the edge, not the inside.

Data source: network connection records whose state field separates answered, refused, reset and unanswered; endpoint socket records share a flow id and name the process

{
  "event": {
    "type": "connection",
    "category": "network"
  },
  "source": {
    "ip": "10.10.30.104"
  },
  "destination": {
    "port": 445
  }
}

Prebuilt Elastic rule: Potential Network Scan Detected

This is a threshold problem by nature, not a single-event one: no individual connection attempt looks malicious in isolation, since checking whether a port is open is indistinguishable from a real connection attempt at the packet level. Hunt for the aggregate: group by source.ip and count distinct destination.port values (and distinct destination.ip values) in a given window, then look for outliers far beyond what any single legitimate host would normally generate.

Signature-based detection structurally struggles here, since there's no single malicious payload to match against, only a pattern across many otherwise-ordinary connection attempts. This is exactly why scanning activity from inside a network often requires a purpose-built threshold rule rather than a standard signature.

Legitimate network scanning happens constantly and for entirely benign reasons: vulnerability scanners, asset-discovery tools, monitoring systems, and even some load balancers or health-check systems generate traffic that looks structurally identical to reconnaissance.

The distinguishing signal is whether the source is a known, expected scanning tool running on its normal schedule, versus an unexpected host (a user workstation, a system with no scanning responsibility) suddenly generating the same pattern. Authorized scanners are usually few, well-known, and consistent; an unfamiliar source doing the same thing is a different story.

• MITRE ATT&CK T1046: Network Service Discovery
• Elastic Security: Potential Network Scan Detected

1 scenario in this catalog covers T1046. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →