Endpoint Architecture and OS Internals

0.1 What endpoint architecture and OS internals means for defenders

Every endpoint security control from ES2 through ES15 defends something specific at the operating system level. ASR rules block process behaviors — but which process behaviors, and why those specific ones? Credential Guard isolates memory regions — but what is stored in those regions, and how does an attacker access them without it? EDR depends on ETW for every event it collects — but what is ETW, and what happens when an attacker disables the providers your detections rely on?

This module takes you inside the operating system from the defender's perspective. Not the developer's view of how to build software. The view of what attackers target: processes and the tokens that carry their privileges, LSASS and the credential material it holds, the registry as a persistence surface, ETW as the telemetry backbone that makes detection possible, and the security subsystem that governs authentication and authorization. Then Linux and macOS — because endpoint security extends beyond Windows, and cross-platform coverage gaps are where attackers go when Windows is well-defended.

The reason this module exists before any control deployment is architectural. When you configure an ASR rule in ES4, you will know which OS API call it intercepts and can predict the blast radius from first principles. When you deploy Credential Guard in ES3, you will know that it uses the hypervisor to create a separate virtual trust level where LSASS secrets are stored — inaccessible even to the NT kernel. When you write custom detection rules in ES8, you will know which DeviceEvents table fields map to which OS-level operations and why certain field combinations indicate compromise. When you deploy Sysmon in ES11, you will know that it registers ETW consumers for specific providers and writes the events to the Sysmon operational log. Every module depends on the OS understanding this module builds.

0.2 What you will learn

Ten sections, each covering a critical OS component from the security perspective.

Section 1.1 — The Windows Process Model. Processes, threads, tokens, handles, and the access rights that govern them. What process injection exploits at the OS level. What token manipulation achieves. Why parent-child chain analysis is the highest-fidelity detection method available. The DeviceProcessEvents fields that record these operations.

Section 1.2 — LSASS and Credential Storage. Why LSASS is the most targeted process on Windows. How credential material — NTLM hashes, Kerberos TGTs, cached credentials — is stored in LSASS memory. The three extraction methods (Mimikatz, comsvcs.dll MiniDump, Procdump) and the four defensive controls (ASR rule, RunAsPPL, Credential Guard, MDE behavioral detection). Logon types and credential exposure per session type.

Section 1.3 — The Windows Registry as an Attack Surface. The registry hives that attackers use for persistence: Run keys, Services, Scheduled Tasks, COM objects, IFEO debugger redirection, AppInit_DLLs, WMI subscriptions, and LSA authentication packages. The Sysmon Event IDs and KQL queries that detect registry-based persistence.

Section 1.4 — Event Tracing for Windows. The kernel-level telemetry infrastructure that every EDR product depends on. How ETW providers generate events, how sessions buffer them, and how consumers process them. What happens when attackers tamper with ETW — user-mode patching, trace session manipulation, kernel callback removal. Why HVCI and tamper protection exist.

Section 1.5 — The Windows Security Subsystem. The authentication chain from user input through Winlogon, LSASS, SSPI, the KDC, to the access token. NTLM versus Kerberos credential exposure. Protected Process Light and the Security Reference Monitor. Kerberos attack techniques — Kerberoasting, AS-REP roasting, Golden and Silver Tickets.

Section 1.6 — Linux Kernel Security and eBPF. Kernel namespaces, cgroups, seccomp, and how they create security boundaries. eBPF as the modern kernel-level monitoring framework that MDE's Linux sensor uses. Container escape techniques and detection. The cross-platform coverage gap — what happens when Linux servers have no endpoint agent.

Section 1.7 — Linux Authentication and Privilege. PAM modules and authentication flow. Sudo configuration and abuse — GTFOBins shell escapes. SUID/SGID and capabilities. The five privilege escalation paths on Linux and the defensive control for each. SSH key theft as the Linux equivalent of pass-the-hash.

