ES1.9 What Attackers Actually Target

· Module 1 · Free

Operational Objective

This module has covered OS internals across Windows, Linux, and macOS. The final synthesis connects each internal component to the specific MITRE ATT&CK technique that abuses it, the defensive control that protects it, and the detection opportunity it creates. This three-column mapping — internal → technique → defense — is the mental model that transforms OS knowledge into endpoint security engineering decisions. Every configuration choice you make in Modules ES2 through ES15 originates from this mapping.

Deliverable: A complete mapping of OS internals to ATT&CK techniques to defensive controls, structured as the engineering reference you will use throughout this course.

Estimated completion: 20 minutes

Figure ES1.9 — The three-column mapping that connects 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 and the attack technique it prevents.

Building the mental model

The mapping above is not a reference table to memorize. It is a decision framework. When you encounter an endpoint security configuration decision — “should I enable this ASR rule?” “should I deploy Credential Guard?” “should I configure this Sysmon event ID?” — the three-column model answers the question by connecting the control to the attack it prevents and the OS mechanism it protects.

Example 1: Should I enable the LSASS ASR rule? The OS internal: LSASS stores credential material in process memory. 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.

Example 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. 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 event ID provides the primary detection signal for process injection, which is used by most post-exploitation frameworks.

Example 3: Should I configure Linux kernel module loading restriction? The OS internal: Linux allows kernel modules to be loaded at runtime via insmod/modprobe. The attack: rootkit installation (T1547.006) loads a kernel module that hides attacker activity. The control: setting kernel.modules_disabled=1 in sysctl prevents any new module loading after boot. Decision: on production servers that do not need to load new modules at runtime — yes. On development systems where module loading is part of the workflow — monitor module loading events instead of blocking.

Decision Point

You have limited time and must choose between deploying two controls: (A) Sysmon Event ID 10 (ProcessAccess) to detect LSASS access patterns, or (B) the LSASS ASR rule in block mode to prevent LSASS access entirely. Which provides more value? The ASR rule (option B). Prevention eliminates the attack entirely — no credential dump occurs, no detection alert is needed, no investigation is triggered, no containment is required. Sysmon Event ID 10 detects the attack after it begins — the credential dump may complete before anyone reviews the alert. Deploy the ASR rule first. Deploy Sysmon Event ID 10 second as the detection layer for attacks that bypass the ASR rule (which is a small category — mostly custom tools signed with stolen certificates).

Try it: map your environment's top 5 attack techniques to controls

Using MITRE ATT&CK Navigator or your organisation’s threat intelligence, identify the 5 ATT&CK techniques most relevant to your environment (based on your industry, your threat model, or your recent incidents). For each technique:

Identify the OS internal: What OS mechanism does this technique abuse? (e.g., T1003.001 → LSASS credential storage)
Identify the defensive control: What endpoint security control prevents or detects this technique? (e.g., ASR LSASS rule, Credential Guard, Sysmon Event ID 10)
Assess your current state: Is the control deployed? In what mode? (audit, block, not configured)
Identify the gap: If the control is not deployed, what is the engineering effort to deploy it? Which module in this course covers it?

This exercise produces a prioritized deployment list based on YOUR threat model — not a generic best-practice list.

Mapping OS internals to ATT&CK: the mental model

Every OS component covered in this module maps to specific MITRE ATT&CK techniques. This mapping is the mental model that connects understanding (how the OS works) to action (what to detect and defend):

Process model (ES1.1) → T1055 Process Injection, T1134 Access Token Manipulation. Understanding processes, threads, handles, and tokens reveals how attackers inject code into legitimate processes and manipulate token privileges for escalation. The detection: anomalous process handle operations (Sysmon Event ID 10), unexpected token privilege assignment (Security Event ID 4672).

LSASS (ES1.2) → T1003 OS Credential Dumping. Understanding LSASS’s role as the credential cache reveals why every credential dumping technique targets this single process. The defense: Credential Guard (isolates the cache), RunAsPPL (prevents non-protected processes from accessing LSASS), ASR LSASS protection rule (blocks known access patterns), custom detections NE-CRED-001 through 005 (catches the access regardless of the tool).

