Overview

Process Discovery (T1057) is a reconnaissance technique where adversaries enumerate running processes on a compromised system to understand what software is active, what security tools are present, and what opportunities exist for further exploitation. By knowing exactly what is running, attackers can identify EDR/AV processes to evade, locate high-value targets like credential managers or backup agents, and decide whether to proceed with or abort their attack chain.

Because process enumeration uses built-in OS utilities that administrators legitimately use every day, it is one of the noisiest and most easily overlooked techniques in the discovery tactic. Despite low individual alert fidelity, process discovery is almost universally present in post-compromise activity — detecting it in the right context (wrong user, wrong time, wrong parent process) is a reliable signal that an attacker has already gained a foothold and is actively planning next steps.

Attacker Perspective

After gaining initial access, attackers nearly always enumerate running processes before taking any further action, using this information to profile the environment and tailor their attack to avoid detection.

• Windows reconnaissance via built-ins: Attackers run tasklist /v or wmic process get name,processid,commandline from cmd.exe to get a full process listing including command lines, then pipe output to a file for exfiltration. Get-Process | Select-Object Name,Id,Path | Export-Csv C:\Windows\Temp\procs.csv is a common PowerShell variant.
• Security tool identification: Tools like PCHunter, Process Hacker, or custom implants call CreateToolhelp32Snapshot / Process32Next via the Windows Native API to silently enumerate processes and check for EDR agent names (e.g., searching for MsMpEng.exe, CylanceSvc.exe, cb.exe) before deploying a payload.
• Linux/macOS and ESXi enumeration: On Linux hosts and ESXi hypervisors, attackers run ps aux, ps -ef, or the ESXi-specific esxcli system process list to identify virtual machine management processes and running VMs before deploying ransomware that targets VM disk files.
• Network device profiling: On compromised Cisco or similar network devices, attackers issue show processes cpu or show processes memory via the CLI to understand device load, identify monitoring daemons, and assess whether their implant is likely to be noticed.

Process discovery is attractive to attackers precisely because it is low-risk, uses tools that are native to every platform, and provides high-value intelligence that directly determines whether the rest of the attack chain succeeds or fails.

Detection Strategy

Required Telemetry

• Windows — Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → Success. Critically, also enable command-line logging: GPO path Administrative Templates → System → Audit Process Creation → Include command line in process creation events, or registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled = 1. Without this, you get process names but no arguments.
• Windows — Sysmon Event ID 1 (Process Create): Preferred over 4688 because it includes ParentImage, ParentCommandLine, User, Hashes, and LogonId in a single event. Deploy Sysmon with a community config (SwiftOnSecurity or Olaf Hartong’s modular config). Event ID 1 should be forwarded to your SIEM via Windows Event Forwarding (WEF) or a SIEM agent.
• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO: Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging, or registry key HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging = 1. This captures full PowerShell script content including Get-Process calls, even when encoded or obfuscated.
• Windows — WMI Activity (Event ID 4688 or Sysmon EID 1 for WMIC + Microsoft-Windows-WMI-Activity/Operational): WMIC process enumeration appears as process creation of wmic.exe with process arguments. Enable the WMI operational log via Event Viewer → Applications and Services → Microsoft → Windows → WMI-Activity → Operational and set it to collect.
• Linux — auditd rules for process execution: Add the following rules to /etc/audit/rules.d/process_discovery.rules:
  -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/ps -k process_discovery and
  -a always,exit -F arch=b64 -S execve -F exe=/bin/ps -k process_discovery.
  These generate EXECVE and SYSCALL audit records with the full command line and calling user. Forward with auditbeat (Elastic) or audispd-plugins to your SIEM.
• macOS — Endpoint Security Framework / EDR telemetry: Native macOS audit (auditd) is deprecated; rely on your EDR’s process execution telemetry or enable Unified Logging and collect process category events. ps execution will appear with parent process and user context.
• ESXi — Shell command logging: Enable ESXi shell logging via Host → Manage → Security Profile → Services → ESXi Shell and ensure /var/log/shell.log is forwarded to your SIEM. Commands like esxcli system process list and ps will appear there with timestamp and user.
• Network Devices (Cisco) — AAA accounting logs: Configure aaa accounting commands 15 default start-stop group tacacs+ on Cisco devices to capture all privilege-15 commands including show processes. These logs ship to a TACACS+ or syslog server that your SIEM ingests.

Key Indicators

• Suspicious process: tasklist.exe spawned by unusual parent. In Windows process creation logs (Sysmon EID 1 or 4688), look for Image ending in \tasklist.exe where ParentImage is not explorer.exe, cmd.exe launched by a human session, or known admin tooling. Red flags: parent is powershell.exe, wscript.exe, mshta.exe, svchost.exe, or any Office process (winword.exe, excel.exe).
• WMIC process enumeration command line. In Sysmon EID 1 or 4688, look for CommandLine containing both wmic and process where the command does NOT also contain call create or call terminate (those are execution, not discovery). Pattern: CommandLine CONTAINS "wmic" AND CONTAINS "process" AND NOT CONTAINS "call".
• PowerShell Get-Process in script block logs. In Windows EID 4104, look for ScriptBlockText containing Get-Process or ps (PowerShell alias). Elevate priority if the same script block also contains Export-Csv, Out-File, ConvertTo-Json, or network cmdlets — indicating the output is being staged for exfiltration.
• Native API calls via known attack tools. In EDR telemetry, look for calls to CreateToolhelp32Snapshot or NtQuerySystemInformation from processes that are not standard system utilities. PCHunter (PCHunter64.exe, PCHunter32.exe) or Process Hacker (ProcessHacker.exe) execution should be treated as high-fidelity indicators when observed outside of known IT admin activity.
• Linux/macOS: ps execution by unexpected users or parents. In auditd or EDR logs, look for ps executed where auid (audit user ID) maps to a non-interactive service account, or where the parent process is a web server (apache2, nginx, httpd), database process, or remote access tool. Command-line arguments ps aux or ps -ef are the most common patterns.
• ESXi-specific: esxcli system process list in shell logs. In /var/log/shell.log, look for this exact string. Legitimate ESXi administration almost never requires this command — any occurrence outside a documented change window should be treated as high-priority.
• Cisco AAA logs: show processes from unrecognized source IPs. In AAA accounting logs, look for the keyword show processes where the source IP is not in your documented network management station list. Also flag if the AAA log shows the command was issued but no corresponding change ticket exists.
• Bulk process enumeration in a short window. Multiple process discovery commands (any combination of tasklist, wmic process, Get-Process, ps) from the same host within a 5-minute window — this pattern is more indicative of scripted recon than a human administrator checking one thing.

Detection Logic

Rule 1 (Broad — High Sensitivity): Any process discovery tool execution
IF (Image ENDSWITH "\tasklist.exe" OR Image ENDSWITH "\wmic.exe" AND CommandLine CONTAINS "process") OR (EventID = 4104 AND ScriptBlockText CONTAINS "Get-Process") THEN alert(severity=LOW, tag="T1057")

This broad rule catches all common Windows process discovery invocations. Expect high volume — this is a baseline visibility rule, not an actionable alert by itself. Use it to build frequency baselines per user and host, then use those baselines to drive anomaly-based tuning. Alert volume will be high in most environments until exclusions for known-good admin behavior are added.

Rule 2 (Medium — Suspicious Parent Process): Process discovery launched by high-risk parent
IF (Image ENDSWITH "\tasklist.exe" OR (Image ENDSWITH "\wmic.exe" AND CommandLine CONTAINS "process") OR (Image ENDSWITH "\powershell.exe" AND CommandLine CONTAINS "Get-Process")) AND ParentImage IN ("\winword.exe", "\excel.exe", "\outlook.exe", "\mshta.exe", "\wscript.exe", "\cscript.exe", "\regsvr32.exe", "\rundll32.exe", "\svchost.exe") THEN alert(severity=HIGH, tag="T1057-SuspiciousParent")

This rule targets the most common post-exploitation pattern: a malicious document, script host, or LOLBin spawning a process enumeration tool. False positive rate is very low — this combination almost always indicates active compromise or red team activity. Expected alert volume: rare in most environments; treat every hit as a priority investigation.

Rule 3 (High Precision — Tooling): Known offensive process inspection tools
IF Image ENDSWITH "\PCHunter64.exe" OR Image ENDSWITH "\PCHunter32.exe" OR OriginalFileName = "PCHunter.exe" OR Description CONTAINS "Epoolsoft" OR Hashes CONTAINS "SHA256=2B214BDDAAB130C274DE6204AF6DBA5AEEC7433DA99AA950022FA306421A6D32" THEN alert(severity=HIGH, tag="T1057-HackTool")

PCHunter and similar kernel-level process inspection tools (also include Process Hacker hash matching if available) have almost no legitimate use in enterprise environments. Hash-based matching catches renamed binaries. Expected alert volume: near-zero false positives; treat every hit as a confirmed incident until proven otherwise.

