Blog - Securelist

securelist.com | Dec 28th 2016

It appears that this may be a homepage or an index page with non-article content. To accurately view it, you may want to switch to the Full Web Page view.

If you know there should be an article here, help improve the article parser by reporting this page. Thanks!

Home→Blog→Targeted Attacks

All threats Author search 2011Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Latest posting By rating By popularity

28 Dec The Mystery of Duqu: Part Seven (Back to Stuxnet) Aleks

30 Nov The Mystery of Duqu: Part Six (The Command and Control servers) VitalyK

15 Nov The Mystery of Duqu: Part Five Igor Soumenkov

11 Nov Story of one presentation - Gartner Symposium Barcelona Vicente Diaz

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

05 Nov Duqu First Spotted as 'Stars' Malware in Iran Ryan Naraine

Join our blog

You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.

Incidents|The Mystery of Duqu: Part Seven (Back to Stuxnet)

Aleks
Kaspersky Lab Expert
Posted December 28, 16:37 GMT
Tags: Duqu, Targeted Attacks, Stuxnet 0.3

We have been studying the Duqu Trojan for two months now, exploring how it emerged, where it was distributed and how it operates. Despite the large volume of data obtained (most of which has yet to be published), we still lack the answer to the fundamental question - who is behind Duqu?

In addition, there are other issues, mostly to do with the creation of the Trojan, or rather the platform used to implement Duqu as well as Stuxnet.

In terms of architecture, the platform used to create Duqu and Stuxnet is the same. This is a driver file which loads a main module designed as an encrypted library. At the same time, there is a separate configuration file for the whole malicious complex and an encrypted block in the system registry that defines the location of the module being loaded and name of the process for injection.

This platform can be conventionally named as ‘Tilded’ as its authors are, for some reason, inclined to use file names which start with "~d".

We believe Duqu and Stuxnet were simultaneous projects supported by the same team of developers.

Several other details have been uncovered which suggest there was possibly at least one further spyware module based on the same platform in 2007-2008, and several other programs whose functionality was unclear between 2008 and 2010.

These facts significantly challenge the existing "official" history of Stuxnet. We will try to cover them in this publication, but let us first recap the story so far.

Comment Link

Incidents|The Mystery of Duqu: Part Six (The Command and Control servers)

VitalyK
Kaspersky Lab Expert
Posted November 30, 15:10 GMT
Tags: Duqu, Targeted Attacks, Zero-day vulnerabilities, Stuxnet 0.6

Over the past few weeks, we have been busy researching the Command and Control infrastructure used by Duqu.

It is now a well-known fact that the original Duqu samples were using a C&C server in India, located at an ISP called Webwerks. Since then, another Duqu C&C server has been discovered which was hosted on a server at Combell Group Nv, in Belgium.

At Kaspersky Lab we have currently cataloged and identified over 12 different Duqu variants. These connect to the C&C server in India, to the one in Belgium, but also to other C&C servers, notably two servers in Vietnam and one in the Netherlands. Besides these, many other servers were used as part of the infrastructure, some of them used as main C&C proxies while others were used by the attackers to jump around the world and make tracing more difficult. Overall, we estimate there have been more than a dozen Duqu command and control servers active during the past three years.

Before going any further, let us say that we still do not know who is behind Duqu and Stuxnet. Although we have analyzed some of the servers, the attackers have covered their tracks quite effectively. On 20 October 2011 a major cleanup operation of the Duqu network was initiated. The attackers wiped every single server they had used as far back as 2009 – in India, Vietnam, Germany, the UK and so on. Nevertheless, despite the massive cleanup, we can shed some light on how the C&C network worked.

Incidents|The Mystery of Duqu: Part Five

Igor Soumenkov
Kaspersky Lab Expert
Posted November 15, 14:15 GMT
Tags: Duqu, Targeted Attacks, Zero-day vulnerabilities, Stuxnet 0.3

Driver

The driver is the first component of Duqu to be loaded in the system. As we discovered, the driver and other components of malware are installed with a dropper exploiting a 0-day vulnerability (CVE-2011-3402). The driver is registered in the HKLM\System\CurrentControlSet\Services\ registry path. The exact name of the registry key varies in different versions of Duqu drivers.

Once the driver is loaded, it decrypts a small block that contains its registry key and the name of the registry value to be read from that key. It also contains the name of the driver object to create.

All versions of the driver available at the moment have the same registry value name, “FILTER”.