Registry (ES1.3) → T1547 Boot/Logon Autostart Execution, T1546 Event Triggered Execution. Understanding registry run keys, COM objects, and IFEO reveals the persistence mechanisms that attackers deploy. The detection: DeviceRegistryEvents for run key modifications, Sysmon Event ID 13 for registry value set operations with process context.

ETW (ES1.4) → T1562 Impair Defenses: Disable or Modify Tools. Understanding ETW providers and their role in EDR telemetry reveals why attackers target ETW — patching a provider blinds the EDR to specific event categories. The defense: Sysmon as an independent telemetry channel, anomaly detection for telemetry gaps.

Security subsystem (ES1.5) → T1558 Steal or Forge Kerberos Tickets, T1550 Use Alternate Authentication Material. Understanding the Kerberos authentication flow reveals where golden ticket, silver ticket, and pass-the-hash attacks intercept the chain. The detection: MDI for Kerberos anomalies, custom detections for DCSync (NE-CRED-004).

Linux kernel (ES1.6) → T1611 Escape to Host (container escape), T1014 Rootkit. Understanding namespaces, cgroups, and kernel modules reveals the container escape and rootkit techniques that target Linux infrastructure. The defense: eBPF-based runtime monitoring, Sysmon for Linux, kernel module integrity verification.

macOS TCC/SIP (ES1.8) → T1548 Abuse Elevation Control Mechanism, T1553 Subvert Trust Controls. Understanding TCC and SIP reveals the permission boundaries that constrain macOS attackers and the bypass techniques that circumvent them. The defense: Intune-managed TCC permissions, Gatekeeper enforcement, MDE for macOS monitoring.

This mapping transfers directly to the detection rules in ES8 and the hunting queries in ES9. When building a detection for a specific technique, reference the OS internal from this module to understand WHERE the telemetry originates and WHY the detection pattern works.

Compliance Myth: "We don't need to understand OS internals — we just need to follow the vendor's recommended configuration"

The myth: Microsoft publishes security baselines and recommended configurations. Follow them and your endpoints are protected. Understanding the underlying OS mechanisms is unnecessary.

The reality: Vendor baselines are a starting point, not a destination. The Microsoft security baseline for MDE does not enable all ASR rules in block mode — it leaves several in audit because the blast radius varies by environment. The baseline does not include custom detection rules — those must be written for your environment. The baseline does not configure Sysmon — it is a third-party tool. Understanding OS internals tells you which baseline settings matter most for YOUR threat model, which additional controls to deploy beyond the baseline, and how to troubleshoot when a baseline setting causes unexpected behavior. The engineer who understands that the LSASS ASR rule blocks handle acquisition to a specific process can troubleshoot a false positive. The engineer who just enabled the baseline setting cannot.

Cross-platform attack patterns: the same techniques, different implementations

Attackers targeting multi-platform environments (like NE with Windows, Linux, and macOS) use the same tactical patterns across all operating systems — the techniques differ but the objectives are identical:

Credential access. On Windows: Mimikatz dumps LSASS memory. On Linux: reading /etc/shadow for password hashes, or extracting SSH private keys from ~/.ssh/. On macOS: accessing the Keychain database or dumping credentials from memory. The same ATT&CK tactic (Credential Access) applies to all three — the detection must monitor the platform-specific credential stores.

Persistence. On Windows: registry run keys, scheduled tasks, WMI subscriptions. On Linux: cron jobs, systemd services, .bashrc modifications. On macOS: launch agents, login items, dylib hijacking. Each platform has its own persistence mechanisms, but the detection pattern is the same: monitor for new entries in persistence-capable locations created by unexpected processes.

Defence evasion. On Windows: ETW patching, AMSI bypass, process injection. On Linux: LD_PRELOAD hijacking, kernel module loading, /proc manipulation. On macOS: TCC bypass, Gatekeeper circumvention, code signing abuse. Each platform’s security architecture creates different evasion targets — understanding the platform-specific architecture (this module) reveals the platform-specific evasion techniques.

