How T1049 system network connections discovery reveals attacker mapping
When a host shows unusual enumeration, the SOC lead needs to decide quickly whether the activity is discovery or routine administration. T1049 System Network Connections Discovery is the ATT&CK technique that describes an adversary listing the network connections a system has open and the services it is listening on, which tells the attacker which hosts the system talks to and where it can go next. It is catalogued under the Discovery tactic (TA0007), which ATT&CK describes as the adversary trying to figure out the environment. In intrusions it typically appears after initial access has been gained and before lateral movement, once the attacker needs a map of the local network. This page targets Enterprise ATT&CK 20.0, which MITRE released on 2026-10-13 according to the attack-stix-data repository index. Mappings change between releases, and techniques can be renamed, deprecated or revoked, so confirm the version your detection content references before you rely on any technique ID. The MITRE ATT&CK tactic page for Discovery is the natural starting point for checking how the tactic is framed in the version you run. Ask your detection engineering team which ATT&CK version their Sigma rules and analytics were written against. For the SOC lead, the practical question is whether the activity on this host is consistent with a user or service doing legitimate troubleshooting. Decide in advance which hosts are expected to run connection listing commands, such as build servers or network administrators' workstations, and which should never do so. Any listing activity on a server that normally has no interactive users should be escalated for triage, with the parent process and the account context recorded before the host is touched.
Which telemetry shows T1049 on each platform
This table maps each data component ATT&CK links to T1049 to the platforms where it applies and the open-source collector that captures it. Read each row as a question: if this telemetry is missing on a platform, which blind spot does that leave? Confirm analytic IDs against the ATT&CK version your detection library targets, because v18 moved detections into detection strategies and analytics.
| Data component | Signal to look for | Platforms and collector |
|---|---|---|
| Process Creation (DC0032) | Execution of common network state utilities by unexpected parent processes or service accounts | Linux and macOS: Auditd or Wazuh agent process logs. ESXi and IaaS hosts: forward host logs to Wazuh or Security Onion |
| Command Execution (DC0064) | Command lines that request socket or connection tables, especially from scripts, cron jobs or web service accounts | Linux and macOS: Auditd execve records or Wazuh command monitoring. Sysmon for Linux where deployed |
| OS API Execution (DC0021) | Native API calls that enumerate active connections, mainly relevant on hosts where the platform exposes these calls | Confirm coverage per platform with your agent vendor. Treat as a supplementary signal on Linux and macOS |
| Network Traffic Content (DC0085) | Protocol content showing connection enumeration activity, such as management traffic from unexpected sources | Zeek for protocol logs and Suricata rules for content matches across monitored segments |
| Network Connection Creation | Bursts of short-lived outbound or inbound connections from a single host to many destinations | Zeek connection logs and Security Onion dashboards. Confirm the sensor sees east-west traffic on IaaS and ESXi management networks |
| Process Access (DC0035) | Reads of process metadata tied to network ownership, typically on Windows hosts | Limited relevance on Linux and macOS. Use as a cross-check where Windows endpoints are in scope |
Detection ideas for T1049 that a SOC can tune
T1049 System Network Connections Discovery shows up as a sequence of small, ordinary-looking actions on a host or management plane. The four cards below combine process, command, network and hypervisor signals, and each one needs thresholds set against the baseline of the environment before it can be trusted. Every card lists the false positive sources a SOC should exclude or label before tuning.
Network state tools run by non-admin users
Process Creation events for tools that report sockets, listening ports or established sessions, launched by accounts that do not normally administer the host, are a direct signal for T1049. Alert on the parent process, the user context and the host role together, so a web service account running these tools on a production server stands out. Tune by host group: workstations and build agents will be noisier than database servers. False positives come from monitoring agents, vulnerability scanners and health checks that run under service accounts, so maintain an allowlist keyed on parent path and signed binary, not on tool name alone.
Short-window enumeration command bursts
A single network status query is weak evidence, but several enumeration steps on one host within a short window is a stronger pattern. Count distinct network-state commands per user and host over a sliding window, and raise the alert when the count crosses a threshold you set from a two-week baseline. Include neighboring discovery steps such as interface and routing queries in the same window to catch chained reconnaissance. False positives include configuration management runs, patch tooling and incident responders who legitimately collect state, so correlate the burst with change tickets and deployment schedules.
Local enumeration output leaving the host
Network Traffic Content can reveal when the text output of local connection listings is sent off the host, for example in plain text over an unexpected protocol or to a destination the host has never contacted. Inspect outbound flows from servers that should not send tabular system state to external addresses, and flag payloads that carry socket or port tables. Confirm sensor coverage first, because encrypted traffic limits content inspection and you may need metadata-based rules instead. False positives include legitimate diagnostic uploads to vendor support, log shippers and backup agents, so keep an explicit list of approved destinations.
ESXi and IaaS management plane activity
On ESXi hosts and cloud control planes, look for management sessions that query network configuration and connection state for many virtual machines or instances in a short period, especially when they originate from identities that do not own those workloads. Forward hypervisor shell and API audit records to your SIEM and compare session source addresses against your administration jump hosts. False positives come from configuration management, backup products, inventory and asset tools, and cloud health checks that poll the same APIs on a schedule, so exclude named service identities and document each exclusion with its owner.
How to validate a T1049 detection before relying on it
This sequence shows how a team proves that its T1049 analytic fires on the intended network-state enumeration, stays quiet during normal operations and produces records that can be traced to a specific ATT&CK and rule version. It turns a rule that looks correct on paper into evidence the SOC can defend.
Pin the ATT&CK and rule versions
Before any test, the detection owner records the ATT&CK version the mapping targets, the identifier and version of the analytic, and the data components it depends on, such as Process Creation (DC0032) and Command Execution (DC0064). Enterprise ATT&CK 20.0 is the version these pages use, and the owner should confirm it against the MITRE updates page before writing the baseline. The step is complete when a single document names all of these items and a second engineer has reviewed it.
Define the expected behavior of the analytic
The detection engineer writes down, in plain words, what the analytic should match: which host classes are in scope (for example Linux, macOS and ESXi hosts), which process or command telemetry should appear, which network-state fields should be present, and which conditions should suppress the alert. This written expectation is the yardstick for every later result. The step closes when the team can explain what a true positive and a true negative look like in the lab and in production.
Agree the emulation scope with the cyber range team
The red or purple team and the defenders agree in writing on the test hosts, the time window, the accounts used and the stop conditions. The emulation is limited to network-state enumeration on those hosts. The operators should not be given command lines by this page, and the agreement should say so. The step is complete when the signed scope names the hosts, the owner of each host and the person who can halt the exercise.
Run the agreed emulation on test hosts
The test team runs the agreed network-state enumeration on the isolated hosts while the defenders watch the pipeline in real time. Operators log the start and end time of each activity, the host and account used, and the expected outcome. Defenders confirm that the raw events reached the SIEM, such as in Wazuh or Security Onion, before judging the alert. The step closes with a timestamped activity log that matches the events the team saw.
Confirm the alert fires with the right fields
Each emulated activity is compared with the alert it should have produced. The reviewer checks that the alert fired, that it names the correct host and account, that the process and command fields are populated, and that any network-state fields the analytic depends on are present in the event. A missing field counts as a failed test even if an alert appeared. The step closes when every expected activity has a matched alert or a logged gap with a cause.
Measure false positives over a normal business period
The rule runs in a monitored, non-alerting mode against production-like telemetry for a normal business period that the owner sets and documents. Analysts triage every alert and tag it as benign or suspicious, noting which administrative tools, monitoring agents or backup jobs triggered it. The team then decides whether to tune exclusions, narrow the scope or accept the rate. The period length should be agreed with the SOC rather than copied from a template, and the step closes with a tagged alert list and a documented decision on each recurring source.
Record results against the versions in use
The team writes a validation record that lists the ATT&CK version, the analytic version, the test scope, each expected behavior, the observed result, the false positive tags and the tuning decisions. The record is stored with the rule in version control so that a later ATT&CK release that renames or revokes the technique triggers a re-test. The step is complete when the record is approved by the detection owner and the SOC lead.
Schedule re-validation after changes
The team sets a trigger for re-validation whenever the analytic changes, the telemetry source changes, the host configuration changes or a new ATT&CK version is adopted. The trigger should be written into the change process so it does not depend on memory. The step closes when the trigger is documented and an owner is named for each detection, which gives auditors and assessors a repeatable record.
Preventive controls that reduce T1049 exposure
T1049 succeeds when an adversary can query connection state from a host or account it should not reach, and it is most useful to them when the surrounding network is flat and logging is thin. The six ATT&CK mitigations below work on different parts of that problem: who can run enumeration, what each host exposes, how far a foothold can see, and whether the activity is recorded. Treat them as a set, and confirm each one against your own estate rather than assuming the vendor default applies.
Audit (M1047)
Audit (M1047) makes sure that commands and sessions used to list connections are recorded, which is what turns a quiet enumeration step into a detection. For T1049, the question is whether process creation events and command history from administrative shells, container exec sessions and cloud management consoles reach your central store with the fields needed to identify the caller. Confirm that audit rules cover the utilities your Linux, macOS and ESXi hosts use to show sockets and sessions, and that retention is long enough for your investigation timelines. Gaps in audit coverage are the most common reason T1049 goes unnoticed.
Operating System Configuration (M1028)
Operating System Configuration (M1028) covers hardening settings that limit which local users and processes can read socket and session information. On multi-user Linux and macOS hosts, restricting process visibility and tightening permissions on tools that expose connection tables reduces what a low-privileged account can see. Check that hosts do not expose unnecessary management services, that default shells and privilege elevation are restricted to named groups, and that ESXi and hypervisor management interfaces are not reachable from general workstation networks.
Network Segmentation (M1030)
Network Segmentation (M1030) limits how far a host's connection table is useful to an adversary. If a compromised workload can only reach its own tier, the connections it reports reveal little about the rest of the environment. Review whether production, management, backup and developer networks are separated by enforced access rules, not only by addressing, and whether east-west traffic between workloads is restricted to documented flows. Confirm these rules with your network team, because many segmentation projects are partial.
Network Intrusion Prevention (M1031)
Network Intrusion Prevention (M1031) addresses the network side of T1049, where enumeration output or follow-on connections to management ports can be inspected and blocked. Intrusion prevention rules tuned for unusual administrative protocol use from workloads that should not perform it can interrupt activity before it spreads. Confirm which sensors sit on east-west paths, not only at the perimeter, and whether blocking mode is enabled for the rules you depend on. Alerts that nobody triages provide little protection, so pair this control with a documented response owner.
Disable or Remove Feature or Program (M1042)
Disable or Remove Feature or Program (M1042) reduces the number of utilities and services that an adversary can use to list connections. Container base images, jump hosts and hardened server builds often carry diagnostic packages that are useful to operators and equally useful to an attacker. Inventory these packages in each image and host build, remove those not required for operations, and document exceptions. Confirm the list with your platform and operations owners, since removing a tool used during incident response can slow your own investigators.
User Account Management (M1018)
User Account Management (M1018) controls who can run connection enumeration in the first place. T1049 is often performed by accounts that were granted broad read access for troubleshooting and never reviewed. Review which groups can obtain shell access to production hosts, which service accounts have interactive logins, and whether privileged access is time-bound and approved. Confirm that accounts used by monitoring agents and backup tooling are scoped to what they need, because they are frequently the easiest accounts to reuse.
Triage steps when a T1049 detection fires
Start by deciding whether the alert describes a real administrative action or an adversary enumerating connections on the host. For a T1049 System Network Connections Discovery alert, first confirm the process lineage: which parent launched the process that listed sockets or sessions, whether that parent is a management agent, a monitoring tool, an interactive shell or a script runner, and whether the binary path and hash match what is expected on that host class. Then establish the user context: the account that owned the process, whether it was a service identity or a person, whether that identity logged on interactively, and whether it was elevated at the time. An ESXi host, an IaaS instance and a Linux or macOS workstation each have different normal administrative patterns, so compare the event against the baseline for that platform rather than a generic rule.
Next, check whether the activity matches an approved task. Ask the change or operations team whether a maintenance window, incident response, a health check or a vendor support session was scheduled for that host and time. Confirm whether the owning service account is documented in your privileged access inventory. If nothing matches, correlate the alert with other signals on the same host over the surrounding period: authentication events (including new or unusual logon sessions and failed attempts), other discovery alerts such as System Network Configuration Discovery (T1016) or Network Service Discovery (T1046), and any file access or command execution that suggests staging. A single discovery command is weak evidence on its own. A short sequence of discovery activities following an unexpected logon is strong evidence.
Before isolating the host, capture volatile evidence of the network state at the time of the alert. Record active connections, listening sockets, owning processes, routing and ARP tables, and DNS cache where your platform exposes them, and export the matching network flow records from your sensors. Keep the raw output and hash it, because a later reboot or a stop of the suspicious process will erase it. Then decide on containment with the system owner: isolation is justified when the lineage or account cannot be explained, when other alerts corroborate the activity, or when the host holds sensitive data. Otherwise, document a monitored state with tighter logging. Record the decision, the evidence collected, the people consulted and the time of each step in the incident record so that the reasoning can be reviewed later.
Rehearsing T1049 detection in a private cyber range
This segment mirrors a small fleet of Linux and macOS workstations joined to the range's directory and reporting to a Wazuh manager and a SIEM. The red team runs a scripted, pre-approved discovery activity from one workstation so the blue team can practice spotting host-level enumeration of network connections. Injects should arrive as an alert queue and a short shift handover note, not as instructions about what was executed. Confirm with your range provider which endpoint agent versions and log sources are present before the exercise starts.
- Topology: Two or three endpoints per operating system, a jump host, and one segregated test subnet. Record which hosts forward process and command telemetry to Wazuh.
- Injects: A ticket referencing an unusual process on a developer laptop, followed by a second ticket about a macOS host that shows repeated short-lived network queries.
- Good detection: Analysts correlate process creation and command execution events by host and user within a short window, and a Wazuh or SIEM rule fires on the combination, not on a single benign tool.
- Good response: The ticket records the host, user, time window and evidence; the analyst confirms whether the activity is authorized before containment, and isolates the endpoint only if the range rules allow it.
- Baseline: Capture normal administrative activity on the same hosts so false positives are measured, not guessed.
Check that every rehearsed detection has a documented expected alert and a named owner before scoring the exercise.
This segment covers the management plane: an ESXi host or hypervisor management network and an IaaS control account with audit logging enabled. Discovery of network connections on a hypervisor or cloud management console is a high-impact signal, so the range should test whether management-plane events reach the SIEM with usable identity context. Confirm which audit logs your platform exposes, their retention and whether they can be forwarded, because these details differ by product and version.
- Topology: A small ESXi lab with a management VLAN, a bastion host, and an IaaS project or account that mirrors production logging settings.
- Injects: An administrator session on the bastion that the change calendar does not explain, followed by a cloud audit notice for an unfamiliar API caller.
- Good detection: Analysts link the management session, the account identity and the event time across the hypervisor or cloud audit trail and the bastion logs, and the SIEM groups them into one case.
- Good response: The team verifies the caller with the account owner, reviews recent privilege grants, and rotates or restricts credentials through the documented change process before any containment step.
- Evidence: The ticket keeps the audit record identifiers, screenshots of the relevant view, and the decision log so an auditor can follow the reasoning.
Confirm whether your hypervisor and cloud audit events can be exported without a paid add-on, and what those exports contain.
This segment places Zeek and Suricata sensors on the range's east-west and egress paths so the blue team can see network-side evidence of discovery. Network connection records, protocol metadata and Suricata alerts are the telemetry here, and the exercise tests whether analysts can tie a flurry of connection attempts to a source host seen in the endpoint logs. Sensor placement, traffic mirroring and packet capture limits should be written down before the exercise, because they decide what can be seen at all.
- Topology: One sensor on the workstation subnet and one on the management VLAN, both feeding the same SIEM index so events can be joined by time and address.
- Injects: A Security Onion or SIEM notice showing many short connection records from one address to several internal targets, with no matching change request.
- Good detection: Analysts use connection logs to measure breadth and rate, and confirm the source with endpoint telemetry; a Suricata or custom rule fires on the pattern with a documented threshold and tuning note.
- Good response: The team blocks or isolates the source only through the range's approved containment path, then preserves the relevant connection logs and pcap for the case record.
- Validation: Compare alert counts before and after tuning, and record which true positives were missed so the rule backlog reflects real gaps.
Check sensor coverage and retention settings with your platform owner, since they limit what the exercise can prove.
Common questions from SOC leads about detecting T1049
How do we separate T1049 activity from routine monitoring and administration?
Separate it by context, not by the command alone. Routine monitoring agents, configuration management and health checks also query socket tables, so a single execution of a network connection listing tool says little on its own. Build a baseline of which service accounts, parent processes and hosts normally perform these queries, then alert on deviations such as an interactive shell, an unfamiliar parent process, a user account outside its usual role, or a burst of queries across many hosts in a short window. Confirm the baseline in your own environment with your platform and operations teams before you tune any rule, because the noisiest sources are often internal tools nobody has documented.
Is network content inspection needed, or is host telemetry enough for T1049?
Host telemetry covers most of the T1049 detection need, because the behavior happens on the endpoint through process creation and command execution records. Network Traffic Content adds value where a host is untrusted, where logging is incomplete, or where the discovery activity is followed by unusual outbound or lateral traffic. Open-source sensors such as Zeek and Suricata can record that traffic when they sit where the relevant flows pass. Decide this by reviewing which hosts have reliable process logging today and where your sensors can see east-west traffic. Confirm the data component mapping for your ATT&CK version before you commit sensor capacity to it.
How do we handle telemetry gaps on ESXi and IaaS platforms?
Treat ESXi hosts and IaaS control planes as separate evidence sources, because a Linux process log on a guest does not show what the hypervisor or cloud API recorded. For ESXi, confirm which host logs are forwarded and whether shell access is audited. For IaaS, confirm which control plane and API activity logs are enabled, their retention, and whether they reach your central store. Where a source is missing, record it as a known gap with a compensating control, such as restricting management access, rather than assuming coverage. Ask your platform owners to document each gap so auditors and responders know what the detection cannot see.
How often should we revalidate T1049 detections after an ATT&CK version change?
Revalidate whenever the ATT&CK version your mappings target changes, and whenever a release touches the technique, its sub-techniques or the data components it relies on. MITRE's releases in the recent cycle replaced detections with detection strategies and analytics and updated data components, so a rule written against an older mapping may no longer match the current guidance. Record the ATT&CK version in each detection's metadata, review the release notes for changes to T1049, and rerun your cyber range test cases against the updated analytic. Agree the review cadence with your detection engineering owner, since the trigger is the release, not a calendar date.
What evidence should we keep to show T1049 detection controls work?
Keep evidence that links each control to a test result. Useful items include the detection rule and its version, the ATT&CK version and data components it maps to, the log sources and their retention settings, the cyber range test plan and the dated results, the tuning decisions with their reasons, and the response playbook. Store these in a version-controlled location with a named owner. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors decide whether the evidence is sufficient, so ask your assessor early which format they expect.
Can our own SOC build and run these detections, or do we need outside help?
Many SOC teams can build the basic detections themselves if they already run a SIEM, endpoint logging and a documented detection lifecycle. Outside help is most useful for the parts that need a second pair of hands or a safe place to test: mapping coverage across platforms, building a private cyber range to rehearse the activity, and documenting evidence for an assessment. Scope the work in writing with clear deliverables before it starts. An in-house team should estimate its own effort by listing the platforms, log sources and rules in scope, then comparing that list against current staff capacity.
What drives the cost of a T1049 detection program, and what should we ask for in a quote?
The main cost components are staff time for mapping and tuning, log storage and retention, sensor capacity for network content, and the cyber range environment used for rehearsal. Costs recur through storage, sensor operation, rule maintenance after each ATT&CK release, and periodic exercises. Costs fall when logging is already centralized and when the platform inventory is small and documented. In a quote, ask for the platforms and log sources in scope, the ATT&CK version targeted, the test cases rehearsed, the evidence delivered, what is one-time versus recurring, and which items you must provide yourself. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen builds T1049 detections and range scenarios
DeployOpen approaches T1049 System network connections discovery as a written, fixed-scope engagement inside your own environment. The work covers detection content, validation in a private cyber range and the documentation your team needs to operate it.
How we scope
- Agree which platforms are in scope for T1049, such as ESXi, IaaS, Linux and macOS hosts.
- Confirm the telemetry sources available, including process creation, command execution and network traffic content.
- Record the ATT&CK version the detections target, so mappings stay accurate after future releases.
How we build
- Write detection logic for T1049 in Sigma and map it to the chosen open-source stack, such as Wazuh or Zeek.
- Tune rules against your normal administrative activity to reduce noise from routine network inventory tasks.
- Build range scenarios that replay connection enumeration on each in-scope platform to test the detections.
How we hand over
- Deliver rule files, data source mappings and validation results for T1049 with clear version notes.
- Document triage steps, escalation paths and the mitigations linked to T1049 for your analysts.
- Run a walkthrough with your security operations team so they can rerun the range exercise themselves.
How we support
- Offer ongoing support and continuous testing for T1049 detections as a retainer, if your team wants it.
- Review detection performance after platform upgrades or changes to logging configuration.
- Confirm with your team which ATT&CK releases trigger a review of T1049 mappings and rule content.
