This post is co-authored by Alex McDonnell, Brandon Stultz, Joel Esler, Patrick Mullen, Armin Pelkmann, and Craig Williams
When the Internet Explorer 0-day CVE 2014-1776 was announced, we turned to our intelligence feeds for more information. In the course of taking it apart we found a few things that were quite interesting that we wanted to share.
dword2data" and "
arrLen" showing up without so much as a base64 encoding in sight.
The only thing that was not apparent was where our exploit condition was. It looked to be missing completely. Upon closer inspection we noticed one function that was not being called from the script at all,
oil(). The function takes a parameter in string form and runs
eval() on it. That looked like the missing piece of the puzzle, and we thought if we could find out how oil was called and what was passed to it we could detect it. The sample had an accompanying flash file that we believed was used to spray the heap, so with the html proving to be a dead end, we dove into the flash file to see if we could find out more about what makes this tick.
Examining the actionscript we saw the heap spray that we expected. Flash heap sprays in the last year or so have some commonly recognizable attributes: Their main class extends the basic class “
sprite”, they load up an array with objects and they use a dll like
msvcrt to build a ROP chain
This shellcode was different though; it was encrypted using RC4, which is an extra level of obfuscation we don't commonly see. In addition to the shellcode we also saw two variables,
m_keys that looked interesting.
m_keys is used to decode the strings that are RC4 encrypted.
m_trg however, appeared after the heapspray in an external call to "
oil". This string, once decoded was sent back out of the flash file into the html, as the parameter for the JS function "
oil". This string was then
eval'ed by the function, causing the crash. When we decoded the string, we found our IE exploit, hanging out in the Flash file, not even in the html file that it uses to exploit!
Once we decoded the shellcode, we found it was also xored. The end result is that the shellcode calls out to download a page from inform.bedircati.com.
Our data indicates our customers were targeted by this attack beginning Thursday, April 24, 2014. According to our cloud web security data we've seen a small number of companies along the manufacturing and industrial vertical targeted. The initial samples were directed at specific users by name, but, as the attack progressed, this did not stay consistent with some attempts starting simply with "Hi" or "Greetings".
We were able to identify a pattern in the malicious URLs, which we then used to extract additional malicious domains from our email telemetry system. This uncovered additional phishing attempts using an identical exploit. Due to this we believe the same group is responsible for all the attack attempts.
The regex we crafted narrowed down our search space and made it easy to focus on a set of URLs to investigate. In the image below, you'll see the results, sanitized for your safety.
Due to active exploitation uncovered among our customer base, we are releasing the following indicators about the expo it so that anyone can investigate their own environments and protect themselves:
We’ve associated the following subjects with this campaign so far:
Welcome to Projectmates!
What's ahead for Senior Care M&A
UPDATED GALLERY for 2014 Calendar Submissions
Associated domains so far:
Below are a couple sample phishing attempts:
Snort covers the IE 0-day CVE 2014-1776 and the heapspray file with signatures:
ClamAV coverage is as follows:
FireAMP, the Security Intelligence Feed (IP Blacklist) Cisco Email, and Web Security products provide coverage for this threat.
Cisco Legacy IPS also has coverage with the following signatures: 4256-0, 4256-1
Microsoft has released an out of band patch for this vulnerability: