Wednesday, December 17, 2014

Wiper Malware - A Detection Deep Dive

This post was authored by Christopher Marczewski with contributions from Craig WIlliams

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:

Monday, December 15, 2014

Ancient Mac Site Harbors Botnet that Exploits IE Vulnerability

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.

Tuesday, December 9, 2014

Dridex Is Back, then it's gone again

This post was authored by Armin Pelkmann and Earl Carter.

Talos Security Intelligence and Research Group noticed a reappearance of several Dridex email campaigns, starting last week and continuing into this week as well. Dridex is in a nutshell, malware designed to steal your financial account information. The attack attempts to get the user to install the malicious software on their system through an until lately, rarely exploited attack vector: Microsoft Office Macros. Recently, we noticed a resurgence of macro abuse. If macros are not enabled, social engineering techniques are utilized to try to get the user to enable them. Once the malware is installed on the system, it is designed to steal your online banking credentials when you access your banking site from an infected system.

Talos analyzed three separate campaigns in the last days, all distinguishable from their subject lines.

Microsoft Patch Tuesday for December 2014: Light Month, Some Changes

This post was authored by Yves Younan.

Today, Microsoft is releasing their final Update Tuesday of 2014. Last year, the end of year update was relatively large. This time, it’s relatively light with a total of seven bulletins, covering 24 CVEs. Three of those bulletins are rated critical and four are considered to be important. Microsoft has made a few changes to the way they report their bulletins. Microsoft has dropped the deployment priority (DP) rating, which was very much environment-specific and might not be all that useful for non-default installations. Instead, they are now providing an exploitability index (XI), which ranges from zero to three. With zero denoting active exploitation and three denoting that it’s unlikely that the vulnerability would be exploited. Another change is to more clearly report on how the vulnerability was disclosed: was Microsoft notified via coordinated vulnerability disclosure or was the vulnerability publicly known before being released?