Techniques

Au lieu d'une table d'imports normale, le programme résout les API à l'exécution via LoadLibrary et GetProcAddress sur des chaînes chiffrées, laissant l'IAT statique quasi vide et l'analyste aveugle.

Injecter du code sans WriteProcessMemory en mappant une section partagée à la fois dans le processus local et distant, en écrivant le shellcode via la vue locale, puis en l'exécutant depuis la vue distante.

Les sauts conditionnels sont remplacés par des points d'arrêt INT3 tandis qu'un processus débogueur parent détient une table associant chaque adresse à la cible et à la condition réelles du saut, corrigeant l'exécution à chaque exception de débogage.

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.

Détourner un processus GUI en modifiant une entrée de sa KernelCallbackTable dans le PEB pour pointer vers du shellcode injecté, puis déclencher l'exécution avec un message de fenêtre tel que WM_COPYDATA.

Une instruction arithmétique ou logique unique est remplacée par une séquence équivalente plus longue : la passe -sub d'OLLVM qui gonfle les expressions et casse la reconnaissance naïve de motifs.

Après le chargement, le stub met à zéro l'en-tête PE en mémoire ou corrompt SizeOfImage, si bien que les dumpers mémoire qui s'appuient sur l'en-tête échouent, forçant l'analyste à reconstruire l'en-tête avant de pouvoir analyser un dump.

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é.

Charger une DLL signée bénigne dans un processus cible et écraser sa section de code avec du shellcode, de sorte que la mémoire malveillante soit adossée à un module légitime et échappe aux scanners de mémoire non adossée.

Des séquences d'instructions sans effet et des octets de remplissage désalignés sont insérés pour gonfler le code et désynchroniser les désassembleurs en balayage linéaire, masquant le vrai flux d'instructions.

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 packer copie les premières instructions du point d'entrée d'origine dans une mémoire de stub allouée dynamiquement et redirige l'EP, si bien qu'un dump naïf manque de ces octets et que le véritable OEP reste caché jusqu'à leur récupération.

Marquer un fichier de charge utile en suppression différée avant de le mapper dans une section et de créer un processus, de sorte que l'exécutable a disparu du disque au moment où le processus s'exécute — ne laissant aucune image analysable.

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.

Des opérations simples sont remplacées par des mélanges sémantiquement équivalents d'opérateurs arithmétiques et booléens, déjouant la reconnaissance de motifs et la simplification du décompilateur tout en préservant le résultat.

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.

Les packers effacent ou redirigent la table des adresses d'import et résolvent les API via un thunk personnalisé à l'exécution, si bien qu'un dump statique n'a aucun import exploitable et doit être reconstruit avant analyse.

Abuser des transactions NTFS pour charger une charge utile dans une section, puis annuler la transaction afin que l'image malveillante ne soit jamais validée sur le disque avant la création d'un processus depuis cette section.

Les instructions natives sont traduites en un bytecode personnalisé exécuté par un interpréteur embarqué : le reverser voit une boucle fetch-decode-dispatch au lieu du code machine d'origine.

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 crypter encapsule une charge utile chiffrée et un petit stub qui, à l'exécution, déchiffre le code d'origine en mémoire et lui transfère l'exécution, si bien que l'antivirus statique ne voit que le stub et un blob à forte entropie.

La technique classique d'injection de DLL à distance : allouer le chemin d'une DLL dans un processus cible, l'y écrire, puis lancer un thread distant démarrant sur LoadLibrary pour mapper la DLL dans la victime.

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.