In February, Cisco Managed Threat Defense (MTD) security investigators detected a rash of Dridex credential-stealing malware delivered via Microsoft Office macros. It’s effective, and the lures appear targeted at those responsible for handling purchase orders and invoices. Here’s a breakdown of the types of emails we’ve observed phishing employees and inserting trojans into user devices.
Cisco Talos is aware of the public discourse surrounding the malware family dubbed “The Equation Family”. As of February 17th the following rules (33543 – 33546 MALWARE-CNC Win.Trojan.Equation) were released to detect the Equation Family traffic. These rules may be found in the Cisco FireSIGHT Management Console (Defense Center), or in the Subscriber Ruleset on Snort.org. Talos security researchers have also added the associated IPs, Domains, URLs, and hashes to all Cisco security devices to provide immediate protection across the network. Talos will continue to monitor public information as well as continue to independently research to provide coverage to this malware family.
Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.
While email has not been observed as an attack vector, ESA is capable of blocking the malware used in this campaign.
The Cisco 2015 Annual Security Report highlights many creative techniques that attackers are exploiting to conceal malicious activity, often taking advantage of gaps in security programs. They are continually refining and developing new techniques to gain a foothold in environments and, increasingly, they are relying on users and IT teams as enablers of attacks to persistently infect and hide in plain sight on machines.
Given this complex and dynamic threat landscape, organizations need a mature and adaptable incident response process.
Advanced malware is dynamic, elusive, and evasive. Once it slithers into the organization’s extended network, it can very quickly proliferate, cause problems, and remain undetected by traditional point-in-time security tools. These tools poll or scan endpoints for malware or indicators of compromise at a moment in time, and then do not evaluate again until the next big scan is triggered.
To prevent a malware intrusion from becoming a full-fledged and costly breach, it is important to catch that malware as quickly as possible. To do that, you need to go beyond point-in-time tools, and instead continuously watch and analyze all file and program activity throughout your extended network, so that at the first glimpse of malicious behavior you can contain and remediate immediately.
*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: