ES1.10 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. 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 instead of disabling the rule entirely.

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 AV exclusion list (via Get-MpPreference) knows exactly where to store their tools. Understanding that AV scanning works at the file system level (intercepting file operations via the MDE minifilter driver) explains why directory exclusions create such broad gaps. The informed alternative: exclude specific file extensions within the directory (*.mdf, *.ldf for SQL data files) rather than the entire path.

ETW tampering threatens your detection stack because EDR depends on ETW. The engineer who understands that MDE uses both ETW providers (user mode) and kernel callbacks (kernel mode) knows that user-mode ETW patching does not blind MDE completely. The engineer who does not understand ETW may see a red team report about “EDR bypass via ETW patching” and conclude that MDE is fundamentally broken — when in reality, the bypass is partial and the kernel-mode visibility remains intact. The informed response: enable HVCI to protect kernel callbacks, deploy Sysmon as an independent telemetry source, and build detections for ETW tampering indicators. The uninformed response: panic, consider replacing the EDR product.

Credential Guard matters because of how LSASS stores secrets. The engineer who understands that LSASS stores NTLM hashes and Kerberos tickets in process memory — and that Credential Guard moves those secrets to an isolated virtual machine — understands WHY Credential Guard is worth the deployment effort. They can also explain to IT operations why Credential Guard breaks NTLMv1 delegation (because the secrets are no longer in LSASS for delegation) and propose the correct remediation (migrate to Kerberos authentication).

Why OS internals knowledge changes your engineering decisions

Without OS internals knowledge, endpoint security engineering is configuration by documentation: Microsoft says to enable this setting, so you enable it. With OS internals knowledge, endpoint security engineering is configuration by understanding: you know WHY the setting works, WHAT it protects, and WHEN it is insufficient.

Three examples of how OS internals knowledge changes engineering decisions:

AV exclusions for SQL Server. The documentation says: “Exclude .mdf and .ldf files from AV scanning.” Without internals knowledge, you create the exclusion and move on. With internals knowledge, you understand: the SQL Server storage engine holds file locks on .mdf and .ldf files. AV scanning attempts to read these files, which contends with SQL’s file locks, causing query latency. The exclusion prevents this contention. But you also understand: a directory-level exclusion (excluding C:\SQLData) creates a scanning blind spot where an attacker could place an executable without detection. The file-extension exclusion (.mdf, .ldf) is narrower — it exempts only the database files while still scanning executables in the same directory. The OS internals knowledge (file locking mechanics) drives the engineering decision (extension exclusion, not directory exclusion).

ASR rule: Block credential stealing from LSASS. The documentation says: “This rule blocks known patterns of credential access to LSASS.” Without internals knowledge, you enable the rule and assume credential theft is prevented. With internals knowledge, you understand: this rule blocks specific API call patterns that known tools (Mimikatz, procdump) use to access LSASS memory. It does NOT block: direct syscalls that bypass the API hooks the rule monitors, reflective injection that loads credential dumping code into LSASS’s own process space, or comsvcs.dll MiniDump which uses a different API path. The rule is a valuable layer but not a complete defense. You need additional layers (Credential Guard, Sysmon Event ID 10, custom detection NE-CRED-002) to cover the techniques the ASR rule does not address. The OS internals knowledge (how LSASS access works at the API level) drives the layered defense architecture.

Sysmon deployment alongside MDE. The documentation says: “MDE provides comprehensive endpoint telemetry.” Without internals knowledge, you accept this and skip Sysmon deployment. With internals knowledge, you understand: MDE’s sensor subscribes to ETW providers for telemetry. ETW providers can be patched by an attacker to suppress events. Sysmon’s kernel driver uses a different mechanism (PsSetCreateProcessNotifyRoutine callback) for process monitoring — it is independent of the ETW providers that MDE relies on. If an attacker patches an ETW provider, MDE loses visibility but Sysmon continues capturing events. Additionally, Sysmon captures DNS queries (Event ID 22) and named pipe connections (Event IDs 17/18) that MDE does not capture comprehensively. The OS internals knowledge (ETW architecture and its limitations) drives the decision to deploy Sysmon as a complementary telemetry source.

The pattern: OS internals knowledge transforms endpoint security from “follow the vendor documentation” to “engineer a defense architecture that accounts for how the OS actually works and how attackers actually exploit it.”

ES13 (Cross-Platform): Server-specific configurations (DC AV exclusions, SQL Server scan optimisation) require understanding the workload’s OS-level behaviour — how ntds.dit is accessed (ES1.2), how SQL Server manages file locks, how IIS handles web content. Linux deployment (mdatp with eBPF) connects directly to ES1.6. macOS deployment (Endpoint Security framework, TCC permissions) connects directly to ES1.8. The cross-platform module applies internals knowledge from this module to every platform NE operates.

The course roadmap: from internals to architecture

Each subsequent module in this course builds on the OS internals foundation from ES0-ES1. Here is how the internals knowledge connects to the specific engineering decisions ahead:

ES2 (MDE Architecture): Understanding the MDE sensor requires understanding ETW (ES1.4) — the sensor subscribes to ETW providers and processes their events. Understanding device health requires understanding the Windows service model — MsSense.exe runs as a service and depends on kernel drivers (WdFilter.sys, SysmonDrv.sys) that interact with the components from ES1.1-ES1.5.

ES4 (ASR Rules): Each ASR rule blocks a specific OS-level operation. “Block Office applications from creating child processes” targets the process creation mechanism from ES1.1. “Block credential stealing from LSASS” targets the LSASS access patterns from ES1.2. “Block executable content from email client” targets the file system and process creation path. Understanding the OS operation the rule blocks reveals whether the rule provides genuine protection or merely blocks one implementation of the technique.

ES8 (Detection Engineering): Writing effective KQL detection rules requires understanding what data is available and where it comes from. DeviceProcessEvents originates from ETW providers (ES1.4). DeviceRegistryEvents reflects the registry operations from ES1.3. DeviceLogonEvents maps to the authentication flow from ES1.5. A detection engineer who understands the OS internals writes rules that match the OS behaviour, not rules that match a specific tool’s output.

ES11 (Forensic Readiness): Configuring audit policies, Sysmon, and PowerShell logging requires understanding: which OS components generate the events (ES1.4-ES1.5), where the events are stored (event log architecture), and what an attacker can do to suppress them (ETW tampering from ES1.4, log clearing detection).

ES12 (Evasion): Every evasion technique targets a specific OS component. Process injection (ES1.1 process model), ETW tampering (ES1.4), credential dumping (ES1.2 LSASS), and AMSI bypass (PowerShell engine architecture). The evasion module teaches the technique; this module provides the OS-level understanding of WHY the technique works.

Troubleshooting

“I understand the internals but I’m not sure which controls to prioritize first.” Return to the deployment sequence from ES0.7. The internals knowledge from this module does not change the deployment order — it changes the CONFIDENCE with which you deploy each control. Phase 1 (visibility) remains first. Phase 2 (prevention) remains second. But now you understand WHY the LSASS ASR rule is safe to deploy early (low false positive because few legitimate non-Microsoft processes access LSASS) and WHY the Office child process ASR rule requires more preparation (legitimate LOB applications may use Office process spawning).

“The OS internals seem Windows-focused — but half our critical infrastructure is Linux.” The Linux sections (ES1.6, ES1.7) cover the kernel, eBPF, PAM, sudo, and privilege escalation that are specific to Linux environments. Module ES13 applies this knowledge to NE’s RHEL and Ubuntu servers with specific configuration. The Windows focus in this module reflects the endpoint composition of most M365 E5 environments — but the Linux knowledge is equally important for the servers that host critical data.