Section 1.8 — macOS Security Architecture. TCC as the permission framework that restricts application access to sensitive resources. Gatekeeper for application trust. SIP as kernel-level enforcement even against root. The Endpoint Security Framework that MDE hooks into. Apple Silicon Secure Boot. Where macOS security differs architecturally from Windows and Linux.

Section 1.9 — What Attackers Actually Target. The OS components from Sections 1.1–1.8 mapped to MITRE ATT&CK techniques and defensive controls. The three-column mapping — internal → technique → defense — that drives every configuration decision. Cross-platform attack patterns. Prioritization framework for the top five techniques.

Section 1.10 — From Internals to Controls. How OS internals knowledge changes configuration decisions. Why the engineer who understands LSASS deploys Credential Guard with confidence. Why the engineer who understands ETW does not panic at "EDR bypass" red team findings. The bridge from understanding (ES1) to engineering (ES2–ES15).

0.3 Why OS internals matter for endpoint security engineering

Endpoint security is not a product — it is a set of controls that operate on specific OS mechanisms. If you understand the mechanisms, the controls make architectural sense. If you do not, they are arbitrary configuration steps that you follow because a guide told you to.

Consider the ASR rule "Block credential stealing from the Windows local security authority subsystem." Without understanding LSASS, this is a checkbox. With the architecture from Section 1.2, you understand: LSASS holds NTLM hashes and Kerberos TGTs in memory. The ASR rule blocks non-Microsoft processes from opening a handle to the LSASS process with PROCESS_VM_READ access. An attacker who bypasses the rule must use alternative credential access techniques — Kerberoasting, DCSync, or token theft — each of which targets a different OS component and generates different telemetry. The rule is not a checkbox. It is a defense of a specific memory space that forces a specific attacker behavior change that creates a specific detection opportunity.

That level of understanding is what this module builds. The OS internals do not change across product versions or platform updates. The controls built on top of them evolve, but the foundation — processes, tokens, credential storage, telemetry infrastructure, authentication chains — is stable knowledge that compounds throughout your career.

KQL gives you direct analytical access to the OS-level telemetry. Every query in this module runs against DeviceProcessEvents, DeviceRegistryEvents, DeviceLogonEvents, or DeviceEvents — the MDE tables that record OS operations. You are not dependent on portal views or vendor dashboards. You query the OS-level data directly and see exactly what happened.

0.4 How to get the best from this module

Work through the sections in order. Each builds on the previous — the process model (1.1) is the foundation for LSASS (1.2), the registry (1.3), and ETW (1.4). The security subsystem (1.5) synthesizes the Windows components. The Linux and macOS sections (1.6–1.8) stand alone but are most valuable after the Windows sections because the comparison reveals both the platform-specific attack surfaces and the cross-platform gaps.

Sections 1.1 and 1.2 are the conceptual core. Every module from ES2 onward references process behavior and credential protection. If you understand how tokens carry privileges and how LSASS stores credentials, the ASR rules in ES4, the Credential Guard deployment in ES3, and the detection rules in ES8 will make immediate architectural sense.

Section 1.10 (internals to controls) is the reference you will return to throughout the course. Bookmark it. When a later module teaches a control and you want to understand what it defends at the OS level, Section 1.10 provides the mapping.

Estimated total time: 4 to 5 hours. Two to three sections per session produces consistent progress.

0.5 Module structure

• Section 1.1 — The Windows Process Model
• Section 1.2 — LSASS and Credential Storage
• Section 1.3 — The Windows Registry as an Attack Surface
• Section 1.4 — Event Tracing for Windows
• Section 1.5 — The Windows Security Subsystem
• Section 1.6 — Linux Kernel Security and eBPF
• Section 1.7 — Linux Authentication and Privilege
• Section 1.8 — macOS Security Architecture
• Section 1.9 — What Attackers Actually Target
• Section 1.10 — From Internals to Controls

Prerequisite: ES0 (Endpoint Security Foundations). The five-layer stack, the attack chain phases, and the NE gap assessment from Module 0 provide the context for understanding why each OS component matters to defenders.

Go to Section 1.1 — The Windows Process Model to begin.