Techniques de détection de sandboxes et machines virtuelles

PUBLISHED ON OCT 6, 2016 — SECURITY

Lors de l’analyse d’un malware, j’ai découvert qu’il utilisait diverses techniques afin de cacher son payload lorsqu’il tourne dans une sandbox ou dans une machine virtuelle. Dans la suite de ce billet, je détaillerai quelques unes de ces techniques.

Évidemment, je parlerai ici de Windows car la plupart des malwares sont développés pour ce système d’exploitation.

ProductID

Lorsque vous installez Windows, une “clé produit” unique est associée à votre machine. Celle-ci est stockée dans une sous-clé de registre nommée ProductId et dont le chemin d’accès est : HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion. Cet identifiant est différent pour chaque installation de Windows.

Un problème se pose lorsque qu’une sandbox est distribuée avec une version de Windows pré-installée.

Prenons l’exemple de la sandbox Joe Box. Pendant longtemps (et encore maintenant ?), il suffisait, pour un malware, de vérifier que la clé produit de la machine était égale à 55274–640–2673064–23950.

De la même manière, les sandboxes Anubis et CW Sandbox pouvaient être détectées via les clés : 76487–337–8429955–22614 et 76487–644–3177037–23510.

Pour être tout à fait honnête, cette technique est de moins en moins répandu pour plusieurs raisons dont la plus évidente est que les sandboxes peuvent sans problème changer de ProductID. Par exemple, la plus connue, Cuckoo, génère une clé produit à chaque lancement ce qui empêche toute détection.

DLLs

Ici, il ne s’agit plus de détecter une clé unique mais une DLL spécifique accessible par un programme. Lorsque qu’un programme tourne dans une sandbox qui propose une DLL supplémentaire, il n’est pas compliqué de la détecter.

void detect_sandboxie(void){
    if(GetModuleHandle("SbieDll.dll") != NULL){
        printf("Sandbox detected!\n");
    }
}

Dans cet exemple, le programme demande la DLL SbieDll.dll via la fonction de Windows GetModuleHandle. Si l’on exécute cette fonction dans Sandboxie, le message “Sandbox detected!” s’affiche.

Logiciels et configurations spécifiques

VirtualBox, vous connaissez ? Le “plugin” Guest Additions est très pratique mais a besoin du logiciel VBoxService.exe. Si ce logiciel est présent dans votre gestionnaire des tâches, vous êtes dans une machine virtuelle. Pour observer le comportement d’un malware dans VirtualBox, il est conseillé de ne pas utiliser Guest Additions.

Pour finir, nous allons parler du merveilleux Cuckoo Sandbox. On peut, sous certaines conditions détecter la présence de l’agent.py. Si vous avez déjà utilisé Cuckoo, vous savez que vous devez lancer agent.py pour qu’il ouvre un petit serveur sur votre machine “cible” … Vous me voyez venir ? Et oui ! Un malware peut tenter de se connecter à l’adresse 127.0.0.1:8000.

Pour lutter contre cela, il suffirait de modifier l’agent pour définir un port exotique et le tour serait joué mais cela ne semble pas possible actuellement …

Cuckoo Sandbox detected
Mon programme a détecté la VM de Malwr.com

La détection, une défense en carton ?

Je vous encourage à essayer ces techniques mais peut-on vraiment les utiliser dans des malwares ? La réponse est … tout dépend. En réalité, bien que ce soit fun de voir son programme changer de comportement en fonction de la sandbox ou de la machine virtuelle dans laquelle il tourne, ce n’est pas très utile pour lutter contre l’analyse. Ces techniques sont connues, communes et visibles et forment souvent des signatures reconnaissables.

En effet, pourquoi un logiciel légitime ne voudrait pas être exécuté dans une sandbox ? C’est louche donc potentiellement malveillant. Une clé produit se retrouve facilement dans les strings du programme, le VBoxService.exe également … Bien sûr, l’obfuscation peut permettre de cacher temporairement ces données mais le malware finit toujours par être exécuté dans un environnement contrôlé où il sera simple de voir qu’un appel de la DLL SbieDll.dll a été effectué.

Bref, détection ne veut pas dire discrétion, bien au contraire !

Au final, les techniques classiques de lutte contre le reverse engineering comme l’obfuscation (dont packing et chiffrement), l’anti-débogage et l’anti-désassemblage restent les plus efficaces.