See It Done: A Week on the Queue

Introduction

Everything in this module so far has been a piece of the job described on its own. This section is one week at Northgate with all the pieces arriving together, in the order and at the pace they actually arrive.

Nothing in the week is exotic. There is one real intrusion, a great deal of ordinary queue work, two things that turn out to be nothing after an hour of somebody's time, and one question that cannot be answered at all. That last one is the most useful thing the week produces.

You will finish able to recognize each of this module's failures in the middle of a working week rather than in a section named after it, which is the only place recognizing them is worth anything.

Priya opens the queue at 08:30. Forty-one items, of which she will close thirty-eight by six o'clock, and the shape of that number is the first thing worth reading.

She does not produce the table below as part of her day. It comes from the ticketing system afterwards, in about ten minutes, and it is the first time anybody at Northgate has looked at handling time rather than count.

Read the two lines at the bottom. Volume and cost point at different rows, which is the observation from EO0.8: the alert type that dominates the count is not the one consuming the week, and a tuning effort aimed at the top row would free thirty-eight minutes.

Thirty-eight closed items in a shift is also worth putting against the published range. Tier one analysts typically process somewhere between twenty and fifty alerts a shift, so this is an ordinary day rather than a heavy one, and it still consumed most of two people. That is the capacity arithmetic from EO0.8 arriving as lived experience: the queue fits, just, and there is nothing left over.

The LSASS rule is the expensive one, and it is the rule from EO0.10's exercise. It fires on the endpoint agent's own access to the process it protects, four times a day, and every one of those alerts costs half an hour because an analyst has to establish which access it was. Priya has raised it twice.

Nothing happens about it, and the reason is worth understanding rather than resenting. Raising it as noisy is a complaint, and complaints compete with everything else somebody has to do. The version that moves is the cost table above: four alerts a day at thirty-one minutes each is roughly two hours of analyst time daily, or a quarter of one person, and that is a sentence with a number in it that somebody can weigh against the fortnight of engineering it would take to fix.

Priya writes that version on Monday afternoon. It is the first of the week's four outputs and it arrives before anything has gone wrong.

Legal ask for the logon history of a departed contractor across March, for an employment matter. It is a reasonable request, it arrives with a deadline, and it takes Tom eleven minutes to establish that it cannot be answered.

Requests like this are more common than most endpoint teams expect, and they arrive from outside security entirely. Legal, HR and audit all eventually want a record of what somebody did on a machine, and the security team is where they ask because it is where the logging is.

// The question, and the answer it actually returns
DeviceLogonEvents
| where Timestamp between (datetime(2026-03-01) .. datetime(2026-03-31))
| where AccountName == "c.mackay"
| summarize Logons = count() by DeviceName, LogonType
// returns: 0 rows. advanced hunting holds 30 days.
// SIEM holds 90 in the analytics tier. March is 5 months back.

Zero rows, no error, and an answer that reads like the contractor did nothing in March. Tom recognizes it as the retention boundary from EO0.3 rather than a finding, which is the difference between an honest answer and a wrong one.

The query is written with an explicit date range rather than a relative lookback for exactly this reason. A relative range would have quietly returned the most recent thirty days and produced rows, which look like an answer to a question about March and are not. An explicit range returns nothing and the nothing is informative.

What he does next is the part worth copying. He replies the same day with the window each source can answer for, states that March is outside all of them, and raises a ticket recording the request that could not be met. That ticket is the third ending from EO0.7, and it is the fourth such ticket this year.

Compare that with what usually happens. The common version is a day spent searching increasingly creatively, a reply late in the week saying no records were found, and nothing written down anywhere. The requester reads no records found as evidence of absence, which is a materially different answer from we do not keep records that far back, and the retention gap that caused it stays invisible for another quarter.

Tom's eleven minutes are the whole difference, and they were possible because the retention map from EO0.3 was already written down. Without it he would have been guessing about whether the empty result meant anything.

Four suspicious PowerShell alerts fire on WS-NGE-MCR-0198 between 09:14 and 15:50. Priya examines two, finds encoded command lines of the kind the estate produces daily, and plans to close the other two on Thursday.

That decision is defensible on each alert individually and wrong on the four together. Four of one type on one host is a cluster, and a cluster is the shape an intrusion makes, whereas nineteen encoded PowerShell alerts spread across nineteen machines is a Tuesday.

The distinction is not subtle and it is nearly invisible in a queue interface. Alerts arrive as a list ordered by time and severity, and the host is one column among a dozen; nothing draws the eye to the fact that four rows separated by six hours share a value in it. Reading the queue grouped by host once a shift is a thirty-second habit that would have surfaced this, and almost nobody does it.

There is a second reason the sampling was reasonable and still wrong. Encoded PowerShell on this estate is genuinely common, nineteen of them fired on Monday, and an analyst who investigated all nineteen would have closed nothing else that day. The correct response to a common alert type is not to examine every instance; it is to have a rule that raises the ones clustering on one host, which is exactly the output Friday produces.

The handover is better than most and it still drops things. Seven alerts arrived after four o'clock and nobody opened them, while the in-progress line says nothing, so the incoming shift reads a document telling them there is no partial work.

The impossible travel closure in that note deserves its own comment, because it is the failure from EO0.5 in miniature. She is at a conference is either something Priya verified or something she assumed from knowing Elena's calendar, and the note does not say which. Six weeks later nobody can reconstruct it, and if that closure ever turns out to have been wrong there is no way to tell whether the reasoning was flawed or the evidence was.

One extra clause would have fixed it: confirmed with her directly, or seen the travel approval, or assumed from the team calendar. Three words, written while the view is open, and the closure becomes defensible.

Marcus runs the rare-pair hunt from EO0.9 on Thursday morning, as part of the baselining work rather than because of anything on the queue. It returns eleven pairs on three hosts or fewer, of which ten are explainable in a few minutes.

It is worth noticing that this hunt was scheduled rather than prompted. Nobody asked for it, no alert triggered it, and it was on Marcus's list because the team had decided to baseline the estate. Had the week been slightly busier it would have been the thing that slipped, which is the pattern from EO0.7: hunts are the interruptible work and they are interrupted first.

Two hunts a quarter had been planned and this was the second of them. The intrusion was found by the last hunt the team had capacity for.

InitiatingProcessFileName   FileName          Hosts   FirstSeen
mshta.exe                   powershell.exe        1   2026-08-11T02:41:07

(every other pair in the result appears on 40+ hosts,
 or is a deployment tool nobody needs to think about)

The host is WS-NGE-MCR-0198. The same host as Wednesday's four alerts.

That last line is the whole week in two sentences. The alerts fired, they were triaged individually and reasonably, and the connection between them and to a parent process that has no business existing on a workstation was made by a hunt three days later.

Ten of eleven pairs explained in a few minutes is worth registering too, because it is what makes this technique usable. A hunt that returns eleven rows on a fleet of 865 machines is a hunt somebody can actually work, and the ten that turned out to be a deployment tool, two administrators and a developer are now written down as the baseline. Next quarter's run of the same query starts from ten known-good pairs rather than from nothing.

The pair itself is not subtle once seen. A scripting host spawning a shell has no legitimate reason to occur on a workstation, it appears on exactly one machine out of 865, and the parent-child relationship is the entire signal. Neither binary is unusual and the pair is, which is the EO0.9 observation in its simplest possible form.

Reconstructing it takes the rest of the morning. Initial execution at 02:41 on Monday, reconnaissance for domain admins two minutes later, remote process creation against the file server at 03:11, and a logon to that file server at 03:14. Thirty-three minutes from first execution to a second host, which is close to the published average breakout time from EO0.9.

Note where the reconstruction happened. Every step of it was in advanced hunting the whole time, retrievable in minutes, and Monday is inside the thirty-day window with room to spare. Nothing was lost to retention and nothing needed a special collection; the evidence sat there for three days while four alerts about the same host were triaged as four unrelated events.

That is the uncomfortable shape of most missed intrusions. Not an absence of data, and not an absence of alerts, but an absence of the connection between them, which no product makes for you and which took Marcus about forty minutes once he had a reason to look.

Containment follows from that reading rather than from the alert. Both hosts are isolated, because the breakout at 03:14 means the file server is part of the incident rather than somewhere it might go, and the account is reset by somebody else on what Marcus tells them.

Containment is straightforward: both hosts isolated by three o'clock, the account reset, the file server examined. The investigation is where the week gets uncomfortable.

Both hosts is the phrase to notice. Containing only the workstation would have been the obvious action and the wrong one, because the breakout at 03:14 means the file server is part of the incident rather than a place the incident might go. That judgment came from having found the logon, and it is the reason EO0.9 treats the breakout moment as the thing that changes scope rather than as one more event in a timeline.

The account reset is the other half and it belongs to somebody else. Isolating machines removes two hosts from the network and leaves the credential working everywhere, so the identity team has to act, and they act on what Marcus tells them. An escalation that named the account and the time got both things done; one that said a machine is compromised would have got one.

Three of the six are unanswerable and none of them is anybody's fault. Script block logging was never enabled, which is a readiness decision from EO4 that nobody took. The workstation was reimaged on Tuesday by a service desk measured on getting a user working again, which is the fourth failure from EO0.5 in its exact textbook form.