The driver then registers the DriverReinitializationRoutine that queues the WorkerRoutine where actual driver initialization is performed. In the WorkerRoutine the driver reads the “FILTER” value from registry and decrypts it with a hard-coded encryption key. There are two known versions of decryption routine and two corresponding decryption keys. The driver also locates the NTOSKRNL.EXE or NTKRNLPA.EXE module and gets the addresses of API functions for further usage.

The decrypted “FILTER” value from registry contains the list of records that contain the name of the process (“services.exe”), the path to corresponding PNF DLL file that will be injected in that process and the decryption key (0xAE240682) that is used to decrypt the PNF DLL file.

After initialization the driver registers LoadImageNotifyRoutine that will be then called by Windows each time a new module is loaded. The routine checks if the name of image matches one of these specified in “FILTER” value and if it does, starts the injection: it decrypts and copies the PNF DLL file into an allocate memory region on that process. It also builds an copies a stub EXE file into that process that is then used as a loader for the PNF DLL.

As soon as “KERNEL32.DLL” is loaded in the same process, it locates addresses of API functions required by the loader EXE and modifies the original entry point of the main process module so that it passes execution to the loader EXE code.

The loader EXE module performs initial initialization of the PNF DLL module and then executes the export as specified in the configuration (“FILTER”). After that it restores the code of the original entry point and returns execution to the original process module. The loader also interacts with the driver module using a custom IOCTL code to change memory protection of the original entry point code.

PNF DLL file

This module is stored on disk as an encrypted block of data. As soon as it is decrypted, it turns out to be a DLL packed with UPX. Known versions of PNF DLL modules export 8 or 6 different functions by ordinal numbers.

Export 2 runs export 6 in a separate process.

Export 4 runs export 5 in a separate process.

Export 5 starts a thread in “services.exe” process that loaded the 302 resource (see below) and, if provided with correct information by the callee, installs a complete new set of Duqu components.

Export 6 stops the driver and completely uninstalls all components of Duqu. Export 8 and 1 initialize the PNF DLL module and start main threads.

It seems that ordinal 1 is intended to export primary functionality of the DLL. First, it loads the configuration information from another PNF file, the PNF Config file. If the file is not present, it is created from an encrypted hard-coded copy that is stored in the PNF DLL file.

The name of the configuration file is different for every version of Duqu. The PNF Config contains the name and path to the driver component, to the PNF DLL and PNF Config itself.

When the PNF Config is created, the date of creation is written into the file. The file also contains the TTL (“time to live”) value: a separate thread started by PNF DLL monitors if TTL days passed since the creation date, and after that runs the uninstallation routine.

Some versions of the PNF DLL also start an RPC server similar to the one found in Stuxnet.

The PNF DLL also provides API for manipulating the configuration file from external modules using globally available events.

Depending on the flags in the PNF Config, the PNF DLL code looks for specific processes: the list of process names in the PNF Config, “explorer.exe”, “svchost.exe” and then injects code in them. The code to be injected is stored in binary resource 302 found in PNF DLL.

302 resource

Depending on the flag in the PNF configuration file, it is either a DLL loader module or a block of data (equivalent of decompressed “.zdata”, see below). Both configuration have been found in different Duqu versions. The PNF DLL checks a flag in PNF Config and determines whether to pass execution to the DLL loader or to locate the payload DLL and call it directly.

The loader DLL module is similar to PNF DLL. The main purpose of the loader is to decompress its “.zdata” section and pass execution to the main payload that is contained in decompressed data.

The .zdata block contains the header that starts with the magic number 0x48747193. It contains the offsets and sizes of the DLL loader, the payload configuration block and the payload DLL.

Configuration block

The configuration block contains the name of the temporary file to use %TEMP%\~DR0001.tmp, additional binary data controlling the behavior of the payload and information required to connect to the C&C servers. There are two lists of C&C servers, one can contain domain names, IP addresses or names of network shares, and the other contains IP addresses in binary format and is used to connect using Windows HTTP (winhttp) services. Although the configuration blocks we have found so far are similar and are set up to connect to its C&C using HTTP and HTTPS, the payload DLL is able to connect to a network share and even become a server.

Payload

We are still analyzing the payload. It contains 256K of C++ code with extensive use of STL and its own complex class hierarchies, probably own framework.

The payload is able to connect to C&C server using either winhttp library or connection to a network share IPC$ endpoint. It is able to connect using proxy server configuration of Internet Explorer. It also contains code for acting as a HTTP server and processing the same requests as served by the C&C. The payload is able to load an external DLL module provided by the C&C and interact with it using a pre-defined API. The most noticeable module discovered so far is the infostealer module. There are also modules for updating the TTL value in the PNF DLL configuration, for reading the network and disk storage configuration from the infected machine.

