ES1.12 Module Summary

What you built in this module

This module took you inside the operating system — the layer that endpoint security controls ultimately defend. Not at the level of a kernel developer, but at the level needed to make informed security engineering decisions.

You examined the Windows process model from a security perspective: processes as containers holding tokens, handles, and virtual memory — each component an attack surface. Access tokens define privilege and are stolen via token theft and impersonation. Handle tables provide access to resources including other processes — the handle to LSASS is the prerequisite for credential dumping. Virtual memory is where injected code hides — CreateRemoteThread, process hollowing, and APC injection all write malicious code into legitimate processes. Parent-child chains create the behavioral fingerprint that detection relies on — anomalous chains (Word→PowerShell, svchost→cmd) are among the highest-fidelity detection signals available.

You learned why LSASS is the most targeted process on Windows — it stores NTLM hashes, Kerberos tickets, cached credentials, and DPAPI keys for every user who has logged into the machine. You examined the three extraction methods (Mimikatz, comsvcs.dll MiniDump, Procdump) and the four defensive controls (ASR rule, RunAsPPL, Credential Guard, MDE behavioral detection). Each control addresses a different level of attacker sophistication. Layering all four provides genuine defense in depth.

You explored the Windows registry as a persistence surface — Run keys, services, COM hijacking, IFEO, WMI subscriptions, AppInit_DLLs, and LSA authentication packages. Each location is a potential persistence mechanism. Sysmon Event IDs 12 and 13 combined with targeted registry path monitoring provide the detection capability for registry-based persistence.

You understood ETW as the telemetry foundation for your entire detection stack. MDE and Sysmon depend on ETW providers for event data. ETW tampering — patching providers, disabling sessions, removing kernel callbacks — is a real evasion technique that blinds security tools. HVCI, tamper protection, and the vulnerable driver ASR rule protect ETW integrity.

You mapped the Windows security subsystem — from user credential input through Winlogon, LSA, SSPI, SAM/AD/KDC, to the access token and authenticated session. Each component is both a defensive control point and an attack target.

You examined Linux kernel security — the process model, namespaces, cgroups, and eBPF as the foundation for modern Linux endpoint security monitoring. You explored Linux privilege escalation paths — PAM, sudo, SUID, capabilities, kernel exploits — and the hardening and detection controls for each.

You reviewed macOS security architecture — TCC, Gatekeeper, SIP, and the Endpoint Security Framework — understanding what macOS provides natively and where third-party endpoint security adds value.

Finally, you connected every OS internal to a specific ATT&CK technique and a specific defensive control, building the three-column mapping that drives every configuration decision in this course.

What comes next

Module ES2 begins the engineering work. You will configure MDE’s sensor architecture, complete onboarding to 100% of the fleet, build the device health monitoring dashboard, and establish the visibility foundation that every subsequent module depends on. The OS internals knowledge from this module informs every decision: why the sensor has both user-mode and kernel-mode components (to survive ETW evasion), why onboarding validation matters (a sensor that is not running provides zero visibility), and why device groups and RBAC structure affect your security operations capability.