Like in 2009, CERT-Lexsi attended this week's Octopus Conference on Cybercrime at the Council of Europe.

I won't try to summarize 3 days of intense debates and presentations. You can find most of the presentations on the CoE website. Update: François Paget made also a good summary here and Roger Halbheer here (day 1 and 2).

I first want to thank the Council for all their work and commitment to these issues. This unique event brings together high-level law enforcement officers, prosecutors, regulators, industry experts...

I particularly appreciated the participation of bodies such as ICANN and RIPE to the event. I can't wait for the next ICANN meeting in Brussels to see if the issues discussed are really taken into account.

I also liked the momentum -particularly in South America and Africa- that receives the Budapest Convention. This treaty could indeed have a major impact on the fight against cybercrime in the long term. I hope new countries will soon join the initiative.

But I also regret that Ukraine and Russia have not express at any time their own views or some kind of support for the fight against cybercrime. It is even worse that no representative from China made the trip to Strasbourg.

I also publically emphasized the need for more involvement from the financial institutions and anti-money laundering authorities. I indeed strongly believe that cybercrime might be curbed by unabling cybercriminals to profit from their crimes. Technical, legal and financial barriers to commit cybercrimes are not high enough. That is why it is one of the less risky and most profitable criminal activity which attracts more people every day. On the legal aspect, modernisation of laws are indeed in progress and trying to fill the gaps in a lot of countries, but it will not be sufficient. More needs to be done to prevent cybercriminals from accessing and even setting up their own technical, financial and fiscal facilities.

Tomorrow, CERT-Lexsi will take part to another important law enforcement-oriented event, FIC 2010 in Lille. The fight continues...

On this blog, difficulties faced by antivirus software when dealing with fast-spreading malware such as Conficker or Virut were already exposed. Here is another tricky example: double infections.

We were recently contacted by a client who were experiencing difficulties to eradicate a virus from his machines, although it was detected by the antivirus deployed on his workstations and servers. To determine the malware family, let's begin by performing an on-demand scan with different antivirus engines on a sample:

Almost every AV detects the sample as a variant of Sality, the latest trendy PE infector. This can be quickly confirmed by looking at its section; there is indeed a .nrdata section with read/write/execute flags set:

However, it is well-known that malware assumptions can't be based on on-demand signatures only; the piece of malware will thus be executed in a sandbox. Among other things, we notice that access to the task manager and to the registry editors is blocked. So far, this is consistent with our Sality hypothesis, and we can begin to give pieces of advice to our client on how to remove a PE infector in a corporate environment.

But some other behaviors of the sample seem a bit odd. For example, the following items are not expected from a PE infector:

• the binary creates a netmon.exe process. It also drops a sysdrv32.sys driver and hides this process via DKOM on the _EPROCESS chained list. This driver is registered as Play Port I/O Driver. These names do ring a bell as they are used by the Neeris worm and some IRCbot.

• it creates 2 registry keys to ensure it will run even in Safe Mode (although Sality is known to remove the Network and Minimal keys of HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot to exactly prevent this)

• it tries to connect to port 445/tcp (microsft-ds) on random IP addresses:

In fact, this binary spreads by exploiting the MS08-067 vulnerability like Conficker, which can be proved by noticing the famous "\..\..\" pattern in SMB packets:

• it adds an exception to the Windows firewall and sets up a pseudo web server listening on a random port to distribute an executable which will be downloaded by newly infected systems when exploiting this vulnerability

By the way, we can notice that the server responds with a Server: private header. This string is hardcoded in the deciphered binary:

That's why, even if the listening port is random, this can be used to remotely detect infected systems. We have implemented this method in a simple Nmap script. An infected machine will return the following result:

PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
10387/tcp open  unknown
|_ http-Neeris/IRCbot-lexsi: System infected with Neeris/IRCbot

Finally, the system was in fact infected by 2 pieces of malware: Sality and Neeris/IRCbot, the former having infected the binary of the latter (explaining why some AV detected it as IRCbot and not Sality). This alters our removal recommendations as we will have to ensure that the patch fixing MS08-067 is deployed. You can't base an analysis only on signatures provided by AV vendors, as it may prevent you from setting a reliable removal procedure, especially due to the worm exploiting a vulnerability.

Besides, some Neeris/IRCbot variants also exploit weak passwords on the sa accounts of MS SQL servers and execute arbitrary commands via the xp_cmdshell stored procedure, or manipulate the MSN and AIM instant messengers to send the virus to the victim's contacts, which is not the case for Sality. However, it is hard to tell whether the Neeris/IRCbot sample was downloaded by Sality or if these virus managed to infect the network independently.

Luckily enough, this sample is detected by the MSRT, enabling us to quickly get rid of it before letting the AV disinfect each PE file.

This is not an isolated case. For example, we have already been contacted a few months ago for a double Neeris/Virut infection. Again, we shouldn't forget that antivirus, even up to date, are not an unbreakable barrier, unlike what many end-users, and even system administrators may think. It is only one piece of a corporate security plan, other pieces being for example strict security patch management and malicious outgoing connections monitoring.

