For my Malware Analysis class, my final project was to choose a malware sample from the wild and do an analysis of it. In our class we’ve been focusing on 32-bit x86 malware to make things simpler – that’s generally for Windows XP or Vista – around 10 years old or so. But while I was looking at the Zoo for 32-bit malware samples I ran across one that had been uploaded just the week before called Win32.RedDelta. I googled it and couldn’t find *any* information about it at all, and when I downloaded it the archive contained five files with apparently randomly generated names and no extensions. It seemed like a great challenge to see what I – who had never done this from scratch before – could figure out about it.
To summarize, I found an executable file made to look like a politically challenging Word document, and an accompanying DLL. If you clicked on the file it would create an actual Word document and open it so you may not realize you had just run a malicious program. Then it would call routines in the DLL to contact a website, download a malicious payload, decompress and unpack/decode it, and execute that code.
The rest of this is from my final project presentation:
The RedDelta malware sample had been uploaded to the Zoo on August 5th – just the week before.
I had been debating analyzing something like Stuxnet, but there was so much available online about it I didn’t want to duplicate other work. When I searched Google about RedDelta I didn’t found any information about it whatsoever.
I downloaded and unzipped the archive and found five files with seemingly random names, no extensions or other identifiable information.
This seemed like an interesting challenge, so I decided to go for it. I re-numbered them smallest to largest
and just started working my way down the list.
Going down the list – File #1:
Using PEview and Ida Pro, I can see that File #1 is a DLL with process handling and file handling imports:
It also has exports, seemingly randomly-named:
Using strings, you can see references to KERNEL32.dll, and hex.dll:
Going down the list – File #2:
File #2 also appears to be a DLL – lots of Word-related strings, and a document name. It has process and module-loading imports, and again, seemingly randomly-named exports.
You can see a lot of strings that look related to Word documents, and in fact can see an intriguing document name:
Going down the list – File #3:
File #3 is a DLL almost identical to file #2 – the same Word-related strings and the same number of imports/exports, although the random names are different and we see a different document name – apparently in Italian.
Going down the list – File #4:
File #4 turns out to not be a Windows’ PE file at all – it looks like a zip archive based on the PK/ZF strings and now-familiar filenames:
We’ll come back to this…
Going down the list – File #5:
File #5 looks like a 64-bit executable. At the time I wasn’t equipped to examine this safely – we were using an XP virtual machine with a 32-bit version of Ida Pro. I’m currently setting up a 64-bit image with malware analysis tools, will get back to this one in Part 2.
You can see a libcurl reference and some network-related error messages though:
Back to File #4 – File 4-1:
Ida pro confirms that File #4 is an archive:
Ida pro will apparently analyze the contents in the archive, but I rename the file with a .zip extension and Windows is happy to unzip the two contained files:
File 4-1, while taking pains to appear like a Word document, is actually an executable. It has a Word document icon, but an .exe extension.
Strings shows a reference to wwlib.dll (File 4-2), KERNEL32.dll and process-managing routines, and randomly-named functions like we saw in the DLLs:
The imports list shows some process-handling and DLL loading routines – but the most interesting/suspicious ones are IsDebuggerPresent() – indicating it’s looking to see if it is being analyzed in a debugger so it can act differently – and VirtualProtect(), which can change the permissions of memory contents.
Back to File #4 – File 4-2:
File 4-2 is called wwlib.dll, which sounds like it could be an innocuous Windows DLL, but isn’t.
These imports, exports and strings are starting to look familiar:
Decision Time:
Having looked at the original five files, it appears we have three similar versions of the same DLL, one different DLL, a 32-bit executable and a 64-bit executable.
I decided to just focus on the two extracted files as they had names and I’m reasonable sure they belong together – were likely extracted from the same host machine.
I’ll come back to the different DLL and the 64-bit executable in Part 2.
File 4-2 – wwlib.dll Static Analysis:
Starting with wwlib.dll, I loaded it into Ida Pro. It has no idea what the functions should be called, so calls them sub_<address>. Over the course of my time with it I examined and renamed all the functions with what I determined they were about:
The first thing I noticed is that the malware uses this string-hiding method to hide the names of the external functions it calls – it builds the name from individual characters stored in memory so they’re not visible with a strings-type tool. It uses this method *everywhere*, for every external function call:
This code must be the result of a compiler or automated post-processing as it is inefficient and inconsistent. Some letters have a second level of indirection with being stored in a register, but it doesn’t really stop you from figuring out what they are. Also different instances of the same string hide different letters, so if you see the same similar name multiple times you can determine all the letters.
This one decoded to InternetCrackUrlA() in the wininet library.
After decoding all the references, you can now see the true list of imports – all the handle variables created to hold handles to DLLs and functions with hidden names:
There’s lot of interesting internet-related calls, along with memory allocation, resource handling, and we see VirtualProtect() again.
File 4-1 – *.exe Static Analysis:
I did the same function analysis and renaming as I did to the DLL. There weren’t as many functions (some were just one-line functions that called other functions and weren’t worth renaming) and the executable didn’t use the same string-hiding technique so my guess is that it was compiled separately.
You can see some calls that register the DLL with the operating system, and CheckDebuggerPresent() again.
This function appears to be the code that actually registers wwlib.dll with the OS. The hexadecimal string is a provided Component ID:
The malware appears to use a performance counter check to see if it is running on a virtual machine, but there are still some things I don’t understand here.
… I don’t understand why it’s xor-ing the ESP register value with the stored performance counter result and then checking it against the original value.
At any rate the malware is expecting a particular value, and if it doesn’t see that value it calls a function which ends in terminating the process before it does anything.
The IsDebuggerPresent() check seems to be intended to actually help with debugging while developing the malware, rather than hindering reverse-engineering of it. It seems to raise an exception with the debugger to halt execution just before terminating the process.
This next code block appears to be the core functionality – really the entire point of the malware. This is where the malware execution is transferred to the code that was downloaded from the website. Malware has copied the result of it’s unpacking/decoding routines into memory, called VirtualProtect() on that memory space to make it executable, and then (at 0x1000141B) makes a “call esi”, which tranfers execution to the address of the (now executable) memory block.
0x40 = PAGE_EXECUTE_READWRITE
File 4-1 – *.exe Dynamic Analysis – Executing the executable:
I set up Process Explorer and Process Monitor, Wireshark, ApateDNS and regshot.
When you double-click on the file, the malware executable runs and immediately creates a file with the same root name that looks like a Word doc –
and then it exits after a few seconds. I couldn’t see any sign that the DLL or a new process is still running – perhaps I failed the performance check.
I had to install 32-bit Word reader and some compatibility updates, but was able to open the .doc file in my secure environment:
I have no idea about the accuracy of the contents of this file, but it doesn’t really matter. The important thing to me is the date – the date indicates the malware was created in the last 3-4 months. The .doc didn’t ask me to enable macros or anything. Later I realized that if I had had the Word reader installed already it would have opened the file before exiting – so I think the Word .doc exists solely to give the impression that you did, in fact, open a Word document as intended instead of what you actually did – run a malicious executable.
File 4-1 – *.exe Dynamic Analysis – Debugging with Ollydbg:
I set breakpoints around the CheckforDebugger() calls:
The call for the routine that I think installs wwlib.dll:
The call to the DLL’s FMain() function:
And a function that does some sort of transform on the downloaded data:
Execution stopped at the breakpoint just before the ShellExecute() call:
This is the code that opens the Word .doc that it created in order to make it look like we actually clicked on a Word doc file instead of a malicious executable.
Tracing through the program enabled me to reach some of the conclusion I’ve detailed above.
Conclusions:
In the original archive we appear to have a 32-bit version of the loader, I’m guessing a 64-bit version of the loader (File #5), three different versions of “wwlib.dll” (Files #2, #3, and #4-1), and another DLL I haven’t looked at yet (File #1). Given the two different documents we saw reference to (one related to Hong Kong, one related to Islam), the files appear to be a ruse to get people of different nationalities/religions to run the executable, and hide the fact that they did anything other than opening a Word document.
The executable appears to simply exist as a loader to install and execute the DLL, and the DLL appears to simply download code from a website and execute it. If the website is unreachable the malware doesn’t appear to be able to do anything to maintain presence or re-try the connection.
Analysis still to do:
I didn’t see that the DLL was executing in a resident process on my machine after execution. Further debugging is necessary to study and see if bypassing the performance monitor checks allows persistence. It’s possible there isn’t really any persistence yet though, that that would be handled by code that is downloaded and executed.
There is a dense block of assembly in the DLL that calls an external function to decompress and then does an internal transform (unpacking or decoding) on the data received over HTTP. The URL is not active anymore, so opening the HTTP session fails. I’d like to set up a server with a fake hk.dat file and trace what the DLL does with the data.
Likewise, I can’t exercise the code that transfers execution to the downloaded code block without a block of code to try. I would love to find a wild copy of hk.dat.
I plan to spin up a secure 64-bit environment to examine the 64-bit executable/loader.
I will also examine DLL File #1.
Other Analysts:
After determining the full URL the malware was trying to access, I was able to search for ‘hk.dat’ and found one reference to someone on Twitter doing their own analysis of this malware:
Thank you for reading! It was really fun to find out that I had the skills to grab a sight-unseen recent malware – created just in the last few months – and be able to figure out what it was trying to accomplish and how it worked.
I will continue the analysis of the other files in Part 2!
zerosquared.io 