The Mystery of Duqu: Part Three

First things first, I have to point out a mistake in the previous text.

When analyzing the fourth incident in Iran, we stated that there were two network attacks on a victim machine from the IP address 63.87.255.149. It could have been an exclusive version of Duqu, but it turned out to be a big mistake.

Judge for yourself – Duqu checks for Internet connections and attempts to reach the server kasperskychk.dyndns.org which should be located at 68.132.129.18. An analysis of the information at this address shows that it is located at the same data center as the 63.87.255.149 IP address that we “discovered”!

In actual fact, however, I made a mistake when converting the address, which was the result of a single missing ‘minus’ sign: the numbers “1062731669” and “-1062731669”. In the first case, converting to an IP address we get 63.87.255.149, but in the second we get the local address 192.168.0.107, which, of course, is of no interest to our research whatsoever 🙁

Dropper and 0-day.

Now, for some much more interesting news. It turned out that the continuing research by the Hungarian lab Crysys has led to the detection of the main missing link – a dropper that performed the initial system infection.

As we expected, a vulnerability was to blame. An MS Word doc file was detected that was sent to one of the victims by the people behind Duqu. The file contained an exploit for a previously unknown vulnerability in Windows that extracted and launched components of Duqu.

Symantec and Microsoft still haven’t made the actual dropper file available to other antivirus companies yet, nor have they provided information about which Windows component contains the vulnerability that results in privilege escalation. However, indirect evidence suggests that the vulnerability is in win32k.sys.

We discovered a similar vulnerability (see MS10-073) a year ago when analyzing the Stuxnet worm. Another interesting problem in win32k.sys (MS11-077) was fixed by Microsoft on 11 October this year – a code execution vulnerability than can be exploited through font files.

Microsoft said it was working on the vulnerability used by Duqu, although it looks like a patch won’t be available in November’s updates.

The detection of the dropper and the route used to penetrate the system (a targeted attack against a specific victim conducted via email) proves our theory that the Duqu attacks are directed against a very small number of victims and in each case, they can employ unique sets of files. To infect other computers in the network, Duqu seems to be using scheduled jobs, a technique that we’ve also seen in Stuxnet and is a preferred choice of APTs. These, together with other previously known details reinforce the theory that Stuxnet and Duqu were created by the same people.

Additional information shows that the attackers worked meticulously with the affected systems, carefully gathering data from every computer, penetrating deeper and deeper into the local network of the victims. As well as a unique set of Duqu files for each victim, there may well be a unique command server (C2) for each entity that was attacked.

Our research shows that the incidents we detected involving Duqu in Sudan and Iran are actually bigger than initially thought. At the current time, we have recorded three victims in Sudan and four in Iran. We are already working with some of them to uncover all the Duqu components and to determine the path of the initial infection.

We expect to have those results in the very near future and will publish them in the next installment of ‘The Mystery of Duqu’.