The ShadyRAT whitepaper spectacle coincided with the start of the Blackhat USA 2011 conference. While it was noted that AV vendors reliably detect related ShadyRAT downloader components, discussion of other components were absent. The downloaders vaguely mentioned in the report have been reliably detected by Kaspersky Lab products for years.

More information was provided later on another vendor's site. But whitepaper readers were left with only a dive into the high level data compiled by the attackers’ web monitoring components and no actionable information presented.

Meanwhile, over on the HBGary blog, the more interesting descriptions of the meat of the backdoor components and communications were discussed - something sysadmins can do something about.

We also added detection of this component and variants like it as Backdoor.Win32.Shady.a (Trojan-Downloader.Win32.Agent.szfj), which was actually used early 2011 and after several months, still active and detected only by Sophos.

This prolonged absence of detection is both acutely problematic and symptomatic of active, determined groups. These Shady backdoors are especially interesting for their style of covert communications with hidden messages appearing in HTML source text on both compromised and managed sites.

Cloud Computing providers offer gigabytes of storage for free, and the cybercriminals use to maintain and spread malware of all the kind. At the same time, many legitimate services are not free, but are still very attractive to cybercrime gangs. In the case of Amazon, Amazon Simple Storage Service (Amazon S3) does the trick.

Despite being a paid service, the cost is not an obstacle for profitable attackers. In fact, my colleague Dmitry Bestuzhev recently told us about the spread of malware exploiting this service to "the cloud".

The truth is that these cases are not isolated. According to our research, cybercriminals have been running SpyEye activities and from Amazon for the past couple of weeks.

Modification of the hard drive areas responsible for the initial loading of the system has become increasing popular with cybercriminals. Moreover, cybercriminals have now moved on from just modifying the MBR (master boot record) to infecting the code of the NTFS loader.

We recently discovered an interesting piece of malware — Cidox. It is peculiar in that it infects the load area code of the boot partition on the hard drive.

The master file Trojan-Dropper.Win32.Cidox “carries on board” two driver rootkits (Rootkit.Win32/Win64.Cidox). One is compiled for 32-bit platforms, the other for 64-bit platforms.

The source component of Cidox makes the following modifications to the beginning of the hard drive:

• Saves the relevant driver to free sectors at the beginning of the hard drive;
• It chooses the section marked as the boot partition in the MBR partition table for infection. It is important to note that it only infects partitions with the NTFS file system.
• Writes part of its code over Extended NTFS IPL (Initial Program Loader), which is responsible for parsing the MFT table (Master File Table), searching for the file with the loader in the root directory of the section (ntldr — pre-Vista, bootmgr — Vista+), reading this file form the disk and transferring control to it. At the same time the original contents of Extended NTFS IPL are encrypted, saved and added to the end of the malicious code.

    There were some recent comments about Amazon Cloud as a platform for successful attacks on Sony… Well, today I found that Amazon Web services (Cloud) now is being used to spread financial data stealers.

Since yesterday I've been attending the annual Hack-in-the-Box Quad-Track Security Conference in Amsterdam/NL. There's a very nice and open atmosphere here at the conference, besides the beautiful city of Amsterdam.

First, Joe Sullivan (CSO at facebook), held a very interesting keynote about the development of security innovations at facebook. For him innovation is „these hacking culture, we think about each day at facebook“. After explaining some of the newer security innovations (https-only, login notifications, login approvals [if e.g. geo-location of a user is suspicious], recognized devices, recent activity) he talked about the recent fb-scams with malicious scripts. „No one would do that, copying and pasting a script into the browser! - Yes, they do...“, he said.

Also a remarkable talk I attended was about binary planting, given by Mitja Kolsek (CTO at ACROS Security). In "Binary Planting: First Overlooked, Then Downplayed, Now Ignored" Mitja also showed a new method he called "advanced binary planting", which uses a feature from Windows' special folders (like control panel, printers, etc.) and clickjacking to make it possible to own the users' computer.

In the winter garden of the conference hotel there's a technology showcase area. Hackerspaces from all over Europe and the Netherlands are showcasing their projects here. There also is a capture-the-flag competition happening, a lock-picking and (sponsor) companies-showcase.

For more informations please see the conference website.

A trojan called Bohu that was spreading earlier this year caught people's attention: it has the ability to block cloud-based anti-virus services, which is kind of a new thing. The malware spreads via social engineering and mostly targets China. The guys over at MMPC have published a nice blog post with more details here.

First off, our products already detected and blocked Bohu based on its behavior profile even before we had any signatures out for it. On the contrary, if a system was already infected before the installation of a scanner, you might be in trouble...

Amongst other things, Bohu also prevents access to a Kaspersky server that hosts virus signature updates by hooking the DNS resolver in order to filter out resolution attempts for the corresponding domain name. Consequently, an infected system is prevented from automatically updating its Kaspersky signature databases, so it cannot detect and remove the threat.

