Why Traditional AV Fails

Introduction

Every organization in this course's audience already runs antivirus, on every endpoint, reporting healthy. Breaches happen anyway, and not because the product failed at what it does.

This section explains what antivirus was built to solve, the three assumptions that made it work, and the order in which attackers broke them. Each generation that followed closed one of those gaps and left another open.

By the end you will be able to say which generation your own estate is actually running, which is a different question from which products it has licensed.

Antivirus was designed for one thing: known malicious files written to disk. It does that job well, and the job stopped being the whole problem some time ago.

It is worth stating plainly rather than dismissively, because everything built since has kept it. The model is a scanner and a list. A file appears, the engine hashes it or matches it against a pattern, and the verdict is block or allow. That decision is made once, at the moment the file arrives, and everything downstream depends on it being right.

It ran on hardware that could not have supported anything heavier, and it needed no analyst.

A scanner is also cheap to run, which is why it survives inside every later generation rather than being replaced by one.

The economics were good for a long time. One list, distributed widely, stopping a very large volume of commodity attacks for almost no effort per endpoint.

Notice what the model never asks. It does not ask what the file did afterwards, what created it, or whether the same action would be suspicious coming from somewhere else. Those questions have no place in a scanner because a scanner is not recording anything.

One verdict, and what it does not carry forward

  scanned    invoice.doc      2026-03-14 09:12   clean
  scanned    setup.exe        2026-03-14 09:31   blocked, Trojan:Win32/...
  scanned    update.ps1       2026-03-14 09:44   clean

Nothing here records what invoice.doc did after it was cleared.

Read the third line. A script cleared at the moment it was scanned is a script the model has no further opinion about, however it behaves ten seconds later.

That is the shape of the whole limitation: the product answers a question about a file, and the thing you actually want to know is a question about a sequence.

That is not a criticism of the design. Solving the known-bad-file problem removed an entire category of attack from the everyday, and every generation since has kept a scanner inside it for exactly that reason.

Keep that in mind when a vendor describes signatures as legacy. The list still stops an enormous volume of commodity attacks and removing it would be a straightforward mistake.

Every generation after this one keeps the scanner and adds to it, which is why none of what follows replaces antivirus.

The gap is that the model rests on three assumptions about what an attack looks like, and an attacker who violates any of them walks past a product that is working perfectly.

Each assumption failed separately, and the industry answered the first two with engineering.

Each is stated as a claim about the attacker rather than about the product, which is the useful way to read them.

All three were reasonable in the environment the model was designed for, and all three describe an attacker who brings something with them.

Take them in that order, because the industry answered them in that order and the answers explain the generations.

The first is a visibility problem. Code that runs from memory without touching disk gives a file scanner nothing to scan, and the answer was to watch execution rather than storage.

It is also the one most people picture when they hear that antivirus is obsolete, and it is the least interesting of the three.

The second is an arms race the defender can win at scale. A unique binary per victim defeats a hash list, and the answer was cloud lookup and machine classification rather than a local list of everything ever seen.

The third is different in kind, and it is the one worth carrying through the rest of this course. When an attacker uses PowerShell, the scripting host, the certificate tool and the remote-access client your administrators use daily, there is no file to convict.

Blocking the tools themselves is the answer people reach for, and it is not available.

Notice that this one has no engineering answer. The first two failed because the product could not see enough; this one fails because there is nothing incriminating to see.

You cannot block PowerShell. You cannot block the scripting host. Blocking either breaks the people who keep the estate running, and an attacker who confines themselves to those tools has removed the file from the equation entirely.

Living off the land, as it appears on the endpoint

  powershell.exe    -enc SQBFAF...        started by winword.exe
  certutil.exe      -urlcache -f http://  started by cmd.exe
  rundll32.exe      javascript:...        started by explorer.exe

Every binary here ships with Windows and is signed by Microsoft.

There is no file in that list a scanner could convict. Each one is a legitimate Microsoft binary doing something it is designed to do, and the only thing that marks it is what started it and what it did next.

That is why generations two, three and four are not better scanners. They change the question from what is this file to what happened here, and the difference between those two questions is the subject of the entire course.

Endpoint Protection Platforms kept the scanner and moved the hard part off the device.

Its answer to the second assumption is genuinely good, its answer to the first is partial, and its silence on the third is total.

