T1057: Process Discovery
Adversaries may attempt to get information about running processes on a system. Information obtained could be used to gain an understanding of common software/applications running on systems within the network. Administrator or otherwise elevated access may provide better process details. Adversaries may use the information from Process Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.
In Windows environments, adversaries could obtain details on running processes using the Tasklist utility via cmd or Get-Process via PowerShell. Information about processes can also be extracted from the output of Native API calls such as CreateToolhelp32Snapshot. In Mac and Linux, this is accomplished with the ps command. Adversaries may also opt to enumerate processes via `/proc`. ESXi also supports use of the `ps` command, as well as `esxcli system process list`.CitationSygnia ESXi Ransomware 2025CitationCrowdstrike Hypervisor Jackpotting Pt 2 2021
On network devices, Network Device CLI commands such as `show processes` can be used to display current running processes.CitationUS-CERT-TA18-106ACitationshow_processes_cisco_cmd
Security context for executives and security teams
Process Discovery is an early reconnaissance behavior where an adversary checks what is running on Windows, Linux, macOS, ESXi, or network devices before deciding what to do next. For leaders, its value is not that a process listing is inherently malicious; it is that this behavior often helps an intruder identify security tools, business applications, virtualization hosts, and device services that can shape follow-on actions. Coverage matters because missed process discovery can leave SOC and IR teams without context for how an intrusion was scoped and prepared.
Executive priority
Treat this as a baseline visibility and response-readiness control, not a standalone high-severity alert. Executives should ask whether endpoints, ESXi hosts, and network devices generate enough command, process, and administrative-session evidence to prove what was enumerated during an incident. This is especially relevant for operational resilience where ESXi or network devices support critical services, and for audit/compliance evidence where teams must reconstruct attacker discovery activity.
Technical view
ATT&CK lists Process Discovery under Discovery across ESXi, Linux, macOS, Network Devices, and Windows. Validate visibility for common process-enumeration paths described by MITRE: Windows Tasklist through cmd, PowerShell Get-Process, Native API process snapshot activity, ps and /proc access on Unix-like systems, ESXi ps and esxcli system process list, and network device CLI commands such as show processes. Because MITRE provides no official detection text for this object, detection engineering should lean on relationship context from DET0034 and local baselines: focus on unusual users, remote sessions, suspicious parent processes, automation, post-compromise tool chains, and discovery clustered with other ATT&CK behaviors.
Likely telemetry
- Endpoint process creation events with command-line arguments
- PowerShell execution and script logging where available
- Windows command shell activity involving process listing utilities
- API or EDR telemetry indicating process enumeration behavior
- Linux, macOS, and ESXi shell command history or audit logs for ps, /proc access, and esxcli process listing
Detection direction
- Do not alert on every process listing in isolation; tune around context such as uncommon account, host, parent process, remote source, time of day, or proximity to other discovery and execution activity.
- Build separate baselines for servers, admin workstations, ESXi hosts, and network devices because legitimate administrative process checks are common.
- Prioritize correlation where process discovery follows suspicious execution or precedes credential, defense-evasion, lateral movement, or ransomware-like activity.
- Validate that DET0034 or equivalent analytic coverage is mapped to this technique and tested with benign simulations in each supported platform class.
- Check blind spots around ESXi shell access, network device CLI logging, PowerShell visibility, and Linux/macOS audit coverage; these are often less complete than standard Windows endpoint logs.
Mitigation priorities
- Ensure least-privilege administration so elevated process details are limited to authorized users and sessions.
- Centralize and retain endpoint, ESXi, Linux/macOS, and network device administrative telemetry for incident reconstruction.
- Harden and monitor remote administrative access paths used to run process discovery commands.
- Use detection tuning and response playbooks that treat process discovery as a contextual signal rather than a guaranteed malicious event.
- For critical infrastructure or cyber-physical environments, confirm that virtualization hosts and network infrastructure supporting operations are included in logging and IR collection plans.
Additional notes and limits
The relationship set shows this technique is used across many campaigns and groups, including espionage, ransomware, supply-chain, botnet, and network-device activity. That breadth supports prioritizing visibility, but it should not be interpreted as attribution in a local incident. The most defensible use of this technique in operations is as a correlation and scoping signal: who enumerated processes, on which platform, from what session, and what happened before and after.
MITRE did not provide official detection guidance for T1057 in the supplied object. Specific commands and telemetry availability vary by operating system, device type, EDR/audit configuration, and administrative practice. This take does not assert active exploitation, customer exposure, or guaranteed detection coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Process Discovery
Adversaries may attempt to get information about running processes on a system. Information obtained could be used to gain an understanding of common software/applications running on systems within the network. Administrator or otherwise elevated access may provide better process details. Adversaries may use the information from Process Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.
In Windows environments, adversaries could obtain details on running processes using the Tasklist utility via cmd or Get-Process via PowerShell. Information about processes can also be extracted from the output of Native API calls such as CreateToolhelp32Snapshot. In Mac and Linux, this is accomplished with the ps command. Adversaries may also opt to enumerate processes via `/proc`. ESXi also supports use of the `ps` command, as well as `esxcli system process list`.CitationSygnia ESXi Ransomware 2025CitationCrowdstrike Hypervisor Jackpotting Pt 2 2021
On network devices, Network Device CLI commands such as `show processes` can be used to display current running processes.CitationUS-CERT-TA18-106ACitationshow_processes_cisco_cmd
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.