Why you might not be done with your January Microsoft security patches

The January patching window for your firm has probably come and gone. But has it? While January included a huge release of patches, several releases in other months have provided more than one headache for the patch management community. These are the patches and updates you need to evaluate if you haven’t already done so.

BitLocker Security Feature Bypass Vulnerability

In January, additional information came out about CVE-2022-41099, the BitLocker Security Feature Bypass Vulnerability. If you’ve already deployed the November or later security updates to your network and have done nothing else, you aren’t done with the evaluation of this update.

First, you need to determine your risk level. For this attack to be successful, the attacker needs physical access to your computer. There is much less risk for devices that have physical security and are locked or stored securely. If you have disabled the Windows Recovery Environment (WindRE) partition because you have alternative means to recover and reimage your devices, you are also not at risk. If you are somewhere in the middle you’ll need to determine if you need to take action.

Patching is not enough. You must also apply the applicable Windows security update to your WinRE. Besides disabling the recovery partition, you could also use a GitHub script to update the WinRE for this vulnerability and ensure it is patched appropriately. Additional discussions describe the potential for additional attack sequences, but it appears at this point to be an attack sequence that leads us back to theoretical attacks rather than proven attack sequences as well as remembering the long-standing Immutable Law of Security #3: If a bad actor has unrestricted physical access to your computer, it’s not your computer anymore.

Kerberos hardening updates

Many administrators are still evaluating the impact of the November Kerberos hardening updates. Any patch installed on your domain controller that includes the November or later updates will have potential impact on your domain. To be proactive the following is recommended:

First, determine if these updates will impact your domain. A PowerShell script is available to detect potential authentication issues that may occur in an Active Directory (AD) domain after installing these updates. As noted, “Run the script in PowerShell with domain administrator privileges from a machine with AD RSAT tools installed, such as on a domain controller. The script will output any detected compatibility issues found in the domain related to changes made for CVE-2022-37966.”

As noted in a Microsoft blog, the November updates caused issues with authentication, and Microsoft released an out-of-band update to fix the issue. Many patching administrators skipped over both the November and December updates waiting for issues to shake out.

Next, if you can’t remember the last time your organization changed the password to the Kerberos account (Krbtgt account), then you are long overdue to run this script to do so. There are various modes for the script, and it’s recommended to run it in this order:

1. Mode 1: Informational mode (no changes at all)
2. Mode 8: Create TEST KrbTgt accounts
3. Mode 2: Simulation mode (temporary canary object created, no password reset)
4. Mode 3: Simulation mode — Use KrbTgt TEST/BOGUS accounts (password will be reset once)
5. Mode 4: Real reset mode — Use KrbTgt PROD/REAL accounts (password will be reset once)
6. Mode 9: Cleanup TEST KrbTgt accounts (could be skipped to reuse accounts the next time)

It’s recommended to change the Krbtgt password twice, waiting 24 hours between each change before changing it the second time. This is also the recommended process if you have a compromised Active Directory. It’s also recommended to reset all administrator and service account passwords twice.

If you only reset the password once:

• After first reset, the new KRBTGT password replicates to all the DCs in the domain.
• All new tickets will use the new password (KRB1).
• Old tickets issued by old KRBTGT password (KRBOLD) should continue to work as password history is 2.
• Post old tickets expiry they should renew tickets with new KRBTGT password (KRB1).
• Present KRBTGT passwords will be KRB1 and KRBOLD.

When you reset the password twice, wait for 24 hours to pass:

• After second reset new KRBTGT password replicates to all the DCs in the domain.
• All new tickets will use the new password (KRB2).
• Old tickets issued by old KRBTGT password (KRB1) should continue to work as password history is 2.
• Present KRBTGT passwords will be KRB1 and KRB2.
• Post old tickets expiry they should renew tickets with new KRBTGT password (KRB2).
• Old KRBTGT password (KTB old) not valid anymore as password history is of 2.

These Kerberos updates are only in audit mode now and will be enforced later. The December 13 updates have added auditing events. If you are not seeing any such events in your event logs, you should be able to implement the hardening mode in advance by setting the KrbtgtFullPacSignature registry setting or waiting for the enforcement phases. As Microsoft notes, in July 2023 the default setting will be enforced.

You want to look for events now before the new settings are enforced. To do so, open the system event log and filter as follows:

Susan Bradley

While not enforced at this time, the impact on legacy systems should be investigated. You may need to have your team open support cases to discuss the impact and options with Microsoft. After this patch is enforced, all legacy operating systems will fail to authenticate via Kerberos.

The impact of these two patching-related issues is not immediate. You have time for your team to investigate. Don’t wait too long or expect Microsoft to roll back the impact on these two patches. Both are certain to create more work for your BitLocker and AD teams.