The Duqu Saga Continues: Enter Mr. B. Jason and TV’s Dexter

As we informed you earlier, we’ve recently been conducting an investigation into a number of incidents in connection with a Duqu trojan infection. Thankfully we’ve been able to make some headway in getting to the bottom of Duqu and putting together several of the previously absent components without which it has been difficult to understand what’s actually been going on.

First things first, we would like to express our sincere thanks to the specialists at CERT Sudan. They’ve been providing us with priceless assistance in our investigation, and showed the utmost professionalism – in full accordance with the values and aims of any CERT around the world. Our cooperation with the Sudanese CERT is ongoing and will cover another three incidents found in the country.

Our main achievement has been in the investigation of the incident deemed No.#1, described in my second post about Duqu. We managed to not only locate all the previously undiscovered files of this variant of Duqu, but also to find both the source of the infection and the file dropper that contains the vulnerability exploit in win32k.sys (CVE-2011-3402).

Comparing the data we uncovered with that obtained by other researchers and antivirus companies, we’ve elicited various common traits that have revealed the approximate timeline and overall methods used by Duqu’s authors.

The dates of the incident correlate with the history of discovery in Iran of a virus called Stars. At that time Iranian specialists didn’t share samples of the discovered virus with any of the anti-virus companies, and this, it has to be said, was a serious mistake, which gave rise to all subsequent events in this saga. Most probably, the Iranians found a keylogger module that had been loaded onto a system and which contained a photo of the NGC 6745 galaxy. This could explain the title Stars given to it.

It’s possible that the Iranian specialists found just the keylogger, while the main Duqu module and the dropper (including the documents that contained the then-unknown vulnerability) may have gone undetected.

Stage I: Penetration, E-mail

The attack took place on a pre-selected target. For obvious reasons, we can’t reveal the name of the company that was targeted in incident No.#1,. Like with the incident investigated by CrySyS Lab, the attack was launched via e-mail.

The object was attacked twice – on April 17 and 21, 2011. The first attempt turned out to be unsuccessful (the e-mail from the attackers wound up in the junk folder), after which they repeated the attack four days later, amending the subject line of the e-mail slightly.

Mr. B. Jason sure was dedicated and persistent. It wasn’t a mass spam mail-out, since both the subject and the name of the file mentioned the attacked company specifically.

Both times the e-mail was sent from one and the same IP-address, based in Seoul, South Korea. We reckon that this computer was infected earlier by some kind of malicious program and was used unknowingly (to its owner) as a proxy.

The second attack turned out successful: the addressee opened the attached DOC file that contained the vulnerability exploit and Trojan installer.

The attackers used an interesting ruse at this stage. After the addressee opened the file the exploit started its work: it became active, residing in the memory, but did nothing! Meanwhile, both the original file and Word itself could have been closed.

This period of inactivity lasted around ten minutes, after which the exploit waited for the user’s activity to stop (no keyboard or mouse activity). Only then did the dropper kick into action.

The variant of the dropper that we found differs somewhat from the dropper found by the Hungarian laboratory Crysys and described by Symantec. However, these differences relate mainly to sizes and dates of creation of the component upon a tiny change to the code.

The overall arrangement at this stage looked like this:

Exploit -> kernel -> driver in kernel -> loader dll in services.exe -> big pnf in services.exe -> big pnf installing from lsass or AV process.

The shellcode of the exploit was contained in an embedded font processed by the win32k.sys system. The font was called Dexter Regular, and its creators were shown as Showtime Inc.

This is another prank pulled by the Duqu authors, since Showtime Inc. is the cable broadcasting company behind the TV series Dexter, about a CSI doctor who happens also to be a serial killer who avenges criminals in some post-modern perversion of Charles Bronson’s character in Death Wish.

The driver loaded by the exploit into the kernel of the system had a compilation date of August 31, 2007. The analogous driver found in the dropper from CrySyS was dated February 21, 2008. If this information is correct, then the authors of Duqu must have been working on this project for over four years!

The driver loaded in the services.exe process a library, which was also located in the body of the exploit – the main module of the dropper – and ran its code.

At this stage the dropper attempts to check in the registry the following key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsZones4“CF1D”

It should be noted that in the document published by Symantec a CFID key is mentioned; however, this may be a typo.

The dropper retrieves from its body the contents of the “.init” section in which there is a header with the magical identifier CIGH, plus extra settings, a PNF (.DLL), and a driver which gets installed on the system. After unpacking the contents of the section, a test is carried out for correspondence of the current date with the range installed in the heading of the “.init” section of the dropper. If the date doesn’t fall within that range, the Trojan is not installed.

In our variant, this range was from August 17, 2010 to July 18, 2012. In the sample of the dropper found by CrySyS the range was different: August 17, 2005 to November 2, 2023.

Next, the dropper loads the PNF (DLL) part and transfers control to the function exported as No.4. This function is responsible for the installation onto the system and the launch of the driver of the Trojan and encrypted library (PNF DLL), together with the configuration file. The configuration file contains the date of infection and the period of work of the Trojan in the system (by default – 30 days, but this period could change depending on commands from the control center).