Read the reimage timing against the timeline. The machine was rebuilt on Tuesday morning, roughly thirty hours after the intrusion started and two days before anybody knew there had been one, in response to a user saying their computer was acting strangely. The service desk did their job correctly and quickly, and in doing so destroyed the only copy of whatever was on that disk.

The user report is worth dwelling on for a different reason. Somebody noticed something was wrong on Tuesday morning, roughly thirty hours before the security team did, and reported it to the service desk because that is where you report a computer behaving oddly. That report never reached the queue, and there is no mechanism by which it would have.

Wiring the service desk's own signal into the security queue is not in any module of this course, and it is one of the highest-yield things a small team can arrange. A user saying my machine is strange is a detection with a very low false positive rate and it is currently being routed away from the people who would recognize it.

Nothing in that sequence is fixable by asking anybody to behave differently. What fixes it is collection triggered by a signal the service desk already generates, which is the point EO4 makes and the reason readiness is a configuration problem rather than a discipline problem.

Marcus writes those three lines down as the thing the investigation could not establish. That is the habit from EO0.8, and it is the entry that will eventually get script block logging turned on.

Thirty-eight alerts closed on Monday is not what the week produced. One hundred and ninety alerts closed across the week is not either, and that number is the one the metrics pack will carry.

Four things are, and it is worth noticing when each of them was created. Three came out of things going wrong on Wednesday and Thursday, and one came from Monday afternoon when nothing was happening at all.

The second output is the one most teams never write. A correlation rule that raises an incident when three or more alerts of the same type hit one host in a day would have surfaced Wednesday's cluster on Wednesday, and it is a rule about the queue rather than about a technique.

It is also cheap and unglamorous, which is why it does not get written. There is no technique to research, no threat report behind it and nothing to map it to; it is a rule that says look at this host, and it would have moved the discovery from Thursday to Wednesday morning. Rules about the shape of the queue rather than the shape of an attack are consistently undervalued and consistently among the highest-yield things a team can ship.

Scope it to the alert types that are individually common and collectively meaningful. Encoded PowerShell qualifies. A rule that fires on any three alerts of any type would produce its own noise problem, which is the trap in every good idea about correlation.

Rachel asks the obvious question at Friday's review: how did an intrusion run for three days while alerts were firing about it.

There are two ways to answer that and they lead to different places. One is that the analyst on Wednesday should have looked at all four alerts, which is true, is unfair, and produces nothing except an analyst who is more anxious next week. The other is to walk the seven entries in the table below and show that six of them were set before Monday.

The second version also determines whether the team tells you about the next one. A review that lands on individual judgment teaches people to be careful about what they write down, and a review that lands on the queue design teaches them to bring you the next cluster on Wednesday morning.

There is a third version that is worse than either and it is common, which is not reviewing the week at all because nothing was breached and the containment worked. A week that ends with an intrusion contained feels like a success, and the three days are only visible if somebody goes looking for the first evidence, which is the retrospective calculation from EO0.8. Without it this week is filed as a win.

Marcus takes the four outputs into that meeting rather than a narrative. Three of them cost under a day each, and the fourth, script block logging, now has an incident behind it, which is the difference between a request and a case.

Every failure in the week has a module, and naming them is the point of this walkthrough. Do it as a table rather than as a narrative, because a table can be worked through in a meeting and a narrative gets discussed.

The mapping is also how you decide what to do next. Seven entries is more than any team fixes at once, so the ones to take are the cheap ones with the widest effect, which in this week are the correlation rule and the handover template. Both are a day, both apply to every week from now on, and neither requires anybody's permission.

Read the last line. One entry in that table would have been solved by somebody being better at their job, and six would have been solved by a decision taken on an ordinary afternoon when nothing was happening.

That ratio is the argument for this entire module. A course that only taught investigation technique would address one of the seven, and the person reading it would still lose three days on the next intrusion for reasons that have nothing to do with their skill at reading a process tree.

It is also the honest answer to somebody asking why the orientation module is eleven sections long before any query language appears. Six of the seven entries were decided before the week started, by people who were not thinking about this week, which is where EO0.1 began.

Nobody in this week was negligent. The tooling worked, the alerts fired, the data was retained, and a competent team lost three days on an intrusion visible from Monday morning. That is the normal condition of endpoint operations rather than a failure state, and the six modules after this one are an attempt to compress those three days.

That was one week at Northgate. This is how you read your own.

The final section of this module summarizes what the orientation established, and then the course begins with the telemetry you are operating.