If you cannot read endpoint logs, you will miss the attack that is already inside your network, and the exam will punish you for it. Endpoint Intrusion Analysis is the skill of looking at the data a computer generates — process lists, network connections, file changes — and spotting the evidence of a compromise. For the 200-201 exam, this is the single most practical domain because it tests whether you can answer the question ‘Is this normal, or is this an attack?’
Jump to a section
A simple way to picture Endpoint Intrusion Analysis
3,500 times a day, a security camera at a busy warehouse records every person who enters, every door they open, every file they touch on a shared computer, and every USB stick they plug in. That camera is the Endpoint Detection and Response (EDR) agent installed on every company laptop and server. The warehouse manager does not watch 3,500 video clips live — she waits for an alarm. The alarm is a Security Information and Event Management (SIEM) rule that fires when, say, someone logs in at 3 a.m. and immediately runs a tool named ‘mimikatz.exe’. When the alarm sounds, the detective opens her notebook. The notebook is the endpoint telemetry log: a timestamped list of every process started, every network connection made, every registry key changed. She does not guess. She scrolls backwards from the alarm time to find the root cause — was the login credential stolen? Was the tool downloaded via a phishing email? Each log entry is a clue that answers a specific question: what executed, when, from where, and with what parent process. The detective reconstructs the attack timeline exactly as it happened, minute by minute, by cross-referencing multiple laptops and servers. If she finds one laptop where the attacker’s tool ran but the antivirus did not catch it, she knows the malware was custom-built and never seen before — a zero-day. The notebook never lies; it only shows what the detective has the skill to interpret.
The specific mapping to Endpoint Intrusion Analysis is this: the EDR agent is the camera, the SIEM is the alarm system, and the log data is the detective’s notebook. The analyst’s job is to read the notebook, connect the clues, and tell the exact story of the intrusion, from initial access to data exfiltration.
Endpoint Intrusion Analysis is the process of examining data from individual devices — laptops, desktops, servers — to find signs of an intrusion, understand how it happened, and determine what the attacker did. An ‘endpoint’ is any device that connects to a network and runs applications: your laptop, a web server, a database server, even a printer. The word ‘intrusion’ means unauthorised access or activity. So, ‘Endpoint Intrusion Analysis’ means: ‘I have a device that may have been hacked — let me look at its internal records to know for sure.’
Every modern operating system (Windows, Linux, macOS) keeps logs. Logs are timestamped records of events. Think of them as a diary that the computer writes automatically. Common log types include:
Security logs: record login successes, login failures, account lockouts, and privilege escalations (when a user gains extra permissions).
System logs: record when drivers load, when services start or stop, and when the computer shuts down unexpectedly.
Application logs: record errors and events from specific programs like a web browser or a database.
Process creation logs: record every time a program (.exe, .bin, .sh) starts, who started it, and what started it (the parent process).
Network connection logs: record every outbound and inbound connection — IP address, port, protocol, and the process that made the connection.
The analysis begins when something suspicious happens. A Security Information and Event Management (SIEM) system collects logs from thousands of endpoints, correlates them, and generates an alert. ‘Correlation’ means looking for patterns across multiple logs — for example, a single user logging in from three different countries in one hour. The alert is a notification: ‘Something needs attention.’ But alerts are often false positives — benign events that look malicious. The analyst must ‘triage’ the alert: decide quickly if it is real or a false alarm.
If the alert is real, the analyst performs ‘deep analysis’. They look at the specific endpoint that triggered the alert. They ask: What process caused the alarm? What was the parent process — the program that launched the suspicious one? A legitimate process (like ‘explorer.exe’ on Windows) launching a calculator is normal. That same process launching a PowerShell script that downloads a file from a foreign IP address is suspicious.
The analyst uses a tool called an Endpoint Detection and Response (EDR) agent. The EDR agent sits on the endpoint and records everything: every process creation, every network connection, every registry change (registry is the Windows database of configuration settings), every file write, every scheduled task creation. The analyst can query the EDR to answer specific questions:
Is the process signed by a trusted vendor? Unsigned processes are not necessarily malicious, but they are more suspicious.
Has this file hash (a unique digital fingerprint of the file) ever been seen in the wild? Reputation services compare the hash against databases of known malware.
Did the process make a network connection to an IP address known for command-and-control (C2) activity? C2 is how an attacker controls a hacked computer remotely.
Were any persistence mechanisms created? ‘Persistence’ means the attacker ensures their malware runs again after a reboot — for example, by adding a registry run key or creating a scheduled task.
Why does all of this matter for the 200-201 exam? Because the exam presents you with log excerpts, process trees, and alert details, and asks you to determine what happened, what the next step should be, or what type of attack is underway. You do not need to know every log format perfectly, but you must understand the concepts: what an endpoint is, what logs contain, how to trace a process tree, and how to spot common malicious behaviours like credential dumping (using tools like ‘mimikatz’ to steal passwords from memory) or lateral movement (when an attacker jumps from one endpoint to another). This replaces the old approach of merely trusting antivirus signatures — modern attacks are custom-built and bypass signature detection, so behaviour-based analysis is essential.
Receive the Alert
A SIEM generates an alert based on a rule, such as 'Multiple failed logon attempts within 5 minutes'. The analyst triages the alert by checking the severity, the affected endpoint IP, and the time. This step matters because it determines how urgently to investigate — a critical server alert gets immediate attention, while a low-severity alert on a test machine may wait.
Identify the Suspicious Process
Using the EDR console, the analyst queries the endpoint for all processes that started within the alert time window. They look for unusual process names, command-line arguments, or unexpected parent-child relationships. For example, if the alert is about failed logins, they look for a process like 'powershell.exe' launched by 'svchost.exe' — that is a clue that the login was part of an automated attack script.
Examine the Process Chain
The analyst traces back from the suspicious process to its parent, grandparent, and so on, until they reach the original process that started the chain. This reveals the entry point — a phishing email attachment, a drive-by download from a web browser, or a remote exploitation via a vulnerable service. This step is critical because it shows how the attack began.
Check Network Connections and File Operations
The analyst reviews network connections made by the suspicious process to see if it contacted any external IP addresses. They also check file creation, modification, and deletion events. If the process downloaded an executable or wrote to a registry Run key, those are strong signs of persistence and C2 activity. This step confirms whether the process is truly malicious.
Isolate and Document
Once the analyst confirms the endpoint is compromised, they contain the threat by isolating the endpoint from the network using the EDR's 'contain' or 'quarantine' feature. They then document the entire timeline, the IoCs (file hashes, IPs, registry keys), and the steps taken. This documentation is essential for escalation to incident response, legal reporting, and improving future detection rules.
An IT professional working as a Security Operations Center (SOC) Analyst receives an alert from the SIEM at 2:17 a.m. on a Tuesday. The alert reads: ‘Windows Security Event ID 4625 — multiple failed logon attempts from IP 10.5.12.88 to server SRV-FINANCE-01.’ The analyst knows that a single failed login is normal; 50 in two minutes is an attack — likely a brute-force password guessing attempt.
Step-by-step, the analyst uses Endpoint Intrusion Analysis to investigate:
The analyst opens the EDR console for SRV-FINANCE-01. The console shows a timeline of every process running on that server in the last hour. The analyst filters for processes that started around 2:15 a.m.
A process named ‘powershell.exe’ appears, started by ‘svchost.exe’ — the standard Windows service host. But the command-line argument for that PowerShell instance is suspicious: it downloads a file from ‘http://malicious.site/payload.ps1’. The analyst recognises this as a ‘fileless’ attack — the attacker never writes a file to disk, so traditional antivirus would miss it.
The analyst looks at network connections from that PowerShell process. It connected to an external IP address 45.33.32.156 on port 443. The analyst cross-references this IP with a threat intelligence feed (a constantly updated list of known malicious IPs). The IP is flagged for C2 activity.
The analyst checks the parent process chain. ‘svchost.exe’ was started by ‘services.exe’, which is normal. But the analyst notices that ‘svchost.exe’ was modified two days ago — the file hash changed. The attacker replaced the legitimate service host with a trojanised version.
The analyst now has a timeline: the attacker compromised the server two days ago, installed a backdoor as a fake service, and is now using it to execute PowerShell commands and connect to C2. The analyst immediately isolates the server (disconnects it from the network) using the EDR’s ‘contain’ feature, and drafts an incident report.
This scenario is exactly what the 200-201 exam wants you to understand: the ability to reconstruct an attack timeline from endpoint data, recognise common malicious patterns, and take appropriate action. In real companies, this process happens hundreds of times per day, and the analyst’s skill determines whether a breach is stopped in minutes or becomes a headline news story.
The 200-201 exam tests Endpoint Intrusion Analysis in several specific ways. You can expect multiple-choice questions, drag-and-drop scenario questions, and exhibit-based questions (where you read a log or a process tree and answer questions about it). The exam objective 4.3 says: ‘Analyse endpoint data to detect and investigate intrusions.’ The exam writers love to test your ability to identify suspicious behaviour from normal behaviour.
Key topics they test:
Process tree analysis: They will show you a parent-child process lineage and ask which process is malicious. For example: ‘explorer.exe → cmd.exe → powershell.exe → wscript.exe’ — wscript.exe running from a command shell is suspicious because wscript is a Windows script host, not normally launched from a command prompt.
Event ID knowledge: You must know that Event ID 4625 is failed logon, 4624 is successful logon, 4688 is process creation, 5156 is a network connection. They will give you an Event ID in an exhibit and ask what it means.
File hash and reputation: They will test whether you know that if a file hash is unknown (low prevalence), it is more suspicious than a hash with many good reputation scores.
Persistence mechanisms: You must recognise that registry keys like ‘HKCU\Software\Microsoft\Windows\CurrentVersion\Run’ are common persistence points. They will ask: ‘Which registry key would an attacker modify to gain persistence?’
Common tools and techniques: They love to mention ‘Mimikatz’ for credential dumping, ‘PsExec’ for lateral movement, and ‘PowerShell’ for fileless execution. You must know what each does and what log evidence it produces.
Traps the exam sets:
False positives: The exam will present logs that look malicious but are benign — for example, a legitimate Windows update process that downloads a file from an IP address. They want you to validate the reputation and process chain before concluding it is malicious.
Confusing process names: An attacker might name their malware ‘svchost.exe’ but place it in a different directory (C:\Users vs C:\Windows\System32). The exam expects you to notice the path difference.
Overlooking parent process: They will give you a child process that looks clean (e.g., ‘notepad.exe’) but the parent is a web browser, which is normal. If the parent is a suspicious script, the same notepad.exe could be malicious (e.g., reading a password file).
What the correct answer pattern looks like: Always trace back to the parent process. Always check the command-line arguments. Always check the file path. If an answer says ‘Isolate the endpoint and collect a memory dump’ that is usually the correct containment step. If an answer says ‘Ignore the alert because it is a false positive’ and you have not verified the process chain, that is likely the trap.
Memorise these exact items:
The difference between a SIEM (centralised log correlation) and an EDR (endpoint-level agent for deep inspection).
The typical MITRE ATT&CK technique mappings: T1059.001 (PowerShell), T1003.001 (LSASS memory dumping), T1053.005 (scheduled task persistence). The exam will not ask you MITRE IDs directly, but they appear in scenario descriptions.
The concept of ‘indicator of compromise (IoC)’ — any observable artifact (hash, IP, domain, registry key) that suggests an intrusion.
An endpoint is any device that connects to a network and runs applications, such as a laptop, server, or printer.
Logs are timestamped records of events; the three main types are security logs, system logs, and application logs.
A SIEM correlates logs from multiple sources to generate alerts; an EDR agent on an endpoint provides deep forensic data.
Process tree analysis — tracing the parent-child relationship of running processes — is the single most important skill for detecting intrusions.
Persistence mechanisms like registry Run keys and scheduled tasks ensure malware survives a reboot; finding unauthorised persistence is a strong indicator of compromise.
Fileless attacks execute in memory without writing to disk, so they evade traditional antivirus; behaviour-based detection via EDR is required to catch them.
These come up on the exam all the time. Here's how to tell them apart.
SIEM (Security Information and Event Management)
Centralised platform that collects logs from many sources (network devices, servers, endpoints).
Uses correlation rules to generate alerts when patterns match attack signatures.
Limited visibility into individual endpoint internals like in-memory processes and registry changes.
EDR (Endpoint Detection and Response)
Agent-based software installed directly on each endpoint (laptop, server).
Records detailed telemetry: process creation, network connections, file writes, registry modifications.
Allows deep forensic queries into a single endpoint, such as dumping memory or collecting a file.
Signature-Based Detection
Compares file hashes or known strings against a database of known malware signatures.
Fast and low false-positive rate for known malware, but fails against custom or modified variants.
Commonly used by traditional antivirus software.
Behaviour-Based Detection
Analyses patterns of activity — like a process launching a child process that connects to a rare IP address.
Can detect novel or ‘zero-day’ attacks that have no signature.
Commonly used by EDR tools and advanced threat protection systems.
True Positive (Alert)
An alert that accurately indicates malicious activity, such as a known ransomware hash detected on an endpoint.
Requires immediate investigation and containment action to prevent damage.
Increases when the attacker uses known tools like Mimikatz or common persistence techniques.
False Positive (Alert)
An alert that fires but turns out to be benign, like a system update script that resembles a malware download.
Wastes analyst time and can cause alert fatigue if too frequent.
Often caused by overly broad detection rules or legitimate software misidentified as malicious.
Mistake
If antivirus does not detect it, the file is safe.
Correct
Antivirus relies on signatures of known malware. Attackers use custom-built malware or fileless techniques that never write a file to disk. Endpoint analysis looks at behaviour, not just signatures.
People trust the green checkmark of antivirus. They do not understand that modern attacks bypass signature detection by design. This misconception is dangerous because it leads to ignoring behavioural alerts.
Mistake
A process named 'svchost.exe' is always safe because it is a legitimate Windows system process.
Correct
Attackers often name their malware 'svchost.exe' to blend in. The safe version runs from C:\Windows\System32. If the same process name appears in C:\Users\Public\ or a temporary folder, it is almost certainly malicious.
People recognise the name and stop investigating. They do not check the file path. The exam specifically tests this by providing a process tree with a legitimate-named process in a suspicious directory.
Mistake
A single failed login alert is always a brute-force attack in progress.
Correct
One failed login could be a legitimate user mistyping a password. Multiple failed logins from the same IP in a short time window (e.g., 10 in 1 minute) indicate a brute-force attack. Analysts must look at volume and pattern, not just the event.
Beginners overreact to any security event. The exam tests whether you can differentiate a true positive from a benign anomaly by applying context (time, frequency, source).
Mistake
PowerShell is only used by system administrators, so any PowerShell execution is suspicious.
Correct
PowerShell is a legitimate administration tool used constantly by IT staff. However, attackers also use it for fileless attacks. You must examine the command-line arguments and parent process to judge intent. A PowerShell launched by Outlook is suspicious (phishing); one launched by a scheduled backup script is normal.
People see 'PowerShell' and immediately flag it as malicious. The exam puts PowerShell in normal contexts to see if you evaluate the full picture, not just the tool name.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A SIEM (Security Information and Event Management) collects logs from many sources and generates alerts based on correlation rules. An EDR (Endpoint Detection and Response) is an agent installed on each endpoint that records detailed process, file, and network activity. The SIEM tells you an alert exists; the EDR provides the data to investigate it.
Yes. The exam commonly tests Event ID 4625 (failed logon), 4624 (successful logon), 4688 (process creation), and 5156 (network connection). You do not need to memorise hundreds, but these four appear regularly in exhibit-based questions.
A process tree is a hierarchical view showing which process launched which. For example, 'explorer.exe -> cmd.exe -> powershell.exe'. Analysts use it to find the entry point of an attack. If a script launches a suspicious executable, the script is the parent, and you trace back to the original source (e.g., a browser download).
A fileless attack does not write any malicious file to disk. Instead, it runs code directly in memory, often using legitimate tools like PowerShell or WMI. This means traditional antivirus (which scans files) cannot detect it. EDR detects fileless attacks by monitoring process behaviour and command-line arguments.
Check the process reputation (is it signed by a trusted vendor?), the file path (is it in the expected system directory?), the parent process (is it a normal launcher?), and the network destination (is it a known benign service?). If everything checks out, it is a false positive. The exam tests this by mixing benign but unusual-looking events with real threats.
Persistence is any technique an attacker uses to ensure their malware runs again after a reboot or logoff. Common persistence mechanisms include registry Run keys, scheduled tasks, and startup folder entries. Finding unauthorised persistence is a strong indicator that a system is compromised and the attacker intends to stay.
You've finished Endpoint Intrusion Analysis. Continue through the 200-201 study guide to build a complete picture of the exam.
Done with this chapter?