This post was authored by Nick Biasini, Earl Carter and Jaeson Schultz
Flash has long been a favorite target among Exploit Kits (EK). In October 2014 the Angler EK was believed to be targeting a new Flash vulnerability. The bug that the Angler exploit kit was attempting to exploit had been “accidentally” patched by Adobe’s APSB14-22 update. According to F-Secure, the vulnerability that Angler was actually attempting to exploit was an entirely new bug, CVE-2014-8439. The bug was severe enough that Adobe fixed it out-of-band.
Fast forward to January 2015. With the emergence of this new Flash 0-day bug, we have more evidence that the Angler Exploit Kit developers are actively working on discovering fresh bugs in Flash for themselves. The group is incorporating these exploits into the Angler EK *before* the bugs are publicized. Considering these 0-day exploits are being used alongside one of Angler’s preferred methods of distribution, malvertising, thus intensifying the potential for large-scale compromise. Read More »
Tags: 0-day, angler, exploit kits, Talos, Threat Research
This post was written by Yves Younan.
Microsoft’s first Update Tuesday of 2015 is pretty light, there’s a total of eight bulletins, all covering a single vulnerability. Seven of these bulletins are rated as important and just one is rated critical. No bulletin for IE is being released this month. Two of the vulnerabilities were publicly disclosed prior to today, while another one was being actively exploited by attackers.
Microsoft made a number of changes to Update Tuesday last month, such as dropping deployment priority in favor of their exploitability index (XI). This month more changes were made to the program: Microsoft is no longer providing their Advance Notification Service (ANS) to the general public, but is instead only providing it to premier customers.
Read More »
Tags: 0-day, coverage, ms tuesday, rules, security, Talos
This post was authored by Andrea Allievi and Earl Carter.
Ransomware holds a user’s data hostage. The latest ransomware variants encrypt the user’s data, thus making it unusable until a ransom is paid to retrieve the decryption key. The latest Cryptowall 2.0, utilizes TOR to obfuscate the command and control channel. The dropper utilizes multiple exploits to gain initial access and incorporates anti-vm and anti-emulation checks to hamper identification via sandboxes. The dropper and downloaded Cryptowall binary actually incorporate multiple levels of encryption. One of the most interesting aspects of this malware sample, however, is its capability to run 64 bit code directly from its 32 bit dropper. Under the Windows 32-bit on Windows 64-bit (WOW64) environment, it is indeed able to switch the processor execution context from 32 bit to 64 bit.
Read More »
Tags: Cryptowall, ransomeware, reverse engineering, Talos, Threat Research
This post was authored by Christopher Marczewski with contributions from Craig WIlliams
*This blog post has been updated to include Command and Control IP addresses used by the malware.
A new piece of wiper malware has received quite a bit of media attention. Despite all the recent press, Cisco’s Talos team has historic examples of this type of malware going back to the 1990s. Data is the new target, this should not surprise anyone. Recent examples of malware effectively “destroying” data -- putting it out of victims’ reach – also include Cryptowall, and Cryptolocker, common ransomware variants delivered by exploit kits and other means.
Wiping systems is also an effective way to cover up malicious activity and make incident response more difficult, such as in the case of the DarkSeoul malware in 2013.
Any company that introduced proper back-up plans in response to recent ransomware like Cryptolocker or Cryptowall should already be protected to a degree against these threats. Mitigation strategies like defense in depth will also help minimize the chance of this malware reaching end systems.
The Deep Dive
Initially we started investigating a sample reported to be associated with the incident to improve detection efficacy. Based off our analysis of e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a we were able to link 0753f8a7ae38fdb830484d0d737f975884499b9335e70b7d22b7d4ab149c01b5 as a nearly identical sample. By the time we reached the network-related functions during our analysis, the relevant IP addresses belonging to the C2 servers were no longer responding back as expected. In order to capture the necessary traffic we had to modify both of the aforementioned disk wiper components. One modification replaced one of the hard-coded C2 server IP addresses with a local address belonging to a decoy VM while changing references to the other hard-coded addresses to point to this local address instead. The other modification simply changed the parameter being passed to an instance of the Sleep() function so debugging efforts wouldn’t be put on hold for 45 minutes (the original sample used a 10 minutes sleep).
When we initially examined a rule that was being distributed in the public we were looking for areas where we could improve coverage to better protect our customers. The new Wiper variant is poorly written code and luckily includes very little obfuscation.The author(s) made the mistake of allocating a buffer for the send() function that surpasses the data they wished to include in the payload: a null-terminated opening parentheses byte, the infected host’s local IP address, and the first 15 bytes of the host name. This incorrect buffer allocation results in the desired data, in addition to some miscellaneous data already present on the stack (including the 0xFFFFFFFF bytes we alerted on in the first revision of our rule).
Simply running the disk wiper component on different versions of Windows proves the miscellaneous data from the stack that we onced alerted on only applies to beacons being sent from Win XP hosts:
Read More »
Tags: APT, malware, security, Talos
This post was authored by Alex Chiu and Shaun Hurley.
Last month, Microsoft released a security bulletin to patch CVE-2014-6332, a vulnerability within Windows Object Linking and Embedding (OLE) that could result in remote code execution if a user views a maliciously crafted web page with Microsoft Internet Explorer. Since then, there have been several documented examples of attackers leveraging this vulnerability and attempting to compromise users. On November 26th, Talos began observing and blocking an attack disguised as a hidden iframe on a compromised domain to leverage this vulnerability and compromise Internet Explorer users.
Read More »
Tags: botnet, cnc, Exploit, IE, malware, security, Talos, vulnerability