PowerShell Inside a Certificate? – Part 2

In our previous blogpost, we developed a method to detect certificate files that do not contain a real certificate. Trojanized certificates like these are often not detected by AV and IDS. Although we found all kinds of payloads, fake certificates containing a Windows executable appear to be the most common. In this post we will analyze one such certificate, containing a PowerShell script.

Certificate files can be used by adversaries as a container for all kinds of payloads to avoid detection of the payload by anti-virus, IDS, … . The payload will not activate when the certificate file is opened on a Windows systems; It has to be extracted by the actor or malware.

Another consequence is that dynamic analysis is not possible on the certificate file itself. Opening the certificate in a sandbox will not result in code execution, and thus no malicious behavior can be observed.

Analysis

We detected certificate MD5 0082aed588f76b517946a824fba43994 on VirusTotal with our YARA detection rule. Its BASE64 code does not start with letter M, hence it can’t be a valid certificate. Neither is it a Windows executable (PE file), as the BASE64 code does not start with letter T.

base64dump.py gives us more information:

This looks like a command starting with powershell.exe. Let’s take a look at the full code:

This payload has several layers of obfuscation, something that is typical for red team assessments and malicious PowerShell scripts found in the wild. This is another reason why we selected this certificate as an example: it allows us to show how to statically analyze PowerShell scripts.

In the screenshot above, you can see that powershell.exe is executed with -encodedcommand argument, which is a long BASE64 encoded UNICODE string. This too can be decoded with base64dump:

This deobfuscated script contains BASE64 code too, adding another layer of obfuscation. Let’s reformat this for better readability:

As we can see, the BASE64 string is decoded, decompressed (GZip) and executed (IEX).

Once decoded and decompressed, we end up with another PowerShell script. translate.py has a function (GzipD) to decompress GZip compressed data:

And again, more BASE64! This type of script is also well-known: it contains shellcode (BASE64 encoded) that gets injected in the PowerShell process and then executed. The last if statement, with an expression to compare the size of an integer pointer (IntPtr) with 8, is a trick to detect if the PowerShell process is a 32-bit or a 64-bit process. 32-bit processes use 4-byte pointers and 64-bit processes 8-byte pointers. In this script, if the pointer is not 8 bytes long (32-bit), the script gets executed directly (IEX). While for 64-bit PowerShell, a 32-bit PowerShell process is started (start-job … IEX … -RunAs32) to run the script.

This 32-bit trickery is done because the script contains only 32-bit shellcode, which can only be run inside a 32-bit process, and not inside a 64-bit process.

So … another level of BASE64 decoding:

And finally, when we decode this BASE64-encoded shellcode and extract strings, we can see a domain and a user agent string.

Extracting and emulating this shellcode with scdbg.exe will give us a better idea of what this shellcode does:

The shellcode establishes an HTTP connection to download a multi-stage shellcode that will launch a remotely accessible shell. This code is typical for penetration testing tools, like (older) Metasploit/Meterpreter and similar frameworks developed in PowerShell.

In next parts, we’ll publish several detection rules for YARA, Suricata and ClamAV.

Conclusion

Malware hidden in certificate files can not be directly analyzed with dynamic analysis methods, because certificates do not execute code when opened. The first step is therefore the extraction of the payload.

In this blog post, we gave an example of the static analysis of layers-deep obfuscated PowerShell scripts that ultimately execute first-stage shellcode. This is typical for a penetration testing framework,  but is also used by criminals.

About the authors
Didier Stevens is a malware expert working for NVISO. Didier is a SANS Internet Storm Center senior handler and Microsoft MVP, and has developed numerous popular tools to assist with malware analysis. You can find Didier on Twitter and LinkedIn.