Intrusion investigation

Six findings out of 1.13 million events, and all six sit at the 100th percentile — the most abnormal things in the window by a wide margin. Every one is on a single host, vnevado-win10v, and hosts_running_this = 1 tells me this is not fleet-wide servicing: no other machine does it.

The behaviour is reads and writes against lsass.exe — the process holding credential material — and the command line names two different user accounts, kyleg and fk8mq, each with an NTLM hash. That is pass-the-hash. But I should be careful: the model didn't flag this because it recognises the tool, it flagged it because nothing like it exists in the baseline. Let me confirm that directly rather than trusting my own reading of the filename.

Zero occurrences across a million events of benign history. Whatever this is, the environment has never done it before. Now: how concentrated is it in time, and is anything else happening around it?

The activity is compressed into roughly five minutes on 27 June, 14:32 to 14:37 — the shape of hands-on-keyboard work, not a background process. The fourth row is a different host on a different day, a week earlier; I'll note it as unrelated for now and come back if the timeline demands it.

Now I want the whole local sequence, not just the top of the global ranking — what happened on that host, in that hour, in order.

This is the part that matters. The last two rows are the payload of the stolen credential: a PowerShell command using the impersonated session to list the C$ administrative share on a different machine — vnevado-win10b. So this is not isolated credential theft on one box; it is credential theft in order to reach somewhere else, and it ran fourteen times.

Before I call PowerShell suspicious, though, I should check the obvious objection: this environment surely runs PowerShell constantly.

Exactly the objection, answered. PowerShell runs 51,403 times in the reference and 2,720 times on this very host — utterly routine. That specific invocation: never, not once.

This is why a signature on the binary would be useless here and why the model isn't fooled. The program is legitimate; what is unprecedented is what it was asked to do, and by whom. The score is carrying the sequence and arguments, not the filename.

Next question: does the tool see this as one episode, and does it reach further than I've established?

The top campaign is the one I've been reading: thirty distinct behaviours, fifty-eight events, five minutes, one host — and it scores three and a half times higher than anything else in the window.

Worth being precise about a limitation: the linker grouped this by shared identifiers in time, and it did not pull vnevado-win10b into the campaign. My reason for suspecting that host is the command line, not the graph. The two earlier campaigns on 20 June are a different day and, in the third case, a different machine; I'll treat them as separate activity rather than force them into this story.

So the linker won't confirm the second host for me. I'll go look at it directly.

There it is. On the machine the stolen session reached, in the window immediately after, the second-most abnormal behaviour is Rubeus — a Kerberos ticket-extraction tool — dumping tickets for a third account, lucasb.

That completes a coherent chain rather than a set of unrelated oddities: steal credentials on the first host, use them to reach the second, harvest more credentials there. Each stage was surfaced by the same question — what here is unlike normal — with no rule describing any of it.

Let me assemble what I can defend, and separate it from what I'm inferring.

Observed. On 27 June, 14:32–14:37, vnevado-win10v ran a tool making reads and writes into lsass.exe, referencing NTLM hashes for two accounts (kyleg, fk8mq). Fourteen executions of a PowerShell command listing the administrative share of vnevado-win10b. Within the following ninety minutes, vnevado-win10b ran Rubeus dumping Kerberos tickets for lucasb. None of these behaviours appear anywhere in a million events of benign history; PowerShell itself appears 2,720 times on that host, so the anomaly is the invocation, not the program.

Inferred. That the two hosts are one operation — the evidence is the target name inside the command line and the time ordering, not a linked identifier; the campaign tool did not join them. That the three named accounts are compromised rather than merely referenced. That this is an intruder rather than an authorised red-team exercise, which I cannot distinguish from the telemetry alone.

Not visible to me. Whether the accounts were compromised before this window, how the first host was accessed, and anything at all in the identity plane — sign-ins, mailbox rules, cloud activity — which this device model does not see. If sign-in data exists for these accounts, that is where I would look next.