How the Adobe 0-day is used in attacks

Matt Oh posted a great blog post yesterday about how the Adobe 0-day vulnerability works (CVE-2010-1297) and today we'll take a look at how the vulnerability is used in a live attack and how the Websense ACE technology protects customers.

The attack

So far we have only seen the vulnerability being used in targeted attacks via emails. The emails have either contained an attached PDF file that contains the exploit to force the machine to automatically download malware when opened or as in this example, contained a URL that performs a drive-by download when visited to infect the machine. This is similar to how some of the Aurora attacks took place. Below is an email that was picked up by our ThreatSeeker network:

For the exploit to work the attackers need shellcode to make the exploit do something, such as download and execute a file. When the attackers use a PDF file the shellcode is part of the PDF itself but in the drive-by scenario they're using JavaScripts in HTML pages to do it. A screenshot can be seen here of what it looks like:

Zero detection

The SWF file (Flash file) that gets pushed to the users PC is unfortunately not well detected. In fact, zero antivirus vendors detect it according to VirusTotal. Detection of the shellcode doesn't look much better either with just one vendordetecting it. We at Websense had this detected since January 5th, 2009 (that's over a year!!) thanks to our ability to do real-time scanning on web content in Websense Security Gateway. The actual malware that gets downloaded in the endisn't detected by anyone either. A quick analysis of the binary revealed it was an encrypted file with XOR 0x95, once decrypted by the shellcode the file detection is slightly improved.

The payload

In the next stage the shellcode runs the decrypted file which drops a file called iexplore.dll to %userprofile%\Start Menu\Programs\Startup\, this file is also very badly detected. After the file gets dropped its extension is changed toiexplore.exe by a batch script dropped at %programfiles%\Windows NT\cbt.bat. Then iexplore.exe attempts to open some content from hjkl.wekby.com/testaaaaaaaaa.txt with Microsoft's® HTML Help Executable located at %windir%\hh.exe (that's a legitimate file). Unfortunately, the URL wasn't responsive at the time of the analysis, but iexplore.exe constantly checks with another batch script located at %programfiles%\Windows NT\1.bat if the file gets successfully downloaded. An infected machine at this stage will have 5 files and repeated attempts to run the batch files and access hjkl.wekby.com for testaaaaaaaaa.txt, here are the system locations details and MD5s:

Encrypted executable: %userprofile%\local settings\temporary internet files\sss[1].exe c8816edfa228e460bf52eb1dbcb4a746
Decrypted executable: %userprofile%\local settings\temporary internet files\ssb[1].exe 7175b91dba6844439a94e7be2ef47059
Dropped file: %userprofile%\Start Menu\Programs\Startup\iexplore.exe 8ee79709f8c53c446eff31cdf93949fe
Batch file: %programfiles%\Windows NT\cbt.bat 6c47930dd19fa38777de8c63824f4658
Batch file: %programfiles%\Windows NT\1.bat f8e7044d6d62d42220933cf501d1b1e5

This is just one if several URLs and files we have seen used in these targeted attacks

Patch

Adobe has announced that they will release an updated Flash Player tomorrow, June 10, which will help in the drive-by scenario. The PDF attack vector will remain open until June 29 when the updated version of Adobe Reader/Acrobat will be made available. Until then, use extreme care when opening PDF files from unknown sources. Adobe has posted some possible workarounds in their advisory.

This post has been updated with information about the payload.