Hackers backed by the North Korean government gained a major win when Microsoft left a Windows zero-day unpatched for six months after learning it was under active exploitation.
Even after Microsoft patched the vulnerability last month, the company made no mention that the North Korean threat group Lazarus had been using the vulnerability since at least August to install a stealthy rootkit on vulnerable computers. The vulnerability provided an easy and stealthy means for malware that had already gained administrative system rights to interact with the Windows kernel. Lazarus used the vulnerability for just that. Even so, Microsoft has long said that such admin-to-kernel elevations don’t represent the crossing of a security boundary, a possible explanation for the time Microsoft took to fix the vulnerability.
A rootkit “holy grail”
“When it comes to Windows security, there is a thin line between admin and kernel,” Jan Vojtěšek, a researcher with security firm Avast explained last week. “Microsoft’s security servicing criteria have long asserted that ‘[a]dministrator-to-kernel is not a security boundary,’ meaning that Microsoft reserves the right to patch admin-to-kernel vulnerabilities at its own discretion. As a result, the Windows security model does not guarantee that it will prevent an admin-level attacker from directly accessing the kernel.”
The Microsoft policy proved to be a boon to Lazarus in installing “FudModule,” a custom rootkit that Avast said was exceptionally stealthy and advanced. Rootkits are pieces of malware that have the ability to hide their files, processes, and other inner workings from the operating system itself and at the same time control the deepest levels of the operating system. To work, they must first gain administrative privileges—a major accomplishment for any malware infecting a modern OS. Then, they must clear yet another hurdle: directly interacting with the kernel, the innermost recess of an OS reserved for the most sensitive functions.
In years past, Lazarus and other threat groups have reached this last threshold mainly by exploiting third-party system drivers, which by definition already have kernel access. To work with supported versions of Windows, third-party drivers must first be digitally signed by Microsoft to certify that they are trustworthy and meet security requirements. In the event Lazarus or another threat actor has already cleared the admin hurdle and has identified a vulnerability in an approved driver, they can install it and exploit the vulnerability to gain access to the Windows kernel. This technique—known as BYOVD (bring your own vulnerable driver)—comes at a cost, however, because it provides ample opportunity for defenders to detect an attack in progress.
The vulnerability Lazarus exploited, tracked as CVE-2024-21338, offered considerably more stealth than BYOVD because it exploited appid.sys, a driver enabling the Windows AppLocker service, which comes pre-installed in the Microsoft OS. Avast said such vulnerabilities represent the “holy grail,” as compared to BYOVD.
In August, Avast researchers sent Microsoft a description of the zero-day, along with proof-of-concept code that demonstrated what it did when exploited. Microsoft didn’t patch the vulnerability until last month. Even then, the disclosure of the active exploitation of CVE-2024-21338 and details of the Lazarus rootkit came not from Microsoft in February but from Avast 15 days later. A day later, Microsoft updated its patch bulletin to note the exploitation.
It’s unclear what caused the delay or the initial lack of disclosure. Microsoft didn’t immediately have answers to questions sent by email.
Whatever the reason, the six-month wait gave Lazarus a much more efficient and stealthy way to install FudModule. Once in place, the rootkit allowed Lazarus to bypass key Windows defenses such as Endpoint Detection and Response, Protected Process Light—which is designed to prevent endpoint protection processes from being tampered with—and the prevention of reading memory and code injection by unprotected processes. Avast’s Vojtěšek explained:
From the attacker’s perspective, crossing from admin to kernel opens a whole new realm of possibilities. With kernel-level access, an attacker might disrupt security software, conceal indicators of infection (including files, network activity, processes, etc.), disable kernel-mode telemetry, turn off mitigations, and more. Additionally, as the security of PPL (Protected Process Light) relies on the admin-to-kernel boundary, our hypothetical attacker also gains the ability to tamper with protected processes or add protection to an arbitrary process. This can be especially powerful if lsass is protected with RunAsPPL as bypassing PPL could enable the attacker to dump otherwise unreachable credentials.
The researcher went on to write:
If an attacker, despite all of these hurdles, manages to exploit a zero-day vulnerability in a built-in driver, they will be rewarded with a level of stealth that cannot be matched by standard BYOVD exploitation. By exploiting such a vulnerability, the attacker is in a sense living off the land with no need to bring, drop, or load any custom drivers, making it possible for a kernel attack to be truly fileless. This not only evades most detection mechanisms but also enables the attack on systems where driver allowlisting is in place (which might seem a bit ironic, given that CVE-2024-21338 concerns an AppLocker driver).
While we can only speculate on Lazarus’ motivation for choosing this third approach for crossing the admin-to-kernel boundary, we believe that stealth was their primary motivation. Given their level of notoriety, they would have to swap vulnerabilities any time someone burned their currently used BYOVD technique. Perhaps they also reasoned that, by going beyond BYOVD, they could minimize the need for swapping by staying undetected for longer.
Vulnerability or not, patch ASAP
Independent researcher Kevin Beaumont called the company’s handling of the vulnerability “another clanger from Microsoft.”
Not all researchers are as critical. In an online interview, Will Dormann, a senior vulnerability analyst at security firm Analygence and a frequent Microsoft critic, said:
They could have a very good reason for why it might have been more complicated and required more engineering time to fix. On the other hand, it could have simply gotten prioritized underneath other more-pressing security fixes. And perhaps at play is Microsoft’s own public stance that admin-to-kernel is *not* a security boundary, so they could have legitimately gotten away with refusing to fix the issue at all if they wanted.
He went on to say that waits of six months to fix vulnerabilities are “common,” even though such delays may not be “acceptable.”
Since Microsoft isn’t explaining the reasons for the way it handled the patching of CVE-2024-21338, the world will likely never know. One thing that is clear: Now that the vulnerability is public, the risk of it being more widely exploited has grown. Windows users who have yet to patch should prioritize doing so.