In this incident, as we assumed earlier, a unique set of files was used, which is different from earlier-known sets. The most important difference is that the main module of the Trojan (the PNF DLL file) had a creation date of April 17 – the same day as the first attack on the victim. This fact shows that the authors build a separate set of files for each specific victim, and do so right before the attack.

The files we discovered amount to the following collection:

The differences in size of the main DLL (they were found on different computers in one incident) are explained by the fact that, in the first variant of the DLL, the component interacting with the control center is stored in the PNF DLL as a resource numbered 302; and in the second variant this component is included in the compressed “.zdata” section of a loader library that is stored as resource 302. We assume that the compression took place upon forming the set for attacking a different computer on the network.

The control server (C2) used in this set also differed from previously discovered ones in India and Belgium. In this incident the control center was situated in another country; however, we cannot publically announce the data due to the ongoing nature of the investigation. Besides, we know of yet another control center used in a different incident; it too is currently being analyzed. This information shall be published shortly. This also seems to indicate that the attackers have used a separate C&C for each unique attack.

Stage II: Collecting Info

During our investigation of the incident it was established that two computers were compromised in one organization. The first of them was the source of infection from April 21; the second was compromised later, at the end of May. The infection of the second computer occurred via the local network.

After infection of the system and establishing the link with the control server, it is clear that an extra module known as a keylogger was loaded and installed, which was able to collect information about the system, take screenshots, search for files, capture passwords, etc. To date, the existence of at least two variants of the given module has been confirmed – that found by Crysys Lab (compilation date June 1, 2011) and that found by Symantec (compilation date August 10, 2011). We haven’t been able to find a similar module in the given incident; however, we can announce that it existed as far back as in May 2011.

On both computers were found traces of the operation of a spy module, i.e., files named ~DFxxxxx.tmp (e.g., ~DF1EF83.tmp) and ~DQx.tmp (e.g., ~DQ2C6.tmp).

The name format of the file ~DF differs from the names of the temporary files created by MS Word, which use the format ~DF.

~DF files contain a compressed identifier of the infected system and start with the line ABh91AY&SY. ~DQ files contain gathered information (lists of processes, screenshots, info about applications). These files are also compressed and contain a similar marker, differing by just one symbol: AEh91AY&SY.

At present we do not know what module creates the ~DF files (the ~DQ files are created by the known spy module), or what their precise target is. On the first computer these files were dated April 27 – three days after the date of infection.

On May 25, 2011, the spy module created the file ~DQ181.tmp

In it is contained information about the network neighborhood of the initially infected computer. On the next day, May 26, 2011, infection of the second computer in the network was recorded. On it was created the file identifier ~DF.

What is interesting here is the fact that later on the second computer was created yet another ~DF file. This occurred on June 2, 2011. This date coincides with the date of compilation of the known spy module (June 1, 2011). It is possible that in this period of June 1-2 the authors of Duqu installed this new version of the module on all the infected computers via the C&C server.

Traces of the work of this module are visible in the existence of file ~DQ4.tmp, created on June 29.

We found three ~DQ-type files, created on May 25, June 29 and August 24. We noticed that all three dates are Wednesdays. This could be just a coincidence, maybe not. Still, based on this ‘coincidence’ it is possible to name the group behind Duqu as the Wednesday’s Gang 🙂

The Trojan was present in the infection of systems from April 21 right up to the end of October 2011. Its configuration files were installed over at least a minimum of 121 days; the reinstallation of the main module occurred back at the end of June 2011.

During all this time the attackers periodically installed new modules, infected other computers on the network, and collected information.

Conclusion

As part of the investigation of the given incident we’ve established the entry points for penetration of the systems, dates of events, and several facts regarding the conduct of the attackers. This information allows one to date one of the waves of attack to mid-to-late April 2011. Key findings include:

• For every victim, a separate set of attack files was created;
• Each unique set of files used a separate control server;
• The attacks were conducted via e-mails with a .DOC file attached;
• The mail-outs took place from anonymous mailboxes, probably via compromised computers;
• At least one e-mail address is known from which the mail-outs were conducted -bjason1xxxx@xxxx.com;
• For each victim, a separate DOC file was put together;
• The vulnerability exploit was contained in the font called “Dexter Regular”;
• The attackers changed the shellcode, and varied the range of dates for possible infection;
• After penetration into a system the attackers installed extra modules and infected neighboring computers;
• The presence on the systems of the files ~DF.tmp and ~DQ.tmp unambiguously points to an infection by Duqu.

Due to privacy reasons and protection of the identity of the victim, we cannot share the source .DOC file with other parties.

Also, we are not at present disclosing the address of the control server for this variant of Duqu; however, we think that it is not functioning now and all critical information on it has already been deleted by the attackers. This is also the case for one more control server we have discovered. Information about the control servers will be published later.

We can say that there are at least 12 unique sets of Duqu files known to us at present. The variant discussed in this post has been named variant F. Detailed information on the other variants will be published later.