Valid Adobe Certificate Used to Sign Malicious Utilities Common in Targeted Attacks

Adobe announced today it was the victim of an APT-style attack after two malicious utilities commonly used in targeted attacks for privilege escalation and pivoting within a network were discovered signed by a valid Adobe digital certificate. Adobe said it will revoke the certificate next week.

Adobe products and services senior director of security Brad Arkin said in a statement that a build server with access to the Adobe code signing infrastructure was compromised and is the source of the issue.

The certificate will be revoked on Oct. 4; this affects only Adobe software signed with the cert after July 10 running on Windows, as well as three Adobe Air applications that run on Windows and the Macintosh platform.

“Customers should not notice anything out of the ordinary during the certificate revocation process,” Arkin said. “Our investigation to date has shown no evidence that any other sensitive information—including Adobe source code or customer, financial or employee data—was compromised.”

 

Arkin said Adobe does not believe the certificate was used to sign widespread malware, and is limited to the two utilities discovered.

“We believe the vast majority of users are not at risk,” Arkin said.

The two utilities in question are pwdump7 v7.1, which extracts password hashes from Windows and sometimes links the OpenSSL library libeay32.dll, and myGeeksmail.dll, a malicious ISAPI filter that runs on the Microsoft Web server software IIS. ISAPI can be used to modify IIS’ functionality.

Mikko Hypponen, chief research officer at F-Secure, said on a Twitter post that his company's sample repository has more than 5,000 files signed by the compromised certificate. Hypponen said only three of the files were malicious.

IT administrators can try to mitigate the threat by creating a software restriction policy via Group Policy that prevents the utilities from executing. However, moving the certificate to the Windows Untrusted Certificate Store, according to Adobe tests, will not block an attacker from executing the utilities on a compromised machine. This will also hamper performance of legitimate Adobe products signed with the certificate.

Adobe has decommissioned the code-signing infrastructure and instituted a temporary code-signing service for re-signing components signed with the compromised key. It is investigating how the signatures were created.

So far, Arkin said, Adobe has identified malware on the build server in question and how the attackers gained access to it, in addition to having forensic evidence linking the server to the signing of the malicious utilities. He said the private key was not extracted from a hardware security module, stored in a physically secured location.

“We believe the threat actors established a foothold on a different Adobe machine and then leveraged standard advanced persistent threat tactics to gain access to the build server and request signatures for the malicious utilities from the code signing service via the standard protocol used for valid Adobe software,” Arkin said.

 The compromised build server had access to source code for only one product, Arkin said, who added it was not Flash, Reader, Shockwave or AIR.

“We have reviewed every commit made to the source repository the machine did have access to and confirmed that no source code changes or code insertions were made by the build server account,” Arkin said. “There is no evidence to date that any source code was stolen.”

Courtesy by Michael Mimoso