The Mystery of Duqu: Part Two

Our investigation and research of Duqu malware continues. In our previous report, we made two points:

• there are more drivers than it was previously thought;
• it is possible that there are additional modules.

Besides those key points, we concluded that unlike the massive Stuxnet infections, Duqu attacks are limited to an extremely small number of targets.

But before informing you about our new findings, I would like to pay tribute to the Hungarian research laboratory Crysys for their work. They were the first who analyzed Duqu components and generated an excellent report. It was later provided to antivirus vendors and became the basis of further investigations. (Unfortunately, our company was not the first to receive this report, but now it’s even more interesting to find out everything about Duqu)

Our experts continue to conduct in-depth analysis of all Duqu components, and are finding more evidence of similarities between Duqu and Stuxnet. A detailed report with our experts’ analysis of files and their structure is in progress and will be published later. This part of our research is not the most urgent. It is much more important to understand the details of the attacks and the facts, which will be discussed here.

Real incidents

In our previous blog, we mentioned that in the previous 24 hours, we had found only one real incident after adding the detection of all known Duqu components. Since that incident, we have discovered more, and it allows us to make some conclusions about the attack vector itself.

It is important to mention that we can neither confirm nor deny information from other AV vendors about reported incidents in the UK, USA and possibly in Austria and Indonesia. We are making no comment on possible incidents in Hungary. Let’s focus only on cases we’ve discovered with the help of Kaspersky Security Network.

Incident #1: Sudan

One of the first real infection cases took place in a somewhat distinctive region, as we confirmed earlier. It happened in Sudan.

In this case, we found a completely new driver which differs from previous variants in both name and MD5.

Based on our finding that the main Duqu module consists of three components (driver, DLL library and configuration file), we may speculate that two more files are a part of the package. But we haven’t observed any detections in our customer base with our current detection set. It means that these files are different from known examples (netp191/192.pnf, cmi4432/cmi4464.pnf).

Unfortunately, we were not able to connect with the infected user for a detailed analysis and research effort for this incident. Also, we don’t have a copy of the adp55xx.sys driver. We know only the file name, size and checksum at this point.

Incident #2: Iran

At the moment, the highest number of Duqu incidents have been recorded in Iran. This fact brings us back to the Stuxnet story and raises a number of issues. But first, let’s look into some details.

We see the same situation: a new unique file name (iraid18.sys), an already known file size (24960 bytes) and a new checksum. But besides those three static file characteristics, there are some differences. We found not only a new driver, but also a new configuration file ird182.pnf. Doubtless, it’s analogous to known files (same size 6570 bytes) but some of the content is different, making this file unique. It stores information about the infection date in order to control further uninstall processes.

Another driver is even more interesting. We were not able to restore its original name. And, despite being the same size as previous Duqu drivers, it is also different from iraid18.sys, which was also found at the infected location. It is different from all previously known drivers.

At this point, we see an almost complete new set of modules with similar names: iraid18.sys + ird182.pnf + unknown main DLL library (which we suspect may have a name like ird181.pnf).

Incident #3: Iran

This incident is one of the most interesting. Here we have an infection of two systems connected to each other. Besides the fact that these systems are in one network, they were also infected with the same driver (new again) – igdkmd16b.sys. We were able to obtain a copy of this file:

Note that before this incident, we had never seen a file with the size 25088 bytes. Until this case, we have only seen drivers with the size of 24960 bytes (without a digital signature) or 29568 bytes (with a digital signature).

In addition, we found two more files on one of the systems (unfortunately, we weren’t able to get a copy of these files). The first file is a configuration file with the name netq795.pnf and the second file is an unknown driver with the same size of 25088 bytes, but with the different checksum.

As in incident #2, here we also have an almost complete new set of modules: igdkmd16b.sys + netq795.pnf + unknown main DLL library (which we suspect may have a name like netq794.pnf).

Incident #4: Iran

As in all the incidents described above there is a unique driver which differs from previous ones both in name (bpmgs.sys) and in size (24832 bytes). Unfortunately, we weren’t able to get a copy of the file and its content is still a mystery. The same goes for its corresponding configuration file.

At the same time, we discovered a fact that is probably not related to this Duqu case. BUT!

This computer was recently subjected to network attacks on October 4 and October 16. Both attacks used an exploit abusing the MS08-067 vulnerability (e.g. which was used by Kido and Stuxnet).

The IP address of the attacker is 63.87.255.149 (in both cases). It is owned by MCI Communications Services, Inc., a subdivision of Verizon Business.

So, imagine the situation. Two attacks in a 12-day period from one IP address. What is the probability that this attack was automatically performed by Kido? It is possible in the case of a single attack. It is impossible in the case of two attacks. It strongly suggests that these attacks were not accidental, but targeted. It is possible that the attacker used not only MS08-067 but also other exploits that were not traced.

Conclusions and facts

1. We only have recorded incidents in Sudan and Iran;
2. We have no information linking the victims to Iran’s nuclear program, CAs or specific industries;
3. It is obvious that every single Duqu incident is unique with its own unique files using different names and checksums;
4. Duqu is used for targeted attacks with carefully selected victims (The term APT has been used to describe this, but I don’t like this expression and prefer not to use it);
5. We know that there are at least 13 different driver files (and we have only 6 of them);
6. We haven’t found any ‘keylogger’ module usage. Either it has never been used in this particular set of incidents, or it has been encrypted, or it has been deleted from the systems;
7. Analysis of driver igdkmd16b.sys shows that there is a new encryption key, which means that existing detection methods of known PNF files (main DLL) are useless. It is obvious that the DLL is differently encoded in every single attack.
   Existing detection methods from the majority of AV vendors are able to successfully detect Duqu drivers. But it is almost 100% certain that the main DLL component (PNF) will go undetected.

8. Duqu is a multifunctional framework which is able to work with any number of any modules. Duqu is highly customizable and universal;
9. The main library (PNF) is able (export 5) to fully reconfigure and reinstall the package. It is able to install drivers and create additional components, record everything in the registry, etc. It means that if there is a connection to active the C&C and commands, then Duqu’s infrastructure on a particular system might be changed completely;
10. Duqu’s authors were able to install updated modules on infected systems just before the information about this malware was published because we continue to discover new Duqu drivers created on October 17, 2011. We cannot rule out the possibility that they were able to change the C&C;
11. We cannot rule out that the known C&C in India was used only in the first known incident (see original report from Crysys Lab) and that there are unique C&Cs for every single target, including targets found by us;
12. Reports that Duqu works on infected systems for only for 36 days are not entirely correct. Even this data point is customized: only jminet7.sys/netp191.pnf uses its 36-day counter. The set of modules cmi4432.sys/cmi4432.pnf will remove itself after 30 days.