Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

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-файл)?

Мы рекомендуем крипт-сервис (жаба:

Roughly translates to the following:

Do not tell - where kriptanut EXE-file (DLL-file)?

We recommend that the crypts service (Toad:

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

Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More