For the last few days, much malware research time has been devoted to the brand-new malware that ESET calls Win32/Duqu. One of the features that makes this kind of malware particularly interesting is that it very closely resembles Stuxnet, one of the most sophisticated worms of recent years. Last year we performed in-depth analysis of
For the last few days, much malware research time has been devoted to the brand-new malware that ESET calls Win32/Duqu. One of the features that makes this kind of malware particularly interesting is that it very closely resembles Stuxnet, one of the most sophisticated worms of recent years. Last year we performed in-depth analysis of Stuxnet and released a comprehensive report on it. Now we are in the process of dissecting the Duqu’s binaries.
After some preliminary analysis it’s become evident that Duqu is based on the Stuxnet’s source code. From the point of view of the malware’s architecture, Duqu is almost identical to Stuxnet: namely, there is a kernel-mode driver which injects DLL into specific processes in the system. The DLL in turn includes the payload in its resources and exports the set of routines that implements specific actions. Besides the architectural similarities, the Duqu modules are very close to Stuxnet from a binary point of view: the same classes and structures were used to compile both Stuxnet and Duqu. Obviously the modules aren’t 100% identical, but we’ve found identical code patterns.
Since researchers started analyzing Duqu, many questions have been raised, most of which remain unanswered. In particular we have no (public) information about Duqu’s dropper and how and when it was installed onto the infected machines. This information is vital for forensic analysis. As regards the actual date on which the malware was installed, the key can be found in its configuration file. Since Duqu is intended to stay on the system only for a specified time span – after which it removes itself from the system – it was reasonable to assume that the date of infection was stored somewhere in the configuration file. It wasn’t difficult to figure out the code responsible for implementing this storage and thus to determine what location in the configuration data was used to store the date of installation.
The date and time when Duqu is first run on the infected system is stored in UTC format, at offset 0x123E from the beginning of the configuration file. Based on these data it is possible to determine the actual date when Duqu penetrated the system.
In the report «Duqu: the precursor to the next Stuxnet» the author mentioned that one of the modifications of Duqu they analyzed has a life time span of 36 days and on expiration of this date the malware removes itself from the system.
It is curious that the gamma array which is used to decrypt the data consists of *8 elements, of which only the first 7 elements are used. Although this might have been done intentionally, we consider it likely that it’s a small bug in its implementation.
Based on analysis of several samples, we observed that the life span differs between different samples. This value is defined in the configuration data (word at offset 0x124E). In the following graphics you can see fragments of configuration files showing lifespan information.
There are lots more interesting technical details in the Duqu code which we will be publishing in the course of our research.
*Not 7/6 elements, as previously stated due to a typographical error.
Aleksandr Matrosov, Eugene Rodionov, David Harley