3 Windows vulnerabilities that may not be worth patching (2024)

Some vulnerabilities eat up a security team’s time and resources yet provide little or nothing in the way of true protection. Some may even introduce more risk to a network.

Credit: Clint Patterson / Unsplash

It’s getting ever harder to keep a network safe and secure from attacks, whether cloud-based, hybrid, or on-premises. Bad actors are employing a dizzying variety of methods, from social engineering to attacking edge devices, to gain a foothold in our networks.

Security teams are urged to take action to secure networks using techniques ranging from patch management to the implementation of zero trust. But even organizations as big as US government agencies and Microsoft itself are proving to be vulnerable to attacks.

Every month we have an increasing number of vulnerabilities and CVEs to manage while performing critical upgrades such as removing NTLM from our networks and implementing Oauth integrations and monitoring and blocking malicious attacks. In the midst of all of this, we are patching vulnerabilities that may — or may not — be a true risk for our firms.

It’s time to slow down and really consider whether some of these represent risks we need to be putting our efforts into.

Here are three examples of vulnerabilities that take time, evaluation, and resources from your security team and yet may not provide much in the way of true protection — in fact, they may provide more risk by making machines unbootable.

Secure boot and KB5025885

Secure boot was touted as “a security standard developed by members of the PC industry to help ensure that a device boots using only software that’s trusted by the original equipment manufacturer (OEM).” Your organization’s device management policies may require you to enable it on your enrolled Windows device.

Devices that don’t meet this requirement may be unable to access work or school resources. In firms, often you are purchasing computers and laptops that have Windows 11 preloaded. As a result, these systems come with Secure Boot enabled and a TPM chip.

Furthermore, many of you are mandated to deploy Bitlocker to provide for disk encryption. While Bitlocker does not provide protection and encryption for data while the computer system is running, it does provide protection for data at rest and often is mandated by policy and cyber insurance mandates.

Yet managing and maintaining secure boot is turning into a headache and a near full-time project. For example, there are a plethora of steps a patching team needs to take to proactively patch and protect from the BlackLotus bootkit (KB5025885 details the process).

First, you must install security updates to supported Windows machines that are included in security updates released after April 9, 2024 (and later). Then you need to ensure that machines have their firmware up to date before taking the next actions. Failure to install firmware updates may make machines ranging from laptops to servers to virtual machines fail to boot, triggering additional workload for your security staff.

You’ll need to first ensure that recovery media is up to date with fixed or patched media because if you need to reboot or recover the machine, you’ll need media that matches the system you are attempting to recover. Microsoft notes that at this time they have not tested all interactions with the mitigations with vendor configurations. As the note in the KB, “Please first test these mitigations on a single device per device class in your environment to detect possible firmware issues. Do not deploy broadly before confirming all the device classes in your environment have been evaluated.”

In my own firm, where I have machines with HP Sure start deployed, Microsoft notes that “these devices need the latest firmware updates from HP to install the mitigations. The mitigations are blocked until the firmware is updated.”

Is your firm prepared to know what level of bios is on each computer and what version level they are?

Next up, you need to be aware of where the Bitlocker recovery key is located. As noted in the KB, “Some devices may go into BitLocker recovery.” So, ensure that you have a process to look up and supply recovery keys where needed.

Next, you will have your security management teams perform the following steps. As you read through the provided guidance from Microsoft you will note how many times the machines will need to be rebooted — sometimes twice in a row — before proceeding to the next step. At this time you need to be testing and determining an efficient process. If you use config manager, I’ll recommend reviewing resources to assist you in the process.

It’s my opinion that this is not a process that can be done remotely in a fashion that will provide your teams with the necessary feedback to ensure it’s being carried out correctly. I predict that you may wish to perform these actions in a phased manner requesting that devices be swapped out over time.

The bottom line: review your hardware and your vendor specifications. You may decide to perform these steps as you change out hardware.

Certificate-based authentication changes on domain controllers

In February 2025, or later if Microsoft decides we are not ready for the change, Microsoft will put Full Enforcement mode in its hardening of certificate-based authentication (detailed in KB5014754). Once full enforcement mode is enabled, unless a certificate is strongly mapped, authentication will be denied.

At this time, you’ll want to be monitoring the audit logs on your domain controllers. Look for event 39 which will indicate issues.

For example, the error may say “The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a strong way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user through explicit mapping. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more.”

Windows Recovery Environment update for Windows 10

Back in January of 2024, Microsoft released KB5034441 which automatically applies Safe OS Dynamic Update (KB5034232) to the Windows Recovery Environment (WinRE) for Windows 10, version 21H2 and 22H2 on a running PC to address a security vulnerability that could allow attackers to bypass BitLocker encryption by using WinRE.

However, on computers with a smaller recovery partition, many of them failed to install the update. In order to properly install the patch, you had to manually increase the partition size through the use of third-party tools or scripting.

All three of these vulnerabilities need to be analyzed to see if you truly feel you are at risk. All of them introduce risk merely by following the recommended steps for deployment.

Will your vulnerability scanner flag these as needing action? Will these take resources and hours away from patching something that may actually be more impactful to your security stance?