BeyondTrust

Security in Context: The BeyondTrust Blog

Welcome to Security in Context

Bringing you news and commentary on solutions and strategies for protecting critical IT infrastructure in the context of your business.

Duqu, Son of Stuxnet, Destroyer of Worlds!

Posted October 20, 2011    Marc Maiffret

So, as everyone has hopefully heard by now, the world is indeed coming to an end because of a new piece of malware dubbed Duqu. Duqu is supposed to be based off of Stuxnet and therefore it makes it the scariest thing in cyber space or, as FoxNews.com said, “Stuxnet Clone ‘Duqu’: The Hydrogen Bomb of Cyberwarfare?”

The fuss is being made because some anonymous researchers sent a report to some anti-virus companies showing analysis of some new malware that shared similar characteristics to Stuxnet. This has of course lead people to make all sorts of outlandish claims of what this means and how bad it all is.

The reality, however, is that while Duqu and Stuxnet might share characteristics within their code and how they embed into a system, it becomes apples and oranges to draw any more comparisons than that. What made Stuxnet revolutionary was not how it compromised systems using zeroday, or how it backdoored systems, but rather its unique ability to actually implant code into physical systems to cause actual damage in the real world outside of cyberspace.

The capabilities of Duqu, while maybe structured like Stuxnet, are not unique to Stuxnet or Duqu. In fact, a lot of the command and control functionality that is accessible by attackers leveraging Duqu is not much different than any of the functionality you get in common botnet malware. The ability to list processes, take screen shots, log keystrokes, load modules, grab system information, etc… is all functionality that a wide variety of malware backdoor programs have these days.

One could argue that it is hard to actually write any modern piece of malware these days that does not include various functionality and characteristics from Duqu, Stuxnet, Aurora and so on and so forth.

This is not to take away from the original anonymous research report on Duqu, which most of the anti-virus industry initially based their assessments on, as there surely are things in that report that show a level of technical similarities to how Duqu was structured in a way that is the same as Stuxnet. The distinction is not in the code similarities, but in the functionality Duqu gives you compared to any other modern malware.

The original anonymous research report cited by Symantec, McAfee and other Anti-Virus companies, however, also draws conclusions that are a bit unnecessary. There is a table within the report that lists the various features of Stuxnet and Duqu that also shows which of those features are shared between the two. If a feature is shared, they both get a check box. There are a total of 26 features and about 14 out of 26 of those features are shared between Stuxnet and Duqu. Why include features in the table that are not shared? Probably for completeness—obviously not just to make the comparison table look bigger.

Of course, there are some shared features that are distracting from the comparison of Stuxnet and Duqu, since they are shared not just by Stuxnet and Duqu, but by all sorts of modern malware. Things like Visual C++ payloads, UPX compression, etc… Then there are features that have a check box for Stuxnet and Duqu, so as to indicate they are shared, but then caveats are given, such as “Seems based on Stux.”, “different alg.”, “almost the same”, etc… I am probably just nitpicking, but I find it is helpful when making assertions that you either know something to be true or not. You start losing a lot of credibility when you start using words like “seems” and “almost.”

I am not typically a fan of anonymous research reports that are quickly regurgitated by large anti-virus companies to drive “sky is falling” headlines. What you end up getting is exactly what we have now… major news media outlets and security industry publications blowing everything out of proportion, using “what if” and “maybe” quotes. There is an utter lack of facts and scientific rigor in any discussions.

There was one security publication that quoted a security company representative as saying “Duqu could be the precursor to another SCADA-type attack. Or the events could be entirely independent.”

I understand that sound bites can be hard to say, but our industry is honestly becoming more and more hype-oriented by giving sloppy, fear mongering quotes with little to no factual information to back any of it up. By industry, I probably mean society, but I digress. I mean really, to say “SCADA-type attack,” to then just “it could be”? But “maybe it is not”? Then, it becomes “maybe?” Finally it lands on “who really knows?” Imagine if our U.S. military leaders said “Iran might be bringing nuclear weapons into the country or maybe they are not, we are not really sure.”

While I could point out all the random inaccuracies, discrepancies, and generally funny and interesting things surrounding Duqu, at the end of the day, that doesn’t really help anybody. The thing that has worried me from the moment I heard about Duqu until now and the thing that doesn’t seem to be getting near as much attention as the “sky is falling” rhetoric is: What methods is Duqu using to actually compromise systems in the first place?

You see, there is new malware being found every day and plenty of malware that is being found that, when embedded on a system, gives an attacker just as much control over the system as anything Duqu can currently do. Call it Duqu or name any of the other botnet malware out there—the fact is these things are prolific and are just as likely already compromising industrial control systems and certificate authorities as they are Fortune 500 enterprises, defense contractors and so forth.

We will never win while we, as an industry, focus on chasing the next malware threat. Even in the most sophisticated attacks, such as Stuxnet, the malware and attacks being leveraged could have been prevented through simple best practices.

Few people ever talk about real prevention though.

Few people ever analyze these high profile attacks and mention the 5-10 things an IT person could have done proactively, and usually for free, to have easily prevented these attacks. Instead, we talk about doomsdays scenarios of what the malware might do. We talk about how some anti-virus product now has updated signatures to find these bad things after the fact.

We talk about everything except what IT folks, who are so desperate for knowledge and help, need to know to actually start fighting back against these threats in a proactive way.

At eEye, we do more than just tell IT people to “update their signatures.” If my team and I are able to find any further information on the root cause of how Duqu is actually compromising systems, we will be sure to publish meaningful preventative security measures, just as we did starting with CodeRed so many years ago and as we did with Stuxnet, the supposed father of Duqu.

Editor note: For more commentary and analysis on the Duqu “phenomenon”, you can follow both Marc Maiffret and eEye on Twitter. 

Leave a Reply

Additional articles

Ponemon_Report

Big Surprise: Cost of Data Breaches Up; Are you Doing the *Right* Things to Mitigate the Costs?

Posted May 28, 2015    Scott Lang

Ponemon Institute Cost of Data Breach Study – costs are going up – to the tune of a 23% increase in total costs of data breaches, and a 12% increase in per-record cost since 2013. Are you doing the right things to mitigate costs?

Tags:
, ,
IRS-Data-Breach

The tip of the IRS data breach – and it IS an iceberg

Posted May 27, 2015    Morey Haber

The IRS has been warned for decades about their security best practices. And now, at least 100,000 Americans have had their records compromised. How? The IRS uses a service called “Get Transcript”.

Tags:
, , ,
dave-shackleford-headshot

Tales from the Datacenter: Vulnerability Management Nightmares

Posted May 27, 2015    Dave Shackleford

Vulnerability scanning, threat management, risk analysis, patching, and configuration management are some of the major activities usually associated with vulnerability management, and none of these are new…so why are we failing so badly at many of them?

Tags:
, ,