Diamond Fox – part 1: introduction and unpacking

Diamond Fox (also known as Gorynch) is a stealer written in Visual Basic that has been present on the black market for several years. Some time ago, builders of its older versions (i.e. 4.2.0.650) were cracked and leaked online – thanks to this we could have a closer view at the full package that is being sold by the authors to other criminals.

In 2016 the malware was almost completely rewritten – its recent version, called “Crystal” was described some months ago by Dr. Peter Stephenson from SC Media (read more).

In this short series of posts, we will take a deep dive in a sample of Diamond Fox delivered by the Nebula Exploit Kit (described here). We will also make a brief comparison with the old, leaked version, in order to show the evolution of this product.

In this first part, we will take a look at Diamond Fox’s behavior in the system, but the main focus will be about unpacking the sample and turning it into a form that can be decompiled by a Visual Basic Decompiler.

Analyzed samples

• 92d098a9f2adb0e4c524edd82a81c894 – original sample
  • 05ce32843c7271464b48283fe8f179cc – unpacked stage 1
    • 988e9fa903cc2fbb80e7221072fb2221 – unpacked (final VB payload)

Behavioral analysis

After being deployed, Diamond Fox runs silently, however, we can notice some symptoms of its presence in the system. First of all, the UAC (User Account Control) gets disabled and we can see an alert about it:

Another pop-up is asking the user to restart the system so that this change will take effect:

The initial executable is deleted and the malware re-runs itself from the copy installed in the %TEMP% folder. It drops two copies of itself – dwn.exe and spoolsv.exe. Viewing the process activity under Process Explorer, we can observe the spawned processes:

It also deploys wscript.exe.

For persistence, Diamond Fox creates a new folder with a special name (read more about this feature): %TEMP%lpt8.{20D04FE0-3AEA-1069-A2D8-08002B30309D}.

Thanks to this trick, the user cannot access the files dropped inside. Another copy (backup) is dropped in the Startup folder.

While running, the malware creates some files with .c extensions in %APPDATA% folder:

Also, new files are created in the folder from which the sample was run:

The file keys.c contains an HTML formatted log about the captured user activities, i.e. keystrokes. Here’s an example of the report content (displayed as HTML):

The files log.c and Off.c are unreadable.

Examining the content of the %TEMP% folder we can also find that the malware dropped downloaded payload inside:

It is a XOR encrypted PE file (key in the analyzed case is: 0x2), that turns out to be an update of the main Diamond Fox bot.

Network communication

Diamond Fox communicates with the CnC using an HTTP-based protocol. It beacons to gate.php

Data from the bot is sent to the CnC in form of a POST request. Pattern:

13e=

Responses from the CnC have the following pattern:

We can observe the bot downloading in chunks some encrypted content (probably the payload/bot update):

It also periodically uploads the stolen data. In the example below: sending the report about the logged user activities (content of the previously mentioned file keys.c):

After defeating the first layer of protection, we can see a new PE file. It is wrapped in another protective stub – this time typical for this version of Diamond Fox. The executable has three unnamed sections followed by a section named L!NK. The entry point of the program is atypical – set at the point 0.

It makes loading the application under common debuggers a bit problematic. However, under a disassembler (i.e. PE-bear) we can see, where this Entry Point really leads to:

The header of the application is interpreted as code and executed. Following the jump leads to the real Entry Point, that is in the second section of the executable:

I changed the the executable Entry Point and set it to the jump target (RVA 0xEDB0).

Saved application could be loaded in typical debuggers (i.e. OllyDbg) without any issues, to follow next part of unpacking.

The steps to perform at this level are just like in the case of manual unpacking of UPX. The execution of the packer stub starts by pushing all registers on the stack (instruction PUSHAD). We need to find the point of execution where the registers are restored, because it is usually done when the unpacking of the core finished. For the purpose of finding it, after the PUSHAD instruction is executed, we follow the address of the stack (pointed by ESP). We set a hardware breakpoint on the access to the first DWORD.

We resume the execution. The application will stop on the hardware breakpoint just after the POPAD was executed restoring the previous state of the registers.

This block of code ends with a jump to the unpacked content. We need to follow it in order to see the real core of the application and be able to dump it. Following the jump leads to the Entry Point typical for Visual Basic applications. It is a good symptom because we know that the core of Diamond Fox is a Visual Basic application.

Now we can copy the address of the real Entry Point (in the analyzed case it is 0x4012D4) and dump the unpacked executable for further analysis.

I will use Scylla Dumper. Not closing OllyDbg, I attached Scylla to the running process of Diamond Fox (named s_1.exe in my case).

I set as the OEP (Original Entry Point) the found one, then I clicked IAT Autosearch and Get Imports:

Scylla found several imports in the unpacked executable:

We can view the eventual invalid and suspected imports and remove them – however, in this case, it is not required. We can just dump the executable by pressing button Dump.

Then, it is very important to recover the found import table by clicking Fix Dump and pointing to the dumped file. As a result, we should get an executable named by Scylla in the following pattern: _dump_SCY.exe.

Now, we got the unpacked file that we can load under the debugger again. But, most importantly, we can decompile it by a Visual Basic Decompiler to see all the insights of the code.

Example of the decompiled code – part responsible for communication with the CnC (click to enlarge):

Conclusion

Unpacking Diamond Fox is not difficult, provided we know a few tricks that are typical for this malware family. Fortunately, the resulting code is no further obfuscated. The authors left some open strings that make functionality of particular blocks of code easy to guess. In the next post, we will have a walk through the decompiled code and see the features provided by the latest version of Diamond Fox.

This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.