Aller au contenu

Concepts de base

Cette page explique comment Stentor fonctionne sous le capot : les composants qui composent la plateforme, les entités avec lesquelles vous interagissez et le cycle de vie d'une opération C2, du déploiement à la post-exploitation.

Si vous êtes nouveau dans les frameworks Command and Control (C2), cette page vous donnera les bases dont vous avez besoin. Si vous avez de l'expérience avec des outils comme Cobalt Strike, Sliver ou Mythic, vous trouverez des concepts familiers mappés à la terminologie de Stentor.

Présentation de l'architecture

Stentor est un système distribué composé de quatre composants qui communiquent au-delà des frontières du réseau :

graph LR
    subgraph Operator
        UI["Web UI<br/><small>:3001</small>"]
    end
    subgraph Server ["Stentor Server"]
        API["Backend API<br/><small>:8082</small>"]
        DB[("PostgreSQL")]
    end
    subgraph Kali ["Relay Agent"]
        Relay["Relay Service"]
        Listener["C2 Listener"]
    end
    subgraph Target ["Windows Target"]
        Implant["Implant"]
    end

    UI -->|"REST / WebSocket"| API
    API --> DB
    API <-->|"WebSocket"| Relay
    Relay --> Listener
    Implant <-->|"HTTP / DNS / SMB"| Listener

Les quatre composants

Interface utilisateur de l'opérateur

Une application Web React qui s'exécute dans votre navigateur. C'est votre fenêtre sur l'engagement : vous créez des listeners, générez des payloads, émettez des commandes aux beacons et visualisez les informations collectées tout au long de cette interface. L'interface utilisateur communique avec le serveur via des appels d'API REST et une connexion WebSocket pour les mises à jour en temps réel.

Serveur

Le backend Go qui sert de cerveau à la plateforme. Il gère l'authentification, stocke toutes les données dans PostgreSQL, gère une file d'attente de tâches persistante pour les commandes de beacon et maintient les connexions WebSocket à la fois à l'interface utilisateur de l'opérateur (via CockpitHub) et aux agents de relais (via RelayHub). Le serveur ne communique jamais directement avec les cibles : il coordonne tout via des relais.

Relais

Un processus agent qui s'exécute sur une machine Kali Linux (ou sur tout hôte Linux positionné à la périphérie du réseau). Le relais se reconnecte au serveur Stentor via une connexion WebSocket persistante et héberge les listeners C2 qui acceptent les connexions des implants. Considérez le relais comme un traducteur : il communique le protocole C2 aux implants d'un côté et le protocole interne WebSocket au serveur de l'autre.

Implant

Un binaire compilé qui s'exécute sur la machine Windows cible. Une fois exécuté, l'implant se connecte à un listener C2 hébergé par un relais. Il s'enregistre périodiquement, récupère les tâches en file d'attente, les exécute et renvoie les résultats. L'implant comprend plus de 60 modules de post-exploitation pour les opérations sur les fichiers, la gestion des processus, la collecte d'informations d'identification, l'élévation des privilèges, les mouvements latéraux, etc.

Entités principales

Ce sont les objets que vous créez et avec lesquels vous interagissez lors d’un engagement. Comprendre leurs relations les uns avec les autres est essentiel pour des opérations efficaces.

Listener

Un service réseau qui accepte les connexions des implants. Les listeners sont créés par l'opérateur dans l'UI et hébergés sur un agent relais. Chaque listener possède un type (HTTP/S, DNS ou SMB), une adresse de liaison et un port. Vous devez démarrer un listener après l'avoir créé -- la création seule ne commence pas à accepter les connexions.

Exemple : Un listener HTTPS sur le port 8443 attribué au relais Kali.

Relais

Agent déployé qui se connecte au serveur Stentor et héberge les listeners. Dans une configuration typique, le relais s'exécute sur une machine Kali Linux disposant d'un accès réseau au serveur et à l'environnement cible. Plusieurs relais peuvent être déployés pour la redondance ou pour couvrir différents segments de réseau.

Exemple : Un relais fonctionnant sur Kali à 10.0.0.50, connecté au serveur via WebSocket.

Implant

Le binaire payload déployé sur une machine cible. Un implant est configuré au moment de la construction avec l'adresse d'un listener de rappel. Une fois exécuté, il établit une connexion et devient un beacon. Les implants prennent en charge plusieurs protocoles de transport et peuvent être générés dans différents formats (EXE, DLL, shellcode).

