L’équipe derrière WepAWet, également co-auteur de la très populaire sandbox Anubis, a mis en ligne le site du projet FIRE (accronyme pour FInd RoguE networks), qui présente des statistiques d’activité malicieuse par opérateur réseau.

On remarque immédiatement que les Etats-Unis sont plutôt en bonne position dans ce classement, puisqu’ils occupent 14 places sur les 20 places attribuées aux pires hébergeurs, qu’ils soient « seulement » laxistes ou complètement frauduleux. Si l’on inclut le Canada, alors le territoire nord-américain occupe 16 places. Ce qui confirme bon nombre d’études qui plaçaient l’Amérique du Nord comme principale source de malveillances informatiques dans le monde – sans pour autant préjuger de la nationalité des fraudeurs eux-mêmes, ce qui est une autre question.

Nous avons constitué notre propre palmarès des réponses tristement amusantes – ou consternantes, selon le point de vue – lors de nos prises de contact avec des opérateurs, certains étant présents dans la liste du projet FIRE. Toutes les citations qui suivent ont été prononcées dans le cadre d'interventions sur des cas urgents de fraude en ligne :

• « Nous ne comprenons pas en quoi le site mentionné est frauduleux ? » : usurpation de marque et de logo flagrantes, détournement de mots de passe et plaintes utilisateurs en série ne sont visiblement pas suffisants.
• « Laissez votre message sur notre boîte vocale. » : la boîte vocale en question raccroche après 10 secondes.
• « Nous ne pouvons pas fermer cet espace d’hébergement, nous transmettons votre demande à notre client. » : le « client » contacté, qui n’est autre que le pirate, doit encore rire de cet épisode.
• « Impossible de restituer son nom de domaine à cette entreprise car la demande de transfert du domaine semble en tout point légitime. » : le site web détourné affichait pourtant un drapeau israélien en flammes et des propos racistes.
• « Je suis au regret de ne pouvoir vous aider. Vous devriez plutôt appeler la police. » : on imagine les sirènes et la descente de police dans le datacenter…
• « Je suis actuellement à l'hôpital pour des examens, je ne peux pas vous aider. » : très bien, nous passons le message aux victimes de la fraude de patienter sagement.
• « Veuillez patienter, nous ne sommes pas des robots ! » : après notre douzième relance sans réponse.

Quelques répliques assez sinistres qui en disent long sur l'état de la lutte anti-cybercriminalité :

• « Je peux effectivement intervenir, mais virez-moi d'abord la somme de $2000. » : réponse donnée par l'administrateur d'un site web piraté en Mongolie.
• « Nous constatons effectivement la fraude, mais dans notre pays aucune loi ne nous oblige à intervenir, donc nous n’interviendrons pas. » : réponse donnée par un opérateur algérien.

Et pour finir sur une note positive, un hébergeur au Bénin prend visiblement le problème de la fraude très au sérieux puisque sa page d'accueil mentionne :

• « Je dors dans la salle des serveurs qui hébergent vos sites webs. Ce n'est pas très confortable, mais je me suis promis d'être le plus proche possible de vos serveurs quand il y a un problème pour maintenir la disponibilité de vos sites webs. Et je ne vais pas vous décevoir ».

Un malware intéressant a été repéré dans la nature : il s’agit d’un cheval de Troie Windows qui serait utilisé dans des attaques par rebond. Jusqu’ici rien d’original, si ce n’est que le troyen est coordonné au moyen d’une structure « command & control » (« c&c » -- aussi appelé « coordination ») hébergée sur un groupe de discussion Google.

Le malware est probablement d’origine chinoise, d’après l’analyse du code-source réalisée par Symantec, ainsi qu’en raison de la langue paramétrée pour le groupe (chinois simplifié – ce qui situerait les auteurs du malware en Chine, et non pas à Taiwan, où le chinois simplifié n’existe pas). Le groupe de discussion Google contient toute une série de messages chiffrés (base64 + RC4), qui contiennent des instructions à exécuter par le troyen ; ces instructions sont des commandes réseau de reconnaissance : résolution DNS, ping, et scan de ports. D’autres commandes portent sur l’ajout d’utilisateurs sur les machines infectées de manière à ouvrir une porte dérobée pour le pirate. Symantec suppose que le cheval de Troie aurait pu être conçu à des fins d’espionnage, ce qui est effectivement possible.

