In February 2022, the extortion group LAPSUS$ breached NVIDIA’s systems and stole approximately 1 terabyte of data, including two of the company’s code-signing certificates. When NVIDIA refused to pay a ransom, LAPSUS$ published the stolen data, certificates included. Within roughly one day, malware signed with NVIDIA’s own certificates began appearing on VirusTotal, the malware-scanning platform security researchers use to track new threats.
The certificates had expired years earlier. That should have made them worthless to attackers. It did not, because of a deliberate, long-standing Windows design choice that the incident exposed to a much wider audience than ever intended it.
The Breach: LAPSUS$ and NVIDIA’s Refused Ransom
LAPSUS$ was an extortion-focused cybercrime group active in early 2022, responsible for breaches at several other organizations around the same period, including Portugal’s largest media conglomerate Impresa and Brazil’s Ministry of Health. The group explicitly stated it was not state-sponsored and was not politically motivated, describing itself as purely financially driven.
NVIDIA’s breach, which the group claimed began around February 23, 2022, resulted in the exfiltration of approximately 1 terabyte of data, reportedly including hardware schematics, firmware source code, internal drivers, employee email accounts, and NTLM password hashes for more than 71,000 NVIDIA employees. NVIDIA declined to negotiate a ransom payment. LAPSUS$ responded by publishing the stolen data on a leak site beginning around March 1, 2022.
The Two Certificates and Why They Mattered
Among the leaked files were two NVIDIA code-signing certificates, the cryptographic credentials NVIDIA’s own developers used to sign legitimate drivers and executables before release. A code-signing certificate exists specifically to give users and operating systems cryptographic proof that a piece of software came from the claimed publisher and has not been tampered with since signing.
The two certificates had expiry windows of 2011 to 2014 and 2015 to 2018, meaning both were already years past their validity period by the time of the 2022 leak. Under normal circumstances, an expired certificate cannot be used to produce a new, validly-trusted signature, because certificate validation explicitly checks whether the signing certificate was valid at the time of signing.
The Counterintuitive Part: Why Expired Certificates Still Worked
Windows has a long-standing, deliberate compatibility behavior for kernel-mode drivers: a driver signed with a certificate that was valid at the time the signature was applied continues to be accepted by Windows even after that certificate later expires, provided the signature includes a trustworthy timestamp proving when the signing actually occurred. This exists because constantly forcing every legitimately signed driver in the world to be re-signed the moment the original publisher’s certificate expires would be operationally impossible. Hardware and driver publishers sign things once; those drivers need to keep working on customer machines for years afterward, long after the original certificate’s validity window closes.
This is not a bug. It is a backward-compatibility tradeoff Windows made deliberately, and it works correctly for its intended purpose: keeping legitimately signed, years-old drivers functional. The problem in NVIDIA’s case is that the attackers had something no ordinary expired-certificate scenario assumes anyone but the original publisher has: the actual private key paired with that certificate, stolen directly from NVIDIA. With the private key in hand, LAPSUS$ (or whoever distributed the certificates after the leak) could produce new signatures using NVIDIA’s expired certificate that Windows would still treat as legitimately signed, because the validation mechanism Windows uses was never designed to anticipate the original certificate holder’s private key being stolen and reused by someone else entirely.
The lesson is precise and important: this incident did not reveal a flaw in how Windows handles expired certificates in general. It revealed what happens when an attacker obtains the private key behind a certificate that benefits from this specific backward-compatibility exception. Windows correctly trusted a properly formed signature using NVIDIA’s certificate, exactly as designed, because Windows has no way to know the entity producing that signature was no longer NVIDIA. The vulnerability is entirely about private key custody and revocation speed, not about a hole in Windows’ driver-signing logic.
What Malware Was Actually Signed With the Stolen Certificates
Security researchers tracking VirusTotal submissions found the stolen NVIDIA certificates used to sign a range of malicious tools within days of the leak:
- Mimikatz: a well-known credential-dumping and lateral-movement tool used by attackers to extract passwords and authentication tokens from compromised Windows systems, commonly used to expand access after an initial breach.
- Cobalt Strike beacons: components of Cobalt Strike, a legitimate penetration-testing framework that is also one of the most widely abused tools in real-world cybercrime and ransomware operations, used here to establish persistent command-and-control access on compromised machines.
- Quasar Remote Access Trojan (RAT): a remote access tool that gives an attacker hands-on control of an infected machine, signed with one of the stolen certificates to help it pass as legitimate software.
- At least one actual Windows driver: researchers identified a malicious kernel-mode driver signed with a stolen certificate, which is the specific, highest-stakes category this incident enabled: kernel drivers run with the highest level of system privilege, and Windows’ driver-signing requirement exists specifically to prevent unsigned or untrusted code from running at that level.
Signing malware with a trusted vendor’s certificate provides two separate benefits to an attacker: it can help malicious files pass signature-based detection in some antivirus and endpoint protection tools that treat signed files with more leniency, and it allows kernel-mode drivers, which Windows otherwise blocks from loading without a valid signature, to load and run with full system privileges.
Microsoft’s Response and Its Practical Limits
On March 3, 2022, David Weston, Microsoft’s director of enterprise and OS security at the time, publicly advised that administrators could configure Windows Defender Application Control (WDAC) policies to block specific NVIDIA driver certificates or restrict which driver versions were allowed to load, as an interim mitigation.
Security researchers and outlets covering the incident, including BleepingComputer, noted this was not a realistic fix for the average Windows user. WDAC policy configuration requires specific administrative knowledge and is not something most home users or even many small business IT environments are equipped to do confidently. The more durable, structural fix is for the relevant Certificate Authority to add the compromised certificates to its Certificate Revocation List (CRL), which operating systems and security software can check against without requiring any end-user configuration. A compromised certificate can only be revoked by its issuing CA, not by the victim organization unilaterally, which means the timeline for a full fix depends on the CA’s revocation process, not just NVIDIA’s or Microsoft’s response speed.
Revocation has a real-world limitation worth understanding: Certificate Revocation Lists and OCSP (Online Certificate Status Protocol) checks depend on the validating system actually checking revocation status at the time a signature is evaluated. Some systems, some configurations, and some offline scenarios do not perform live revocation checks, which means a revoked certificate can in some circumstances still be accepted by a system that simply never checked whether it had been revoked. This is part of why certificate compromise incidents like this one can have a long tail of residual risk even after the CA formally revokes the certificate.
Why Code-Signing Certificate Compromise Is a Categorically Different Risk
Most certificate compromise scenarios discussed in security contexts involve SSL/TLS certificates, where the consequence is typically that a connection can be intercepted or impersonated, serious but generally limited to network traffic. Code-signing certificate compromise is different in kind: it weaponizes the specific trust mechanism users and operating systems rely on to distinguish legitimate software from malware. A user who sees a file signed by NVIDIA has every reasonable expectation that the file came from NVIDIA. The entire value of code signing as a security control depends on that expectation holding.
This is why private key protection for code-signing certificates carries a higher operational bar than for most SSL/TLS certificates. Industry practice has shifted in the years following incidents like this toward requiring code-signing private keys to be stored in Hardware Security Modules (HSMs), physical or cloud-based devices specifically designed so the private key material can never be extracted in usable form, even by someone with direct access to the system. CA/B Forum requirements for code signing certificates have moved toward mandating HSM-backed key storage rather than allowing private keys to be stored as ordinary files on a developer’s workstation, precisely because incidents like NVIDIA’s demonstrated how catastrophic a stolen private key can be when paired with a still-recognized certificate.
For organizations issuing or managing code-signing certificates today, the operational takeaway from this incident is specific: code-signing private keys should never be stored as exportable files on general-purpose servers or developer workstations. EV Code Signing certificates, which require hardware token or HSM-based private key storage as part of the CA/B Forum’s Baseline Requirements for code signing, exist specifically to make the kind of bulk private key exfiltration that happened to NVIDIA structurally much harder to replicate, since the key material itself is designed to never leave the hardware device in a usable, extractable form.
Frequently Asked Questions
Could this happen with an SSL/TLS certificate instead of a code-signing certificate?
The specific mechanism that made NVIDIA’s stolen certificates valuable, Windows’ tolerance of expired certificates for previously-signed drivers, is specific to code-signing and driver-signing validation logic, not SSL/TLS certificate validation. A stolen SSL/TLS certificate and its private key would let an attacker impersonate a website for the remaining validity period of that specific certificate, but browsers do not have an equivalent ‘accept it anyway if it was valid at signing time’ exception for expired website certificates the way Windows does for drivers. The core lesson, that a stolen private key remains dangerous regardless of certificate expiry status until properly revoked, applies to any certificate type, but the specific exploitation mechanism in this incident was particular to code signing and Windows driver trust.
Were NVIDIA’s customers ever at direct risk from this, or was it only a risk to other systems running the malware?
The risk to NVIDIA’s actual customers was indirect: the stolen certificates did not give attackers any ability to modify or compromise NVIDIA’s real, currently distributed drivers. The risk was that a user could be tricked into downloading and running an entirely different, malicious file that appeared to be signed by NVIDIA, making it seem more trustworthy than an unsigned or unknown-publisher file would. The danger was reputational and trust-based: the malware was not actually NVIDIA software at all, it was malware wearing NVIDIA’s signature as cover, distributed through whatever channels the attackers chose, not through NVIDIA’s own distribution infrastructure.
Has this kind of stolen code-signing certificate incident happened to other companies?
Yes, this is a recurring category of incident rather than an isolated one. Stolen or fraudulently obtained code-signing certificates have been used to sign malware in multiple other documented incidents over the years involving various organizations, which is part of why the industry’s shift toward mandatory HSM-backed key storage for code-signing certificates has accelerated. The NVIDIA case is among the most widely cited examples specifically because of the scale of the breach, the prominence of the company, and the unusually clear demonstration of the expired-certificate-still-works mechanism, which made it an effective and frequently referenced teaching example in security research and training.
——————————————————-
Sources: BleepingComputer, ‘Malware now using NVIDIA’s stolen code signing certificates’ (March 3, 2022; primary reporting, breach timeline, certificate validity dates, Microsoft WDAC response); Malwarebytes / ThreatDown, ‘Stolen Nvidia certificates used to sign malware, here’s what to do’ (March 2022, updated May 2024; certificate validity periods 2011-2014 and 2015-2018, Windows expired-certificate driver acceptance behavior); Threatpost, ‘NVIDIA’s Stolen Code-Signing Certs Used to Sign Malware’ (March 7, 2022; Mimikatz detection, breach scale, employee data details, LAPSUS$ statements); TechRadar, ‘Stolen Nvidia code signing certificates used to sign off malware’ (March 2022; LAPSUS$ prior incidents at Impresa and Brazil’s Ministry of Health); Heimdal Security, ‘Malware Made Look Trustworthy through Stolen NVIDIA Code Signing Certificates’ (December 2022; Cobalt Strike and Quasar RAT signing confirmation, malicious driver identification, researcher attribution to Kevin Beaumont and Will Dormann).