Exemple : Un implant EXE configuré pour rappeler https://10.0.0.50:8443.

Beacon

Une session en direct représentant un implant qui s'est connecté avec succès à un listener et s'est enregistré auprès du serveur. Les beacons apparaissent dans le graphique pivot du cockpit et sont pilotables via la console shell. Chaque beacon expose les propriétés de la machine cible :

  • Nom d'hôte -- le nom du réseau de la machine
  • Nom d'utilisateur : le contexte utilisateur dans lequel l'implant s'exécute.
  • PID -- l'ID de processus de l'implant
  • Niveau d'intégrité : Faible, Moyen, Élevé ou SYSTÈME
  • OS et architecture – par exemple, Windows 10 x64
  • IP interne/externe -- adresses réseau
  • Intervalle de veille et gigue : à quelle fréquence le beacon s'enregistre
  • Dernière heure d'enregistrement : date à laquelle le beacon a été vu pour la dernière fois
Tâche

Une commande envoyée à un beacon pour exécution sur la machine cible. Lorsque vous tapez une commande dans le shell du cockpit (par exemple, ls C:\Users), elle devient une tâche mise en file d'attente sur le serveur. La tâche est transmise à l'implant lors de son prochain enregistrement, exécutée et les résultats sont renvoyés de manière asynchrone.

Exemple : Une tâche screenshot mise en file d'attente pour le beacon sur WORKSTATION-01, livrée lors du prochain enregistrement, résultat affiché dans la console.

Le cycle de vie C2

Une opération complète de Stentor suit cette séquence depuis la configuration initiale jusqu'à l'engagement actif :

1. Déployer

Installez et démarrez le serveur et la base de données Stentor. Déployez un agent relais sur une machine positionnée pour atteindre les réseaux cibles (généralement une VM Kali Linux). Le relais se connecte au serveur via WebSocket et s'enregistre.

2. Configurer

Créez un listener dans l'interface utilisateur de Stentor. Choisissez le type de transport (HTTP/S est le plus courant), attribuez-le à un relais et configurez l'adresse et le port de liaison. Appliquez éventuellement un profil C2 malléable pour façonner la façon dont le trafic apparaît sur le fil.

3. Commencez

Démarrez le listener à partir de l'interface utilisateur. Le serveur envoie une commande de démarrage au relais via WebSocket et le relais commence à accepter les connexions sur le port configuré.

4. Générer

Générez un payload d'implant configuré pour rappeler l'adresse du listener. Choisissez le format en fonction de votre méthode de livraison : un EXE autonome pour une exécution directe, une DLL pour le chargement latéral ou un shellcode brut pour l'injection.

5. Exécuter

Livrez le payload à la cible et exécutez-la. Les méthodes de livraison varient : e-mails de phishing, téléchargements drive-by, chutes USB, exploitation ou placement manuel lors d'un accès physique.

6. Beacon

L'implant se connecte au listener et le relais transmet la connexion au serveur. Une nouvelle beacon apparaît dans le graphique pivot du cockpit. L'opérateur peut désormais voir les détails de la machine cible et commencer à émettre des commandes.

7. Utiliser

Émettez des commandes via le shell du cockpit. Les commandes transitent par l'opérateur via le serveur et sont relayées vers l'implant, et les résultats reviennent par le même chemin. Les opérations courantes comprennent :

  • Navigation dans le système de fichiers et transfert de fichiers
  • Dénombrement et injection de processus
  • Récolte d'identifiants (tickets SAM, LSASS, Kerberos)
  • Élévation de privilèges (contournement UAC, manipulation de jetons)
  • Reconnaissance du réseau (scan de ports, requêtes LDAP)
  • Capture d'écran et capture de frappe

8. Persister

Établissez des mécanismes de persistance pour que l’implant survive aux redémarrages et rétablisse le contact. Déplacez-vous latéralement vers des machines supplémentaires, augmentez les privilèges et étendez l'empreinte de l'engagement.

Flux de tâches

Le diagramme suivant montre comment une commande se déplace de l'opérateur à la cible et vice-versa :

