Skip to content

Votre échantillon ne fait rien dans le sandbox, mais le SOC l'a observé actif sur un vrai hôte. Quelle est la raison probable et votre réponse ?

Réponse courte

Les malwares vérifient couramment les artefacts de VM/sandbox, les durées d'exécution courtes ou l'interaction utilisateur et restent dormants s'ils les détectent. Déguisez et durcissez la VM d'analyse, prolongez l'exécution ou passez sur bare metal, et extrayez le comportement depuis une image mémoire de l'hôte vivant. Supposer qu'il est cassé ou que l'hôte se trompe ignore un échantillon prouvé malveillant en conditions réelles. Un redémarrage ne change rien car la logique d'évasion se déclenche à chaque exécution.

Quand un échantillon est inerte dans votre sandbox mais manifestement actif sur un hôte de production, l'examinateur vérifie si vous faites davantage confiance à vos outils qu'aux preuves — ou l'inverse. La télémétrie de l'hôte est la vérité terrain ; c'est le sandbox qui a échoué.

Pourquoi l'anti-analyse est la réponse probable

Les malwares modernes identifient systématiquement leur environnement avant d'agir. Ils cherchent des artefacts de VM et de sandbox (pilotes spécifiques, plages MAC, clés de registre, faible nombre de cœurs/RAM), vérifient la présence d'un analyste (fichiers récents, mouvement de souris, uptime) et usent d'astuces temporelles (longs sleeps qui dépassent la fenêtre de capture courte d'un sandbox). S'ils sentent l'analyse, ils ne font rien — exactement ce que vous avez observé. La réponse : déjouer ces contrôles. Durcir et déguiser la VM pour qu'elle ressemble à un vrai poste, prolonger la durée d'exécution au-delà des sleeps, simuler l'interaction utilisateur et, au besoin, analyser sur bare metal. Surtout, comme le SOC a déjà une infection vivante, vous pouvez extraire une image mémoire du vrai hôte et récupérer directement le comportement du malware — souvent la voie la plus rapide.

Pourquoi les autres options sont fausses

  • L'échantillon est simplement cassé. Il a tourné sur un vrai hôte ; un code « cassé » ne fonctionne pas sélectivement en production. Cette explication ignore la seule preuve solide dont vous disposez.
  • Le rapport de l'hôte était erroné. Écarter la télémétrie du SOC pour protéger votre résultat de sandbox, c'est à l'envers. La détection sur une vraie machine fait davantage autorité que le silence de votre labo.
  • Redémarrer le sandbox en espérant. La logique d'évasion s'exécute de façon identique à chaque démarrage. Redémarrer ne change rien et perd du temps tandis que l'hôte vivant reste compromis.

Ce que recherchent les examinateurs

Une réponse senior nomme des contrôles d'évasion précis, explique des contre-mesures concrètes (durcissement de VM, exécution prolongée, bare metal) et — le geste marquant — bascule vers l'analyse mémoire de l'hôte déjà infecté plutôt que de lutter contre le sandbox. Le jugement sondé est l'humilité envers l'outillage : quand votre environnement et le monde réel divergent, le monde réel l'emporte, et vous y adaptez l'analyse.

Questions de suivi probables

  • Nommez trois artefacts concrets que le malware vérifie pour identifier un sandbox, et comment vous masqueriez chacun.
  • Pourquoi l'analyse mémoire de l'hôte déjà infecté est-elle souvent la voie la plus rapide quand l'échantillon refuse de détoner ?
  • Comment déclencheriez-vous un comportement conditionné à l'interaction utilisateur (sleeps, mouvement de souris, domaines précis) dans votre labo ?

Sources

Recevez 100 questions d'entretien en cybersécurité + réponses

Laissez votre e-mail et nous vous enverrons le pack PDF gratuit et le jeu de flashcards.

Pas de spam. Désabonnez-vous à tout moment.