It’s important for those defending critical and industrial infrastructure to share knowledge and stay up-to-date on malware tradecraft.
With that in mind, when the GreyEnergy Advanced Persistent Threat (APT) ended up unveiled by ESET last year, I put my reverse engineering skills to work to analyze one of the malware’s infection techniques. This was the phishing email containing a malicious Microsoft Word document (maldoc) that lead to the installation of the malware (backdoor) on a victim’s network. ESET researchers said GreyEnergy operators have been strategically targeting ICS control workstations running SCADA software and servers for espionage and reconnaissance purposes.
A new research paper provides a comprehensive analysis of how the malware works, from the maldoc, to the custom packer and the final dropper (backdoor). This investigation is a more detailed analysis, with the deepest investigation done on the packer, an executable that decrypts and decompresses another executable inside itself.
This is a summary of the techniques used by the packer to conceal its true functionality. In addition for those wanting more detail, click here to register for the full research paper entitled, “GreyEnergy: Dissecting the Malware from Maldoc to Backdoor, Comprehensive Reverse Engineering Analysis.”
‘Packer’ Executable Concealed
When someone opens the Word document contained in the GreyEnergy phishing email, and clicks on “Enable Content,” malicious code is downloaded from a remote location.
The downloaded file is an executable which I suspected was a “packer,” i.e. an executable which contains one or more executables compressed and encrypted. While sometimes used legitimately to protect intellectual property, packers are also used by threat actors to hide malware.
As I investigated the suspected packer executable, I found it was built using several anti-analysis techniques:
Junk code – Unnecessary code that has no impact on the suspected packer’s code, and whose purpose is to confuse the reverse engineer. GreyEnergy contains a massive amount of junk code.
Overlapping instructions – GreyEnergy uses JMP instructions that function as overlapping instructions, where the same sequence of bytes can be interpreted as different instructions, depending on the exact byte in which execution starts.
JMP-based execution code – The execution flow of the suspected GreyEnergy packer is almost completely based on the use of JMP instructions, instead of sequential instructions. This makes it very hard to identify the true executable, hidden in a sea of junk code. Furthermore, the binary file of the suspected packer appeared to have overlay data. This is data appended at the end of the file that includes an additional executable component, and is decrypted during run-time.
Entropy – This is an assessment of a file’s randomness. Using one measure of entropy, with a scale of 0 to 8, where results of 7 or more indicate encryption, GreyEnergy has a score of 7.994. This is a strong indicator overlay data is encrypted.
After assessing the above aspects of the malware, I had a strong suspicion that I was dealing with a packer, but lacked solid proof. I decided to switch to a dynamic analysis approach to order to speed up the investigation. I then discovered several interesting attributes of the suspected packer file:
Hardcoded imports – The WinAPIs called by the suspected packer are not contained in the PE import table, but loaded at runtime and pushed ono the stack using a mov instruction, without any kind of obfuscation technique.
String overwrite – The suspected packer overwrites all strings with zeros, after the strings have been loaded into memory.
By now, there are multiple indicators that strongly suggest the binary is a packer:
• Apparently encrypted overlay
• Anti-analysis techniques
• APIs manually resolved by parsing the PE header
• Strings hardcoded inside the code and overwritten with 0x00s after use
Accessing the overlay – The malware uses a series of steps to identify where the overlay starts and the exact size of its own executable, and allocates space for itself inside the memory. Analysis reveals exactly how the malware identifies the right offset for the overlay.
Decryption algorithm – The malware uses a custom algorithm to hide its malicious components. When the decryption algorithm is applied, it is clear the data contains an executable. However, there are several unexpected bytes between the recognized patterns, indicating the data is not yet complete. I suspected that the data is compressed somehow.
Decompression algorithm – My suspicion is quickly confirmed, and after decompression, the new buffer contains a valid Portable Executable (PE) header.
Original entry point (OEP) – Next the packer points to the uncompressed buffer, parses the PE header and iterates all sections again. Once it accesses the overlay data, a second PE header is revealed, which is the real malicious component (backdoor), waiting to be installed inside the victim’s systems.
It’s now possible to identify two specific components from the unpacked data – the dropper and the backdoor.
The suspected packer executes the dropper in-memory without storing it inside the filesystem. This step confirms the binary is a packer, because it has just demonstrated all the primary characteristics of packers.
Once complete, my analysis showed the GreyEnergy packer is robust and capable of significantly slowing down the reverse engineering process. The techniques used are not new, but the tools and the tactics employed were cleverly selected. The threat actors’ broad use of anti-forensic techniques underlines their attempt to be stealthy and ensure the infection would go unnoticed.
Based on how well the malware disguises itself once it infects a system, the best way for industrial organizations to protect themselves from the GreyEnergy APT is to train employees on the dangers of email phishing campaigns, including how to recognize malicious emails and attachments.
In addition, critical infrastructure networks should always be monitored with dedicated cyber security systems to proactively detect threats present on the network.
As a direct outcome of this analysis, I developed tools to help analysts dissect this piece of malware. The GreyEnergy Yara Module, is high-performing code for compiling with the Yara engine. It adds a new keyword that determines whether a file processed by Yara is the GreyEnergy packer or not.
This tool, combined with the previously published GreyEnergy Unpacker (a Python script that automatically unpacks the dropper and the backdoor, extracting them onto a disk), saves other security analysts the reverse engineering work.
Alessandro Di Pinto is a security researcher at Nozomi Networks. He is an Offensive Security Certified Professional (OSCP) with a background in malware analysis, ICS/SCADA security, penetration testing and incident response. He holds GIAC Reverse Engineering Malware (GREM) certification, which recognizes technologists with the skills and knowledge to reverse engineer malware and conduct forensic investigations.