ES0.1 Why Traditional AV Fails

The signature problem: why AV stopped working

Antivirus was built to solve a specific problem: known malicious files written to disk. The detection mechanism is straightforward — the AV vendor collects malware samples, generates signatures (byte patterns, file hashes, behavioral fingerprints), distributes those signatures to endpoints, and the local AV engine scans files against the signature database. If the file matches a known signature, it is blocked or quarantined. This model worked when malware was distributed as compiled executables attached to emails or downloaded from websites, and when the number of unique malware samples was measured in thousands per day.

The model breaks when any of its assumptions are violated. Assumption one: the malware is a file on disk. Fileless attacks execute code in memory using legitimate interpreters — PowerShell, WMI, .NET — and never write a standalone executable. There is no file to scan. Assumption two: the malware has a known signature. Polymorphic malware generates a unique binary for every infection. Metamorphic malware rewrites its own code. Server-side polymorphism generates unique payloads per download. The signature database cannot contain a signature for a binary that did not exist when the database was compiled. Assumption three: the malware behaves differently from legitimate software. Living-off-the-land attacks use signed Microsoft binaries (PowerShell, certutil, mshta, regsvr32, rundll32) for the entire attack chain. The “malware” is the operating system itself, used in ways the designers did not intend.

The living-off-the-land revolution

The most significant shift in endpoint attack methodology is not a new exploit or a new malware family — it is the systematic abuse of legitimate operating system tools for the entire attack chain. Living-off-the-land binaries (LOLBins) are signed, trusted Microsoft executables that attackers repurpose for malicious operations. PowerShell downloads and executes payloads. Certutil decodes base64-encoded executables. Mshta executes HTA files from remote URLs. Regsvr32 loads DLLs from remote servers. Rundll32 executes arbitrary DLL exports. BITSAdmin downloads files using the Background Intelligent Transfer Service. Msiexec installs remote MSI packages.

None of these are malware. They are legitimate Windows utilities, signed by Microsoft, present on every Windows installation, and required for normal system administration. The AV cannot block PowerShell — it would break every administrator’s workflow. It cannot block rundll32 — half the operating system depends on it. The detection challenge is not “is this binary malicious?” but “is this legitimate binary being used maliciously?” — and that question requires behavioral analysis that signature-based AV was never designed to perform.

From AV to EPP: adding behavioral analysis

Endpoint Protection Platforms (EPP) extended the AV model with cloud-based lookups, machine learning classifiers, and behavioral heuristics. Instead of relying solely on local signature databases, EPP sends file metadata (and sometimes the file itself) to a cloud service for analysis. The cloud service runs the file through multiple ML models, sandboxes, and reputation engines, returning a verdict in seconds. Microsoft’s Block at First Sight feature exemplifies this: when Defender encounters an unknown file, it sends file metadata to the cloud protection service. If the file has never been seen before, the cloud service can request the full file for detonation and return a block verdict within 10 seconds.

EPP also introduced AMSI — the Antimalware Scan Interface — which provides visibility into script content at the point of execution. Before AMSI, PowerShell scripts that were obfuscated or encoded were invisible to AV until they were decoded and executed. AMSI intercepts the script content after deobfuscation, before execution, giving the AV engine a chance to scan the actual code the interpreter is about to run. This closed the simplest fileless attack vectors: a base64-encoded PowerShell command that downloads Invoke-Mimikatz is now visible to the AV engine through AMSI, even though the encoded command line on disk is not recognisably malicious.

EDR: continuous monitoring of endpoint behavior

Endpoint Detection and Response fundamentally changed the architecture of endpoint security. Instead of making a single block/allow decision at the point of file write or process execution, EDR continuously records endpoint telemetry — every process creation, every network connection, every file write, every registry modification, every DLL load, every logon event — and correlates these events over time to identify behavioral patterns that indicate compromise.

The shift is architectural. AV asks: “Is this file malicious?” EDR asks: “Is this sequence of behaviors malicious?” An attacker who uses PowerShell to enumerate Active Directory, then uses net.exe to map network shares, then uses robocopy to stage sensitive files in a temp directory, then uses certutil to encode the staged files for exfiltration — each individual action is legitimate. PowerShell queries AD every day. Net.exe maps shares for IT operations. Robocopy copies files for backups. Certutil encodes files for email. But the sequence — reconnaissance, followed by mapping, followed by staging, followed by encoding — is the behavioral fingerprint of data exfiltration. EDR detects this because it records and correlates the entire sequence, not just individual file events.

Microsoft Defender for Endpoint records this telemetry into the DeviceEvents family of tables: DeviceProcessEvents (process creation and command lines), DeviceNetworkEvents (network connections and DNS), DeviceFileEvents (file creation, modification, deletion), DeviceRegistryEvents (registry key changes), DeviceLogonEvents (authentication events), and DeviceImageLoadEvents (DLL and driver loads). These tables are queryable through Advanced Hunting using KQL, enabling both automated detection rules and proactive threat hunting.

XDR: cross-workload correlation and why it still requires engineering

Extended Detection and Response extends the EDR model across workloads: endpoint + identity + email + cloud + applications. Microsoft’s Defender XDR correlates signals from MDE (endpoints), MDI (identity/Active Directory), MDO (email), MDA (cloud apps), and Entra ID Protection (identity risk) into unified incidents. An AiTM phishing attack that starts with a malicious email (MDO), captures credentials (Entra ID), establishes a new session from an anomalous location (Entra ID Protection), and then accesses sensitive SharePoint sites from the compromised endpoint (MDE) — XDR correlates all four signals into a single incident, providing the analyst with the complete attack chain instead of four unrelated alerts.

The architectural advantage of XDR is real. Single-workload EDR can see the endpoint activity but cannot see that the same user received a phishing email 10 minutes earlier or that their identity was compromised through an AiTM attack. XDR connects the dots. But the persistent problem remains: XDR correlates what it can see, and what it can see depends on what you have configured. If ASR rules are not enforced, the prevention layer has gaps. If custom detections are not written, the detection layer has gaps. If forensic readiness is not configured (audit policies, Sysmon, PowerShell logging), the telemetry layer has gaps. XDR amplifies the value of a well-configured endpoint security stack and amplifies the consequences of a poorly configured one.

This is the central thesis of this course: the Microsoft security ecosystem provides the architecture for comprehensive endpoint security. But architecture is not protection. Configuration is protection. Tuning is protection. Validation is protection. The gap between “installed” and “engineered” is where attackers live.

Troubleshooting

“We can’t justify the cost of EDR — AV should be enough.” If you have M365 E5, you already have EDR. Defender for Endpoint P2 is included in your existing license. The cost is not additional licensing — it is the engineering time to configure it. This course provides the configuration, the queries, and the deployment methodology. The investment is your time, not your budget.

“Our AV catches everything — we haven’t had a breach.” Survivorship bias. You know about the malware your AV caught. You do not know about the attacks that bypassed your AV and were never detected. Without EDR telemetry, hunting queries, and custom detections, you have no visibility into fileless attacks, living-off-the-land activity, or credential abuse that your AV was never designed to detect. The absence of detected breaches is not evidence of the absence of breaches — it may be evidence of the absence of detection.

“We have a managed SOC — they handle endpoint security.” Your managed SOC triages alerts generated by your endpoint security configuration. If your ASR rules are not in block mode, those alerts were never generated. If your custom detections do not exist, those alerts were never created. If your audit policies are at default, the telemetry your MSSP needs for investigation was never collected. The managed SOC operates ON your configuration — they do not create it for you. This course builds the configuration that makes your managed SOC effective.