Un fichier suspect est exécuté dans un environnement sandbox et ne fait presque rien. Traditionnellement, cette absence d’activité pouvait laisser penser que le fichier présentait peu de risques.
Mais la question la plus importante est de savoir pourquoi il est resté silencieux. Le fichier n’a-t-il pas réussi à s’exécuter, ou a-t-il reconnu l’environnement sandbox et décidé de ne pas révéler ce dont il était capable ?
Les malwares modernes sont de plus en plus sélectifs quant au moment où ils s’exécutent. Ils peuvent rechercher des artefacts de virtualisation, mesurer la temporisation du système, détecter l’activité de l’utilisateur et vérifier si l’hôte ressemble à un véritable terminal.
Certaines souches utilisent même la trigonométrie pour déterminer si les mouvements de la souris semblent humains ou automatisés. Si quelque chose paraît artificiel, le malware peut rester dormant, retarder son exécution ou dissimuler sa fonction principale.
La virtualisation et l’évasion des environnements sandbox, associées à la technique T1497 d’ATT&CK, figurent désormais parmi les techniques d’évasion les plus répandues observées dans l’activité malveillante actuelle. Un échantillon qui reste silencieux pendant l’analyse peut se comporter très différemment une fois arrivé sur un véritable terminal.
Pourquoi les malwares silencieux restent dangereux
Les équipes de sécurité considèrent depuis longtemps le comportement observable comme une source de vérité. Toute exécution qui génère du trafic réseau, accède à des identifiants, modifie la persistance ou injecte du code en mémoire donne aux analystes matière à investigation.
Cependant, lorsqu’il y a peu ou pas d’activité visible, on a tendance à considérer l’échantillon comme moins risqué ou moins intéressant. Cette réaction est désormais dangereuse. Dans bien des cas, l’inactivité fait partie du mode opératoire.
Les vérifications de l’activité de l’utilisateur constituent un moyen pour les malwares de vérifier si l’environnement est réel. Dans les environnements automatisés, il peut toutefois être difficile de reproduire les petites incohérences du comportement humain.
Les véritables terminaux peuvent présenter un historique de navigation, des fichiers récents, des mouvements de souris irréguliers et des pauses de durées variables ; ils sont aussi remplis du bruit propre à une activité professionnelle normale.
Les environnements sandbox font généralement défaut sur ces points. Les auteurs de malwares le savent, et nombre de souches attendront des signes d’interaction humaine directe avant de poursuivre, ce qui fait de l’absence de comportement un indicateur possible d’évasion, plutôt qu’un signe de sécurité.
Prenons le malware LummaC2 comme exemple. Au lieu de simplement vérifier si la souris bouge, il examine la façon dont elle bouge. Il échantillonne les positions du curseur, mesure les distances euclidiennes et les angles qui les séparent, et distingue les mouvements humains réels des lignes droites et régulières générées par les scripts. Les mouvements réels de la souris comportent de petites courbes, des hésitations et de légers changements de direction que les scripts n’ont pas. Si les calculs indiquent que le mouvement est factice, le malware reste inactif.
Comment les malwares échappent à la détection des environnements sandbox
Les malwares utilisent également des vérifications temporelles pour éviter les environnements sandbox.
Certaines familles font davantage que simplement attendre. Blitz, par exemple, exécute deux threads en parallèle et compare leurs performances. Un thread exécute des instructions CPUID, tandis que l’autre effectue des calculs en virgule flottante. Sur du matériel physique, le résultat est généralement supérieur à une certaine valeur, ce qui indique que le système est réel. Dans une machine virtuelle, la surcharge supplémentaire peut faire baisser le résultat et révéler l’environnement sandbox.
Les vérifications de l’activité de l’utilisateur fonctionnent différemment. Certaines souches les utilisent pour déterminer si un humain est présent, notamment en attendant une interaction réaliste ou, dans le cas de LummaC2, en utilisant la trigonométrie pour déterminer si les mouvements de la souris semblent humains ou synthétiques. Lorsqu’un fichier suspect reste silencieux après ces vérifications, il peut s’agir d’une évasion délibérée plutôt que d’un manque de capacités.
Les attaquants consacrent désormais davantage d’efforts à se dissimuler, à rester plus longtemps en place et à éviter la détection.
Les défenseurs doivent donc reconsidérer ce que signifie le silence apparent d’un fichier. Un fichier qui s’exécute sans problème peut malgré tout laisser des indices importants. A-t-il vérifié son environnement avant de s’arrêter ? A-t-il recherché des signes indiquant qu’il était analysé ? A-t-il attendu de détecter de véritables mouvements de souris ? A-t-il mesuré depuis combien de temps il fonctionnait, ou tenté de tenir jusqu’à la fin du test ? Ces actions peuvent en dire plus qu’une attaque manifeste.
Ce que les défenseurs doivent faire différemment
Les équipes de sécurité doivent cesser de supposer qu’un résultat silencieux signifie que tout est sûr. Si un fichier suspect s’exécute, vérifie depuis combien de temps il fonctionne ou recherche une activité de l’utilisateur, puis ne fait rien, il mérite un examen plus approfondi.
Les équipes doivent tester leurs défenses contre les malwares qui tentent d’éviter la détection, plutôt que de croire que tout va bien simplement parce que l’environnement sandbox n’a rien détecté. Elles doivent également surveiller les problèmes silencieux, comme les appareils qui cessent d’envoyer des journaux ou les systèmes sur lesquels les outils de sécurité ont été désactivés ou modifiés.
Les environnements d’analyse doivent eux aussi être plus difficiles à tromper. Les environnements d’exécution assistés par le matériel ou bare metal sont plus difficiles à identifier pour les malwares. Les contre-mesures fondées sur le temps peuvent aider en accélérant le temps de manière crédible et en forçant les malwares qui tentent d’attendre la fin des fenêtres d’observation à se révéler plus tôt.
Lorsqu’un fichier reste silencieux, les défenseurs doivent aller au-delà de l’examen du fichier lui-même. Ils doivent utiliser des simulations de compromission et d’attaque pour vérifier si leurs systèmes peuvent toujours détecter les malwares qui retardent leurs actions, examinent leur environnement ou attendent que les conditions semblent réelles avant d’agir.
Les environnements sandbox permettaient autrefois de déterminer facilement si un fichier était dangereux. Cette méthode est désormais moins fiable, car certains malwares resteront silencieux s’ils pensent être surveillés. Ce qui semble inactif pendant les tests peut en réalité examiner son environnement et attendre de se retrouver sur un système réel.
Les équipes doivent reconsidérer ce que signifie le silence. Un fichier qui ne fait rien n’est pas toujours inoffensif : cela peut simplement signifier que le malware savait qu’il était testé.