Les chevaux de Troie utilisent depuis quelques temps des techniques particulièrement innovantes pour se coordonner. Si il y a 10 ans on voyait surtout des botnets coordonnés par IRC, depuis quelques années les structures C&C sont hébergées sur des serveurs web accessibles en HTTP(S). En 2006, le ver Storm Worm implémentait une structure de contrôle en pseudo-P2P, destinée à masquer l’existence d’un serveur C&C central. Début 2009, Conficker implémentait une véritable coordination P2P, en poussant le concept jusqu’au bout, mais en ne renonçant pas à un second mode de coordination alternatif via un serveur central (ce mode de coordination ayant d’ailleurs été contrecarré par le Conficker Working Group avec l’enregistrement préventif de plusieurs centaines de milliers de domaines avec lesquels Conficker prévoyait d'entrer en communication).

Depuis, d’autres expériences ont été tentées par les pirates : plusieurs chevaux de Troie sont désormais contrôlés à travers des structures C&C hébergées sur Twitter. Le but recherché est d’entraver au maximum l’action des forces de l’ordre : d’une part, en rendant plus difficile l’intrusion sur le serveur C&C – le pirate bénéficiant de la protection implicite des serveurs de Twitter ou de Google Groups, et n’a pas à se soucier lui-même de sécuriser sa machine ; et d’autre part, à minimiser les traces du pirate et les éléments à charge pouvant être retenus contre lui. En effet, à l’inverse des serveurs C&C dédiés qui sont utilisés comme de véritables outils de travail collaboratif, et où sont souvent stockées des informations particulièrement compromettantes pour les pirates (logs de connexion, fichiers, bases de données, etc. pouvant induire un profilage très précis des criminels), un C&C sur Twitter ou Google Groups n’est rien d’autre qu’un canal de communication unidirectionnel pour le botnet. Et enfin, cela complique la tâche des administrateurs réseaux qui chercheraient à détecter et interdire l'accès aux serveurs C&C depuis le réseau de l'organisation en se basant sur des listes noires de domaines ou d'adresses IP.

On peut aussi imaginer à l’avenir un malware tirant ses instructions de profils Facebook, MySpace ou Flickr, et téléchargeant ses mises à jour depuis des sites de partage de fichiers.

Cette démarche est toutefois peu adaptée aux botnets de grande taille, en raison du trafic important qu’ils génèrent, et induit un risque accru de décapitation du réseau, dans la mesure où Twitter et Google réagissent rapidement à de tels signalements.

Microsoft has just released its security bulletins for September. Eight vulnerabilities have been fixed, all rated critical. The 0-day affecting IIS has not been fixed.

MS09-045: vulnerability in the Windows JScript scripting engine (Ref Lexsi 12234)

MS09-046: vulnerability in the Windows DHTML editing component ActiveX control (Ref Lexsi 12233)

MS09-047: two vulnerabilities in Windows Media (Ref Lexsi 12236)

MS09-048: three vulnerabilities in the Windows TCP/IP stack (Ref Lexsi 12235). One of them, allowing an attacker to cause a remote denial of service with very little resource, was disclosed in 2008 by Outpost24 and the affected vendors have just released their patches in a coordinated manner. This patch will not be available on Windows 2000 due to the huge modifications that it would imply. But surprisingly enough, it will not be available on Windows XP either, Microsoft justifying it by the fact that no service is listening for incoming remote connections on this system by default... Another vulnerability in Vista and 2008 when parsing a TCP field can potentially allow remote code execution. This is the same kind of vulnerability as the 0-day affecting SMBv2 discovered yesterday.

MS09-049: vulnerability in the Wireless LAN AutoConfig Service (Ref Lexsi 12232). It can be remotely exploited without user interaction to execute arbitrary code, the only condition being that the user has its wireless interface up! However, it only affects Vista and 2008.

Like every month, the MSRT has been updated and now supports Bredolab and Daurso. The former is a downloader, installing other malicious software; the latter is a password stealer and can be installed by the former. It searches for connection information stored by several popular FTP clients (FileZilla, CuteFTP, etc), as well as in the Windows Protected Storage. This can be critical if the webmaster's system becomes infected, thus allowing access to the web site by the attacker, for example to add a malicious iframe.

Microsoft vient de livrer ses correctifs pour le mois de septembre. Huit vulnérabilités ont été corrigées, toutes qualifiées de critiques. La 0-day affectant IIS n'est pas corrigée.

MS09-045 : vulnérabilité dans le moteur JScript de Windows (Réf Lexsi 12234)

MS09-046 : vulnérabilité dans le composant ActiveX d'édition DHTML de Windows (Réf Lexsi 12233)

MS09-047 : deux vulnérabilités dans Windows Media (Réf Lexsi 12236)

MS09-048 : trois vulnérabilités dans la pile TCP/IP de Windows (Réf Lexsi 12235). L'une d'elle, permettant de provoquer un déni de service avec très peu de ressources, avait été publiée par Outpost24 fin 2008 et la plupart des éditeurs concernés viennent de publier leurs correctifs de manière concertée. Ce correctif ne sera pas disponible pour Windows 2000 en raison des trop grandes modifications qui seraient nécessaires. Mais plus étonnant, il ne le sera pas non plus pour Windows XP, Microsoft se justifiant par le fait qu'aucun service n'est en écoute distante par défaut sur ce système... Une autre vulnérabilité dans le traitement d'un champ TCP par Vista et 2008 permet potentiellement d'exécuter du code arbitraire à distance. Le type de vulnérabilité est proche de celle découverte hier sur SMBv2.

MS09-049 : vulnérabilité dans le service d'autoconfiguration wifi de Windows (Réf Lexsi 12232). Elle peut être exploitée à distance sans aucune interaction afin d'exécuter du code arbitraire, avec la seule condition que la victime ait activé sa carte wifi ! Cependant, seules les versions Vista et 2008 sont vulnérables.

Comme chaque mois, le MSRT a été mis à jour, supportant désormais Bredolab et Daurso. Le premier est un downloader, installant d'autres malware sur le poste ; le second est de type password stealer et peut être installé par le premier. Il recherche localement les informations de connexion stockées par les logiciels de transfert FTP les plus courants (FileZilla, CuteFTP, etc), ainsi que depuis le Protected Storage de Windows. Cela peut être critique si le poste du webmaster se fait infecter, donnant ainsi l'accès au site web pour par exemple y ajouter une iframe malveillante.

Yesterday, a vulnerability (Lexsi Ref. 12225) announced as a remote denial of service affecting Microsoft Windows Vista, Seven and 2008 has been published by a security researcher. It affects the driver for the SMBv2 protocol, a new version of the well-known SMB. By changing a single parameter of a "negotiation protocol" SMB query, a remote attacker could cause a BSOD.

But let's have a more closer look...

The execution of the exploitation code against one of our test machines causes the following blue screen:

We note that the impacted driver is srv2.sys and that the instruction causing the PAGE_FAULT is located at 0x8E18A749. If we open the driver using a disassembler, we observe the following code:

We can see that the modified value in the packet (here eax) is then directly used as an index of a functions array! The vulnerability could then be exploited to redirect the execution flow to a memory area we control, allowing remote execution of arbitrary code with the privileges of the kernel ...

It is unfortunate that the researcher has not adopted the practice of responsible disclosure, by reporting the vulnerability to Microsoft without publishing it, to give time to the editor to correct it before any exploitation in the wild occurs. Perhaps he thought that a simple denial of service was not "that" critical ...

Aujourd'hui, une vulnérabilité (Réf. Lexsi 12225) annoncée comme un déni de service distant touchant les versions Vista, Seven et 2008 de Windows a été publiée par un chercheur en sécurité. Celle-ci affecte le pilote pour le protocole SMBv2, nouvelle mouture du bien connu SMB. En modifiant un simple paramètre d'une requête SMB de type "négociation de protocole", un attaquant distant pourrait provoquer un BSOD.

Mais regardons les choses de plus près ...

L'exécution du code d'exploitation contre une de nos machines de test provoque l'écran bleu suivant :

Nous notons que le pilote impacté est bien srv2.sys, et que l'instruction provoquant le PAGE_FAULT est située à l'adresse 0x8E18A749. Si l'on ouvre le-dit fichier à l'aide d'un désassembleur, nous observons le code suivant :

On peut voir que la valeur modifiée dans le paquet (ici eax) est alors directement utilisée comme indice d'un tableau de fonction ! La vulnérabilité pourrait alors être exploitée afin de dériver le flot d'exécution vers un espace sous notre contrôle, permettant ainsi l'exécution de code arbitraire à distance, avec les privilèges du noyau ...

Il est malheureux que le-dit chercheur n'ait pas adopté les pratiques du responsible disclosure, en remontant la vulnérabilité à Microsoft sans l'ébruiter, afin de donner le temps à l'éditeur de la corriger avant une éventuelle exploitation dans la nature. Peut-être a-t-il jugé qu'un simple déni de service n'était pas "si" critique ...

The first half of 2009 has seen the following main virus threats: Conficker, Virut and Neeris. The latter is a worm which spreads like Conficker by exploiting the MS08-067 vulnerability. It was far from receiving the same media attention as Conficker but did succeed in infecting many companies. Different ways of spotting the first infected machine on a network, namely the infection source, are described in this post.

It is assumed that all machines are synchronized with a time server; comparing time between machines then makes sense and our problem boils down to determining the infection date of each machine. This can be determined from the modifications the worm made on the system, mainly on the filesystem, events and registry (NB: a filter like "Category is Write" in Process Monitor is a good starting point).

Filesystem

The worm begins by copying itself in C:\WINDOWS\system under a randomly chosen name, netmon.exe in this case. NTFS attributes give the file creation date and time, that is to say an infection date (NB: first, fls is used to get the index of the file in the MFT, then istat is used to retrieve the information):

$ fdisk -ul neeris_disque.raw
neeris_disque.raw1   *          63     8369864     4184901    7  HPFS/NTFS

$ fls -o 63 -r neeris_disque.raw | grep netmon
++ r/r 9433-128-3:	netmon.exe

$ istat -o 63 neeris_disque.raw 9433
$STANDARD_INFORMATION Attribute Values:
Created:	Mon Aug 31 18:02:33 2009
File Modified:	Mon Aug 31 18:02:32 2009
MFT Modified:	Tue Sep  1 06:36:38 2009
Accessed:	Mon Aug 31 18:02:33 2009

Similarly, the worm drops a rootkit in C:\WINDOWS\system32\drivers\sysdrv32.sys. The properties of this file also give us an infection date:

$ fls -o 63 -r neeris_disque.raw | grep sysdrv32.sys
+++ r/r 9437-128-3:	sysdrv32.sys

$ istat -o 63 neeris_disque.raw 9437
$STANDARD_INFORMATION Attribute Values:
Created:	Mon Aug 31 18:02:36 2009
File Modified:	Mon Aug 31 18:02:36 2009
MFT Modified:	Mon Aug 31 18:02:36 2009
Accessed:	Mon Aug 31 18:02:36 2009

This gives us another time, showing us that this action occurred a few seconds after the other one.

We have another option: prefetch files. Prefetch is a functionality of the Windows Memory Manager which aims at speeding up the boot and application load process, enabled by default and configurable via the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters registry key (refer to chapter 7 of the Windows Internals book for more details). Like every application, the worm is also impacted by this mechanism and Windows will create the appropriate files in C:\WINDOWS\Prefetch:

$ fls -o 63 -r neeris_disque.raw | grep NETMON
++ r/r 9436-128-4:	NETMON.EXE-0D87B210.pf

$ istat -o 63 neeris_disque.raw 9436      
$STANDARD_INFORMATION Attribute Values:
Created:	Mon Aug 31 18:02:34 2009
File Modified:	Mon Aug 31 18:02:44 2009
MFT Modified:	Mon Aug 31 18:02:44 2009
Accessed:	Mon Aug 31 18:02:34 2009

The filesystem timeline (the capture below was taken with PTK) shows that at the time determined above, temporary Internet files have been written under the NetworkService account. This is a sign of a successful exploitation of a vulnerability in a Windows network service:

All directories and files in the capture above, if their names are not system dependent, can be used to determine the infection date.

Events

The rootkit is loaded via the Windows Service Control Manager and this will generate a 7035 event in the System event log, providing us with an infection date:

Searching for this event is trivial as the rootkit always installed itself as Play Port I/O Driver. The only issue we may face would be the overwrite of these events. However, the time given by this method is relatively late (10s after the main executable was dropped).

Registry

Several modifications are made in the registry:

1. new value in the HKLM\SOFTWARE\CurrentVersion\Run key under a randomly chosen name (netmon here), pointing to a copy of the worm in C:\WINDOWS\system
2. new firewall exception (new value in the HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List key)
3. kernel rootkit (new HKLM\SYSTEM\CurrentControlSet\Services\sysdrv32 key)
4. the worm runs even in safe mode with or without network support (new HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\{Minimal,Network}\netmon keys)

In the registry, dates and times are stored, but they correspond to keys and not values. Indeed, the LastWriteTime is stored in a _CM_KEY_CONTROL_BLOCK structure:

lkd> dt nt!_CM_KEY_CONTROL_BLOCK
  +0x038 KcbLastWriteTime : _LARGE_INTEGER

We are looking for a registry key specifically created by the worm which we will be able to extract the LastWriteTime (last modification time) from, and not a new value in an existing key. The second and third points above meet this requirement. The date and time can be extracted manually with regedit by exporting the key in text format:

The procedure can be automatized via the RegQueryInfoKey function which returns the information in its lpftLastWriteTime field.

Another method would be to analyze the RAM. The task has recently become easy thanks to the possibility of using RegRipper plugins against memory dumps via Volatility. First, let's list the hives available in our RAM dump via the hivelist plugin:

$ ./volatility hivelist -f neeris_ram.raw
Address      Name
0xe17ff008   \Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe17f7b60   \Documents and Settings\<user>\NTUSER.DAT
0xe13112b0   \WINDOWS\system32\config\software
0xe1311b60   \WINDOWS\system32\config\default
0xe1309008   \WINDOWS\system32\config\SECURITY
0xe1309758   \WINDOWS\system32\config\SAM
0xe101b008   \WINDOWS\system32\config\system

Now, our plugin can be executed against these hives and will return the information, for example from the SYSTEM hive:

$ perl rip.pl -p neeris_lexsi -r neeris_ram.raw@0xe101b008

ControlSet001\Services\sysdrv32
[Mon Aug 31 16:02:41 2009]

ControlSet001\Control\Safeboot\Minimal\netmon
[Mon Aug 31 16:02:33 2009]

ControlSet001\Control\Safeboot\Network\netmon
[Mon Aug 31 16:02:33 2009]

ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
[Tue Sep  1 04:36:38 2009]

In these examples, the given time doesn't take into account the time zone (this is a memory dump from a French system at UTC+2). The time of the sysdrv32 key matches the one extracted from the event log. However, the AuthorizedApplications\List key has been modified afterwards and doesn't give a correct time.

This RegRipper plugin is available for download (please note that the plugin is not exhaustive and is only a proof of concept).

If these keys were removed by the antivirus, it is still possible to apply the LastWriteTime method on a key where the worm only added a value, such as HKLM\SOFTWARE\CurrentVersion\Run or HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List, rather than on a key it created. This will surely returns a result, but it may not be correct due to legitimate modifications of these keys by other programs, which also affect the date and time (see the example above about the RAM dump). Anyway, if these dates match, chances are that this is the right infection date.

Processes

By analyzing the RAM, it is also possible to determine the time when the netmon.exe process was launched via the psscan2 Volatility plugin (NB: pslist will not work here due to the rootkit which hides this process):

$ ./volatility psscan2 -f neeris_ram.raw
PID    PPID   Time created             Time exited              Offset     PDB        Remarks
  1352    556 Mon Aug 31 11:07:23 2009                          0x00f79228 0x00f66000 spoolsv.exe     
   916    556 Mon Aug 31 11:06:55 2009                          0x0102f6b0 0x06a00000 svchost.exe     
   852    556 Mon Aug 31 11:06:53 2009                          0x0103b020 0x0643a000 svchost.exe     
   772    556 Mon Aug 31 11:06:48 2009                          0x0104da90 0x05c50000 svchost.exe     
   568    484 Mon Aug 31 11:06:41 2009                          0x0106b938 0x057d7000 lsass.exe       
   556    484 Mon Aug 31 11:06:41 2009                          0x0106d090 0x057cb000 services.exe    
  1664   1608 Mon Aug 31 16:02:34 2009                          0x0107d670 0x06f26000 netmon.exe      
   356      4 Mon Aug 31 11:06:34 2009                          0x0108c4d0 0x047dc000 smss.exe        
   460    356 Mon Aug 31 11:06:37 2009                          0x010b5488 0x052ae000 csrss.exe       
   484    356 Mon Aug 31 11:06:38 2009                          0x011b7020 0x05473000 winlogon.exe    
     4      0                                                   0x011f29c8 0x00039000 System          
  1964    556 Mon Aug 31 11:08:13 2009                          0x0604cb00 0x001c4000 alg.exe         
  1924    556 Mon Aug 31 11:08:09 2009                          0x060c8020 0x024a0000 svchost.exe     
  1036    556 Mon Aug 31 11:07:06 2009                          0x078e9508 0x0791e000 svchost.exe     
  1208   1140 Mon Aug 31 11:07:16 2009                          0x07d29020 0x07de8000 explorer.exe    
  1204   1208 Mon Aug 31 11:19:46 2009                          0x07d92820 0x0554a000 cmd.exe

Modulo the 2-hour time difference, this gives us the same date and time as determined above.

Network connections

Finally, sockets also have a creation date. By listing the sockets associated with our process (PID 1664), we are given the connections corresponding to the exploitation of the MS08-067 vulnerability on remote hosts; the first of these dates is the first exploitation attempt, and the date matches (modulo 2 hours again):

$ ./volatility sockets -f neeris_ram.raw | grep 1664 
Pid    Port   Proto  Create Time
1664   4637   6      Tue Sep 01 04:39:01 2009  
1664   4641   6      Tue Sep 01 04:39:02 2009  
1664   4645   6      Tue Sep 01 04:39:02 2009  
1664   1664   6      Tue Sep 01 01:10:06 2009  
1664   2866   6      Mon Aug 31 22:01:10 2009  
1664   4634   6      Tue Sep 01 04:39:00 2009  
1664   4638   6      Tue Sep 01 04:39:02 2009  
1664   3502   6      Tue Sep 01 01:52:38 2009  
1664   4642   6      Tue Sep 01 04:39:02 2009  
1664   4646   6      Tue Sep 01 04:39:02 2009  
1664   3762   6      Tue Sep 01 01:53:03 2009  
1664   14575  6      Mon Aug 31 16:02:36 2009  
1664   3495   6      Tue Sep 01 01:52:37 2009  
1664   1669   6      Tue Sep 01 01:10:07 2009  
1664   4635   6      Tue Sep 01 04:39:00 2009  
1664   4639   6      Tue Sep 01 04:39:02 2009

Conclusion

Different ways of determining the date when a system has been infected by Neeris have been described, through disk and RAM analysis. These methods have their own advantages and drawbacks, but their efficiency can be decreased by the actions performed by the antivirus which may remove pieces of evidence when removing the worm. Analyzing the RAM can be useful, provided the first responder doesn't arrive too late...

La première moitié de l'année 2009 a été marquée par 3 familles de malware : Conficker, Virut et Neeris. Ce dernier est un ver se propageant comme Conficker via la vulnérabilité MS08-067. Il est loin d'avoir eu la visibilité médiatique de Conficker, mais il a bel et bien infecté de nombreuses entreprises, y compris françaises. Nous allons décrire dans ce billet différentes méthodes pour tenter de repérer le premier système infecté dans un parc de machines, autrement dit la source de l'infection.

On part du principe que les machines sont synchronisées avec un serveur de temps ; la comparaison du temps entre elles a donc du sens et le problème revient ainsi à déterminer la date d'infection de chaque poste. Cela s'effectue à partir des modifications opérées par le malware sur le poste, principalement sur le système de fichiers, les événements et la base de registre (NB : un filtre "Category is Write" dans Process Monitor est un bon point de départ).

Système de fichiers

Le ver commence par se recopier dans C:\WINDOWS\system sous un nom choisi parmi une liste prédéfinie, netmon.exe dans notre cas. Les attributs NTFS fournissent l'heure de création du fichier et donc une heure d'infection (NB : on utilise d'abord fls pour connaitre l'index dans la MFT associé à ce fichier, puis istat pour obtenir l'information voulue) :

$ fdisk -ul neeris_disque.raw
neeris_disque.raw1   *          63     8369864     4184901    7  HPFS/NTFS

$ fls -o 63 -r neeris_disque.raw | grep netmon
++ r/r 9433-128-3:	netmon.exe

$ istat -o 63 neeris_disque.raw 9433
$STANDARD_INFORMATION Attribute Values:
Created:	Mon Aug 31 18:02:33 2009
File Modified:	Mon Aug 31 18:02:32 2009
MFT Modified:	Tue Sep  1 06:36:38 2009
Accessed:	Mon Aug 31 18:02:33 2009

De même, le ver droppe une rootkit dans C:\WINDOWS\system32\drivers\sysdrv32.sys. Les propriétés de ce fichier nous donnent aussi une heure d'infection :

$ fls -o 63 -r neeris_disque.raw | grep sysdrv32.sys
+++ r/r 9437-128-3:	sysdrv32.sys

$ istat -o 63 neeris_disque.raw 9437
$STANDARD_INFORMATION Attribute Values:
Created:	Mon Aug 31 18:02:36 2009
File Modified:	Mon Aug 31 18:02:36 2009
MFT Modified:	Mon Aug 31 18:02:36 2009
Accessed:	Mon Aug 31 18:02:36 2009

On remarque que l'heure fournie n'est pas identique à la précédente, montrant que cette action a eu lieu peu de temps après.

Une autre option s'offre à nous : les fichiers de prefetch. Le prefetch est une fonctionnalité du Memory Manager de Windows destinée à optimiser le chargement du système et des applications, activée par défaut et configurable via la clé HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters (cf chapitre 7 du livre Windows Internals pour les détails). Comme toute application qui se respecte, le malware est affecté par ce mécanisme et Windows va donc créer des fichiers correspondant dans C:\WINDOWS\Prefetch :

$ fls -o 63 -r neeris_disque.raw | grep NETMON
++ r/r 9436-128-4:	NETMON.EXE-0D87B210.pf

$ istat -o 63 neeris_disque.raw 9436      
$STANDARD_INFORMATION Attribute Values:
Created:	Mon Aug 31 18:02:34 2009
File Modified:	Mon Aug 31 18:02:44 2009
MFT Modified:	Mon Aug 31 18:02:44 2009
Accessed:	Mon Aug 31 18:02:34 2009

En générant la timeline du disque dur (la capture ci-dessous provient de PTK), on observe qu'à l'heure déterminée ci-dessus, des fichiers Internet temporaires sont écrits sous le compte NetworkService. Ceci est typique de l'exploitation réussie d'une vulnérabilité dans un service réseau Windows :

Tous les fichiers et répertoires ci-dessus, pour peu qu'ils aient un nom ne dépendant pas du système, peuvent donc potentiellement servir à déterminer la date d'infection.

Événements

La rootkit est chargée via le Service Control Manager de Windows et cela génère un événement 7035 dans le journal Système, nous fournissant une date d'infection :

La recherche est rendue triviale par le fait que cette rootkit utilise le nom constant Play Port I/O Driver. Le seul problème qui pourrait se poser pour cette méthode serait un écrasement des événements. Cependant, on remarque que l'heure donnée est relativement tardive (10s après le drop de l'exécutable principal).

Base de registre

Plusieurs modifications ont lieu dans la base de registre :

1. ajout d'une valeur dans la clé HKLM\SOFTWARE\CurrentVersion\Run sous un nom choisi parmi une liste prédéfinie (ici netmon), pointant vers la copie du ver présente dans C:\WINDOWS\system
2. ajout d'une exception au pare-feu (nouvelle valeur dans la clé HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List)
3. rootkit noyau (nouvelle clé HKLM\SYSTEM\CurrentControlSet\Services\sysdrv32)
4. lancement du malware même en mode sans échec avec ou sans support réseau (nouvelles clés HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\{Minimal,Network}\netmon)

Dans la base de registre Windows, des dates et heures sont bien enregistrées, mais elles concernent les clés et non les valeurs. Le champ LastWriteTime est en effet stocké dans une structure _CM_KEY_CONTROL_BLOCK :

lkd> dt nt!_CM_KEY_CONTROL_BLOCK
  +0x038 KcbLastWriteTime : _LARGE_INTEGER

Idéalement, on cherche donc une clé créée spécifiquement par le malware dont on va pouvoir extraire le champ LastWriteTime contenant l'heure de dernière modification, et non une nouvelle valeur dans une clé existante. Les deuxième et troisième points ci-dessus correspondent précisément à notre attente. On peut alors extraire manuellement ces date et heure depuis regedit en exportant la clé de registre au format texte :

La procédure peut s'automatiser via la fonction RegQueryInfoKey qui nous retourne l'information voulue dans son paramètre lpftLastWriteTime.

Une autre méthode envisageable consiste à analyser la RAM. La tâche est rendue facile par la récente possibilité de lancer les plugins RegRipper sur une image de la RAM via Volatility. Concrètement, on commence par utiliser le plugin hivelist afin de lister les ruches présentes dans le dump de RAM :

$ ./volatility hivelist -f neeris_ram.raw
Address      Name
0xe17ff008   \Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe17f7b60   \Documents and Settings\<user>\NTUSER.DAT
0xe13112b0   \WINDOWS\system32\config\software
0xe1311b60   \WINDOWS\system32\config\default
0xe1309008   \WINDOWS\system32\config\SECURITY
0xe1309758   \WINDOWS\system32\config\SAM
0xe101b008   \WINDOWS\system32\config\system

On peut ensuite lancer notre plugin sur les ruches ainsi trouvées en mémoire, et obtenir l'information voulue, par exemple depuis les clés de la ruche SYSTEM :

$ perl rip.pl -p neeris_lexsi -r neeris_ram.raw@0xe101b008

ControlSet001\Services\sysdrv32
[Mon Aug 31 16:02:41 2009]

ControlSet001\Control\Safeboot\Minimal\netmon
[Mon Aug 31 16:02:33 2009]

ControlSet001\Control\Safeboot\Network\netmon
[Mon Aug 31 16:02:33 2009]

ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
[Tue Sep  1 04:36:38 2009]

Ici, l'heure donnée ne tient pas compte du décalage horaire et on retrouve bien le 18:02 du 31/08/2009 (il s'agit d'un système à l'heure de Paris). L'heure de la clé sysdrv32 correspond à celle trouvée via l'event log. En revanche, la clé AuthorizedApplications\List a été modifiée après coup (cette clé est modifiée et non créée par le malware) et ne donne donc pas une heure correcte.

