LSASS minidump: a credential theft attempt, caught in a second

What the attack is

When someone signs in to a Windows machine, the system keeps what it needs to recognise them in memory. For an intruder who already has a foothold, that memory is the prize: copy it out, and the passwords of everyone who has used the machine come with it — often including an administrator's, which is what turns one compromised computer into the whole network.

It is one of the most common steps in real intrusions, and one of the most important to catch, because it is usually done with tools that are already part of the operating system rather than with anything that looks like malware.

What the test was

A disposable virtual machine with the nXDR agent installed, and a single attempt to copy that memory out using only what ships with Windows. Nothing was downloaded and no attack tool was installed.

The shell on the lab machine, showing the two commands used for the attack — The attack itself: two commands in an ordinary shell, using only what ships with Windows.

What nXDR made of it

nXDR alert list: four alerts at 8:03 PM, three critical and one high, all marked new — The alert list seconds later: three critical alerts and one high.

The attempt was raised as critical within about a second, from more than one angle — the alerts are separate detections that reached the same conclusion independently, rather than one rule firing three times.

An nXDR alert opened in detail, showing its causality chain: explorer.exe started powershell.exe, which is marked as the trigger — One alert opened: the process, the command it ran, and the causality chain that led to it.

Every alert explains itself in the console — what it saw and why that matters — so the person reading it does not have to reverse-engineer a rule to understand it.

nXDR process execution chain and event timeline: explorer.exe starts powershell.exe two seconds before the alerts — The full chain and timeline: which program started which, second by second, ending at the one that made the attempt.

Each alert comes with the chain of programs that led to it, so the question "where did this start?" is answered on the same screen rather than in an afternoon of log searching.

What it did not do

It detected; it did not block. The agent was running in observe-only mode for this test, so the attempt was reported rather than stopped. Blocking is a separate mode and is not what this entry shows.

One of the four alerts was noise. The high-severity alert was raised on the machine's own antivirus, which was busy reacting to the same event — not on the attack itself. It is exactly the kind of technically-correct, practically-useless alert that makes a console tiring to live with, and removing it is on the list.

What this means in practice

Put together, this is what someone watching the console would have seen, in order:

A program is started on the machine. Nothing unusual yet — people start programs all day, and nXDR stays quiet.
That program tries to copy the stored sign-in data. This is the moment that matters, and it is the moment the critical alerts appear — about a second later.
The alert already tells the story. Which machine, which program, what started it, and when — without having to dig through logs first.
A person decides what happens next. In this test nXDR only reported. In real use the next step would be to isolate the machine and change the passwords that were on it.

The short version: the attempt was noticed at the moment it happened, rated as serious as it is, and arrived with enough context to act on straight away. What is still missing is stopping it automatically, and a quieter console — both are the next pieces of work.

← All nXDR entries