Nous avons décrit à plusieurs reprises sur ce blog les difficultés rencontrées par les solutions antivirales pour faire face aux infections à grande échelle, comme Conficker ou Virut. Voici un autre cas, celui des doubles infections.

Un client nous a récemment contacté pour nous faire part de ses difficultés à éradiquer un virus de son parc, bien qu'il soit détecté par la solution antivirale déployée sur ses postes de travail et serveurs. Pour déterminer la famille du malware, commençons par effectuer un scan à la demande d'un échantillon avec différents moteurs antivirus :

Presque tous les antivirus s'accordent pour dire qu'il s'agit d'une variante de Sality, le dernier infecteur de PE à la mode (cf article dans MISC 48). Cela peut rapidement être confirmé en regardant les sections du binaire ; on trouve bien une section .nrdata, avec des caractéristiques de lecture/écriture/exécution :

Cependant, il est bien connu qu'il ne faut pas se fier aux signatures fournies lors des scan à la demande ; nous allons donc exécuter le binaire en sandbox. On constate alors entre autres le blocage de l'accès au gestionnaire des tâches et à l'éditeur de base de registre. Jusqu'ici, tout concorde avec Sality et on peut commencer à donner au client les premières préconisations d'éradication des infecteurs de PE en environnement d'entreprise.

Mais d'autres comportements du malware en VM ne correspondent pas à ce qui est attendu. En particulier, les éléments suivants sautent aux yeux :

• le binaire crée un processus netmon.exe. Il droppe également un pilote sysdrv32.sys et cache ce processus par DKOM sur la liste chainée des _EPROCESS. Ce driver est enregistré sous le service Play Port I/O Driver. Tous ces noms ne nous sont pas méconnus puisqu'il s'agit des caractéristiques que l'on peut retrouver dans le ver Neeris ou quelques IRCbot.

• il crée 2 clés afin d'assurer son lancement même en mode sans échec (alors que Sality est censé supprimer les clés Network et Minimal de HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot pour justement empêcher ce démarrage en mode sans échec, ce qui est contradictoire)

• il tente de se connecter au port 445/tcp (microsft-ds) sur des IP aléatoires :

De fait, le binaire se propage en exploitant la vulnérabilité MS08-067 à la manière de Conficker, ce qui est démontré par le fameux motif "\..\..\" dans les paquets SMB :

• il ajoute une exception au pare-feu Windows et met un pseudo-serveur web en écoute sur un port aléatoire pour distribuer un exécutable qui sera téléchargé par les systèmes nouvellement compromis lors de l'exploitation de cette vulnérabilité

Au passage, on remarque que le serveur répond avec un en-tête Server: private. Cette chaîne est codée en dur dans le binaire déchiffré :

Ainsi, bien que le port en écoute soit aléatoire, ceci peut donc être utilisé comme signature afin de détecter à distance les systèmes infectés. Nous avons implémenté cette méthode dans un simple script Nmap. Une machine infectée retournera le résultat suivant :

PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
10387/tcp open  unknown
|_ http-Neeris/IRCbot-lexsi: System infected with Neeris/IRCbot

Finalement, nous sommes donc face à un système infecté par au moins 2 malwares : Sality et Neeris/IRCbot, le premier ayant infecté le binaire du second (cela explique d'ailleurs que certains antivirus aient détecté le binaire comme IRCbot et non Sality). Cela modifie les préconisations de désinfection : en particulier, il va désormais falloir s'assurer que le correctif MS08-067 est bien déployé. Il ne faut donc pas uniquement se fier aux signatures fournies par la plupart des antivirus sous peine de ne pouvoir définir une stratégie de désinfection fiable, en raison de la virulence de la propagation du ver par exploitation de la vulnérabilité.

Par ailleurs, certaines variantes de Neeris/IRCbot exploitent également les mots de passe faibles sur le compte sa des serveurs MS SQL afin d'exécuter des commandes arbitraires par la procédure stockée xp_cmdshell, ou prennent la main sur les messageries instantanées MSN et AIM pour envoyer le malware aux contacts de la victime, ce qui n'est a priori pas le cas de Sality. En revanche, difficile de dire si ce Neeris/IRCbot a été téléchargé suite à l'infection par Sality, ou si les deux malwares ont infecté le parc indépendamment.

Ce Neeris/IRCbot est par chance correctement détecté et éradiqué par le MSRT, ce qui permet de s'en débarrasser rapidement avant de laisser la main à l'antivirus pour la désinfection des PE.

Il ne s'agit pas d'un cas isolé. Nous avons par exemple déjà été contacté par le passé pour des doubles infections Neeris/Virut. Une fois de plus, il est bon de rappeler que les antivirus, même à jour, ne sont pas la barrière que beaucoup de personnes, end-users ou administrateurs, considèrent comme infranchissable. Il s'agit d'une des briques de la sécurité d'un parc, complétée entre autres par l'application rigoureuse des correctifs de sécurité et le blocage et la surveillance des flux sortants malveillants.