Getty Images
In July, security researchers revealed a sobering discovery: hundreds of pieces of malware used by multiple hacker groups to infect Windows devices had been digitally signed and validated as safe by Microsoft itself. On Tuesday, a different set of researchers made a similarly solemn announcement: Microsoft’s digital keys had been hijacked to sign yet more malware for use by a previously unknown threat actor in a supply-chain attack that infected roughly 100 carefully selected victims.
The malware, researchers from Symantec’s Threat Hunter Team reported, was digitally signed with a certificate for use in what is alternatively known as the Microsoft Windows Hardware Developer Program and the Microsoft Windows Hardware Compatibility Program. The program is used to certify that device drivers—the software that runs deep inside the Windows kernel—come from a known source and that they can be trusted to securely access the deepest and most sensitive recesses of the operating system. Without the certification, drivers are ineligible to run on Windows.
Hijacking keys to the kingdom
Somehow, members of this hacking team—which Symantec calls Carderbee—managed to get Microsoft to digitally sign a type of malware known as a rootkit. Once installed, rootkits become what’s essentially an extension of the OS. To gain that level of access without tipping off end-point security systems and other defenses, the Carderbee hackers first needed its rootkit to receive the Microsoft seal of approval, which it got after Microsoft signed it.
With the rootkit signed, Carderbee went on to pull another audacious feat. Through means that aren’t yet clear, the group attacked the infrastructure of Esafenet, a China-based developer of software, known as the Cobra DocGuard Client, for encrypting and decrypting software so it can’t be tampered with. Then, Carderbee used its newfound control to push malicious updates to roughly 2,000 organizations that are Cobra DocGuard customers. Hacking group members then pushed the Microsoft-signed rootkit to roughly 100 of those organizations. Representatives with Esafenet and its parent company, NSFOCUS, didn't respond to an email asking for verification.
“It seems clear that the attackers behind this activity are patient and skilled actors,” Symantec researchers wrote. “They leverage both a supply chain attack and signed malware to carry out their activity in an attempt to stay under the radar. The fact that they appear to only deploy their payload on a handful of the computers they gain access to also points to a certain amount of planning and reconnaissance on behalf of the attackers behind this activity.”
Microsoft put the mandatory program in place with the launch of Windows 10. Attackers had long used drivers in post-exploit activities, meaning after hacking a system and gaining administrative access. While attackers could already install apps, steal passwords, and take other liberties, running code in the kernel allowed them to do things that would otherwise be impossible. For example, they could suppress warnings from endpoint detection and response systems and other defenses. Effective from then on, drivers that needed kernel access had to be digitally signed.
Carderbee’s use of Microsoft certificates to sign its malware is by no means an isolated incident. In July, security firm Sophos reported its discovery of 133 malicious drivers, 100 of which had been digitally signed by Microsoft and the remaining ones by other trusted parties that went unnamed. The signings dated as far back as April 2021. In December, Sophos reported its discovery of another malicious driver signed by Microsoft.
The Sophos July report coincided with related posts from security firm Trend and Microsoft. Trend said it had unearthed newly discovered malware that came as a standalone kernel driver signed directly by Microsoft through its hardware compatibility program. Compromised signatures are “an evolving attack vector that has been frequently appearing in today’s malware landscape,” Trend researchers wrote. “Despite how complex [it] is to build such capabilities, it seems that current malicious actors are exhibiting competence and consistent usage of such tools, tactics, and procedures (TTPs), regardless of their final motive and objectives.”
Microsoft, meanwhile, published a post that said the malicious signings were the result of “several developer accounts for the Microsoft Partner Center… engaged in submitting malicious drivers to obtain a Microsoft signature.” All developer accounts involved, Microsoft said, were immediately suspended once they were caught. The company also added signed malicious drivers to a block list. (Last year, researchers showed that despite repeated Microsoft assertions to the contrary, the block list failed to work.)
If at first you don’t succeed, fail, fail again
Microsoft’s July statement was almost a verbatim copy of one it issued last December, after being told two months earlier by security firms SentinelOne, Mandiant, and Sophos of similar abuse of its driver-signing program. The process of obtaining a signature is also known as attestation. It requires the party applying to sign their software with what’s known as an extended validation certificate, a type of digital credential that verifies the party’s identity.
In a post titled I Solemnly Swear My Driver Is Up to No Good: Hunting for Attestation Signed Malware, Mandiant researchers wrote:
Mandiant has continually observed threat actors use compromised, stolen, and illicitly purchased code-signing certificates to sign malware, lending legitimacy and subverting security controls such as application allow-listing policies. Attestation signed drivers take the trust granted to them by the CA and transfers it to a file whose Authenticode signature originates from Microsoft itself. We assess with high confidence that threat actors have subverted this process using illicitly obtained EV code signing certificates to submit driver packages via the attestation signing process, and in effect have their malware signed by Microsoft directly.
Mandiant said that the drivers were signed directly by Microsoft and required an inspection with code of the underlying signature to identify the software developer who applied for it. The security firm added that the Microsoft signatures appeared on “several distinct malware families associated with distinct threat actors” and involved at least nine unique organization names. Key among the signed malware were those tracked as Poortry and Stonestop, both of which were used to terminate antivirus and endpoint detection processes on infected systems.
In their own post, SentinelOne researchers theorized on the possible ways the Microsoft signing process kept getting hijacked:
We are highly confident that the malicious drivers mentioned above, as well as the one from June 2021, were used by different threat actors. This raises an important question: Is the driver signing process being exploited by a supplier(s) and offered as a service available to various threat actors willing to pay?
A competing theory is that multiple threat actors have compromised legitimate driver developers and surreptitiously used their EV certificate to sign and submit the malicious drivers using their developer account. However, this scenario is less likely due to the requirement that EV private keys be stored on a physical hardware token intended to help prevent digital theft.
Other evidence supporting the ‘supplier’ theory stems from the similar functionality and design of the drivers. While they were used by two different threat actors, they functioned in very much the same way. This indicates they were possibly developed by the same person then subsequently sold for use by someone else.
There are still more reported incidents of Microsoft signing malicious wares. In June 2021, for instance, the company gave its digital imprimatur to a driver with the innocuous name Netfilter. A researcher from security firm G Data later discovered it was a rootkit that decrypted encrypted communications, most likely to eavesdrop on SSL communications.
In recent months, Microsoft has come under blistering criticism for security practices that led to the breach of dozens of accounts belonging to customers using the company's Azure and Exchange cloud offerings. What’s arguably worse has been the company’s opaque notifications of those events and the role Microsoft played in their origins. The CEO and chairman of security firm Tenable, Amit Yoran, recently said the company’s security was mired in “grossly irresponsible” practices and a “culture of toxic obfuscation.”
Those same dynamics are at play in Microsoft’s recent failures in policing the processes it put in place for digitally certifying trustworthy Windows drivers. The near-verbatim advisories mentioned earlier—one from last December and the other from last month—illustrate that whatever the company has been doing to lock down the program isn’t working. They also show how the company relies on vague and ambiguous notifications that aim to conceal as much as inform.
Microsoft’s driver-signing requirement is founded on a concept known as security in depth. The idea is to have multiple layers of security so that if one fails, another will prevent a breach or at least contain the damage. In this case, certificates are a hedge designed to lessen the harm that comes when an adversary gains administrative system rights to a compromised device.
Virtually all of the key-hijacking incidents reported in recent years have been attributed to Chinese hackers, usually for espionage purposes. Microsoft’s string of failures in locking down its certification program, and its reticence when disclosing them, are undermining the entire concept of security, much to the delight of these adversaries.
0 Comments