sequenceDiagram
    participant Op as Operator
    participant Srv as Server
    participant Rel as Relay
    participant Imp as Implant

    Op->>Srv: Issue command (REST API)
    Srv->>Srv: Queue task for beacon
    Note over Imp: Implant sleeps between check-ins
    Imp->>Rel: Check-in (HTTP/DNS/SMB)
    Rel->>Srv: Forward check-in (WebSocket)
    Srv->>Rel: Deliver queued tasks
    Rel->>Imp: Send tasks in response
    Imp->>Imp: Execute tasks locally
    Note over Imp: Next check-in cycle
    Imp->>Rel: Return results on next check-in
    Rel->>Srv: Forward results (WebSocket)
    Srv->>Op: Display output (WebSocket push)

Asynchrone par conception

Les commandes ne sont pas délivrées instantanément. L’implant doit s’enregistrer avant de recevoir les tâches en file d’attente, et les résultats sont renvoyés lors de l’enregistrement suivant. Ce retard est intentionnel : il rend l’implant plus difficile à détecter. Voir Modèle de communication ci-dessous.

Modèle de communication

La communication Beacon est asynchrone et basée sur l'extraction. Comprendre ce modèle est essentiel pour des opérations efficaces.

Sleep et jitter

Chaque beacon dispose d'un intervalle de veille configurable : le temps entre les enregistrements. Un beacon dormant à 60 secondes avec 20 % de gigue s'enregistrera toutes les 48 à 72 secondes (60 ± 12 secondes de randomisation).

  • Sommeil plus long = temps de réponse plus furtifs mais plus lents
  • Veille plus courte = interaction plus rapide mais plus d'activité réseau (risque de détection plus élevé)
  • Mode interactif (veille 0 ou proche de zéro) fournit une interaction en temps quasi réel mais génère un trafic continu

Vous pouvez modifier l'intervalle de veille d'un beacon à tout moment avec la commande sleep.

Transports

Stentor prend en charge trois protocoles de transport pour la communication implant-relais :

HTTP/HTTPS

Le transport le plus courant. L'implant envoie des requêtes HTTP au listener, en se fondant dans le trafic Web normal. HTTPS ajoute le chiffrement TLS. Les profils C2 malléables peuvent transformer le trafic pour imiter des sites Web, des API ou des CDN légitimes.

DNS

Les données sont codées dans les requêtes et réponses DNS. Plus furtif que HTTP car le trafic DNS est rarement inspecté, mais nettement plus lent en raison de la petite taille de payload par requête. Idéal pour les canaux de persistance à faible bande passante.

SMB

Utilise des canaux nommés Windows pour la communication. Idéal pour le pivotement interne entre les machines sur le même segment de réseau sans générer de trafic lié à Internet. Les beacons SMB s’enchaînent via d’autres beacons ayant accès au réseau.

File d'attente des tâches

Le serveur maintient une file d'attente de tâches persistante par beacon. Lorsque vous émettez une commande, elle est immédiatement ajoutée à la file d'attente mais n'est délivrée que lorsque le beacon s'enregistre. Si vous mettez plusieurs commandes en file d'attente, elles sont livrées ensemble par lot lors de l'enregistrement suivant. Cela signifie que vous pouvez émettre plusieurs commandes et partir : elles s'exécuteront toutes dans l'ordre.

Modèle de sécurité

Stentor sécurise les communications à chaque couche de l'architecture.

Opérateur vers serveur

Toutes les requêtes API nécessitent un JWT (JSON Web Token) émis lors de la connexion. Les jetons sont de courte durée et peuvent être actualisés. Les mots de passe sont hachés avec Argon2id. La connexion WebSocket à CockpitHub nécessite la même authentification JWT.

Serveur à relais

Le relais s'authentifie auprès du serveur à l'aide d'un secret partagé (variable d'environnement RELAY_SECRET). La connexion WebSocket est persistante et bidirectionnelle, le serveur validant l'identité du relais lors de la connexion.

Relais vers Implant

La communication de l'implant est cryptée à l'aide de RSA pour l'échange de clés et d'AES pour le cryptage des payloads. Les profils C2 malléables dissimulent le modèle de trafic pour échapper à l'inspection au niveau du réseau, faisant ressembler le trafic C2 à des requêtes Web légitimes, des appels API ou à toute autre activité réseau bénigne.

Quelle est la prochaine étape

Avec une compréhension de l'architecture et du cycle de vie, vous êtes prêt à commencer à construire votre infrastructure C2 :