However, the domain name filter can also be turned into an infection check! We have prepared a little web page at http://www.securelist.com/bohucheck that takes advantage of Bohu's blockade and displays different messages depending on whether a system can access the blocked domain or not. Users can now simply surf to this page to find out if they are infected with the trojan. If the page shows the above message, the trojan is not present.

But if the web page shows a warning message, the system is most likely infected:

In any case, if you see the message above, you should manually scan and clean your system. To do so, you can download our freely available rescue disk image and burn it to a CD or USB drive, then boot into it. As the scanner on the rescue system is not affected by the trojan's domain filter, it can still update its signatures and detect and remove the malware. More information on how to use the rescue system is available online on this link.

Over the past few weeks the AV industry has continued to focus its research efforts on the Stuxnet worm. We blogged about what we found while we were investigating the malware; our Stuxnet series may have come to an end, but that doesn’t mean we’ve stopped our research.

One of the things our research has identified is that Stuxnet uses several Windows zero-day vulnerabilities.

Yes, you read that correctly – several zero-day vulnerabilities.

Until now, most of the focus has been on the LNK/PIF vulnerability which Stuxnet exploits in order to spread via removable storage media and networks. But this has turned out not to be Stuxnet’s only surprise. The worm doesn’t just spread by using the LNK vulnerability. Once it’s infected a computer on a local network, it then attempts to penetrate other computers using two other propagation routines.

Firstly, Stuxnet is designed to exploit MS08-067, the same vulnerability used by Kido (aka Conficker) at the beginning of 2009. The exploit code that Stuxnet uses to target MS08-067 is slightly different to that used by Kido. However, what’s really interesting is the second propagation routine.

In addition to exploit code for MS08-067, Stuxnet contains an exploit for a previously unidentified vulnerability in the Print Spooler service; this vulnerability makes it possible for malicious code to be passed to, and then executed on, a remote machine. Two files (winsta.exe and sysnullevent.mof) appear on attacked systems. It’s not just the way in which the malicious code gets on to the remote machine which is interesting, but also how the code then gets launched for execution.

As soon as we identified the vulnerability we informed Microsoft about the problem and they confirmed our findings. The vulnerability has been identified as “Print Spooler Service Impersonation Vulnerability” and rated “critical”. Today Microsoft released MS10-061, a patch which fixes this vulnerability.

Analysis of the vulnerability shows that it’s computers with shared access to a printer which are at risk of infection.

During analysis, we searched our collection for other malicious programs capable of using this vulnerability. Happily, we didn’t find anything.

On top of all this, we've identified yet another zero-day vulnerability in Stuxnet's code, this time an Elevation of Privilege (EoP) vulnerability. The worm uses this to get complete control over the affected system. A second EoP vulnerability was identified by Microsoft personnel, and both vulnerabilities will be fixed in a security bulletin in the near future.

The fact that Stuxnet uses four previously unidentified vulnerabilities makes the worm a real standout among malware. It’s the first time we’ve come across a threat that contains so many “surprises”. Add to this the use of Realtek and JMicron certificates, and remember that Stuxnet’s ultimate aim is to access Simatic WinCC SCADA systems.

Stuxnet was undoubtedly created by professionals who’ve got a thorough grasp of antivirus technologies and their weaknesses, as well as information about as yet unknown vulnerabilities and the architecture and hardware of WinCC and PSC7.

Together with Microsoft and other AV companies, so far we’ve spent more than two months looking at Stuxnet. We’ll be presenting our findings, including a detailed look at how the vulnerability works, at the end of the month at the Virus Bulletin conference.

So far in our series about Stuxnet we’ve focussed on the main issue: the threat posed by the zero-day vulnerability in the processing of LNK files, and the fact that cybercriminals have somehow got their hands on digital certificates. What we haven’t done in any detail is look at the worm’s functionality.

Anyone following the story has probably already read about how the worm, in addition to replicating, attempts to gain access to industrial systems running WinCC from Siemens.

I can’t remember which journalist or antivirus researcher first mentioned power plants (some of which certainly do run WinCC) in connection with Stuxnet. Since then, the whole story’s taken on the air of a Hollywood movie, with dark and repeated murmurings of ‘attacks on industry’ and ‘inter-government espionage’.

Stuxnet does attempt to connect to the WinCC SCADA visualization system using the default password from Siemens. Part of the worm is a very interesting component, a dll, which acts as a wrapper for the original Siemens dll. It’s this wrapper that tries to connect to WinCC, redirecting the majority of the functions to the original dll, while emulating the remaining functions itself.

The functions are:

s7db_open
s7blk_write
s7blk_findfirst
s7blk_findnext
s7blk_read
s7_event
s7ag_test
s7ag_read_szl
s7blk_delete
s7ag_link_in
s7db_close
s7ag_bub_cycl_read_create
s7ag_bub_read_var
s7ag_bub_write_var
s7ag_bub_read_var_seg
s7ag_bub_write_var_seg

