Meilleures pratiques OPSEC¶

Référence complète en matière de sécurité opérationnelle pour les opérateurs de Stentor. Ce guide couvre les surfaces de détection pour chaque grande catégorie de techniques, le pipeline d'obfuscation de garble, la commande de posture d'exécution opsec, une matrice de décision pour la sélection de techniques par environnement et des recommandations opérationnelles depuis le pré-engagement jusqu'au nettoyage.

Surface de détection par catégorie de technique¶

Chaque catégorie de techniques produit des artefacts médico-légaux distincts sur différentes couches de détection (télémétrie des points finaux, surveillance du réseau, analyse des journaux). Les sections ci-dessous mappent les capacités de Stentor à leurs surfaces de détection avec des références spécifiques à MITRE ATT&CK et les mesures d'atténuation recommandées.

Injection de processus¶

Accès aux informations d'identification¶

Mouvement latéral¶

Persistance¶

Évasion de la défense¶

Découverte¶

Les commandes de découverte qui génèrent des processus enfants (commandes shell) sont plus détectables que celles utilisant des API natives ou des BOF. Préférez l’exécution en ligne plutôt que le fork-and-run lorsque cela est possible. Utilisez execute-assembly avec les outils .NET compilés plutôt que les commandes shell pour l'énumération AD.

Pipeline d’obfuscation Garble¶

Garble est l'outil d'obscurcissement au moment de la construction de Stentor pour les binaires Go. Il supprime, crypte ou randomise les artefacts médico-légaux qui rendent les binaires Go identifiables et réversibles. Comprendre ce que Garble corrige et ce qu'il ne peut pas corriger est essentiel pour la planification OPSEC.

Créer un flux de pipeline¶

graph LR
    A[Payload Generation<br/>API / CNA Hook] --> B[garble<br/>-seed=random<br/>-literals -tiny]
    B --> C[ldflags<br/>-s -w -trimpath<br/>-buildid=]
    C --> D[Compiled Binary<br/>EXE / DLL]
    D --> E{Shellcode<br/>Wrapping?}
    E -->|Yes| F[Donut<br/>Position-independent<br/>shellcode]
    E -->|No| G[Final Binary<br/>Obfuscated EXE/DLL]
    F --> H[Final Payload<br/>PE headers stripped]

    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 F fill:#0d47a1,color:#fff
    style H fill:#01579b,color:#fff

Ce que Garble corrige¶

Limitations connues et irréparables¶

Il s’agit d’exigences architecturales du runtime Go. Aucun outil d'obscurcissement ne peut les supprimer sans casser le binaire.

Le pclntab (Tableau des numéros de ligne du compteur de programme) est l'artefact non réparable le plus risqué. Il existe dans chaque binaire Go et contient :

• Octets magiques qui identifient la famille de versions Go (0xFFFFFFF0 pour Go 1.18+, 0xFFFFFFF1 pour Go 1.20+)
• Points d'entrée des fonctions (noms tronqués mais structure intacte)
• Mappages de numéros de ligne du fichier source (chemins supprimés par -trimpath)
• Tailles de cadre de pile pour le déroulement

Des outils comme GoReSym exploitent cette structure pour récupérer les limites des fonctions, même à partir de binaires tronqués. La structure elle-même ne peut pas être supprimée – le runtime Go panique sans elle.

Impact : Tout binaire contenant des octets magiques pclntab peut être identifié comme Go indépendamment de toute autre obscurcissement. Les analystes binaires peuvent récupérer les limites des fonctions (mais pas les noms) et reconstruire le graphe d'appel du programme.

Meilleure atténuation : Enveloppez le binaire tronqué dans le shellcode Donut. Donut convertit le binaire en code indépendant de la position, supprimant entièrement les en-têtes PE et les caractéristiques des sections. Le pclntab existe toujours en mémoire au moment de l'exécution, mais il est chiffré pendant les périodes de veille lorsque le masquage du sommeil est activé.

