How fiends abuse an out-of-date Microsoft Windows driver to infect victims

Ransomware spreaders have built a handy tool that abuses an out-of-date Microsoft Windows driver to disable security defenses before dropping malware into the targeted systems. This detection evasion utility, which Sophos X-Ops researchers are calling AuKill, is the latest example in a growing trend where miscreants either …

[Roland6]

Malware that targets SysAdmin’s

Typical users don’t install Process Explorer or other utilities such as 7zip, it is experts with varying degrees of SysAdmin competence that install these useful tools.

The problem I have encountered is that these tools may not either auto update or get updated by software inventory tools.

[Anonymous Coward]

Re: Malware that targets SysAdmin’s

My reading is that Process Explorer doesn’t need to be installed. The malware installs the old Process Explorer driver to leverage a vulnerability in the driver to hide its tracks.

[Roland6]

Re: Malware that targets SysAdmin’s

Thanks on rereading, I see I missed the reference to the malware dropping the old process Explorer on the system.

Now need to see if the security suite can block the execution of “process Explorer”.

[Blackjack]

Re: Malware that targets SysAdmin’s

7zip is actually quite common for regular users as it can check if a compressed file is damaged for example.

Or at least it was back when I used Windows 7. Does Windows 10/11 tell you if a compressed file is in bad state?

[JessicaRabbit]

The real issue here seems to be that Microsoft are either incapable or unwilling to block the installation of known-to-be-vulnerable drivers. Surely it would not be particularly challenging from a technical standpoint to just maintain a revocation list. It need not even revoke the entire signing certificate for a meely vulnerable driver (stolen certificates is another matter), since any modification to the driver would invalidate the signature it would only need to keep hashes of the driver's binary.

[The Basis of everything is...]

MS have a lot of problems, but that ain't one of 'em.

You're now expecting Microsoft to block the installation of applications on your machine at OS level? Just think about that for a second, and then take a guess at how long until they get sued.

If you don't want stuff installed on your computer, or the ones you managed, don't give users the ability to install stuff. Or get one of the many security / endpoint protection tools etc that will give you the control over what actually happens on your computers, and even then keep install rights restricted to as few as possible.

And you owe me a beer for potentially defending M$ too. I feel dirty....

[JessicaRabbit]

Re: MS have a lot of problems, but that ain't one of 'em.

In what way have I defended Microsoft? If anything I'm criticising their lack of a feature that should be available. Also I'm not talking about blocking applications, the article is very specifically about drivers loaded into the kernel. Also it's not users installing the driver, this is about malware that gets onto a computer, uses local privilege escalation vulnerabilties in other OS components to gain System Admin privileges and then using that to install a driver which has been signed thus Windows will accept which is known to contain vulnerabilities which can be used to run arbitrary code at ring 0. Thus allowing them to bypass kernel-level protections including anti-virus etc software which also operates at ring 0.

Plus how is blocking dangerous drivers any different than anti-virus blocking dangerous executables? Suing a company because they protected your customers from an old version of your driver being used to own their machine? Not unthinkable but fuck any company that did that.

[trindflo]

Re: MS have a lot of problems, but that ain't one of 'em.

blocking an application might be difficult, but since the drivers need to be signed *by Microsoft*, it seems like Microsoft should be able to deal with that in a number of ways. Revoking old certificates is the simplest, but not the only way. It is curious why Microsoft hasn't taken any steps in that direction.

[Hans 1]

Re: MS have a lot of problems, but that ain't one of 'em.

You need to re-read the article, MS has.

#FeelsDirtyForDefendingMS

[Phil NZ]

Anyone running Windows Defender AV can enable one of the Attack Surface Reduction rules to do just this.

https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide#block-abuse-of-exploited-vulnerable-signed-drivers

No MDE licence necessary. This one blocks attempts to write known-vulnerable drivers to disk.

Additionally the Vulnerable Driver Blocklist has been available since Windows 10 1809 and is enabled by default in Windows 11 22H2.

This one blocks vulnerable drivers from being loaded by Windows even if they’re already installed.

Stops BYOVD attacks, at least for known-vulnerable drivers.

I know there’s been a lot of whinging on Reg about the hardware requirements for Windows 11, well most of those strict requirements are for the hardware security features that allow for robust HVCI which in turn allows for these controls.

[david 12]

The real issue here was that MS was not updating the block list on Windows 10 or Server 2019, which are no longer receiving OS version updates.

Because the 'driver block list" was tied to the "service pack" release, not to the "anti-virus protection update" release.

[Phil NZ]

That is true, and inexcusable. However it was resolved 6 months ago. So the point still stands, enable the vulnerable driver blocklist in Windows 10, and the Vulnerable Driver ASR rule.

https://support.microsoft.com/en-gb/topic/kb5020779-the-vulnerable-driver-blocklist-after-the-october-2022-preview-release-3fcbe13a-6013-4118-b584-fcfbc6a09936

[ps2os2]

I still blame MS for the problem

I would argue that it is still an MS issue because any code that accepts or disables any or all security without first checking whether the caller is authorized to do so violates basic security protocol. In other words, trust but verify. This is tantamount to leaving the key to the door underneath the mat (or flower pot etc.). Verification of the code that calls a subroutine that essentially lets the caller run naked and can essentially destroy the system and the data it is being protected points directly at the carefree attitude of MS, and it also tells the public that you are a fool in believing that MS cares anything about security and reliability of any MS operating system.

[ChrisBedford]

Re: I still blame MS for the problem

"trust but verify"

The most oxymoronic piece of advice I've ever heard. And I hear it a lot. People quote it all the time without apparently listening to the words or thinking about what they mean.

If you trust something or someone by definition you are dispensing with the need to verify. Conversely, if you verify something or someone you by definition do not trust them or it. The two actions are completely and 100% mutually exclusive, no way to overlap those two circles.

[Mahhn]

Re: I still blame MS for the problem

I think of the "trust but verify" as a pathetic attempt to sound nice, and not say Zero Trust, which is the only way. I don't trust people apps or hardware. But we have to allow just enough leash for work to get done, but keep it tight enough to keep the dog from running into traffic. Inspecting the leash, dog and environment non-stop. Gad I hope I live long enough to retire and be normal (stupid and happy).

[ps2os2]

Re: I still blame MS for the problem

Yes, that is the case all the time with MS, they still have the idea that PCs are playthings, and that may be right in some other world, but here on earth, we consider life. death, money (and a few other items) are real, and in a production environment, it is important to know the basics. and security is one of THE basics.

Try looking at IBM and how they implement security. They take it to the next level. When someone finds a flaw, IBM puts out a fix and alerts people about it, and they make sure the customer knows about it. IBM really is a serious company when it comes to security. Their RACF product security is world-class and, as far as I know, second to none. IBM does security like no other company in the world because they know that their systems are the best.MS's answer to issues like this is "reboot" and forget. If an IBM system is hung or crashes, they have items like system dumps and have the ability 90+ percent of the time to find out why the system crashed/hung and can create a fix for the issue. IBM has been doing this for 40+ years, AFAIK MS has no capability to do this. The real world sees MS as a laugh when it comes to creating a stable system.