Process Monitor is used to watch file, registry, process, and network-related activity in near real time on Windows. A practitioner can capture a burst of activity while reproducing suspicious behaviour to see exactly what changed. It is useful for tracing persistence, detecting unusual writes, and confirming how malware or software behaves.
What a Process Monitor example looks like in a real investigation
A practical example is capturing a short burst of activity while you reproduce a suspicious action, such as launching an application that may be dropping a persistence mechanism. You then filter the trace to the process of interest and inspect file, registry, process, and network events to see exactly what changed and when.
That kind of workflow is useful because it turns a vague symptom into observable behaviour. Instead of assuming what the software or malware did, you can confirm whether it wrote to autorun locations, created child processes, touched unexpected files, or attempted outbound connections during the test.
How practitioners use it to confirm suspicious behaviour
In practice, process monitor is most valuable when you already have a hypothesis. For example, if an endpoint shows signs of recurring re-entry after login, you can reproduce the condition, record the event stream, and then narrow the capture to registry writes or process creation activity that coincides with the symptom.
The main value is correlation. A short, well-targeted capture often tells you more than a long unconstrained trace, because it shows the sequence of actions that happened immediately before the unexpected behaviour. This makes it easier to distinguish harmless background noise from the action that actually changed the system state.
For deeper Windows investigation, that workflow often sits alongside Digital Forensics (DFIR) Guide, especially when the goal is to preserve evidence, interpret Windows artefacts, and build a reliable timeline from volatile and non-volatile activity.
What makes a good capture in practice
A good capture is intentionally narrow. You start Process Monitor before the suspicious action, record only long enough to reproduce the behaviour once, and then stop the trace so the signal is still readable. The goal is not to collect everything, but to collect enough to explain one specific change.
Filtering matters just as much as recording. If you do not constrain the output by process name, path, operation, or result, the trace becomes difficult to interpret and the interesting event can be lost in routine operating system activity. The best captures are usually the ones where the operator already knows what they are trying to confirm.
For a broader Windows security review, it is worth pairing the trace with authoritative control guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls, because logging, auditability, and system integrity controls explain why this kind of observation is so useful in incident handling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Process Monitor is used to observe and explain activity changes on a system. |
| AU-6 — Audit Review, Analysis, and Reporting | The tool supports analysis of captured activity to identify meaningful system changes. | |
| SI-4 — System Monitoring | Near real-time monitoring of file, registry, process, and network activity aligns with system monitoring. | |
| Recommendation — Log and review the specific events needed to reconstruct the suspicious action. Analyze captured activity for the sequence that explains the suspicious change. Monitor endpoints for unexpected process, registry, file, and network behaviour. | ||
| MITRE ATT&CK | T1057 — Process Discovery | Process Monitor commonly helps validate suspicious process activity and process relationships. |
| T1547 — Boot or Logon Autostart Execution | The tool is useful for tracing persistence through registry and startup-related changes. | |
| Recommendation — Map observed process activity to likely discovery or execution behaviour. Inspect startup and persistence locations for unexpected modification. | ||
Practitioner Guidance
What to prioritise: Use Process Monitor when you need to answer a narrow forensic question, not as a general monitoring tool. Start with one suspected process or one suspicious trigger, then capture only the window of time that matters.
What to verify: Confirm whether the activity you see is a one-off consequence of a test action or a repeated persistence mechanism. If the same file, registry key, or child process appears across multiple reproductions, treat it as a stronger lead than a single isolated event.
Common mistake: Teams often collect too much data and too little context. Without a clear starting point, the trace becomes hard to explain, and the opportunity to prove causality is lost.
Practitioner takeaway: The best Process Monitor example is a short, deliberate capture that proves cause and effect, not a broad trace that simply records lots of system activity.
Related resources from NHI Mgmt Group
- What breaks when observability tools run inside the same agent process they monitor?
- What breaks when security teams do not monitor guardrail files and anomalous AI process behavior?
- Where does supply chain traceability fail in practice when the underlying process is not tightly controlled?
- What are the signs that a just-in-time access process is failing in practice?