nSIEM dev diary · Driver load ·
What the attack is
A driver runs inside the Windows kernel — the deepest level of the machine, below every program and below the security tools that watch them. An intruder who gets a driver of their own loaded can switch those tools off, hide what they are doing, and stay hidden.
That is why Windows insists that drivers carry a trusted signature, and why any driver that appears on a machine is worth knowing about: where it came from, who installed it, and whether Windows let it run.
What the test was
A disposable virtual machine with the nSIEM agent installed, and a test driver that does nothing at all — it loads, then unloads. It was signed with a self-made test certificate rather than one Windows trusts, and installed from an ordinary user folder, twice: once as Windows normally runs, and once with Windows switched into test mode.
Attempt one: Windows says no
With Windows in its normal mode, the driver could be registered but not started. Windows refused to load it because it could not verify the signature.
A refusal is easy to miss — nothing breaks, and nothing appears on screen unless you were the one typing. But Windows writes it down, and nSIEM collected the record:
Attempt two: test mode
Windows has a test mode for developers that accepts drivers signed with a self-made certificate. With it switched on and the certificate trusted, the same driver was installed, started, stopped and removed.
The driver was gone again within seconds — but the installation left two records behind, one in each of two different Windows logs, and nSIEM collected both:
Together they answer the questions that matter: what was installed (a kernel driver), from where (a user's desktop folder, not a system location), and by whom.
Finding it again
A driver that loads from a user's folder is unusual in itself. One search asks exactly that question across everything collected:
What it did not do
It recorded; it did not alert. Every record above was collected and searchable within seconds, but nSIEM does not yet raise an alert on its own — someone had to ask. Turning searches like the one above into detections that fire by themselves is the next stage of the work.
It does not stop drivers. The block in attempt one was Windows doing its job; nSIEM's part was making sure the refusal was not lost.
What this means in practice
- A driver nobody trusts is refused. Windows blocks it — and the refusal is kept, so an attempt that failed is still visible.
- A driver that does load leaves a trail. What, from where and by whom, from two independent logs.
- The trail is one search away. No digging through each machine's logs by hand.