The Microsoft Signed Rootkit Malware That Can Decrypt All Encrypted Communications

In June 2021, a security researcher found that Microsoft had digitally signed a kernel-mode rootkit. The driver, called “Netfilter,” passed through Microsoft’s own hardware certification pipeline, then redirected network traffic and planted a rogue trusted root certificate on infected machines, the kind of certificate that underlies trust in encrypted communications. This article lays out exactly what Netfilter did, what it did not do, and what the incident still teaches security and PKI teams about driver-signing trust today.

Published: September 2022. Updated: August 2026. Reviewed by Encryption Consulting’s PKI and Code Signing Advisory team.

What Happened in the Netfilter Rootkit Incident?

Karsten Hahn, a malware researcher at the security firm G Data, spotted a driver flagged by his company’s detection system that carried a valid Microsoft digital signature. The first instinct was to treat the alert as a false positive, since Microsoft had signed the file under its Windows Hardware Compatibility Program (WHCP). Hahn kept digging anyway. The oldest known sample of the driver dated back to March 2021, and further analysis showed it behaved like a rootkit rather than a legitimate network filter. Hahn shared his findings publicly and contacted Microsoft directly.

On June 25, 2021, Microsoft’s Security Response Center confirmed the report. A third-party developer had submitted the driver, named “Netfilter,” for certification through WHCP, and Microsoft’s signing pipeline had approved it. BleepingComputer and Ars Technica both covered the confirmation the same week, and their reporting, together with G Data’s original analysis, is the primary factual basis for this article.

What Netfilter actually did, based on G Data’s reverse engineering and follow-up reporting, was narrower than the incident’s reputation suggests:

• Redirected specified network traffic to attacker-controlled IP addresses, including a command-and-control (C2) host observed at 110.42.4.180:2081, with redirection traffic routed toward 45.248.10.244:3000.
• Wrote a new certificate into the Windows registry path for trusted root certificates, effectively adding a rogue certificate authority (CA) to the machine’s trust store.
• Could set a new system proxy and modify local internet settings without user consent.
• Carried self-update logic, checking in with its C2 server and replacing its own binary when a newer version was available.

The C2 infrastructure exposed a small set of URL paths, each with a distinct job:

• /p, associated with proxy settings
• /s, encoded redirection IP addresses
• /h?, used to fingerprint the CPU ID
• /c, delivered the rogue root certificate
• /v?, handled the malware’s self-update functionality

Multiple outlets reported the actor’s likely goal as targeting gamers, largely in China, so they could spoof their geolocation and bypass regional restrictions or play on servers they were not authorized for. Some reporting also described keylogging behavior tied to account compromise. Neither G Data’s original analysis nor the follow-up press coverage documented a large-scale, verified capability to intercept or decrypt “all” encrypted traffic on an infected machine, let alone across the internet.

How Did Netfilter Abuse Microsoft’s Driver-Signing Trust Model?

Windows requires kernel-mode drivers to carry a valid Microsoft signature before they will load on modern 64-bit systems. That requirement exists precisely to stop unsigned or tampered code from running with the highest level of OS trust. WHCP is the certification path hardware and driver vendors use to get that signature: a partner submits a driver, Microsoft’s pipeline tests and signs it, and the resulting Microsoft signature tells every Windows machine the driver is safe to load.

Netfilter did not exploit a flaw in Microsoft’s cryptography or steal a private key. The attacker used a registered WHCP partner account, submitted a driver that passed automated testing, and received a legitimate signature for malicious code. Microsoft’s own investigation, described in its statement at the time, found no evidence that its signing certificate or WHCP signing infrastructure had been compromised. The company suspended the submitting account, reviewed other submissions from the same partner for additional malware, added Netfilter detection to Microsoft Defender, and shared indicators with other antivirus vendors.

This is the core lesson for code-signing programs of any kind, not just Microsoft’s: a signing pipeline is a trust decision about the submitter, not a scan for malicious intent. If the vetting around who can submit code, and what testing that code goes through, has a gap, a valid signature can end up on malicious content without anyone breaking the underlying cryptography. No CVE was ever assigned to this incident, because it was not a vulnerability in Windows code. It was a process and identity-vetting failure in a supply chain that Windows depends on for trust.

Could Netfilter Really “Decrypt All Encrypted Communications”?

This is the claim in the title, and it deserves a precise answer: no, not as a literal, demonstrated capability. What the public record supports is narrower and still worth taking seriously.

