## 2 Duqu
### Duqu Analysis  
In order to investigate the reason of the incident at the company that requested our help, and to be able to fix the system such that the same type of incident cannot happen again, we were allowed to access the hard drive of an infected computer. We produced a virtualized copy of the affected computer, which allowed us to revert the machine to a former state at any point during the analysis.  
We hypothesized from the beginning that the malware loads a kernel driver, so the first task was to find that driver. The driver called cmi4432.sys became suspicious, but it was inactive on the particular computer we investigated, and it was digitally signed. Therefore, we performed a systematic search: we deleted groups of kernel drivers until we found that the malware was no longer active, and then refined the search iteratively to pinpoint the driver that was part of the malware. This led to the identification of another driver called jminet7.sys. After that, we recognized that cmi4432.sys is indeed connected to the threat. We also discovered some suspicious PNF files that did not have any corresponding INF files installed on the system. (Windows INF files contain setup information for programs and drivers in textual form, while PNF files contain the same information in a pre-compiled format. Normally, PNF files are generated automatically by Windows from INF files when they are copied on the computer.) Finally, we uncovered three main groups of malware components: a standalone keylogger, a group of objects related to jminet7.sys, and another group of objects related to cmi4432.sys. The keylogger is a standalone executable that was found on an infected computer. It contains an internal encrypted DLL, which provides the keylogging functions, whereas the main executable injects the DLL and controls the logging process. The objects of the jminet7 group work as follows: In the registry, a service is defined that loads the jminet7.sys driver during the Windows boot process. This kernel driver then loads configuration data from itself and from the registry, and injects code from a DLL called netp191.pnf into a system process. Finally, some configuration data is stored in an encrypted configuration file called netp192.pnf. The objects of the cmi4432 group essentially exhibit the same kind of behavior, but they use the files cmi4432.pnf and cmi4464.pnf.  
This sort of behavior was very similar to the operation of Stuxnet. Our suspicion that Duqu and Stuxnet are related grew rapidly when we discovered that Duqu also injects code into the lsass.exe process; it uses non-existent virtual files, and it uses the same hooks from ntdll.dll as Stuxnet. In addition, as we mentioned before, the driver cmi4432.sys had a valid digital signature on it. The corresponding certificate belonged to a Taiwanese company that did not seem to be the author of the driver, so we suspected that the signature was generated with a compromised private key. The only known case at that time where malicious kernel drivers were signed with possibly compromised keys was the case of Stuxnet, and the compromised keys belonged to Taiwanese firms in that case too.  
Given the strong evidence for a highly sophisticated malware, we decided to carry out a deeper analysis of Duqu to see if it is really related to Stuxnet. The potential connection between the two incidents urged us to reveal Duqu's existence to the security community as soon as possible. Thus, we set 10 days as a hard deadline for ourselves to finish the analysis; we did not aim at completeness, rather we wanted to understand as much as possible within 10 days and then release our analysis report. Below, we summarize the key findings of our analysis. Due to space limitations, we keep the discussion brief, and we refer the interested reader for more details to our technical report [10].