Rule 4 (Broad — Linux/ESXi): Process enumeration from non-interactive or service accounts
IF (process.name IN ("ps", "esxcli") AND process.args CONTAINS_ANY ("aux", "-ef", "system process list")) AND (user.name NOT IN [known_admin_accounts] OR process.parent.name IN ("apache2", "nginx", "httpd", "python", "python3", "ruby", "php")) THEN alert(severity=MEDIUM, tag="T1057-Linux")

Catches process enumeration on Linux and ESXi hosts either by unexpected users or from web/app server parent processes, which is a strong indicator of web shell or RCE exploitation. Expected alert volume: low if known-admin exclusions are maintained; spikes warrant immediate investigation.

Tuning Guidance

• IT administration and helpdesk tools: SCCM, Tanium, BigFix, and similar endpoint management platforms routinely run tasklist and WMI process queries as part of inventory collection. Identify the service account(s) and parent process names these tools use and exclude: ParentImage ENDSWITH "\CcmExec.exe" or user.name IN ["svc-sccm", "svc-tanium"]. Do not exclude the host — only the specific account and parent combination.
• Security and vulnerability scanners: Tenable Nessus, Qualys, Rapid7 InsightVM, and CrowdStrike Falcon sensor itself may enumerate processes during scans. Identify scanner source hosts or service accounts and exclude by source.ip IN [scanner_subnet] or user.name = "nessus". Verify these exclusions quarterly as scanner configs change.
• Developer and DevOps activity: Developers frequently use Get-Process in scripts, tasklist to debug applications, and ps aux on Linux dev boxes. Exclude known developer workstations or user groups from Rule 1 (broad rule) but retain them in Rules 2 and 3 — a suspicious parent process is still suspicious regardless of who the user is.
• Scheduled tasks and automation scripts: Many organizations have monitoring scripts that check for specific running services using tasklist or wmic process on a schedule. Identify these by correlating with ParentImage = "\taskeng.exe" or ParentImage CONTAINS "Task Scheduler" and the specific script path, then add a targeted exclusion: ParentImage ENDSWITH "\taskeng.exe" AND CommandLine CONTAINS "C:\Scripts\MonitorService.ps1".
• Cisco AAA false positives from NOC: Network operations staff legitimately run show processes during troubleshooting. Exclude source IPs belonging to documented NOC jump hosts or management stations. Alert on the same command from any other source. Build a lookup table of authorized management IPs and reference it in your detection rule.

When the Alert Fires: Investigation Steps

1. Verify the alert against the raw log. Pull the original event from your SIEM using the event ID, timestamp, and host — confirm the process creation record actually exists in the source log (Sysmon EID 1 or Windows EID 4688) and was not a SIEM parsing artifact. Check that the CommandLine field is populated; if it is empty, your audit policy may not have command-line logging enabled, which limits your investigation.
2. Identify the affected host and user account. Confirm the hostname, IP address, and the SubjectUserName (EID 4688) or User (Sysmon EID 1) that executed the process. Flag immediately if the account is a service account, a privileged administrator account, or if the host is a server, domain controller, or sensitive system — those contexts sharply increase severity.
3. Reconstruct the full parent process chain. Using Sysmon EID 1 (which includes ParentProcessGuid), trace backwards from the process discovery command to find the grandparent and great-grandparent processes. Use your EDR or SIEM to pivot on ProcessGuid or ProcessId. If the chain leads back to a browser, Office application, script host, or an unusual network-connected process, treat this as a confirmed compromise and escalate immediately.
4. Check for network connections and files written around the same timestamp. Using Sysmon EID 3 (Network Connection) and EID 11 (File Create), look for any outbound connections or file writes within a 2-minute window before and after the process discovery event. Specifically look for output files written to temp directories (%TEMP%, C:\Windows\Temp, /tmp) and any connections to external IPs or unusual internal hosts that could indicate data staging or C2 check-in.
5. Search for the full discovery script or toolset. Process discovery rarely happens in isolation — query your SIEM for all process creation events from the same host within the prior 30 minutes and look for other T1057 siblings: whoami, ipconfig, net user, net group, systeminfo, netstat. A cluster of discovery commands in a short window is a strong indicator of automated post-exploitation (e.g., a Cobalt Strike or Metasploit post-exploitation module running its standard recon sequence).
6. Check for lateral movement originating from this host. In Windows Security logs, look for EID 4624 (successful logon) Type 3 (network) or Type 10 (RemoteInteractive) events where the source IP is the host under investigation. In your network flow data, look for new SMB (port 445), RDP (port 3389), WinRM (port 5985/5986), or SSH connections originating from this host to other internal systems in the 60 minutes following the process discovery event.
7. Make the escalation decision. If process discovery was executed by a known tool from a legitimate admin account on a workstation with no suspicious parent and no subsequent suspicious activity, close as benign with a tuning note. Escalate to a confirmed incident if any of the following are true: suspicious parent process chain, non-admin account, subsequent network connections or file writes, cluster of discovery commands, presence of offensive tooling (PCHunter, Process Hacker), or the host is a server or domain controller. When in doubt, escalate — the cost of a false negative here is an undetected foothold.

