Why Traditional AV Fails

The signature model and its three broken assumptions

Antivirus was built to solve a specific problem: known malicious files written to disk. The vendor collects malware samples, generates signatures — byte patterns, file hashes, behavioral fingerprints — distributes those signatures to endpoints, and the local engine scans files against the database. Match a known signature, block or quarantine. This model worked when malware was distributed as compiled executables attached to emails, and when unique malware samples numbered in the thousands per day.

The model breaks when any of three 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. The attacker calls [System.Reflection.Assembly]::Load() with a byte array fetched from a remote server, and the malicious code runs entirely in the memory space of a legitimate process. The AV file scanner has nothing to examine because no file was created.

Assumption two: the malware has a known signature. Polymorphic malware generates a unique binary for every infection. Server-side polymorphism generates unique payloads per download. AV-TEST Institute registers over 450,000 new malware samples per day. Even at 99% detection of known samples within 24 hours of first observation, 4,500 new samples per day go undetected. For targeted attacks that never reach vendor collection infrastructure, the detection gap is substantially wider. The economics have shifted permanently: generating unique variants costs the attacker nothing — automated packers and crypters produce unique binaries in seconds. Writing signatures costs the vendor analyst time and infrastructure. The attacker wins through volume alone.

Assumption three: the malware behaves differently from legitimate software. Living-off-the-land attacks use signed Microsoft binaries for the entire attack chain. 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. None of these are malware. They are legitimate Windows utilities, signed by Microsoft, present on every Windows installation, required for normal system administration. The LOLBAS project catalogues over 200 Windows binaries, scripts, and libraries that attackers abuse in this way.

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 shifts from "is this binary malicious?" to "is this legitimate binary being used maliciously?" That question requires behavioral analysis that signature-based AV was never designed to perform.

Generation 2 — EPP: cloud analysis and AMSI

Endpoint Protection Platforms 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 to a cloud service for analysis. The cloud service runs the file through ML models, sandboxes, and reputation engines, returning a verdict in seconds. Microsoft's Block at First Sight feature is the reference implementation: 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 requests the full file for detonation and returns 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 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. A base64-encoded PowerShell command that downloads Invoke-Mimikatz is now visible through AMSI, even though the encoded command line on disk is not recognizably malicious.

AMSI is not a complete solution. It is a speed bump that forces attackers to invest additional effort. The most common bypass patches amsi.dll in memory, causing the scan function to return a clean result without actually scanning. More sophisticated bypasses use reflection to modify the AMSI scan buffer or disable the AMSI provider entirely. These techniques are well-documented and built into most penetration testing frameworks.

The architectural limitation of EPP remains: it focuses on the prevention decision — block or allow — at the point of execution or file write. It does not continuously monitor what happens after an allowed process starts running. A PowerShell process that passes the AMSI scan at launch but then uses reflection to load a malicious .NET assembly in memory after 30 seconds is invisible to EPP. That visibility gap is what EDR was built to fill.

Generation 3 — EDR: continuous behavioral telemetry

Endpoint Detection and Response changed the architecture of endpoint security fundamentally. 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, file write, registry modification, network connection, DLL load, and 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 — each individual action is legitimate. But the sequence — reconnaissance, mapping, staging, encoding — is the behavioral fingerprint of data exfiltration. EDR detects the chain because it records and correlates the entire sequence, not individual file events.

Defender for Endpoint records this telemetry into the DeviceEvents family of tables: DeviceProcessEvents captures process creation and command lines. DeviceNetworkEvents captures network connections and DNS queries. DeviceFileEvents captures file creation, modification, and deletion. DeviceRegistryEvents captures registry key changes. DeviceLogonEvents captures authentication events. DeviceImageLoadEvents captures DLL and driver loads. These tables are queryable through Advanced Hunting using KQL.

When EDR detects a behavioral pattern, the alert structure reflects the chain — not a single file verdict. The difference between an AV alert and an EDR alert is visible in the alert metadata itself.

{
  "alertId": "da637812345678901234_-12345678",
  "title": "Suspicious process chain: Office → PowerShell → certutil",
  "severity": "High",
  "category": "Execution",
  "detectionSource": "EDR",
  "mitreTechniques": ["T1059.001", "T1105"],
  "evidence": [
    { "entityType": "Process", "fileName": "WINWORD.EXE", "processRole": "ParentProcess" },
    { "entityType": "Process", "fileName": "powershell.exe", "processRole": "CreatedProcess" },
    { "entityType": "Process", "fileName": "certutil.exe", "processRole": "CreatedProcess" },
    { "entityType": "File", "fileName": "payload.bin", "filePath": "C:\\Users\\t.ashworth\\AppData\\Local\\Temp\\" }
  ],
  "investigationState": "PendingApproval",
  "automatedInvestigationId": "42"
}

This is what an EDR behavioral alert looks like in the Defender XDR API. Compare it to an AV alert, which would show a single file with a malware family name. The EDR alert shows the entire process chain — Word as the parent, PowerShell as the child, certutil downloading a payload — with MITRE technique mapping and multiple evidence entities. The detectionSource: "EDR" means this was caught by behavioral analysis, not a signature. The investigationState: "PendingApproval" means AIR has investigated and is waiting for analyst approval to remediate. AV gives you a file name. EDR gives you the attack story.

