From Internals to Controls

Why internals knowledge changes configuration outcomes

ASR rules exist because of specific OS behaviors. The ASR rule "Block Office applications from creating child processes" exists because the Windows process model allows any process to create child processes via CreateProcess (Section 1.1). Macro-based malware exploits this: the Office process executes a macro that calls CreateProcess to spawn PowerShell. The ASR rule intercepts the CreateProcess call when the parent is an Office process and blocks it. Knowing this, you can predict which legitimate software will trigger the rule — anything that legitimately launches a helper process from Office — and build targeted exclusions for the specific Office add-in's helper binary instead of disabling the rule entirely.

Without internals knowledge, the ASR rule is a checkbox. With it, the rule is a specific interception of a specific OS API call, and the false positive is a specific software component calling the same API for legitimate reasons. The troubleshooting path is different: the informed engineer checks which child process Office is trying to create and creates a process exclusion. The uninformed engineer sees "ASR blocked something" and turns it off.

AV exclusions are dangerous because of how AV scanning works. A directory-level AV exclusion like C:\SQLData\ means Defender will not scan any file in that directory — including malware an attacker places there. The attacker who discovers your exclusion list (via Get-MpPreference, which is readable by any local admin) knows exactly where to store their tools without detection. Understanding that AV scanning intercepts file operations through the MDE minifilter driver — a kernel-level file system filter from Section 1.4 — explains why directory exclusions create broad gaps: the minifilter stops processing the IO operation entirely for excluded paths, so no telemetry is generated for files in those directories. The informed alternative: exclude specific file extensions within the directory (.mdf, .ldf for SQL data files) rather than the entire path, or use process-based exclusions that allow the SQL Server process to write without scanning while still scanning files written by other processes.

The same principle applies to Linux. If you exclude /var/lib/mysql/ from Defender for Linux scanning to reduce IO impact on the database, you create a directory where an attacker can store tools undetected. The eBPF-based monitoring from Section 1.6 still captures process execution events from that directory — mdatp's real-time protection exclusion does not affect the eBPF telemetry. But the file scanning that would detect a known malware binary placed in the excluded directory is skipped. Understanding the separation between real-time protection (file scanning via minifilter or fanotify) and EDR telemetry (ETW or eBPF event capture) is what lets you make informed exclusion decisions: exclude from scanning for performance while retaining behavioral detection for security.

ETW tampering does not mean your EDR is broken. The engineer who understands that MDE uses both ETW providers (user mode) and kernel callbacks (kernel mode) from Section 1.4 knows that user-mode ETW patching does not blind MDE completely — the kernel callbacks continue operating. When a red team report says "we bypassed EDR via ETW patching," the informed response is: enable HVCI to protect kernel callbacks, deploy Sysmon as an independent telemetry source, and build detections for ETW tampering indicators. The uninformed response — concluding that the EDR product is fundamentally broken and needs replacement — wastes budget and time on a problem that defense-in-depth already addresses.

Credential Guard matters because of how LSASS stores secrets. The engineer who understands that LSASS stores NTLM hashes and Kerberos tickets in process memory (Section 1.2) — and that Credential Guard moves those secrets to an isolated virtual machine inaccessible even to kernel-level code — can explain to IT operations why Credential Guard is worth the deployment complexity. They can also explain why it breaks NTLMv1 delegation: the secrets are no longer in LSASS for delegation because they have been moved to LSAIso, the isolated credential process running in Virtual Trust Level 1. The correct remediation is migrating affected applications to Kerberos authentication or Kerberos constrained delegation, not disabling Credential Guard. The engineer who understands the architecture proposes a migration path. The engineer who does not understand it sees "Credential Guard broke our application" and reverts the deployment.

This pattern — understanding enables targeted remediation, ignorance enables only on/off decisions — repeats across every module. On Linux (Section 1.7), understanding PAM means you can troubleshoot a failed SSH authentication by reading the PAM stack configuration and identifying which module is rejecting the credentials. Without understanding PAM, you restart the SSH service and hope. On macOS (Section 1.8), understanding TCC means you can deploy an Intune TCC profile that grants MDE the specific permissions it needs without over-provisioning access. Without understanding TCC, you grant Full Disk Access to everything and create unnecessary security exposure.

The bridge to every subsequent module

Every module from ES2 through ES15 connects back to an OS internal from this module. The connection is explicit — when you configure a control, you will know which OS component it defends and which attack technique it prevents.

Module ES2 (Defender Antivirus) configures the real-time protection engine that uses the minifilter driver to intercept file operations — the kernel-level file system hook from Section 1.4. Understanding the minifilter architecture explains why AV exclusions are directory-scoped (the minifilter intercepts IO at the file system level), why real-time protection has performance impact on IO-heavy workloads (every file operation passes through the filter), and why cloud protection adds latency (the file hash is checked against the cloud service before the file operation completes).

