Oh, how procrastination gets all of us! April 15th is the U.S. tax deadline and it looks like most of us will be coming down to the wire on declaring our taxes and holding our collective breath in expectation of that sweet, sweet refund. Sadly, our malware writing friends are aware of this and their discipline has proven far superior. Knowing that many are on the lookout for emails from the Internal Revenue Service concerning pending refunds, criminals have crafted some of their own:
The attachment is actually a Trojan-Downloader.MsWord.Agent malware, built by the same group behind the recent LogMeIn malicious campaign described here.
The infection scheme is very similar to the aforementioned, however, the threat actor has moved on from abusing Pastebin entries and has instead hacked a Web server in China to host the instructions script file. This file as well as the download URL are also encoded in Base64 and the resulting payload is actually ransomware.
URLs embedded in the malicious macros leading to a Base64 encoded instructions script file and the payload URL below
Instructions files with the URL to the ransomware payload
The malicious ransomware payload is detected by Kaspersky Anti-Virus as Trojan-Ransom.Win32.Foreign.mfbg
Due to the reliance on the IRS branding, this particular malicious campaign is mostly focused on US citizens and permanent residents of the USA.
Some months ago we wrote a blog post about CoinVault. In that post we explained how we tore the malware apart in order to get to its original code and not the obfuscated one.
So when were contacted recently by the National High Tech Crime Unit (NHTCU) of the Netherlands' police and the Netherlands' National Prosecutors Office, who had obtained a database from a CoinVault command & control server (containing IVs, Keys and private Bitcoin wallets), we were able to put our accumulated insight to good use and accelerate the creation of a decryption tool.
We also created a website and started a communications campaign to notify victims that it might be possible to get their data back without paying.
To build the decryption tool we needed to know the following:
- Which encryption algorithm was being used?
- Which block cipher mode was being used?
- And, most importantly, what malware are dealing with?
There was obviously no time for "hardcore" reverse engineering, so the first thing we did was run the malware sample to see what it was doing. And indeed, just as we thought, it was another CoinVault sample. The next thing we did was open the executable in a decompiler, where we saw that the same obfuscation method was used as described in the post. So CoinVault it is. However, we still didn't know which encryption algorithm and block cipher mode it was using.
But luckily we have a sandbox! The nice thing about the sandbox is that it executes the malware, but also has the ability to trace virtually anything. We can dump files and registry changes but in this case the memory dumps were the most interesting. We knew from the previous CoinVault samples that the malware was using the RijndaelManaged class, so all we had to do was search in the memory dump for this string.
And here it is. We see that it still uses AES, although not the 128-bit block size anymore, but the 256-bit one. Also the block cipher mode has changed from CBC to CFB. This was all the information we needed to write our decryption tool.
To see if you can decrypt your files for free, please go to https://noransom.kaspersky.com
On 9 April, 2015 Kaspersky Lab was involved in the synchronized Simda botnet takedown operation coordinated by INTERPOL Global Complex for Innovation. In this case the investigation was initially started by Microsoft and expanded to involve a larger circle of participants including TrendMicro, the Cyber Defense Institute, officers from the Dutch National High Tech Crime Unit (NHTCU), the FBI, the Police Grand-Ducale Section Nouvelles Technologies in Luxembourg, and the Russian Ministry of the Interior's Cybercrime Department "K" supported by the INTERPOL National Central Bureau in Moscow.
As a result of this takedown 14 C&C servers were seized in the Netherlands, USA, Luxembourg, Poland and Russia. Preliminary analysis of some of the sinkholed server logs revealed a list of 190 countries affected by the Simda botnet.
Simba character, courtesy of Walt Disney Productions, has nothing to do with Simda botnet
Simda is a mysterious botnet used for cybercriminal purposes, such as the dissemination of potentially unwanted and malicious software. This bot is mysterious because it rarely appears on our KSN radars despite compromising a large number of hosts every day. This is partly due to detection of emulation, security tools and virtual machines. It has a number of methods to detect research sandbox environments with a view to tricking researchers by consuming all CPU resources or notifying the botnet owner about the external IP address of the research network. Another reason is a server-side polymorphism and the limited lifetime of the bots.
Simda is distributed by a number of infected websites that redirect to exploit kits. The bot uses hardcoded IP addresses to notifying the master about various stages of execution process. It downloads and runs additional components from its own update servers and can modify the system hosts file. The latter is quite an interesting technique, even if it seems deceptively obvious at first glance.
Normally malware authors modify host files to tamper with search engine results or blacklist certain security software websites, but the Simda bot adds unexpected records for google-analytics.com and connect.facebook.net to point to malicious IPs.
KL detected the #Simda #bot as Backdoor.Win32.Simda, it affected hundreds thousands victims worldwideTweet
Why is that, one might ask? We don't know, but we believe that the answer is connected with Simda's core purpose – the distribution of other malware. This criminal business model opens up the possibility of exclusive malware distribution. This means that the distributors can guarantee that only the client's malware is installed on infected machines. And that becomes the case when Simda interprets a response from the C&C server - it can deactivate itself by preventing the bot to start after next reboot, instantly exiting. This deactivation coincides with the modification of the system hosts file. As a farewell touch, Simda replaces the original hosts file with a new one from its own body.
Now, curious mind may ask: how does it help them? Those domains are no longer used to generate search results, but machines infected by Simda in the past might occasionally continue to send out HTTP requests to malicious servers from time to time, even in when exclusive 3rd-party malware is supposed to have been installed.
We need to remember that these machines were initially infected by an exploit kit using a vulnerability in unpatched software. It's highly likely that 3rd-party malware will be removed over time, but a careless user may never get round to updating vulnerable software.
In this investigation Microsoft and various law enforcement bodies completed the sinkholing process and Kaspersky Lab willingly contributed to the preparations for the takedown. That work included technical analysis of malware, collecting infection statistics, advising on botnet takedown strategy and consulting our INTERPOL partners.
Kaspersky Lab detected the Simda bot as Backdoor.Win32.Simda and according to our estimations based on KSN statistics and telemetry from our partners it affected hundreds thousands victims worldwide.
Simda is automatically generated on demand and this is confirmed by the absence of any order in compilation link times. Below is a chart generated from a small subset of about 70 random Simda samples:
Samples link times in UTC timezone
The increase in link times is most likely related to the activity of the majority of Simda victims located somewhere between UTC-9 and UTC-5 timezones, which includes United States.
Thanks to the sinkhole operation and data sharing between partners we have put up a page where you can check if your IP has connected to Simda C&C servers in the past. If you suspect your computer was compromised you can use one of our free or trial solutions to scan your whole hard drive or install Kaspersky Internet Security for long-term protection.
Kaspersky Lab products currently detect hundreds of thousands of modifications of the Simda together with many different 3rd-party malware distributed during the Simda campaign.
In December 2014 we discovered a very interesting vulnerability in the Darwin kernel, which is an open source part of Apple's two operating systems: OS X and iOS. As a result, OS X 10.10 and iOS 8 are also at risk. This vulnerability is connected with the processing of an IP packet that has a specific size and invalid IP options. As a result, remote attackers can cause DoS (denial of service) of a device with OS X 10.10 or iOS 8 installed. It means that attackers can send just one incorrect network packet to the victim and the victim's system will crash.
OS X 10.10 crash after invalid network packet processing
Using vulnerability in the Darwin kernel attackers can cause DoS of a device with OS X 10.10 or iOS 8 installedTweet
While analyzing this vulnerability we've discovered that the following devices with 64-bit processors and iOS 8 installed are affected by this threat:
- iPhone 5s and later models
- iPad Air and later models
- iPad mini 2 and later models
To understand the nature of this bug let's look at a crash dump:
Kernel stack trace
You can see from this trace that something went wrong in the icmp_error() function and it calls the panic function. This function tries to construct a new ICMP error message and resend it. This screenshot shows that the icmp_error was called after parsing packet options. The problem lies in this piece of code:
The cause of the problem
When the conditions laid down in the code are met, the panic function is engaged and the system is shut down in emergency mode. This happens because the internal kernel structures have been changed and the new buffer size is insufficient to store a newly-generated ICMP packet. To cause this, the IP packet must satisfy the following criteria:
- The size of the IP header should be 60 bytes.
- The size of the IP payload should be at least 65 bytes
- There should be errors in the IP options (invalid size of option, class, etc.)
Example of packet that cause a crash
At first glance it is not obvious how this bug could be exploited effectively. However, a true professional can easily use it to break down a user's device or even interrupt the work of a corporate network. Usually this kind of incorrect packet would be dropped by routers or firewalls but we discovered several combinations of incorrect IP options that can pass through the Internet routers.
This vulnerability no longer exists in OS X 10.10.3 and iOS 8.3. In addition, users of Kaspersky Lab's products are secured against this vulnerability in OS X 10.10 by the Network Attack Blocker feature. Starting from Kaspersky Internet Security for Mac 15.0, this threat is detected as DoS.OSX.Yosemite.ICMP.Error.exploit.