Fonctionnalités de transport avancées¶

Au-delà des principaux types d'listeners (HTTP/S, DNS, SMB, QUIC, TCP Bind), l'implant de Stentor comprend une suite de fonctionnalités de transport avancées pour l'évasion, la résilience et la flexibilité. Ces fonctionnalités fonctionnent comme des couches autour ou à côté du transport principal : elles peuvent être combinées pour créer des canaux de communication C2 hautement personnalisés.

DNS sur HTTPS (DoH)¶

DNS sur HTTPS encapsule les requêtes DNS C2 dans les requêtes HTTPS standard adressées aux résolveurs DoH publics (Cloudflare, Google, etc.). Cela contourne la surveillance DNS traditionnelle qui inspecte le trafic brut du port UDP/TCP 53, puisque les requêtes DNS transitent par des connexions HTTPS cryptées vers des points de terminaison bien connus et fiables.

Comment ça marche¶

sequenceDiagram
    participant Implant as Implant (Windows)
    participant DoH as DoH Resolver (e.g., Cloudflare)
    participant DNS as C2 DNS Server
    participant Backend as Backend API

    Note over Implant: Encode C2 data as DNS subdomain labels
    Implant->>DoH: HTTPS POST /dns-query (RFC 8484)
    DoH->>DNS: Standard DNS query to C2 domain
    DNS->>Backend: Forward beacon data
    Backend-->>DNS: Task data in DNS response
    DNS-->>DoH: DNS response (A/AAAA/TXT records)
    DoH-->>Implant: HTTPS response with DNS answer
    Note over Implant: Decode task from DNS records

L'implant construit des requêtes DNS au format filaire (RFC 1035), les enveloppe dans des requêtes HTTPS conformément à la RFC 8484 et les envoie aux résolveurs DoH publics. Le serveur C2 reçoit les requêtes via son serveur DNS faisant autorité et code les réponses dans les enregistrements DNS.

Canaux de données¶

DoH prend en charge trois modes d'enregistrement DNS pour la récupération des tâches, sélectionnables au moment de l'exécution :

Le mode peut être modifié au moment de l'exécution via SetMode(), permettant à l'opérateur de changer de canal de données sans redéployer l'implant.

Configuration¶

Les préfixes de sous-hôte pour différents types de requêtes sont configurables :

Méthodes de demande du DoH¶

Méthode POST (par défaut, selon la spécification Cobalt Strike) : envoie la requête au format filaire DNS comme corps de la requête avec Content-Type: application/dns-message.

Méthode GET : Base64url encode la requête DNS (pas de remplissage, selon RFC 8484) et la place dans le paramètre de requête dns :

GET /dns-query?dns=AAABAAABAAA... HTTP/1.1
Host: cloudflare-dns.com
Accept: application/dns-message

Sélection de serveur à tour de rôle¶

Lorsque plusieurs serveurs DoH sont configurés, le transport utilise une sélection circulaire entre les requêtes. Cela répartit le trafic entre plusieurs résolveurs pour éviter la limitation du débit et réduire le risque qu'un seul résolveur soit signalé.

Considérations OPSEC¶

Domain fronting¶

Le domain fronting achemine le trafic C2 via les réseaux de diffusion de contenu (CDN) en exploitant la différence entre le nom d'hôte TLS SNI et l'en-tête de l'hôte HTTP. Les moniteurs réseau voient une connexion à un domaine CDN légitime, tandis que le CDN achemine la demande vers le serveur C2 réel en fonction de l'en-tête Host.

Comment ça marche¶

sequenceDiagram
    participant Implant as Implant
    participant CDN as CDN Edge (e.g., CloudFront)
    participant C2 as C2 Server

    Note over Implant: TLS SNI = d111111abcdef8.cloudfront.net
    Note over Implant: HTTP Host = c2.attacker.com
    Implant->>CDN: HTTPS connection (SNI: cloudfront.net)
    Note over CDN: Routes based on Host header
    CDN->>C2: Forward request to c2.attacker.com
    C2-->>CDN: C2 response
    CDN-->>Implant: HTTPS response
    Note over Implant: Network monitor sees: cloudfront.net