Modes de construction¶

Outils de détection¶

Guide de l'opérateur¶

• Garble est une évasion, pas une invisibilité. Cela rend l'ingénierie inverse statique beaucoup plus difficile mais ne rend pas un binaire inanalysable. Un analyste déterminé utilisant GoReSym peut toujours récupérer les limites des fonctions.

• Les binaires Go SONT identifiables comme Go. Les octets magiques pclntab sont une exigence architecturale. Aucune dissimulation ne peut changer cela. Si "not Go" est une exigence stricte, utilisez le stager C pour l'accès initial.

• Enveloppez l'implant tronqué dans le chargeur de shellcode. Donut convertit l'EXE tronqué en shellcode indépendant de la position, supprimant entièrement les en-têtes PE et les caractéristiques de section.

• Le masque de sommeil protège au moment de l'exécution. Pendant le sommeil, la section .text est cryptée en mémoire, annulant ainsi l'analyse de la mémoire pour les modèles Go.

• -seed=random signifie que chaque build est unique. Chaque compilation produit un binaire avec différents noms de symboles et clés de cryptage de chaîne, battant ainsi la détection AV basée sur les signatures.

• La détection comportementale EDR est orthogonale au garble. Garble n'affecte que l'analyse statique. Les détections comportementales (séquences d'appels API, modèles de réseau, injection de threads) ne sont pas affectées par l'obscurcissement binaire.

• Le stager C évite entièrement les signatures Go. Le stager MinGW C (~ 23 Ko) télécharge et exécute l'implant complet. Il n'a pas de runtime Go, pas de pclntab, pas de goroutines. Utilisez le stager C lorsque l’accès initial ne doit pas ressembler à Go.

Commande de posture OPSEC d'exécution¶

La commande opsec exécute l'OpsecModule (implant/internal/modules/opsec/opsec.go) et renvoie un rapport de posture noté avec 17 vérifications individuelles. Utilisez-le pour auditer la configuration d'évasion d'un beacon avant d'exécuter des opérations sensibles.

Exécuter la commande¶

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"
  }'

Exemple de sortie¶

[*] OPSEC Posture Report
[*] Score: 71/100

[+] syscall_method: indirect -- APIs routed via ntdll gadgets
[+] sleep_mask: enabled -- .text encrypted during sleep
[+] heap_mask: enabled -- Heap records encrypted during sleep
[!] stack_mask: disabled -- Thread stack visible during sleep
[+] beacon_gate: enabled (25 APIs) -- Sensitive APIs through syscall shim
[!] module_stomp: disabled -- No module stomping (MEM_PRIVATE allocations)
[+] ppid_spoof: explorer.exe -- Child processes spoofed under explorer.exe
[+] spawnto: RuntimeBroker.exe (pool: 7) -- Context-aware rotation
[+] amsi_patched: enabled -- AmsiScanBuffer patched in fork-and-run
[!] etw_patched: disabled -- ETW active in fork-and-run processes
[+] tls_fingerprint: chrome_auto -- uTLS fingerprint spoofing active
[!] sleep_method: direct -- Standard sleep (no timer queue obfuscation)
[+] drip_load_inject: enabled -- Injection memory allocated in small chunks
[+] use_rwx: disabled -- W^X compliant (RW->RX transitions)
[!] udrl: disabled -- Standard reflective loading
[-] edr_hooks: 3 hooked -- Hooked: NtAllocateVirtualMemory, NtWriteVirtualMemory, NtCreateThreadEx -- run edr_unhook
[+] hwbp_status: 2/4 DR slots active -- AMSI/ETW bypass via hardware breakpoints

Recommendations:
  - Consider enabling stack masking for additional sleep protection
  - Configure module stomping DLL for MEM_IMAGE backing
  - Consider timer_queue sleep method for Ekko-style timer-based sleep
  - Consider enabling UDRL for custom reflective loading
  - Run edr_unhook to remove EDR userland hooks before injection/credential operations

