Month: May 2025

Summary

A critical security incident exposed KeyPlug malware infrastructure due to the improper use of wolfSSL test certificates in production. The 24-hour exposure revealed sophisticated attack tools linked to the RedGolf/APT41 threat group, demonstrating how poor certificate management can compromise even advanced threat actors’ operations.

The Certificate Failure

The compromised server was identified through its WolfSSL test certificate:

Subject Common Name: www[.]wolfssl[.]com
Subject Organizational Unit: Support_1024
Issuer Organizational Unit: Consulting_1024
SHA-256: 4C1BAA3ABB774B4C649C87417ACAA4396EBA40E5028B43FADE4C685A405CC3BF

Critical Issues

• Test Certificate Misuse
  • Production use of wolfssl.com test domain
  • Weak 1024-bit keys (indicated by “_1024” suffix)
  • Certificate sharing across multiple attack servers
• Security Impact
  • Exposed Fortinet exploitation tools and C2 infrastructure
  • Enabled infrastructure correlation through shared certificates
  • Compromised operational security of advanced threat actors

Best Practices for WolfSSL Implementation

To avoid security lapses like the one described, it’s critical to follow best practices when deploying wolfSSL in production environments. The following guidelines focus on certificate requirements, security controls, and monitoring techniques:

Production Deployments

• Certificate Requirements
  • Use only trusted CA-issued certificates
  • Implement minimum 2048-bit RSA keys
  • Maintain proper validation chains
• Security Controls
  • Never use test certificates in production
  • Implement certificate pinning
  • Regular certificate rotation

Monitoring and Detection

• Certificate Auditing
  • Regular infrastructure scans
  • Certificate inventory management
  • Automated validation checks
• Warning Signs
  • Domains containing “wolfssl.com”
  • Organizational units with test indicators
  • Key sizes below 2048 bits
  • Invalid trust chains

Recommendations

To mitigate risk and ensure strong certificate hygiene, both WolfSSL users and security teams should take immediate action. Below are tailored recommendations for each group:

Immediate Actions

1. For WolfSSL Users
   • Audit all certificates
   • Remove test certificates
   • Implement CA-issued certificates
   • Verify proper key lengths
2. For Security Teams
   • Monitor for test certificate usage
   • Implement certificate validation
   • Regular infrastructure scanning
   • Maintain certificate inventory

Conclusion

Organizations must maintain strict separation between development and production certificates and implement proper certificate management policies to prevent similar exposures.

Please do not use wolfSSL test certificates in production because the corresponding private keys are published as part of the wolfSSL source code package, so by design, these certificates are insecure. The test certificate private keys are public!

Source:

• KeyPlug-Linked Server Briefly Exposes Fortinet Exploits, Webshells, and Recon Activity Targeting a Major Japanese Company
• Exposed KeyPlug Malware Staging Server Contains Fortinet Firewall and VPN Exploitation Scripts

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

In the evolving landscape of cryptographic security, supporting multiple signature algorithms within a single certificate has become increasingly important. These certificates are known as Chimera certificates, a moniker coined by the X9.146 banking standards team. They provide enhanced security, flexibility, and agility, especially for the transition to post-quantum cryptography. As well, wolfSSL also understands the new TLS 1.3 CKS extension as defined by the X9.146 banking standard draft.

Chimera certificates are X.509 certificates that contain two public keys and signatures. These certificates are implemented through the use of three extensions:

• Subject Alternative Public Key Info (SAPKI): Contains an alternative public key
• Alternative Signature Algorithm: Specifies the algorithm used for the alternative signature
• Alternative Signature Value: Contains the actual bitstring of the alternative signature

In X.509 certificates, extensions can be marked as either “critical” or “non-critical.” Critical extensions MUST be understood and processed by the certificate validator. If a validator doesn’t recognize a critical extension, it MUST reject the certificate. Non-critical extensions can be safely ignored if not understood.

Before release 5.8.0, wolfSSL’s dual algorithm certificate implementation did not properly support the parsing of these extensions if they were marked as Critical. This was because the whole purpose of these extensions was to facilitate migration by allowing unmigrated systems to ignore the alternative public key and signatures. In that context, marking these extensions as critical made no sense.

That said, these extensions are standardized in the 2019 edition of the ITU-T X.509 standard. In that document, under recognition that there might be other future applications for these extensions, marking these extensions as critical is permitted.

The addition of critical extension support for Chimera certificates extensions represents an important compliance step. Without standards, interoperability would not be possible.

As the cryptographic landscape continues to evolve, especially with the ongoing transition to post-quantum algorithms, enhancements such as Chimera certificate support will become increasingly valuable. wolfSSL continues to demonstrate its commitment to providing a robust, standards-compliant, and forward-looking cryptographic library.

If you have question about any of the above, please contact us at >a href=”mailto”facts@wolfssl.com”>facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now