Our investigation and research of Duqu malware continues. In our previous report, we made two points:
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.
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.
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.
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).
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:
|2||Product||Intel Graphics Accelerator|
|3||Description||Intel Graphics Kernel Mode Driver|
|8||Date of compilation||17 October 2011|
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).
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 220.127.116.11 (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.
2011 Oct 26, 18:37
Donna's New Idea
I think you need to make a "New",Anti Virus,