By: ThreatLabz

In The Wild Flash Exploit Analysis – Part 2

Exploit

In the first blog, we talked about how a recent Flash exploit works using heap spraying. In this blog, we will see how the shellcode functions and how it downloads malicious binaries to an infected system. If you remember, malicious shellcode was loaded on heap by the exploit. So let’s try to see if we can identify strings or URLs in the loaded shellcode. If you look closely, the shellcode is not in a readable format and appears to be encoded. Here is the how shellcode looks:

There is no single identifiable string in the shellcode. Let’s debug this shellcode further to understand if it is encoded or not. When we left off in the last blog, we were at a “CALL EAX” instruction with EAX pointing to 08080808. If we press F9, we will land on the heap and start executing every NOP instruction until ultimately reaching the malicious shellcode. We will reach the first instruction of the shellcode by putting a hardware breakpoint in the shellcode. Here is another screenshot of the debugger:

The shellcode contains some unused instructions and it will be difficult to understand it simply using static analysis. Let’s start debugging step by step. The first few instructions are the same and will POP EAX from stack. Then there is short jump call to 08089C42, which will call the address 08089C32. At which point it will XOR the ECX value and push a value of 3B8 (decimal 952) into CX. Then there is small loop, which is very interesting.

08089C3A 80340B BD XOR BYTE PTR DS:[EBX+ECX],0BD

08089C3E ^E2 FA LOOPD SHORT 08089C3A

The first instruction is XORing every byte with 0BD from the last byte i.e. starting from value (EBX+ECX) until the current EBX value as ECX will start decrementing. This is the method used to encode the original shellcode. After exiting from the loop, we land into decoded shellcode which can now be reviewed. Here is the XOR’ed version of original shellcode:

Gr8! Every instruction is now readable and easy to understand. We can now attempt to identify strings. I went into a memory dump of the heap and converted instructions into Hex/ASCII format. Here, I was able to find some known strings and one URL at the end. Here is the ASCII dump:

Now, this looks pretty straightforward. The above decoded shellcode is going to download “css.exe” to the infected system. At this point, I downloaded the malicious file. Let’s open it in OllyDbg and try to find some additional strings and to see what that executable is doing. I quickly looked at the disassembly and was able to quickly realize what the file is doing. I found an additional URL request in the code:

This executable downloads additional malware by visiting “hxxp://www.ffxiname.com”. Then it will add some registry values and run library “C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\300056251037don.dll,Set1” using "C:\WINNT\System32\rundll32.exe”. The TEMP directory will be full of additional malicious executables and DLL’s. The website in question (“ffxiname.com”) appears to be a drop zone, containing numerous additional exploits. The site will deliver different exploits based on the browser issuing the request. Here are some wireshark packet captures from the website:

The site is exploiting browser specific vulnerabilities to push additional malware. This is not the end of this process. It also downloads,

hxxp://www.40sys40.cn/txt/a1.exe

hxxp://www.40sys40.cn/txt/a2.exe

hxxp://www.40sys40.cn/txt/a3.exe

hxxp://www.40sys40.cn/txt/a4.exe

Additionally, two DLL’s are downloaded into the temp folder. The names of the files are “231053kou.dll” and “231054eve.dll”. Based on strings identified in the DLLs, it appears that they are used to sniff passwords for various web domains as can be seen in the following screen capture:

 

As can be seen, the initial infection due to the Flash vulnerability is only the start of the process. Successful exploitation leads to additional malicious binaries being downloaded to the infected system. The exploit also led to the installation of malicious DLL’s, which steal valuable information such as login credentials when you visit popular web sites.

That’s it for this series. Remember, this chain of infection was triggered when a victim with a vulnerable Flash Player simply viewed a single malicious page – no user intervention was required. This also shows that how active Flash exploits are in the wild. Keep your systems/AV up to date and install latest Flash Player from Adobe.

Be Safe,

Umesh

Learn more about Zscaler.