Author Topic: How a Microsoft blunder opened millions of PCs to potent malware attacks  (Read 173 times)

Offline javajolt

  • Administrator
  • Hero Member
  • *****
  • Posts: 35044
  • Gender: Male
  • I Do Windows
For almost two years, Microsoft officials botched a key Windows defense, an unexplained lapse that left customers open to a malware infection technique that has been especially effective in recent months.

Microsoft officials have steadfastly asserted that Windows Update will automatically add new software drivers to a blocklist designed to thwart a well-known trick in the malware infection playbook. The malware technique—known as BYOVD, short for "bring your own vulnerable driver"—makes it easy for an attacker with administrative control to bypass Windows kernel protections. Rather than writing an exploit from scratch, the attacker simply installs any one of dozens of third-party drivers with known vulnerabilities. Then the attacker exploits those vulnerabilities to gain instant access to some of the most fortified regions of Windows.

It turns out, however, that Windows was not properly downloading and applying updates to the driver blocklist, leaving users vulnerable to new BYOVD attacks.

As attacks surge, Microsoft countermeasures languish

Drivers typically allow computers to work with printers, cameras, or other peripheral devices—or to do other things such as provide analytics about the functioning of computer hardware. For many drivers to work, they need a direct pipeline into the kernel, the core of an operating system where the most sensitive code resides. For this reason, Microsoft heavily fortifies the kernel and requires all drivers to be digitally signed with a certificate that verifies they have been inspected and come from a trusted source.

Even then, however, legitimate drivers sometimes contain memory corruption vulnerabilities or other serious flaws that, when exploited, allow hackers to funnel their malicious code directly into the kernel. Even after a developer patches the vulnerability, the old, buggy drivers remain excellent candidates for BYOVD attacks because they’re already signed. By adding this kind of driver to the execution flow of a malware attack, hackers can save weeks of development and testing time.
BYOVD has been a fact of life for at least a decade. Malware dubbed "Slingshot" employed BYOVD since at least 2012, and other early entrants to the BYOVD scene included LoJax, InvisiMole, and RobbinHood.

Over the past couple of years, we have seen a rash of new BYOVD attacks. One such attack late last year was carried out by the North Korean government-backed Lazarus group. It used a decommissioned Dell driver with a high-severity vulnerability to target an employee of an aerospace company in the Netherlands and a political journalist in Belgium.

In a separate BYOVD attack a few months ago, cybercriminals installed the BlackByte ransomware by installing and then exploiting a buggy driver for Micro-Star’s MSI AfterBurner, a widely used graphics card overclocking utility.

In July, a ransomware threat group installed the driver mhyprot2.sys—a deprecated anti-cheat driver used by the wildly popular game Genshin Impact—during targeted attacks that went on to exploit a code execution vulnerability in the driver to burrow further into Windows.

A month earlier, criminals spreading the AvosLocker ransomware likewise abused the vulnerable Avast anti-rootkit driver aswarpot.sys to bypass virus scanning.

Entire blog posts have been devoted to enumerating the growing instances of BYOVD attacks, with this post from security firm Eclypsium and this one from ESET among the most notable.

Microsoft is acutely aware of the BYOVD threat and has been working on defenses to stop these attacks, mainly by creating mechanisms to stop Windows from loading signed-but-vulnerable drivers. The most common mechanism for driver blocking uses a combination of what's called memory integrity and HVCI, short for Hypervisor-Protected Code Integrity. A separate mechanism for preventing bad drivers from being written to disk is known as ASR or Attack Surface Reduction.

Unfortunately, neither approach seems to have worked as well as intended.

Microsoft has touted these protections since at least March 2020, when the company published this post promoting "Secured Core" PCs, which have HVCI enabled right out of the box. Microsoft presented Secured Core PCs (and HVCI in general) as a panacea for in-the-wild BYOVD attacks, stemming either from buggy drivers or "wormhole" drivers (those which are vulnerable by design). The company wrote:

In our research, we identified over 50 vendors that have published many such wormhole drivers. We actively work with these vendors and determine an action plan to remediate these drivers. In order to further help customers identify these drivers and take necessary measures, we built an automated way in which we can block vulnerable drivers and that is updated through Windows update. Customers can also manage their own blocklist as outlined in the sections below. [emphasis added]

The post went on to say that "Microsoft threat research teams continuously monitor the threat ecosystem and update the list of drivers that [are] in the Microsoft-supplied blocklist. This blocklist is pushed down to devices via Windows update."

A few months later, Microsoft Senior VP of Enterprise and OS Security David Weston tweeted that by turning on these protections, Windows users were safe from an ongoing BYOVD attack that had recently made the rounds.

“Security vendors are going to tell you [that you] need to buy their stuff, but Windows has everything you need to block it,” Weston wrote.

Multiple Microsoft posts have made the same claim about automatic updating ever since. This one from last December said that signed drivers reported to be vulnerable are blocked by default through Microsoft’s automated Windows Update mechanism when Windows 10 has HVCI enabled.

But as I was reporting on the North Korean attacks mentioned above, I wanted to make sure this heavily promoted driver-blocking feature was working as advertised on my Windows 10 machine. Yes, I had memory integrity turned on in Windows Security > Device security > Core isolation, but I saw no evidence that a list of banned drivers was periodically updated.

So I reached out to Microsoft and asked if someone would provide me with background about how the protection worked. The response: Microsoft had “nothing to share” with me.

I then turned to Peter Kálnai, a researcher at security firm ESET who has had plenty to share about BYOVD attacks. I asked him for help testing this driver blocklist feature. Very quickly, we found it lacking. When Kálnai enabled HVCI on a Windows 10 Enterprise system in his lab, for instance, the machine loaded the vulnerable Dell driver that had recently been exploited by Lazarus.