Response Playbook

Containment

• Isolate the host — keep it powered on. Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate, or similar) to cut off all network connectivity while preserving the live system for forensics. Do not shut it down — volatile memory may contain injected code, C2 configuration, or decryption keys that are unrecoverable after power-off.
• Disable the affected user account immediately. In Active Directory, use Disable-ADAccount -Identity [username] or the ADUC console. If the account is a service account, coordinate with the application owner before disabling, but prioritize security — document your action and the time.
• Kill any identified malicious or suspicious processes. Use your EDR to terminate the process tree rooted at the malicious parent identified in step 3 of the investigation. Document the PID, image path, and command line before terminating.
• Block identified C2 IPs and domains. Push any external IPs or domains identified in step 4 (network connections) to your perimeter firewall block list and your DNS RPZ (Response Policy Zone) to prevent other potentially compromised hosts from beaconing. Use your SIEM or TIP to enrich these IOCs before blocking to avoid false blocks.
• Revoke active sessions and tokens. If the compromised account has active Kerberos tickets, use klist purge on affected hosts and consider resetting the account password to force ticket invalidation. If Azure AD or cloud tokens are involved, revoke refresh tokens via Revoke-AzureADUserAllRefreshToken or the Entra ID portal.

Eradication

• Remove identified persistence mechanisms. Audit scheduled tasks (schtasks /query /fo LIST /v), registry run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and user equivalents), services (sc query type= all), and startup folders. Remove any entries not present in your baseline or change records. On Linux, check /etc/cron*, ~/.bashrc, /etc/rc.local, and systemd unit files.
• Find and delete dropped tools and payloads. Search the host for files created or modified in the time window around the incident. On Windows, query Sysmon EID 11 for file creation events. Look specifically in C:\Windows\Temp, C:\Users\[user]\AppData\Local\Temp, and any paths referenced in the malicious command lines. Submit unknown binaries to your sandbox or VirusTotal before deleting, to capture IOCs.
• Reset credentials for all accounts involved. Reset the password for the compromised user account and any accounts that account had access to or that logged in to the same host. If there is any possibility of credential dumping (check for lsass access in EDR telemetry), treat all accounts that had active sessions on that host as potentially compromised and reset them.
• Audit lateral movement targets. For any hosts the compromised host connected to (identified in investigation step 6), run the same investigation checklist on those hosts — check for the same process discovery artifacts, new scheduled tasks, new accounts, and EDR detections. Expand your scope iteratively until you find the boundary of the compromise.
• Rotate any secrets or API keys that may have been exposed. If the host ran applications with embedded credentials, API keys, or certificates, rotate all of them. Check environment variables, configuration files, and credential manager stores on the affected host for stored secrets.

Recovery

• Re-image the host if confidence in cleanliness is low. If you cannot confirm the full scope of what the attacker did (e.g., memory forensics was not possible, or the parent process chain led to a sophisticated implant), re-image the endpoint from a known-good baseline rather than attempting surgical cleanup. Reconnect to the network only after re-image and a clean EDR scan.
• Re-enable the user account only after confirming no persistence remains. Before re-enabling the account, run a final pass of the persistence checks listed in eradication, and confirm with your EDR that no detections have fired on the host in the 24 hours since remediation. Brief the user on what happened and remind them of phishing/social engineering awareness.
• Monitor the affected host and user for 72 hours post-remediation. Create a temporary high-sensitivity watchlist rule in your SIEM that alerts on any process creation, network connection, or authentication event from this host or user account for 72 hours. Attackers who are evicted sometimes attempt rapid re-entry using the same or similar techniques.
• Document the full incident timeline and close formally. Record the initial alert time, investigation steps taken, IOCs discovered, systems affected, actions taken, and time to containment. This documentation feeds your next tabletop exercise and is required if the incident meets breach notification thresholds.
• Update detection rules based on new IOCs. Any new command-line patterns, file hashes, parent process combinations, or network indicators discovered during this investigation should be added to your detection rules immediately. File a rule update ticket and validate it in your SIEM with a test event before closing the incident.