The Adversary You Operate Against

Introduction

Everything in this course so far has been about your own estate. This section is about the other side, because the shape of the work follows from what the adversary is actually doing rather than from what the tooling was designed for.

Two figures decide most of it. The large majority of detections now involve no malware at all, and the interval between initial access and movement to a second machine has fallen to well under an hour. Neither figure is about a particular threat group, which is what makes them useful: they describe the ordinary case rather than the notable one, and the ordinary case is what an endpoint operation meets. Neither of those is a prediction; both are measured, and together they explain why an endpoint operator spends their time reading relationships rather than files.

You will finish able to say what your detections should key on when there is no file to key on, and where the endpoint retains an advantage that identity and cloud telemetry do not.

The share of detections involving no malicious file has climbed steadily for several years and now sits at around 82 per cent, up from roughly half at the start of the decade.

That is not a statement about how clever adversaries have become at hiding files. It is a statement that they have largely stopped using files. Intrusions run on valid credentials, on administrative tools that ship with the operating system, on approved integrations and on trusted identity flows, and they blend into ordinary activity because they are made of ordinary activity.

That diagram is the argument for the whole course in one picture. If the adversary brings nothing, then detection is a question about behavior, and behavior is only available if it was recorded, which is why EO0.2 and EO0.3 came before anything about writing rules.

It also explains a frustration that arrives early in this job. Antivirus is working, the console is green, the estate is genuinely protected against the eighteen per cent, and an intrusion runs through it anyway using nothing the product was built to object to. That is not a failure of the product; it is a product answering the question it was designed to answer, on a threat that stopped asking it.

Both halves are needed. The malware share has fallen and it has not gone away, so the scanning layer still covers the commodity end of the spectrum cheaply and automatically, and that matters because the commodity end is where volume lives. What has changed is that it is no longer the interesting layer, and an operator whose mental model is scanning will be reading the wrong fields.

The trend is also worth knowing as a trend rather than a snapshot. Roughly two in five detections were malware-free at the end of the last decade, about half by 2020, and something over four in five now. A number moving that consistently in one direction is a structural shift rather than a fluctuation, and it means a detection library assembled five years ago was built for a materially different distribution of threats than the one it now faces.

Breakout time is the interval between initial access on one machine and movement to a second. It is the most operationally useful number published about intrusions, because it is the deadline: whatever your detection and response manages to do inside it happens on one machine, and everything after it happens on more than one. The average across criminal intrusions has fallen to around twenty-nine minutes, from roughly forty-eight the year before, and the fastest recorded case was twenty-seven seconds.

Those numbers break a model rather than merely accelerating it. Detect, then investigate, then respond is a sequence with latency at every step, and a sequence measured in hours cannot contain something that has already moved in half an hour.

Read the direction as well as the value. Forty-eight minutes to twenty-nine in a single year is a sixty-five per cent increase in speed, which is not a trend line you can plan around by shaving minutes off triage. Whatever margin you gain by working faster is being consumed at a rate you do not control.

Some of that acceleration is tooling on the other side rather than skill. Access is increasingly brokered and handed on, and parts of the sequence are automated, which is why the interval compresses without the individual steps becoming more sophisticated. It is the same six operating system binaries, executed faster.

The fastest recorded case is the one that settles the argument about automation. Twenty-seven seconds from initial access to lateral movement is shorter than the time it takes a person to read an alert title, so for that class of case there is no human response and the only question is whether something automatic was already agreed.

Do not design the whole operation for the fastest case, though. It is the extreme rather than the median, and an operation built around twenty-seven seconds would automate things that need judgment. The median of twenty-nine minutes is the number to plan against: it is long enough for a person to act and short enough that the person has to already know what to do, which is an argument for prepared playbooks rather than for removing the person.

The practical consequence for an endpoint operator is specific: the detections that matter most are the ones covering the first few minutes rather than the impact stage. A rule that fires on encryption behavior is a rule that fires after the decision has already been made for you.

Check where your own rules sit on that timeline. Most estates have good coverage at the impact end, because impact behavior is unambiguous and easy to write a rule for, and thin coverage at initial access and execution, because that is where the legitimate and the malicious look most alike. That distribution is a natural consequence of writing the easy rules first, and it puts your detection weight exactly where the breakout figures say it helps least.

