The Attacker Perspective

Introduction

An operator who lands on one of your endpoints spends their first minutes finding out what you have, because the answer decides whether their normal tooling will work or whether this is going to be expensive.

This section is that assessment from the other side, and the reason it belongs in a foundations module is that everything they read is something you can read first. The commands are unremarkable, the answers are the same readings you have been taking throughout this module, and the gap between what they learn in a minute and what most organizations can establish in a week is the finding.

You will finish able to run their assessment against your own estate, say what each control actually removes from their path rather than what it is called, and recognize the point in an intrusion at which blinding you becomes the objective.

Discovering what security software is present is a named technique in the ATT&CK catalog and it is the least sophisticated thing an operator does. It needs no exploit, no elevated rights in most cases, and no tooling beyond what is already on the machine, because the state of your defenses is exposed through the same interfaces your own administrators use.

PS C:\> whoami /groups | Select-String "S-1-5-32-544"

PS C:\> Get-MpComputerStatus | Select-Object AMRunningMode
AMRunningMode
-------------
Normal

Note what the first command returned, which is nothing: this session is not administrative. The second still answered, because the antivirus state is readable without elevation, which is the property that makes the whole assessment cheap for them and impossible for you to remove.

The reason it comes first is economics rather than caution. Tradecraft that works against an unhardened estate is cheap, reusable and already written. Tradecraft that works against a hardened one has to be developed, tested and burned, and every technique used against a defended target risks being detected and therefore losing value everywhere else. Finding out which situation they are in is worth more than any other minute they will spend.

What that means for you is that your posture is not a secret and cannot be made one. The question is never whether an operator can determine your configuration; it is whether the answer they get makes their next step cheap or expensive, and that is a configuration decision rather than an obscurity one.

The last row is the whole reframing this section offers. Every other section of this module has treated configuration as a defensive measure; this one treats it as the reply to a question that will definitely be asked, by somebody who will act differently depending on what it says.

It also explains a pattern defenders find puzzling, which is why some intrusions look sophisticated and others look lazy against the same adversary. The sophistication is usually a response to the target rather than a property of the actor. An operator with capable tooling will still use the cheapest thing that works, because the expensive tooling has a limited number of uses before it stops working anywhere, and spending it on an estate that did not require it is a waste they can measure.

Which turns the usual argument about attacker skill on its head. You cannot make yourself uninteresting, and you can make yourself the version of your industry that costs more than the next one, and that comparison is being made explicitly rather than as a metaphor.

None of which is an argument for obscurity, and it is worth closing that door before somebody walks through it. Hiding your configuration is not available: the readings below are how the operating system reports its own state to any process with normal rights, and they have to be, because your own management tooling depends on the same interfaces. The answer is to change what the reading says, not to hide it.

Run these on a machine you own. Every one appears earlier in this module as a health check, and the point of repeating them here is that the output is identical whoever is reading it and only the conclusion differs.

PS C:\> Get-MpComputerStatus | Select-Object AMRunningMode,
            RealTimeProtectionEnabled, IsTamperProtected

AMRunningMode             : Normal
RealTimeProtectionEnabled : True
IsTamperProtected         : False

PS C:\> (Get-MpPreference).AttackSurfaceReductionRules_Actions

