Hollow

hollow est un générateur de chargeurs de shellcode. Vous lui fournissez un binaire de shellcode brut et un profil, et il produit un chargeur PE Windows compilé avec votre shellcode chiffré à l'intérieur.

Pour commencer

Les binaires sont disponibles sur la page des versions, ou vous pouvez compiler depuis les sources :

go build -o hollow .

Nécessite x86_64-w64-mingw32-gcc pour la compilation croisée.

Sur Arch Linux : pacman -S mingw-w64-gcc Sur Debian/Ubuntu : apt install gcc-mingw-w64-x86-64

Utilisation

./hollow -shellcode payload.bin -profile profiles/new_process_injection_sc.json

Comment ça fonctionne ?

hollow suit un pipeline en trois étapes : chiffrer, substituer, compiler.

Votre shellcode est chiffré avec AES-256-CBC en utilisant une clé et un IV générés aléatoirement à chaque exécution. Les deux sont intégrés dans le binaire de sortie. Le modèle C choisi voit ensuite ses espaces réservés remplacés par le shellcode chiffré, la clé et l'IV, et le résultat est compilé en un PE lié statiquement et épuré par MinGW.

À l'exécution, le chargeur déchiffre le shellcode en utilisant BCrypt de Windows et l'exécute selon la technique d'injection implémentée par le modèle.

Modèles

Les modèles sont les fichiers source C qui implémentent la logique d'injection réelle. Chacun se trouve dans templates/ et contient des jetons d'espace réservé (${SHELLCODE}, ${KEY}, ${IV}, ${TARGET_PROCESS}) que hollow remplit avant compilation. Vous sélectionnez un modèle via votre profil.

hollow est livré avec six modèles :

Vous pouvez écrire vos propres modèles et les placer dans templates/ — hollow les détectera automatiquement tant que votre profil y fait référence.

Profils

Les profils sont des fichiers JSON qui indiquent à hollow quel modèle utiliser, quel processus cibler et comment compiler la sortie. Ils se trouvent dans profiles/ et sont destinés à être personnalisés par engagement.

{
    "name": "New Process Injection via Direct Syscalls",
    "author": "",
    "template": "new_process_injection_sc",
    "target_process": "C:\\Windows\\System32\\cmd.exe",
    "arch": "x64",
    "compile": {
        "automatic": true,
        "gcc": "x86_64-w64-mingw32-gcc",
        "strip": true,
        "output_type": "exe"
    },
    "output_dir": "./output"
}

output_type est soit exe soit dll. Mettez automatic: false pour écrire le code C substitué sur le disque au lieu de le compiler, utile si vous voulez modifier le code avant la construction.

Le fichier de sortie est écrit dans output_dir, nommé {template}_loader.{exe|dll}.

Modèles en détail

Injection dans un nouveau processus

Modèle : new_process_injection

Technique : Injection de thread distant dans un processus fraîchement lancé.

Lance le processus cible avec CREATE_BREAKAWAY_FROM_JOB | CREATE_NO_WINDOW, attend deux secondes qu'il s'initialise, puis alloue de la mémoire dans son espace d'adressage, écrit le shellcode déchiffré, le marque comme exécutable et crée un thread distant pointant dessus. Le drapeau BREAKAWAY est nécessaire lorsque le chargeur est lancé depuis WinRM, qui encapsule tous les processus dans un objet travail (job). La cible est un chemin d'exécutable complet.

Appels Win32 : CreateProcessA, VirtualAllocEx, WriteProcessMemory, VirtualProtectEx, CreateRemoteThread.

Injection dans un nouveau processus via des appels système directs

Modèle : new_process_injection_sc

