Pierluigi Paganini April 02, 2019

Cybaze-Yoroi ZLAB malware researchers decided to use the NSA Ghidra suite in a real case study, the analysis of the AZORult malware.

Introduction

One of the most expected moments in the infosec community during the last few months was, with no doubt, the Ghidra public release. On the 5th of March, at the RSA conference, Ghidra has been presented to the public revealing the inner details of the Software Reverse Engineering (SRE) framework that National Security Agency used for more than a decade.

Its release was a sort of “main event” for security researchers all around the globe, which immediately started exploring its functionalities to find out its place within the reversing tool panorama. Cybaze-Yoroi ZLAB team also decided to play around with it, but this time using a real case study, AZORult: one of the most active threats spreading nowadays, always using new methodologies to avoid detection. For this reason, a recent AZORult sample has been chosen to field-test the NSA reverse engineering tool.

Technical Analysis

The sample is a PE32 file apparently coded in Visual C++, containing references to major IT companies in its metadata fields like Google and Amazon.

Dynamically executing the malware, we are able to isolate only a few actions of the malware, because its C2 server wasn’t active at the time of analysis, probably due to a configuration error.

So, after contacting the server, the sample does not have the possibility to download other components and configurations. Thus, the malware kills itself and terminates its execution.  For this reason, we focused the investigation into static analysis and debugging.

Digging into the Sample

The first details about the malware inner workings have been retrieved through the API calls tracing, where some interesting APIs emerged: the malware performs a check on the active processes, finding the typical malware analysis tools, like Wireshark, Process Explorer and Process Monitor.

Among the API calls, there is one quite interesting, an OpenProcess call referencing the process itself, referencing an embedded portable executable inside the original file: the payload.

Reversing the Payload with Ghidra

The extracted payload is written in Delphi language, as confirmed with a first preliminary analysis. Thus, we decided to test Ghidra in order to statically analyze the malware.

Using the Ghidra search strings function we found the hardcoded C2 address in plain-text, meaning the malware writers do not bother to protect its payload, but only the container. This IP address is the same was seen during the dynamic analysis section, as shown in Figure 2. Also, the malware uses a custom user-agent.

Then, we managed to gather the characteristic strings of the payload, finding many interesting ones, extensively reported in the section “Configuration Strings”. Thanks to this, we have also isolated the AZORult routine used to gather and store the Mozilla cookies (Figure 8).

Digging further, we identified the “shell routine” which allows the command and control operator to execute arbitrary commands on the victim machine. The code snippet shown in Figure 9 shows how the malware exploits this capability to delete its execution traces into the victim machine.

We also leveraged Ghidra built-in script engines to test Yara rules against the inspected code. This flexibility is one of the main characteristics makes Ghidra a valuable tool for a Reverse Engineer.

Using the “YaraGhidraGUIScript”, available off-the-shelf in the tool, we managed to write down an ad hoc rule to spot the in-memory payload.

The usage of this extension is quite intuitive: the analyst has to select the piece of disassembled code he/she consider representative of the malicious behaviour.

For instance, the selected piece of code in Figure 12 refers to the routine used by AZORult to contact the C2 with the specific User-Agent. Selecting it into the “YaraGhidraGUIScript”, a new popup forms shows the analyst a powerful Yara generation helper.

The Yara GUI shows a smart rule proposal and allows the analyst to freely edit it: in this case the Hex values of the PUSH and MOV operation could be relative to the current virtual addressing of the specific machine, so by clicking on these values, the script replaces the operand values with the wildcard “?”, preserving the assembly instructions.

The resulting Yara rule is reported the right section “Yara rules” below.

Conclusion

Ghidra is a valuable tool in the arsenal of a Reverse Engineer. It freely provides advanced features like the code decompilation, that was typically available into high end commercial products, accessible to well budgeted professionals. The NSA choice to give back to the security community is admirable, especially because the tool itself is solid and has advanced peculiarities that make it suitable for professional usage.

Anyway, it is not possible to directly compare it to commercial products, or wondering if it may be able to replace any of those, it’s conceptually erroneous, and after this field test we can confirm Ghidra is a valuable tool should be included in every reverse engineering’s arsenal.

Further technical details, including Indicators of Compromise (IoCs) and Yara rules are reported in the analysis published on the Yoroi blog:

Pierluigi Paganini

(SecurityAffairs – Ghidra, malware)

[adrotate banner=”5″]

[adrotate banner=”13″]