Why Traditional AV Fails

Introduction

Antivirus is on every endpoint in almost every organization, it is working, and organizations with it are breached routinely. Both halves of that are true at once, and the reason is not that the product is bad at its job.

This section is about what that job actually is. Antivirus answers one question about one thing, the question is a good one, and three assumptions sit underneath it. Attackers broke those assumptions in a particular order, and each generation of endpoint security since is an answer to one of them.

The generation you are running is not the generation you licensed. That gap is the single most common finding in this course, it is invisible in every console, and it comes down to a handful of settings that anyone can read in a minute.

You will finish able to name what each generation fixed and what it left, say which one your own estate is operating at, and explain why the third assumption is the one no product will ever close.

Antivirus was built for known malicious files written to disk, and it solved that problem well enough that an entire category of attack stopped being an everyday event. The model is a scanner and a list: a file appears, the engine hashes it or matches a pattern against it, and the verdict is block or allow. That decision is taken once, at the moment the file arrives, and everything downstream depends on it having been right.

The economics were excellent for a long time. One list, distributed widely, running on hardware that could not have supported anything heavier, needing no analyst to operate it and stopping an enormous volume of commodity attacks for almost nothing per endpoint. Every generation since has kept that scanner inside it rather than replacing it, and a vendor describing signatures as legacy is describing a component their own product still ships.

What the model never asks is the interesting part. It does not ask what the file did after it was cleared, what created it, or whether the same action would be suspicious arriving from somewhere else. Those questions have no place in a scanner, because a scanner records nothing: it renders a verdict and moves on, and the verdict is the only thing that survives.

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, and there is no row anywhere that would tell you it behaved at all. That is the shape of the whole limitation: the product answers a question about a file, and the thing you want to know is a question about a sequence.

There is a second cost to the model that is easier to feel than to measure. A verdict is unappealable and it is not evidence: it records that something was blocked, rarely why, and almost never what the file would have gone on to do. When an incident is reconstructed months later the scanner's contribution is a line saying a detection occurred, which tells an investigator that the product was present and almost nothing about the attack. Everything the investigation actually needs, the parent process, the command line, the connection that followed, was never captured because the model had no reason to capture it.

Three assumptions hold the model up, and each one is a claim about the attacker rather than about the product. That the malicious thing is a file. That it is something already known. That it looks different from the software the organization runs on purpose. All three were reasonable in the environment the model was designed for, and all three describe an attacker who brings something with them.

Get-MpThreatDetection | Select-Object -First 3

InitialDetectionTime  2026-03-10 10:35:02
ThreatName            Behavior:Win32/DefenseEvasion.A!ml
Resources             {file:_C:\Users\d.thompson\AppData\...}
ActionSuccess         True
IsActive              False

InitialDetectionTime  2026-03-10 10:35:41
ThreatName            Trojan:Win32/Casdet!rfn
ActionSuccess         False
IsActive              True

Read ActionSuccess on the second record. The scanner named the thing correctly and did not remove it, so the detection exists, the verdict is right, and the file is still running. A count of detections would record two successes here.

Take them in the order the industry answered them, because the answers are the generations. The first is a visibility problem: code that runs from memory without ever touching disk gives a file scanner nothing to scan, and the answer was to watch execution rather than storage. It is the one most people picture when they hear that antivirus is obsolete, and it is the least interesting of the three, because watching execution is a solved engineering problem.

The second is an arms race the defender wins at scale. A binary compiled fresh for each victim defeats a list of hashes by construction, and no local list can ever be long enough. The answer was to stop keeping the list locally and ask a service that sees what is happening across an enormous number of machines, where a binary nobody has ever seen before is itself a usable signal even when known-bad is not available.

The third is different in kind and it is the one worth carrying into every later module. It is not that the product cannot see enough. It is that there is nothing incriminating to see, and no amount of engineering produces a verdict on a file that is not there.

Three questions, three answers that all favor the attacker, and a product returning a correct verdict at the end of it. That row is worth holding onto, because every generation after this one is an attempt to make one of those three questions answerable, and the last of them never becomes answerable at all.

The first two rows are the generations that followed, and both are genuine improvements you should want. The bottom row is the one to carry into every later module, because it is not a gap waiting for a better product. It is a property of the problem.