The rebalancing does not mean removing the impact rules. Those are the safety net and they are the ones that will catch an intrusion nobody saw earlier, so they stay. It means the next few rules you write should be earlier ones, and it means accepting that earlier rules are harder, noisier and need the baselining work from EO0.7 before they are shippable.

The exercise below is the scenario at the top of this section. Read the parent line before the command line on every entry, because parentage is doing most of the work in the judgment and it is the field people skip.

Work it before reading the explanation, and expect the first pass to be uncomfortable. Nine lines, all signed, all Microsoft, and no verdict anywhere to lean on. That discomfort is the point of the exercise: it is what every real triage decision on a malware-free intrusion feels like, and the technique for handling it is the four checks in the closing card rather than a stronger instinct.

Two entries in that artifact look alarming and are ordinary, and both are separated from the intrusion by the same two fields. Parent process and argument shape carry almost the entire judgment, which is worth noticing because they are also the two fields most often absent from a detection somebody wrote in a hurry.

The time of day is the third signal and it is weaker than it looks. Activity at half past two in the morning is suspicious on a workstation belonging to somebody who works office hours and unremarkable on a shift worker's machine or during a maintenance window. Use it to sort what you look at first rather than as a condition in a rule, because a rule keyed on hours will miss the same intrusion run at eleven in the morning.

When everything is legitimate, the question changes from what is bad to what is unusual here. That is a question about your estate rather than about the world, and it is one no vendor can answer for you.

// Living off the land: signed system binaries, ranked by how rare their parent is
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("rundll32.exe", "mshta.exe", "wmic.exe",
                     "regsvr32.exe", "certutil.exe", "bitsadmin.exe")
| summarize Hosts = dcount(DeviceName), Runs = count()
          by FileName, InitiatingProcessFileName
| where Hosts <= 3
| sort by Hosts asc, Runs asc

That query contains no notion of malicious. It groups by the pair of binary and parent, then keeps only the pairs appearing on three hosts or fewer, because on a uniform managed estate a legitimate parent-child pair appears almost everywhere and an intrusion's pair appears once.

Set the threshold from your own estate rather than taking the three. On 865 uniform workstations three is generous and you could use one; on a fleet with many bespoke machines it will return too much. Run the same query without the threshold once, look at the distribution of host counts, and put the line where the long tail starts.

Add a second dimension when the first pass is noisy. The same query grouped by binary, parent and the initiating account will separate an administrator using wmic on three machines from an intrusion using it on three machines, because the account tells you which. Rarity on its own finds the unusual; rarity plus context tells you whether unusual is a problem.

The uniformity is doing the work, which is worth understanding because it also tells you where this technique fails. An estate where every machine has different software, or where developers install what they like, has no uniform baseline to be rare against, and rarity hunting there produces noise. Managed estates are easier to hunt in for exactly the reason they are duller to work on.

Where that is your situation, split the population before hunting rather than abandoning the technique. Engineering laptops hunted against engineering laptops still have a usable baseline, even where the estate as a whole does not, and a rare pair within a coherent population is as meaningful as one across a uniform fleet.

The same shape works for scheduled tasks, service creation, remote execution and administrative logons. It is the single most transferable hunting pattern in this course, and it works precisely because the tools are legitimate: their ordinary usage is uniform, so the exception stands out.

Keep the explained pairs when you work through the result. The output of one afternoon is a baseline of what is normal here, which makes the next run of the same query a comparison rather than a fresh investigation, and turns a day of work into fifteen minutes a quarter. That is the baselining from EO0.7 in its most useful form.

Adversaries move where visibility is thinnest, and that is increasingly not the endpoint. Cloud-conscious intrusions rose sharply last year, valid account abuse accounted for around a third of cloud incidents, and a large share of exploitation by one prominent group targeted edge devices such as VPN appliances, firewalls and routers, which sit outside endpoint agent coverage entirely.

That movement is a compliment to the discipline and a problem for it at once. Endpoints are the best-monitored surface in most organizations, which is exactly why intrusions increasingly avoid spending time on them, and an endpoint operator working only from endpoint telemetry will see the parts of an intrusion that touched a device and infer the rest.