Calcul des scores¶

Chacun des 17 contrôles est noté en fonction de son statut :

Formule : score = (sum of points / total checks) * 100

Un score de 100 signifie que les 17 chèques sont dans l'état good. Visez un score minimum de 70 pour les engagements standard et de 85+ pour les environnements à forte intensité EDR.

Les 17 contrôles de posture¶

Matrice de décision : sélection de la technique par environnement¶

Sélectionnez les techniques d'évasion en fonction de la posture défensive de l'environnement cible. La matrice ci-dessous mappe chaque paramètre configurable à trois profils d'environnement.

Profils d'évasion complets¶

Utilisez ces profils copier-coller comme points de départ pour chaque type d'environnement.

sleep 5
syscall-method none

sleep 60 25
syscall-method indirect
sleep_config sleep_mask on
sleep_config heap_mask on
beacon_gate enable
ppid explorer.exe
spawnto x64 %windir%\sysnative\RuntimeBroker.exe
blockdlls start
hwbp both on

sleep 300 40
syscall-method indirect
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
beacon_gate enable
beacon_gate mask_on_call true
ppid explorer.exe
spawnto x64 %windir%\sysnative\dllhost.exe
blockdlls start
hwbp both on
argue net1.exe /enum /domain

Garde-corps d'exécution¶

Les garde-fous d'exécution imposent des limites opérationnelles à l'exécution des beacons. Configurez-les au moment de la génération de le payload pour empêcher les beacons de s'exécuter dans des environnements non autorisés, après les délais d'engagement ou en dehors des fenêtres opérationnelles.

Date de mise à mort¶

Le beacon vérifie la date actuelle par rapport à la date d'élimination configurée à chaque cycle d'interrogation. Après la date d'arrêt, le beacon exécute CleanupArtifacts (supprime les tâches planifiées, les clés de registre et s'auto-supprime), puis se termine.

kill_date: 2026-03-31

Heures de travail¶

Limitez l’activité du beacon à des heures et des jours spécifiques. En dehors de la fenêtre configurée, le beacon calcule le temps restant jusqu'à la prochaine période de travail et se met en veille pendant cette durée dans un seul appel de veille obscurci (et non dans une boucle de vérification-veille rapide).

working_hours: 08:00-18:00
working_days: Mon-Fri
timezone: America/New_York

Le mappage des fuseaux horaires Windows couvre 16 zones communes. Le beacon résout le nom du fuseau horaire Windows en décalage UTC au démarrage.

Géolocalisation¶

Restreindre l’exécution à des environnements réseau spécifiques. Le beacon vérifie ces contraintes au démarrage et revérifie tous les 10 cycles d'interrogation.

{
  "geofence_ips": ["10.10.10.0/24", "192.168.1.0/24"],
  "geofence_hostnames": ["WS01", "WS02"],
  "geofence_domains": ["corp.local"],
  "geofence_usernames": ["labuser"]
}

Détection DNS Canary¶

Configurez un domaine DNS Canary que le beacon résout au démarrage. Si le domaine est résolu (indiquant que le binaire a été soumis à un bac à sable qui résout automatiquement le DNS), le beacon déclenche le point de terminaison Canary et se termine.

dns_canary: canary.yourdomain.com

Le point final du voyage Canary n'est pas authentifié (accessible au relais sans jeton JWT), de sorte que le beacon peut signaler avant même l'enregistrement C2 complet. La résolution Canary utilise net.Resolver (multiplateforme, aucune beacon de build nécessaire).

Vérifications OPSEC préalables à la tâche¶

Lorsque anti_analysis est activé, le beacon exécute des vérifications d'environnement avant d'exécuter des tâches sensibles :

