RedKit Payload - Binary Fun
Before I jump into this blog post, I'd like to point out some interesting developments with the RedKit exploit kit. Specifically, the authors changed the color!
Anyways, my coworker Arseny Levin was nice enough to supply me with a sample executable from this recently discovered exploit kit. This executable was the payload component that gets dropped on the victim's machine in the event that an exploit was successful in this particular instance. As the exploit kit can be purchased by anyone, the attackers may upload any executable, or piece of code they wish.
A post published at 'Malwares don't need Coffee' (see this link) reveals the FAQ that was released with the exploit kit. Please do not navigate to any of the links referenced in the FAQ unless you are running in a sandboxed environment, as these links may contain malicious elements. The following excerpt appears inside the FAQ:
Не подскажете — где криптануть EXE-файл (DLL-файл)?
Мы рекомендуем крипт-сервис http://livefreeteam.ru/ (жаба: LiveFreeTeam@jabber.ru).
Roughly translates to the following:
Do not tell - where kriptanut EXE-file (DLL-file)?
We recommend that the crypts service http://livefreeteam.ru/ (Toad: LiveFreeTeam@jabber.ru).
It is likely that this service was utilized to obfuscate the malware we will be analyzing, thus explaining the obfuscation we shall witness. While we cannot be certain, it is typical for clients to follow the advice given to them by the exploit kit authors.
So let's begin…
The file is named 'setup.exe' to avoid suspicion, and is configured with a shield icon (likely to immitate some form of protection software, such as anti-virus).
Digging into the file, we quickly discover that some form of packing and/or crypting is taking place. Again, it is likely the result of the crypting service mentioned above. Some clues to this include the small number of functions being loaded in the imports table, along with this wonderful blob of data that is placed in the middle of the executable.
Static analysis proves to be little help in this situation, as there are a large number of functions being daisy-chained together. Instead, we'll move to dynamic analysis to get a better understanding of what is going on. I should point out that static analysis is not impossible, but in order to save on time in this particular instance, dynamic analysis will provide more 'bang for our buck'. Once we get through a lot of, for lack of a better word, garbage, we come to the following:
One thing that is completely whacky about the image above is the use of the hFile argument. According to MSDN, this parameter is reserved for future use and must be Null. Clearly something else is happening here, so let's dig in further.
We begin by seeing three values (6AC, 6AC, and 40001) being pushed on the process's stack.
The process proceeds to move 861C95C6 to the EAX register. Once this is complete, the value of 7A239A86 is added to 861C95C6, and the resulting value is pushed to the stack. We see this value is pointing to the kernel32.HeapCreate function. Once this occurs, the malware subtracts 2 from the recently pushed kernel32.HeapCreate value. This results in a value of 7C812C54.
If we inspect this location in memory, we can see that the HeapCreate function is prepended with NOPs, or 'No Operation'. In layman's terms, these opcodes do nothing.
Next we witness the malware move the previous 7C812C54 value to the memory location EAX is pointing to. In other words, we're not copying 7C812C54 to EAX, but instead copying that value to 0040300C. We can see this below. The value is reversed due to the endianness.
Finally, we see a call to, what Ollydbg believes is, LoadLibrary.
However, we discovered earlier that 7C812C54 is actually pointing to kernel32.HeapCreate minus 2. As we continue to follow the flow of execution, we reach the call to RtlHeapCreate, with the following arguments:
RtlHeapCreate(00041001, 00000000, 00001000, 000006AC, 00000000, 00000000)
From the Microsoft documentation, we discover that by setting a null value for the 2nd argument, we're allocating system memory for the heap from the process's virtual address space.
We see this space allocated in memory below:
As we continue to debug the setup.exe executable, we see the blob of data from earlier is de-obfuscated and written to memory in the space previously allocated:
The executable then proceeds to call this block of code at 009D0000:
This is where the real purpose of the executable is revealed. We see the un-obfuscated code immediately begin loading functions from a number of libraries. The malware then takes the code that was previously copied in memory, and makes a copy of that elsewhere, after it allocates space using the VirtualAlloc() function:
Resulting memory block:
After this is performed, the malware's flow of execution continues in the context of this new space in memory. We then continue on, and discover that the malware attempts to download a 'newm001.exe' file from one of two domains.
Please note the shortened header in the above PCAP, which often can provide clues to the malicious nature of the request. In the event that setup.exe cannot find the malware from the first domain, it will sleep for 10 minutes before attempting to download it from the other domain. This process repeats until successful. Once the malware is successful in downloading the executable, it writes it to the victim's TEMP directory as an ambiguous name (in this case 'temp54.exe'), before executing it in the context of setup.exe.
At this point, the second stage of the payload is executed.
As we continue to analyze the newly downloaded executable, we quickly realize that the same method of obfuscation is utilized that we saw in setup.exe. Unlike setup.exe, this malware extracts a UPX-packed executable into memory, and proceeds to execute this file. I shall not go terribly in-depth into this sample, as it is a well-known executable that has been seen many times before. An example variant of this file can be found here, at ThreatExpert. A good method of identification is the creation of the following registry keys:
- HKEY_CURRENT_USER\Software\Amd\DBID
- HKEY_CURRENT_USER\Software\Amd\DB
- HKEY_CURRENT_USER\Software\Amd\DB2
- HKEY_CURRENT_USER\Software\Amd\DB3
Some highlights for this malware include:
- Searching victim for passwords in well-known software packages
- Looking for bitcoin wallets
- Sniffing traffic for unencrypted data (SMTP, Telnet, FTP, etc.)
At this point we've achieved a good grasp on both what the malware is doing, as well as the methods in use for obfuscation. While this is just an example of what the RedKit (Or shall we just start calling it Chameleon?) exploit kit is capable of delivering, I hope it provides some insight for any readers as to the capabilities, and the dangers, users face on a daily basis.