It also can form a PNF DLL with a configuration block and the payload DLL ready for distribution to other machines.

2 comments Link

Events|Story of one presentation - Gartner Symposium Barcelona

Vicente Diaz
Kaspersky Lab Expert
Posted November 11, 14:59 GMT
Tags: Social Engineering, Targeted Attacks, Zero-day vulnerabilities 0.2

This week I attended the Gartner Symposium in Barcelona. The event is for IT leaders and executives, held in a magnificent venue and superbly organized.

Having the chance of giving a talk there, I wondered what kind of message should I give to such attendees. These people lead big companies and get regular reports from the best analyst in the world. During the conference basically they will get tons of information, and I wanted my message to remain in their minds, so I decided to go for a practical approach.

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

Aleks
Kaspersky Lab Expert
Posted November 11, 12:09 GMT
Tags: Duqu, Microsoft Word, Targeted Attacks, Vulnerabilities and exploits, Zero-day vulnerabilities, Stuxnet 0.7

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.

Incidents|Duqu First Spotted as 'Stars' Malware in Iran

Ryan Naraine
Kaspersky Lab Expert
Posted November 05, 15:55 GMT
Tags: Duqu, Targeted Attacks, Zero-day vulnerabilities, Stuxnet 0.3

As we continue to investigate the Duqu targeted attack, there is new information that suggests the malware was created to spy on Iran's nuclear program.

Some background and facts:

Back in April this year, Iran announced it was victim to a cyber-attack with a virus called "Stars." This article offers some additional details on that attack.

We can now confirm that some of the targets of Duqu were hit on April 21, using the same method involving CVE-2011-3402, a kernel level exploit in win32k.sys via embedded True Type Font (TTF) file.

According to analysis by IrCERT (Iran's Computer Emergency Response Team) Duqu is an upgraded version of "Stars":

If we are to believe these reports, then it means that Duqu was created in order to spy on Iran's nuclear program.

Just yesterday (November 4), the United Nations announced it was in possession of plans from Iran to make computer models of a nuclear warheads.

"The annex will also say that more than 10 nations have supplied intelligence suggesting Iran is secretly developing components of a nuclear arms program - among them an implosion-type."

It would not be surprising that Stars and Duqu were used to collect such information.

1 comments Link

Incidents|The Mystery of Duqu: Part Three

Aleks
Kaspersky Lab Expert
Posted November 02, 12:35 GMT
Tags: Duqu, Targeted Attacks, Zero-day vulnerabilities, Stuxnet 0.5

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’.

Comment Link

Incidents|The Mystery of Duqu: Part Two

Aleks
Kaspersky Lab Expert
Posted October 25, 19:59 GMT
Tags: Duqu, Rootkits, Targeted Attacks, Industrial control systems, Stuxnet, Certificate authorities 0.9

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.

Incidents|The Mystery of Duqu: Part One

Aleks
Kaspersky Lab Expert
Posted October 20, 11:52 GMT
Tags: Duqu, Rootkits, Targeted Attacks, Keyloggers, Industrial control systems, Stuxnet, Certificate authorities 0.6

First of all, we feel it necessary to clarify some of the confusion surrounding the files and their names related to this incident. To get a full understanding of the situation you only need to know that we’re talking about just two malicious programs here (at a minimum) - the main module and a keylogger. All that has been mentioned in last 24 hours about connections between Duqu and Stuxnet is related mostly to the first one - the main module.

The main module consists of three components:

a driver that injects a DLL into system processes;
a DLL that has an additional module and works with the C&C; and
a configuration file.

The module is very similar to Stuxnet - both in structure and in behavior. However, the name Duqu has almost no connection with it. This name is based on the names of the files that are related to a completely different malicious spy-program!

This second malicious program, which is basically a keylogger (but is also able to collect other types of information) was discovered on the system of one of the victims together with the main module described above. Because of this fact, plus the main module’s ability to download other components, it was assumed that the main module and the keylogger were somehow related to each other. While working in a system, the keylogger stores collected data in files with names like ~DQx.tmp. So the name of the main module – Duqu – was given based on these files.

But actually, the code of the Trojan-Spy in part proves the connection between it and the main module, and it was probably downloaded by the main module sometime earlier. But as per its functionality, it is an independent malicious application able to work without the main module. At the same time, the main module is able to work without the Trojan-Spy. However, the connection between the keylogger and Stuxnet is not so obvious, and that’s why it’s possible – at a stretch – to perhaps call it a grandchild of Stuxnet, but certainly not its child :)