1. Détection EDR - 10 signatures de processus de fournisseurs (CrowdStrike, SentinelOne, Defender, Carbon Black, Cylance, ESET, Kaspersky, Sophos, Trend Micro, Symantec)
2. Indicateurs du bac à sable – Faible nombre de processeurs, faible RAM, installation récente du système d'exploitation, noms d'utilisateur du bac à sable connus
3. Détection du débogueur -- IsDebuggerPresent, NtQueryInformationProcess(ProcessDebugPort)
4. Indicateurs VM – Clés de registre pour VMware/VirtualBox/Hyper-V, préfixes MAC connus

Un seuil d'indicateur 2+ est requis pour le déclenchement (un seul indicateur est ignoré pour réduire les faux positifs). Voir Anti-Analysis pour la configuration d'exécution.

Nettoyage à la sortie¶

Lorsqu'un garde-corps se déclenche ou que la date de mise à mort est atteinte, CleanupArtifacts effectue :

1. Supprime 3 noms de tâches planifiées connues utilisées par la persistance
2. Nettoie 3 modèles de clés de registre utilisés par la persistance
3. Supprime automatiquement le binaire du beacon via un fichier batch (cmd /c del /q /f <path>)

Recommandations opérationnelles¶

Pré-Engagement¶

La sécurité opérationnelle commence avant que la première payload ne touche le réseau cible.

Configuration de l'infrastructure :

• Catégorisation des domaines : Enregistrez les domaines plus de 30 jours avant l'engagement. Soumettez-les aux services de catégorisation (Bluecoat, McAfee, Palo Alto) pour une classification légitime. Les domaines datant de moins de 7 jours sont signalés par la plupart des proxys Web.
• Certificats TLS : Utilisez Let's Encrypt ou achetez des certificats légitimes. Les certificats auto-signés sont signalés par les appareils d'inspection SSL et génèrent des avertissements du navigateur.
• Redirecteurs : Placez les redirecteurs Apache/nginx entre le trafic de l'implant et le serveur d'équipe. Configurez les règles de redirection pour filtrer les sondages des analystes (user-agent, plages IP, timing).
• Profils malléables : utilisez un profil C2 malléable qui imite les modèles de trafic légitimes (Microsoft 365, Slack, CDN). Testez le profil par rapport aux bases de données d'empreintes digitales JA3/JA4.

Tests de payload :

• Construire avec garble : Utilisez toujours obfuscate: true pour les payloads d'engagement. Testez les taux de détection par rapport à l’AV/EDR de la cible dans un environnement miroir.
• Définissez des garde-fous : configurez des garde-fous d'adresse IP, de nom d'hôte, de domaine ou de nom d'utilisateur pour empêcher l'exécution sur les sandbox d'analyste.
• Définissez les dates d'arrêt : Chaque payload d'engagement doit avoir une date d'arrêt définie sur la date de fin de l'engagement plus une période tampon.
• Vérifiez la sortie tronquée : Exécutez strings sur le binaire tronqué pour confirmer qu'il ne reste aucune URL C2 en texte clair, message d'erreur ou chemin de package.

Accès initial¶

La première exécution de le payload est le moment le plus risqué. Un binaire inconnu exécuté pour la première fois déclenche l'analyse la plus agressive.

