12 Mar Agent.btz: a source of inspiration? Aleks
28 Jan A cross-platform java-bot Anton Ivanov
16 Jan Big box LatAm hack (1st part - Betabot) Dmitry Bestuzhev
11 Dec The inevitable move - 64-bit ZeuS has come enhanced with Tor Dmitry Tarakanov
12 Nov Sinkholing the Hlux/Kelihos botnet - what happened? Stefan
27 Apr CeCOS VII Michael
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.
The past few days has seen an extensive discussion within the IT security industry about a cyberespionage campaign called Turla, aka Snake and Uroburos, which, according to G-DATA experts, may have been created by Russian special services.
One of the main conclusions also pointed out by research from BAE SYSTEMS, is a connection between the authors of Turla and those of another malicious program, known as Agent.BTZ, which infected the local networks of US military operations in the Middle East in 2008.
We first became aware of this targeted campaign in March 2013. This became apparent when we investigated an incident which involved a highly sophisticated rootkit. We called it the ‘Sun rootkit’, based on a filename used as a virtual file system: sunstore.dmp, also accessible as \\.\Sundrive1 and \\.\Sundrive2. The ‘Sun rootkit’ and Uroburos are the same.
We are still actively investigating Turla, and we believe it is far more complex and versatile than the already published materials suggest.
At this point, I would like to discuss the connection between Turla and Agent.btz in a little more detail.
The story of Agent.btz began back in 2007 and was extensively covered by the mass media in late 2008 when it was used to infect US military networks.
Here is what Wikipedia has to say about it: “The 2008 cyberattack on the United States was the ‘worst breach of U.S. military computers in history’. The defense against the attack was named ‘Operation Buckshot Yankee’. It led to the creation of the United States Cyber Command.
It started when a USB flash drive infected by a foreign intelligence agency was left in the parking lot of a Department of Defense facility at a base in the Middle East. It contained malicious code and was put into a USB port from a laptop computer that was attached to United States Central Command.
The Pentagon spent nearly 14 months cleaning the worm, named Agent.btz, from military networks. Agent.btz, a variant of the SillyFDC worm, has the ability ‘to scan computers for data, open backdoors, and send through those backdoors to a remote command and control server’.”
We do not know how accurate is the story with the USB flash drive left in the parking lot. We have also heard a number of other versions of this story, which may, or may not be right. However, the important fact here is that Agent.btz was a self replicating computer worm, not just a Trojan. Another important fact is that the malware has dozens of different variants.
We believe that the initial variants of the worm were created back in 2007. By 2011 a large number of its modifications had been detected. Today, most variants are detected by Kaspersky products as Worm.Win32.Orbina.
Curiously, in accordance with the naming convention used by PC Tools, the worm is also named Voronezh.1600 – possibly a reference to the mythical Voronezh school of hackers, in Russia.
In any event, it is quite obvious that the US military were not the only victims of the worm. Copying itself from one USB flash drive to another, it rapidly spread globally. Although no new variants of the malware have been created for several years and the vulnerability enabling the worm to launch from USB flash drives using “autorun.inf” have long since been closed in newer versions of Windows, according to our data Agent.btz was detected 13,832 times in 107 countries across the globe in 2013 alone!
The dynamics of the worm’s epidemic are also worth noting. Over three years – from 2011 to 2013 – the number of infections caused by Agent.btz steadily declined; however, the top 10 affected countries changed very little.
|Agent.BTZ detections (unique users)||2011|
|Agent.BTZ detections (unique users)||2012|
|Agent.BTZ detections (unique users)||2013|
The statistics presented above are based on the following Kaspersky Anti-Virus verdicts: Worm.Win32.Autorun.j, Worm.Win32.Autorun.bsu, Worm.Win32.Autorun.bve, Trojan-Downloader.Win32.Agent.sxi, Worm.Win32.AutoRun.lqb, Trojan.Win32.Agent.bve, Worm.Win32.Orbina
To summarize the above, the Agent.btz worm has clearly spread all over the world, with Russia leading in terms of the number of infections for several years.
Map of infections caused by different modifications of “Agent.btz” in 2011-2013
For detailed information on the modus operandi of Agent.btz, I recommend reading an excellent report prepared by Sergey Shevchenko from ThreatExpert, back in November 2008.
On infected systems, the worm creates a file named ‘thumb.dd’ on all USB flash drives connected to the computer, using it to store a CAB file containing the following files: “winview.ocx”, “wmcache.nld” and “mswmpdat.tlb”. These files contain information about the infected system and the worm’s activity logs for that system. Essentially, “thumb.dd” is a container for data which is saved on the flash drive, unless it can be sent directly over the Internet to the C&C server.
If such a flash drive is inserted into another computer infected with Orbina, the file “thumb.dd” will be copied to the computer under the name “mssysmgr.ocx”.
Given this functionality and the global scale of the epidemic caused by the worm, we believe that there are tens of thousands of USB flash drives in the world containing files named “thumb.dd” created by Agent.btz at some point in time and containing information about systems infected by the worm.
Over one year ago, we analyzed dozens of modules used by Red October, an extremely sophisticated cyber espionage operation. While performing the analysis, we noticed that the list of files that a module named “USB Stealer” searches for on USB flash drives connected to infected computers included the names of files created by Agent.btz “mssysmgr.ocx” and “thumb.dd”.
This means that Red October developers were actively looking for data collected several years previously by Agent.btz. All the USB Stealer modules known to us were created in 2010-2011.
Both Red October and Agent.btz were, in all probability, created by Russian-speaking malware writers. One program “knew” about the files created by the other and tried to make use of them. Are these facts sufficient to conclude that there was a direct connection between the developers of the two malicious programs?
I believe they are not.
First and foremost, it should be noted that the fact that the file “thumb.dd” contains data from Agent.btz-infected systems was publicly known. It is not impossible that the developers of Red October, who must have been aware of the large number of infections caused by Agent.btz and of the fact that the worm had infected US military networks, simply tried to take advantage of other people’s work to collect additional data. It should also be remembered that Red October was a tool for highly targeted pinpoint attacks, whereas Agent.btz was a worm, by definition designed to spread uncontrollably and “collect” any data it could access.
Basically, any malware writer could add scanning of USB flash drives for “thumb.dd” files and the theft of those files to their Trojan functionality. Why not steal additional data without too much additional effort? However, decrypting the data stolen requires one other thing – the encryption key.
The connection between Turla and Agent.btz is more direct, although not sufficiently so to conclude that the two programs have the same origin.
Turla uses the same file names as Agent.btz – “mswmpdat.tlb”, “winview.ocx” and “wmcache.nld” for its log files stored on infected systems.
All the overlapping file names are presented in the table below:
In addition, Agent.btz and Turla use the same XOR key to encrypt their log files:
The key is not a secret, either: it was discovered and published back in 2008 and anybody who had an interest in the Agent.btz story knew about the key. Is it possible that the developers of Turla decided to use somebody else’s key to encrypt their logs? We are as yet unable to determine at what point in time this particular key was adopted for Turla. It is present in the latest samples (dated 2013-2014), but according to some data the development of Turla began back in 2006 – before the earliest known variant of Agent.btz was created.
Now we have determined that Red October “knew” about the file names used by Agent.btz and searched for them. We have also determined that Turla used the same file names and encryption key as Agent.btz.
So what about a possible connection between Red October and Turla? Is there one? Having analyzed all the data at our disposal, we do not see any overlapping between the two projects. They do not “know” about each other, they do not communicate between themselves in any way, they are different in terms of their architecture and the technologies used.
The only thing they really have in common is that the developers of both Rocra and Turla appear to have Russian as their native language.
Back in 2012, while analyzing Flame and its cousins Gauss and MiniFlame, we noticed some similarities between them and Agent.btz (Orbina). The first thing we noticed was the analogous naming convention applied, with a predominance of use of files with the .ocx extension. Let’s take as an example the name of the main module of Flame – “mssecmgr.ocx”. In Agent.btz a very similar name was used for the log-file container on the infected system – “mssysmgr.ocx”. And in Gauss all modules were in the form of files with names *.ocx.
|Using USB as storage||Yes (hub001.dat)||Yes (.thumbs.db)|
The Kurt/Godel module in Gauss contains the following functionality: when a drive contains a '.thumbs.db' file, its contents are read and checked for the magic number 0xEB397F2B. If found, the module creates %commonprogramfiles%\system\wabdat.dat and writes the data to this file, and then deletes the '.thumbs.db' file.
This is a container for data stolen by the 'dskapi' payload.
Besides, MiniFlame (module icsvnt32) also ‘knew’ about the ‘.thumbs.db’ file, and conducted a search for it on USB sticks.
If we recall how our data indicate that the development of both Flame and Gauss started back in 2008, it can’t be ruled out that the developers of these programs were well acquainted with the analysis of Agent.btz and possibly used some ideas taken from it in their development activities.
The data can be presented in the form of a diagram showing the interrelations among all the analyzed malicious programs:
As can be seen in the diagram, the developers of all three (even four, if we include Gauss) spy programs knew about Agent.btz, i.e., about how it works and what filenames it uses, and used that information either to directly adopt the functionality, ideas and even filename, or attempted to use the results of the work of Agent.btz.
Summarizing all the above, it is possible to regard Agent.btz as a certain starting point in the chain of creation of several different cyber-espionage projects. The well-publicized story of how US military networks were infected could have served as the model for new espionage programs having similar objectives, while its technologies were clearly studied in great detail by all interested parties. Were the people behind all these programs all the same? It’s possible, but the facts can’t prove it.
Early this year, we received a malicious Java application for analysis, which turned out to be a multi-platform bot capable of running on Windows, Mac OS and Linux. The bot was written entirely in Java. The attackers used vulnerability CVE-2013-2465 to infect users with the malware.
To make analyzing and detecting the malware more difficult, its developers used the Zelix Klassmaster obfuscator. In addition to obfuscating bytecode, Zelix encrypts string constants. Zelix generates a different key for each class – which means that in order to decrypt all the strings in the application, you have to analyze all the classes in order to find the decryption keys.
String initialization and decryption is implemented in the static initializer code (<clinit>).
The more people switch to 64-bit platforms, the more 64-bit malware appears. We have been following this process for several years now. The more people work on 64-bit platforms, the more 64-bit applications that are developed as well. Sometimes these include some very specific applications, for example, banking applications.... If someone wants to hack into an application like this and steal information, the best tool for that would also be a 64-bit agent. And what’s the most notorious banking malware? ZeuS, of course – the trendsetter for the majority of today’s banking malware. Its web injects have become a fundamental must-have feature of almost every banking malware family. And it was only a matter of time until a 64-bit version of ZeuS appeared – but we didn’t expect it to happen quite so soon.
That’s because cybercriminals don’t actually need a 64-bit version. ZeuS is mostly intended to intercept data passing through browsers, and modify that data allowing the operator to steal information related to online banking, to wire transactions or to cover his tracks. But nowadays people still use 32-bit browsers – even on 64-bit operating systems. So, 32-bit versions of ZeuS have been sufficient to keep the thieves satisfied with their earnings.
Then, out of the blue, we spotted a 32-bit ZeuS sample maintaining a 64-bit version inside. And it’s turned out that this 64-bit version has already been recorded being present in the wild at least since June, 2013 and compilation date specified in the sample is April 29, 2013! Moreover, this ZeuS version works via Tor. The initial 32-bit sample injects malicious code into target processes. If the target process belongs to a 64-bit application, ZeuS injects its 64-bit version into the process; otherwise, it pushes the 32-bit version. We ran tests to see how the 64-bit ZeuS works inside a 64-bit Internet Explorer and it demonstrated the usual ZeuS functionality: in any case, the web injects functioned as usual.
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.
The Counter eCrime Operations Summit VII (CeCOS VII) engages questions of operational challenges and the development of common resources for the first responders and forensic professionals who protect consumers and enterprises from the electronic-crime threat every day.
The annual event, organized by the Anti-Phishing Working Group (APWG) is this time held in Buenos Aires, Argentina.
Is it a Skype day? Or maybe a Bitcoin one? Or maybe just both?
I say this because right after I published my previous post about malware ongoing campaign on Skype, a mate from Venezuela sent me a screenshot of her Skype client with a similar campaign in terms or propagation but different in origins and purposes. Here is the original screenshot:
(Translation from Spanish: “this is my favorite picture of you”)
After the recent emergence of the criminal PiceBOT in Latin America, AlbaBotnet has joined the growing ranks of regional IT crime. It revolves around online pharming, with a view to delivering targeted phishing attacks which steal information from the online accounts of two major Chilean banks.
According to the data we have processed, this campaign is part of a trial stage of this botnet: up to now there has been no monetization of AlbaBotnet. We do know that the author of this threat began testing it in early 2012.
The botnet appears to have a similar structure to its Latin American counterparts. As well as the default automated malware builder, it includes a package which automatically sends emails. Thus, the botmaster can customize infection campaigns through the classic mechanisms of visual social engineering:
Like other crimeware of its kind, its main purpose is the distribution of malware that steals financial information through local pharming attacks (arbitrary modification of a hosts file). Despite its recent onset (less than a month) it has already been adopted by Latin American cybercriminals to target clients of major banks. So far we have recorded phishing attacks generated and managed through this botnet in Chile, Peru, Panama, Costa Rica, Mexico, Colombia, Uruguay, Venezuela, Ecuador, Nicaragua and Argentina. The following image, obtained from an underground forum, shows some examples: