Introduction

EquationGroup has a malware called DoubleFantasy. Sounded interesting, so I decided to go ahead and attack it and find out what it’s all about. Supposedly Kaspersky said about EquationGroup,

The Equation Group is probably one of the most sophisticated cyber
attack groups in the world; and they are the most advanced threat actor
we have seen

So let’s see what it’s all about.

I’m definitely splitting this one up into several posts because a detailed from-scratch analysis will take some time. Due to this, be ready for a more comprehensive explanation in the latter posts as at that point, I can tie it all together and explain what this thing does. Let’s look at the preliminaries:

I ran the malware executable through PE Studio first to get suspicious imports and strings. Of the ones PES identified, this is what caught my eye. Note that some of these may be harmless, but nevertheless, I flagged the below strings:

!#%’)+-/13579;=?ACEGIKMOQSUWY[]_acegikmoq
BINRES
080904b0
CompanyName
ProductName
oszhk}ny`qU_NSOSZH`kURXSKO`
SRHNSP
]_HDLNDE
actxprxy.DllCanUnloadNow
actxprxy.DllGetClassObject
actxprxy.DllRegisterServer
actxprxy.DllUnregisterServer
GetProxyDllInfo
actxprxy.GetProxyDllInfo
ole32.dll
_beginthreadex
|$$$}rstuvwxyz{$$$$$$$>?@ABCDEFGHIJKLMNOPQRSTUVW$$$$$$XYZ[\]^_`abcdefghijklmnopq
abababababab
!”#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg
!”#$%&'()*+,-./01234567
nPqNrNpKpKtJ
Uc32nbspacec97c98c99c100c101c102c103c104c105c106c107c108c109c110c111c112c113c114c115c116c117c118c119c120c121c122_0061h_0062h_0063h_0064h_0065h_0066h_0067h_0068h_0069h_006Ah_006Bh_006Ch_006Dh_006Eh_006Fh_0070h_0071h_0072h_0073h_0074h_0075h_0076h_0077h_0078h_007
9h_007AhFLW33abcdefghijklmnopqrstuvwzyz. ABCDEFGHIJKLMNOPQRSTUVWXYZ. 1234567890.
ABOVE 341 bytes^

abcdefghijklmnopq
IsBadWritePtr
GetCurrentThread
FindFirstFile
CompareFileTime
CreateMutex
SetEntriesInAcl
AllocateAndInitializeSid
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
DeleteService
OpenService
OpenSCManager
NtCreateSection
NtMapViewOfSection
ReadProcessMemory
AdjustTokenPrivileges
LookupPrivilegeValue
OpenProcessToken
OpenThreadToken
DeleteFile
GetCurrentProcessId
GetCurrentProcess
GetCurrentThread
GetWindowsDirectory
GetTempPath
GetModuleFileName
AccessCheck
msvcp5%d.dll
PsDereferencePrimaryToken
PsReferencePrimaryToken

As we can see, there are a lot of goodies up above, such as thread creation, possible privilege escalation, creating or modifying of some dll file called msvcp5(some number).dll, Common Object Model usage, service creation, file reading and writing, possible shellcode text, and I even found ntoskrnl.exe (Windows Kernel) functions PsDereferencePrimaryToken and PsReferencePrimaryToken, which indicate some sort of driver or low-level code because that is Kernel-Mode code. Last but not least, at the beginning of the giant string with the hex codes, there is Uc32nbspace. This one caught my eye and with a simple Google search, I found something called MicroChip ChipKIT Development Board UC32 ¹ which is just a speculation at this point, but who knows, maybe this malware targets or looks for an embedded device.

Next on the list was to try and identify any cryptography ahead of time, so I ran this thing through PEiD KANAL and came up with:

BASE64 table :: 0002B8C0 :: 0042C8C0
The reference is above.
RC5 / RC6 [Init, -Delta] :: 00027D07 :: 00428D07
The reference is above.

So we have RC6 encryption and a BASE64 encoding, which I suspected based upon a few of the strings above. Good to know.

Next on the list was checking the resources in ResourceHacker. We have 3 resources in this file named 1,2, and 4. The first two resources appeared to be some sort of encoded binary data and the third resource was, voila, an entire embedded executable file! I extraced this guy to disk, to be analyzed soon. See screenshots:

Opening the main malware executable up into IDA, I found a WinMain, and one of the first things it does is load up resource 1, copy it into a buffer, decrypt it, and then save it into memory decoded. The rest of the post will examine this process:

“1” is currently in al and pushed into the Resource Name argument before the resource is searched for.

If the “1” resource is found, the resource is loaded in the below series of API calls:

Load resource, alloc memory for size of resource

LocalAlloc is similar to malloc in that it grabs some heap memory. The reason why SizeOfResource above is run is to know how much memory to allocate in this step:

Pictured above, the malware also goes ahead and copies the resource data into the newly allocated heap memory, as shown by the arrow. It’s important to remember that LocalAlloc has returned a handle to the fresh heap memory which is inside of eax, which is then pushed to memcpy. This step is quite easy to miss as its a plain-old memcpy which does the dirty work. If this is all successful, the malware then iterates through the buffer containing the encoded data from the resource and decodes it using the below function. Note that I added some comments to explain the details, but this is just a simple xor decode:

As we see, the function adds the counter variable value to the current byte, xors it with 0x79 or 121 decimal, then moves on to the next byte. After the decode, the decoded message is placed into a buffer and returned back a couple of subroutines.

Stay tuned for more analysis of this and other malware in upcoming posts. I’ve decided to take a multi-part approach to these rather than write one ginormous page.