In this section
What Attackers Actually Target
Sections 1.1 through 1.8 covered the OS internals across three platforms — processes, LSASS, the registry, ETW, the security subsystem, Linux kernel and privilege, and macOS security architecture. This section connects each internal to the specific ATT&CK technique that abuses it and the defensive control that protects it. This three-column mapping — internal → technique → defense — is the mental model that transforms OS knowledge into endpoint security engineering decisions.
Scenario
You are prioritizing endpoint security controls for NE. Threat intelligence indicates the most likely attack chain is: phishing → macro execution → PowerShell download cradle → LSASS credential dump → lateral movement via PsExec. Five distinct attack phases, each targeting a different OS component from this module. The question is not "which controls should I deploy" — the answer is "all of them." The question is which controls to deploy first, and that requires knowing which OS component each phase targets and which control interrupts it.
The mapping that drives every configuration decision
The three-column mapping below is not a reference table to memorize. It is a decision framework. When you encounter an endpoint security configuration question — "should I enable this ASR rule?" "should I deploy Credential Guard?" "should I configure this Sysmon event ID?" — the framework answers by connecting the control to the attack it prevents and the OS mechanism it protects.
Process model (Section 1.1) → T1055 Process Injection, T1134 Access Token Manipulation. Processes, threads, handles, and tokens enable attackers to inject code into legitimate processes and manipulate token privileges for escalation. The OS component is the virtual memory space (for injection) and the access token (for privilege escalation). The prevention: ASR rule "Block process injection" interrupts handle acquisition. The detection: Sysmon Event ID 8 (CreateRemoteThread) and Event ID 10 (ProcessAccess) capture the OS-level operations. The course module: ES4 deploys the ASR rule, ES8 builds the detection.
LSASS (Section 1.2) → T1003.001 OS Credential Dumping: LSASS Memory. LSASS stores credential material in process memory — NTLM hashes, Kerberos tickets, cached credentials. Every credential dumping technique targets this single process. The OS component is the LSASS process memory space. The prevention: ASR LSASS rule blocks handle acquisition, RunAsPPL enforces kernel-level access control, Credential Guard isolates the credential material in a separate virtual machine. The detection: Sysmon Event ID 10 for LSASS access, MDE behavioral alerts. The course modules: ES3 deploys Credential Guard, ES4 deploys the ASR rule, ES8 builds custom detection rules NE-CRED-001 through NE-CRED-005.
Registry (Section 1.3) → T1547.001 Boot/Logon Autostart Execution: Registry Run Keys, T1546.015 Event Triggered Execution: COM Hijack, T1546.012 Image File Execution Options. The registry stores configuration that the OS executes automatically — Run keys at logon, services at boot, COM objects on application load. The OS component is the registry hive files and the execution logic that reads them. The prevention: no prevention control — registry persistence is a detection problem. The detection: Sysmon Event IDs 12/13 for registry modification with process context, DeviceRegistryEvents for fleet-wide monitoring. The course module: ES8 builds registry persistence detection rules.
ETW (Section 1.4) → T1562.006 Impair Defenses: Indicator Blocking. ETW providers generate the telemetry that EDR depends on. Patching a provider blinds the EDR to specific event categories without disabling the security tool. The OS component is the ETW provider functions in ntdll.dll (user mode) and the kernel callback registration (kernel mode). The prevention: HVCI prevents unsigned kernel code, the vulnerable driver ASR rule blocks BYOVD attacks that are the prerequisite for kernel-level ETW tampering. The detection: correlation of ntdll.dll loads with subsequent memory protection changes. The course module: ES12 covers ETW integrity protection.
Security subsystem (Section 1.5) → T1558 Steal or Forge Kerberos Tickets, T1550 Use Alternate Authentication Material. The Kerberos authentication flow creates tickets that attackers steal (pass-the-ticket) or forge (golden ticket). The NTLM authentication stores hashes that attackers reuse (pass-the-hash). The OS component is the SSPI/SSP framework and the credential cache in LSASS. The detection: Event ID 4769 with encryption type 0x17 for Kerberoasting, Event ID 4624 with LogonType and AuthenticationPackage for anomalous authentication patterns.
Linux kernel (Section 1.6) → T1611 Escape to Host, T1014 Rootkit. Namespaces provide container isolation boundaries. Kernel modules provide deep persistence. eBPF provides runtime monitoring. The OS components are the namespace boundaries and the kernel module loading mechanism. The prevention: seccomp profiles restrict syscalls, kernel.modules_disabled=1 prevents module loading after boot. The detection: eBPF-based runtime monitoring (Falco, Defender for Linux), Sysmon for Linux.
Linux privilege (Section 1.7) → T1548.003 Sudo Abuse, T1548.001 SUID/SGID Abuse. Sudo misconfigurations and SUID binaries provide privilege escalation from unprivileged user to root. The OS components are the sudoers configuration and the SUID file permission flag. The prevention: sudoers least-privilege review, nosuid mount options. The detection: auth.log sudo monitoring, SUID baseline comparison, DeviceProcessEvents for sudo shell spawns.
macOS TCC/SIP (Section 1.8) → T1548 Abuse Elevation Control Mechanism, T1553 Subvert Trust Controls. TCC restricts application access to sensitive resources. SIP prevents system modification. The OS components are the TCC database and the SIP enforcement mechanism. The prevention: MDM-managed TCC profiles, Gatekeeper enforcement. The detection: MDE for macOS monitoring launch agent creation, TCC database modification alerts.
Figure ES1.9 — The three-column mapping connecting OS internals to attack techniques to defensive controls. Every row is a configuration decision. Every defensive control exists because of the OS internal it protects.
Using the mapping: three worked decisions
The mapping is practical, not academic. Three examples show how it resolves real configuration decisions.
Decision 1: Should I enable the LSASS ASR rule? The OS internal: LSASS stores credential material in process memory (Section 1.2). The attack: Mimikatz reads that memory (T1003.001). The control: the ASR rule blocks the handle acquisition that precedes the memory read. Decision: yes — this control directly prevents the most common credential access technique against the most targeted process. The blast radius is low because very few legitimate applications open handles to LSASS.
Decision 2: Should I deploy Sysmon Event ID 8 (CreateRemoteThread)? The OS internal: Windows allows processes to create threads in other processes' address spaces via CreateRemoteThread (Section 1.1). The attack: process injection (T1055) uses this API to execute code inside a trusted process. The control: Sysmon Event ID 8 logs every remote thread creation with the source and target processes. Decision: yes — this provides the primary detection signal for process injection, which is used by most post-exploitation frameworks.
Decision 3: Should I restrict Linux kernel module loading? The OS internal: Linux allows kernel modules to be loaded at runtime via insmod/modprobe (Section 1.6). The attack: rootkit installation (T1547.006) loads a kernel module that hides attacker activity. The control: setting kernel.modules_disabled=1 in sysctl prevents new module loading after boot. Decision: on production servers that do not need runtime module loading — yes. On development systems where module loading is part of the workflow — monitor module loading events through eBPF instead of blocking.
Cross-platform attack patterns: same objectives, different implementations
Attackers targeting multi-platform environments use the same tactical patterns across all operating systems — the techniques differ but the objectives are identical. Credential access on Windows means Mimikatz dumping LSASS memory. On Linux, it means reading /etc/shadow for password hashes or extracting SSH private keys from ~/.ssh/. On macOS, it means accessing the Keychain database. The same ATT&CK tactic applies to all three — the detection must monitor the platform-specific credential stores.
Persistence on Windows means registry run keys, scheduled tasks, WMI subscriptions. On Linux: cron jobs, systemd services, .bashrc modifications. On macOS: launch agents, login items. Each platform has different mechanisms but the detection pattern is the same: monitor for new entries in persistence-capable locations created by unexpected processes. The detection query logic differs per platform — DeviceRegistryEvents for Windows Run keys, DeviceFileEvents for macOS .plist creation, DeviceProcessEvents for Linux cron job modification — but the analytic approach is identical: baseline the normal rate of persistence location changes, then alert on deviations from the baseline.
Defense evasion on Windows means ETW patching, AMSI bypass, process injection. On Linux: LD_PRELOAD hijacking, kernel module loading, /proc manipulation. On macOS: TCC bypass, Gatekeeper circumvention. Each platform's security architecture creates different evasion targets — the platform-specific architecture from this module reveals the platform-specific evasion techniques. The cross-platform implication: a security team that understands only Windows evasion techniques will not recognize Linux LD_PRELOAD hijacking or macOS TCC bypass attempts. Cross-platform endpoint security requires cross-platform OS knowledge — which is why this module covers all three platforms rather than focusing solely on Windows. The attacker who targets NE will encounter Windows endpoints, RHEL servers, and macOS engineering workstations. The defender who understands only one platform leaves the other two as blind spots that the attacker will exploit.
Cross-platform lateral movement is particularly important for NE's environment. An attacker who compromises a Windows endpoint can dump SSH keys from the user's home directory and use them to access Linux servers — the CHAIN-ENDPOINT attack chain at NE followed exactly this path. The m.chen IT admin account had SSH keys on their Windows workstation for managing the RHEL manufacturing servers. When the attacker dumped LSASS for Windows credentials, they also found the SSH private key in C:\Users\m.chen\.ssh\id_rsa. The Windows credential dump and the Linux SSH access are two phases of the same attack, targeting two different OS credential stores, detected by two different telemetry sources. The detection requires cross-platform hunting queries that correlate Windows credential access events (DeviceProcessEvents showing LSASS access) with subsequent Linux SSH authentication events (DeviceLogonEvents from the RHEL servers). Module ES13 builds these cross-platform detections, and the mapping from this section identifies which OS components are involved at each stage.
The prioritization principle is consistent across platforms: deploy prevention controls before detection controls, and deploy controls that interrupt the earliest phase of the attack chain first. An ASR rule that blocks macro execution (phase 2) provides more value than a detection rule for lateral movement (phase 5) because the prevention control eliminates four subsequent phases. If the prevention control is bypassed, the detection controls for later phases still fire. But if you deploy only late-stage detections, four phases of the attack complete before any alert is generated.
This query identifies which ATT&CK techniques generate the most alerts in your environment across all platforms — the empirical starting point for prioritization. If T1059 (Command and Scripting Interpreter) dominates, your highest-value controls are ASR rules for Office child processes and script execution. If T1003 (Credential Dumping) is high, LSASS protection is the priority. The mapping from this section connects each technique to the OS internal it targets and the control that interrupts it. The query provides the data. The mapping provides the engineering decision.
For most M365 E5 environments, the top-priority techniques are: T1003.001 (LSASS credential dump), T1547.001 (registry Run key persistence), T1059.001 (PowerShell execution), T1055 (process injection), and T1021 (remote services for lateral movement). These five techniques cover the core of most attack chains. The controls that address them — LSASS ASR rule, registry monitoring with Sysmon, AMSI and ScriptBlock logging, process injection detection, and lateral movement detection — provide the highest return on engineering investment. Deploy controls for these five before expanding to the full ATT&CK matrix. An environment that covers 5 techniques well is more secure than one that covers 50 techniques poorly. Depth before breadth.
The prioritization is not static. Run the AlertInfo query monthly. As your defenses improve and certain techniques are reliably blocked, the top-10 list shifts — new techniques appear because the attacker adapts, or previously undetected techniques become visible as your telemetry improves. The maturity model from Section 0.9 captures this: Level 2 covers the top 5 techniques. Level 3 expands to 15. Level 4 covers the full threat-model-relevant set. Each level builds on the detection foundation of the previous level.
Endpoint security configured from a vendor checklist without connecting controls to the OS mechanisms they defend. The engineer enables ASR rules because the checklist says to, not because they understand that the Office child process rule intercepts CreateProcess calls when the parent is an Office binary. When the rule produces a false positive — a legitimate Office add-in that launches a helper process — the engineer disables the rule entirely instead of creating a targeted exclusion for the specific add-in. Understanding the OS internal (process creation) enables targeted troubleshooting. Following the checklist enables only on/off decisions.
Endpoint Security Principle
Every endpoint security control exists because of a specific OS mechanism and a specific attack technique. The three-column mapping — internal → technique → control — transforms configuration from a checklist into engineering. When you know what the control defends at the OS level and what attack it prevents, you can predict blast radius, troubleshoot false positives at root cause, and build detections based on OS behavior rather than tool signatures.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.