Ce plugin RegRipper est disponible en téléchargement (à noter qu'il n'est pas exhaustif au niveau des clés testées, il ne s'agit que d'une preuve de concept).

Si ces clés ont été supprimées par l'antivirus, il reste toujours possible d'appliquer la méthode du LastWriteTime non pas sur une clé créée par le malware, mais sur une clé dans laquelle il a ajouté une valeur, comme par exemple HKLM\SOFTWARE\CurrentVersion\Run ou HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List. On est sûr d'obtenir un résultat, mais pas forcément celui attendu car un logiciel légitime a pu aussi ajouter des valeurs dans ces clés et ainsi modifier leur date (voir l'exemple ci-dessus sur la RAM). Cela dit, si les deux dates coïncident, il y a de fortes chances qu'il s'agisse bien de la date réelle d'infection.

Processus

Toujours par analyse de la RAM, il est aussi possible de déterminer l'heure du lancement du processus netmon.exe via le plugin psscan2 de Volatility (NB : un simple pslist ne va pas marcher en raison de la rootkit qui cache ce processus) :

$ ./volatility psscan2 -f neeris_ram.raw
PID    PPID   Time created             Time exited              Offset     PDB        Remarks
  1352    556 Mon Aug 31 11:07:23 2009                          0x00f79228 0x00f66000 spoolsv.exe     
   916    556 Mon Aug 31 11:06:55 2009                          0x0102f6b0 0x06a00000 svchost.exe     
   852    556 Mon Aug 31 11:06:53 2009                          0x0103b020 0x0643a000 svchost.exe     
   772    556 Mon Aug 31 11:06:48 2009                          0x0104da90 0x05c50000 svchost.exe     
   568    484 Mon Aug 31 11:06:41 2009                          0x0106b938 0x057d7000 lsass.exe       
   556    484 Mon Aug 31 11:06:41 2009                          0x0106d090 0x057cb000 services.exe    
  1664   1608 Mon Aug 31 16:02:34 2009                          0x0107d670 0x06f26000 netmon.exe      
   356      4 Mon Aug 31 11:06:34 2009                          0x0108c4d0 0x047dc000 smss.exe        
   460    356 Mon Aug 31 11:06:37 2009                          0x010b5488 0x052ae000 csrss.exe       
   484    356 Mon Aug 31 11:06:38 2009                          0x011b7020 0x05473000 winlogon.exe    
     4      0                                                   0x011f29c8 0x00039000 System          
  1964    556 Mon Aug 31 11:08:13 2009                          0x0604cb00 0x001c4000 alg.exe         
  1924    556 Mon Aug 31 11:08:09 2009                          0x060c8020 0x024a0000 svchost.exe     
  1036    556 Mon Aug 31 11:07:06 2009                          0x078e9508 0x0791e000 svchost.exe     
  1208   1140 Mon Aug 31 11:07:16 2009                          0x07d29020 0x07de8000 explorer.exe    
  1204   1208 Mon Aug 31 11:19:46 2009                          0x07d92820 0x0554a000 cmd.exe