Write it down once and reuse it. A boundary statement is a paragraph, it changes perhaps twice a year, and having it ready turns an awkward question during an incident into a document you already circulated.

State that honestly rather than defensively. An endpoint operator who claims coverage of the whole intrusion surface will be wrong in a specific, discoverable way, and an endpoint operator who names the boundary is the one people trust when they say something is covered.

The edge appliance row deserves particular attention because of how it is being exploited. Exploits against these devices have been weaponized within a couple of days of public disclosure, and they are precisely the devices no endpoint agent runs on, so a serious intrusion can begin and establish itself entirely outside the telemetry this course teaches you to read.

That is an argument for knowing who does watch them rather than for taking it on. Somebody in most organizations receives those logs, and the useful contribution from the endpoint side is a standing arrangement to be told when one of those devices is implicated, because the next thing an adversary does after an edge appliance is reach a machine you can see.

What the endpoint retains is the thing no other telemetry has: execution. Identity data can tell you a token was used and cloud audit can tell you an API was called, and only the endpoint can tell you what actually ran on a machine and what it spawned. When an intrusion touches a device at all, that is where the richest evidence lives.

That is a genuine advantage and it is worth stating in the same conversation as the boundary. An identity alert says an account did something unusual; the endpoint says which process, under which parent, with which command line, and what happened in the four minutes afterwards. Almost every investigation that reaches a conclusion does so on endpoint evidence, even when it started somewhere else.

The figures above are not context; they are instructions about what to build.

The fourth row is the one that requires the most courage, because it means writing down what you cannot see and giving it to somebody who may assume you can see everything. That is uncomfortable once and considerably better than the alternative, which is being asked during an incident why an entire population produced no evidence.

The third row is the one endpoint practitioners skip most. Almost every entry in the exercise above carried an account, and the intrusion is as much a story about what that account did as about which binaries ran. Reading the account context turns an endpoint finding into something the identity team can act on.

It also changes what containment means. Isolating a workstation removes one machine from the network and leaves the credential working everywhere else, which on a valid-credential intrusion is containing the symptom. The account has to be dealt with by somebody else, usually quickly, and the endpoint operator is the person who knows which account and when.

Build the habit of naming the account in every escalation for that reason. An escalation that says a machine is compromised gets a machine isolated; one that says this account executed this at this time and moved to this host gets both actions taken.

The same applies in reverse and it is worth expecting. Identity teams will send you findings about an account with no device context, and the endpoint telemetry is where that becomes an intrusion with a shape. Handling those well is one of the fastest ways an endpoint operator becomes useful beyond their own queue.

The breakout figures argue for some pre-agreed automatic action, and the argument collapses the moment somebody proposes automating everything. The workable version is narrow and agreed in advance with whoever owns the endpoints.

Before proposing anything on that page, run the case through four tests. Failing any one of them means the answer is no, and most cases fail the first.

Two or three cases is a realistic target and it is worth more than it sounds, because those are the cases that would otherwise be handled at whatever hour they occur by whoever is available. Automating the unambiguous end also protects the analyst judgment you have for the cases that need it.

Start from the incidents you have actually had rather than from a list of what could be automated. Look at the last year of confirmed incidents, find the ones where the first correct action was obvious to everybody afterwards, and propose those. A proposal grounded in three real incidents from this estate is a different conversation from a proposal grounded in a vendor's capability list.

Scope the automation to a device group rather than the estate on the first pass, which is what the group-level automation setting exists for. A containment action agreed for laptops and not for servers is a proposal that gets accepted, and it produces six months of evidence for the wider version.

The fourth test is the one that gets skipped and the one that determines whether the automation survives. An automatic containment nobody agreed to will be switched off after the first false positive, and the conversation that follows will make the next proposal harder.

The adversary in the exercise above did nothing sophisticated. Six operating system binaries in an order documented for years, and it worked because the estate was watching for files. Most intrusions are like that, which means the work is far more often reading ordinary things carefully than recognizing something exotic.

One query, and one paragraph about what you cannot see. The second is the harder of the two to write.

The next section explains why this course is ordered as it is, which is largely a consequence of the two figures above.