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