Remote BOF Runner

Un framework d'extension Havoc pour l'exécution à distance de fichiers objet Beacon (BOF) en utilisant un chargeur PIC réalisé avec Crystal Palace.

Aperçu

Remote BOF Runner permet l'exécution sécurisée de BOFs dans des processus arbitraires en exploitant le chargeur PIC Crystal Palace. Ce framework implémente un mécanisme sophistiqué de communication inter-processus (IPC) via des tubes nommés pour transférer de manière transparente la sortie des beacons des processus injectés vers le serveur de commande et contrôle (C2).

Configuration et installation

Installation de l'extension

Assurez-vous que l'extension est installée dans le répertoire des extensions d'Havoc :

YOUR_HAVOC_FOLDER + /data/extensions/

Dépendances

Pour compiler le chargeur PIC, les outils et bibliothèques suivants doivent être installés sur votre système :

• MinGW-w64 : Compilateur croisé pour cibles Windows
• Make : Outil d'automatisation de build
• OpenJDK 11 : Kit de développement Java (requis pour la compilation de Crystal Palace)
• Zip : Utilitaire de compression

Pour des instructions d'installation détaillées, consultez le Guide d'installation WSL.

Commandes d'installation

sudo apt-get update
sudo apt-get install mingw-w64
sudo apt-get install make
sudo apt-get install openjdk-11-jdk
sudo apt-get install zip

Architecture

Composants

1. Injecteur BOF

Le composant BOF est responsable de :

• Créer et suspendre un processus factice.
• Injecter le chargeur Crystal Palace et le BOF cible dans le processus factice.
• Établir un canal IPC (tube nommé) pour la communication de sortie.
• Recevoir et agréger la sortie de l'exécution du BOF distant.

2. Chargeur PIC (Crystal Palace)

Le chargeur PIC se compose de :

• Chargeur Crystal Palace : Gère l'allocation mémoire, la gestion de la section BSS, et l'initialisation sécurisée du contexte d'exécution.
• Charge utile BOF distante : Le code BOF réel à exécuter (whoami, ipconfig, cacls, reg-query, etc.).
• Marshalling d'arguments : Arguments sérialisés passés via le chargeur pour l'exécution distante du BOF.

Flux d'exécution

┌───────────────────────────────────────────────────────────────────┐
│ 1. Processus Beacon (Havoc)                                       │
│    ├─ Exécuter l'injecteur BOF                                    │
│    ├─ Créer un processus factice (suspendu)                       │
│    ├─ Injecter le chargeur PIC + BOF distant                      │
│    └─ Créer un tube nommé IPC                                     │
└────────────┬──────────────────────────────────────────────────────┘
             │
             ▼
┌───────────────────────────────────────────────────────────────────┐
│ 2. Exécution du chargeur PIC                                      │
│    ├─ Chargeur Crystal Palace                                     │
│    ├─ Effectue l'allocation de la section BSS                     │
│    ├─ Initialise le contexte UI (pour la compatibilité .NET)      │
│    └─ Hooke les fonctions beacon (BeaconPrintf, BeaconOutput, etc.)│
└────────────┬──────────────────────────────────────────────────────┘
             │
             ▼
┌───────────────────────────────────────────────────────────────────┐
│ 3. Exécution du BOF distant                                       │
│    ├─ Exécuter le BOF cible (whoami, ipconfig, etc.)              │
│    ├─ Le BOF appelle les fonctions beacon hookées                 │
│    ├─ Les fonctions hookées redirigent la sortie vers le tube IPC│
│    └─ La sortie s'accumule dans le processus beacon via le tube   │
└────────────┬──────────────────────────────────────────────────────┘
             │
             ▼
┌───────────────────────────────────────────────────────────────────┐
│ 4. Collecte et transmission de la sortie                          │
│    ├─ Le beacon attend la fin du processus distant                │
│    ├─ Accumule toute la sortie du tube IPC                        │
│    ├─ Agrège les messages fragmentés (tampon de 8 Ko)             │
│    ├─ Filtre les délimiteurs de protocole (@START@, @END@)        │
│    └─ Transmet la sortie consolidée au serveur d'équipe           │
└───────────────────────────────────────────────────────────────────┘

Fonctionnalités clés

1. Isolation des processus

• L'exécution du BOF a lieu dans un processus séparé et isolé.
• Minimise l'impact sur la stabilité du processus beacon.
• Permet l'exécution dans des contextes de processus arbitraires.

2. Transfert de sortie IPC

