---
{
  "title": "Process Discovery",
  "summary": "Process discovery enumerates running software to understand a host's purpose and defenses.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1057"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1057: Process Discovery",
      "url": "https://attack.mitre.org/techniques/T1057"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Process discovery enumerates running software to understand a host's purpose and defenses. It can inform subsequent targeting or evasion decisions.


## An investigation example

A suspicious script lists running processes and then changes behavior after discovering a security application.

## Evidence to examine

Examine process enumeration, script content, parent-child relationships, and actions following the query.

## A common analytical pitfall

Listing processes is a routine diagnostic task, so an isolated command does not establish compromise.

## Response considerations

Correlate discovery with the access chain and later behavior, avoiding broad exclusions that hide unauthorized use of diagnostic tools.


## A process list describes current execution context

Process discovery enumerates running software to understand a host's role and defenses. An intruder may use the result to select a target or adjust behavior. Administrators, monitoring agents, and ordinary applications also query process state. Judge the activity through its origin, expected purpose, and subsequent actions rather than treating enumeration itself as proof of compromise.

Names, identifiers, parent relationships, account context, and executable locations provide different clues. Process identifiers can be reused, and display names can be imitated. A snapshot also misses processes that ended before collection. Correlate records by time and richer identity context where possible, not by one number or familiar name alone.

## A fictional targeted termination

An academy sees an unfamiliar process enumerate running applications and then attempt to terminate a selected component. Analysts compare the sequence with approved support activity and inspect the requesting process's ancestry. The later termination attempt adds context, while success or failure must be established from the relevant outcome records.

A query might be visible only through its command execution, without a retained copy of the returned list. Do not claim that the process saw a particular entry unless the evidence supports it. A later live snapshot can help understand the environment but may not reproduce the earlier state.

## Compare two snapshots

Create fictional process lists taken five minutes apart, including one terminated process and one reused identifier. Explain why a simple identifier match can mislead. Add an enumeration event and write the narrow finding it supports. This teaches process-state reasoning without inspecting another person's device or running intrusive tools.

For reporting, distinguish discovery from code injection, credential access, or termination. Those behaviors can follow process enumeration, but the list alone does not prove them. A clear sequence of independently supported observations gives responders a stronger basis for action than a broad label that hides which stages actually occurred.

## Related concepts

- [[digital-forensics]]
- [[incident-timeline]]
- [[logs-and-telemetry]]
- [[command-and-scripting-interpreter]]
- [[native-api]]