The module also contains several encrypted blocks of data – here’s an example of a decrypted block:

Siemens is currently conducting its own investigations and analysis of the malware. They’ve published official information about the incident, which reports one confirmed case of infection of a WinCC client in Germany.

From the report:

"Currently there is still only one known case where a customer's WinCC computer has been infected. The virus infiltrated a purely engineering environment of a system integrator, but was quickly eliminated. A production plant has not been affected so far."

"There is only one known case of infection in Germany. We are, at present, trying to find out whether the virus caused any damage."

Siemens also confirms that the worm is able to transmit process and production data, and that it attempts to establish a connection with the cybercriminals’ servers. At the moment, however, the servers are apparently inactive.

P.S. Siemens has just issued an update:

"Currently we know of two cases worldwide where a WinCC computer has been infected. A production plant has so far not been affected."

A few days ago we wrote about a new variant of the Stuxnet worm’s rootkit component, signed not with Realtek’s digital signature, but with one owned by JMicron. Costin posted about it in detail.

The media jumped on the news, and there was a lot of talk about “New worm variant discovered”. However, the situation isn’t quite as simple as the headlines made out.

There wasn’t a clear answer to the main question i.e. where’s the worm which the signed driver would have come from? The fact that the driver was created on 14 July could indicate that a new variant of the worm, potentially with new functionality, was out in the wild.

However, all of our attempts to find the dropper of the second rootkit driver (there are meant to be two) came to nothing.

Over the last few days, all the discussions have boiled down to two possible explanations: either cybercriminals stole the digital certificates using a Trojan, or it was the work of an insider. Our failure to find the dropper or second driver, though, makes the whole story all the more complicated.

So we decided to look at some statistics: how many times has the Kaspersky Security Network detected Rootkit.Win32.Stuxnet.c (the driver signed with the JMicron certificate)? The numbers are discouraging – since 20 July, the module’s been detected all of twice, once in Russia and once in Ukraine. These figures look pretty silly when compared to the detection statistics for the rootkit component signed with the Realtek signature.

Verisign has now revoked the JMicron certificate, making it invalid. Our whitelisting database contained 124 programs which had been signed using the certificate – all of them, of course, were clean.

At the moment, I’m not drawing any conclusions about the origins of this mythical driver. I don’t doubt that it is a modified variant of mrxcls.sys. We’re still looking for whatever is launching it, or computers which it’s infected.

If we look at the stats relating to the initial Stuxnet variant, they show epidemics in India, Iran, and Indonesia. The number of infected computers increases by about a thousand every day, and this is only what our monitoring systems show us. In other words, it’s merely the tip of the iceberg.

Apart from the three countries hit by Stuxnet, Azerbaijan and Afghanistan have also been heavily affected, with more than a thousand infected machines each.

The geographical spread of the Trojan, together with the “missing” variant, has given us all a lot to think about.

Last night, Verisign acted promptly and revoked the second stolen certificate used to sign a version of the Stuxnet rootkit driver. As previously mentioned, this certificate belonged to JMicron Technology Corp, a popular Taiwanese hardware company.

We have prepared a short FAQ about Stuxnet and the revoked stolen certificates:

1. I heard Microsoft and Verisign revoked the stolen Realtek certificate, does it mean I’m safe now?

Due to the way certificates work, a revoked certificate doesn’t mean the malware will not run anymore. You will still get infected by Stuxnet and the driver will still load without any warning. The only effect of the revoke process is that the bad guys will not be able to sign any further malware with it.

2. How many stolen certificates are we talking about?

So far, we’ve seen Stuxnet drivers signed with certificates from JMicron Technology Corp and Realtek Semiconductor Corp. Both companies seem to have offices in the Hsinchu Science and Industrial Park, which could indicate an insider job. It is also possible that the certificates were stolen using a dedicate Trojan, such as Zeus, meaning, there could be more.

3. I have a Realtek/JMicron motherboard/network card in my computer. Does it mean that I am at risk?

So far, we haven’t found anything suspicious in the Realtek/JMicron hardware drivers.

4. Now that Microsoft and Verisign revoked the Realtek/JMicron certificates, does it mean that my Realtek/JMicron drivers will stop working?

No. Due to the way certificates and signatures work, the revoking doesn’t have any effect on already signed drivers. Both companies were issued new certificates, which they can use to sign upcoming drivers.

5. Are we going to see more signed malware in the future?

Most likely, yes. There are currently tens of thousands malicious programs that have been signed – that’s a fact. For more information, I encourage everyone to view Jarno Niemelä’s excellent presentation “It's Signed, therefore it's Clean, right?“, presented earlier this year at the CARO Workshop.