emp3r0r v4.15.0

emp3r0r

Un C2 auto-réparateur, uniquement en mémoire, pour Linux et Windows — des agents qui survivent aux liens rompus, ne touchent jamais le disque et se frayent un chemin dans l'API Win32 par script.

Qu'est-ce qu'emp3r0r ?

emp3r0r est un framework de post-exploitation et un C2 conçu pour les environnements Linux et Windows où la furtivité et la résilience ne sont pas optionnelles. Au lieu de supposer une connexion fiable vers un seul serveur, les agents forment un maillage auto-réparateur qui continue de fonctionner lorsque les liens se rompent. Au lieu de demander Python ou PowerShell à la cible, ils exécutent tout en mémoire. Et au lieu de vous limiter aux astuces d'une seule plateforme, emp3r0r exécute des BOFs Windows, des objets Linux et des scripts Starlark — le tout sans fichier, le tout en processus.

Points clés et fonctionnalités uniques

🐍 Agents scriptables (moteur Starlark embarqué et proxy d'API Win32)

Chaque agent embarque son propre moteur de script, ce qui vous permet d'ajouter de nouvelles logiques de post-exploitation sans compiler ni déployer de binaires.

• Les scripts s'exécutent entièrement en mémoire — aucun Python, Bash ou PowerShell requis sur la cible, et aucun interpréteur de commandes lancé.
• Un ensemble complet d'API intégrées couvre les E/S de fichiers, HTTP, l'exécution de commandes, et plus encore, directement depuis le code du script.
• Sous Windows, les scripts peuvent appeler directement des fonctions Win32 natives — l'agent fait office de proxy vers les DLL système.
• Les modules sont de simples fichiers Starlark accompagnés d'un petit manifeste JSON, ce qui rend l'ajout des vôtres facile et sans fichier.

Pourquoi c'est important : écrire et étendre les fonctionnalités de l'agent devient aussi simple que de modifier un script, sans la moindre empreinte liée au dépôt d'un interpréteur ou d'un nouveau binaire sur la cible.

🔐 Épinglage d'identité cryptographique TOFU

Les agents lient leur identité à une clé cryptographique la première fois qu'ils communiquent avec vous — et ce lien ne change jamais.

• Une ré-inscription avec des identifiants différents est traitée comme un imposteur et rejetée.
• La suppression d'un agent est une décision explicite de l'opérateur, et non quelque chose qu'une clé volée peut faire discrètement.

Pourquoi c'est important : le détournement de session et le clonage d'agent ne se produisent tout simplement pas ; chaque agent avec lequel vous communiquez est celui que vous avez enregistré.

🔒 Confidentialité persistante (PFS)

Chaque lien C2 et pair-à-pair utilise des clés ECDH éphémères avec des clés de chiffrement dérivées de la session.

Pourquoi c'est important : même si une clé à long terme est compromise plus tard, elle ne peut pas être utilisée pour déchiffrer le trafic déjà passé.

🕸️ Réseau maillé P2P gossip autonome

Les agents se découvrent mutuellement et relaient le trafic via un maillage gossip, de sorte que l'opération ne s'effondre pas lorsqu'un lien ou un serveur disparaît.

• Les pairs se connectent via mTLS 1.3 de camouflage ou UDP fiable (KCP), avec chaque saut chiffré.
• Le trafic contourne automatiquement les relais morts — aucune chirurgie manuelle de proxy en pleine opération.
• Les segments sans accès direct au C2 restent joignables via leurs voisins.

Pourquoi c'est important : le réseau fait le pivotement pour vous. Coupez un lien, perdez une machine ou bloquez le C2 — les agents se reroutent d'eux-mêmes.

📂 Système de fichiers P2P

Les fichiers circulent directement entre agents, pas seulement via le C2.

• Les transferts empruntent des tunnels pair-à-pair chiffrés, de sorte que les réseaux internes ne saturent pas votre serveur.
• Les fichiers sont mis en cache dans la mémoire de l'agent sous forme de blobs chiffrés et servis aux pairs à la demande.
• Si aucun pair ne possède un fichier, l'agent le récupère automatiquement depuis le C2.

Pourquoi c'est important : la livraison est rapide et largement invisible pour le canal C2 — idéal pour les environnements à sortie restreinte.

📡 Écouteurs multi-protocoles et stagers enfichables

Faire entrer un agent est traité aussi sérieusement que le maintenir en vie.

• Écouteurs HTTP, TCP et UDP avec cadrage fiable et profils HTTP personnalisables.
• Un stager d'environ 2 Ko construit sur des appels système Linux directs — pas de libc, pas de chaîne d'outils sur la cible.
• Des transports de stager enfichables et des packers auto-décompressants vous permettent de fondre l'accès initial dans le canal que votre cible autorise, et de déjouer au passage la correspondance statique de signatures.
• Le code du stager et de l'agent respecte la discipline lecture/écriture/exécution — jamais RWX.

Pourquoi c'est important : un accès initial petit, adaptable et hygiénique en mémoire signifie que vous pouvez atterrir sur des hôtes qui seraient autrement hors de portée.

🧩 Prise en charge native multiplateforme des BOF et PICO (COFF, ELF et PICO)

Exécutez des modules C compilés en processus sur l'une ou l'autre plateforme :

• Binaires Windows COFF/BOF avec empaquetage d'arguments typés.
• Objets relogeables ELF Linux chargés directement dans la mémoire de l'agent.
• Modules Crystal-Kit PICO avec usurpation de pile d'appels SilentMoonwalk.
• Kerbeus-BOF, Remote-OPs et une suite de conscience situationnelle sont livrés prêts à l'emploi.

Pourquoi c'est important : les BOFs ne valent que par leur chargeur — emp3r0r les exécute en processus sans nouveau processus et sans trace laissée derrière, sous Linux comme sous Windows.

🔑 Jetons Windows, sessions netonly et tickets Kerberos (PTT)

Une fois sur un hôte Windows, emp3r0r vous permet de devenir les utilisateurs qui s'y trouvent — sans jamais déposer d'outil.

• Volez un jeton d'accès depuis n'importe quel processus en cours et utilisez-le partout : modules Go, Starlark, BOFs.
• Créez des sessions netonly jetables avec le drapeau --user d'un module : elles conservent l'identité propre de votre agent et n'empruntent celle de l'utilisateur cible que pour l'accès sortant — n'importe quel mot de passe fonctionne, rien n'est jamais validé.
• Importez des tickets Kerberos avec le drapeau --ticket pour un pass-the-ticket complet : votre identité réseau devient celle du ticket (par exemple, l'administrateur du domaine) tandis que votre identité locale ne change jamais.
• Chaque module compatible avec les jetons accepte --token, --user et --ticket, de sorte que changer d'identité ne tient qu'à un drapeau — y compris créer une session et charger un ticket en une seule commande.
• Les tickets vivent par session d'ouverture de session, de sorte que le matériel DA reste mis en quarantaine dans une session jetable que vous pouvez purger, et le processus de l'agent lui-même reste propre.

Pourquoi c'est important : le mouvement latéral vers des machines sans aucun agent — partages SMB, contrôle de service, CIFS — devient une partie normale de votre flux de travail, authentifié en tant qu'utilisateur emprunté, et non en tant qu'outil sur disque.

🧦 Pivotement SOCKS5 et tun2socks côté opérateur

Pivotez sans brûler un autre implant : le C2 exécute un proxy SOCKS5 qui relaie via l'agent que vous sélectionnez, et le côté opérateur peut aller plus loin avec un périphérique TUN transparent.

• socks_start 1080 vous donne un point de terminaison SOCKS5 sur le C2 qui tunnelise via l'agent choisi — pointez proxychains ou n'importe quel outil dessus et vous êtes à l'intérieur du réseau cible.
• tun2socks start --route 10.10.0.0/24 crée un périphérique TUN qui route uniquement les sous-réseaux que vous nommez via ce proxy — tout le reste continue d'utiliser votre connexion normale.
• Le résultat semble provenir de l'agent, sans configuration de proxy par outil.

Pourquoi c'est important : atteignez des réseaux entiers côté agent de manière transparente — faites un curl vers un DC, utilisez n'importe quel outil — avec une sortie qui semble provenir du réseau cible, et non de votre machine opérateur.

🎭 Transport C2 enfichable, évasion JA3 uTLS et protocole CBOR

• Choisissez l'interrogation HTTP de style beacon ou le streaming HTTP/2 — les deux avec des profils malléables.
• Les empreintes TLS sont randomisées avec uTLS, de sorte que le canal ne se démarque pas dans la télémétrie réseau.
• Le trafic de contrôle emprunte un protocole CBOR compact — plus petit, plus rapide et plus difficile à analyser que JSON.

Pourquoi c'est important : le canal C2 est conçu pour ressembler à du trafic ordinaire et rester léger sur le réseau.

💾 Stockage chiffré privilégiant la mémoire

• Les opérations de fichiers de l'agent s'exécutent sur un système de fichiers virtuel en mémoire, chiffré en AES-GCM ; les données volumineuses ne débordent sur le disque que sous forme de blobs chiffrés sans en-têtes identifiables.
• Les agents compatibles P2P mettent en cache ce qu'ils récupèrent et le partagent avec leurs pairs, réduisant encore le trafic C2.

Pourquoi c'est important : même le disque est considéré comme hostile — l'agent ne conserve aucun artefact en clair à trouver.

Démarrage rapide

1. Installation du serveur C2

La compilation d'emp3r0r nécessite Docker ou Podman sur l'hôte — pas de chaîne d'outils Go locale.

git clone --depth=1 https://github.com/jm33-m0/emp3r0r.git && cd emp3r0r
./install.py

L'installateur compile tout dans un conteneur jetable et prépare le kit opérateur. Drapeaux utiles : --lightweight (Linux/Windows amd64 uniquement, le plus rapide), --targets OS/ARCH,..., --debug, --skip-build.

Lancez le serveur :

emp3r0r server --c2-hosts 1.2.3.4 --http-port 12345 --operator-port 13377

2. Configuration de la machine opérateur

tar --zstd -xpf emp3r0r-operator-kit.tar.zst
cd ./emp3r0r-operator-kit && ./install.py

Connectez-vous à l'aide des identifiants WireGuard affichés par le serveur :

emp3r0r client --c2-port 13377 \
  --server-wg-key '<SERVER_WG_KEY>' --server-wg-ip '<SERVER_WG_IP>' \
  --operator-wg-ip '<OPERATOR_WG_IP>' --operator-wg-key '<OPERATOR_WG_KEY>' \
  --c2-host 1.2.3.4

3. Générer des charges utiles d'agent

Dans la console opérateur :

# Direct C2 agent
generate --type linux_executable --arch amd64 --cc your.domain.com

# Mesh gateway agent (also reachable from the C2 directly)
generate --type linux_executable --arch amd64 --cc your.domain.com \
  --p2p --direct-c2 --p2p-transport mtls

# Mesh intermediate peer (relays for other agents)
generate --type linux_executable --arch amd64 --cc your.domain.com \
  --p2p --p2p-transport mtls --peers 1.2.3.4

# Windows mesh peer over SMB named pipes (local \\.\pipe, cross-host \\host\pipe),
# AES-GCM framed like the other transports
# (requires the Windows SMB stack / logon session to reach the peer)
generate --type windows_executable --arch amd64 --cc your.domain.com \
  --p2p --p2p-transport smb

Les nœuds du maillage peuvent utiliser différents transports. Chaque agent annonce le transport et le port sur lesquels son relais écoute, et les composeurs utilisent toujours le transport annoncé par le pair, de sorte qu'un maillage mixte (par exemple des nœuds Windows SMB aux côtés de nœuds Linux mTLS) route via un pair qui partage un transport utilisable au lieu de supposer que tout le monde utilise la valeur par défaut locale. smb n'est accepté que pour les charges utiles Windows ; kcp/mtls fonctionnent partout.

Documentation et ressources

• 📝 Politique de sécurité : SECURITY.md
• 📜 Journal des modifications : CHANGELOG.md
• 🛠️ Guide de développement de modules : core/modules/module_development_guide.md

Soutenir le développement

Si emp3r0r s'est révélé précieux dans vos recherches et tests de sécurité, envisagez de soutenir son développement continu via GitHub Sponsors.