Netfilter’s confirmed capability was installing a rogue root certificate into the Windows trusted root store. That matters because Windows and most browsers decide whether a TLS connection is trustworthy by checking whether the certificate presented by a server chains up to a CA in that trust store. If an attacker can add their own CA to the store, they can issue certificates for any domain, and the OS will accept them as valid. Combined with Netfilter’s traffic-redirection and proxy-setting behavior, that gives an attacker the pieces needed to run a man-in-the-middle (MITM) attack, intercepting and re-encrypting TLS-protected traffic that the attacker actually routes through their own infrastructure.

That is meaningfully different from a claim that the malware could decrypt all encrypted communications, anywhere, without redirecting them first. Reporting from G Data, BleepingComputer, and TheHackerNews describes Netfilter redirecting specific traffic, tied to gaming and geolocation spoofing, not silently decrypting arbitrary encrypted sessions across the internet. The rogue root certificate is the mechanism that makes broader TLS interception possible in principle; it is not itself proof that the attacker used it that way at scale.

Read this title as describing an attack mechanism, a rogue trusted root certificate that can enable TLS interception on redirected traffic, rather than a proven, unlimited decryption capability. That distinction matters for accurate incident response and for anyone citing this case as a reference point.

What Is a Rootkit, and Why Does the Root Certificate Matter?

A rootkit is malware built to hide its own presence from the operating system, from file listings, task managers, and standard detection tools, usually by running at a privilege level, like kernel mode, where it can intercept and falsify what the rest of the system sees. Netfilter qualified as a rootkit because it ran as a signed kernel-mode driver, giving it the same trust level as legitimate hardware drivers.

A root certificate, in normal operation, belongs to a Certificate Authority that a browser or OS vendor has vetted and trusts to only issue certificates to verified domain owners. That trust is what lets TLS confirm both that traffic is encrypted in transit and that the server on the other end is who it claims to be. When Netfilter wrote its own certificate into that same trusted store, it inserted an unvetted CA into a system designed around the assumption that everything in that store has been through a real validation process.

What Is the Threat Model Behind Driver-Signing Supply-Chain Attacks?

Netfilter is one instance of a broader pattern: an attacker does not need to break a code-signing algorithm when they can get a legitimate signature applied to malicious content through the process around it. The realistic threat model for any organization that relies on code signing, whether for kernel drivers, firmware, or software releases, includes:

1. Identity abuse at submission. An attacker registers, buys, or compromises a legitimate signing account and submits malicious code as if it were routine.
2. Insufficient pre-signing validation. Automated testing checks for stability and compatibility, not malicious intent, so code that behaves “normally” during testing can still be malicious in production.
3. Private key theft. If the signing key itself is exposed, an attacker can sign arbitrary code without going through the legitimate submission process at all, a distinct and more severe failure mode than Netfilter’s.
4. Trust store poisoning. Once malicious code executes with system privileges, it can add rogue certificates, disable protections, or open additional persistence paths.
5. Downstream propagation. Signed malicious drivers or binaries spread through normal software distribution and update channels, since the signature itself suppresses most security warnings.

Encryption Consulting has covered the more severe version of this threat model in a separate case study on the 2023 MSI code-signing key theft, where an actual signing key was stolen rather than abused through submission. Both incidents point to the same underlying requirement: the security of a code-signing program depends on how the keys and the submission process are governed, not just on the strength of the cryptographic algorithm.

How Should Organizations Choose Code-Signing Algorithms and Protocols to Prevent This?

Algorithm choice is necessary but not sufficient on its own; Netfilter was signed with a valid, uncompromised key, so the failure sat in process, not cryptography. Still, getting the cryptographic baseline right closes off adjacent attack paths:

• Use RSA-3072 or ECDSA P-384 or stronger for code-signing keys, matching current CA/Browser Forum baseline requirements for publicly trusted code-signing certificates, and avoid legacy SHA-1 signing entirely. See Encryption Consulting’s code-signing best practices in the SDLC for a full walkthrough of pipeline-level controls.
• Require hardware-backed private key storage. Since June 2023, CA/Browser Forum Code Signing Baseline Requirements have required that private keys for publicly trusted code-signing certificates be generated and stored on FIPS 140-2 Level 2 (or equivalent Common Criteria EAL 4+) hardware, such as an HSM or a hardware token, precisely so a key cannot be exported or copied off the device that protects it.
• Prefer EV code-signing certificates for kernel-mode submissions. Microsoft’s current Hardware Dev Center dashboard requires an EV certificate (or, as an alternative path, a registered Authenticode certificate) to submit binaries for attestation signing or WHCP certification, which raises the identity-verification bar on who can submit a driver in the first place.
• Add RFC 3161 timestamping to every signature so a signature remains verifiable, and any post-signing revocation still invalidates fraudulently issued code, even after the signing certificate itself expires.
• Adopt Windows Defender Application Control (WDAC) or a driver allowlist on top of signature checks, so a valid Microsoft signature is necessary but not automatically sufficient to run in your environment.

