How T1057 process discovery shows up before an attacker picks a target
A process listing run from an unexpected account or host can be the first quiet sign of an intrusion, and it is easy to dismiss because the command itself is ordinary. T1057 Process discovery sits under the Discovery tactic, TA0007, which MITRE describes as the point where "the adversary is trying to figure out your environment." In Enterprise ATT&CK version 20.0, the technique is catalogued under that tactic, so a SOC analyst reviewing alerts should read a process enumeration as a question about who is looking at the host and why, not as a finding in its own right.
Running processes tell an adversary a great deal in a few seconds. They reveal which security agents, backup clients and monitoring collectors are active, whether a hypervisor management service or a database engine is present, and which applications are worth targeting next. Attackers typically run this step after gaining a foothold, often in the same session as account and network discovery, and before they move laterally or stage tools. An illustrative pattern for a SOC lead: a service account that normally only runs scheduled backups suddenly enumerates processes on several hosts within minutes, then opens a shell. Each event alone looks routine, but the sequence is the signal.
The detection problem is context, not presence. Administrators, configuration management tools, endpoint agents and health checks all list processes constantly, so an alert rule that fires on every enumeration will be ignored within days. Before writing rules, confirm with your platform and endpoint teams which accounts, parent processes and hosts legitimately perform process listing, and record that baseline. Then decide which deviations matter most, such as enumeration by accounts with no administrative role, from hypervisor or network device management contexts, or immediately after a suspicious logon.
Telemetry that reveals process discovery and the open-source tool that collects it
This table maps the data components most often referenced for process discovery to the platforms where they can be collected, the signal to look for and the open-source tool that gathers it. Read each row as a starting point for your own logging design, then confirm what each platform actually exposes. The main takeaway is that Linux and macOS hosts usually provide the strongest process telemetry, while ESXi and network devices depend heavily on what their vendors log.
| Platform | Data component and signal | Collection point and open-source tool |
|---|---|---|
| Linux hosts | Process Creation (DC0032) and Command Execution (DC0064): new process events and command lines of enumeration utilities run by unexpected accounts or parents | Kernel audit rules via auditd, forwarded to Wazuh for correlation with Sigma rules |
| macOS hosts | Process Creation (DC0032) and Command Execution (DC0064): process launches and arguments for process listing utilities, including those started from scripts | Endpoint agent logs forwarded to Wazuh, with Velociraptor used for on-demand process collection during investigation |
| Linux and macOS file activity | File Access (DC0055): reads of process-related paths and per-process information directories by non-system processes | auditd file watches or Wazuh file integrity monitoring, reviewed in Security Onion |
| Process inspection | Process Access (DC0035): one process reading the state of another, where the platform records it | Endpoint telemetry where available; Velociraptor artifacts for collection. Confirm the platform records this event type. |
| ESXi hosts | Process Creation (DC0032) and Command Execution (DC0064): shell and management command activity, if shell or command logging is enabled | Host syslog forwarded to Wazuh or Security Onion. Confirm which shell and command events ESXi exposes in your version. |
| Network devices | Command Execution (DC0064): show-style commands entered on administrative sessions, if the device logs them | Device syslog and AAA accounting sent to Security Onion or Wazuh. Confirm command accounting support with the vendor. |
| Network traffic context | Command Execution and process context correlated with remote management sessions, from Zeek or Suricata metadata | Zeek connection and session logs in Security Onion. Traffic alone rarely shows which process ran the command. |
Detection logic for process discovery that separates reconnaissance from routine operations
Process discovery is noisy on its own because monitoring agents, configuration management and health checks enumerate processes all day. The cards below pair each detection idea with the context that makes it suspicious, the thresholds to tune and the benign sources to exclude, so that T1057 Process discovery alerts point at reconnaissance rather than routine operations.
Enumeration by unexpected accounts
Flag process listing commands run by an account that does not normally perform administration, such as a service account for a web application, a developer account on a production host or a user account on a server it has never touched. Build a baseline per host group from Process Creation and Command Execution records over a period you can defend, then alert on first-seen account and command combinations. Check whether the account has an interactive logon and whether its parent process is a shell or a remote session. Known false positive sources are monitoring agents and configuration management tools that run under dedicated service accounts, so allowlist those accounts by name and parent path rather than by broad group membership.
Bursts of enumeration on one host
Count distinct process enumeration events per host within a short sliding window and alert when the count exceeds the baseline for that host role. A burst matters more when several different enumeration commands run in sequence, since routine health checks usually repeat one command on a fixed schedule. Tune the window and threshold per host class, with separate values for build servers, database hosts and jump hosts. Scheduled jobs, container runtime health probes and backup pre-checks are the common sources of benign bursts, so record their schedules and suppress them by job identifier. Validate the threshold in the cyber range before it reaches production.
Enumeration followed by security or backup access
Correlate a process listing with later access to processes that belong to security agents, log forwarders or backup software on the same host. Discovery that ends in interaction with these processes is a stronger signal than discovery alone, because it suggests an adversary is looking for something to disable or evade. Use Process Access events and File Access events for agent binaries and configuration paths, with a short follow-on window such as minutes rather than hours. Expected false positives include agent upgrades, backup restores and support staff troubleshooting, so require a matching change record or ticket reference before an analyst closes the alert as benign.
Enumeration from non-management sources on ESXi and network devices
On ESXi hosts and network devices, process or task listings should originate from management networks and named administrative jump hosts. Alert when the same listing comes from a workstation subnet, a user segment or an unexpected host, using source address and authenticated account from Command Execution or session logs. Compare against the management network ranges defined in your segmentation design, and confirm with the platform owner which accounts are permitted to run diagnostics. Routine causes include vendor monitoring appliances, backup proxies and scheduled collection from a central logging system, so maintain an explicit source list and review it after each network change.
How to validate that the process discovery detection fires
This sequence proves that the T1057 Process Discovery detection fires on each platform in scope, shows how quickly it fires, and confirms that analysts can act on the alert without drowning in administrative noise. Each step produces a recorded artifact that can be reviewed later.
Agree scope and rules of engagement
The detection owner, the SOC lead, the range operator and the system owner for each test host agree in writing which platforms are in scope (for example ESXi, Linux, macOS and network devices), which accounts may be used, which hours are permitted, and how the exercise is stopped if production systems are affected. Confirm that the test hosts are isolated lab systems, not production assets. The step is done when the signed scope document is stored with the detection record. Confirm with your own legal and change management teams whether any notification is required before emulation begins.
Select an approved emulation method
Choose either an emulation tool that your organization has approved for use in the range, or a documented set of benign activities that perform process listing actions typical of discovery. Record the tool name and version, or the exact activity list, so the test can be repeated. Avoid anything that gives instructions beyond what the detection team needs to verify the telemetry. The step is complete when the test plan names the activity for each platform and the expected ATT&CK technique mapping, tied to the ATT&CK version the detection targets.
Run the activity on a test host per platform
The range operator runs the agreed activity on one isolated test host for each platform in scope, starting with the platform where process creation and command execution telemetry is most mature. Each run is logged with the host name, operator, start and end time, and the account used. The step is done when every platform has one recorded run and the operator has confirmed the activity completed as planned.
Record expected alerts and event timestamps
Before reviewing the SIEM, the detection owner writes down the alert or rule name that should fire for each run, along with the event source, such as process creation, command execution or file access on the monitored host. After the run, the analyst records the timestamp of the source event on the endpoint and the timestamp when the alert appears in the SIEM. The step is complete when each run has an expected alert, an observed alert or a documented gap, and both timestamps.
Measure collection latency and coverage gaps
Calculate the time between the endpoint event and the alert in the SIEM for each platform, and note where the telemetry was missing, delayed or parsed incorrectly. Common gaps include agents that do not forward command logs on network devices or hypervisors that send logs through a separate syslog path. Record each gap with its owner and a planned fix. The step is done when the latency and gap table is reviewed by the detection owner and the platform team that operates the log source.
Test against normal administrative activity
Run the detection over a defined window of routine administrative work on production-like hosts, such as patching, monitoring agent checks, backup jobs and health scripts that list processes. Count how many alerts are raised, group them by process name, parent process and account, and classify each as expected or unexpected. Document the false positive rate that results and the exclusions proposed. The step is complete when the false positive review is signed off by the SOC lead and any exclusions are tied to a named business justification.
Analyst triage and outcome review
Give an analyst who was not involved in writing the rule a copy of the alert from a test run, without the operator's notes, and time how they reach a disposition: true positive, benign, or needs more data. Record which context fields they needed and whether the alert contained them. Compare the outcome to the expected result. The step is done when the triage notes and disposition are stored with the test record, and the alert runbook is updated where the analyst lacked information.
Version and peer review the rule
Store the detection logic, its exclusions, the test results and the ATT&CK version it maps to in version control, with the test evidence linked to each change. Have a second engineer review the rule for logic errors, overly broad matching and unclear naming before it is promoted to production. Re-run the test set whenever the rule, the log source or the ATT&CK mapping changes, since ATT&CK releases can rename or deprecate techniques. The step is complete when the reviewed rule, its version and the passing test evidence are merged into the detection repository.
Preventive controls that limit what process discovery reveals
Process discovery is hard to stop outright because listing running processes is a normal administrative action. The controls below reduce what an adversary can learn from that listing and make the attempt more visible. Confirm each mitigation mapping against the ATT&CK version your detection content targets, because mappings can change between releases.
Audit (M1047)
Audit is the mitigation that makes process enumeration visible in the first place. Confirm that process creation events and command execution are logged on every Linux, macOS and ESXi host in scope, and that logs reach your Wazuh or Security Onion pipeline. Without this, the process listing itself leaves no trace, so review audit coverage before tuning any detection.
User Account Management (M1018)
Process listings show which accounts own which processes, so account scope limits what discovery reveals. Restrict interactive shells and service accounts to the minimum needed, and remove shared administrative logins. Ask your team to confirm which accounts can read process lists of other users on each platform, since default visibility differs by operating system and configuration.
Operating System Configuration (M1028)
Operating system settings determine how much of the process table an ordinary user can read. On Linux, review the process information visibility settings for the /proc filesystem and confirm that hardening baselines apply to every host class. Treat the result as a configuration check to verify in your own environment, not as a guarantee that all process data is hidden.
Network Segmentation (M1030)
Process discovery usually runs after an adversary already has a foothold, so segmentation limits where that foothold can go next. Place management interfaces, hypervisor hosts and build servers in separate zones with explicit allow rules. Confirm that segmentation boundaries are enforced and logged, because a discovered process list is far less useful when the attacker cannot reach the systems it describes.
Network Intrusion Prevention (M1031)
Network intrusion prevention can block the remote tools and transfers that often accompany process enumeration on compromised hosts. Deploy Suricata in inline mode at key egress and east-west points where your architecture allows it, and tune rules against the traffic your environment legitimately produces. Confirm rule coverage with your own testing, since rulesets vary in what they block.
Disable or remove feature or program (M1042)
Unneeded utilities and services expand what a process listing exposes and what an attacker can run once inside. Remove debugging tools, unused agents and legacy packages from production images, and rebuild golden images on a schedule. Ask your platform team to produce a written inventory of installed software per host class, so you can tell an expected process from an unexpected one during investigation.
Triage steps when a process discovery alert fires
When a process discovery alert for T1057 fires, the first job is to confirm who ran the activity and on which host, before deciding whether it matters. Pull the account, the parent process and the source host from the alert, then check whether the same account is known to the owning team. Ask the change calendar and the automation owners whether a patch window, inventory scan, monitoring agent or configuration management run was active on that host at that time. Process listing is routine for administrators and for many agents, so a match to a documented job with a known service account usually closes the alert, provided the command lines and parent processes match what that job is supposed to run. Record the check you ran, not only the conclusion.
If the activity does not match a known job, correlate it with the rest of the host's telemetry over the same window. Look at logon sessions opened shortly before the enumeration, file access to configuration, credential or log locations, and new outbound connections from the same host or from the account. A burst of process enumeration followed by reads of sensitive files or new network sessions raises the priority, while isolated enumeration from a host with no other unusual events is more often a misconfigured script or a administrator checking a service. Keep the time window wide enough to include the minutes before the alert, because the reconnaissance may have started earlier than the first matching event.
Containment should follow evidence capture, not precede it. If escalation is warranted, capture volatile data first, including the running process list, active network connections, logged-on sessions and memory where your forensic procedure allows, then isolate the host from production networks while keeping management access for the response team. Confirm with your incident commander that isolation will not disrupt a business service, and check whether the host is a hypervisor or a shared platform node, since isolating it may affect other workloads. Document the decision in the incident record with the time, the analyst, the evidence captured, the options considered and the reason for escalating or closing the alert, so the outcome can be reviewed later.
Rehearsing process discovery detection in a private cyber range
Build the range with a small set of Linux and macOS endpoints enrolled in your log pipeline, each running the agents your detection design expects. Place them on a segment that mirrors a production server zone so that the process telemetry you collect reflects the same parent and child relationships your analysts see daily. Keep a dedicated benign user account on each host so that every injected action is attributable during review.
- Range topology: Two or three hosts with different roles, such as an application server and an administrative workstation, connected to one log collector and one analysis node.
- Benign injects: Scripted sessions run by the test account that list running processes through standard administrative tools, both interactively and from a scheduled job, so you can compare how each invocation is recorded.
- Detection expectation: An alert fires from process creation or command execution telemetry, is enriched with user, host and parent process context, and reaches triage within the target time your team has agreed in advance.
- Response expectation: The analyst confirms the benign origin, captures the command history and process listing as evidence, and records whether the rule should be tuned for the scheduled job.
- Logging check: Confirm which Linux audit and macOS unified logging sources your range can collect and whether command arguments are captured on each platform.
Check that every inject produced a record in the collector before you score the exercise.
Virtualization hosts and network devices often sit outside the endpoint agent footprint, so their process discovery signals reach the SOC through different paths. Build a range segment with one ESXi host in a lab cluster and one or more network devices or emulated appliances, and route their syslog or API audit output to the same collector used for endpoints. Use a separate administrative account for the exercise so that activity is easy to separate from production.
- Range topology: One ESXi host, one management network segment, one syslog relay and a device or emulator that writes to the same log store as the other tabs.
- Benign injects: Authorized shell or management sessions that display running tasks and service states, with the time and operator recorded in each session.
- Detection expectation: A rule built on shell or command audit records raises an event that names the host, account and source address, and that event is enriched with the asset owner before triage.
- Response expectation: The analyst checks change tickets for the window, confirms the account is authorized, and preserves the relevant log lines in the case record.
- Logging check: Confirm which ESXi shell, host agent and device audit logs your version and configuration can forward, and whether process-level detail is available or only session-level records.
Record any device where the expected signal is missing, because that gap is a finding in itself.
The detection only has value if the SOC handles the alert consistently, so this tab tests the workflow rather than the sensors. Run the injects from the other two tabs as a single scenario, without telling the analysts which events are benign, and time how the alert moves from ingestion to triage to closure. Use the tooling your team already operates, such as a Wazuh dashboard, Security Onion case workflow or Velociraptor collection, so that the exercise reflects daily practice.
- Escalation path: The first-line analyst reviews the alert, decides whether it is benign, and escalates to the on-call engineer with a defined handoff template if the account or host is unknown.
- Evidence capture: Analysts preserve the alert, the raw process and command records, the host context and any collection output in a case folder with timestamps and hashes where your process requires them.
- Triage target: Agree the target before the exercise and measure against it, recording any delay between alert creation and first analyst action.
- Rule tuning: After the exercise, review false positives and missed events, then update the Sigma or local rule, version it, and retest it against the same injects.
- Lessons record: Store the scorecard, the rule changes and the open logging gaps with owners and due dates.
Confirm with your range provider and your SOC lead which tools, retention periods and escalation contacts apply before the exercise begins.
Questions detection engineers ask about T1057 process discovery
How do I tell administrative process checks from attacker enumeration of processes?
Start by treating process listing as ambiguous on its own and judging it by context: who ran it, from which host and session, in what sequence, and what happened before and after. Administrators run process listings during troubleshooting, patching and incident response, so a single ps-style or task listing event is rarely enough to alert on. Build a baseline per host role and per service account for the commands that operations teams normally use. Then raise priority when a listing comes from an account or parent process that does not normally run administrative tooling, from an interactive session that just authenticated from an unusual source, or when it is followed quickly by other Discovery activity such as account, network or system information checks. Document these rules so analysts can explain each alert.
Can ESXi and network devices be monitored at the process level?
Often only partially, and you should confirm the exact telemetry your platform exposes before writing rules. On ESXi hosts, the realistic path is usually to forward host logs and shell or command audit records to a central collector, where Wazuh or a similar SIEM can parse them. Whether those logs contain process-level detail depends on the ESXi version and logging configuration in your environment. On network devices, process-level visibility is commonly replaced by command accounting, authentication logs and configuration change records. Where native process telemetry is absent, detect the surrounding behavior instead: privileged shell logins, unexpected command sessions and access from management networks that should not reach the device. Record every gap in your coverage matrix so auditors and responders know what is not observed.
How should I version detection rules against ATT&CK 20.0?
Name the ATT&CK version in every rule's metadata, mapping file and change record, so a future release cannot silently change what a rule claims to cover. The current Enterprise release referenced for these pages is version 20.0, released on 2026-10-13, and MITRE's update notes state that releases can rename, deprecate or revoke techniques. Keep a mapping table that links each rule to its technique and sub-technique IDs, its detection strategy identifier and the data components it depends on. When a new version is published, diff the relevant STIX bundle from the attack-stix-data repository against your table and review only the affected rules. Store rules in version control with a review step, so each change has an owner, a date and a test result.
How do I reduce noise from monitoring and management agents?
Most of the noise in process discovery comes from software that is supposed to be there, including endpoint agents, backup jobs, configuration management runs and vulnerability scanners. Inventory those tools first, then record their parent process names, service accounts, install paths and execution schedules. Exclude them by specific combination of parent, account and path rather than by the process name alone, because attackers can reuse common names. Review exclusions on a fixed schedule and tie each one to a documented owner and reason. Measure how many alerts each exclusion removes and whether any true activity was hidden. Exclusions should be narrower after every tuning cycle, not broader.
Which data components should I collect first for process discovery?
Start with Process Creation and Command Execution, because ATT&CK maps them to Discovery techniques more often than other sources, and together they show what was run, by whom and from which parent. Add File Access where your platform supports it, since many enumeration actions read configuration or state files. Use OS API Execution and Process Access later, once the basics are stable, because they add depth but also volume and implementation effort. Confirm with each platform owner which of these data components their logging stack actually produces, and write down the fields available for each, such as user, parent image, command line and host. Collection that is incomplete on one platform should be stated plainly in the coverage report.
How often should I rerun validation after tuning a process discovery rule?
Rerun validation after every change to the rule, the exclusions, the log pipeline or the ATT&CK version it maps to, and also on a recurring schedule so drift is caught even when nothing changed on purpose. Each run should replay a set of known benign administrative actions and a set of controlled enumeration activity in a private cyber range, then record which events fired, which did not and why. Compare results with the previous run, and treat any new silent failure as a defect. The schedule itself should be set by your change volume and risk appetite, and your team should confirm it with the platform and security owners rather than adopting a fixed interval from elsewhere.
How DeployOpen builds process discovery detections and range exercises
DeployOpen works on T1057 Process discovery as a fixed-scope engagement inside the client's own infrastructure, covering detection content, validation and range rehearsal. Each step is agreed in writing before work starts, so the client knows exactly which platforms, telemetry and response steps are covered.
How we scope
- Confirm which platforms are in scope, such as ESXi, Linux, macOS and network devices, and which hosts or segments are included.
- Inventory the process creation, command execution and file access telemetry the client already collects for those platforms.
- Agree the ATT&CK version the detection mapping will target, since releases can rename or deprecate techniques.
How we build
- Write detection logic for process discovery in Sigma-style rules and map it to the matching data components and detection strategies.
- Deploy and tune the rules in the client's open-source stack, such as Wazuh or Security Onion, against the agreed telemetry sources.
- Document known benign process enumeration, such as inventory and monitoring agents, so analysts can separate expected activity from concern.
How we hand over
- Deliver the rule set, mapping records, data source dependencies and validation results in a form the client's team can maintain.
- Provide runbooks describing triage steps, escalation paths and containment options for process discovery alerts.
- Run a cyber range exercise with the client's analysts so detection and response steps are rehearsed before handover is accepted.
How we support
- Ongoing support is available as a retainer for rule tuning, ATT&CK version updates and continued validation.
- Retesting after platform upgrades or telemetry changes can be scoped as a follow-up piece of work.
- Ask any provider to confirm in writing which deliverables recur and which are one-time, and what the quote covers.
