MITRE ATT&CK T1046 Network Service Discovery: Spotting Enumeration Early

Almost every hands-on intrusion pauses to ask the same question from inside the network: which hosts are listening, on which ports, running which services, and which of them can be exploited or logged into next. MITRE ATT&CK T1046 Network Service Discovery, in the Discovery tactic (TA0007), covers that internal enumeration: port, vulnerability and wordlist scans, probing cloud hosts from a foothold in a VPC, and on macOS, Bonjour (mDNS) browsing for advertised services. It has no sub-techniques and applies to Containers, IaaS, Linux, macOS, Network Devices and Windows in ATT&CK v20. This guide is for SOC analysts and detection engineers who need detections that fire on real scanning without drowning in alerts from vulnerability scanners and monitoring tools. For the wider network control set, see the Network Security Guide; for scanning of your internet perimeter before compromise, see the T1595 Active Scanning Defensive Guide.

Key takeaways

• It is a pivot point, not a goal. Service discovery sits between the first foothold and lateral movement or exploitation of remote services, so catching it buys time before ransomware or data theft.
• Adversaries prefer tools you already run. CISA reports Volt Typhoon trying the Advanced IP Scanner already present for administration, and Medusa actors using Advanced IP Scanner and SoftPerfect Network Scanner. Tool-name rules alone miss this.
• Detect the shape, not the binary. ATT&CK's detection strategy DET0376 correlates process creation with many outbound connections to sequential hosts or ports in a short window.
• Baseline your legitimate scanners. Vulnerability scanners, monitoring and asset discovery tools generate the same pattern; allowlist them by source host and service account, and alert when those identities scan from anywhere else.
• Exposure reduction is the mitigation. ATT&CK lists three: M1042 close unneeded ports and services, M1031 network intrusion prevention, and M1030 network segmentation.

What the technique covers

ATT&CK describes adversaries listing services on remote hosts and network infrastructure devices, including services that may be vulnerable to remote exploitation, typically with port, vulnerability or wordlist scans using tools brought onto a system. In cloud environments the same activity targets other cloud hosts, and where the cloud network is connected to on-premises networks, services there too. On macOS, the Bonjour mDNSResponder daemon advertises a host's registered services, so an adversary can browse for, say, SSH or screen sharing on other Macs without sending a classic port scan.

T1046 is about services. Finding which hosts exist is T1018 Remote System Discovery, listing a host's own connections is T1049 System Network Connections Discovery, and enumerating shares is T1135. Scanning from outside before compromise is T1595 Active Scanning. Keep those distinctions in your detection tags so coverage reporting stays honest.

How adversaries use it: cases from ATT&CK and advisories

• Volt Typhoon (G1017): CISA advisory AA24-038A, cited by ATT&CK, says the group used commercial tools, living off the land utilities and appliances already present on the system for network service discovery. It names a UPX-packed command-line port scanner, ScanLine, and an attempt to use Advanced IP Scanner that was already on the network for administration. See the Volt Typhoon Threat Actor Profile.
• Medusa Group (G1051): CISA advisory AA25-071A reports Medusa actors using Advanced IP Scanner and SoftPerfect Network Scanner for initial enumeration, and commonly scanning ports 21, 22, 23, 80, 115, 443, 1433, 3050, 3128, 3306 and 3389 once inside. That list doubles as a watchlist for internal fan-out rules. See the Medusa Ransomware Threat Actor Profile.
• TeamTNT (G0139): ATT&CK records the group using masscan to search for open Docker API ports and Kubernetes clusters. Its 2020 worm scanned for Docker APIs reachable without access control, then read AWS CLI credential files from each host it landed on: service discovery led directly to stolen machine credentials. See the TeamTNT worm analysis.
• Anthropic AI-orchestrated Campaign (C0062): ATT&CK records the adversary using Claude Code to enumerate internal network services and endpoints across targeted environments. The operators connected agent instances to commodity security tools and mapped infrastructure in parallel, at machine speed. See the Anthropic GTG-1002 campaign analysis.
• Salt Typhoon (G1045): ATT&CK, citing CISA advisory AA25-239A, records the group scanning open ports and services within victim environments, a reminder that telecommunications and network device estates are in scope. See the Salt Typhoon Threat Actor Profile.

ATT&CK lists many more procedure examples, from ransomware groups using NetScan to commodity frameworks such as Cobalt Strike and Empire with built-in port scan modules. The common thread is that discovery runs from a host the adversary already controls, often under a legitimate account.

What to detect and where

ATT&CK v20 detection strategy DET0376 has four analytics. The data components and log sources below are the ones ATT&CK names:

Rules that work in practice

• Fan-out by source: count distinct destination IP and port pairs per source host in a short window (for example 5 minutes) from flow logs or firewall logs, and alert on outliers against that host's own baseline. Workstations rarely talk to dozens of internal hosts on database or RDP ports.
• Failed connection ratio: scans produce many resets, rejects and timeouts. A high share of failed or rejected connections from one source is a stronger signal than volume alone and catches slow scans.
• Process to network join: on endpoints, join the process that opened the connections (Sysmon Event ID 3 carries the image path) with its parent and user. A scanning burst from a shell spawned by an Office application, web server or remote management agent deserves priority.
• Admin tools in the wrong place: legitimate scanners such as Advanced IP Scanner running on a host or under an account that is not on the scanner allowlist, or newly written to a temp or user directory.
• Port watchlists: internal connection attempts to remote access, database and container management ports (3389, 22, 1433, 3306, the Docker API and kubelet ports) from sources that have never used them.
• Cloud findings: AWS GuardDuty's Recon:EC2/Portscan finding, derived from VPC flow logs, reports an EC2 instance trying to connect to multiple ports on a remote host over a short period; Impact:EC2/PortSweep reports an instance probing one port across a large number of public addresses. Equivalent flow log analytics in other clouds give the same signal: an instance that suddenly fans out.
• Deception: a decoy host or service that no legitimate system should contact produces near-zero false positives. Any connection to it is worth a look. See the Deception Technology Guide.