What Are the Performance and Interoperability Trade-Offs of Stricter Driver-Signing Policies?

Tightening driver-signing and code-signing controls is not free, and security teams should plan for these trade-offs rather than discover them after rollout:

• HSM-backed signing adds latency to the release pipeline. Every signing operation becomes a network or hardware call instead of a local file operation, which can add seconds per build in a CI/CD pipeline signing many artifacts per day; batching and caching signing sessions mitigate most of this.
• WDAC and strict allowlisting increase support overhead. Legitimate but unlisted drivers, common with niche hardware or older peripherals, will be blocked until explicitly approved, which shifts real work onto IT and helpdesk teams during rollout.
• EV certificate issuance is slower and more document-heavy than standard code-signing certificate issuance, since it requires organizational identity vetting, which can delay a driver submission timeline by days if requested at the last minute.
• Stricter trust-store change monitoring can generate false positives from legitimate enterprise software, like VPN clients or endpoint agents, that also install root or intermediate certificates for valid reasons, so baselining what is normal in your environment matters before enforcing blocking rules.

None of these trade-offs argue against the controls. They argue for rolling them out with a monitoring-first phase before moving to enforcement, so the operational cost is visible and manageable rather than a surprise outage.

What Are the Key-Management Dependencies for Protecting Code-Signing Keys?

Netfilter’s specific failure mode did not involve a stolen key, but the broader class of code-signing incidents, including the MSI case referenced above, most often does. A code-signing program’s key-management posture is a dependency the rest of the trust model rests on:

• Hardware custody. Signing keys should be generated inside, and never exportable from, a FIPS 140-validated HSM. A key that exists only as an export target is a key that can eventually leave the building, as Encryption Consulting covers in its guide to private key exposure.
• Role separation and dual control. No single engineer should be able to both request and approve a signing operation for production-bound code; key ceremonies for root or high-value signing keys should require multiple authorized participants.
• Access logging tied to identity, not shared credentials. Every signing operation should be attributable to a specific authenticated user or automated pipeline identity, so an anomalous signing request is traceable.
• Scoped, short-lived signing certificates for CI/CD pipelines. A pipeline identity that can sign anything, indefinitely, is a bigger blast radius than one scoped to a specific artifact type and refreshed on a defined schedule.
• A documented revocation and rotation plan. If a signing key or partner account is ever suspected of compromise or abuse, the organization needs a tested path to revoke, rotate, and re-sign affected artifacts quickly, not one designed under pressure during an incident.

How Do You Harden a Code-Signing Pipeline Against This Kind of Attack?

Use this as a working checklist for reviewing or building a code-signing or driver-signing program:

1. Inventory every signing key, certificate, and partner account currently authorized to produce trusted signatures in your environment, including third-party build pipelines.
2. Move any signing key still stored in software, a build server, or a developer workstation into an HSM, and disable export capability on the new hardware-backed key.
3. Require EV validation, or an equivalent verified-identity certificate, for any account authorized to submit kernel-mode or system-level drivers.
4. Add mandatory dual-control approval for signing operations tied to kernel-mode, firmware, or other high-privilege code paths.
5. Enable timestamping on every signature so revocation remains effective after certificate expiry.
6. Deploy WDAC or an equivalent allowlist so a valid signature is a necessary, not sufficient, condition to execute in your environment.
7. Add continuous monitoring for unexpected changes to the trusted root certificate store across endpoints.
8. Run a tested revocation and re-signing playbook at least annually, so the team is not designing that process for the first time during a live incident.

What Do Real-World Hardened Deployments Look Like?

Three deployment patterns cover most organizations that produce signed code, drivers, or firmware:

• Enterprise software vendor, CI/CD-integrated signing. Build pipeline requests a signature from an HSM-backed signing service over an authenticated API call, scoped to a specific build identity and artifact type, with every request logged and every signature timestamped, so a compromised build agent cannot sign arbitrary future releases.
• Hardware or driver vendor, WHCP-style submission. Driver binaries are signed internally with an HSM-protected key before submission, submission accounts require EV-validated identity and multi-person approval for kernel-mode releases, and post-signing monitoring watches for any driver signed under the organization’s identity that was not part of an approved release.
• Regulated enterprise, internal application signing. Internal applications are signed through a centralized service with role-based access, dual control for any signing scope broader than a single application, and automatic alerts if a new root or intermediate certificate appears in an endpoint’s trust store outside of a change window.

Attack Vector, Defense, and the EC Service That Addresses It

Attack Vector	Defense	Related EC Service
Abused or unvetted driver/code-signing submission account	EV-validated partner identity, dual-control approval before signing	CodeSign Secure
Signing key stored in software and exportable	Hardware-backed key custody, no export capability	HSM-as-a-Service
Rogue root certificate added to the trust store	Continuous trust-store monitoring, endpoint allowlisting (WDAC)	Encryption Advisory, PKI Services
No visibility into which keys, algorithms, and certificates exist across the environment	Continuous cryptographic discovery and inventory	CBOM Secure
Slow or improvised revocation after a suspected compromise	Tested revocation, rotation, and re-signing playbook	PKI Services, Encryption Advisory

Limitations

Several details of the Netfilter incident were never made fully public. Microsoft did not disclose the exact internal process gap that let the submission through certification, and it did not name the third-party submitter beyond confirming the account was suspended. G Data’s original technical write-up documented the redirection, proxy, and root-certificate behavior in detail but did not itself publish a confirmed finding of active SSL/TLS eavesdropping in the wild; that specific characterization traces back to commentary from an independent reverse engineer at the time, not a formal, corroborated technical report. An earlier version of at least one contemporaneous report also named a specific submitting company as a “Communist Chinese military” company per a U.S. Department of Defense list; BleepingComputer later reported it could not verify that company on the relevant DoD list, and the claim was retracted from the source it originated in. This piece treats that specific attribution as unconfirmed.

What Would Encryption Consulting Recommend?

Treat this incident as a process lesson, not a cryptography lesson. The fix for a Netfilter-style failure is not a stronger algorithm; RSA and ECDSA signing were never broken here. The fix is closing the gaps around who can request a signature, what hardware protects the key that produces it, and how quickly you can revoke and re-sign if something gets through anyway. In practice, that means moving every code-signing and driver-signing key onto HSM-backed custody with HSM-as-a-Service, enforcing identity-verified, dual-control signing workflows with CodeSign Secure, and maintaining a live inventory of every key, certificate, and algorithm in use across your environment with CBOM Secure, so an unexpected signing account, certificate, or algorithm change surfaces immediately instead of during a public disclosure. Talk to our code-signing advisory team to review your current signing pipeline against this checklist.

Frequently Asked Questions

Did the Netfilter rootkit actually decrypt all internet-wide encrypted traffic?
No. Verified reporting from G Data, BleepingComputer, and Ars Technica describes Netfilter redirecting specific network traffic and installing a rogue root certificate, a mechanism that can enable interception of redirected TLS traffic. No public report documents a demonstrated capability to decrypt all encrypted communications across the internet.

Was Microsoft’s code-signing infrastructure hacked?
Microsoft stated it found no evidence that its signing certificate or Windows Hardware Compatibility Program (WHCP) signing infrastructure was compromised. The malicious driver reached signing through a legitimate, but abused, partner submission account.

Why is a kernel-mode driver more dangerous than ordinary malware?
A kernel-mode driver runs at the same privilege level as core parts of the operating system, giving it the ability to intercept traffic, modify trust stores, and hide its own presence from standard detection tools, which is what makes a signed rootkit like Netfilter especially hard to catch.

Did this incident receive a CVE?
No. A CVE is assigned to a specific vulnerability in software. Netfilter exploited a gap in Microsoft’s driver-submission and vetting process rather than a flaw in Windows code, so no CVE identifier applies to the incident.

How does a rogue root certificate let an attacker intercept HTTPS traffic?
Operating systems and browsers trust a TLS connection when the server’s certificate chains up to a Certificate Authority already present in the device’s trust store. If malware adds its own, unvetted CA to that store, it can issue certificates for any domain that the device will accept as valid, enabling a man-in-the-middle attack on traffic actually routed through the attacker’s infrastructure.

Conclusion

Netfilter was a real, well-documented failure: Microsoft did sign a rootkit, and that rootkit did plant a rogue trusted root certificate capable of enabling TLS interception on redirected traffic. It was not, based on the verified public record, a demonstrated mass-decryption weapon against all encrypted communications. Microsoft’s own account of the incident points to the actual gap: a certification process that verified stability, not intent, and a submission account that should have faced more scrutiny before it ever reached the signing pipeline. Every organization that relies on code signing, for drivers, firmware, or software releases, should read this as a reminder that a valid signature is only as trustworthy as the process and the key management behind it.

References

• G Data: Microsoft signed a malicious Netfilter rootkit
• BleepingComputer: Microsoft admits to signing rootkit malware in supply-chain fiasco
• Ars Technica: Microsoft digitally signs malicious rootkit driver
• The Hacker News: Hackers trick Microsoft into signing Netfilter rootkit malware
• Microsoft Learn: Driver code signing requirements
• DigiCert: New private key storage requirement for code signing certificates