Lesson 7 — Investigating Process Events
Process events show what executed on an endpoint, who launched it and how one process led to another.
Microsoft Defender for Endpoint records this activity in the Device Timeline and exposes it through the DeviceProcessEvents table for Advanced Hunting.
This lesson explains how analysts use process names, command lines, parent-child relationships, user context, hashes and integrity levels to determine whether execution was legitimate or malicious.
What you will learn
This lesson explains how to investigate process execution in Microsoft Defender for Endpoint.
Learning objectives
After completing this lesson, you should be able to investigate process execution using Defender for Endpoint telemetry.
- Explain what process events represent.
- Understand the purpose of DeviceProcessEvents.
- Interpret process names, command lines and hashes.
- Follow parent and child process relationships.
- Recognise suspicious use of legitimate binaries.
The problem this solves
Almost every endpoint attack causes something to execute.
Process telemetry helps analysts identify what ran, how it started, who launched it and what activity followed.
What are process events?
Process events record the creation and execution of programs on an endpoint.
They provide the foundation for understanding scripts, tools, malware, administrative activity and attacker behaviour.
A process name is only the beginning. The command line, parent process, user and surrounding activity determine intent.
How process execution becomes evidence
DeviceProcessEvents
DeviceProcessEvents is the Advanced Hunting table used to query process creation activity collected by Defender for Endpoint.
It allows analysts to investigate execution across one device or the entire organisation.
Why process telemetry matters
Phishing, malware, ransomware, credential theft and living-off-the-land attacks all involve execution.
Understanding process telemetry helps analysts reconstruct the attack path from initial launch to impact.
Process name
The process name identifies the executable that ran.
Names such as powershell.exe, cmd.exe or rundll32.exe are not inherently malicious and must be interpreted in context.
Command line
The command line shows the instructions supplied to the executable.
Switches, URLs, encoded content, script paths and file locations often reveal the real purpose of the process.
Process name versus command line
| Process name | Command line |
|---|---|
| Shows what executable ran. | Shows what the executable was instructed to do. |
| May appear completely legitimate. | May reveal suspicious switches, URLs or encoded content. |
| Useful for broad filtering. | Critical for understanding intent. |
| Can be misleading by itself. | Becomes strongest when combined with parent and user context. |
Parent process
The parent process identifies what launched the new process.
This relationship often explains whether execution was expected, user-driven, automated or suspicious.
Child processes
Child processes show what the process launched next.
Unexpected command shells, script engines or system tools may reveal escalation, persistence or payload execution.
Example process chain
Initiating process fields
Initiating process fields describe the parent process that caused the event.
They may include the initiating filename, command line, account, hashes and process identifiers.
Process identifiers
Process IDs help distinguish multiple instances of the same executable.
Use them with timestamps and initiating process information to follow the correct execution chain.
Timestamp
The timestamp shows when the process event occurred.
Correlate it with file creation, network connections, registry changes and user logons to reconstruct the sequence.
User context
User fields identify the account under which the process executed.
Determine whether the process ran as a standard user, administrator, service account, SYSTEM or another privileged identity.
Account domain and name
Account domain and account name help identify the full security context.
This can distinguish local accounts, domain accounts, managed service accounts and system identities.
Integrity level
Integrity level indicates the privilege context of a process.
Common levels include low, medium, high and system, and unexpected elevation may require further investigation.
File hashes
Hashes such as SHA1 and SHA256 uniquely identify file content.
Use hashes to compare binaries across devices, search threat intelligence and determine whether the same payload appeared elsewhere.
Digital signatures
Signer and signature information can help establish whether a binary is trusted, unsigned or published by an unexpected vendor.
A valid signature does not guarantee safe behaviour, because trusted binaries can still be abused.
Original filename
Original filename metadata may reveal renamed executables.
A file named update.exe may still identify itself internally as a different tool or binary.
File path
The process path shows where the executable ran from.
Temporary folders, user profile directories, downloads and unusual writable locations may increase suspicion.
Living-off-the-land binaries
Living-off-the-land binaries are legitimate tools that attackers can abuse.
Common examples include PowerShell, rundll32, regsvr32, mshta, certutil, bitsadmin, wscript and cscript.
Why LOLBins are difficult
Security teams cannot simply block every trusted Windows utility.
Analysts must evaluate the command line, parent process, user, path and resulting behaviour.
Examples of suspicious context
| Execution | Why it may be suspicious |
|---|---|
| winword.exe launching powershell.exe | A document application starting a script engine may indicate malicious document execution. |
| mshta.exe connecting to an external domain | MSHTA can execute remote script content. |
| certutil.exe downloading a file | Certutil can be abused as a transfer tool. |
| rundll32.exe from a temporary folder | The path and command may indicate payload execution. |
Encoded PowerShell
Encoded PowerShell can conceal commands from casual inspection.
Encoding is not automatically malicious, but it increases the need to decode and understand the content.
Script interpreters
PowerShell, wscript, cscript and mshta can execute script content.
Review the script path, arguments, user context and initiating process.
Office applications as parents
Office applications launching command shells or script engines can indicate phishing or document-based execution.
Check the email, attachment, user action and resulting network activity.
Browser child processes
Browsers normally create many child processes.
Focus on unusual executable launches, downloaded files and processes started from browser cache or temporary locations.
Service and scheduled task execution
Processes launched by services or scheduled tasks may be legitimate automation or persistence.
Review the service name, task definition, creating account and command line.
System processes
Processes running as SYSTEM have extensive privileges.
Unexpected tools executing under SYSTEM may indicate privilege escalation, service abuse or malicious persistence.
Process investigation workflow
Pivot to DeviceNetworkEvents
After identifying a suspicious process, check whether it created network connections.
Correlate the process ID, filename, timestamp, remote IP address and domain.
Pivot to DeviceFileEvents
Check whether the process created, modified, renamed or deleted files.
This can reveal payload drops, staging, encryption or cleanup activity.
Pivot to DeviceRegistryEvents
Review registry changes made by the process.
This can reveal persistence, configuration changes or attempts to weaken security controls.
Pivot to the Device Timeline
The Device Timeline provides a visual sequence around the process event.
Use it to examine what happened immediately before and after execution.
Pivot to Advanced Hunting
Advanced Hunting allows repeatable queries across multiple devices and time ranges.
Use it to search for the same command line, hash, parent process or user elsewhere in the environment.
Common mistake
A common mistake is deciding based only on the executable name.
Legitimate tools can be abused, and malicious binaries can be renamed to look harmless.
Another common mistake
Do not ignore the parent process or command line.
These fields often contain the strongest evidence of attacker intent.
Agent Foskett investigation tip
Follow the complete process chain and correlate it with file, network, registry and user activity before deciding whether execution was malicious.
Best practices
- Read the complete command line.
- Identify the parent and child processes.
- Check the user and integrity level.
- Review file path, hashes and signer.
- Correlate network, file and registry activity.
- Search for the same behaviour across devices.
Agent Foskett takeaway
Process telemetry is the foundation of endpoint investigation.
When analysts understand what executed, how it started and what followed, they can explain the majority of endpoint attack behaviour.
Related Agent Foskett learning
Continue learning
Microsoft Defender for Endpoint Process Events
Process events in Microsoft Defender for Endpoint record executable creation, command lines, parent and child processes, user context, hashes, file paths, signer information and integrity levels.
Module 2 Endpoint Telemetry — DeviceProcessEvents Lesson 7
This Agent Foskett Defender for Endpoint Academy lesson explains how analysts investigate process execution, living-off-the-land binaries, suspicious command lines and related file, network and registry activity.