Le FrontedClient crée des URL ciblant le domaine frontal (https://d111111abcdef8.cloudfront.net/api/v1/c2/beacon) mais définit httpReq.Host = c2.attacker.com pour qu'il achemine via le CDN vers le véritable backend C2.

Configuration¶

Prise en charge des proxys¶

La domain fronting prend en charge la configuration de proxy facultative via NewFrontedClientWithProxy(). Lorsqu'aucun proxy explicite n'est configuré, le transport revient automatiquement à la détection du proxy IE/système sous Windows (voir Détection du proxy IE ci-dessous).

Intégration avec uTLS¶

Le fronting de domaine utilise newUTLSFrontedTransport() qui définit le SNI TLS sur le domaine frontal (et non sur la cible de la connexion). Lorsqu'un tlsFingerprint est spécifié, la négociation TLS utilise un ClientHello correspondant au navigateur tout en gardant le SNI pointé vers le domaine CDN.

Considérations OPSEC¶

Empreinte digitale uTLS¶

La bibliothèque standard crypto/tls de Go produit une empreinte digitale TLS ClientHello distinctive (JA3/JA4) que les outils de sécurité réseau peuvent identifier comme trafic non-navigateur. uTLS remplace la poignée de main TLS par des empreintes digitales correspondant au navigateur à l'aide de la bibliothèque refraction-networking/utls, faisant apparaître les connexions C2 comme un trafic normal du navigateur.

Comment ça marche¶

Au lieu du crypto/tls.Dial de Go, le transport utilise utls.UClient avec un ClientHelloID prédéfini qui reproduit les extensions TLS exactes, les suites de chiffrement et les paramètres de prise de contact d'une version spécifique du navigateur.

Profils d'empreintes digitales pris en charge¶

Variantes de transport¶

uTLS est intégré dans trois constructeurs de transport :

Lorsque fingerprint est vide, tous les constructeurs reviennent au standard Go crypto/tls (pas d'uTLS). L'indicateur DisableCompression: true est toujours défini pour empêcher Go d'injecter Accept-Encoding: gzip qui prendrait l'empreinte du client.

Considérations OPSEC¶

Transport rotatif/de repli¶

Le RotatingTransport encapsule plusieurs instances de transport et gère la sélection des hôtes via des stratégies configurables. Il offre une résilience multi-hôtes, un basculement automatique et une stratégie de sortie lorsque tous les serveurs C2 sont inaccessibles.

Stratégies de rotation¶

Suffixes de durée : s (secondes), m (minutes), h (heures), d (jours).

"round-robin"   -- Cycle through all hosts
"random"        -- Random selection
"failover-5"    -- Switch after 5 failures
"rotate-2h"     -- Switch every 2 hours
"rotate-7d"     -- Switch every 7 days

Stratégie de tentative/sortie maximale¶

Le MaxRetryConfig définit ce qui se passe lorsque tous les hôtes sont inaccessibles :

Format: exit-[max]-[increase]-[duration]

exit-96-48-5m
  |    |   |
  |    |   +-- Escalate sleep interval to 5 minutes
  |    +------ Escalate at 48 consecutive failures
  +----------- Exit implant after 96 consecutive failures

En cas de succès après l'escalade, l'intervalle de veille est automatiquement restauré à sa valeur d'origine.

Mutation de l'hôte (exécution)¶

Les hôtes peuvent être ajoutés, supprimés, conservés ou réinitialisés au moment de l'exécution via la session de l'opérateur :

Récupération de l'hôte en attente¶

Lorsque tous les hôtes sont marqués comme « en attente » (temporairement indisponibles en raison de pannes), le transport libère automatiquement tous les hôtes et réessaye. Cela évite un état de blocage dans lequel aucun hôte n'est disponible.

Rappel de basculement¶

Enregistrez un rappel pour être averti lorsque l'hôte actif change :

rt.SetFailoverCallback(func(fromIndex, toIndex int) {
    log.Printf("Failover: host %d -> host %d", fromIndex, toIndex)
})

Considérations OPSEC¶

Sommeil adaptatif¶

Le AdaptiveTimer ajuste les intervalles de sommeil du beacon en fonction de l'heure et du jour de la semaine. En dehors des heures d'ouverture (nuit et week-end), l'intervalle de veille est multiplié par un facteur configurable, réduisant ainsi la fréquence des beacons lorsque le trafic utilisateur réel est faible et qu'une activité réseau anormale est plus susceptible d'être détectée.

Configuration¶

Calcul du sommeil¶

if (hour < WorkStart OR hour >= WorkEnd OR Saturday OR Sunday):
    sleep = baseSleep * OffHoursMult
else:
    sleep = baseSleep

Exemple avec WorkStart=8, WorkEnd=17, OffHoursMult=3.0, baseSleep=60s :

Considérations OPSEC¶

TCP P2P (liaison peer-to-peer)¶

Le TCPPeerClient permet aux beacons parents de se connecter aux beacons enfants exécutées en mode de liaison TCP. Cela crée des chaînes de relais peer-to-peer pour atteindre des cibles qui n'ont pas d'accès au réseau sortant, en acheminant le trafic C2 via des beacons intermédiaires.

Comment ça marche¶

graph LR
    C2[C2 Server] <-->|HTTPS| Parent[Parent Beacon]
    Parent <-->|TCP P2P| Child[Child Beacon<br/>Bind Mode]
    Child <-->|TCP P2P| Grandchild[Grandchild Beacon<br/>Bind Mode]

    style C2 fill:#f96,stroke:#333
    style Parent fill:#6f9,stroke:#333
    style Child fill:#69f,stroke:#333
    style Grandchild fill:#69f,stroke:#333

Le beacon enfant écoute sur un port TCP (mode liaison). Le beacon parent s'y connecte en utilisant TCPPeerClient et relaie toutes les opérations C2 (enregistrement, récupération de tâches, soumission des résultats) via le protocole de message P2P.

Protocole de messages P2P¶

Toutes les communications utilisent des messages P2P structurés avec des codes de type :

Cycle de vie de la connexion¶

1. Création : NewTCPPeerClient(host, port) -- ne se connecte pas immédiatement
2. Premier enregistrement : La connexion est établie lors du premier appel Checkin()
3. Opérations : GetTask() et SubmitResult() utilisent la connexion TCP établie
4. Démontage : Close() met fin à la connexion P2P

Considérations OPSEC¶

Transport profilé HTTP/2¶

HTTP2ProfiledClient fournit une communication HTTP/2 C2 avec une prise en charge complète des profils malléables. Il applique les mêmes transformations d'URI, d'en-tête et de corps que le ProfiledClient standard mais force le transport HTTP/2 à l'aide de golang.org/x/net/http2.Transport avec la négociation ALPN h2.

HTTP/2 vs HTTP/1.1 profilés¶

Intégration de profils malléables¶

Le transport profilé HTTP/2 utilise la même structure de profil que HTTP/1.1 :

• Checkin/GetTask : Utilise le bloc de profil http-get - transformations de métadonnées, sélection d'URI, types de terminaison (cookie, paramètre, en-tête, corps)
• SubmitResult : Utilise le bloc de profil http-post - transformations de sortie, transformations d'ID, verbe HTTP configurable

Placement des données (types de résiliation) :

Considérations OPSEC¶

Commande d'en-tête¶

Le système de gestion des en-têtes de Stentor supprime les en-têtes HTTP automatiquement injectés par Go et garantit que seuls les en-têtes définis par le profil apparaissent dans les requêtes. Cela évite les empreintes digitales triviales du client C2 en tant qu'application Go.

Problème : les en-têtes par défaut de Go¶

Le net/http de Go injecte automatiquement deux en-têtes qui identifient le client comme non-navigateur :

Solution¶

Deux fonctions gèrent la gestion des en-têtes :

setOrderedHeaders() -- Pour les transports profilés (ProfiledClient, HTTP2ProfiledClient) :

1. Efface tous les en-têtes existants de la requête
2. Définit Accept-Encoding sur nil (supprime l'auto-injection de Go)
3. Applique les en-têtes définis par le profil dans leur ordre déclaré
4. Revient au profil UserAgent uniquement si aucun en-tête de profil ne définit User-Agent

suppressGoDefaults() -- Pour les transports non profilés (FrontedClient, EncryptedClient) :

1. Remplace User-Agent par la valeur configurée
2. Supprime l'auto-injection Accept-Encoding: gzip

Considérations OPSEC¶

Détection du proxy IE (Windows)¶

Sur les cibles Windows, l'implant détecte automatiquement les paramètres de proxy système configurés via les options Internet (IE/WinHTTP). Cela permet au beacon d'acheminer via les serveurs proxy d'entreprise sans configuration manuelle.

Comment ça marche¶

Lors de l'initialisation du transport, lorsqu'aucun proxy explicite n'est configuré, l'implant appelle l'API WinHTTP pour lire les paramètres de proxy IE de l'utilisateur actuel. Il s'agit du même mécanisme que celui utilisé par les navigateurs et les applications Windows pour la découverte de proxy.

Prise en charge des formats de proxy¶

Pour les chaînes proxy par protocole, l'entrée http= est extraite. Si aucune entrée http= n’existe, la première entrée est utilisée comme solution de secours.

Intégration automatique¶

La détection du proxy IE est appelée automatiquement par plusieurs transports lorsqu'aucun proxy explicite n'est fourni :

• NewFrontedClient() -- appelle applyIEProxyFallback(transport)
• NewFrontedClientWithProxy() -- revient au proxy IE lorsque proxyURL est vide
• newUTLSTransportWithProxy() -- revient au proxy IE lorsque proxyURL et fingerprint sont vides

Limites¶

Considérations OPSEC¶

Wrapper de transport chiffré¶

Le EncryptedClient ajoute une couche de cryptage AES-256-GCM au-dessus du transport HTTP. Toutes les payloads C2 (enregistrement, récupération des tâches, soumission des résultats) sont chiffrées de bout en bout entre l'implant et le serveur C2, indépendamment de TLS.

Pourquoi le double cryptage ?¶

Même si un dispositif d'inspection SSL ou un CDN met fin et rechiffre TLS, la couche AES interne protège le payload C2 de l'inspection.

Flux d'échange de clés¶

sequenceDiagram
    participant Implant
    participant C2 as C2 Server

    Implant->>C2: GET /pubkey (fetch RSA public key)
    C2-->>Implant: RSA public key (PEM)
    Note over Implant: Generate AES-256 session key
    Implant->>C2: POST /keyx (RSA-encrypted session key)
    C2-->>Implant: Acknowledgment
    Note over Implant,C2: All subsequent traffic uses AES-256-GCM
    Implant->>C2: POST /beacon {encrypted checkin}
    C2-->>Implant: {encrypted response}

1. L'implant récupère la clé publique RSA du serveur
2. Implant génère une clé de session AES-256 et la chiffre avec la clé RSA du serveur
3. Le serveur déchiffre la clé de session et la stocke pour la session du beacon
4. Toutes les requêtes ultérieures utilisent le cryptage AES-256-GCM

Premier flux d'enregistrement¶

Le premier enregistrement utilise un flux spécial car le beacon n'a pas encore d'ID attribué :

1. Générer un UUID temporaire comme identifiant de session
2. Effectuer un échange de clé avec l'UUID temporaire
3. Envoyer un enregistrement crypté (l'ID du beacon est nul dans le corps)
4. Le serveur attribue un ID de beacon et migre la session de l'UUID temporaire vers l'ID de beacon réel
5. Les requêtes suivantes utilisent l'ID de beacon attribué par le serveur.

Format de demande¶

Les requêtes chiffrées incluent des en-têtes d'identification :

La payload chiffrée est enveloppée dans une enveloppe JSON avec un encodage base64 :

{"data": "base64-encoded-AES-256-GCM-ciphertext"}

Récupération de session¶

Si le serveur redémarre et perd la clé de session (renvoie HTTP 401), le client automatiquement :

1. Invalide la session locale (efface la clé de session et la clé publique mise en cache)
2. Rétablit la session via l'échange de clés
3. Réessaye la requête ayant échoué (une fois, pour éviter les boucles infinies)

Chemins de points de terminaison personnalisés¶

Pour OPSEC, les chemins des points de terminaison d'échange de clés peuvent être personnalisés via SetStagerPaths(pubkeyPath, keyxPath) pour correspondre aux chemins d'étape de profil malléables. Cela évite d'utiliser des chemins par défaut comme /pubkey et /keyx qui pourraient être signés.

Intégration avec uTLS¶

Le client chiffré prend en charge les empreintes digitales uTLS et la configuration du proxy :

• NewEncryptedClient() -- utilise newUTLSTransport(fingerprint, insecureSkipVerify)
• NewEncryptedClientWithProxy() -- utilise newUTLSTransportWithProxy(fingerprint, insecureSkipVerify, proxyURL)

Considérations OPSEC¶

Comparaison des transports¶

Voir aussi¶

• Listeners HTTP/HTTPS -- Configuration de transport HTTP/HTTPS standard
• Listeners DNS -- Transport DNS C2 brut
• Listeners QUIC -- HTTP/3 sur le transport QUIC
• Listeners SMB -- Transport de canalisations nommé pour le mouvement latéral
• TCP Bind Listeners -- Mode de liaison TCP pour la liaison P2P
• Profils malléables -- Mise en forme du trafic basée sur le profil