Modulo les 2 heures de décalage horaire, on retrouve bien l'heure et la date déjà déterminées ci-dessus.

Connexions réseau

Pour finir, les sockets possèdent également une date de création. En listant celles associées à notre processus (ici celui de PID 1664), on obtient les connexions correspondant aux tentatives d'exploitation de la vulnérabilité MS08-067 sur des systèmes distants ; la première de ces dates nous donne donc la première tentative, et la date correspond bien si on prend en compte le décalage horaire :

$ ./volatility sockets -f neeris_ram.raw | grep 1664 
Pid    Port   Proto  Create Time
1664   4637   6      Tue Sep 01 04:39:01 2009  
1664   4641   6      Tue Sep 01 04:39:02 2009  
1664   4645   6      Tue Sep 01 04:39:02 2009  
1664   1664   6      Tue Sep 01 01:10:06 2009  
1664   2866   6      Mon Aug 31 22:01:10 2009  
1664   4634   6      Tue Sep 01 04:39:00 2009  
1664   4638   6      Tue Sep 01 04:39:02 2009  
1664   3502   6      Tue Sep 01 01:52:38 2009  
1664   4642   6      Tue Sep 01 04:39:02 2009  
1664   4646   6      Tue Sep 01 04:39:02 2009  
1664   3762   6      Tue Sep 01 01:53:03 2009  
1664   14575  6      Mon Aug 31 16:02:36 2009  
1664   3495   6      Tue Sep 01 01:52:37 2009  
1664   1669   6      Tue Sep 01 01:10:07 2009  
1664   4635   6      Tue Sep 01 04:39:00 2009  
1664   4639   6      Tue Sep 01 04:39:02 2009

Conclusion

Nous venons de décrire différentes manières d'obtenir la date d'infection d'un système par le ver Neeris, par analyse du disque dur et de la mémoire vive. Ces méthodes ont chacune leurs avantages et inconvénients mais leur efficacité peut surtout être mise à mal par l'antivirus qui, lors de la suppression du malware, pourrait également supprimer les "preuves" de son ancienne présence. L'analyse de la RAM peut alors s'avérer précieuse, à condition de ne pas arriver trop tard...