The National Security Agency (NSA) is urging organizations to harden their systems against BlackLotus UEFI bootkit malware, warning there is “significant confusion” and a “false sense of security” regarding the threat it poses.
BlackLotus, first observed in October last year, has powerful features including the ability to disable Windows Defender, BitLocker, and Hypervisor-protected Code Integrity. The malware is also capable of infecting Windows machines with Secure Boot enabled, exploiting a known vulnerability (CVE-2022-21894) called Baton Drop.
Microsoft addressed the additional Baton Drop vulnerability (CVE-2023-24932) last month, issuing a fix as part of May’s patch Tuesday. But while the new patch provides configuration options to manually enable protections against the vulnerability, they are not enabled automatically. According to Microsoft, system administrators need to verify all their devices and bootable media are updated and ready for the patch before enabling the new protections.
In a cybersecurity information sheet (PDF) released on Thursday, the NSA said the confusion over BlackLotus resulted in some organizations believing it was an unstoppable, unpatchable threat while others thought they were safe because they had applied the two patches Microsoft had issued.
“The risk exists somewhere between both extremes,” the information sheet said.
“NSA believes that currently published patches could provide a false sense of security for some infrastructures. Because BlackLotus integrates Shim and GRUB into its implantation routine, Linux administrators should also be vigilant for variants affecting popular Linux distributions.”
Targeting a flaw in older boot loaders
BlackLotus targets Windows boot by exploiting a flaw in older boot loaders, or boot managers, to set off a chain of malicious actions that compromise endpoint security. This is achieved by exploiting the Baton Drop vulnerability to strip the Secure Boot policy and prevent its enforcement.
BlackLotus shares some characteristics with Boot Hole, a vulnerability discovered in 2020. Unlike Boot Hole, however, BlackLotus targets vulnerable boot loaders that have not been added to the Secure Boot Deny List Database (DBX) revocation list.
“Because the vulnerable boot loaders are not listed within the DBX, attackers can substitute fully patched boot loaders with vulnerable versions to execute BlackLotus,” the NSA wrote.
“Administrators should not consider the threat fully remediated as boot loaders vulnerable to Baton Drop are still trusted by Secure Boot.”
As a result, a malicious actor exploiting Baton Drop could bypass Secure Boot and compromise the device.
Tips for defending against BlackLotus
Zachary Blum, the NSA’s Platform Security Analyst, said protecting systems against BlackLotus was not a simple fix.
“Patching is a good first step, but we also recommend hardening actions, dependent on your system’s configurations and security software used,” he said.
The NSA’s information sheet recommends enabling the new optional protections provided in Microsoft’s May patch, including mitigations to prevent rollback of the boot manager and kernel to versions vulnerable to Baton Drop and BlackLotus.
“The optional mitigations – including a Code Integrity Boot Policy – should be enabled after the organization has updated its Windows installation, recovery, and diagnostic software to the latest available versions,” the information sheet says.
Because BlackLotus operates by placing an older Windows boot loader Extensible Firmware Interface (EFI) binary into the boot partition, and disabling Memory Integrity and BitLocker, the NSA recommends configuring endpoint security products to block these events outside of a legitimate, scheduled update.
“Configure defensive software to scrutinize changes to the EFI boot partition in particular. Alternatively, leverage application allow lists to permit only known and trusted executables.”
It also recommends configuring endpoint security products and tools to monitor the composition of the EFI boot partition. “Leverage these tools to look for unexpected changes in bootmgfw.efi, bootmgr.efi, or the introduction of additional unexpected EFI binaries (e.g., shimx64.efi or grubx64.efi). Changes to the boot partition are infrequent and warrant additional scrutiny.”