Noise and baselining

The biggest source of false positives is your own tooling: vulnerability scanners, network monitoring, asset discovery, configuration management and some EDR and backup agents. Build an inventory of each, with its source hosts, service accounts, schedule and target ranges. Suppress on that full tuple, not on the tool name, so an adversary who copies the scanner to another host or reuses its service account outside its window still alerts. Review the allowlist quarterly. For tuning guidance across techniques, see the ATT&CK Detection Strategies and Analytics Guide.

Mitigations

The following are NHI Mgmt Group recommendations that build on those mitigations:

• Reduce what a scan can find: Kubernetes network policies that deny pod-to-pod traffic by default, cloud security groups that allow only named sources, and no management ports on user subnets. See the Kubernetes Network Policy Guide.
• Control scanning tools: application control that permits network scanners only on designated admin hosts. See the M1038 Execution Prevention guide.
• Flow visibility everywhere: VPC or VNet flow logs on, NetFlow or IPFIX from core switches, and retention long enough to look back over an investigation window.

Where identity fits

Scanning runs under an identity, and the most dangerous scanners are trusted ones. Vulnerability scanners and discovery tools often hold privileged service accounts with credentials for every host they authenticate to; if an adversary takes over that account or its host, their scanning blends into a scheduled job. Restrict each scanner service account to its source hosts and time windows, alert when it is used elsewhere, and store its credentials in a vault rather than in the scanner's configuration. In cloud, an instance that starts scanning should prompt a check of what its role can reach, because the next step in cases such as TeamTNT was harvesting credentials from the hosts it found.

How to put it in place

1. Inventory legitimate scanners: list every tool, host, account and schedule that performs scanning or discovery, and agree an owner for each.
2. Turn on telemetry: Sysmon Event IDs 1 and 3 (or EDR equivalents) on Windows, auditd execve on Linux, flow logs in every VPC or VNet and on core network segments.
3. Deploy fan-out and failed-connection rules in alert-only mode: run them for two to four weeks, tune thresholds per segment, and add the scanner allowlist on the full tuple.
4. Add high-fidelity signals: decoy services, scanner-binary-out-of-place rules and port watchlists.
5. Test: run an authorised scan from a workstation, a server and a cloud instance in a test segment, and confirm each produces an alert with the process, user and host attached. Repeat with a slow scan.
6. Promote and respond: move tuned rules to production with a triage runbook: identify the process and account, check the parent chain, isolate the host if the source is not allowlisted.
7. Roll back safely: if a rule floods the queue, lower its severity or narrow its scope rather than disabling it, and record the change.

Decision guidance

• Network or endpoint detection: flow data sees every scan regardless of tool but not the process; endpoint telemetry names the process and user but misses unmanaged hosts and network devices. Use flow data for coverage and EDR for attribution.
• Block or detect: blocking scans with IPS inline can break legitimate discovery; start with detection internally and block only on segments where no scanning is expected, such as OT or management zones.
• Small organisations: turn on host firewalls, cloud flow logs and your provider's managed threat detection, and place one or two decoy services.
• Large organisations: add east-west sensors, per-segment baselines, scanner identity controls and regular purple-team tests.

Measurement

• Coverage: share of subnets and cloud networks with flow logging enabled and ingested.
• Detection latency: minutes from the start of an authorised test scan to an alert.
• Allowlist hygiene: number of scanner allowlist entries reviewed in the last quarter, and number removed.
• Noise: false positive rate of fan-out rules per week, tracked after each tuning change.
• Exposure: count of internally reachable management and database ports on user subnets, trending down.

Common failure patterns

• Tool-name-only rules: alerting on nmap while the adversary uses the admin scanner you already approved, as CISA describes for Volt Typhoon.
• Blanket scanner suppression: suppressing all traffic from a scanner's IP or tool name, so a compromised scanner host is invisible.
• Perimeter-only IDS: sensors at the internet edge with nothing watching east-west traffic, where T1046 actually happens.
• Flow logs off in cloud: no VPC flow logs, so an instance probing the network leaves no record. TeamTNT's worm moved between exposed Docker hosts in exactly this kind of blind spot.
• Flat networks: every workstation can reach every server port, so one scan maps the whole estate.

Framework mapping

Practitioner checklist

• Inventory every legitimate scanner by tool, host, service account, schedule and target range.
• Enable Sysmon Event IDs 1 and 3 or EDR network telemetry on Windows, and auditd execve on Linux.
• Turn on flow logs in every VPC or VNet and on core network segments, with adequate retention.
• Deploy fan-out and failed-connection-ratio rules, tuned per segment.
• Alert on scanner tools and scanner service accounts used outside their allowlisted hosts and windows.
• Watch internal connections to remote access, database and container management ports from new sources.
• Place decoy services that no legitimate system should contact.
• Close unused ports and enforce deny-by-default segmentation between zones.
• Test detections with authorised fast and slow scans from workstation, server and cloud sources.

Standards and references

• MITRE ATT&CK: T1046 Network Service Discovery
• MITRE ATT&CK: TA0007 Discovery
• CISA: PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (AA24-038A)
• CISA: #StopRansomware: Medusa Ransomware (AA25-071A)
• AWS: GuardDuty EC2 finding types
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: ATT&CK Discovery Tactic (TA0007) Guide, T1018 Remote System Discovery, T1135 Network Share Discovery Defensive Guide, M1030 Network Segmentation, M1031 Network Intrusion Prevention.