Comment le malware détecte-t-il et contourne-t-il les sandbox d'analyse, et comment y faire face ?
Réponse courte
Un malware conscient du sandbox vérifie s'il est observé avant de mal se comporter. Il cherche des artefacts de VM et d'hyperviseur (pilotes, préfixes MAC, clés de registre, CPUID), des outils d'analyse et débogueurs (noms de processus, IsDebuggerPresent, temporisation du pas-à-pas), et des signes d'un vrai utilisateur (peu de processus, aucun document récent, pas de mouvement de souris, faible uptime, petit disque). Il peut temporiser avec de longs sommeils ou ne se déclencher qu'à une date, une langue ou un domaine précis. Les analystes y font face en durcissant la VM pour la rendre réaliste, en neutralisant les vérifications par patch, en accélérant les sommeils, en simulant l'activité utilisateur, et en confirmant le comportement par désassemblage statique.
L'analyse dynamique n'est utile que si le malware exécute réellement son code malveillant pendant que vous l'observez. Les recruteurs posent cette question parce que les échantillons modernes partent du principe qu'ils seront détonés dans un sandbox et cachent leur comportement quand ils en détectent un. Comprendre ce jeu du chat et de la souris est au cœur du métier.
Ce que vérifie le malware
- Artefacts d'environnement. Empreintes de VM et d'hyperviseur : pilotes et clés de registre VMware/VirtualBox, préfixes d'adresse MAC connus, le bit hyperviseur du
CPUID, chaînes de BIOS, et petit disque ou faible RAM. Présence d'outils d'analyse (Procmon, Wireshark, x64dbg) par nom de processus ou de fenêtre. - Détection de débogueur.
IsDebuggerPresent,CheckRemoteDebuggerPresent, drapeaux du PEB, vérifications de temporisation qui remarquent le ralentissement du pas-à-pas, et astuces basées sur les exceptions. - Signaux de vrai utilisateur. Les sandbox semblent stériles : peu de processus en cours, aucun document récent, noms d'utilisateur par défaut, pas de mouvement de souris, faible uptime, et un historique de navigateur vierge. Un malware qui voit une machine immaculée suppose qu'il est analysé.
- Bombes logiques et temporisation. Longs appels
Sleepou boucles d'attente pour survivre à la fenêtre d'analyse du sandbox ; déclencheurs conditionnés à une date, une langue système, une disposition de clavier ou un domaine précis pour ne se déclencher que sur la cible visée.
Comment les analystes y font face
Vous faites en sorte que la VM paraisse habitée : installez des logiciels courants, peuplez documents et historique, simulez l'activité souris et clavier, fixez un uptime réaliste, et retirez les artefacts d'outils évidents. Dans un débogueur, vous neutralisez par patch les vérifications anti-débogage ou vous interceptez l'API pour qu'elle mente, et vous accélérez les sommeils en interceptant Sleep/NtDelayExecution. Surtout, vous vous repliez sur le désassemblage statique pour lire la logique d'évasion et les conditions de cible qui ne se déclenchent jamais dynamiquement.
Une réponse solide la présente comme une course aux armements et insiste sur le fait que les analyses statique et dynamique couvrent mutuellement leurs angles morts.
Questions de suivi probables
- Comment feriez-vous pour qu'une VM d'analyse ressemble au poste de travail d'un vrai utilisateur ?
- Qu'est-ce que le ralentissement par sommeil et comment le déjouez-vous ?
- Comment l'analyse statique peut-elle révéler une logique d'évasion qui ne se déclenche jamais dynamiquement ?