Discovery of new UEFI rootkit exposes an ugly truth: The attacks are invisible to us

Researchers have unpacked a major cybersecurity find—a malicious UEFI-based rootkit used in the wild since 2016 to ensure computers remained infected even if an operating system is reinstalled or a hard drive is completely replaced.

The firmware compromises the UEFI, the low-level and highly opaque chain of firmware required to boot up nearly every modern computer. As the software that bridges a PC’s device firmware with its operating system, the UEFI—short for Unified Extensible Firmware Interface—is an OS in its own right. It’s located in an SPI-connected flash storage chip soldered onto the computer motherboard, making it difficult to inspect or patch the code. Because it’s the first thing to run when a computer is turned on, it influences the OS, security apps, and all other software that follows.

Exotic, yes. Rare, no.

On Monday, researchers from Kaspersky profiled CosmicStrand, the security firm’s name for a sophisticated UEFI rootkit that the company detected and obtained through its antivirus software. The find is among only a handful of such UEFI threats known to have been used in the wild. Until recently, researchers assumed that the technical demands required to develop UEFI malware of this caliber put it out of reach of most threat actors. Now, with Kaspersky attributing CosmicStrand to an unknown Chinese-speaking hacking group with possible ties to cryptominer malware, this type of malware may not be so rare after all.

“The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016—long before UEFI attacks started being publicly described,” Kaspersky researchers wrote. “This discovery begs a final question: If this is what the attackers were using back then, what are they using today?”

While researchers from fellow security firm Qihoo360 reported on an earlier variant of the rootkit in 2017, Kaspersky and most other Western-based security firms didn’t take notice. Kaspersky’s newer research describes in detail how the rootkit—found in firmware images of some Gigabyte or Asus motherboards—is able to hijack the boot process of infected machines. The technical underpinnings attest to the sophistication of the malware.

A rootkit is a piece of malware that runs in the deepest regions of the operating system it infects. It leverages this strategic position to hide information about its presence from the operating system itself. A bootkit, meanwhile, is malware that infects the boot process of a machine in order to persist on the system. The successor to legacy BIOS, UEFI is a technical standard defining how components can participate in the startup of an OS. It’s the most “recent” one, as it was introduced around 2006. Today, almost all devices support UEFI when it comes to the boot process. The key point here is that when we say something takes place at the UEFI level, it means that it happens when the computer is starting up, before the operating system has even been loaded. Whatever standard is being used during that process is only an implementation detail, and in 2022, it will almost always be UEFI anyway.

In an email, Kaspersky researcher Ivan Kwiatkowski wrote:

So a rootkit may or may not be a bootkit, depending on where it is installed on the victim’s machine. A bootkit may or may not be a rootkit, as long as it infected a component used for the system startup (but considering how low-level these usually are, bootkits will usually be rootkits). And firmware is one of the components which can be infected by bootkits, but there are others, too. CosmicStrand happens to be all of these at the same time: It has the stealthy rootkit capabilities and infects the boot process through malicious patching of the firmware image of motherboards.

The workflow of CosmicStrand consists of setting “hooks” at carefully selected points in the boot process. Hooks are modifications to the normal execution flow. They usually come in the form of additional code developed by the attacker, but in some cases, a legitimate user may inject code before or after a particular function to bring about new functionality.

The CosmicStrand workflow looks like this:

• The initial infected firmware bootstraps the whole chain.
• The malware sets up a malicious hook in the boot manager, allowing it to modify Windows’ kernel loader before it is executed.
• By tampering with the OS loader, the attackers are able to set up another hook in a function of the Windows kernel.
• When that function is later called during the normal startup procedure of the OS, the malware takes control of the execution flow one last time.
• It deploys a shellcode in memory and contacts the C2 server to retrieve the actual malicious payload to run on the victim’s machine.

Execution chain

The CosmicStrand execution chain starts with a driver. It appears to be a modification of a legitimate one called CSMCORE that creates a pointer to a boot service function known as HandleProtocol. Whenever HandleProtocol is called, the execution is redirected to attacker-supplied code that checks for certain criteria, including which component called it and specific bytes included in the return address.

Credit: Kaspersky

“This specific point in the execution was chosen because at this stage, the boot manager is loaded in memory but isn’t yet running,” Monday’s blog post explained. “CosmicStrand seizes this chance to patch a number of bytes in its Archpx64TransferTo64BitApplicationAsm."

This function gets called later during the normal bootup process. At that point, the Windows OS loader is also present in memory and is in turn modified. Archpx64TransferTo64BitApplicationAsm will then locate the OS loader function named OslArchTransferToKernel and add a hook to the end.

Before the Windows kernel begins running, CosmicStrand adds another hook, this time in the ZwCreateSection function. This step injects malicious shellcode into the image of a file named ntoskrnl.exe, as it’s stored in memory, and the first bytes of ZwCreateSection are overwritten to redirect to it. To make the code less conspicuous to security products, the researchers said, the attackers were careful to put the malicious code inside the “slack,” or leftover storage space, of ntoskrnl.exe file’s .text section.

