Endpoint: Evidence & Entity Investigation
Every investigation follows the evidence. Learn how to perform evidence-based investigations, trace entity relationships, and investigate incidents where automatic attack disruption has already acted.
Evidence-based investigation
A detective does not arrest someone based on a hunch. They follow evidence β fingerprints, CCTV footage, phone records β and build a case. Every piece of evidence connects to other evidence until the full picture emerges.
In MDE, evidence includes files, processes, IP addresses, URLs, user accounts, and registry entries that appear in alerts. Entity investigation means tracing how these pieces connect β which process created which file, which user ran which command, which device connected to which IP.
Sometimes, automatic attack disruption has already acted before you even start investigating. In those cases, you verify the disruption was correct and complete the investigation.
Entity types in MDE
Each entity type has its own investigation page:
| Entity | Investigation Page Shows | Key Questions |
|---|---|---|
| File | Hash, prevalence, first/last seen, VirusTotal results, related alerts | Is this file malicious? How many devices have it? |
| Process | Command line, parent process, child processes, network activity | What did this process do? Who launched it? |
| IP Address | Geolocation, ASN, reputation, devices that connected to it | Is this a C2 server? Which devices talked to it? |
| URL/Domain | Reputation, associated alerts, devices that accessed it | Is this a phishing site? How many users visited? |
| User Account | Sign-in history, devices used, alerts involving this account | Is this account compromised? What did it access? |
| Device | Full timeline, installed software, vulnerabilities, related alerts | What happened on this device? Is it compromised? |
File entity investigation
When investigating a suspicious file:
- Check the file hash β look it up in VirusTotal, Microsoft TI, or your internal TI feeds
- Check prevalence β how many devices in your org have this file? If it is on one device, it is more suspicious than if it is on 1,000 (common software)
- Check first/last seen β when did this file first appear? Did it arrive via email, download, or USB?
- Check related alerts β has this file triggered alerts on other devices?
- Check behaviour β what did the file do when executed? (process tree, network connections, file writes)
Process tree analysis
The process tree shows the parent-child relationship of processes:
explorer.exe
βββ outlook.exe
βββ winword.exe (opened email attachment)
βββ powershell.exe (macro executed)
βββ update.exe (payload downloaded)
βββ cmd.exe (lateral movement attempt)
Tracing the process tree reveals the attack chain: which legitimate process was abused, what the attacker executed, and how deep the compromise goes.
Scenario: Tyler traces a process tree
Tyler at CipherStack investigates an alert: βSuspicious process creation from Office application.β
Process tree:
outlook.exeβ opened an attachmentwinword.exeβ macro enabled by userpowershell.exeβ-enc aQBlAHgA...(Base64-encoded command)certutil.exeβ downloadedupdate.exefrom external URL (LOLBin technique)update.exeβ connected to C2, then spawnedcmd.exefor reconnaissance
Tyler identifies:
- Initial vector: Email attachment with macro
- Execution technique: PowerShell + certutil (living-off-the-land)
- Persistence: Not yet β Tyler catches it before the attacker establishes persistence
- Response: Quarantine
update.exe, block the C2 domain, purge the email across mailboxes
Investigating attack disruption incidents
When you open an incident that automatic attack disruption handled, you see:
What disruption already did
| Disruption Action | What It Means for Investigation |
|---|---|
| Device contained | The device is isolated β you can still investigate via timeline and live response |
| User suspended | The account is disabled in Entra ID β check what the account did before suspension |
| Attack stopped | The spreading mechanism (ransomware, BEC) was interrupted |
Your role after disruption
- Verify the disruption was correct β was the right device/user contained? Any false positive?
- Complete the investigation β disruption stops the immediate threat but does not find the root cause
- Check for gaps β did the attacker access other systems before disruption? Is there persistence on other devices?
- Remediate fully β reset passwords, remove persistence, patch vulnerabilities
- Release contained entities β once investigation is complete, uncontain devices and re-enable accounts
Exam tip: disruption does not equal resolution
The exam tests whether you understand that attack disruption is containment, not resolution. After disruption:
- The incident is still Active (not resolved)
- Investigation must continue to identify root cause
- Persistence mechanisms may exist on undisrupted devices
- The attacker may have exfiltrated data before disruption kicked in
If a question asks βwhat should the analyst do after attack disruption contains a device?β β the answer is continue investigating, not close the incident.
An investigation package shows that `certutil.exe` was used to download a file from an external URL. What type of attack technique is this?
Automatic attack disruption contained a ransomware-infected device at Atlas Bank. Elena opens the incident and sees the device is isolated. What should she do next?
π¬ Video coming soon
Next up: Endpoint investigation complete. The last piece of Domain 2 β investigating Microsoft 365 activities using Purview Audit, Content Search, and Graph activity logs.