Process Discovery (MITRE ATT&CK T1057) is a discovery technique. The adversary gets a list of the processes running on a system to learn what software is there. MITRE lists ESXi, Linux, macOS, network devices and Windows as platforms.
The information is used to shape what happens next. MITRE notes that process details can decide whether an adversary fully infects a target or tries specific actions. A list that shows a security product might change the plan. A list that shows a database or a backup agent might suggest a target.
How attackers use it
The technique uses ordinary tools, which is why it is hard to alert on in isolation. MITRE documents these by platform:
- Windows: the Tasklist utility through cmd, Get-Process through PowerShell, and Native API calls such as CreateToolhelp32Snapshot.
- macOS and Linux: the ps command, or reading the /proc directory.
- ESXi: ps and esxcli system process list.
- Network devices: Network Device CLI commands such as show processes.
Administrator or otherwise elevated access may give better process detail, but even a normal user can see a useful list. This is typically an early step, run in bulk by automated discovery alongside other commands that look at the host, accounts and network.
How to detect it
MITRE states that the technique cannot be easily mitigated with preventive controls, because it abuses system features. Its detection strategy therefore focuses on context, with one analytic per platform:
- Windows: execution of tasklist.exe or Get-Process, or API calls such as CreateToolhelp32Snapshot, combined with parent process lineage, network session context or remote origin.
- Linux: ps, top and htop, or access to /proc, with suspicious ancestry. Correlate with interactive shell context and user role.
- macOS: ps, top or launchctl run by unusual parents or from terminal scripts, plus AppleScript based process listing or misuse of system_profiler SPApplicationsDataType.
- ESXi: esxcli system process list or ps in the ESXi shell or over unauthorized SSH sessions.
- Network devices: show process or equivalent on routers and switches, with unusual device access, unauthorized roles or config mode changes.
The practical rule is that the command is not the signal. The signal is who ran it, from where, and what else happened around it. A process listing by an administrator on a jump host is routine. A listing from a web server worker, a document application or a new SSH session from an unknown address deserves a look.
Data to collect:
- Process creation events with command lines and parent process.
- Shell history and audit records for interactive sessions on Linux, macOS and ESXi.
- AAA command accounting logs on network devices.
- Authentication logs, so you can tie a command to a session and a source.
Look for clusters. Process discovery followed within a minute or two by account discovery, network configuration commands and file listing is a common discovery burst and stronger evidence than any one command.
How to reduce the risk
There is no official mitigation to apply, so reduce exposure around it:
- Limit interactive and remote access to servers, ESXi hosts and network devices to named administrators.
- Require multi factor authentication on those paths and log every session.
- Use command accounting on network devices so every command is tied to a user.
- Send endpoint telemetry somewhere an intruder on the host cannot change it.
- Alert on unusual parents for shells, such as server processes and office applications.
Check your own environment
Windows, read-only:
auditpol /get /category:"Detailed Tracking"
This shows whether process creation auditing is enabled, which is where discovery commands would show up in event ID 4688. Sysmon event ID 1 gives the same data with more fields.
Linux, read-only:
sudo auditctl -l
This lists loaded audit rules. If you have none for command execution, an interactive discovery burst leaves little behind except shell history.
Then ask three questions. Do you log command lines on every server tier? Do you log ESXi shell and SSH access? Do network devices send command accounting to a central system?
Quick check
Why is a single tasklist or ps command a weak alert?
Administrators and software use these commands all the time. Context such as parent process, source and nearby commands carries the signal.
Which ESXi command does MITRE list for process discovery?
esxcli system process list, as well as ps.
Sources
- MITRE ATT&CK, Process Discovery: https://attack.mitre.org/techniques/T1057
