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

Hash 12a7b79430bf3b788396009eadb6cbc4da97cba55c6653048d2dd294fa90dc3a Threat Azorult

Size 809 KB SSDEEP 12288:KKi7ifyf5/TIEAcp2o/DZDlvs6SskijhnHW3/qgQrjSh4rNxPXJE:K6m5UYZRUokohnH4QrjCCP5E

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.



Figure 1: Static information about the sample

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.



Figure 2: Communication of the malware with the C2

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.



Figure 3: API logging of the malware



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.



Figure 4: Breakpoint on OpenProcess API allowing payload dump

Reversing the Payload with Ghidra

Hash 70d038d221f79baf9114bf37815fe593965c28218fd70e72827a94984f52d968 Threat Azorult – Payload Size 128 KB SSDEEP 3072:YxRaX6raoCoCyz6/mqv1JR+yBtGOeheWgieGq:caZ1tme+1wie5

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.



Figure 6: Static information about the Azorult payload

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.



Figure 7: Communication routine with the C2 and hardcoded address

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).



Figure 8: Routine for gathering information of Mozilla

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.



Figure 10: Ghidra scripts list

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.



Figure 11: Yara Ghidra GUI script

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.



Figure 12: Selection of the piece of code to generate the Yara Rule

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.



Figure 13: GUI of the Ghidra plugin

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.



Figure 14: Refinement of the generated Yara Rule by replacing the operand values with wildcards

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)

Share this...

Linkedin Reddit Pinterest

Share On