This is the generation most estates are actually running, whatever else they have licensed.

Instead of a local list, the engine asks a cloud service, which sees what is happening across a very large number of endpoints and can classify something never seen before. That directly answers the polymorphism problem: a unique binary is still unusual, and unusual is a signal even when known-bad is not available.

The fourth row is the one that bites in practice. A device that cannot reach the service degrades to a local scanner silently, and segmented networks are exactly where that happens.

It is worth being precise about what this fixed. It did not make the endpoint smarter; it made the verdict better informed. The decision is still block or allow, still taken at one moment, and still followed by no record of what happened next.

Defender Portal
  Settings > Endpoints > Advanced features

Three settings decide whether this generation is operating at all:
  Cloud-delivered protection      on, or the lookup never happens
  Automatic sample submission     on, or the cloud has nothing to judge
  Block at first sight            on, and it depends on both of the above

Those are the three names as the portal shows them. The same settings read differently from the device itself, and the device is the reading that decides what is actually in force.

Get-MpPreference | Select-Object MAPSReporting, SubmitSamplesConsent,
    DisableBlockAtFirstSeen

MAPSReporting          : 2
SubmitSamplesConsent   : 1
DisableBlockAtFirstSeen: False

Read this from a device rather than trusting the portal. The last field is a double negative and is the one people misread most often: False means the feature is on.

None of the three is difficult to check and all three are commonly off, usually switched off years ago by somebody solving a bandwidth or privacy concern that no longer applies.

Those three are worth reading on your own tenant before continuing, because an estate with cloud protection disabled is running generation one with a generation two license, and the console reports it as protected either way.

Read them on a device rather than in the policy where you can. A policy states intent; the device states what is in force, and the two disagree more often than anybody expects.

That gap between what is licensed and what is switched on is the single most common finding in this course, and it appears again in every module that follows.

The Antimalware Scan Interface is the more interesting half of that generation and the one most often dismissed as trivially bypassed.

It is worth understanding properly, because the dismissal is based on a true fact and a wrong conclusion.

What it does is narrow and valuable: it presents a script to the scanning engine after deobfuscation, at the moment the script is about to run. Whatever encoding, compression or string mangling the attacker used has already been undone, because the interpreter had to undo it to execute.

The interface sits between the interpreter and the engine, and that position is what makes it useful and what makes it reachable.

Nothing in that list is controversial. The disagreement is entirely about how much the third row matters relative to the fourth.

The third row is what people mean when they call it useless. An attacker who can run code in a process can disable the interface inside that process, and published techniques for doing so are widely available.

It is a fair objection as far as it goes, and it is the reason the interface is often left out of a threat model entirely.

Weigh the two together rather than accepting the first. The fourth row is why that reasoning is wrong. Tampering with the interface is not a quiet act; it is an unusual thing to do to a process, and it is visible to the generation that records behavior rather than deciding on files.

What the engine receives, after the interpreter has decoded it

  submitted    Invoke-Expression (New-Object Net.WebClient).Downloa...
  original     powershell -enc SQBuAHYAbwBrAGUALQBFAHgAcAByAGUAcwBz...

The encoding bought the attacker nothing at this point.

The attacker's obfuscation is undone before the engine sees it, because the interpreter had to undo it in order to run it. That is a structural advantage rather than a clever trick, and it cannot be engineered away without giving up execution.

It is the reason a bypassable control is still worth deploying, provided somebody is watching for the bypass.

Cost imposed on the attacker is a real defensive outcome even when prevention is not achieved, and this course treats it as one throughout.

That pattern repeats throughout endpoint security and is worth naming now: a control that can be bypassed still raises the cost of the attack, and the bypass is frequently more detectable than the thing it was hiding.

Endpoint Detection and Response changed the architecture rather than improving the verdict.

This is the generation the rest of the course is built on.

Instead of deciding about a file at one moment, the sensor records what happens continuously: processes created, network connections made, files written, registry keys changed, users logged on. The verdict becomes something you can reach afterwards, from a sequence, rather than something the product must get right in the instant.

What the sensor writes, per device, continuously

  DeviceProcessEvents      what ran, and what created it
  DeviceNetworkEvents      what it talked to
  DeviceFileEvents         what it wrote
  DeviceRegistryEvents     what it changed
  DeviceLogonEvents        who was there

