While in the process of analysing a recent malware sample, I noticed that there was a kernel rootkit involved. This rootkit wasn’t loaded via direct kernel injection but via the old-school technique of dropping and loading a kernel driver file.
Usually, this means that a new kernel driver file turns up on disk with a believable but made-up name in the usual place of <System>\drivers\ and to analyse the rootkit, you simply grab the new file, decompile it, and grok it.
What’s interesting about this sample was that there is no new file to grab – just a brief and temporary change to an existing driver. So how does this turn into a kernel rootkit? Thanks to (entirely legitimate!) driver development work during a former life, I can tell you how.
When you stop and start an already-running driver (assuming it supports stop/unload methods), Windows simply reloads the driver from disk, using the driver’s ImagePath value in the registry or the default driver location. If however the on-disk file has been replaced in the meantime, the replacement driver is loaded on restart!
That’s how this malware works, by replacing beep.sys and null.sys, which are part of the base install of Windows and can be stopped and restarted without introducing any system instability or showing any obvious side-effects. Thus by stopping beep.sys, replacing its driver image on disk and then restarting the fake beep.sys, the malware loads its rootkit.
The malware then immediately overwrites the hacked beep.sys with a copy of the original driver so that the on-disk rootkit sample magically vanishes.
This raises the question – is this poor man’s stealth, or clever man’s stealth?