Duqu Attackers Wiped Out C&C Infrastructure After Public Disclosures

Researchers have known for years that virus writers and attackers pay close attention to the analyses researchers do of their work, and it appears that the Duqu authors are no exception. Shortly after the first public reports about Duqu emerged in early autumn, the crew behind Duqu wiped out all of the command-and-control servers that had been in use up to that point, including some that had been used since 2009.

DuquResearchers have known for years that virus writers and attackers pay close attention to the analyses researchers do of their work, and it appears that the Duqu authors are no exception. Shortly after the first public reports about Duqu emerged in early autumn, the crew behind Duqu wiped out all of the command-and-control servers that had been in use up to that point, including some that had been used since 2009.

An in-depth analysis of the known C&C servers used in the Duqu attacks has found that some of the servers were compromised as far back as 2009, and that the attackers clearly targeted Linux machines. All of the known Duqu C&C servers discovered up to this point have been running CentOS, with some being 32-bit systems and others 64-bit. The servers that the Duqu attackers have been using in their operations have not been confined to any one region or country, but instead have been located in a variety of countries, including Vietnam, Germany, Switzerland, the Netherlands and India.

The new analysis, done by researchers at Kaspersky Lab based on known C&C servers in Vietnam and Germany, found that the most likely scenario for the compromise of the C&C servers is through a brute-force password attack. However, the researchers also found some evidence on the servers that they analyzed that could indicate that the attackers were using a zero-day vulnerability in a specific OpenSSH package to compromise the servers. Immediately upon compromising a new server, the attackers would update the existing OpenSSH installation from 4.3 to version 5.8. It was among the first tasks that the attackers carried out on each new server, in fact.

The researchers found some forum posts from 2009 discussing a possible zero-day flaw being used against OpenSSH 4.3 in active attacks. But the most likely attack scenario seems to be the password bruteforcing.

“Could this be the case here? Knowing the Duqu guys and their never-ending bag of 0-day exploits, does it mean they also have a Linux 0-day against OpenSSH 4.3? Unfortunately, we do not know. If we look at the ‘sshd.log’ from 18 November 2009, we can, however, get some interesting clues. The ‘root’ user attempts to log in using a password multiple times from an IP in Singapore, until they finally succeed,” Vitaly Kamluk, a malware expert at Kaspersky Lab, wrote in a new analysis of the Duqu C&C infrastructure.

“Note how the ‘root’ user tries to login at 15:21:11, fails a couple of times and then 8 minutes and 42 seconds later the login succeeds. This is more of an indication of a password bruteforcing rather a 0-day. So the most likely answer is that the root password was bruteforced. Nevertheless, the third question remains: Why did the attackers replace the stock OpenSSH 4.3 with version 5.8?”

The first public discussions of the Duqu attacks surfaced in mid-October when Symantec published a report. However, researchers at Kaspersky and other companies had gotten private reports about it in September. But within a couple of days of the public reports of Duqu, the attackers began systematically cleaning all of the C&C servers that they’d been using.In one case, researchers missed getting an image of a still-active C&C server by just a few hours.

“A global cleanup operation took place on 20 October 2011. The attackers wiped every single server which was used even in the distant past, e.g. 2009. Unfortunately, the most interesting server, the C&C proxy in India, was cleaned only hours before the hosting company agreed to make an image. If the image had been made earlier, it’s possible that now we’d know a lot more about the inner workings of the network,” Kamluk wrote.

Despite the advances in analyzing the known C&C machines, the researchers still haven’t been able to identify the one server that’s being used to control all of the subordinate C&Cs. They have grown more and more confident, however, in recent weeks that whoever wrote Duqu likely also was involved in the development of Stuxnet.

Suggested articles

Discussion

  • Anonymous on

    From looking at the linked article, why do people allow a root log in over SSH?  Having to guess a username and password would make it much more difficult, no?  A simple change to sshd_config would resolve that if they are bruteforcing passwords.

    Regardless, I stopped allowing root access over SSH long ago once I noticed the option.  Why do people still use it?

  • Anonymous on

    Root access is enabled by default for the initial setup of a server, and then best practices would be to disable remote root access once a new user account is created, and instead using 'su' or 'sudo' from then on when something needs to be done that requires root.

     

  • Anonymous on

    Even better, in your server, named server1, in /etc/ssh/sshd_config set:

    PermitRootLogin   without-password

    This means you can no longer use a password to log in as root. It does _not_ mean you can now log in without a password!

    Then, on your administration machine, named admin1, create a keypair, WITH A PASSPHRASE !, like this:

    ssh-keygen -t rsa -b 8192                     ( I know, ridiculously long key, but hey, maybe it will even stop a quantum computer)

    Then it will ask where to put the key, the default is /<your_homedir>/.ssh/id_rsa. If you need multiple keys for multiple servers, you can name it id_rsa_server1 or whatever.

    Now it will ask for a passphrase. This can be a really long password, or some nonsense sentence (multiple words) that no-one can ever guess. You have to enter this twice. This is used to encrypt the key itself.

    What you have now are a key with two parts: a private one called id_rsa, and a public one that is named id_rsa.pub.

    Now you must put the public key you just made on admin1 on server1:

    cat  /<your homedir>/.ssh/id_rsa.pub | ssh root@server1 'cat >> /root/.ssh/authorized_keys'

    Or for this last step you can use the command

    ssh-copy-id   -i   /<your homedir>/.ssh/id_rsa.pub  root@server1

    The end result is that you now use a very long random key instead of a password to log in to your server, and the key itself is protected by a passphrase. Also, desktop environments like GNOME (well version 2 at least) have a neat ssh-agent, which will cause a window to appear asking for your passphrase. After the first time, you no longer need to provide a passphrase during your login session on admin1.

     

  • Anonymous on

    "Unfortunately, the most interesting server, the C&C proxy in India, was cleaned only hours before the hosting company agreed to make an image."

     

    What no backup ? or do they just want everyone to think they didnt get any evidence ?

  • Anonymous on

    Agreed!

  • Anonymous on

    If one had to guess why they patched and how they gained access, the version numbers in question are quite telling:

     

    http://www.cvedetails.com/vulnerability-list/vendor_id-7161/product_id-12081/version_id-58393/Openssh-Openssh-4.3.html

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.