21 Nov Multimedia overwriter with Spy features Dmitry Bestuzhev
15 Nov AutoCAD – new platform for start page Trojans Vigi Zhang
12 Nov Sinkholing the Hlux/Kelihos botnet - what happened? Stefan
11 Nov How to keep your Bitcoins safe Stefan Tanase
05 Nov The Android Trojan Svpeng now capable of mobile phishing Roman Unuchek
05 Nov Brazilian bankers gone wild: now using malicious Office files Fabio Assolini
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.
In China, start page Trojans have become a popular type of malware because by changing users’ browser start pages to point to some navigation site, the owner of the site can get a large amount of web traffic which can then be converted into large sums of money. In order to spread such Trojans as broadly as possible, Trojan authors have even turned their sights to AutoCAD. This week we found two new AutoCAD Trojans detected as Trojan-Downloader.Acad.Qfas.b and Trojan.Acad.Qfas.o. They are written in AutoLISP mixed with VBA, and are aimed at changing users’ browser start pages and displaying adverts. According to our KSN statistics, this threat appears mainly in China, India and Vietnam.
These two Trojans are compiled AutoLISP files with the file extension .fas. Here is a fragment:
This can cause difficulties during analysis because there is no decompiler as such for .fas files and these Trojans managed to avoid detection by all antivirus programs except Kaspersky’s, which are capable of decompiling such files:
Back in March 2012 we teamed up with Crowdstrike, the Honeynet Project and Dell SecureWorks in disabling the second version of the Hlux/Kelihos-Botnet. We thought that now would be a good time for an update on what has happened to that sinkhole-server over the last 19 months.
What we see now is what we expected. The botnet is getting smaller and smaller - victims have been disinfecting or reinstalling their PCs over time. At the moment we're counting about 1000 unique bots on average per month:
Due to the botnetís peer-to-peer-design, there could still exist an independent subset of the initial botnet which never connected to our sinkhole. But we think that the bot-count for any such subset would have evolved in a similar way, because most likely the bot-herders would leave them alone as well and concentrate on establishing "Hlux 3".
Most of the bots are still running under Windows XP. But we also saw some bots running under Windows Server 2008:
Most of the infected clients are located in Poland:
The group behind Hlux is known to be adept at quickly renewing their illegal infrastructure. Since the group is also known to be behind the Waledac botnet, we think that this is unlikely to be the last we hear about this gang.
Last but not least, a quick review about the story of Hlux/Kelihos:
In September 2011 we performed the first takedown of Hlux. The criminals responsible for that botnet didnīt show a major interest in taking counter-measures - they abandoned the botnet to its fate (of being under our control now) and immediately began to build a new botnet. So after a short time, Hlux 2 appeared on the radar and we did it again - poisoning the p2p-network to sinkhole it. And again, the criminals quickly rebuilt their botnet and Hlux 3 was born - within 20 minutes! In March 2013 the bad guys were faced with a new shutdown operation - initiated and performed live at the RSA Conference 2013 by our friends over at Crowdstrike.
As Bitcoin reached an all-time high of $327/BTC, news about yet another huge robbery hit the world of crypto-currencies. One of the relatively new “Bitcoin banking” services named inputs.io claimed it has been compromised by hackers. The attackers were able to penetrate the server on October 23 and 26 and transfer 4100 BTC (approximately US$1.2 million). According to “Tradefortress”, the service owner, the attackers used old email accounts together with a password reset technique: “They were able to bypass two-factor authorization due to a flaw on the server host side”.
Right now it is not possible to confirm that this was a real hack, and not merely a site owner scamming customers. But it is not the first time this has happened - there were a number of similar incidents in recent years on many different bitcoin storage and exchange services. Examples include, in May and July 2012, the Bitconica theft (approx. 58,000 bitcoins stolen), Linode hacks in March 2012 (approx. 46,000 bitcoins stolen) and Bitfloor Theft in September 2012 (approx. 24,000 bitcoins stolen).
All this accidents happened because of silly mistakes made by service operators. Bitfloor was robbed because its unencrypted wallet backup was mistakenly stored on some of the servers. The Bitconica theft occured when a top privileged email account was compromised giving the cybercriminals access to Bitconica’s rackspace server where the wallet was kept. There are hundreds of similar examples.
Bitcoin is a secure and viable currency, but its security ultimately depends on its users. If users are unable to establish the security of their own wallets they definitely will lose them.
The best strategy for storing and using Bitcoins securely is “Don’t keep all of your eggs in the same basket”. Use different approaches for short-term and long-term storage. The most flexible solutions are usually the least secure ones as well. You don’t want to keep all of your bitcoins on your mobile or Blockchain wallet for instance - but just enough for weekly use. At the end of the week, you can top-up your Bitcoins from your long-term storage, the one which is secured.
If you own a couple of Bitcoins, then the most important thing is how to keep them safe. Here’s a couple of tips from our side based on personal experience and watching cybercriminals at work.
First of all – the Bitcoins should not be kept in online stock exchange services or banks that are new and untrustworthy. Keep in mind that most of these services are anonymous; owners are only known by nicknames so most likely, you will not be able to get a refund of your money if something bad happens. Even if a service has a perfect reputation, it could also be compromised like any ordinary bank. To store your Bitcoins, you can use an open-source “offline” bitcoin client like Electrum or Armory. These encrypt your wallet with a strong password and protect it, ensuring that only you have access to your crypto-currency.
Passphrases for your bitcoin wallets and online storages should be complex as possible – use open source password generating software.
Once you have your bitcoins in an “offline” wallet, secured by a strong password, make sure your PC is protected with a good, solid antivirus and your PC has the latest software updates installed. If you have a huge amount of bitcoins - you should keep them in a wallet on a PC that is not connected to the Internet at all!
Some say Bitcoins will bring down governments or even the society as we know it; others advocate it as the solution to all our financial problems. To be honest, when it comes to Bitcoins, nobody knows what the future will bring. One thing is for sure, though - cybercriminals are highly interested into stealing your hard earned crypto-currencies, so we’re likely to see more attacks in the future.
Since we published our first blog post about the mobile Trojan Trojan-SMS.AndroidOS.Svpeng, the cybercriminals have improved its functionalities. Now Svpeng is capable of phishing as well, trying to harvest the financial data of users.
When a user launches the banking application of one of Russia’s largest banks, the Trojan substitutes the opened window with a phishing window, designed to steal the victim’s login and password for the online banking system:
The data the user enters is sent to the cybercriminals.
You may have read about the Cryptolocker malware, a new ransomware Trojan that encrypts your files and demands money to return them.
In the past, we have witnessed similar malware like the famous GPCode that used RSA keys for encryption. Back in 2008, we cracked the 660 bit RSA key used by GPCode and provided the victims with a method to decrypt and recover their data. Later, the GPCode authors upgraded the RSA key to 1024 bits, putting it perhaps only in the realm of NSAís cracking power.
Any online project — be it a long-lost blog, or a new start-up’s web app — has a very important performance feature called a “maximum load”. This indicator makes itself known when a web app either partially or fully fails to perform its assigned functions to process user requests. For some owners, this may mean losing a portion of their blog-reading audience, and for others, it may mean the loss of clients who opt for a product from a competitor whose online store is up and running.
Each online resource has its own maximum load when it comes to the number of user requests it can process at any one time. That’s why developers and web app owners devote special attention to load procedures and stress tests.
Load testing services today are useful, but sometimes the way they are set up leaves a loophole that malicious users can take advantage of.
Data system load testing is a procedure that evaluates the performance features of the system being tested without reaching maximum load. Stress testing, on the other hand, is a similar procedure, but it tests the system with loads at or exceeding maximum load. In most cases, stress tests lead to unwanted behavior by the system being tested, or a service failure — similar to what happens in DDoS (distributed denial of service) attacks.
Infected websites appear on the Internet literally every day. They include personal blogs on WordPress that become infected during mass, automated attacks, and the websites of major media outlets, each of which malicious users infect manually after some preparatory steps. All of these resources replenish the arsenal of so-called “traffic traders” — cybercriminals who redirect visitors to infected websites to the online resources of their malware-writing clients. In the end a user, suspecting nothing, can become the victim of a drive-by attack and, if the user’s browser or the browser’s plug-ins have the necessary vulnerabilities, malware will be downloaded to and installed on the victim’s computer.
Kaspersky Lab has a system that automatically detects and visits infected websites in order to collect a malicious sample and send it to our virus lab for research. To ensure this system is as effective as possible when it comes to detecting online threats, infected websites are studied by virus analysts. With the precision and attentiveness of a forensics examiner, they are able to determine how attacks are launched when a user visits a website.
My attention then turned to an unassuming string in Fiddler, which indicated that part of the site’s content is downloaded through an encrypted channel via HTTPS.
It was hard to believe that malicious users went through the costly procedure of obtaining an SSL certificate for the website in order to spread malicious programs, since these websites are put onto blacklists by antivirus companies and lose their value very quickly. But as Sherlock Holmes says, “Eliminate all other factors, and the one which remains must be the truth.”
I wasn’t feeling overly confident when I switched on Fiddler’s option to decipher HTTPS traffic. But as it turned out, what had originally seemed like an altogether ordinary string was in fact concealing a redirect to a malicious website.
The site that served as the source of malicious software, just like the website that served as the redirect intermediary with the SSL certificate, were both added to our database of malicious resources right then and there. All of the malware that they had been spreading had already previously been detected and identified by Kaspersky Lab.
But my curiosity was piqued: are malicious users really purchasing SSL certificates for the secure transmission of malicious code, or had they somehow figured out a way to get past browser verification using fake SSL certificates? Surprising as it was, the certificate was the real deal.
Quite often, we see malicious users preying on the trust of their victims — they hack accounts on social networks in order to send links to that person’s friends under the guise of yet another cute cat video (but with an .exe extension, and not everyone will fall for that), and they recreate the logos of law enforcement agencies seeded with a blackmailer Trojan, and persuade users to enter their cell phone numbers “to fight botnets”. But what’s more, malicious users also expend no small effort to fool antivirus companies and independent researchers. What may seem like a harmless grey string in an HTTPS connection is just one example of these types of tactics, vying for experts’ trust in these technologies that were designed with the intention of protecting users against online sabotage.