• Canal de communication basé sur des tubes nommés.
• Redirection transparente de la sortie du BOF distant.
• Gestion des fragments de messages (tampon d'accumulation de 8 Ko).
• Filtrage des délimiteurs de protocole.

3. Exécution dans un processus .NET

Le cas d'utilisation principal est l'exécution de BOFs dans des processus .NET natifs :

Pourquoi le chargement direct du CLR dans Beacon est risqué : Charger des assemblies .NET directement dans le processus beacon est intrinsèquement dangereux et détectable :

• Le processus beacon (généralement un binaire natif comme cmd.exe ou rundll32.exe) ne lance normalement pas de CLR.
• Lorsqu'un CLR est chargé dans un processus non .NET, cela déclenche immédiatement des alertes EDR/XDR.

Une solution possible : injection dans un processus .NET natif : Au lieu de charger le CLR dans le beacon, nous injectons et exécutons notre BOF inline-execute-assembly dans un processus déjà natif .NET :

// ❌ DÉTECTABLE : Exécution directe dans le beacon
beacon.exe (natif) → charger ClrCreateInstance → charger assembly .NET → ALERTE EDR

// ✅ DISCRÈTE : Exécution dans un processus .NET natif
dotnet.exe (.NET natif) → injecter BOF → inline-execute-assembly → 
exécuter assembly .NET dans un contexte CLR déjà présent → comportement normal

Cette approche exploite le fait qu'exécuter du .NET dans un processus .NET est impossible à distinguer d'un comportement normal d'application.

4. Intégration de Crystal Palace

• Exécution de code indépendant de la position.
• Résolution dynamique d'API via des recherches de fonctions basées sur des hachages.
• Aucune dépendance à la table d'adresses d'importation.
• Appropriée pour des scénarios d'injection profonde.

Modes d'exécution

Exécution locale

remote-bof-runner whoami
remote-bof-runner ipconfig
remote-bof-runner cacls C:\Windows\System32

Exécution sur un hôte distant

remote-bof-runner reg-query DC01 HKLM SYSTEM\CurrentControlSet

Requêtes de registre

remote-bof-runner reg-query HKLM SYSTEM\CurrentControlSet\Control\Lsa
remote-bof-runner reg-query HKLM SYSTEM\CurrentControlSet\Control\Lsa RunAsPPL

Exécution d'assembly .NET

remote-bof-runner execute-assembly --dotnetassembly "/Payloads/Rubeus.exe" --assemblyargs "triage"

Exemple de sortie :

BOFs disponibles

• whoami - Affiche les informations sur l'utilisateur et le groupe actuels (CS-Situational-Awareness-BOF).
• ipconfig - Affiche la configuration des adaptateurs réseau (CS-Situational-Awareness-BOF).
• cacls - Liste les permissions des fichiers (CS-Situational-Awareness-BOF).
• reg-query - Interroge le registre Windows (CS-Situational-Awareness-BOF).
• execute-assembly - Charge un assembly .NET dans le processus réel (https://github.com/VoldeSec/PatchlessInlineExecute-Assembly).
• bof - Exécute des binaires BOF personnalisés.

Considérations de sécurité opérationnelle

⚠️ Important : Ce projet est une preuve de concept et ne donne PAS la priorité à l'OPSEC par défaut.

Modifications recommandées

L'injecteur BOF et le chargeur PIC nécessitent tous deux un renforcement significatif pour les simulations adverses :

Renforcement de l'injecteur BOF

• Implémenter des méthodes de création de processus personnalisées (pas CreateProcessW).
• Utiliser des techniques d'injection alternatives au-delà de WriteProcessMemory standard.
• Obscurcir le nommage des tubes IPC (randomiser les identifiants).

Renforcement du chargeur PIC

• Chiffrer le protocole de communication (messages du tube).
• Implémenter des techniques d'évasion des règles YARA pour les signatures connues.
• Ajouter une méthode pour contourner les hooks de processus (syscalls indirects, méthodes de déshooking, etc.).
• Ajouter une méthode de chiffrement pour stocker le BOF cible et ses arguments.

Références

• Crystal Palace
• LibIPC - Bibliothèque partagée de Crystal Palace pour la communication inter-processus, basée sur des tubes nommés.
• PatchlessInlineExecute-Assembly - BOF InlineExecute-Assembly pour charger un assembly .NET dans un processus mais avec contournement patchless d'AMSI et ETW utilisant des points d'arrêt matériels.
• CS-Situational-Awareness-BOF - Commandes de connaissance situationnelle implémentées à l'aide de fichiers objet Beacon.

Avis de non-responsabilité

Cet outil est fourni à des fins éducatives et de tests de sécurité autorisés uniquement. L'accès non autorisé aux systèmes informatiques est illégal. Les utilisateurs sont responsables du respect de toutes les lois et réglementations applicables.