Flash Malware Propagating via CDN

Published by Torry Crass on

Final Update: I thought I would post one more update to this, as of the middle of April 2015 an analysis of the same malware indicated almost all AV instances picking it up and identifying it as a Cryptowall variant. In addition, it should be noted that after I contact Rackspace about the malware they did take a look and remove the file from their CDN.

Important Update: After some further analysis and much thanks to @Kafeine, I agree that this is probably not CVE-2015-0313. He suggested it may be CVE-2014-0569 (which I've not looked at yet) but after decompiling the initial SWF, I'm finding references to a couple 2012 vulnerabilities. Based on signatures in the file, DoSWF was used to obfuscate some of the code and the swf file does perform some calls to cmd.exe files with a focus on Python and PHP, per Malwr.com. In any case, this bug made it onto a Content Distribution Network and as of today, still isn't being picked up by signatures, per Malwr.com analysis at mid day on February 9th.

I will work on better due diligence on things like this in the future.


Last night alerts came through that suspicious flash activity was happening in user traffic. After some investigation it was quite clear that someone was using the latest Adobe Flash 0-day (CVE-2015-0313) in order to spread some bugs around. The bugs being spread are related to Flash vulnerabilities, however, so far, specific CVE relation has not been definitively determined.

I was hoping to have this shared a little bit sooner but thought it still might be of use to some since these bugs still might be going around. Especially since the files being distributed are STILL not being picked up by AV clients. As of noon today, only 1 of more than 50 AV clients detected the swf file as malicious and the results were not much better for the php malware.

The main distribution point seen is coming from an account on the Rackspace Content Distribution Network (rackcdn.com). This URL has a malicious flash file which across 2 days hasn't changed, seen below:

hxxp://0683f75aacab1fd008e9-c68beaf8dcca0cd5f77493a027ad6d0c.r84.cf2.rackcdn.com/user_6290_camp_3709_e4205a6204a67af089ee2c41a6fe6ab6.swf

https://malwr.com/analysis/OWQ5MGM2YmM3NTY2NGVkODg1YWQ2OWViYzA0YzM0MDI/

Once the flash file is on the system it dumps malware that then calls out to pull down additional payload which looks similar to that seen below.

hxxp://198.55.119.126/jag200p15co/ee2un066aepv4.php

The php file is actually a Windows malware executable. As you can see below, it dumps out some more fun for us!

cmdline: cmd.exe /c C:\Users\admin\AppData\Local\Temp\xzhian.exe
md5sum: ad7b9c14083b52bc532fba5948342b98
sha1sum: ee8cbf12d87c4d388f09b4f69bed2e91682920b5

Best Current Remediation

To mitigate, you'll need to handle the rackcdn.com URL, this may (until they change it) take care of the problem. The best way found is to add it to be filtered out at any edge proxy solutions you might have, or by adding it to any form of URL blocking/blacklisting you might have. In addition, I'd also consider blocking, at the same, or, at the firewall the distribution IP addresses, which, so far, include the following:

198.55.119.125
198.55.119.126
198.55.119.127
198.55.119.129

The main reason for blocking the 198's at a firewall is because it looks like the pull on the payload is not passing back through proxy filters consistently and even if blocked at the proxy, may still get through.

As of right now, I don't have any additional analysis of this. After all, I do have a day job to keep in mind. 😉 If I come up with more, I'll update this article.

 

Update:

Additional locations to block where the malicious file was identified at (I'm sure there were more but this is what I had available):

hxxp://66.55.129.199/jag200115ab/ee2un066aepv4.php
hxxp://ads.securebanners.biz/bu3012kkk14/ee2un066aepv4.php
hxxp://mediafl0w.org/calv21jan02/ee2un066aepv4.php
hxxp://198.55.119.129/ja200p15gtuiyr/ee2un066aepv4.php
hxxp://host4adz.com/ma08ja15r3/ee2un066aepv4.php

Extra analysis:

https://malwr.com/analysis/ZGE5YmMwNTg4ZGNmNDVjMzgyMjQyNjI5ZDdlMzQwMmM/
https://malwr.com/analysis/NjRkZGVlMzg4ODcxNDRiZGJmZWQxYmY3N2NhNTRlN2Y/
https://malwr.com/analysis/OTk2N2EyMmNkODAxNGE0ZGFkNGM1ODdhNDM2MWEyZjc/


1 Comment

Torry Crass · April 2, 2015 at 3:42 pm

For anyone looking at this that would like a great follow up article on this little gem check out the great post that Denis O’brien has written on his blog: http://malwageddon.blogspot.com/2015/03/data-obfuscation-now-you-see-me-now-you.html

Leave a Reply