Technique : Injection de thread distant dans un processus fraîchement lancé, via des appels système directs (Hell's Gate).

Même comportement que new_process_injection, mais chaque appel d'allocation et de thread contourne complètement la couche Win32. Les SSN sont résolus depuis ntdll à l'exécution et exécutés via l'instruction syscall brute. Voir la section benchmark.

Injection de thread distant

Modèle : remote_thread_injection

Technique : Injection classique de thread distant dans un processus existant.

Trouve un processus en cours d'exécution par son nom en utilisant CreateToolhelp32Snapshot, ouvre un handle sur celui-ci, puis alloue de la mémoire, écrit le shellcode et crée un thread distant. Aucun nouveau processus n'est lancé. Idéal contre des processus de longue durée comme explorer.exe. La cible est un nom d'image de processus, pas un chemin complet.

Appels Win32 : OpenProcess, VirtualAllocEx, WriteProcessMemory, VirtualProtectEx, CreateRemoteThread.

Injection de thread distant via des appels système directs

Modèle : remote_thread_injection_sc

Technique : Injection classique de thread distant dans un processus existant, via des appels système directs (Hell's Gate).

Même comportement que remote_thread_injection, contournant la couche Win32. Voir la section benchmark.

Injection APC Early Bird

Modèle : earlybird_apc

Technique : Injection APC Early Bird (CyberArk, 2018).

Lance le processus cible en état suspendu (CREATE_SUSPENDED | CREATE_BREAKAWAY_FROM_JOB | CREATE_NO_WINDOW), écrit le shellcode déchiffré dans son espace d'adressage, puis place un appel de procédure asynchrone (APC) dans la file d'attente du thread principal pointant vers le shellcode via QueueUserAPC, et reprend avec ResumeThread. Comme l'APC se déclenche avant que le point d'entrée du processus ne s'exécute, le shellcode s'exécute avant que tout outil défensif du processus ne soit initialisé. Évite complètement la triade VirtualAllocEx + WriteProcessMemory + CreateRemoteThread.

Détournement de DLL

Modèle : dll_sideload

Technique : Détournement de DLL / Exécution de shellcode in-process.

Produit une DLL au lieu d'un EXE. Lors de DLL_PROCESS_ATTACH, un thread est lancé qui déchiffre et exécute le shellcode in-process : VirtualAlloc, memcpy, VirtualProtect, puis un appel direct de fonction dans le shellcode. Le processus hôte doit rester vivant pendant que la charge utile s'initialise (environ 10 secondes pour un beacon Sliver). Déployez en plaçant la DLL dans un emplacement où un binaire légitime la chargera via un chemin de recherche de DLL manquant.

Benchmark : Win32 contre appels système directs

Testé sur Windows 10 Build 19041, protection en temps réel de Windows Defender activée, définitions 1.453.354.0, avec un beacon Sliver enveloppé dans Donut de 17 Mo comme charge utile :

Trojan:Win64/AsyncRat.RPY!MTB est une règle de menace-machine basée sur le comportement déclenchée par la séquence classique d'injection à distance : VirtualAllocEx + WriteProcessMemory + CreateRemoteThread appelée sur un handle de processus distant via la couche API Win32. Defender enregistre un rappel noyau qui se déclenche lorsque ces trois appels apparaissent en séquence.

Les modèles _sc contournent cela en n'appelant jamais ces fonctions Win32. Au lieu de cela, ils résolvent les numéros de service d'appel système (SSN) correspondants directement depuis ntdll à l'exécution en utilisant Hell's Gate : chaque stub ntdll non hooké commence par le prologue de quatre octets 4C 8B D1 B8, et le SSN se trouve à l'offset 4. L'appel système réel est une fonction nue GCC contenant uniquement movq %rcx, %r10 / movl ssn(%rip), %eax / syscall / ret, qui est exactement la séquence que le stub ntdll lui-même exécuterait. Le rappel de Defender ne se déclenche jamais car les wrappers Win32 surveillés ne sont jamais invoqués.

Sur les systèmes où les stubs de ntdll sont modifiés par un EDR complet (prologue remplacé par un saut), la vérification du stub propre échoue et le chargeur se termine prématurément. Le Halo's Gate (analyse des stubs voisins pour déduire le SSN) n'est pas implémenté.

Taille du binaire

Le code du chargeur ajoute environ 19 Ko de surcharge. La taille de sortie est essentiellement celle du shellcode d'entrée. Un beacon Sliver de 17 Mo produit un chargeur de 18 Mo. Un shellcode Metasploit typique (~200 Ko) produirait un chargeur d'environ 220 Ko.

Contribuer

Les contributions sont les bienvenues. Si vous avez un modèle que vous avez écrit et que vous souhaitez l'ajouter, ou des améliorations aux modèles existants, n'hésitez pas à ouvrir une PR. Si vous trouvez un bug ou avez une suggestion, ouvrez un ticket.

L'objectif de cet outil est de faciliter le processus de développement de chargeurs, pas d'être un produit fini. De nouveaux modèles, de meilleurs profils et des améliorations du cœur sont tous les bienvenus. hollow a également été construit dans l'intention d'aider les gens à comprendre les concepts derrière les chargeurs de shellcode et les techniques d'injection, donc un code de modèle clair et lisible est aussi précieux que la fonctionnalité.

Blog

Je détaillerai très bientôt les concepts derrière chaque technique et l'utilisation complète de hollow sur mon blog. Restez à l'écoute.

Références

• ldrgen par gatari, inspiration et référence pour la conception du chargeur de shellcode