Lateral movement. On Windows: PsExec, WMI, RDP, SMB. On Linux: SSH (the primary lateral movement mechanism — monitor auth.log for unexpected SSH sessions). On macOS: SSH, Apple Remote Desktop (ARD), screen sharing. Cross-platform lateral movement is common: an attacker compromises a Windows endpoint, dumps SSH keys, and uses those keys to access Linux servers. The detection requires cross-platform hunting queries (ES13.9) that correlate Windows credential access events with subsequent Linux SSH authentication events.

The OS internals from this module explain WHY each technique works on each platform. The detection engineering from ES8 and hunting from ES9 build the specific detection rules and queries for each.

Troubleshooting

“The mapping has dozens of techniques — we can’t address them all.” You do not need to. Prioritize based on your threat model. 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 5 techniques cover the core of most attack chains. The controls that address them (LSASS ASR rule, registry monitoring, AMSI, process injection detection, lateral movement detection) provide the highest return on engineering investment. Expand coverage after these 5 are addressed.

“Do we need separate detection rules for each platform, or can one rule cover Windows and Linux?” MDE’s Advanced Hunting tables (DeviceProcessEvents, DeviceNetworkEvents) contain data from all platforms in the same table. A KQL query that filters by FileName and ProcessCommandLine works across platforms — but the specific file names, paths, and command-line patterns differ. A rule detecting suspicious process execution from /tmp/ catches Linux threats but never fires on Windows (which uses C:\Users...\Temp). Cross-platform detection requires platform-aware queries: the detection logic is the same (unexpected process from a temp directory) but the field values differ per OS. ES13.9 covers cross-platform hunting in detail.

Operational Artifact — OS Internals → ATT&CK → Control Mapping Reference

This mapping is the master reference for endpoint security engineering decisions. For each OS internal covered in this module, the reference provides: the MITRE ATT&CK technique(s) that exploit it, the prevention control (ASR rule, Credential Guard, WDAC, etc.), the detection control (Sysmon event ID, MDE table, custom detection KQL), and the course module that covers configuration. Use this reference when prioritizing your deployment sequence (ES0.7), when writing custom detection rules (ES8), and when validating your endpoint security architecture (ES15 capstone). The reference is not static — update it as new techniques emerge and new controls become available.

You are prioritizing endpoint security controls for NE. Your threat intelligence indicates the highest-likelihood attack chain is: phishing → macro execution → PowerShell download cradle → LSASS credential dump → lateral movement via PsExec. Which THREE controls, deployed in sequence, interrupt the most phases of this chain?

Sysmon deployment → PowerShell ScriptBlock logging → KAPE pre-staging. These are forensic readiness controls that improve investigation but do not prevent any phase of the attack chain.

ASR "Block Office from creating child processes" (interrupts macro→PowerShell), ASR "Block credential stealing from LSASS" (interrupts credential dump), ASR "Block process creations from PSExec and WMI" (interrupts lateral movement). Three ASR rules address three distinct phases: execution (macro→PowerShell), credential access (LSASS dump), and lateral movement (PsExec). If the first rule blocks the macro→PowerShell chain, the entire attack stops at phase 2. If it is bypassed, the second rule stops credential access at phase 4. If both are bypassed, the third rule stops lateral movement at phase 6. Each rule provides an independent interception point — the attacker must bypass ALL THREE to complete the chain.

Credential Guard → LAPS → device isolation playbook. These controls are valuable but address only the credential access and lateral movement phases. They do not interrupt the initial execution phase (macro→PowerShell), allowing the attacker to establish persistence before the credential controls take effect.

Cloud protection High+ → custom detection for PowerShell download cradles → Sentinel integration. These improve detection but do not prevent the attack. Cloud protection may catch the downloaded payload, but if it does not, the remaining controls only detect — they do not prevent — the subsequent phases.

You're reading the free modules of this course

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus

← Previous Next →