Ghost Certificates: How Decade-Old Code Signing Infrastructure Enables Modern Malware

For the past 11 years, threat actors have been signing malware with certificates from 2014, and those signatures still load perfectly on fully-patched Windows 11 systems in December 2025. This isn't a theoretical vulnerability or an edge case. It's a systematic failure in how Windows validates trust, and attackers have built an entire economy around exploiting it.

Our research team at MagicSword recently analyzed two active campaigns that perfectly illustrate this problem:

Campaign 1: VMProtect-packed malware with 126 variants compiled this month, achieving only 24.7% detection rate despite being fresh samples.

Campaign 2: A malware family called FusionCore with 200+ variants spanning 11 years, using the same compromised certificate infrastructure that's been signing malicious code since 2014. That certificate? Still works perfectly on every Windows version we tested.

This research exposes how Windows' backward compatibility requirements have created a persistent vulnerability that defenders need to understand and adapt to. Let's break down what's actually happening, why Microsoft can't simply "fix" it, and what security teams can do about it.

The Samples: A Tale of Two Certificate Abuse Patterns

Sample 1: VMProtect Campaign - Modern Packing with Vintage Trust

SHA256: 78a584f55b7e1a5b11c0a72e440f4d007e0d14760ebfa9d9e3a635b102fa4c34

This sample represents the current state of malware evasion. It uses VMProtect, a legitimate commercial software protection tool that's become a favorite among malware developers. VMProtect isn't malware, it's a packer designed to prevent reverse engineering of legitimate software. But its effectiveness at obfuscation makes it incredibly valuable for attackers.

What caught our attention: 126 similar variants, all compiled in December 2025. This is an active, industrial-scale operation. The detection rate sits at just 24.7% on VirusTotal (18 out of 73 engines). Three-quarters of commercial AV solutions are missing freshly compiled malware because it's wearing the right credentials, specifically, a VeriSign Class 3 Code Signing certificate from the early 2010s.

The technique is elegant in its simplicity. VMProtect's anti-analysis features defeat static analysis through code virtualization, mutation, and import protection. Combined with an old trusted certificate, this creates a binary that's both difficult to analyze AND appears trustworthy to Windows. Microsoft's detection systems recognize VMProtect-packed malware, but the combination of legitimate packing technology and trusted signatures creates a technical challenge. There's no solution that doesn't risk blocking legitimate software protection tools.

VirusTotal Analysis

Sample 2: FusionCore - Eleven Years of Certificate Reuse

SHA256: fa1969cf1c3099fb40ef95e02c194445fab7544941fab72f260cadf5102e3c30

If Sample 1 shows us the present, Sample 2 shows us the scope of the problem. FusionCore started as a PUA/Adware bundler in 2014, and we can trace over 200 variants across 11 years of operation. The family tree reveals how durable this certificate infrastructure truly is:

• 2014-2016: Adware bundling operations
• 2018-2020: ELEX trojan distribution
• 2021-2022: Redline Stealer campaigns
• 2023-2024: Rhadamanthys info stealer
• 2025: Stop ransomware variants

Same certificate infrastructure. Same signing chain. Eleven years of continuous malware distribution, and it's still actively deployed today. The certificate that signed these binaries has been signing malware longer than some security analysts have been in the industry.

VirusTotal Analysis

The VeriSign Timeline: Why These Certificates Persist

Understanding the corporate history helps explain why these certificates still work. VeriSign was a major Certificate Authority that issued millions of code signing certificates, including the Class 3 Code Signing certificates used in our samples. In August 2010, Symantec acquired VeriSign's security business for approximately $1.28 billion. In October 2017, DigiCert acquired Symantec's Certificate Authority business for $950 million in cash and a 30% equity stake.

The VeriSign Class 3 Code Signing 2010 CA certificates like those used in our samples were issued between 2010-2020, with VeriSign transitioning away from new certificate issuance after Symantec's acquisition. But the certificates they issued before that transition? Still trusted by default in Windows trust stores. You can verify this yourself:

1. Open certmgr.msc on any Windows system
2. Navigate to "Trusted Root Certification Authorities" > "Certificates"
3. Look for VeriSign and Symantec roots from the 2000s and 2010s

They're all there, still trusted on Windows 11 25H2.

Why Microsoft Can't Just Remove Them

Microsoft maintains the "Trusted Root Certification Authorities" store that ships with Windows. Their Root Certificate Program Requirements document the process for adding and removing roots, but here's the constraint they face: removing old certificates breaks backward compatibility.

Microsoft's deprecation documentation explains: "Removal of a root from the CTL. All certificates that chain to the root are no longer trusted. Users can still manually install the root into the Local Machine 'Trusted Root Certification Authorities'/Registry physical store." The key insight: roots are "typically distrusted rather than removed" to prevent breaking existing valid certificates.

Translation: Once a root certificate is trusted in Windows, it effectively stays trusted forever. Microsoft can add new roots easily, but removing old ones would break legitimate business-critical applications. The Certificate Trust List (CTL) mechanism that updates through Windows Update only affects NEW trust decisions, it doesn't invalidate certificates already in the trust store.

The Economics of Old Certificates

There's a thriving underground economy around compromised and stolen code signing certificates, but the truly valuable ones aren't fresh, they're old. Here's why attackers pay premium prices for decade-old certificates:

Historical Trust: Certificates issued during 2010-2016 were from the "golden age" of code signing, before Certificate Authorities implemented strict validation. They're implicitly trusted by every Windows version from 7 through 11.

Revocation Infrastructure Decay: The older the certificate, the more likely the revocation infrastructure has degraded. CRL servers go offline, OCSP responders become unreliable, and Windows defaults to trust.

Wide Compatibility: A binary signed in 2012 loads on Windows 7, 8, 8.1, 10, and 11 without compatibility issues. Modern certificates sometimes have problems with older systems that enterprises still run.

Reusability: Once you have access to a compromised certificate from this era, you can use it indefinitely. The 200+ FusionCore variants prove this, same certificate, 11 years of use, still working.

The market reflects these advantages. Research into the underground code signing certificate market shows that standard certificates range from $299-$500, while Extended Validation (EV) certificates command prices of $2,000-$6,500. Older certificates from the 2010-2015 era command premium prices due to their broader trust and compatibility—based on our monitoring of underground forums, these vintage certificates can sell for 3-5x more than freshly obtained modern certificates.

The Bigger Pattern: Certificate Abuse Across Multiple CAs

The VeriSign certificates in our samples aren't isolated cases. We're tracking similar abuse patterns across multiple Certificate Authorities:

• Fuzhou Dingxin Trade Co.: Certificate expired 2012, still signing malware in 2025
• Changsha Hengxiang Technology: Certificate revoked 2016, we've identified 89+ EDR killer variants using it (documented in our HeartCrypt research)
• Multiple VeriSign Class 3 certificates from 2010-2015: Actively used across ransomware, info stealers, and rootkit families
• Zhengzhou Lianhe certificates: Similar pattern, expired 2014, used in 2024-2025 campaigns

The pattern is consistent across all of them: old equals trusted. Attackers have learned that Windows' backward compatibility requirements create a persistent vulnerability they can exploit indefinitely.

Real-World Impact: The HeartCrypt Connection

This certificate abuse pattern isn't limited to commodity malware. In our previous HeartCrypt ransomware research, we documented a VMProtect-based packer service using compromised certificates to sign ransomware payloads. The certificates? Also from the early 2010s. Also still working.

HeartCrypt demonstrates the full supply chain:

1. Ransomware-as-a-Service operators purchase "clean" signed binaries from packer services
2. Packer services use compromised certificates to sign the payloads
3. Signed malware bypasses EDR and application control solutions
4. Certificate infrastructure from a decade ago becomes a force multiplier for modern ransomware operations

The same pattern appears across multiple ransomware families, info stealers, and EDR bypass tools. Old certificates have become critical infrastructure for threat actors.

The Bigger Trend: Trust Exploitation Over Zero-Days

What we're seeing with certificate abuse is part of a larger shift in attacker tactics. As EDR adoption increases and exploit development becomes more expensive, attackers are moving away from zero-day exploits toward trust exploitation:

• Signed malware bypasses application whitelisting and default-deny policies
• LOLBins abuse trusted Windows utilities rather than deploying custom tools
• Supply chain compromises inject malware into trusted software distribution channels
• Stolen credentials bypass authentication rather than exploiting vulnerabilities

The common thread: Don't break in when you can walk through the front door with valid credentials. Old certificates are just another form of valid credentials, trust artifacts from a previous era that still grant access today.

What MagicSword Is Tracking

At MagicSword, we're actively monitoring this certificate abuse ecosystem:

• 300+ compromised/abused certificates across multiple CAs and time periods
• Real-time monitoring of new certificate abuse patterns through threat intelligence sources

We publish regular intelligence on certificate abuse patterns, and our platform helps organizations implement Application Control-based blocking without the traditional deployment complexity.

Key Indicators of Compromise

Sample 1 (VMProtect Campaign)

SHA256: 78a584f55b7e1a5b11c0a72e440f4d007e0d14760ebfa9d9e3a635b102fa4c34

SHA1: e2e603e78b6266b6f31d2c7ba084499bc595e9d2

MD5: a70345cf27c3ea854dc019c217d0a18a

First Seen: December 2025

Related Samples: 126+ variants

Detection Rate: 24.7% (18/73 engines)

VirusTotal Analysis

Sample 2 (FusionCore Family)

SHA256: fa1969cf1c3099fb40ef95e02c194445fab7544941fab72f260cadf5102e3c30

SHA1: a17d52f503b9afc546dfcba67e31d48ddd51bc10

MD5: 88ba7cec70c4ee2399bddfff2b70821b

First Seen: 2014 (200+ variants over 11 years)

Associated Families: ELEX, Redline, Rhadamanthys, Stop ransomware

Detection Rate: 87.7%

VirusTotal Analysis

Certificate Blocking Guidance

Block any binary signed with:

• VeriSign Class 3 Code Signing 2010 CA
• Any certificate issued to companies registered in Changsha or Fuzhou (common fronts)
• Certificates with signing timestamps before January 1, 2018
• Certificates where signing date is more than 5 years before compilation timestamp

The Bottom Line

The convergence of Windows' backward compatibility requirements with the underground certificate economy has created a persistent vulnerability that patching alone cannot solve. Malware signed a decade ago is loading on systems today, and it will continue to work until organizations implement certificate-based blocking strategies.

This isn't theoretical. The FusionCore family's 11-year operational history proves the durability of this approach. The VMProtect campaign's 24.7% detection rate proves its current effectiveness. The economics of the underground certificate market prove it's not going away.

Security teams must shift from "signed equals safe" to certificate-based trust validation. Microsoft has provided the tools through WDAC, but deployment complexity has limited adoption. As threat actors continue investing in certificate abuse infrastructure, the gap between attack sophistication and defense capability widens.

The question isn't whether your organization will encounter malware signed with ghost certificates, it's whether you'll detect and block it when you do.