Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

mcbsys — Sun, 24 Apr 2011 06:56:28 GMT

I was referred here from an article I wrote regarding a UAC prompt to install a driver supposedly signed by Microsoft. My attempts to validate the signature failed at several turns: the driver name did not fit in the UAC prompt; the signature for a driver released on Windows Update in March 2011 expired in January 2010; the certificate revocation list is offline; the PKI policy in the certificate is a dead link; the PKI policy's parent URL works but only says that as of June 2001, it is the "future location" of the PKI policy; and a Microsoft PC Safety rep showed no interest in a potentially bogus certificate.

What is the point of digital signing if there is no pubic PKI policy, no CRL, and out-of-date signatures? How does one determine if a certificate or driver is really from Microsoft?

Here is the article: www.mcbsys.com/.../is-this-driver-legitimate.

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Arash — Fri, 22 Apr 2011 15:58:38 GMT

Good analysis Mark, thanks .

hope to see more deep looks at this specimen in future posts .

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Intuit — Mon, 18 Apr 2011 17:30:57 GMT

".... what made this one extraordinary is that its version information identified it as a Microsoft driver and it had a valid digital signature issued by Realtek Semiconductor Corporation, a legitimate PC component manufacturer...."

After having run across a number of Dell drivers that were AutoRuns-hidden because they were signed as Microsoft under the Windows Hardware-Certificate Authority, for a short time had quit hiding Signed Microsoft Entries. Wanted to see *ALL* third-party software. (Clarification: No intent to imply that the Dell drivers had confirmed malicious code.)

The linked Dossier was *very* interesting reading. Recently submitted an unsigned oddly-named Microsoft driver (loading via weirdly named registry key) unto which the Microsoft analyzer dismissed as "Slightly modified with appended data, but a clean volsnap.sys nevertheless." The techniques described in the dossier lead me to wonder whether there is any possibility of this "appended data" being executed while avoiding detection by automated scanners. The XP-Professional system, for various reasons I assume having once belonged to a corporate environment, (coincidently owner employed by a regional utility company,) had an updated copy of F-Secure running. Never flagged the suspicious file.

Anyway, the above NOT included, have seen many machines with MRx drivers on them but because they were signed, had let them go.

As always, many thanks. Computing would not be the same without your expertise; benevolently put forth in the form of the SysInternals tools suite.

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

oldgoat1957 — Sat, 16 Apr 2011 01:35:51 GMT

I always enjoy these kinds of articles, even if it's only on a "detective novel" sort of level...

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Michael Liberman — Thu, 14 Apr 2011 21:25:06 GMT

Great Analysis , waiting for part two.

Btw I ordered your book and hopefully will have it here in a few days (ordered it pretty much when it was available on Amazon).

Shipping to Israel takes quite a while :(

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Mark Russinovich — Wed, 06 Apr 2011 10:23:20 GMT

@Paulie Thanks for the feedback! I didn't realize that the Microsoft cybercrimes team had used Sysinternals tools for the Rustock takedown - pretty cool!

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Original Paulie D — Wed, 06 Apr 2011 03:06:11 GMT

Mark, the depth of your knowledge and expertise knows no bounds. I truly enjoyed this article.

I thought you / your readers would find it equally interesting that Sysinternals tools were employed in the Rustock botnet takedown, as discussed at Microsoft's www.noticeofpleadings.com website (official lawsuit documents file 2011-March).

For example - see page 29 of the "Campana Declaration (Exhibits 1-10)" document:

noticeofpleadings.com/images/Campana_Declaration_Ex_1-10_.pdf

Not unlike the details you shared, sites such as FireEye have published similar details on the Rustock botnet, including a list of known C&C IP Addresses used by Rustock, as seen here:

blog.fireeye.com/research/2011/03/an-overview-of-rustock.html

Great stuff - keep it coming!

The original Paulie D

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Steve — Tue, 05 Apr 2011 15:13:09 GMT

The depressing thing about this is that there's hardly anything the average user can do to stop this behavior and still use general purpose consumer operating systems. Patching and virus scanners simply don't protect against this, and neither does "being careful."

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Stefan Woe — Fri, 01 Apr 2011 09:58:14 GMT

It is not totally correct that "...code reprograms Siemens SCADA (Supervisory Control and Data Acquisition) systems used in some centrifuges"

The centrifuges themselves are controlled by programmable logic controllers (PLC) which vice versa are controlled remotely by a SCADA System (thats the whole nature of a SCADA). On of the real "innovations" of Stuxnet was that it not only infected windows machines, but also PLCs by a dedicated PLC rootkit (en.wikipedia.org/.../Stuxnet).

re: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Mubarak — Thu, 31 Mar 2011 12:30:27 GMT

Excellent article! I remember using such techniques at my former employer to disinfect Windows Xp installations (c 2006) rather than the "easy" approach of downloading shareware to do the job.

I didn't know it was called reverse engineering.