The malware then appears to disable a protection called PatchGuard. When the Windows kernel starts and calls the hooked ZwCreateSection function while running normally, CosmicStrand regains control of the execution, restores the original code, and runs more malicious code.

From there, Monday's post explained:

All the steps described so far only served the purpose of propagating code execution from the UEFI down to the Windows kernel. This shellcode is the first actually malicious component of the chain so far. It sets up a thread notify routine that gets invoked each time a new thread is created. CosmicStrand waits until one turns up in winlogon.exe and then executes a callback in this high-privilege context.

There, CosmicStrand sleeps for 10 minutes and tests the Internet connectivity of the infected machine. CosmicStrand doesn’t rely on high-level API functions to generate network traffic, but instead interacts directly with the Transport Device Interface: It generates the needed IRPs (I/O request packets) and passes them to the network stack by sending IOCTLs to the TCP or UDP device object. DNS requests are performed in this fashion, using either Google’s DNS server (8.8.8[.]8) or a custom one (222.222.67[.]208).

CosmicStrand retrieves its final payload by sending a specifically crafted UDP (preferably) or TCP packet to its C2 server, update.bokts[.]com. The reply is expected to return in one or several packets containing chunks of 528 bytes following this structure:

Offset (bytes)	Description
0-4	Magic number
4-8	Total length of the payload
8-12	Length of the current chunk
12-16	CRC32 checksum of the current chunk
16-*	Payload chunk

The various chunks are reassembled into a series of bytes that are mapped into kernel space and interpreted as a shellcode. Unfortunately, we were not able to obtain a copy of data coming from the C2 server. We did, however, find a user-mode sample in-memory on one of the infected machines we could study and believe it is linked with CosmicStrand. This sample is an executable that runs command lines in order to create a user (“aaaabbbb”) on the victim’s machine and add it to the local administrators group.

Credit: Kaspersky

We can infer from this that shellcodes received from the C2 server might be stagers for attacker-supplied PE executables, and it is very likely that many more exist.

Here’s a graph summarizing the flow:

A brief history of UEFI rootkits

Kaspersky believes that this variant was active in 2020 and that an earlier version saw use between 2016 and mid-2017 and that both were written by Chinese-speaking developers. The command and control servers used by both variants used domain names that remained dormant for long stretches of time, during which the rootkit would be inoperable. Company researchers believe that means that while CosmicStrand was designed to persist permanently on computers, the actual exploitation of those machines may not have lasted for more than a few months. Then again, the researchers said it may have been possible that the domains were periodically reactivated for short durations.

Kaspersky detected the rootkit running on computers in China, Vietnam, Iran, and Russia. All victims were running Kaspersky’s free product, an indication that targets may have been private individuals. Company researchers have been unable to identify any specific organizations or even industry verticals that were infected. Researchers so far have been unable to determine the entry point that allows the rootkit to get installed in the first place. Qihoo360’s report speculated that one infection may have been the result of a backdoored motherboard ordered at a second-hand reseller, but so far Kaspersky has been unable to confirm that.

Credit: Kaspersky

Some of the components in the rootkit are identical to ones found in the malware family belonging to MyKings, a botnet used to deploy cryptominers that was documented in 2020 by security firm Sophos. Sophos also found the presence of Chinese-language artifacts. In another tie to China, albeit a lower-confidence one, Kaspersky also found CosmicStrand used a hardcoded fallback DNS server located at CHINANET-BACKBONE (AS4134).

To date, known instances of UEFI malware are extremely limited. The first one to come to light was LoJax, a maliciously modified version of the LoJack antitheft product that was used by Fancy Bear, a Kremlin-backed hacking group. The malware, which was used around 2017, was discovered by security firm ESET in 2018.

Discoveries of UEFI rootkits since then include:

• MosaicRegressor, which was used around 2017 by a Chinese-speaking threat actor who used a command server that had been used in the past by a malicious backdoor from “Winnti Umbrella,” a prolific set of threat actor groups that the researchers said operates on behalf of the Chinese government.
• ESpecter, a bootkit persisting in the EFI System Partition that can bypass Windows Driver Signature Enforcement to load its own unsigned driver.
• FinSpy, a UEFI component belonging to the FinFisher surveillance toolset. Although researchers have tracked the spy tool since at least 2011, the bootkit didn’t surface until 2021.
• MoonBounce, which was discovered in January and attributed to APT41, or an actor closely affiliated to the group, which researchers say is part of the Winnti Umbrella.

It’s notable that all of the UEFI rootkits known to date have been discovered by just three firms. ESET identified LoJax in 2018 and ESpector last year. Qihoo360 spotted CosmicStrand in 2017. And Kaspersky found FinSpy, MosaicRegressor, and Moonbounce in 2020, 2021, and 2022, respectively. Kaspersky also independently discovered CosmicStrand. In Monday’s report, the Kaspersky researchers warned that “the multiple rootkits discovered so far evidence a blind spot in our industry that needs to be addressed sooner rather than later.”