The Mystery of Duqu: Part Two

Nytro · October 26, 2011

The Mystery of Duqu: Part Two

Aleks

Kaspersky Lab Expert

Posted October 25, 19:59 GMT

Partea I: http://www.securelist.com/en/blog/208193182/The_Mystery_of_Duqu_Part_One

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 and is contained within 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 provided later 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 find 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 important and urgent. It is much more essential to understand the reasons and sequences of 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’t either confirm or deny information from other AV vendors about known incidents in the UK, USA and possibly in Austria and Indonesia. We are making no comments on any 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 very specific 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 file name, size and checksum at this point.

Incident #2: Iran

At the moment, the highest number of Duqu incidents were found 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 remain 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 it’s different with the content because this file must be unique. It stores information about the infection date in order to control further uninstall process.

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 previous 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 2 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:

1	 Publisher	 Intel Corporation
2	 Product	 Intel Graphics Accelerator
3	 Description	 Intel Graphics Kernel Mode Driver
4	 File version	 2.2.0.15
5	 Original name	igdkmd16b.sys
6	 Internal name	igdkmd16b.sys
7	 Size	 25088 bytes
8	 Date of compilation	17 October 2011

Notice that before this incident, we have never seen a file with the size 25088 bytes. Until this case, we have only seen drivers with the size of 24960 bytes (without digital signature) or 29568 bytes (with 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 it was 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 it was in all 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 found a fact that is probably not related to this Duqu case. BUT!

This computer was attacked for several times via network not so long time ago: 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 12-day period from one IP address. What is the probability that this attack was automatically performed by Kido? It is possible in case of a single attack. It is impossible in case of two attacks. It means that we may suggest 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 have recorded incidents just in Sudan and Iran;

2. We have no information about victim’s relations either with Iran’s nuclear program or with CAs or industries;

3. It is obvious that every single Duqu incident is unique with its own unique files with different names and checksums;

4. Duqu is used for targeted attacks with carefully selected victims(Here was APT word but it strikethrough because I don’t like this term);

5. We know that there are 13 different driver files at a minimum (and we have only 6 of them);

6. We haven’t found any ‘keylogger’ module usage. It is possible that 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 showed 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 the probability of missing detection of the main DLL component (PNF) is almost 100%;

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 C&C and commands, then Duqu’s infrastructure on a particular system might be changed completely;

10. Authors of Duqu were able to install updated modules on infected systems just before the information about this malware has been published because we continue to discover new Duqu drivers created on October 17, 2011. We do not exclude the fact that they were able to change C&C;

11. We do not exclude that 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 is not entirely correct. Even this data point is customized: only jminet7.sys/netp191.pnf uses its 36-day counter. Set of modules cmi4432.sys/cmi4432.pnf will remove itself after 30 days.

Sursa: http://www.securelist.com/en/blog/208193197/The_Mystery_of_Duqu_Part_Two