Incidents|Duqu FAQ

Ryan Naraine
Kaspersky Lab Expert
Posted October 19, 17:04 GMT
Tags: Duqu, Rootkits, Targeted Attacks, Keyloggers, Industrial control systems, Stuxnet, Certificate authorities 0.8

Updated November 15th, 2011 (Scroll down to bottom)

This is an active investigation by Kaspersky Lab's Global Research & Analysis Team. We will be updating this FAQ document as necessary.

What exactly is Duqu? How is it related to Stuxnet?

Duqu is a sophisticated Trojan which seems to have been written by the same people who created the infamous Stuxnet worm. Its main purpose is to act as a backdoor into the system and facilitate the theft of private information. This is the main difference when compared to Stuxnet, which was created to conduct industrial sabotage. It's also important to point out that while Stuxnet is able to replicate from one computer to another using various mechanisms, Duqu is a Trojan that doesn't seem to replicate on its own.

Does this target any PLC/SCADA equipment? Exactly who/what are the targets? Do we know?

Unlike Stuxnet, Duqu doesn't target PLC/SCADA equipment directly, although some of its subroutines could be used to steal information related to industrial installations. It appears that Duqu was created in order to collect intelligence about its targets, which can include pretty much anything that is available in digital format on the victim’s PC.

How does Duqu infect computers? Can it spread via USB devices?

In the cases we have analysed, Duqu infects a computer through a targeted attack involving a Word document which exploits the CVE-2011-3402 vulnerability. This is a 0-day vulnerability in the Windows kernel component Win32k.sys which allows the attackers to run code with the highest privilege level, bypassing pretty much most of the protection mechanisms from Windows or security software. According to our knowledge, Duqu is the only malware using this vulnerability to infect computers. All Kaspersky Lab security solutions detect this vulnerability under the name Exploit.Win32.CVE-2011-3402.a as of November 6, 2011.

Is there any exploit, especially zero-day in Duqu?

There is indeed a 0-day vulnerability being used to infect computers in the initial phase. Microsoft released an advisory (2639658) with basic information and mitigation steps.

How did AV vendors become aware of this threat? Who reported it?

Duqu was brought to the attention of the security community by the Hungarian Research Lab CrySyS. They were the first to point out the resemblance to Stuxnet and perform what remains the most thorough analysis of the malware yet.

When was this threat first spotted?

The first Duqu attacks were spotted as early as mid-April 2011. The attacks continued in the following months, until October 18, when news about Duqu was made public.

How many variants of Duqu are there? Are there any major differences in the variants?

It appears that there are at least seven variants of the Duqu drivers, together with a few other components. These are all detected with different names by various anti-virus companies, creating the impression that there are multiple different variants. At the time of writing, we are aware of two Infostealer components and seven different drivers. Additionally, we suspect the existence of at least another Infostealer component which had the capability to directly search and steal documents from the victim's machine.

There is talk that this specifically targets Certificate Authorities. Is this true?

While there are indeed reports indicating that the main goal of Duqu is to steal information from CAs, there is no clear evidence at this time to support this claim. On the contrary, we believe the main purpose of Duqu was different and CAs were just collateral victims.

Symantec says this is targeted to specific organizations, possibly with a view to collecting specific information that could be used for future attacks. What kinds of data are they looking for and what kinds of future attacks are possible?

One suspicion is that Duqu was used to steal certificates from CAs that can be used to sign malicious code in order to make it harder to catch. The functionality of the backdoor in Duqu is actually rather complex and it can be used for a lot more. Basically, it can steal everything, however, it looks like attackers were particularly interested in collecting passwords, making desktop screenshots (to spy on the user) and stealing various kinds of documents.

Is the command-and-control server used by Duqu still active? What happens when an infected machine contacts the C&C?

The initial Duqu C&C server, which was hosted in India is no longer active. Just like in the case of Stuxnet, it was pulled offline pretty quickly once the news broke. In addition to this, we are aware of another C&C server in Belgium, which was also quickly taken offline. Actually, it appears that every single Duqu targeted attack used a separate C&C server.

Why is Duqu configured to run for 36 days?

Maybe the author was a fan of round numbers, such as 6x6? :) Actually, the time for which Duqu is running in the system is defined by the configuration file and varies between the attacks. We have also seen instances where the duration was set to 30 days.

Who is behind this attack?

The same gang who was behind Stuxnet. Curiously, they seem to have picked up an interest in astronomy; the infostealer executable has a portion of a JPEG file picked up by the Hubble telescope (“Interacting Galaxy System NGC 6745”):