When an attacker confines themselves to PowerShell, the scripting host, the certificate utility and the remote-access client your administrators use daily, there is no file to convict. Every binary involved ships with Windows, is signed by Microsoft, and is running for a reason somebody in the organization considers legitimate on a hundred other machines that hour.

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 nothing in that list a scanner could act on. Each line is a legitimate Microsoft binary doing something it was built to do, and the only thing marking any of them is what started it and what it did next. Neither of those is a property of the file, so neither is available to a product whose unit of judgment is the file.

Notice how thoroughly this defeats the second assumption too. These binaries are not merely known, they are on the allow list by construction: they ship with the operating system, they carry the signature the product trusts most, and they are on every machine in the estate. There is no reputation to downgrade and no prevalence signal to fire, because prevalence is the argument for trusting them.

The instinct this produces is to block the tools, and it is worth following to where it fails rather than dismissing. Your software deployment runs on PowerShell. So does your patching, your inventory collection, and most of what the service desk does when somebody calls. Certutil is how administrators inspect certificate stores. Removing any of them breaks the people keeping the estate running.

Allow-listing does not rescue it either, and the reasoning returns in the application control module. You can allow a binary by path, by hash or by signature, and all three describe the file rather than its use. powershell.exe allowed by hash is allowed when your patching tool calls it and when a macro calls it: same file, same hash. The thing you want to distinguish is not in the artifact you are permitting.

What is available is the context. A scripting engine started by a word processor is a relationship no business process depends on, and the number of times it occurs in a healthy estate is close to zero. That is a rule you can write, enforce and defend at a change board, and it is the shape of nearly every preventive control in the rest of this course: not a claim about a program, but a claim about a relationship between two of them.

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

That query names no file as malicious, and it is worth reading even if the syntax is unfamiliar, because the shape is the point rather than the language. It describes two ordinary programs and one relationship between them, which is a question the scanner model cannot express. Everything from here is about what has to be recorded before such a question has an answer.

Endpoint Protection Platforms kept the scanner and moved the hard part off the device. Instead of consulting a local list, the engine asks a cloud service that sees what is happening across an enormous number of endpoints and can classify something nobody has seen before. That answers the polymorphism assumption directly: a unique binary is still unusual, and unusual is a usable signal when known-bad is not available.

It is worth being precise about what this fixed and what it did not. 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. It also introduced a dependency the original model did not have, because a device that cannot reach the service degrades to a local scanner silently, and segmented networks are exactly where that happens.

Silently is the operative word. The device does not report an error, the console does not flag it, and the endpoint carries on scanning against whatever definitions it last received, which for a machine on an isolated network can be considerably older than anybody assumes. The failure is indistinguishable from success in every view except a direct reading on the device itself, which is a pattern you will see three more times before this section ends.

The Antimalware Scan Interface is the more interesting half of that generation and the one most often written off. It presents a script to the scanning engine after deobfuscation, at the moment the script is about to run, because whatever encoding or string mangling the attacker used has already been undone by the interpreter in order to execute it. That is a structural advantage rather than a clever trick, and it cannot be engineered away without giving up execution.

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 objection is that an attacker running code in a process can disable the interface inside that process, and published techniques for doing so are widely available. That is true and it is why the interface is often left out of a threat model entirely. It is also the wrong conclusion, because tampering with the interface is an unusual thing to do to a process and is visible to the generation that records behavior. A control that can be bypassed still costs the attacker something, and the bypass is frequently louder than the thing it was hiding.

Whether any of this is operating at all comes down to three settings, and they are the fastest reading you can take of an estate.

The reason they are worth reading rather than assuming is that each one is a decision somebody made, usually years ago, for a reason that was sound at the time. Cloud-delivered protection was switched off on estates where every lookup crossed a metered link. Automatic sample submission was switched off after somebody in legal asked what leaves the organization and got an answer nobody wanted to sign. Neither of those concerns holds the way it did, and neither decision has been revisited, because nothing ever prompts a review of a setting that is not generating errors.

The three are also not independent, which is what makes reading them one at a time misleading. Block at first sight is the feature that holds a never-seen file back until a verdict returns, so it needs the lookup to be permitted and it needs a sample to have been sent. Read on its own it reports enabled on an estate where it can never once have fired.

The portal states intent. The device states what is in force, and the two disagree more often than anybody expects, which is why the reading that settles it is taken on an endpoint.

PS C:\> Get-MpPreference | Select-Object MAPSReporting,
            SubmitSamplesConsent, DisableBlockAtFirstSeen

