Cisco Blogs


Cisco Blog > Security > Threat Research

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:

Read More »

Tags: , , ,

A Circular Problem in Current Information Security Principles

Editor’s Note: In this second installment of the blog series on more responsive security, we take a closer look at the circular problems associated with four common security principles in managing “weak link” risks in Information Technology organizations.

Before discussing what constitutes this responsive approach to security, let us first look at a few of the fundamental principles of information security to understand the unique challenges organizations face today in managing security risks.

Read More »

Tags: , , , ,

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.

Read More »

Tags: , , , , , , ,

A Model for Evaluating Breach Detection Readiness

Given that modern attacks are complex and sophisticated, there is not a single product or tool that will ever be 100% effective at detecting threats. Prevention eventually fails. Therefore, you need protection before, during, and after an attack.

Modern-day networks are large and complicated. It is a nightmare for incident response teams and security investigators because it often takes days and months to identify that their networks were compromised. A wide variety of tools, technologies and platforms are available, like big data platforms, machine learning algorithms, statistical techniques, threat intelligence platforms, reputation feeds etc. It is often confusing for the decision makers to identify what is needed for their environment.
Read More »

Tags: , , ,

Reintroducing Snort 3.0

Snort 3.0

A little more than a year ago when Sourcefire became a part of Cisco, we reaffirmed our commitment to open source innovation and pledged to continue support for Snort and other open source projects. Our announcement of the OpenAppID initiative earlier this year was one of several ways we have delivered on this promise.

Today we are announcing the alpha release of a new Snort 3.0 architecture. This alpha release builds on several ideas that were part of the original 3.0 prototype developed several years ago and goes well beyond those initial concepts.

Snort 3.0 expands on the extensible architecture users have come to know and includes several new capabilities that make it easier for people to learn and run Snort. We encourage you check out it out at www.snort.org, give us your feedback and help us build a strong foundation for the future. As Joel mentions in his post, this is a very early release that is intended for community feedback more than anything else.

When I first began building Snort, I architected it so that we could continue to extend it over time. By working with the Snort community, it quickly evolved from the initial primitive idea of an easy-to-use intrusion detection engine to the powerful traffic analysis and control capabilities we have today. With millions of downloads and hundreds of thousands of registered users, Snort is the most widely deployed IPS technology in the world and has become the standard for intrusion detection and prevention. Snort is also the foundation of Cisco’s Next-Generation IPS and is one of the core technologies that cemented Sourcefire’s position as a leader in the security industry.

Cisco understands the power of open source and how it can help customers solve tough challenges. In the coming months you’ll hear more from us about Snort 3.0 and our continued efforts to deliver meaningful capabilities that underscore this commitment.

Tags: , ,