• Utilisez le stager C pour éviter la signature Go. Le stager MinGW C (~ 23 Ko) n'a pas de runtime Go, pas de pclntab, pas de goroutines. Il télécharge et exécute l'implant complet en mémoire. Utilisez-le lorsque le compte-gouttes initial ne doit pas être identifié comme Go.
• Sélectionnez le transport avec soin. HTTPS avec empreinte digitale uTLS (chrome_auto) est la valeur par défaut la plus sûre. DNS C2 est utile pour les environnements qui bloquent le HTTPS direct mais ont une bande passante inférieure. SMB est destiné uniquement au pivotement interne (pas à l'accès initial).
• Utilisez des profils malléables. Un profil malléable bien configuré fait apparaître le trafic C2 comme HTTPS légitime pour les appareils d'inspection. Sans cela, les modèles HTTP par défaut sont facilement signés.
• Réduisez l'empreinte initiale. Exécutez opsec immédiatement après le premier enregistrement. Appliquez le profil d'évasion approprié avant d'exécuter des commandes post-exploitation.

Post-Exploitation¶

Chaque commande exécutée via le beacon génère des artefacts. Minimisez l’empreinte en choisissant soigneusement les méthodes d’exécution.

• Préférez BOF plutôt que fork-and-run. Les fichiers objets Beacon s'exécutent en ligne dans le processus Beacon : pas de création de processus enfant, pas d'injection, pas de terminaison de processus sacrificiel. Fork-and-run génère un processus enfant visible que EDR surveille.
• Préférez inline-execute à execute-assembly. Pour les outils .NET, l'exécution en ligne évite les artefacts de chargement CLR détectés par le profilage .NET au niveau du processus.
• Gérer les intervalles de veille. Le mode interactif (veille 0) génère un trafic réseau continu. Utilisez sleep 5 pour les opérations actives et revenez à sleep 60+ lorsque vous êtes inactif. La gigue empêche la détection de modèles.
• Surveillez la génération du journal des événements. Chaque technique génère des événements Windows spécifiques. Soyez conscient des événements que votre opération actuelle produit (voir les tableaux des surfaces de détection ci-dessus).

Mouvement latéral¶

Le déplacement entre les systèmes génère des événements d'authentification que les SOC mettent en corrélation dans l'ensemble de l'environnement.

• Évitez de répéter PtH sur la même cible. La transmission du hachage au même système à partir de la même source génère un modèle détecté par la corrélation automatisée. Varier les beacons sources et les techniques.
• Nettoyer les services après PsExec. PsExec crée un service (événement 7045) qui persiste après l'exécution. Supprimez le service immédiatement après utilisation.
• Soyez conscient des horodatages. Les mouvements latéraux en dehors des heures d'ouverture (connexion à 3h00 depuis le poste de travail) génèrent des alertes. Faites correspondre l'activité aux heures d'ouverture prévues pour le compte cible.
• Préférez WMI ou DCOM à PsExec. L'exécution WMI et les abus DCOM génèrent moins d'artefacts distinctifs que l'exécution basée sur les services. WMI est particulièrement efficace car l’activité WMI est courante dans les environnements d’entreprise.
• Utilisez l'usurpation d'identité de jeton pour un contexte légitime. Volez les jetons des processus appartenant aux utilisateurs qui accéderaient légitimement au système cible, puis déplacez-vous latéralement dans ce contexte.

Persistance et longue distance¶

Les opérations de longue durée nécessitent une attention particulière aux modèles de comportement des beacons.

• Gestion des intervalles de sommeil. Les beacons longue distance doivent utiliser des intervalles de sommeil de plus de 300 secondes avec une gigue de 30 à 40 %. Les modèles d'enregistrement lents et faibles sont beaucoup plus difficiles à détecter via la détection des anomalies du réseau.
• Rotation des transports. Si vous travaillez sur plusieurs jours, envisagez une rotation entre les transports (HTTPS vers DNS ou entre différents points de terminaison HTTPS) pour éviter une détection de modèles cohérente.
• Modèles d'enregistrement des beacons. Même en cas de gigue, un beacon qui s'enregistre à des intervalles parfaitement réguliers se démarque. La combinaison sommeil + instabilité crée une variation naturelle, mais sachez que les engagements extrêmement longs peuvent présenter des tendances globales.
• Diversité des mécanismes de persistance. Ne comptez pas sur un seul mécanisme de persistance. Utilisez le détournement de COM (furtif, faible détection) comme tâche principale et une tâche planifiée (fiable, haute détection) comme sauvegarde. Testez la survie de la persistance lors des redémarrages en laboratoire.
• Actualisation des informations d'identification. Les tickets Kerberos et les sessions NTLM expirent. Planifiez des intervalles d'actualisation des informations d'identification et disposez d'une procédure pour obtenir à nouveau l'accès si la persistance survit mais que les informations d'identification mises en cache expirent.

Nettoyage¶

Le nettoyage de l'engagement est une obligation de l'OPSEC. Supprimez ou documentez tous les artefacts laissés sur les systèmes cibles.

Conscience du journal des événements :

Chaque technique génère des événements Windows spécifiques. Événements clés à connaître :

L'effacement du journal des événements de sécurité génère l'événement 1102 (le journal d'audit a été effacé). La suppression sélective (evtdelete) génère toujours l'événement 1102/104 et laisse des espaces vides dans l'ID d'enregistrement. La seule façon d'éviter cela est de ne pas générer l'événement en premier lieu : choisissez des techniques avec des empreintes de journal inférieures.

Suppression des artefacts :

• Supprimez les fichiers supprimés. Supprimez tous les exécutables, DLL ou scripts placés sur le disque. Utilisez timestomp pour restaurer les horodatages d'origine sur les répertoires auxquels vous avez accédé.
• Supprimez les mécanismes de persistance. Supprimez les clés de registre, les tâches planifiées, les services et les entrées de piratage COM. Vérifiez la suppression avec une deuxième vérification.
• Nettoyer les artefacts de service. Les services PsExec, les abonnements WMI et les enregistrements DCOM doivent tous être supprimés.
• Utilisez timestomp pour les opérations sur les fichiers. La commande timestomp (T1070.006) modifie les horodatages des fichiers pour qu'ils correspondent aux fichiers environnants, réduisant ainsi l'efficacité de l'analyse de la chronologie. Voir opérations sur les fichiers pour plus de détails.
• Documentez ce qui ne peut pas être supprimé. Certains artefacts (entrées du journal des événements, traces ETW, enregistrements d'audit au niveau du noyau) ne peuvent pas être supprimés après l'exécution. Documentez-les dans votre rapport de mission afin que le client puisse réinitialiser les références.

Indicateurs de risque du menu contextuel¶

Le menu contextuel du cockpit affiche un point de risque OPSEC coloré à côté de chaque technique, donnant aux opérateurs une évaluation du risque en un coup d'oeil avant l'exécution.

Couleur	Niveau de risque	Signification
	Faible	Énumération passive, lectures de configuration, appels API bénins. Génère une télémétrie minimale. Sûr pour la reconnaissance initiale.
	Moyen	Opérations actives avec empreinte de détection modérée. Fork-and-run, manipulation de tokens, opérations fichiers, contournement UAC, LOLBins.
	Élevé	Opérations touchant des ressources fortement surveillées : LSASS, SAM, NTDS, injection de processus, vol de credentials, PowerShell, opérations destructives. La plupart des EDR les signalent immédiatement.

Les niveaux de risque sont définis dans les métadonnées YAML de la base de connaissances (server/knowledge_base/techniques/) et servis via l'API -- ils ne sont pas codés en dur dans l'interface et peuvent être ajustés par engagement.

Voir le Guide du menu contextuel pour la liste complète des indicateurs visuels incluant les badges de privilège et le filtrage par OS.

Références croisées¶

• Kits d'évasion -- Options d'évasion au moment de la construction, kits personnalisés (artefact, ressource, UDRL, masque de sommeil) et tableau de référence complet des options d'évasion.
• Commandes d'évasion -- Syntaxe des commandes d'évasion d'exécution, exemples d'API et profils recommandés pour chaque commande
• Injection de processus -- Détails de la technique d'injection, méthodes prises en charge et considérations OPSEC par technique
• Accès aux informations d'identification -- Commandes de collecte d'informations d'identification avec conseils OPSEC par technique
• Profils malléables -- OPSEC au niveau du réseau via la mise en forme du trafic, le masquage d'empreintes digitales TLS et la transformation HTTP