27 May Jumcar. Timeline, crypto, and specific functions. [Second part] Jorge Mieres
11 Mar Miniduke: web based infection vector Igor Soumenkov
12 Oct Stealing currency permits from the Government Dmitry Bestuzhev
10 Oct Hidden details about the last Skype spread malware Dmitry Bestuzhev
10 Nov Steganography or encryption in bankers? Dmitry Bestuzhev
19 Aug The Miner Botnet: Bitcoin Mining Goes Peer-To-Peer Tillmann Werner
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
Jumcar stands out from other malicious code developed in Latin America because of its particularly aggressive features. At the moment three generations of this malware family exist, which basically use symmetric algorithms in the first and second generation, and an asymmetric algorithm in the third. In this manner the configuration parameters are hidden, progressively increasing the complexity of the variants.
In the first generation, data is encrypted with AES (Advanced Encryption Standard). We estimate that the first variant was released in March 2012, and that other pieces of malware with similar characteristics were being developed until August of the same year. That is to say over a six month period.
In this first stage, 75% of the phishing campaigns targeted Peruvian consumers that use home-banking services. The 25% remaining targeted users in Chile.
The following diagram shows multiple instances used by the second generation of Jumcar:
Together with our partner CrySyS Lab, we've discovered two new, previously-unknown infection mechanisms for Miniduke. These new infection vectors rely on Java and IE vulnerabilities to infect the victim's PC.
While inspecting one of the C&C servers of Miniduke, we have found files that were not related to the C&C code, but seemed to be prepared for infecting visitors using web-based vulnerabilities.
The page hxxp://[c2_hostname]/groups/business-principles.html is used as an starting point for the attack. It consists of two frames, one for loading the decoy web page from a legitimate website (copied from http://www.albannagroup.com/business-principles.html), and another for performing malicious activities (hxxp://[c2_hostname]/groups/sidebar.html)
Source code of business-principles.html
Decoy webpage loaded
Identifying a botnet is not an easy task sometimes, especially when one gets lost in different components like droppers, infectors and other bad stuff. Some two weeks ago, Jose Nazario from Arbor Networks pointed me to a new varmint that appears to be another peer-to-peer bot. When executed, the program installs tons of stuff that holds a number of goodies, for example
However, we leave these aside for now and focus on the botnet's architecture instead, which is really just a channel for pushing software to infected machines. Scrabbling about in the installed programs finally brought up the actual bot, which we detect as Trojan.Win32.Miner.h. The binary has some layers of obfuscation to make analysis harder but eventually writes a UPX packed executable into a memory section from where to original binary can be restored.
One of the first things that come to attention is a list of 1953 hard-coded IP address strings that are contained in the binary. These addresses are contacted by the bot during its bootstrapping phase in order to join the peer-to-peer network.
We recently discovered a new bootkit, i.e. a malicious program which infects the hard drive’s boot sector. Kaspersky Lab detects it as Rookit.Win32.Fisp.a. The bootkit is distributed by Trojan-Downloader.NSIS.Agent.jd. The Trojan infects the computers of users who try to download a video clip from a fake Chinese porn site.
This downloader is remarkable in that it downloads other malicious programs using a NSIS engine and stores all links in the relevant NSIS-script.
Fragment of the NSIS script for Trojan-Downloader.NSIS.Agent.jd
The dropper Rootkit.Win32.Fisp.a is among the files downloaded by the Trojan-downloader. This malicious program infects the hard drive’s boot sector. More specifically, it saves the old MBR to the third sector and replaces it with its own. Starting with the fourth sector, it installs an encrypted driver and the remaining code.
Fragment from the start of the hard disk infected by Rootkit.Win32.Fisp.a
The word ‘leak’ has become rather popular in recent times, but few of us actually realize just how likely it is that our own personal information could be leaked. We protect our computers, our mobile devices, keep up to speed with the latest security issues, but there are still times when we become careless. In particular, I’m speaking about public computers like this one here:
This is a genuine public access computer I came across in a hotel I was staying at last week during a short vacation. I had to use the Internet quite urgently, and of course I understood that my personal data wasn’t completely safe and could end up in someone else’s hands. I decided to try a little experiment and the results clearly demonstrated that any of us could quite easily fall victim to our own personal ‘(Wiki)leaks’:
I’m sure very few people would want their documents, especially of this nature, falling into the hands of strangers, competitors or cybercriminals.
So, if you want to experience your own (Wiki)leaks, all you have to do is use public access computers on a regular basis at airports, in hotels, cafes, libraries etc. If you really have to use a public computer and you know a thing or two about IT security, check first of all to see if the computer is infected. Remember that antivirus scanning results don’t always reflect the real picture.
Secondly, check if the ‘save passwords’ option is activated in the browser.
Thirdly, if you are working with documents or photographs, try not to download them. Many of today’s email services allow you to work with them directly from your email account. If you do download something, don’t forget to delete it afterwards and clear it from the Recycle Bin.
It’s also worth looking at the computer itself to ensure that there are no devices between the port where the keyboard is plugged in and the keyboard itself. These devices can gather information and look something like this:
Other precautionary measures include either cleaning your Internet Activity History or, before going online, switching on the privacy mode that is included in numerous browsers these days.
I cleaned up the aforementioned computer and informed the hotel administration. I didn’t get a discount, but the hotel management was very grateful and promised that no more cybercriminals would be stealing money from their customers (although I’m not so sure about that).
On 14 January, my colleague Vyacheslav Zakorzhevsky published a blog on the dangers of using cracks and keygens.
The malware in question was primarily for stealing registration keys for popular software.
A few days ago, we found a new malicious application that disguises itself as a Kaspersky Trial Resetter (an application that can be used to reset a software evaluation period that has expired).
The new malware is detected as Trojan-PSW.MSIL.Agent.wx and only two vendors, including Kaspersky Lab, currently detect it.
The twist here is that instead of re-setting your trial period, it steals information saved on the computer, be it browser-saved passwords, or passwords saved by an application.
According to the PE header, the malicious software was created on 31 January 2011, although the first infection reports appeared on 6 February. One can only wonder how successful such an application can be? Read below to find out:
In 23 days, a total number of 1109 computers were infected with this password-stealing Trojan, with an average of 48 infections per day.
The top 5 targeted countries were:
What about the type of stolen accounts?
Among the stolen data, hundreds of website credentials were found, such as data for: web hosting, online stores, internet/mobile provider, social networks (LinkedIn, Twitter, Facebook, MySpace etc.), webmail, blogs, banking, instant messaging, online gaming etc.
Here is a list of the browsers targeted by the malicious program, as well as the number of users whose data were stolen:
Kaspersky Lab contacted the hosting provider of the drop zone who closed and deleted the accounts.
I hope these statistics will convince you that downloading pirated software is not a good idea.
1109 users who thought they were downloading a crack for a security solution ended up being infected.
It’s also clear that saving your passwords within your browser isn’t the best idea.
You may want to consider using a Password Management program, such as the Kaspersky Password Manager, which keeps all your passwords encrypted and immune to these sorts of attacks.
We are currently in the process of contacting the victims and informing them about the infection.
On Monday we were among the first to announce the appearance of Gpcode.ai, the latest variant of the notorious ransomware Trojan.
All major antivirus vendors are now aware of this nasty program, covering it in news items and providing detailed descriptions. This can only be good.
However, reading the information issued by the different vendors is more entertaining than usual. My attention was piqued by the fact that av companies, in an effort not to disclose potentially dangerous information, ended up doing themselves and others a disservice. The industry is lacking a unified standard on what information should be published.
Let's take a look at some examples.
Symantec's description includes information about a certain site that Gpcode uses for data exchange.
Why isn't the complete URL shown? There's a good reason for this. Av companies never give full links to sites which might contain malicious programs or which might include confidential data. This is why links in descriptions are partial, with [REMOVED] being used as a substitute for the deleted part of the link.
Now let's take a look at Trend Micro's description.
Trend analysts decided not to publish the full URL, which is great. But unfortunately they deleted one part of the link, and Symantec deleted another.
So - two different companies wanted to ensure this information was withheld, for the very best of reasons. But working together, they managed to make the information public…
A case, no doubt, of the road to hell being paved with good intentions, caused by the lack of a single, industry wide standard.
If we take a look at other examples, we'll see what sort of data some antivirus companies try to mask, while others, apparently, aren't bothered.
Here's Trend again, with text from Gpcode's "read_me.txt" file, which the Trojan drops to the victim machine. The author's email address and victim's personal code were replaced with %s and %d.
This is exactly what we did when we compiled our description of Gpcode.ai:
Clearly, in this case, Trend Micro and Kaspersky Lab were thinking along the same lines: not to publish this data.
So what did Panda Software decide to do?
Not only did this company decide not to delete the crucial data, but actually highlighted it!
Symantec, having decided to mask data by substituting [MAIL ADDRESS] and [PERSONAL CODE] then decides to publish this information further down: 4 email addresses given for victims to contact…
In other words, it's a real mess. And the crowning moment is also shown in the screenshot above, where Symantec analysts decided, for some reason, that the link to the Wikipedia article on RSA should be snipped!