Digital certificates are designed to create trust. But what happens when hackers take advantage of gaps in trust? Reports show that Iranian state-sponsored hackers have been using valid SSL.com certificates to sign malware. This means they could make their malware undetectable and, therefore, more dangerous.<\/p>\n\n\n\n
Check Point Software and Prodaft revealed that an Iranian group tracked as UNC1549, aka Subtle Snail, Smoke Sandstorm, and Nimbus Manticore, had put malware in the wild signed with SSL.com code-signing certificates.<\/p>\n\n\n\n
These code-signing certificates gave the malware an air of legitimacy and reduced detection rates for many antivirus engines, which simply trust “signed” code. The problem security tools faced was that the signed code was malicious, and the tool trusted it as safe because it was signed.<\/p>\n\n\n\n
Multiple investigations claimed the signed code had been issued to a list of suspicious businesses, such as:<\/strong><\/p>\n\n\n\n The domains all contained the same header, “Under Construction” stock images, and there were no contact details listed. These are strong warning signs that a certificate authority (CA) should have detected when issuing the signed code. <\/p>\n\n\n\n Check Point stated that<\/em><\/strong> they believed the companies were either designed front companies created by the actors or that they were fraudulent identities created in the likeness of real businesses. <\/p>\n\n\n\n Regardless, the fact that the certificates were issued suggests there are questions surrounding SSL.com’s vetting process.<\/p>\n\n\n\n Signed binaries generate a considerable risk:<\/p>\n\n\n\n In this case, UNC1549 used the certificates to deploy back doors and infostealer malware against European organizations, but the risk is global.<\/p>\n\n\n\n When Dark Reading reached out to SSL.com<\/em><\/strong>, they first talked with an AI chatbot that simply summarized the inquiry, providing no genuine response. Then Dark Reading created a support ticket, which generated another AI-driven reply that was also vague.<\/p>\n\n\n\n At the time of publishing, SSL.com hadn’t provided any direct response from their security or communications teams. This lack of transparency, plus the fact that some certificates are still valid, raises significant and warranted questions about SSL.com as a CA had they been able to respond to the abuse.<\/em><\/strong><\/p>\n\n\n\n This is not the first time a CA is in question for abuse; back in 2017 Google revoked trust from all Symantec certificates after discovering they had mistakenly issued 30,000+ certificates. As a result, Symantec was forced to sell its PKI business to DigiCert.<\/p>\n\n\n\n If SSL.com does not take considerable steps to improve identity validation and incident response processes, it risks losing the trust of the industry as Symantec did.<\/p>\n\n\n\n While companies cannot influence CA practices, they can enact a risk mitigation plan:<\/p>\n\n\n\n This case provides clear insight into a key weakness in the PKI ecosystem: certificate authorities are a prime target for abuse. Weak vetting combined with over-reliance on automation generates a large gap into which threat actors will insert themselves.<\/p>\n\n\n\n Invalidated malware is not just a detection challenge; it is a trust challenge. If organizations cannot trust the certificates that they depend on, the entire digital trust model begins to break down.<\/p>\n\n\n\n To safeguard your enterprise, you should leverage what are considered highly trusted certificate providers that can demonstrate an established record of security, compliance, trust, and validation.<\/p>\n\n\n\n Industry leaders such as DigiCert Code Signing Certificates<\/a> and Sectigo Code Signing Certificates<\/a> perform more thorough validation and revocation processes, more in line with industry standards, making them less susceptible to abuse. <\/p>\n\n\n\n Start protecting your software supply chain with DigiCert Software Trust Manager<\/a> – certified to be trusted around the world.<\/p>\n","protected":false},"excerpt":{"rendered":"\n
Why Signed Malware Is So Dangerous?<\/h2>\n\n\n\n
\n
SSL.com\u2019s Response Comes into Focus<\/h2>\n\n\n\n
<\/a>History Repeats: A Lesson from Symantec<\/h2>\n\n\n\n
<\/a>Defending Against Signed Malware<\/h2>\n\n\n\n
\n
<\/a>What Does This Mean for PKI Security<\/h2>\n\n\n\n
<\/a>Conclusion<\/h2>\n\n\n\n