Module Summary

What you learned in this module

ES1 took you inside the operating system — the layer that every endpoint security control from ES2 through ES15 ultimately defends. Here is what you now understand:

The Windows process model is both the execution environment and the attack surface (Section 1.1). Processes hold access tokens (stolen via token theft), handle tables (duplicated for LSASS access), virtual memory spaces (targeted by injection), and parent-child chains (the highest-fidelity detection signal). ASR rules, EDR behavioral alerts, and Sysmon Event IDs each defend a specific component of the process model. Understanding the model transforms these controls from checkboxes into architectural decisions.

LSASS is the most targeted process on Windows — and the most defended (Section 1.2). LSASS stores NTLM hashes, Kerberos TGTs, cached credentials, and DPAPI keys for every user who has logged into the endpoint. Three extraction methods (Mimikatz, comsvcs.dll MiniDump, Procdump) and four defensive controls (ASR rule, RunAsPPL, Credential Guard, MDE behavioral detection) form the attack-defense dynamic. Credential Guard uses virtualization-based security to isolate secrets in LSAIso — inaccessible even to kernel-level code.

The registry is the most common persistence surface in endpoint attacks (Section 1.3). Run keys, services, COM hijacking, IFEO debugger redirection, WMI subscriptions, and LSA authentication packages each provide a persistence mechanism. Sysmon Event IDs 12 and 13 with targeted registry path monitoring detect registry-based persistence when combined with process context filtering in the KQL detection layer.

ETW is the telemetry foundation your entire detection stack depends on (Section 1.4). MDE and Sysmon receive events from ETW providers. User-mode ETW patching blinds user-mode telemetry but not kernel callbacks. Kernel callback removal via BYOVD blinds both layers. The defensive stack — HVCI, tamper protection, the vulnerable driver ASR rule, and Sysmon as an independent telemetry source — protects ETW integrity at each layer.

The Windows security subsystem processes every authentication from keyboard to token (Section 1.5). Winlogon, LSASS, SSPI, the Kerberos SSP, the KDC, and the Security Reference Monitor form the authentication chain. Each component is both a defensive control point and an attack target. NTLM authentication creates a larger credential exposure window than Kerberos because NTLM hashes persist indefinitely while Kerberos TGTs expire in 10 hours.

eBPF is to Linux what ETW and kernel callbacks are to Windows (Section 1.6). eBPF provides real-time kernel-level visibility that is fundamentally safer than kernel modules because the BPF verifier guarantees program safety before loading. Defender for Linux uses eBPF for process, file, and network monitoring. Fanotify fallback provides limited file-only monitoring on older kernels. Linux servers without mdatp are invisible to the SOC.

Linux privilege escalation is binary — root or not root (Section 1.7). Five escalation paths — sudo misconfigurations (GTFOBins shell escapes), SUID abuse, capability exploitation, kernel vulnerabilities, and PAM modification — each target a different OS mechanism. SSH key theft is the Linux equivalent of pass-the-hash: immediate lateral movement without password knowledge. PAM file integrity monitoring detects the authentication backdoors that survive password changes.

macOS provides stronger built-in prevention than Windows or Linux (Section 1.8). TCC restricts application access to sensitive resources at the kernel level. Gatekeeper blocks unsigned execution. SIP prevents system modification even by root. The Endpoint Security Framework provides the API MDE uses for macOS telemetry. Apple Silicon adds Secure Boot and signed system volumes. TCC bypass vulnerabilities are the primary macOS post-exploitation research area because TCC is effective enough to be worth bypassing.

Every OS component maps to an ATT&CK technique and a defensive control (Section 1.9). The three-column mapping — internal → technique → defense — drives every configuration decision. Prevention before detection, controls for the earliest attack phase first, and the top five techniques (T1003.001, T1547.001, T1059.001, T1055, T1021) provide the highest return on engineering investment.

Understanding OS internals transforms configuration from checklist following to engineering (Section 1.10). The engineer who understands the OS troubleshoots false positives at root cause, predicts blast radius from first principles, and builds detections based on OS behavior. The engineer without that understanding enables and disables controls based on vendor documentation alone.

What's next

Module ES2 begins the engineering work — configuring Defender Antivirus with the understanding of the AV engine's architecture that this module provided. You will configure cloud protection levels, understand why AV exclusions create security gaps (because the minifilter driver stops processing IO for excluded paths), and deploy the prevention foundation that every subsequent module builds on. The OS internals from this module inform every decision in ES2: why tamper protection matters (it prevents attackers from disabling Defender through the mechanisms described in Section 1.4), why process-based exclusions are safer than directory exclusions (the AV engine evaluates at the process level, not the directory level), and why cloud protection at High+ catches more than Default (the cloud service runs ML models that the local engine cannot).