During the past year, few security events gained as much media attention as the Duqu malware outbreak. The Duqu...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Trojan, or W32.Duqu, as it is formally known (pronounced dyü-kyü), creates files with the file name prefix “~DQ”. First identified Oct. 14, researchers have said it is strikingly similar to the dangerous Stuxnet Trojan, though Duqu was designed specifically to gather intelligence data, not take down nuclear reactors like Stuxnet.
Not all malware should gain the type of attention as Stuxnet, as there is significantly more dangerous malware in the wild for most enterprises and consumers. However, that doesn't mean Duqu should be ignored either. This tip examines Duqu, its capabilities, and how enterprises should respond to a potential threat like the Duqu Trojan.
Does the Duqu Trojan deserve the attention?
Duqu has received significant information security media attention partially because of its reported link to Stuxnet. The most recent reports suggest Duqu was created by the same organization, but it might not be based directly on the Stuxnet code. While that may remain a point of contention among security researchers, it does appear the Duqu developers learned a lot from Stuxnet.
The most notable aspects of Duqu from the recent Symantec report are how its command-and-control servers were forwarding connections to other servers and the peer-to-peer command-and-control components, although using peer-to-peer for command and control is also not new.
Duqu is a relatively sophisticated sample of malware, but many of its capabilities are standard fare in modern malware. Duqu is a remote access Trojan designed to steal information from specific organizations and uses many of the same techniques as other malware. The most notable aspects of Duqu from the recent Symantec report are how its command-and-control servers were forwarding connections to other servers and the peer-to-peer command-and-control components, although using peer-to-peer for command and control is also not new. The threat level Duqu poses to most enterprises is relatively low since it has only been detected in a small number of enterprises. Enterprises with high security environments and highly valuable assets should be more concerned, since they might be targets for Duqu-like attacks. Duqu and Stuxnet may be used in future attacks, but it is likely the attackers will use Duqu as an additional learning exercise to avoid detection in the future when using whatever major malcode follows Duqu.
Enterprise responses to Duqu
The general enterprise response to Duqu should be to evaluate if systems could have detected and prevented it, and to use it as an example for its computer security incident response team (CSIRT). As malware attacks become more advanced and more difficult to detect using traditional security tools, evaluating if or how an enterprise’s current information security tools can be used to detect malware such as Duqu helps ensure it’s prepared for future incidents.
Many of Duqu’s fingerprints, such as the command-and-control communications, can be detected using existing security technologies. If an enterprise kept network IP flow data from an IDS, it could use it to search for data leaving its network or for connections to the command-and-control servers. A DLP tool might even be capable of detecting the data leaving a network. An enterprise could even use a tool meant for system management to inventory all of the files on a system on a daily basis and then analyze the differences (also on a daily basis) to look for unauthorized changes, or use a file integrity monitoring tool to identify when a malicious file was written to a system. A Duqu infection could potentially be prevented by using a whitelisting application that only allows approved code to run.
Using Duqu as an example for a CSIRT exercise also prepares an organization for a similar targeted attack. If gaps are found in an incident response process, new systems or sources of data can be investigated to ensure an enterprise can detect the malware. Most reports on Duqu indicate it infiltrated networks many months prior to detection. By the time it was detected, the data it targeted had most likely already been stolen. Because Duqu utlized a Microsoft Windows zero-day vulnerability and was custom malware, it was not detected by many antivirus or antimalware products, a common problem with targeted attacks. Hence, the best bet for an enterprise to protect itself against damage or losses resulting from Duqu-like attacks is speedy detection and an incident response strategy. This is not to say speedy detection and a good incident response strategy are the only security controls necessary, but advanced malware or a well-resourced attacker could potentially bypass any preventative security controls.
Lessons learned from Duqu malware
While there are much more dangerous malware samples in the wild, there are still some valuable lessons to be learned from Duqu. Enterprises should implement necessary controls to secure their endpoints from the attacks they could face; few enterprises were targeted by Duqu, but most organizations eventually will be forced to respond to a targeted attack of one sort or another, even if it is just a phishing attack.
As advanced attack techniques are commoditized, as described by HD Moore’s Law, the wider attacker community adopts the attacks. There are certainly more advanced attacks we never hear about, so more public data on the more advanced attacks only improves how enterprises secure their systems. With the increasing sophistication and ease of use of exploit kits, enterprises should implement reasonable security controls across their environment and protect individual valuable assets appropriately.
About the author:
Nick Lewis, CISSP, is an information security architect at Saint Louis University. Nick received his Master of Science in Information Assurance from Norwich University in 2005 and Telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and previous at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.