PEMPEMPEM – Hiding Behind Fake Certificates!

Over the years, enterprise security teams and threat actors have been involved in a never-ending game of cat and mouse. Organizations pour millions of dollars to stop advanced threats, but threat actors continue finding ways to evade detection by either enhancing their code or simply repackaging malware in more ways than one. This blog discusses the use of multiple components, including the use of legitimate software and encryption to deliver malware in a new manner.

A few days ago, we received samples, which contained components that include a file that looked like Privacy Enhanced Mail (PEM) certificates. PEM certificates are Base64 encoded Distinguished Encoding Rules (DER) certificates and are frequently used for web servers because they can easily be translated into readable data with the use of a text editor.

A PEM certificate can be identified by the presence of a header and footer, which envelopes a Base64 encoded data, just as the sample below: 

Figure 1.0 PEM Certificate Sample

This component, however, although enveloped with the PEM header and footer, includes a large amount of Base64 encoded data, which the main executable decodes using Windows’ cerutil.exe command line utility.

Figure 2.0 Fake PEM Sample

The decoded data reveals a heavily obfuscated AutoIt script containing encrypted x86 code used as a loader module to decrypt the main malware payload (in this case %temp%vFaqy.com) from the main executable, which is finally injected to another host process.

Figure 3.0 Decoded Fake PEM revealing heavily obfuscated AutoIt script

Figure 3.1 Deobfuscated Autoit Script

With this information, we can use Autoit Script Debugger together with Win32dbg to extract the main payload.

The script checks if the Windows platform is 32bit or 64bit. It will then use a specific set of shellcode for the determined platform to decrypt the payload.

Figure 3.2 Function containing the platform and shellcode

Then it will use a second shellcode to inject the payload to dllhost.exe.

Figure 3.3 Code snippet of 2^nd shellcode

Analysis of the injected code reveals that this payload is a variant of Vidar, a supposed copy/fork of the Arkei family of Stealer Trojans. This malware family has existed since late 2018, and this variant does not have distinguishable changes from its v4.1 functionality which was analyzed and documented 2 years ago.

Looking into other samples that we have detected with AU3/Injector.A.gen!Camelot, we saw at least 2 types of malware packages, one using NSIS and another using CABSFX. These samples are from different malware families, indicating of a new attempt of packaging malware to evade detection with the use of multiple components and supposedly benign/legitimate applications.

Shown below is the execution tree to show the overview of how the malware payload is installed into a system.

We did a little digging to see which malware families are packaged with this multi-component obfuscation and below is a histogram of samples seen over the month of July.

And below is the distribution of malware families using this obfuscation and a list of extracted IOCs.

Indicators of Compromise (IOCs)

Like what you read in this blog? Cyren gathers actionable intelligence (like the IOCs above) by analyzing and processing billions of daily transactions in Cyren GlobalView™ Threat Intelligence cloud. By correlating insights gathered across email content, web traffic, and suspicious files; Cyren provides security teams with a multi-dimensional presentation of critical threat characteristics. Powered by GlobalView, Cyren Threat InDepth’s contextualized threat intelligence allows enterprise security teams to gain unique visibility into evolving email-borne threats and make meaningful decisions to combat them. Learn more.