How T1046 network service discovery shows up in your environment
A SOC lead sees a spike of connection attempts across a subnet at 2 a.m. and must decide within minutes whether it is the scheduled vulnerability scan or an intruder mapping services. T1046 Network Service Discovery is the technique where adversaries enumerate reachable services on hosts and networks to choose their next targets. It sits under the Discovery tactic (TA0007), which ATT&CK describes as the adversary trying to figure out your environment. This page targets Enterprise ATT&CK version 20.0, so every detection mapping below should be checked against that version before it is deployed.
In intrusions, service discovery usually comes early, after an initial foothold or after an attacker lands inside a segment they do not yet understand. The activity matters across Containers, IaaS, Linux and macOS because the same question applies everywhere: which ports answer, which versions respond, and which hosts are worth attention. In a cloud or container estate, a single compromised workload can reach many peers through flat virtual networks, so a sweep that looks small from one host can cover a large part of the environment. Your first decision is therefore which internal ranges and workloads should never originate broad port sweeps, and who owns the authorized scanners that do.
Before tuning any rule, confirm with your vulnerability management team the source addresses, schedules and scan profiles of every authorized scanner, and record them as an allowlist with an owner and review date. Then confirm whether your sensors can see the traffic at all, including east-west flows between containers or instances, since many T1046 detections depend on network telemetry you may not yet collect. Ask your vendors and platform owners which of those flows they log, rather than assuming coverage. Clear answers to these questions determine whether a sweep alert is actionable or just noise.
Which telemetry reveals service enumeration and which tool collects it
This table maps the telemetry that exposes T1046 scanning activity to the open-source collector that captures it and the platforms each signal covers. Read each row as a question: what does the adversary's scanning leave behind, and which sensor sees it first. The main takeaway is that no single source is sufficient, so pair host process telemetry with network sensors and confirm coverage on every platform in scope.
| Signal (ATT&CK data component) | What it reveals for T1046 | Open-source collector and platform coverage |
|---|---|---|
| Process Creation (DC0032) | Scanner or enumeration binaries launched on a host, including tools that sweep ports or banners from a compromised system. Useful for Linux and macOS hosts where interpreters or utilities run locally. | Wazuh agent on Linux and macOS endpoints using auditd or endpoint logging. Confirm Windows and container host coverage separately before relying on it. |
| Network Traffic Content (DC0085) | Protocol banners, handshake content and service responses that repeat across many hosts, showing that a sender is probing services rather than using them. | Zeek and Suricata on sensor taps or mirror ports. Content depth depends on protocol parser support, so confirm which protocols each sensor decodes in your environment. |
| Network Connection Creation (fan-out pattern) | Many new connections from one source to many destinations or many ports in a short window. This pattern is visible even when payloads are encrypted. | Zeek connection logs aggregated in Security Onion or Wazuh. Thresholds must be tuned per subnet because scanners, vulnerability tools and load balancers share the same shape. |
| Cloud and container network flows | Probing of cluster services, instance metadata or internal IaaS endpoints from workloads that should not contact them. | Wazuh agent for host events and Zeek sensors on virtual network taps where the platform allows them. Confirm flow log availability with each cloud provider. |
| Host network connection records | Sockets opened by an unexpected process, which can show local enumeration of listening services on the same host. | Wazuh agent inventory and Security Onion host logs. Coverage on ESXi and network devices is usually indirect, so plan for syslog forwarding and confirm it. |
| Scanner and sensor alert output | Known scan signatures and port sweep rules that name the activity directly, useful for triage but dependent on rule currency. | Suricata rulesets in Security Onion. Confirm rule licensing and update cadence before using them as the sole detection. |
Detection logic for network service discovery that SOC teams can tune
Network service discovery shows up first as patterns in traffic and host activity rather than as a single event. The four cards below describe detection ideas you can build with Wazuh, Zeek, Suricata and Sigma, along with the thresholds you should tune and the benign sources that will trigger them.
Scanning tool process launches on hosts
Host-side detection looks for processes that are launched to enumerate open services, typically from user accounts or parent processes that should never run network sweeps. Build the rule on Process Creation telemetry collected by Wazuh or Sigma-compatible agents, and match on the executable name and parent process rather than on command arguments alone. Expect vulnerability scanners, asset inventory agents and administrators running approved diagnostics to match. Keep an allowlist keyed to host, account and scanner service identity, and review every hit where the parent is an interactive shell or a web service process.
Many-port connections from one source
A single source contacting a large number of distinct destination ports within a short window is the classic horizontal and vertical port sweep pattern. Use Zeek connection logs or Suricata flow records to count unique destination ports per source address over a sliding window, and tune the port count and window length against your normal traffic baseline. Load balancers, backup servers and monitoring collectors can produce similar shapes, so exclude known infrastructure addresses and alert only on sources outside your managed subnets.
Many-host connections to one service
A horizontal sweep appears as one source reaching the same port across many destination hosts, often on administrative services such as remote login or file sharing. Count unique destination addresses per source for each port class, and set separate thresholds for internal subnets with large populations. Vulnerability scanners, configuration management servers and endpoint security consoles are the most common false positives, so maintain a named list of scanner addresses and review the change log whenever that list is updated.
Repeated refused or reset connections
Scanning often produces many connection attempts that are refused or reset by closed ports, which is different from ordinary client failures. Write a rule over Zeek connection states or Suricata flow outcomes that counts rejected or reset attempts per source, and alert when the ratio of failed to successful connections crosses a threshold you set from your own baseline. Health checks, misconfigured clients, retrying applications and load balancers that probe backends can all generate refusals, so correlate hits with known health check sources before escalating.
How to validate that the T1046 detection fires
This sequence proves, in a private lab or cyber range, that a planned network service discovery activity produces the expected events at the host, network sensor and SIEM layers. It also produces a dated record of coverage, alert fidelity and time to alert that the team can compare after each rule change.
Agree scope and rules of engagement in writing
The security lead, the owner of the lab or range, and the engineers who will run the activity agree in writing which source host, which target subnets and services, which time window and which people are allowed to act on alerts. The agreement also names who can stop the activity and how the range is restored afterward. The step is done when every party has signed off and a named contact is reachable during the window.
Define expected events for each detection layer
Before anything runs, the team writes down what each layer should record: process creation events on the source host, network connection creation and network traffic content on the sensors that see the segment, and the matching alert in the SIEM. Each expectation is tied to the ATT&CK version the detection targets, and to the data components used by the detection strategy for T1046. The output is a short expectations sheet that the tester can check against later.
Run the approved discovery activity from the source host
An approved tester runs the agreed discovery activity from the defined source host against the agreed target set, following the written plan and nothing beyond it. The lead records the start and end times, the source identity and any deviations. The step is complete when the activity has ended on schedule and the lead has logged the exact scope that was exercised, so later analysis can match events to this run.
Confirm host and network sensor telemetry
Analysts check the endpoint agent or log pipeline on the source host, then the network sensors that observe the segment, such as Zeek or Suricata feeds. They confirm that the expected events arrived, were parsed correctly and carry the source host, target and timestamp fields the detection depends on. Any gap is recorded against the sensor or host where it occurred, because a missing sensor is a coverage finding, not a detection failure.
Verify the SIEM alert and its fidelity
Analysts confirm that the Wazuh or other SIEM rule fired, that it fired once per discovery pattern rather than flooding the queue, and that the alert contains enough context to triage. They compare the alert against the expectations sheet and label it as a true detection, a partial detection or a miss. The output is the alert record with its rule identifier, fidelity label and the analyst who reviewed it.
Record timestamps, coverage and time to alert
The team writes one results table covering the run: first event time at each layer, alert time, the gap between activity start and alert, sensor coverage across the segments tested, and alert fidelity. Time to alert is calculated from the recorded timestamps, not estimated from memory. The table is stored with the ATT&CK version, rule version and sensor configuration so the run can be reproduced.
Tune rules and re-run the same scope
Where the run showed noise, a miss or a slow alert, the engineer adjusts the rule, sensor filter or log parsing, and records the change in version control. The same scope, source host and expectations sheet are then used for a repeat run. The step is done when the repeat run's results are compared side by side with the first run, and any remaining gap is either closed or accepted in writing by the risk owner.
Preventive controls that reduce what discovery can reveal
Network service discovery succeeds when an adversary can reach many listening services from a position they should not have. The controls below narrow that reach, limit what a scan can return, and shrink the number of services that exist to be found. Each card names a mitigation mapped to T1046 in MITRE ATT&CK and the checks to run in your own environment.
Segment zones to limit reachable services
Network Segmentation (M1030) restricts which hosts and ports can talk to each other across zones, so a foothold in a user subnet cannot enumerate database, management or container control planes. For T1046, the question is which listening services are reachable from each zone, not which exist on the network. Confirm that workload, management and data zones have explicit allow rules, that cloud security groups and Kubernetes network policies default to deny, and that management interfaces are not reachable from general user networks. Review the rules quarterly against the current asset inventory.
Block and throttle scanning patterns
Network Intrusion Prevention (M1031) lets inline sensors drop or rate limit traffic that matches scanning behavior, such as many connection attempts across hosts or ports in a short window. Its effect on T1046 depends on where it sits. Confirm that the prevention engine runs inline at zone boundaries, that its rules cover internal east-west traffic and not only internet ingress, and that blocking is enabled for scan signatures rather than alert only. Test the thresholds, because aggressive limits can also disrupt legitimate scanners such as vulnerability management tools.
Disable services nobody needs
Disable or Remove Feature or Program (M1042) removes services, daemons and optional components that are installed but unused. Every unnecessary listener is a result that discovery can return and a potential entry point. On Linux hosts, compare listening sockets against the approved service list for each role. On container images, remove debugging tools and unused ports from the Dockerfile or base image. Confirm that changes go through configuration management so the reduced state persists after rebuilds and patching.
Keep the asset inventory current
Segmentation and service reduction only work when you know which services exist. A current inventory of hosts, open ports and container workloads gives you the baseline that detection rules compare against. Confirm that the inventory is generated from scans or agents you run yourself, that unexpected listeners raise a ticket, and that shadow instances in cloud accounts are reported to the same owner. Without this baseline, a discovery scan looks the same as routine vulnerability scanning.
Audit access to scanning tools
Audit (M1047) covers the logs that show who ran scanners, from which hosts, and against which ranges. Legitimate scanning is usually scheduled, so an unscheduled scan from a workstation or service account is a useful signal. Confirm that scanner hosts and accounts are on an allow list, that their activity is forwarded to your SIEM, and that scan schedules are documented. Review scanner account permissions so that a compromised user account cannot launch network-wide scans.
What to do in the first hour after a service discovery alert
The first decision is whether the scan is authorized. Check the scanner change calendar and the vulnerability management schedule before anything else, then confirm the source address against the list of known scanner hosts maintained by the security team. If the source matches an approved scanner and the targets fall inside the approved scope, record that and watch for scope creep, such as scans reaching segments that were not in the change request. If the source is unknown, treat the alert as live activity and identify the source host, its owner, and the account that was logged in on it. For a Linux or macOS source, pull the process tree and the active sessions from the host agent, and for a cloud workload, map the source IP to the instance or service identity in the provider's flow or audit logs.
Next, correlate the discovery with what follows. Discovery is usually the prelude to exploitation, so search the same source over the following hours for authentication failures, connections to ports that the scan just found open, new listening services, and outbound sessions from the targets. Your Wazuh or Security Onion dashboards can pivot on the source address across Zeek connection logs and Suricata alerts. Decide on containment based on that evidence: blocking the source at the perimeter or on the affected segment is reasonable when the source is unauthorized and no follow-on activity is seen, while isolating the source host is the stronger step when the host itself shows compromise or the account is suspected of misuse. Make the containment action reversible and record who approved it.
Preserve evidence before you change anything that would overwrite it. Export the relevant sensor records, including the raw packet or flow captures where retained, and snapshot the source host's volatile state through Velociraptor or your EDR before reimaging or powering it off. Notify the owners of the services that were scanned so they can review logs for failed or unusual access, and confirm which of their services answered. Finally, write a short decision record covering the alert time, the triage findings, the containment choice, the approver, and the evidence location. Retain it with the ticket so the post-incident review can test whether the decisions matched the evidence at the time.
Rehearsing T1046 detection in a private cyber range
A private range for T1046 needs at least two network zones so that scanning crosses a boundary the defenders control. Place a simulated user segment, a server segment with Linux hosts, and a container host in its own segment, with the routing and firewall rules between them written down before the exercise starts. Sensors should sit where they see both sides of each boundary, not only on one host. The purpose is to make the discovery traffic observable at the points where a real response decision would be made.
- Segmented zones: Separate user, server and container networks, with documented allow rules between them so the expected traffic is known in advance.
- Linux and container targets: Include Linux servers running a small set of listening services and a container host exposing a few endpoints, so the scan has realistic variety without using production data.
- Sensor placement: Run Zeek and Suricata on span or tap points at each zone boundary, and deploy Wazuh agents on the Linux and container hosts to record process creation.
- Time synchronization: Confirm all sensors and targets share a time source so alert timestamps can be correlated during the review.
- Range isolation: Keep the range off production networks and record the exact scope in writing, including which addresses the attacker simulation may touch.
Before the exercise, confirm with your team which sensor feeds are in scope and which ones your current tooling cannot ingest.
Injects are scripted events that the blue team receives during the exercise. For T1046 the most useful injects simulate network service discovery in a way that resembles routine work, so the team has to judge whether the activity is malicious. Design each inject with a known start time, a known source, and a known set of targets, so the review can compare what the team saw with what was actually run. Keep the attacker-side actions with the range operators and out of the blue team's view.
- Fan-out at an odd hour: A single user workstation begins probing many internal addresses across several ports shortly after midnight, which tests whether the team notices volume and timing outside normal patterns.
- Slow, distributed discovery: The same probing is spread over a longer window from two sources, which tests whether correlation across sensors catches activity that a per-host threshold would miss.
- Discovery from a container: A container workload begins reaching addresses outside its normal service map, which tests whether container and network telemetry are joined.
- Benign look-alike: A scheduled inventory job performs similar reachability checks, which tests whether the team can separate it from the malicious pattern using the approved job record.
- Illustrative example: A workstation scans a server subnet at 02:00 with no ticket, and the team must decide within the agreed window whether to escalate.
Record every inject time so that detection latency can be measured in the debrief.
Good detection for T1046 means the team sees the scanning activity, raises an alert within the window agreed before the exercise, and attributes it to the correct source host and user context. Alerts that fire but name the wrong source, or that fire only after the scan has finished, do not meet the standard. Detection quality should be judged per inject, not as a single pass or fail, because a team may catch the fan-out but miss the slow variant.
- Alert within the agreed window: Define the maximum acceptable time from the first probe to the first alert for each inject, and record whether each inject met it.
- Correct source attribution: The alert should identify the originating host, interface, and where available the process or user on that host, not only a shared gateway address.
- Coverage across sensors: Network-based alerts from Zeek or Suricata should be cross-checked against host process telemetry from Wazuh where a host was involved.
- Low false-positive handling: The benign inventory job should be labeled correctly rather than suppressed silently or escalated without context.
- Rule traceability: Each alert should map to a named rule or analytic that the team can version and tune after the exercise.
Confirm the detection standard with your security leadership before the exercise, because the agreed window and attribution requirements define what the exercise proves.
Good response means the team contains the activity in a controlled way and preserves evidence that supports the investigation. Containment should be proportionate: isolating the source host or blocking traffic between zones is different from disrupting the whole range. Evidence should be collected in a way that keeps timestamps, sensor records and host artifacts intact so the team can reconstruct what was scanned and when.
- Proportionate containment: Block or isolate the originating workstation or the specific zone path, and confirm the containment did not affect the benign inventory job or the server services.
- Clean evidence capture: Export the relevant Zeek and Suricata logs, Wazuh alerts, and host process records with hashes or integrity notes, and store them in the range evidence location.
- Decision record: Log who decided to escalate, when, and on what basis, so the timeline can be checked against the agreed window.
- Eradication check: Confirm the source workstation no longer produces discovery traffic after containment, and that no unexpected accounts or services were changed during response.
- Lessons for the segmentation design: Note which allow rules were broader than needed, since the scan may have reached services that segmentation should have blocked.
After the exercise, compare the decision record and evidence set with the written runbook to see which steps were followed and which were improvised.
DeployOpen runs these T1046 exercises as scoped range engagements, with the range layout, inject list, detection standard and response expectations agreed in writing before work starts. The scope defines which networks, hosts, sensors and attacker-side actions are included, along with the reporting format and the people who may stop the exercise. Ask for this written scope before committing to any delivery, and confirm which parts depend on your own environment and staff time.
- Written scope and rules of engagement: Confirm the address ranges, the permitted attacker actions, and the stop conditions before the first inject.
- Range build and sensor setup: Ask which parts of the Zeek, Suricata and Wazuh deployment are built as part of the range and which are reused from your environment.
- Debrief and tuning output: Request a debrief that maps each inject to the detection and response results, with the rule changes proposed for your own environment.
- Retesting: Ask whether the same inject set can be repeated after tuning, and how the results are compared across runs.
- Client responsibilities: Identify which people, approvals and change windows your team must provide, since these drive how long the exercise takes to schedule.
Request a written quote tied to this scope, and confirm with DeployOpen which deliverables are included before the exercise is booked.
Questions SOC leads and detection engineers ask about T1046
How do we separate authorized vulnerability scans from attacker network service discovery?
Authorized scans are separated by agreement, not by traffic shape, so the first step is a maintained register of scanner source addresses, scheduled windows and owning teams. Alert on any scanning activity that originates outside that register, or that falls outside its windows, and treat the register as a detection input rather than a document. Scanner traffic should be tagged in the SIEM so analysts can see at a glance whether a sweep was expected. Review the register after every change to scanning tools or cloud accounts, because stale entries are the usual cause of noisy or missed alerts.
How should we handle east-west scanning inside Kubernetes and other container clusters?
Container networks produce a lot of legitimate pod-to-pod and service-to-service traffic, so detection needs a baseline of expected connections per namespace and workload. Network telemetry from the cluster, combined with flow records and Zeek or Suricata sensors where traffic is visible, can show a single workload probing many ports or hosts it has never contacted. Confirm with your platform team which network policies and CNI features are available in your cluster before you rely on them for enforcement or logging, since capabilities differ by implementation. Map alerts back to the workload identity so responders know which service account or deployment to investigate.
How do we keep Zeek and Suricata rules current across ATT&CK versions?
Pin every detection to the ATT&CK version it was written against, and record that version in the rule metadata or in your detection repository. Track ATT&CK release notes, since releases can rename, deprecate or revoke techniques, and review mappings for T1046 at each update. Keep the authoritative technique data in the STIX bundles MITRE publishes, so mapping changes can be diffed rather than checked by memory. Assign an owner for each rule set and schedule a review, so that a rule written for a deprecated detection path is retired instead of silently failing.
Can we rehearse T1046 detection without causing an outage on production networks?
Yes, if the rehearsal runs in a private cyber range or an isolated segment that mirrors production logging, not on live business systems. Agree the scope, targets, time window and stop conditions in writing before any traffic is generated, and make sure the network and operations teams know when and where it happens. Use synthetic targets and dummy services so that any disruption stays inside the range. Validate that alerts fire, that they reach the right queue and that responders can follow the runbook, then record the gaps as tracked findings.
What does a T1046 detection engagement cost, and what drives the price up?
Costs fall into a few components: discovery of your logging sources, writing and tuning detections, building or renting a range, running the exercises and documenting the results. Most of these are one-time effort, while sensor upkeep, rule maintenance and periodic re-testing recur. The main drivers are the number of network segments and cloud accounts in scope, the number of container clusters, how much existing telemetry you already collect, and how many ATT&CK versions your detections must cover. Ask any provider, including DeployOpen, for a written scope that lists these items so the quote can be compared. DeployOpen does not publish a price list; a quote follows from the agreed scope.
Can our own team run T1046 detection and testing without an outside partner?
Many SOC teams can run detection and basic testing internally if they have network telemetry, a SIEM, and someone who owns detection content. The gaps usually appear in container visibility, sensor placement across segments, and the discipline of rehearsing response in a range that matches production. Before deciding, check whether you can answer these questions: where your sensors see traffic, how cloud and cluster flows are logged, and who reviews rule changes against ATT&CK updates. An external partner is most useful for a fixed-scope build, a first range exercise, or an independent review of the results.
Which mitigations should we confirm before relying on detection alone for T1046?
ATT&CK maps Network Segmentation (M1030) and Network Intrusion Prevention (M1031) to T1046, so confirm how both are implemented in your environment rather than assuming coverage. Segmentation limits which hosts an attacker can reach, which reduces the value of a sweep, while intrusion prevention can block known scanning patterns on the paths where it is deployed. Verify the actual rule sets, zones and exceptions with your network team, and test them in the range so that blocks and alerts are both observed. Detection still matters, because prevention rarely covers every path, and a blocked scan should still generate a record.
How DeployOpen builds T1046 detections and range exercises
DeployOpen approaches T1046 Network service discovery as a fixed-scope engagement inside the client's own environment. The work covers which platforms, network segments and telemetry sources are in scope, how detections are built on open-source tooling, and how they are rehearsed in a private cyber range before handover.
How we scope
- Agree in writing which platforms count as in scope for T1046, such as Containers, IaaS, Linux and macOS hosts.
- Confirm which telemetry is available, including Process Creation, Network Traffic Content and Network Connection Creation, and where it is collected.
- Record the ATT&CK version the detection mappings target, so later releases can be checked against a fixed baseline.
How we build
- Write detection logic for T1046 in open-source formats such as Sigma rules and map it to the Wazuh, Zeek or Suricata sources in your stack.
- Tune scanning-pattern thresholds against your normal administrative and monitoring traffic to limit false positives.
- Document how the Network Segmentation and Network Intrusion Prevention mitigations are configured and where their logs are reviewed.
How we hand over
- Deliver detection rules, test cases and a validation record showing which simulated discovery activity each rule should catch.
- Run response runbooks through a private cyber range exercise with your security operations staff, and record the observed gaps.
- Provide written configuration and evidence notes that your team and any independent auditor can review.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your team wants it.
- Review detection mappings when a new ATT&CK release renames, deprecates or revokes techniques related to T1046.
- Repeat range exercises on a schedule agreed in the written scope, so detections stay tested as the network changes.
