Duqu: father, son, or unholy ghost of Stuxnet?
Jeremy Sparks, cyberspace officer, U.S. Air Force
Three U.S. Air Force information security experts, independent of their role in the military, studied the Duqu trojan, and you might be surprised by what they found. This is the first article in a two-part series that examines the sophisticated threat that everyone is talking about.
In June 2010, the world learned of the Stuxnet worm.
It was quickly identified for its payload affecting the industrial control systems (ICS) community and was hailed as one of the most advanced cyber weapons ever to be released.
The authors behind Stuxnet were never identified, although many speculated that the United States and Israel were involved. More importantly, though, it was asserted by a few in the industry that a portion of the worm's code, referred to as the weapon system, would be used in the future with modified code, referred to as the payload, to attack different targets.
Fast forward to Oct. 18, when Symantec published its dossier n the Duqu trojan. Duqu uses the weapon system part of the Stuxnet code, but does not utilize the Stuxnet payload, which targeted programmable logic controllers (PLCs).
Duqu was also designed to be much stealthier than Stuxnet. Stuxnet self-replicated and infected all available systems while only initiating its payload on specific targets. Instead, Duqu does not self-replicate after being injected onto a target system and only has a 36-day operation window before it deletes itself.
During these 36 days, the Duqu trojan attempts to exfiltrate information from the targeted systems and networks back to its command-and-control server (C&C) in India. The malware uses .JPG images to send and receive its encrypted files to its C&C server using both HTTP and HTTPS connections.
While Stuxnet did not use image files to steal data it did steal information from the Iranian nuclear centrifuges and sent its data to C&C servers in Malaysia and Denmark.
With all the similarities between Stuxnet and Duqu, the interesting part lies with the order of their release.
Duqu in its design and intended purpose, as we understand it currently, is the type of remote access trojan (RAT) that would have been used to create Stuxnet. Stolen schematics, design documents, and stolen or forged certificates would have all been used in creating Stuxnet.
Duqu has been hailed as the “son of Stuxnet” but it is possible that it is instead the “father of Stuxnet.” The compiling times of Duqu indicate that it was released after Stuxnet. However, there are most likely many variants of Duqu that have yet to be identified, including those that could have compile times before Stuxnet's release.
However, the focus should not be on whether Duqu or Stuxnet came first, but instead in identifying that the weapon system part of the code is now a template of choice for an advanced adversary.
The source code doesn't Lie
RATs are commonly used for computer network exploitation and cybercrime. The targets associated with Duqu, including industrial manufacturers and a university, indicate that the cybercrime angle is less likely. Cybercrime syndicates are not sophisticated enough or willing to pull off a multiyear operation, like Stuxnet or Duqu. A cybercrime syndicate would also have to either produce its own ICS equipment or blackmail a vendor to properly utilize the information obtained from Duqu.
The Duqu variants discovered so far also indicate that the authors learned lessons from Stuxnet. For example, each variant of Duqu could have used different injection methods which may never be fully identified. One method that was identified was a Windows kernel level zero-day hidden in a Microsoft Word document. It is likely that there are multiple droppers for Duqu that may include multiple types of 0-days. The injection methods not discovered are thus valuable resources to Duqu's creators that can be reutilized.
There have been assessments made that Duqu and Stuxnet may not be related because some of the functions and techniques, including kernel driver injection points, are used in other unrelated malware. That does not serve as a strong argument to unlink Stuxnet and Duqu.
The fact is that there are so many similarities between the two pieces of malware that any individual link to other malware is insignificant. Duqu's use of a kernel-level 0-day makes the malware highly sophisticated and consistent with the level of Stuxnet. Duqu has also been identified as attempting to exploit the MS08-067 vulnerability, one of the exploits used in Stuxnet, on two Iranian networks, which, among the other evidence, is a very strong connection.
In regard to the source code, examinations of both binaries expose an obvious relationship. Some of the files created by Duqu are functionally identical, as well as nearly perfect binary matches.
According to Symantec, there is a 50 percent similarity between Stuxnet's code and Duqu. As a matter of perspective, non-related malware samples may have less than a 25 precent code match. Considering the changed payload, the 50-percent match between Stuxnet and Duqu is substantial. This is nearly impossible to achieve without having a common heritage in the original source code.
In fact, the code is so similar that some anti-virus engines actually confused the two pieces of malware as being the same.
Although some Stuxnet binaries and associated research data were released by Anonymous following its infiltration of HBGary, one cannot say hackers used this code to create Duqu. While it is true that reverse-compiling techniques exist, they are often unreliable and usually only work well with very simple programs.
Stuxnet binaries were large, 1 MB in size, and complex compared to most malware in existence. Stuxnet would not reverse-compile well regardless of the resources invested in the task. Even with a large team of highly skilled reverse engineers, it would take a considerable amount of time to produce even a section of the original Stuxnet source code. If that was possible the next task would be overcoming the difficulties of finding and using a signed digital driver.
Based on these factors, it can be stated with a high level of confidence that the authors of Stuxnet and Duqu are the same.
Coming next week: The authors take a closer look at Duqu to determine its motives.
Jeremy Sparks, Robert M. Lee, and Paul Brandau are cyberspace officers in the U.S. Air Force; however this paper and their views do not represent the Air Force, Department of Defense, or any agency within the U.S. government. The opinions held in this paper are theirs alone, and this paper was written outside of a military capacity.