Module ES3 (Credential Protection) deploys Credential Guard, which uses virtualization-based security to isolate LSASS credential material in LSAIso — the architecture from Section 1.2. Understanding VBS explains why Credential Guard requires specific hardware (the hypervisor must support virtual trust levels), why it breaks NTLMv1 delegation (the credentials are in a different virtual machine), and why it protects against kernel-level attacks (even kernel code in the main OS cannot access the isolated virtual trust level).

Module ES4 (Attack Surface Reduction) configures ASR rules that intercept specific OS API calls — process creation (Section 1.1), handle acquisition (Section 1.2), registry modification (Section 1.3). Understanding which API call each rule intercepts explains the blast radius: the Office child process rule intercepts CreateProcess, which affects legitimate Office add-ins that launch helpers. The LSASS rule intercepts OpenProcess with specific access flags, which affects legitimate tools that read LSASS for monitoring purposes.

Module ES8 (Custom Detections) builds KQL detection rules that query the MDE tables populated by the telemetry infrastructure from Section 1.4. Understanding which ETW provider generates which DeviceEvents table field explains why certain detection patterns work and why others produce false positives. A detection rule for process injection that filters on CreateRemoteThread works because Sysmon Event ID 8 and the kernel process callback both capture remote thread creation — two independent sources confirming the same OS-level event.

Module ES13 (Cross-Platform) deploys Defender for Linux using eBPF (Section 1.6) and Defender for macOS using the Endpoint Security Framework (Section 1.8). Understanding the platform-specific telemetry architectures explains why detection rules must be adapted per platform: the same ATT&CK technique uses different OS mechanisms on each platform, generates different telemetry fields, and requires different KQL query logic.

Module ES11 (Sysmon Deployment) configures the independent telemetry source that provides defense-in-depth against ETW tampering (Section 1.4). Understanding that Sysmon registers its own kernel driver and ETW provider — separate from MDE's driver and providers — explains why Sysmon provides redundancy: an attacker who patches MDE's user-mode ETW consumption does not affect Sysmon's kernel driver. Sysmon Event IDs 1 (ProcessCreate), 8 (CreateRemoteThread), 10 (ProcessAccess), 12/13 (RegistryEvent), and 7 (ImageLoaded) each map to a specific OS operation from this module. The Sysmon configuration file defines which events to capture and which to exclude — writing effective Sysmon rules requires understanding which OS operations generate which events, which is the knowledge this module provides.

Module ES15 (Capstone) validates the complete endpoint security architecture by attacking it. The capstone simulates the CHAIN-ENDPOINT attack chain against NE's hardened environment and verifies that each control deployed in ES2-ES14 fires at the correct phase. The validation traces through the OS internals: does the Office child process ASR rule block the macro execution (process creation from Section 1.1)? Does the LSASS ASR rule block the credential dump (handle access from Section 1.2)? Does the registry detection rule catch the persistence attempt (registry modification from Section 1.3)? Does the ETW tamper protection prevent telemetry blinding (ETW integrity from Section 1.4)? Each validation check connects a control to its OS internal and confirms the defense operates as the architecture predicts.

The journey from this module to Module ES15 is the journey from understanding to engineering. You now understand what attackers target at the OS level. The remaining modules teach you to engineer the controls that defend each target, test them against realistic attack chains, and validate that they work in your environment. The OS internals do not change. The controls built on top of them are what you will deploy, tune, troubleshoot, and defend throughout your career as an endpoint security engineer.

The practical takeaway from this module is a mental model you will apply in every subsequent section. When Module ES4 presents the ASR rule "Block Office from creating child processes," you will understand that this rule intercepts the CreateProcess API when the parent is an Office binary — and you will predict the blast radius (Office add-ins that launch helpers) without needing to test it blind. When Module ES8 builds a detection rule for LSASS access, you will understand that the rule queries Sysmon Event ID 10 for process handles to lsass.exe with specific access flags — and you will know why the access flags matter (PROCESS_VM_READ is credential dumping, PROCESS_QUERY_LIMITED_INFORMATION is benign). When Module ES13 deploys Defender for Linux, you will understand that the eBPF telemetry provides different event granularity than Windows ETW — and you will adapt your detection rules accordingly rather than assuming cross-platform parity.

This is the transformation the module delivers. You are not learning OS trivia. You are learning the engineering substrate on which every endpoint security decision rests. The next module begins the engineering: Module ES2 configures the first layer of the defense stack — Defender Antivirus — with the understanding of the AV engine's architecture and limitations that this module provided.