Nothing in that list is a verdict. Every row is a fact about something that happened, and the judgment is made later by somebody asking a question.

Five tables, recorded continuously, on every onboarded device. The list is worth knowing now because every query in this course reads from it.

The change is best understood through what it costs to answer a question. Under the scanner model, "did this machine run that tool last Tuesday" has no answer, because nothing recorded it and the file may not exist any more.

It is not that the scanner answered it badly. It never held the information, and the file it examined may have been deleted the same afternoon.

Under the recording model the same question is a query, and it can be asked about the whole estate at once rather than one machine at a time. That is the difference between investigating and guessing, and it is why every later module in this course assumes the telemetry exists.

DeviceProcessEvents
| where InitiatingProcessFileName in ("winword.exe","excel.exe")
| where FileName in ("powershell.exe","cmd.exe","wscript.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName

Two ordinary programs and one relationship between them. It is worth reading even if the syntax is unfamiliar, because the shape is the point rather than the language.

That query names no file as malicious. It describes a relationship between two ordinary programs, and it is the kind of question the scanner model has no way to express.

It also changes what a detection is. A rule can now describe a relationship, such as a document opening a scripting host, rather than describing a file, which is the only way to catch an attacker who brought no files with them.

The limitation of this generation is not technical. It is that recording everything produces nothing on its own.

It is an organizational limitation, and it is the one this course returns to most often.

An estate can have the sensor deployed everywhere, telemetry flowing correctly, retention configured, and zero custom detections written against any of it. The product is working exactly as designed and the organization is no better defended than it was, because nobody is asking the data anything.

Every row in that card describes something that was done correctly. The failure is that the project was scoped as a deployment rather than as a capability.

This is the single most common state of a real estate, and it looks identical to success in every report. Coverage is the number people quote, and coverage says only that the sensor is present.

Coverage is the number that gets reported upward, and coverage is satisfied the moment the sensor is installed.

Read the fourth row carefully, because it is why this state persists for years. Nothing in the console distinguishes an estate with two hundred tuned detections from one with none.

Both costs land on people rather than on products, which is why neither shows up in a health report. There is a second cost, which is attention. Behavioral detection produces more to look at than a scanner does, and an organization that cannot triage what it generates will eventually tune it down until it is quiet, which returns it to generation one by a slower route.

An estate that tunes its way back to silence has spent the license and returned to the starting position, and its reports will look better throughout.

The second cost is the one that quietly reverses the first. Both costs are the reason this course spends more time on measuring, tuning and defending decisions than on turning things on.

The last generation widens the boundary rather than changing the mechanism, and its limitation follows directly from that.

Extended Detection and Response widens the recording across identity, email and cloud rather than deepening it on the endpoint.

The endpoint is one signal among several, and this generation is about what the others add.

The value is that an attack appearing as four unremarkable events across four products becomes one incident that somebody actually opens. A sign-in from an unusual location, a mailbox rule created, a file downloaded and a process spawned are each individually forgettable and collectively obvious.

The second row is the precondition and it is rarely fully met. Most estates correlate two or three workloads and describe themselves as running the fourth generation.

The third row is the assumption that survives every generation. Correlation operates on what it can see, and a workload that is not connected does not appear as a gap; it appears as nothing at all.

One intrusion, four workloads, four unremarkable events

  identity   sign-in from an unfamiliar location, MFA satisfied
  email      inbox rule created, forwarding to an external address
  cloud      file downloaded from SharePoint, ordinary volume
  endpoint   scripting host started by a document

Individually forgettable. In sequence, an intrusion.

None of those four would raise an eyebrow on its own, and three of them are not endpoint events at all. Correlation is what turns them into one thing somebody looks at.

Correlation is only as wide as its inputs, and its inputs are a licensing and configuration question rather than a detection one.

That is the honest summary of four generations. Each one closed a real gap, each introduced a dependency, and none of them removed the need for somebody to know what their estate is actually running rather than what it is licensed for.

Every generation here is worth having, each one is commonly half-deployed, and the half that is missing is rarely the half anybody reports on. None of this argues against deploying any of it. It argues for knowing which one you have.

Which is the question the practice below asks you to answer for your own environment before the next section starts building anything.

The next section takes a real attack chain and walks it past each of these generations in turn, naming exactly where each one would have stopped it and where it would not.