MAPSReporting           : 0
SubmitSamplesConsent    : 2
DisableBlockAtFirstSeen : True

Every one of those three is off. MAPSReporting at 0 means the cloud is never consulted, SubmitSamplesConsent at 2 means nothing is ever sent for it to judge, and DisableBlockAtFirstSeen is a double negative where True means the feature is off. This estate holds a generation two license and is running generation one, and nothing in any console says so, because every one of these was a deliberate setting made years ago by somebody solving a bandwidth or privacy concern that has since stopped applying.

Endpoint Detection and Response changed the architecture rather than improving the verdict. Instead of deciding about a file at one moment, the sensor records continuously what happens: processes created, network connections made, files written, registry keys changed, users logged on. The verdict becomes something reachable afterwards, from a sequence, rather than something the product has to get right in the instant.

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, which is why those five tables carry every query in this course. The change is clearest in what it costs to answer one. Under the scanner model, "did this machine run that tool last Tuesday" has no answer at all: nothing recorded it and the file may have been deleted the same afternoon. Under the recording model it is a query, asked of the whole estate at once.

That difference is what separates investigating from guessing, and it is the assumption every later module in this course rests on. It also changes what a detection is. A rule can now describe a relationship, 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. Writing those rules is engineering work that belongs to your organization rather than to your vendor, because the relationships worth alerting on are the ones that are abnormal in your estate specifically.

The limitation of this generation is not technical, and it is the one this course returns to most often. Recording everything produces nothing on its own. An estate can have the sensor on every endpoint, telemetry flowing, retention configured, and not one custom detection written against any of it. The product works exactly as designed, the organization is no better defended, and the console is green throughout, because coverage is the number that gets reported and coverage is satisfied the moment the sensor is installed.

There is a second cost and it quietly reverses the first. Behavioral detection produces far more to look at than a scanner does, and an organization that cannot triage what it generates tunes it down until it is quiet again. That returns the estate to generation one by a slower route, having spent the license, and its reports look better the whole way. Both costs land on people rather than on products, which is exactly why neither of them appears in a health report.

Classify it before deciding what to do about it. An estate reported as protected and running a generation older than its license is a finding for whoever owns the baseline, and it is not an incident, and those two go to different people with different urgency.

Extended detection joins endpoint telemetry to identity, email and cloud application signals, so a sequence spanning several of them reads as one incident rather than four unrelated alerts in four consoles. That is a real advance, and it is the shape of the chain in the next section, where a phishing email, a process on a laptop and a sign-in from a new device are three views of one operator.

Its dependency is rarely stated when the capability is sold. Correlation works across the workloads that are connected, so an organization that onboarded endpoints but not email, or both but not its identity provider, gets correlation across the part it connected and silence about the rest. The product reports healthy either way, because a workload nobody connected raises no error.

Be concrete about what correlation joins. The signals are tied by shared entities: one account in a sign-in log and on a process event, one device in an email detonation result and a network connection, one hash arriving by mail and executing an hour later. A workload that is not connected does not weaken the join, it removes an entity from it, so the incident that would have been assembled is instead two smaller ones nobody has a reason to open together.

At Northgate that shows up as an incident on a laptop and a separate sign-in alert on the account using it, in the same console, correlated by nothing, triaged by two people on different days. Neither is wrong and neither is the incident. Whether they get joined is a question about which workloads were onboarded eighteen months ago, and the answer is not visible from either alert.

Entitlement and connection are separate facts. An organization can hold every license the correlation needs and still be joining two workloads out of five, and the bill is identical either way.

That is the same failure shape as the three settings and the missing detections, one layer higher. Each generation closed a real gap, each depends on something an organization does rather than buys, and each reports success whether or not it was done. This is why the course spends more time on measuring and defending decisions than on turning things on.

Which is why the generations are a mental model rather than a history lesson. Nobody operates one of them. A real estate runs a scanner that works, a cloud lookup that may or may not be on, telemetry that may or may not have anything written against it, and correlation across whichever workloads happened to get connected. The useful question is never which generation the product belongs to; it is which of those four is true here, this week.

Which is why the reading in the next paragraph is worth more than any diagram in this section.

The next section takes a real attack chain, eight phases over twenty-four minutes, and walks it past each of these generations in turn, naming where each one would have stopped it and where it would not.