Around the same time, researchers, including Will Dormann, a senior vulnerability analyst at security firm ANALYGENCE, had been tweeting for weeks that various drivers known to be actively used in BYOVD attacks were not being blocked the way Microsoft advertised.

One Dormann observation was that even with HVCI turned on, his lab machines loaded a vulnerable driver known as WinRing0 just fine.

Upon further investigation, Dormann discovered that this vulnerable WinRing0 driver wasn’t present in the Microsoft-recommended driver block rules. In the same thread, he went on to show that, despite Microsoft's claims that ASR is capable of blocking vulnerable drivers from being written to disk, he could find no evidence that this feature worked at all. Microsoft has yet to address this criticism or to provide Dormann with guidance.

Dormann went on to discover that the driver blocklist for HVCI-enabled Windows 10 machines hadn't been updated since 2019, and the initial blocklist for Server 2019 only included two drivers.

As scrutiny of this situation increased, a Microsoft project manager finally admitted that something had gone wrong with the update process for the driver blocklist. The manager tweeted that Microsoft was “fixing the issues with our servicing process which has prevented devices from receiving updates to the policy.”

What the program manager was saying boiled down to this: If you thought HVCI was protecting you from recent BYOVD attacks, you were probably wrong. Windows 10 hadn't updated the list in almost three years.

Coinciding with the project manager’s tweet, Microsoft released a tool that allowed Windows 10 users to deploy the blocklist updates that had been held back for three years. (Not that Microsoft has done much to promote the tool; the company quietly updated instructions here.) But this is a one-time update process; it is not yet clear if Microsoft can or will push automatic updates to the driver blocklist through Windows Update.

While Microsoft’s response to my questions about driver blocklist updating was indifference, company employees have been actively dismissive to admins and researchers who began asking their own questions about the topic. Recently, for instance, when Dormann pointed out a demonstrably false claim in an August tweet from Weston—that ASR ensured that updated driver blocking happened automatically—Weston did not apologize or even admit the problems. Rather than confirming an update lapse that spanned more than two years, Weston bristled, saying only that updates “are in the servicing pipeline” and that Microsoft has already “provided a tool to do it right now."

The closest Microsoft has come to an admission of failure is a comment from a company representative, saying, “The vulnerable driver list is regularly updated, however, we received feedback there has been a gap in synchronization across OS versions. We have corrected this and it will be serviced in upcoming and future Windows Updates. The documentation page will be updated as new updates are released.”

The representative didn’t say how long the gap lasted or what upcoming and future Windows updates would fully fix the problem.

Another approach

The Microsoft instructions linked above work, but they’re written for admins who may need to test the blocklist before actually enforcing it. This flexibility is great for people responsible for ensuring they don't cripple big fleets of devices; for average users, it creates unnecessary complexity that may cause them to give up.

To address this, Dormann has created and published a script that normal (i.e., non-enterprise) users will likely find easier to use than Microsoft’s convoluted method. Dormann’s script runs in PowerShell, the command-line shell that's built into Windows. As with any PowerShell script you find on the Internet, be mindful of running this on any computer you care about. It worked for us, but we can't vouch for its effectiveness in every system.

After opening PowerShell with administrator rights, copy the entire contents of Dormann’s script, paste it into the PowerShell window using the ctrl-V keys on your keyboard, and hit enter. Next, type ApplyWDACPolicy -auto -enforce and hit enter.

When I did that, my ThinkPad was no longer able to load a long list of known buggy drivers, including many that have been used for years in recent BYOVD attacks.

Or at least, that was my hope. Given Microsoft’s recent inattention to detail and lack of transparency, I wanted to make sure.

To confirm that driver blocking was working as expected, I checked to see if my machine would load mhyprot3.sys, a successor to the Genshin Impact anti-cheat driver. This driver, as mentioned earlier, was recently used by a ransomware threat group during targeted attacks that went on to exploit a code-execution vulnerability in the driver to disable antivirus scanning.

Prior to running Dormann's PowerShell script, my ThinkPad installed mhyprot3.sys just fine.

After I ran the script, the driver was blocked. This can be confirmed by responses in both the Windows command window and the Windows event viewer.

These images are a striking illustration of the difference between the way that Microsoft claimed Windows driver blocking worked and the way it has actually worked for the past two years. It seems clear that at least some recent malware campaigns using BYOVD would have been less successful had driver blocklist updating lived up to Microsoft’s promises.

Indeed, research from ESET's Kálnai found that in the last year, drivers that have been added to Microsoft's driver blocklist were actually used in in-the-wild BYOVD attacks. These include:

   • DBUtil_2_3.sys by Dell

   • ene.sys by ENE Technology

   • HW.sys by Marvin Test Solutions, Inc.

   • physmem.sys by Hilscher Gesellschaft für Systemautomation mbH

   • rtcore64.sys by Micro-Star

   • mhyprot2.sys by miHoYo Co

   • asWarPot.sys by Avas

   • nvflash.sys by NVIDIA

Stay safe

For now, people should make sure they have driver blocking turned on with the latest blocklist installed using either Microsoft's instructions or Dormann's PowerShell script. People should also await further updates from Microsoft about if and when driver blocklists will automatically be updated through the Windows Update mechanism.

In the longer term, Microsoft's leadership will hopefully recognize the ways that its company culture is becoming increasingly insular and defensive. Had it not been for Dormann and other researchers, like Kevin Beaumont and Brian in Pittsburgh, reporting the problems they were having with driver blocklist updates, Microsoft still might not understand what had gone wrong.

In many cases, these critics know Microsoft products better than executives like Weston. Instead of portraying the critics as uninformed complainers, Microsoft should publicly embrace them—and provide more actionable guidance they and others can use to make the Internet safer.