Yes, it’s that time of the year again! People from all around the world try to escape the heat and pollution of the big cities and find much more enticing options. Once the vacation is over and we are all back to work, what does everybody do first?

Publish photos, of course!

I just came across a suspicious PDF file, so I decided to take a deeper look. Once the file was unpacked, I got an xml file with TIFF image. However, the whole thing looked very strange. The whole thing looked very fishy, and ultimately, it turned out that the xml file contained an exploit for CVE-2010-0188.

I thought it was a bit odd that we hadn’t come across files like this before, so I decided to tak a look at stats for this vulnerability:

CVE-2010-0188 exploit statistics 2010

The graph shows that malware exploiting CVE=2010-0188 started spreading actively at the end of June. It was pretty much a rarity until then. Maybe the virus writers needed a few months to catch up with creating exploits for the new hole in Adobe – who knows?

When I took a closer look, it turned out that the PDF was mainly designed to download and launch another file, Trojan-Dropper.Win32.Zbot.cm. Which, in its turn, is mainly designed to secretly install Zbot (ZeuS) to the system and to combat antivirus software.

I was able to get a final example of Zbot, but it turned out to be encrypted and obfuscated. I then got its dump and decrypted strings, which included a clear link to the banking site under attack, the bot’s http requests and some of the commands used by the botnet C&C:

Part of the decrypted Zbot file

This is the first example of an encrypted Zbot variant spreading via CVE-2010-0188. Clearly, the guys behind this program aren’t sitting on their hands, but working on the most up-to-date methods of delivering their malware to end users.

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.

Working on an efficient generic shellcode detection engine and verifying results with randomly generated input, I've effectively ended up fuzzing different open source disassembler libraries. The disassembler library of choice for my current project is libdasm because of its comparatively long history and public domain license. But writing a sound and complete x86 disassembler is obviously not a trivial task due to the complex nature of the x86 instruction set.

libdasm used to have issues correctly disassembling certain floating point instructions in the past, but this was simply caused by an off-by-three error in the opcode lookup tables (three NULL rows missing) and thus the fix was comparatively easy.