Anti-analyse

Le malware interroge le nombre de cœurs CPU, la taille de la RAM et la capacité du disque ; les ressources anormalement faibles typiques des sandboxes automatisées trahissent l'environnement d'analyse et suppriment le déclenchement.

Le malware lance un enfant qui débogue le parent (ou inversement) afin que la règle d'un seul débogueur par processus verrouille complètement le débogueur de l'analyste hors du processus protégé.

Le malware ferme un handle délibérément invalide ; sous un débogueur, le noyau lève STATUS_INVALID_HANDLE, et capturer cette exception révèle un débogueur attaché.

Le malware lit QueryPerformanceCounter deux fois autour d'une région de code et compare les ticks écoulés à un seuil ; le pas-à-pas ou les points d'arrêt gonflent le delta et révèlent un débogueur.

Le malware dialogue avec l'hyperviseur VMware via le port d'E/S de la backdoor « VX » au moyen d'une valeur magique dans EAX, révélant qu'il s'exécute dans un invité VMware et non sur du matériel réel.

Le malware scanne ou calcule un checksum de sa propre section de code à la recherche des octets 0xCC (INT3) laissés par les points d'arrêt logiciels d'un débogueur, détectant l'analyse sans aucun appel d'API.

Le malware énumère les fenêtres de premier niveau à la recherche des noms de classe d'outils d'analyse connus comme OllyDbg, x64dbg, WinDbg et Process Monitor pour détecter un environnement d'analyse.

Le malware appelle NtSetInformationThread avec la classe ThreadHideFromDebugger pour détacher un thread du débogueur, empêchant les points d'arrêt et exceptions d'atteindre l'analyste.

Un appel d'API Windows qui lit le drapeau BeingDebugged dans le PEB pour détecter un débogueur en mode utilisateur attaché au processus courant.