Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
BOF_RunPe — BOF pour exécuter un PE dans Cobalt Strike Beacon sans création de console | Kitploit
Outils/GitHubGitHub/ntdallas/bof_runpe
Criminalistique MémoireShellcodePost-ExploitationRed Teaming
GitHubntdallas/bof_runpe

BOF_RunPe

BOF pour exécuter un PE dans Cobalt Strike Beacon sans création de console

Voir le dépôt
2002510il y a 10 moisVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

BOF_RunPE

BOF RunPE est un fichier Beacon Object pour Cobalt Strike qui exécute des fichiers PE entièrement en mémoire dans le processus du beacon. Contrairement au fork&run traditionnel, aucun processus enfant n'est créé, aucune console n'est ouverte et aucun tube n'est utilisé – toute la sortie est capturée via un hooking IAT et redirigée vers la console du beacon.

Architecture : x64 uniquement

Aperçu

┌──────────────────────────────────────────────────────────────┐
│                   Cobalt Strike Beacon                       │
│                    (Current Process)                         │
└────────────────────────┬─────────────────────────────────────┘
                         │
                         │  beacon_inline_execute()
                         │
                         ▼
┌──────────────────────────────────────────────────────────────┐
│                    BOF RunPE                                 │
│  ┌────────────────────────────────────────────────────────┐  │
│  │  VxTable + Draugr Initialization                       │  │
│  │  (Syscall Resolution + Stack Spoofing)                 │  │
│  └──────────────────────┬─────────────────────────────────┘  │
│                         │                                    │
│  ┌──────────────────────▼─────────────────────────────────┐  │
│  │  PE Mapping                                            │  │
│  │  - Section Copy    - IAT Patching (with hooks)         │  │
│  │  - Relocations     - Memory Protection                 │  │
│  └──────────────────────┬─────────────────────────────────┘  │
│                         │                                    │
│  ┌──────────────────────▼─────────────────────────────────┐  │
│  │  Thread Execution                                      │  │
│  │  - Spoofed Start Address                               │  │
│  │  - RIP Hijacking to Entry Point                        │  │
│  │  - Output Redirection via Hooks                        │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

Principales fonctionnalités

  • Aucune création de processus : le PE s'exécute dans le processus du beacon
  • Aucune console/tube : la sortie est capturée via des hooks printf/WriteConsole
  • Plusieurs méthodes d'allocation : Heap, VirtualAlloc, Module Stomping
  • Chargement par proxy : Timer Queue, RegisterWait, ou appels directs
  • Déhooking de Ntdll : copie fraîche facultative depuis le disque
  • RWX : allocation mémoire facultative en RWX
  • Usurpation du démarrage de thread : adresse de départ légitime avec détournement de RIP

Options de configuration

Le comportement du BOF peut être modifié dans Additionals postex -> RunPe Config

Custom BOF

Méthodes de proxy

MéthodeDescription
NoneAppels API directs
DraugrAppels API avec spoofing de pile
RegwaitCallback RegisterWaitForSingleObject
TimerCallback Timer Queue

Méthodes d'allocation

MéthodeDescription
HeapTas privé via RtlCreateHeap avec Draugr
VirtualAllocNtAllocateVirtualMemory avec Draugr
Module stompingÉcrase la section .text d'une DLL légitime

Options générales

OptionDescription
AllocRWXAllouer en RWX (vs transition RW→RX)
UnhookNtdllRemplacer la section .text de ntdll.dll par une copie fraîche du disque
TimeoutDélai d'exécution en millisecondes (0 = infini)
StompModuleChemin de la DLL pour le module stomping (ex. chakra.dll)

Usurpation de thread

OptionDescription
ModuleNameModule légitime pour l'adresse de départ (ex. Kernel32.dll)
ProcedureNameNom de la fonction dans le module (ex. BaseThreadInitThunk)
OffsetDécalage depuis le début de la fonction

Capture de sortie

Toute la sortie du PE est redirigée vers la console du beacon via des hooks IAT. Aucune fenêtre de console ni tube nommé n'est créé.

Fonction hookéeCible
GetCommandLineA/WRetourne des arguments usurpés
__getmainargs / __wgetmainargsInitialisation des arguments CRT
printf / wprintfRedirection vers BeaconPrintf
WriteConsoleA/WRedirection vers BeaconPrintf
__stdio_common_vfprintfFonctions d'impression UCRT
ExitProcess / exitConverti en ExitThread

Techniques d'évasion

TechniqueContourne
Syscalls indirectsHooks API en espace utilisateur (EDR/AV)
Draugr Stack SpoofingInspection de la pile d'appels
Usurpation du démarrage de threadAnalyse de l'adresse de début de thread
Module StompingDétection de mémoire sans sauvegarde
Allocation en tas privéSurveillance de VirtualAlloc
Déhooking de NtdllÉcriture de ntdll du disque sur celui en mémoire
Hooking IAT (sans tubes)Surveillance des tubes nommés

Vecteurs de détection

Télémétrie du noyau (ETW-TI)

NtGetContextThread / NtSetContextThread :

  • Manipulation du contexte d'un thread suspendu puis reprise

Opérations mémoire :

  • Allocation NtAllocateMemory, possible en RWX (selon configuration)
  • Transitions NtProtectVirtualMemory (RW → RX)
  • Mémoire exécutable dans des régions de tas est suspecte (selon configuration)
  • Module stomping détectable par désaccord de hachage de section (selon configuration)

Indicateurs comportementaux

  • Création d'un thread suspendu, récupération du contexte puis modification de la valeur de RIP
  • Mémoire du tas marquée comme exécutable (si l'allocateur est le tas)
  • DLL chargée avec DONT_RESOLVE_DLL_REFERENCES (si l'allocateur est le module stomping)
  • Section .text de Ntdll modifiée (si le déhooking est activé)

Utilisation

Chargement du script

Cobalt Strike → Script Manager → Load → BOF_RunPe.cna

Commandes Aggressor

beacon> runpe /chemin/vers/binaire.exe --arg1 valeur1

Mimikatz

beacon> help runpe

Help

Compilation

Nécessite GCC 13 (mingw-w64). Utiliser le Dockerfile fourni :

sudo docker build -t ubuntu-gcc-13 .
sudo docker run --rm -it -v "$PWD":/work -w /work ubuntu-gcc-13:latest make

Sortie : Bin/runpe.o

Limitations

LimitationDescription
CETLa technologie Control-flow Enforcement peut bloquer les trames de pile synthétiques
x64 OnlyPas de support x86/WoW64
Kernel VisibilityLa création de threads est visible par les callbacks du noyau
.NETLes exécutables managés ne sont pas supportés

Crédits / Ressources utilisées pour le développement

Dépôts/articles de blog

  • https://github.com/susMdT/LoudSunRun
  • https://github.com/Octoberfest7/Inline-Execute-PE
  • https://www.coresecurity.com/core-labs/articles/running-pes-inline-without-console
  • https://0xdarkvortex.dev/proxying-dll-loads-for-hiding-etwti-stack-tracing/

Livres

  • Windows Native API Programming par Pavel Yosifovich
  • Windows Internals, Part 1 par Pavel Yosifovich
  • Windows Internals, Part 2 par Andrea Allievi
Télécharger l’outil