EDR gives an analyst a lot of data: processes, network connections, files, commands, alerts, and the relationships between events. But that data only has value once someone knows how to turn a stream of telemetry into a clear picture of an incident.
Investigating in EDR isn't about hunting for one "bad file" — it's about reconstructing a chain of actions: how the attack started, what the adversary did, which systems were affected, and what response is needed.
Start with triage
The first step is quick triage. Its job isn't to prove everything conclusively right away — it's to establish priority and scope.
Useful questions to ask:
- which host and user are tied to the alert;
- when the activity started;
- are there similar events on other hosts;
- are there signs of command execution, file downloads, or network connections;
- does the host need to be isolated immediately.
If an analyst tries to pick apart every single event at this stage, the investigation quickly turns into chaos. What you need is a hypothesis and a timeline.
Build a timeline
A timeline helps you see cause and effect. In EDR, it's important to look not just at the event that triggered the alert, but at what happened before and after it.
It's usually worth reconstructing:
- the parent process and command line;
- the user account the action was executed under;
- network connections before and after the process launched;
- files created or modified;
- attempts at persistence, privilege escalation, and lateral movement.
A good timeline answers the question "what happened," not just lists events.
Separate signal from noise
Enterprise environments are full of legitimate activity that looks suspicious: admin scripts, updates, remote management tools, bulk file operations. That's why an analyst needs to weigh each event against its context.
One PowerShell execution doesn't prove an attack. But PowerShell with an unusual command line, a network connection to an external address, and a subsequently created executable already deserves a close look.
Check the scope
Once you've confirmed the initial finding, you need to determine whether the incident is limited to one host. To do that, search for matching indicators: file hash, domain, IP address, process name, command line, user, or attack technique.
Scaling the search this way helps you avoid missing a second compromised machine and prevents mistaking a local symptom for the whole incident.
Common analyst mistakes
The most frequent mistakes in EDR investigations:
- looking only at the alert itself and not checking the events around it;
- trusting a process name without examining its path and command line;
- not recording hypotheses and conclusions;
- isolating a host too late, or without understanding the consequences;
- not checking for similar indicators across the infrastructure;
- closing the investigation without a clear report on cause and actions taken.
What skills you need
Working with EDR requires more than knowing the product's interface — it takes an understanding of operating systems, network activity, common attack techniques, and SOC process logic. An analyst needs to be able to read telemetry, build hypotheses, and explain the outcome to the response team.
Practice on lab environments
These skills are hard to pick up from lectures alone. In the BI.ZONE EDR course, investigations are practiced on isolated lab environments: you can examine telemetry, test hypotheses, and apply response actions without any risk to production infrastructure.