The picture portrays the aftermath of direct collision of two galaxies(!), several million of years ago. You can read the story here.

UPDATE (November 15, 2011):

Q: What exactly is being stolen from the target machines?

When activated, the main Duqu program body connects to its C&C server and downloads updates and supplemental modules. One such module is the Duqu "infostealer," for which two versions are known and others are believed to have existed at various points in the time.

The "infostealer" module is downloaded in memory and executed through the process injection technique used by Stuxnet and Duqu to avoid temporary files. This is done in order to make sure that the "infostealer" component (and other Duqu updates) will not be intercepted or left behind on an infected machine. It also means that they have a limited lifetime, basically until the next system reboot.

The most powerful version of the "infostealer" has the ability to intercept keystrokes, it makes screenshots of the whole screen (first time) and of the active window, collects the IE browsing history and various data related to the system network configuration. There is also code which can do browsing of network shares. All this information is nicely packaged into a file that is written into the %TEMP% folder by default. It is a compressed BZIP2 format with modified headers. Thanks to the BZIP2 compression, the files are smaller than you'd think.

The "infostealer" components we have seen create files with the name "~DQx.tmp". In addition to this, we are aware of other files with the name "~DFxxxxx.tmp" and "~DOxxxxx.tmp". The "DF" and "DO" have a similar format and appear to have been generated by an earlier version of the "infostealer". They also contain more information, including various files the victim PC such as Word or Excel documents. The "~DF" files are generally much bigger, due to their additional file content.

In all cases, they are easy to recognize by the header "ABh91AY&SY". If you find such files in your PC then most likely you've been a victim of Duqu. If you'd like to scan your system for such files, the nice people at CrySyS have a set of tools that can help.

Q: I heard that Duqu and Stuxnet are written by the same people. I also heard that Duqu and Stuxnet are written by different people. What is the truth?

Duqu and Stuxnet have a lot of things in common. Usage of various encryption keys, including ones that haven't been made public prior to Duqu, injection techniques, the usage of zero-day exploits, usage of stolen certificates to sign the drivers, all of these make us believe both have been written by the same team.

So, what does that mean exactly? Simply put, different people might have worked on Duqu and Stuxnet, but most likely they worked for the same "publishing house." If you want an analogy, Duqu and Stuxnet are like Windows and Office. Both are from Microsoft, although different people might have worked on them.

Q: What is the link between Duqu and Showtime's Dexter?

In the incidents we have analyzed, Duqu arrives in the system in the form of a Microsoft Word Document. The document contains an exploit for the vulnerability known as CVE-2011-3402. This is a buffer overflow in a function of Win32k.sys which deals with True Type fonts. To exploit this specific vulnerability, an attacker needs to craft a special True Type Font and embed it into a document, for instance, a Word Document.

Now, for the connection part - in the incident we've analyzed (and this is also true for the other known incident), the attackers used a font presumably called "Dexter Regular", by "Showtime Inc.," (c) 2003. 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 also happens to be a serial killer who avenges criminals in some post-modern perversion of Charles Bronson's character in Death Wish.

Q: So, are the Duqu authors sociopath serial killers with an interest in computer malware?

We hope they are just fans of Dexter.

Q: Stuxnet contains a particular variable which points to May 9, 1979, the date when a prominent Jewish businessman called Habib Elghanian was executed by a firing squad in Tehran. Are there such dates in Duqu as well?

Interestingly, the same constant can be found in Duqu as well. The Hungarian CrySyS lab was the first to point out the usage of 0xAE790509 in Duqu. In the case of Stuxnet, the integer 0x19790509 is used as an infection check; in the case of Duqu, the constant is 0xAE790509.

What is less known is that 0xAE790509 was also used in Stuxnet, however, prior to Duqu this was not included in any of the public analyses we are familiar with.

There are also many other places where the constant 0xAE is used, both in Duqu and Stuxnet.

Finally, the constant 0xAE240682 is used by Duqu as part of the decryption routine for one of the known PNF files. In case you are wondering, 24 June 1982 is indeed an interesting date - check out the case of BA flight 9.

* Research by Kaspersky Lab Global Research & Analysis Team.

Further reading: The Mystery of Duqu: Part One, The Mystery of Duqu: Part Two and The Mystery of Duqu: Part Three.

Also see:

* Duqu First Spotted as 'Stars' Malware in Iran

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

* The Mystery of Duqu: Part Five

6 comments Link

Original Page: http://www.securelist.com/en/blog?topic=199380263

Shared from Read It Later

אל

Posted via email from DailyDDoSe