// LOLBin abuse — signed Microsoft binaries spawning suspicious child processes
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("mshta.exe", "certutil.exe", "regsvr32.exe", "rundll32.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine
| sort by Timestamp desc

This query demonstrates what EDR makes possible that AV cannot: detecting the relationship between parent and child processes. A LOLBin (mshta, certutil, regsvr32, rundll32) spawning a scripting engine (PowerShell, cmd, wscript) is a behavioral pattern that appears in almost every LOTL attack chain. AV sees individual processes. EDR sees the process tree.

MDE's automated investigation and response (AIR) takes EDR further by automatically triaging certain alert types. When AIR identifies a suspicious process chain, it can collect forensic evidence, terminate the process, quarantine the file, and generate a remediation report — all without analyst intervention. At the semi-automated level (the default), AIR investigates and recommends actions that an analyst approves. At the full automation level, AIR investigates and remediates autonomously for approved device groups. The automation level is a tunable dial: organizations start at semi-automated, validate that AIR's remediation actions are accurate over 30–60 days, then promote specific device groups to full automation as confidence builds.

The telemetry retention model matters for investigation. Advanced Hunting retains device event data for 30 days in the standard tier. Sentinel can extend this indefinitely when MDE data connectors stream the same telemetry into a Log Analytics workspace. If an attacker establishes persistence and operates low-and-slow for 45 days, the Advanced Hunting tables will have already aged out the initial compromise data. Sentinel's long-term retention ensures that forensic evidence survives the attacker's patience. This architectural decision — whether to forward MDE telemetry to Sentinel — is one of the first you'll make in the course, and Section 0.5 covers it in detail.

The limitation of EDR is configuration and attention. EDR generates telemetry — it does not automatically prevent all attacks. Custom detection rules must be written to catch organization-specific patterns. Hunting queries must be executed to find threats no automated rule covers. At NE, MDE is onboarded on 780 of 865 endpoints. The sensor collects telemetry. But zero custom detection rules exist, AIR remains at the default semi-automated level for all device groups, and nobody has executed a hunting query in six months. The EDR is running but the capabilities that make it valuable — custom detections, proactive hunting, automated remediation — sit unused.

Generation 4 — XDR: cross-workload correlation

Extended Detection and Response extends EDR across workloads: endpoint + identity + email + cloud applications. Microsoft's Defender XDR correlates signals from MDE (endpoints), MDI (identity and 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, captures credentials, establishes a session from an anomalous location, and accesses sensitive SharePoint sites — XDR correlates all four signals into a single incident instead of four unrelated alerts across four consoles.

The architectural advantage is real. Single-workload EDR sees endpoint activity but cannot see that the same user received a phishing email 10 minutes earlier or that their identity was compromised through credential theft. XDR connects the dots across the kill chain.

At NE, CHAIN-HARVEST demonstrates exactly why this matters. The attack began with an AiTM phishing email (detected by MDO as a medium-severity alert). The stolen credential was used to sign in from an anomalous IP (detected by Entra ID Protection as a medium-risk sign-in). The attacker created inbox rules to hide forwarded email (logged in OfficeActivity, no alert). The attacker accessed the CFO's mailbox repeatedly over 72 hours (logged in CloudAppEvents, no alert). Without XDR, these are four disconnected signals in four consoles — two medium alerts that individually look like noise, and two unalerted log entries that nobody reviews. With XDR properly configured, the phishing email, the anomalous sign-in, the inbox rule creation, and the mailbox access correlate into a single high-severity incident that tells the full story: credential phished → account compromised → persistence established → data accessed. The analyst sees the complete chain in one view and can respond to all four components simultaneously.

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, prevention-layer events never generate. If custom detections don't exist, detection-layer gaps remain open. If forensic readiness isn't configured — audit policies, Sysmon, PowerShell logging — the telemetry XDR needs for correlation was never collected.

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. Every M365 E5 tenant has the license for Gen 4 XDR. Most operate between Gen 1.5 and Gen 2.5 — they have the platform but not the engineering. The delta between your current generation and fully configured XDR is the work this course covers.

# Assess your endpoint security generation — check key MDE settings
$uri = "https://api.securitycenter.microsoft.com/api/machineactions"
$settings = @{
    CloudProtection  = (Get-MpPreference).MAPSReporting       # 0=Disabled, 1=Basic, 2=Advanced
    BlockAtFirstSight = (Get-MpPreference).SubmitSamplesConsent # 3=SendAllSamples (BAFS on)
    CloudBlockLevel  = (Get-MpPreference).CloudBlockLevel       # 0=Default, 2=High, 4=High+, 6=ZeroTolerance
    RealTimeProtection = (Get-MpPreference).DisableRealtimeMonitoring
    TamperProtection = (Get-MpPreference).IsTamperProtected
}
$settings | Format-Table -AutoSize
# Gen 1: CloudProtection=0, defaults everywhere
# Gen 2: CloudProtection=2, BAFS on, CloudBlockLevel ≥2
# Gen 3: Gen 2 + custom detection rules in Advanced Hunting
# Gen 4: Gen 3 + cross-workload Defender XDR correlation active

Run this on any endpoint to determine your current generation. If CloudProtection is 0 or 1 and CloudBlockLevel is 0, you are operating at Gen 1 — signature AV with minimal cloud enhancement. If CloudProtection is 2 with CloudBlockLevel at 4 or higher, you have Gen 2 EPP capability. The jump to Gen 3 requires custom detection rules in Advanced Hunting, and Gen 4 requires active cross-workload correlation in Defender XDR. Most M365 E5 environments have the license for Gen 4 but the configuration for Gen 1.5. The distance between those two numbers is your engineering backlog.