PS C:\> (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace `
            root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

PS C:\> (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
            -Name RunAsPPL -EA SilentlyContinue).RunAsPPL

PS C:\>

Three of those four returned nothing, and empty is an answer rather than an error. No attack surface reduction actions means no rules configured at all, not rules set to disabled. No running security services means credential isolation is not up. No value for the protected-process flag means the security subsystem is readable by anything with sufficient rights.

The fourth is the one that reads as fine and is not. Tamper protection false means every setting above it can be changed by something running with enough privilege, so the healthy values in the first two lines describe a state that an operator can simply alter. A machine with good settings and no tamper protection is a machine whose settings are a suggestion.

Take the same four readings across a sample rather than one device. What an operator finds is whatever the machine they landed on says, and the machines they land on are not the ones your security team uses, which is the same sampling argument as ES0.6 arriving from the other side.

One more property of these readings is worth noticing, because it is the reason to take them yourself rather than trusting a report. They describe the device and not the policy, so they are immune to every failure mode this module has catalogued: a policy that did not reach the machine, a setting overwritten locally, an assignment gap, a device that stopped reporting. Whatever else is true, the four answers above are what an operator will actually find, which makes them the most trustworthy figures in this entire course.

None of them requires elevation except the last, and the last is readable in most configurations anyway. That asymmetry is worth sitting with: the assessment that takes you a scripted collection across a fleet takes them one machine and a few seconds, because they only need to know about the machine they are on.

The four answers do not sum to a score. Each one removes or permits a specific step, so the useful way to read them is as a set of doors rather than as a posture rating.

Credential isolation running changes the value of the credential phase rather than its difficulty: the dump may still succeed and return material that cannot be used. The protected-process flag changes the difficulty rather than the value, because the read itself is refused and getting past it requires kernel access. Attack surface reduction rules in block remove specific relationships, so the technique has to change rather than the tooling. And tamper protection decides whether any of the other three can simply be switched off first.

Read the order rather than the four boxes. Tamper protection is drawn first because a control that can be turned off before it is faced is not a control, and that is why an estate improving its posture should enable it before, not after, the things it protects.

The four gates, as an operator scores them, on two estates

  GATE              NORTHGATE        A HARDENED ESTATE
  tamper protection   off              on, UEFI-locked
    -> the others are   settings         obstacles

  ASR in block        0 of 18          14 of 18
    -> technique        unchanged        must change route

  RunAsPPL            unset            1, firmware-locked
    -> access           granted          refused in user mode

  credential isolation not running     running
    -> the prize        usable           returns nothing usable

  verdict             default tooling  bespoke work at every
                      throughout       phase, all of it noisy

Read the right-hand column as a cost rather than a posture. Nothing in it makes the estate impossible to compromise, and every row turns a step that was free into a step that has to be designed, tested and spent. The difference between the two columns is four configuration decisions.

There is a fifth reading that does not fit on the diagram and belongs in the same assessment, which is what else is installed. An estate running a third-party security product alongside Defender is a more complicated target in one sense and a simpler one in another, and the next two sections are about which. What an operator learns from a second product is not that the estate is better defended; it is which engine is actually in charge, and that answer frequently surprises the organization more than it surprises them.

Read the gates as a sequence when you plan work as well. Enabling credential isolation on an estate with no tamper protection buys the most expensive gate on the diagram and leaves the switch that disables it exposed, which is a common ordering and produces a posture that reads well and holds badly.

The response to hardened endpoint security has been consistent and it is worth understanding because it tells you which of your controls are actually load-bearing. As security products hardened their own services and gated their disable paths behind tamper protection, the reliable way to switch them off stopped being available in user mode.

// Driver loads that are not part of your build
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "DriverLoad"
| summarize Devices = dcount(DeviceName), First = min(Timestamp)
            by InitiatingProcessFileName, FolderPath
| where Devices <= 2
| sort by First desc

Filter to the rare ones rather than the common ones. A driver present on two devices out of 865 is either a genuinely unusual piece of hardware or the thing this section is about, and both answers are worth a minute.

So the technique moved below it. Loading a legitimately signed driver that contains a vulnerability, and using it to reach kernel level, has become the dominant route for tooling built to blind endpoint security before the noisy part of an intrusion. The drivers involved are genuine, signed software, frequently old, and in several documented cases carrying certificates that have been revoked and remain loadable. Reporting through 2025 and 2026 describes them appearing inside ransomware toolkits as a standard component rather than as bespoke work.

Two consequences follow for a defender and neither is about the technique itself. The first is that signature and reputation have no purchase here, for the same reason they had none in ES0.1: the driver is legitimate software with a real signature, and what is wrong is the use rather than the file. The second is that this is a post-compromise step, so it sits after everything earlier in this module and is prevented most cheaply by the controls that stop the operator arriving with the rights to load a driver at all.

That second consequence deserves emphasis because it is where the effort belongs. Loading a driver needs administrative rights on the host, so every control earlier in this module that keeps an operator at user level, or stops them obtaining a credential granting administrative rights elsewhere, prevents this without engaging with it at all. LAPS is a defense against kernel-level tooling in the same way it is a defense against everything else, by removing the credential that makes the next machine reachable.

The blocklist half is a moving target rather than a solved problem, and it is worth planning for that rather than being surprised by it. Public reporting through 2026 describes attackers rotating toward less well-known signed drivers as blocklists mature, particularly from consumer software with long update tails, so a blocklist that is enforcing and current is a maintained control rather than a switch you flip once.

That last line is the next section, and it is the part most estates get wrong without knowing.

The control aimed directly at this is one of the three standard protection rules from ES0.3: blocking abuse of exploited vulnerable signed drivers, 56a863a9-875e-4185-98a7-b882c64b5ce5. It is in the set Microsoft says can go to block without an audit cycle, so it is among the cheapest changes available to you.

It also has a dependency that is easy to miss and that no console surfaces beside the rule. Attack surface reduction rules are delivered through Defender Antivirus and enforce only where that engine is in its active running mode. On a device where a third-party product holds the active antivirus role and Defender is running in passive or endpoint-detection-only mode, the rule is configured, appears in every policy export, and blocks nothing at all.

PS C:\> Get-MpComputerStatus | Select-Object AMRunningMode

AMRunningMode
-------------
Passive

PS C:\> $p = Get-MpPreference
PS C:\> $i = [array]::IndexOf($p.AttackSurfaceReductionRules_Ids,
            "56a863a9-875e-4185-98a7-b882c64b5ce5")
PS C:\> $p.AttackSurfaceReductionRules_Actions[$i]

1

Read those two answers together and the finding is obvious in a way it never is in a report. The rule reads 1, which is block, so every compliance view of this device says the driver rule is enforcing. The engine is passive, so it is not. Neither reading is wrong and neither alone is sufficient, which is the pattern this whole module keeps returning to.

Where this bites hardest is on servers, because a third-party antivirus product is far more common there than on workstations, and servers are also where an operator most wants kernel access. An estate that promoted this rule fleet-wide and never checked the running mode has a coverage claim that is correct for its laptops and false for the machines that matter most.

The general form of this recurs well beyond one rule. Every control has a dependency, most dependencies are invisible next to the control, and the failure is always the same shape: the thing reads as configured and the thing it needs is not there. Cloud protection needs reachability. Block at first sight needs sample submission. Attack surface reduction needs the engine active. None of those appears as a warning beside the setting.

So the useful habit is to ask, for every control you are about to claim coverage on, what has to be true for it to act. That question has an answer for each one, it is usually a single reading, and asking it is what separates a coverage figure from a claim.

Check the mode before the rule rather than after, because the order determines whether the answer means anything. A rule state read on a device whose engine is passive is a fact about a policy and not about protection, and reporting it as coverage is how an estate ends up defending a number it cannot support.

An operator disabling security tooling is not doing housekeeping. It happens immediately before the actions that are loud, which is credential theft at scale, mass file access, exfiltration or encryption, so treating it as a milestone rather than as a configuration fault changes how fast the response has to be.

That gives you a detection surface with an unusual property: the thing you are looking for is the absence or alteration of your own telemetry, which is exactly what nothing alerts on by default. Silence is not an event, so the query has to ask about it deliberately.

// Security tooling interference: state changes and sudden silence
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType in ("AntivirusDisabled",
        "TamperingAttempt", "DriverLoad")
| summarize Events = count(), Last = max(Timestamp)
            by DeviceName, ActionType
| sort by Last desc

Pair that with the quiet-device query from ES0.5, because the two answer different halves of the same question. One finds a device where something acted on the protection; the other finds a device that stopped talking, which is what a successful attempt looks like from the service side. A machine appearing in both within the same hour is the pattern worth waking somebody for.

Microsoft-Windows-Windows Defender/Operational

  5001   real-time protection disabled
  5007   configuration changed, including an exclusion added
  5010   antivirus scanning disabled
  1116   a threat was detected
  1117   the threat was remediated

The pattern that matters is 1116 with no 1117 after it,
or 5001 and 5010 with no change record anywhere.

The last two lines are the reading. A detection with no remediation after it is the state ES0.2 walked through, where the product saw the payload and did not stop it. And protection being switched off with no corresponding change ticket is the one that should route straight to an incident, because the legitimate version of that event always has a change record behind it and the other version never does.

Reconciling against change records is what makes all three readable, and it is the same reconciliation ES0.8 asked for against the exclusion register. The events are ambiguous by design, because an administrator disabling protection to install software and an operator disabling it to avoid detection produce identical telemetry. What separates them sits entirely outside the endpoint, in whether anybody wrote down that they were going to do it.

That is worth arguing for as a control in its own right. An organization where every legitimate protection change has a record is one where the events above are actionable without investigation; an organization where changes happen informally has the same telemetry and cannot use it, and no amount of detection engineering fixes that.

None of this makes an estate impossible to compromise and it is worth saying so plainly, because a defense argued as prevention collapses the first time something gets through. What it does is change what the intrusion costs, and the currency is not money.

It costs them time, which is the interval in which your detection layer has a chance to matter. It costs them technique, because tooling that works everywhere has to be replaced with something built for you, and bespoke tooling is used less often and studied more. And it costs them exposure, because every step taken to get around a control is a step that generates something, and a technique burned against a defended target loses its value against every other target too.

The honest framing for a review is that you are not trying to be impregnable, you are trying not to be the cheap option, and the four readings at the start of this section are how anybody establishes which you are in under a minute.

One caution about how that argument lands. Framed as deterrence it invites the reply that a determined adversary gets in anyway, which is true and is not the claim. The claim is narrower and more defensible: an intrusion that takes longer and requires adaptation has more opportunities to be caught and a smaller blast radius when it is, and both of those are measurable rather than hoped for.

It also has a consequence for how you spend. Controls that force adaptation are worth more than controls that add a step, and the difference is whether the operator has to change what they do or merely repeat it. That is ES0.3's layers expressed as cost rather than coverage, and it is usually the more persuasive framing in a room that has already heard the coverage argument.

The next section is the module's hands-on assessment, where the readings from all ten sections are taken against one estate and turned into a single position you can defend.