Wiki pour collecter des ressources de durcissement d'infrastructure Red Team
Cette page wiki est destinée à fournir une ressource pour la mise en place d'une infrastructure Red Team résiliente. Elle a été créée pour compléter la présentation de Steve Borosh (@424f424f) et Jeff Dimmock (@bluscreenofjeff) lors du BSides NoVa 2017, intitulée "Doomsday Preppers: Fortifying Your Red Team Infrastructure" (slides)
Si vous souhaitez apporter une contribution, veuillez soumettre une Pull Request ou signaler un problème sur le dépôt.
MERCI à tous les auteurs du contenu référencé dans ce wiki et à tous ceux qui ont contribué !
Lors de la conception d'une infrastructure Red Team qui doit résister à une réponse active ou durer pour un engagement à long terme (semaines, mois, années), il est important de ségréguer chaque actif en fonction de sa fonction. Cela offre résilience et agilité face à la Blue Team lorsque les actifs de la campagne commencent à être détectés. Par exemple, si l'e-mail de phishing d'une évaluation est identifié, la Red Team n'aurait besoin de créer qu'un nouveau serveur SMTP et un serveur d'hébergement de payloads, plutôt qu'une configuration complète de serveur d'équipe.
Envisagez de ségréguer ces fonctions sur différents actifs :
Chacune de ces fonctions sera probablement requise pour chaque campagne d'ingénierie sociale. Étant donné que la réponse active aux incidents est typique dans une évaluation Red Team, un nouvel ensemble d'infrastructure doit être mis en œuvre pour chaque campagne.
Pour renforcer la résilience et la dissimulation, chaque actif back-end (c'est-à-dire le serveur d'équipe) doit avoir un redirecteur placé devant lui. L'objectif est de toujours avoir un hôte entre notre cible et nos serveurs back-end. La mise en place de l'infrastructure de cette manière rend le déploiement de nouvelle infrastructure beaucoup plus rapide et facile - pas besoin de monter un nouveau serveur d'équipe, de migrer les sessions et de reconnecter les actifs non brûlés sur le back-end.
Types de redirecteurs courants :
Chaque type de redirecteur dispose de multiples options d'implémentation qui conviennent le mieux à différents scénarios. Ces options sont discutées plus en détail dans la section Redirecteurs du wiki. Les redirecteurs peuvent être des hôtes VPS, des serveurs dédiés, ou même des applications exécutées sur une instance Platform-as-a-Service.
Voici un exemple de conception, en gardant à l'esprit la ségrégation fonctionnelle et l'utilisation de redirecteurs :
A Vision for Distributed Red Team Operations - Raphael Mudge (@armitagehacker)
Infrastructure for Ongoing Red Team Operations - Raphael Mudge
Advanced Threat Tactics (2 of 9): Infrastructure - Raphael Mudge
Cloud-based Redirectors for Distributed Hacking - Raphael Mudge
How to Build a C2 Infrastructure with Digital Ocean – Part 1 - Lee Kagan (@invokethreatguy)
Automated Red Team Infrastructure Deployment with Terraform - Part 1 - Rasta Mouse (@_RastaMouse)
La réputation perçue d'un domaine variera considérablement en fonction des produits utilisés par votre cible, ainsi que de leur configuration. Par conséquent, choisir un domaine qui fonctionnera sur votre cible n'est pas une science exacte. La collecte de renseignements en sources ouvertes (OSINT) sera essentielle pour aider à faire une estimation éclairée de l'état des contrôles et des ressources à vérifier pour les domaines. Heureusement, les annonceurs en ligne sont confrontés aux mêmes problèmes et ont créé des solutions que nous pouvons exploiter.
expireddomains.net est un moteur de recherche pour les domaines récemment expirés ou abandonnés. Il fournit une recherche et un filtrage avancé, tels que l'âge de l'expiration, le nombre de backlinks, le nombre de captures Archive.org, le score SimilarWeb. En utilisant le site, nous pouvons enregistrer des domaines pré-utilisés, qui viendront avec un âge de domaine, qui ressemblent à notre cible, ressemblent à notre usurpation, ou simplement sont susceptibles de se fondre dans le réseau de notre cible.
Lors du choix d'un domaine pour le C2 ou l'exfiltration de données, envisagez de choisir un domaine catégorisé comme Finance ou Santé. De nombreuses organisations n'effectueront pas d'interception SSL sur ces catégories en raison de problèmes juridiques ou de sensibilité des données. Il est également important de s'assurer que votre domaine choisi n'est associé à aucune campagne antérieure de malware ou de phishing.
L'outil CatMyFish de Charles Hamilton(@MrUn1k0d3r) automatise les recherches et la vérification de catégorisation web avec expireddomains.net et BlueCoat. Il peut être modifié pour appliquer plus de filtres aux recherches ou même effectuer une surveillance à long terme des actifs que vous enregistrez.
Un autre outil, DomainHunter de Joe Vest (@joevest) et Andrew Chiles (@andrewchiles), renvoie la catégorisation BlueCoat/WebPulse, IBM X-Force et Cisco Talos, l'âge du domaine, les TLD alternatifs disponibles, les liens Archive.org et un rapport HTML. De plus, il effectue des vérifications pour l'utilisation dans des campagnes connues de malware et de phishing à l'aide de Malwaredomains.com et MXToolBox. Cet outil inclut également la prise en charge OCR pour contourner les captchas BlueCoat/WebPulse. Consultez le billet de blog sur la version initiale de l'outil pour plus de détails.
Encore un autre outil, AIRMASTER de Max Harley (@Max_68) utilise expireddomains.net et Bluecoat pour trouver des domaines catégorisés. Cet outil utilise l'OCR pour contourner le captcha BlueCoat, augmentant ainsi la vitesse de recherche.
Si un domaine précédemment enregistré n'est pas disponible ou si vous préférez un domaine auto-enregistré, il est possible de catégoriser les domaines vous-même. En utilisant les liens directs ci-dessous ou un outil comme Chameleon de Dominic Chell (@domchell). La plupart des produits de catégorisation ignoreront les redirections ou le contenu cloné lors de la détermination de la catégorisation du domaine. Pour plus d'informations sur l'utilisation de Chameleon, consultez le billet de Dominic Categorisation is not a security boundary.
Enfin, assurez-vous que vos paramètres DNS se sont correctement propagés.
Les mots facile et phishing ne semblent jamais vraiment aller ensemble. La mise en place d'une infrastructure de phishing appropriée peut être un véritable casse-tête. Le tutoriel suivant vous fournira les connaissances et les outils pour configurer rapidement un serveur de phishing qui passe "la plupart" des filtres anti-spam à ce jour et vous fournit une interface RoundCube pour une expérience de phishing facile, y compris les communications bidirectionnelles avec votre cible. Il existe de nombreuses configurations et publications sur le phishing. Ce n'est qu'une méthode.
Une fois que vous avez un domaine qui passe les vérifications appropriées listées dans la section précédente et que votre serveur de phishing est opérationnel, vous devrez créer quelques enregistrements "A" pour votre domaine comme illustré.
Ensuite, connectez-vous en SSH à votre serveur de phishing et assurez-vous d'avoir un nom d'hôte FQDN approprié listé dans votre /etc/hosts. Exemple "127.0.0.1 email.yourphishingserver.com email localhost"
Maintenant, vous allez installer le front-end web pour phisher en quelques étapes simples. Commencez par télécharger la dernière version "BETA" de iRedMail sur votre serveur de phishing. Le moyen le plus simple est de cliquer avec le bouton droit sur le bouton de téléchargement, de copier l'adresse du lien, d'utiliser wget pour télécharger directement sur votre serveur de phishing. Ensuite, décompressez-le "tar -xvf iRedMail-0.9.8-beta2.tar.bz2". Naviguez dans le dossier décompressé et rendez le script iRedMail.sh exécutable (chmod +x iRedMail.sh). Exécutez le script en tant que root, suivez les invites, et vous devrez redémarrer pour terminer le tout.
Vous voudrez vous assurer d'avoir tous les enregistrements DNS appropriés pointant vers votre serveur de messagerie. (https://docs.iredmail.org/setup.dns.html). Pour DKIM, la nouvelle commande devrait être "amavisd-new showkeys" pour lister votre clé DKIM.
Pour DMARC, nous pouvons utiliser (https://www.unlocktheinbox.com/dmarcwizard/) pour générer notre entrée dmarc.
Maintenant, créez un utilisateur pour phisher.
Connectez-vous à l'interface RoundCube avec votre nouvel utilisateur et phishez de manière responsable !
Cobalt Strike fournit des fonctionnalités de spearphishing personnalisables pour soutenir le phishing par e-mail lors de tests d'intrusion ou d'engagements Red Team. Il prend en charge les modèles en HTML et/ou en texte brut, les pièces jointes, une adresse de rebond, l'intégration d'URL, l'utilisation d'un serveur SMTP distant et des délais d'envoi par message. Une autre fonctionnalité intéressante est la possibilité d'ajouter un jeton unique à l'URL intégrée de chaque utilisateur pour le suivi des clics.
Pour des informations plus détaillées, consultez ces ressources :
Pour les exercices de red-team et de phishing où la confiance du client et l'OPSEC comptent, conserver les données client capturées et l'infrastructure principale sur les propres serveurs du client (sur site) offre des avantages significatifs par rapport aux solutions uniquement cloud. Cette approche utilise les actifs cloud uniquement pour des redirecteurs et des fronts légers tout en maintenant les opérations sensibles en interne.
Une configuration Evilginx sur site robuste comprend généralement :
Le filtrage par cookie réduit les hits de bots et l'analyse automatisée en exigeant un cookie spécifique pour accéder au portail de phishing :``` (http.host eq "portal.example.com") and (not http.cookie contains "session_token=abc123def456") and not (http.host eq "landing.example.com" and http.request.uri.path eq "/favicon.ico")
Cette règle redirige les requêtes vers le domaine du portail qui ne contiennent pas le cookie requis, tout en exemptant les requêtes de favicon pour éviter les boucles de redirection.
### Exemple de configuration Caddy```caddyfile
# Redirect direct IP access to prevent fingerprinting
1.2.3.4 {
redir https://legitimate-site.com{uri} permanent
}
landing.example.com {
log {
output file /var/log/caddy/landing_access.log
format console
}
tls internal
encode gzip
reverse_proxy http://127.0.0.1:8000
}
portal.example.com {
log {
output file /var/log/caddy/portal_access.log
format console
}
tls internal
encode gzip
reverse_proxy https://evilginx:443 {
transport http {
versions 1.1
tls_insecure_skip_verify
tls_server_name portal.example.com
}
header_up Host portal.example.com
header_up X-Forwarded-Proto https
}
}
Exécutez Evilginx sur le nœud interne avec les indicateurs appropriés :```bash ./evilginx2 -p ./phishlets -t ./redirectors -developer -debug
**Important :** Evilginx ne doit être accessible que depuis le réseau privé ; ne publiez jamais son IP dans un DNS public.
### Liste de contrôle OPSEC et durcissement
1. **N'exposez jamais les IP d'Evilginx dans un DNS public** - Utilisez uniquement un réseau privé
2. **Conservez les données sensibles uniquement sur les serveurs clients** - Les redirecteurs ne doivent pas stocker les identifiants capturés
3. **Durcissez les redirecteurs** - Alternez les domaines, utilisez des TTL courts, déployez plusieurs redirecteurs éphémères
4. **Implémentez des règles WAF/pare-feu** - Utilisez des vérifications de cookies, des listes blanches d'IP ou une validation de l'UA
5. **Séparez la journalisation et la conservation** - Conservez les journaux d'accès sur Caddy et les journaux de capture sur l'hôte Evilginx
6. **Évitez les empreintes** - N'utilisez pas de schémas prévisibles ni d'empreintes TLS identiques
Cette approche hybride (redirecteur public/capture privée) offre la résilience du cloud fronting tout en conservant les avantages sécuritaires et juridiques du maintien des opérations sensibles sur site.
## Frameworks de phishing
Au-delà de la mise en place de votre propre dispositif de phishing ou de l'utilisation d'un framework de pentest ou de red team, comme Cobalt Strike, il existe de nombreux outils et frameworks dédiés au phishing par e-mail. Bien que ce wiki n'entre pas dans le détail de chaque framework, quelques ressources pour chacun sont rassemblées ci-dessous :
### Gophish
* [Site officiel de Gophish](https://getgophish.com/)
* [Dépôt GitHub de Gophish](https://github.com/gophish/gophish)
* [Guide utilisateur de Gophish](https://www.gitbook.com/book/gophish/user-guide/details)
### Phishing Frenzy
* [Site officiel de Phishing Frenzy](https://www.phishingfrenzy.com/)
* [Dépôt GitHub de Phishing Frenzy](https://github.com/pentestgeek/phishing-frenzy)
* [Présentation de Phishing Frenzy - Brandon McCann (@zeknox)](https://www.pentestgeek.com/phishing/introducing-phishing-frenzy)
### The Social-Engineer Toolkit
* [Dépôt GitHub de The Social-Engineer Toolkit](https://github.com/trustedsec/social-engineer-toolkit)
* [Manuel utilisateur de The Social-Engineer Toolkit](https://github.com/trustedsec/social-engineer-toolkit/raw/master/readme/User_Manual.pdf)
### FiercePhish (anciennement FirePhish)
* [Dépôt GitHub de FiercePhish](https://github.com/Raikia/FiercePhish)
* [Wiki de FiercePhish](https://github.com/Raikia/FiercePhish/wiki)
# Redirecteurs
## SMTP
« Redirecteur » n'est peut-être pas le meilleur mot pour décrire ce que nous allons accomplir, mais l'objectif est le même que pour nos autres redirections. Nous voulons supprimer toute trace de l'origine de notre phishing des en-têtes d'e-mail finaux et fournir un tampon entre la victime et notre serveur backend. Idéalement, le redirecteur SMTP doit être rapide à configurer et facile à décommissionner.
Il y a deux actions clés que nous voulons configurer pour qu'un redirecteur SMTP exécute :
### Sendmail
#### Supprimer les en-têtes de serveur précédents
Ajoutez la ligne suivante à la fin de `/etc/mail/sendmail.mc` :```bash
define(`confRECEIVED_HEADER',`by $j ($v/$Z)$?r with $r$. id $i; $b')dnl
Ajoutez à la fin de /etc/mail/access :```bash
IP-to-Team-Server TAB RELAY
Phish-Domain TAB RELAY
[Removing Sender’s IP Address From Email’s Received From Header](https://www.devside.net/wamp-server/removing-senders-ip-address-from-emails-received-from-header)
[Removing Headers from Postfix setup](https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/)
#### Configurer une adresse catch-all
Cela relaiera tout e-mail reçu à *@phishdomain.com vers une adresse e-mail choisie. C'est très utile pour recevoir les réponses ou les rebonds d'un e-mail de phishing.```bash
echo PHISH-DOMAIN >> /etc/mail/local-host-names
Ajoutez la ligne suivante juste avant //Mailer Definitions// (vers la fin) de /etc/mail/sendmail.mc :```bash
FEATURE(virtusertable', hash -o /etc/mail/virtusertable.db')dnl
Ajoutez la ligne suivante à la fin de `/etc/mail/virtusertable` :```bash
@phishdomain.com external-relay-address
Note : Les deux champs doivent être séparés par des tabulations
Postfix offre une alternative plus simple à sendmail avec une meilleure compatibilité. Postfix propose également un support IMAP complet avec Dovecot. Cela permet aux testeurs de correspondre en temps réel avec les cibles de phishing qui répondent au message d'origine, plutôt que de dépendre de l'adresse de rattrapage et de devoir créer un nouveau message à l'aide de votre outil de phishing.
Un guide complet pour configurer un serveur de messagerie Postfix pour le phishing est disponible dans l'article de Julian Catrambone (@n0pe_sled) Mail Servers Made Easy.
Note : Lors de l'utilisation de redirecteurs C2, un listener externe doit être configuré sur votre framework de post-exploitation pour envoyer le trafic de staging via le domaine du redirecteur. Cela amènera la machine compromise à effectuer son staging via le redirecteur, comme pour le trafic C2 lui-même.
socat peut être utilisé pour rediriger les paquets DNS entrants sur le port 53 vers notre serveur d'équipe. Bien que cette méthode fonctionne, certains utilisateurs ont signalé des problèmes de staging avec Cobalt Strike et/ou des problèmes de latence avec cette méthode. Modifié le 21/04/2017 : La commande socat suivante semble bien fonctionner grâce aux tests de @xorrior :``` socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto::53; echo -ne
[Redirecting Cobalt Strike DNS Beacons - Steve Borosh](https://medium.com/rvrsh3ll/redirecting-cobalt-strike-dns-beacons-e3dcdb5a8b9b)
### iptables pour DNS
Les règles de redirection DNS iptables se sont avérées bien fonctionner avec Cobalt Strike. Il ne semble pas y avoir les problèmes que socat rencontre avec ce type de trafic.
Un exemple de jeu de règles de redirection DNS est fourni ci-dessous.```bash
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <IP-GOES-HERE>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
Aussi, changez la politique de chaîne "FORWARD" en "ACCEPT"
Certains peuvent avoir l'exigence ou le besoin d'héberger un serveur c2 sur un réseau interne. En utilisant une combinaison d'IPTABLES, de SOCAT et de tunnels SSH inversés, nous pouvons certainement y parvenir de la manière suivante.
Dans ce scénario, nous avons notre redirecteur volatile utilisant IPTables pour transférer tout le trafic DNS en utilisant la règle d'exemple décrite précédemment dans cette section. Ensuite, nous créons un tunnel de redirection de port SSH inversé depuis notre serveur c2 interne vers notre redirecteur principal. Cela transférera tout le trafic que le redirecteur principal reçoit sur le port 6667 vers le serveur c2 interne sur le port 6667. Maintenant, démarrez socat sur notre serveur d'équipe pour dupliquer tout le trafic TCP entrant sur le port 6667 vers le port UDP 53, qui est ce sur quoi notre c2 DNS doit écouter. Enfin, nous configurons de manière similaire une instance socat sur le redirecteur principal pour rediriger tout le trafic UDP entrant sur le port 53 vers notre tunnel SSH sur le port 6667.
Remarque : lors de l'utilisation de redirecteurs C2, un écouteur externe doit être configuré sur votre framework de post-exploitation pour envoyer le trafic de staging via le domaine du redirecteur. Cela amènera l'hôte compromis à effectuer le staging via le redirecteur comme le trafic C2 lui-même.
socat fournit une redirection de type « tuyau passif ». Toute requête que socat reçoit sur l'interface/le port source spécifié est redirigée vers l'adresse IP/le port de destination. Il n'y a aucun filtrage ni redirection conditionnelle. Apache mod_rewrite, en revanche, fournit un certain nombre de méthodes pour renforcer votre phishing et augmenter la résilience de votre infrastructure de test. mod_rewrite a la capacité d'effectuer une redirection conditionnelle basée sur les attributs de la requête, tels que l'URI, l'agent utilisateur, la chaîne de requête, le système d'exploitation et l'adresse IP. Apache mod_rewrite utilise des fichiers htaccess pour configurer des ensembles de règles définissant comment Apache doit gérer chaque requête entrante. En utilisant ces règles, vous pourriez, par exemple, rediriger les requêtes vers votre serveur avec l'agent utilisateur wget par défaut vers une page légitime du site web de votre cible.
En bref, si votre redirecteur doit effectuer une redirection conditionnelle ou un filtrage avancé, utilisez Apache mod_rewrite. Sinon, une redirection socat avec un filtrage iptables optionnel suffira.
socat peut être utilisé pour rediriger tout paquet TCP entrant sur un port spécifié vers notre serveur d'équipe.
La syntaxe de base pour rediriger le port TCP 80 sur localhost vers le port 80 sur un autre hôte est :``` socat TCP4-LISTEN:80,fork TCP4::80
Si votre redirecteur est configuré avec plus d'une interface réseau, socat peut être lié à une interface spécifique, par adresse IP, avec la syntaxe suivante :```
socat TCP4-LISTEN:80,bind=10.0.0.2,fork TCP4:1.2.3.4:80
Dans cet exemple, 10.0.0.2 est l'une des adresses IP locales du redirecteur et 1.2.3.4 est l'adresse IP du serveur d'équipe distant.
En plus de socat, iptables peut effectuer une redirection « tuyau passif » via NAT. Pour transférer le port local 80 du redirecteur vers un hôte distant, utilisez la syntaxe suivante :``` iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
### SSH pour HTTP
Nous avons précédemment abordé l'utilisation de SSH pour les tunnels DNS. SSH constitue un moyen solide et robuste de franchir le NAT et d'obtenir un moyen pour l'implant de se connecter à un redirecteur puis à votre environnement serveur. Avant de configurer un redirecteur SSH, vous devez ajouter les lignes suivantes à `/etc/ssh/sshd_config` :```text
# Allow the SSH client to specify which hosts may connect
GatewayPorts yes
# Allow both local and remote port forwards
AllowTcpForwarding yes
Pour rediriger le port local 80 du redirecteur vers votre serveur interne, utilisez la syntaxe suivante sur le serveur interne :``` tmux new -S redir80 ssh -R *:80:localhost:80 Ctrl+B, D
Vous pouvez également rediriger plusieurs ports à la fois, par exemple si vous souhaitez que les ports 443 et 80 soient ouverts simultanément :```
tmux new -S redir80443
ssh <redirector> -R *:80:localhost:80 -R *:443:localhost:443
Ctrl+B, D
Lors de la distribution de charges utiles et de ressources web, nous cherchons à minimiser la capacité des intervenants en réponse à incident à examiner les fichiers et à augmenter les chances d'exécuter avec succès la charge utile, que ce soit pour établir un C2 ou recueillir des renseignements.
Utilisation et exemples d'Apache Mod_Rewrite par Jeff Dimmock :
Autres utilisations et exemples d'Apache mod_rewrite :
Pour configurer automatiquement Apache Mod_Rewrite sur un serveur redirecteur, consultez l'article de blog de Julain Catrambone (@n0pe_sled) Configuration automatique de Mod_Rewrite et l'outil associé.
L'intention derrière la redirection du trafic C2 est double : masquer le serveur d'équipe backend et paraître comme un site web légitime si un intervenant en réponse à incident y accède. Grâce à Apache mod_rewrite et aux profils C2 personnalisés ou à d'autres proxys (comme avec Flask), nous pouvons filtrer de manière fiable le véritable trafic C2 du trafic d'investigation.
En s'appuyant sur la « Redirection C2 » ci-dessus, une autre méthode consiste à faire utiliser par votre serveur redirecteur le moteur SSL Proxy d'Apache pour accepter les requêtes SSL entrantes, et les rediriger vers un écouteur HTTPS inversé. Le chiffrement est utilisé à toutes les étapes, et vous pouvez faire pivoter les certificats SSL sur votre redirecteur selon vos besoins.
Pour que cela fonctionne avec vos règles mod_rewrite, vous devez placer vos règles dans « /etc/apache2/sites-available/000-default-le-ssl.conf » en supposant que vous avez utilisé LetsEncrypt (alias CertBot) pour installer votre certificat. De plus, pour activer le moteur SSL ProxyPass, vous aurez besoin des lignes suivantes dans ce même fichier de configuration :```bash
SSLProxyEngine On
ProxyPass / https://DESTINATION_C2_URL:443/ ProxyPassReverse / https://DESTINATION_C2_URL:443/
SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
### Autres ressources Apache mod_rewrite
* [Automatisation des profils Apache mod_rewrite et Cobalt Strike](https://posts.specterops.io/automating-apache-mod-rewrite-and-cobalt-strike-malleable-c2-profiles-d45266ca642)
* [mod-rewrite-cheatsheet.com](http://mod-rewrite-cheatsheet.com/)
* [Documentation officielle Apache 2.4 mod_rewrite](http://httpd.apache.org/docs/current/rewrite/)
* [Introduction à Apache mod_rewrite](https://httpd.apache.org/docs/2.4/en/rewrite/intro.html)
* [Guide approfondi de mod_rewrite pour Apache](http://code.tutsplus.com/tutorials/an-in-depth-guide-to-mod-rewrite-for-apache--net-6708)
* [Vérificateur de syntaxe Mod_Rewrite/.htaccess](http://www.htaccesscheck.com/)
# Modification du trafic C2
## Cobalt Strike
Cobalt Strike modifie son trafic à l'aide de profils Malleable C2. Les profils offrent des options hautement personnalisables pour modifier l'apparence du trafic C2 de votre serveur sur le réseau. Les profils Malleable C2 peuvent être utilisés pour renforcer l'évasion lors de la réponse à incident, imiter des adversaires connus ou se faire passer pour des applications internes légitimes utilisées par la cible.
* [Profils Malleable C2 officiels - GitHub](https://github.com/rsmudge/Malleable-C2-Profiles)
* [Documentation Malleable Command and Control - cobaltstrike.com](https://www.cobaltstrike.com/help-malleable-c2)
* [Cobalt Strike 2.0 - Malleable Command and Control - Raphael Mudge](http://blog.cobaltstrike.com/2014/07/16/malleable-command-and-control/)
* [Cobalt Strike 3.6 - A Path for Privilege Escalation - Raphael Mudge](http://blog.cobaltstrike.com/2016/12/08/cobalt-strike-3-6-a-path-for-privilege-escalation/)
* [A Brave New World: Malleable C2 - Will Schroeder (@harmj0y)](http://www.harmj0y.net/blog/redteaming/a-brave-new-world-malleable-c2/)
* [How to Write Malleable C2 Profiles for Cobalt Strike - Jeff Dimmock](https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/)
* [In-Memory Evasion (série de vidéos) - Raphael Mudge](https://www.youtube.com/watch?v=lz2ARbZ_5tE&list=PL9HO6M_MU2nc5Q31qd2CwpZ8J4KFMhgnK)
Lorsque vous commencez à créer ou à modifier des profils Malleable C2, il est important de garder à l'esprit les limites de taille des données pour le placement des informations Beacon. Par exemple, configurer le profil pour envoyer de grandes quantités de données dans un paramètre d'URL nécessitera de nombreuses requêtes. Pour plus d'informations à ce sujet, consultez l'article de blog de Raphael Mudge [Beware of Slow Downloads](https://blog.cobaltstrike.com/2018/03/09/beware-of-slow-downloads/).
Si vous rencontrez des problèmes avec votre profil Malleable C2 et remarquez que la console teamserver affiche des erreurs, reportez-vous à l'article de blog de Raphael Mudge [Broken Promises and Malleable C2 Profiles](https://blog.cobaltstrike.com/2018/06/04/broken-promises-and-malleable-c2-profiles/) pour des conseils de dépannage.
## Empire
Empire utilise des profils de communication, qui offrent des options de personnalisation pour les URI de requêtes GET, le user agent et les en-têtes. Le profil se compose de chaque élément, séparé par le caractère pipe, et défini avec l'option `set DefaultProfile` dans le menu contextuel `listeners`.
Voici un exemple de profil par défaut :```bash
"/CWoNaJLBo/VTNeWw11212/|Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)|Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*|Accept-Language:en-en"
Alternative, la valeur DefaultProfile peut être définie en modifiant le fichier /setup/setup_database.py avant la configuration initiale d’Empire. Cela modifiera le profil de communication par défaut qu’Empire utilisera.
En plus du profil de communication, pensez à personnaliser les URI de staging du serveur Empire, les en-têtes du serveur et le contenu de la page web par défaut en suivant les étapes présentées dans l’article de Joe Vest (@joevest) Empire - Modifying Server C2 Indicators.
Tirer parti de services web légitimes et de confiance pour le C2 peut offrir un avantage précieux par rapport à l’utilisation de domaines et d’infrastructures que vous avez configurés vous-même. Le temps et la complexité de configuration varient selon la technique et le service utilisés. Un exemple populaire d’utilisation de services tiers pour la redirection C2 est le Domain Fronting.
Le Domain Fronting est une technique utilisée par les services et applications d’évasion de la censure pour acheminer le trafic via des domaines légitimes et hautement fiables. Les services populaires prenant en charge le Domain Fronting incluent Google App Engine, Amazon CloudFront et Microsoft Azure. Il est important de noter que de nombreux fournisseurs, comme Google et Amazon, ont mis en place des mesures d’atténuation contre le Domain Fronting. Certaines ressources liées ou informations fournies dans ce wiki peuvent donc être obsolètes au moment où vous tenterez de les utiliser.
En résumé, le trafic utilise le nom DNS et SNI du fournisseur de services de confiance, Google étant utilisé dans l’exemple ci-dessous. Lorsque le trafic est reçu par le serveur périphérique (ex. : situé à gmail.com), le paquet est transmis au serveur d’origine (ex. : phish.appspot.com) spécifié dans l’en-tête Host du paquet. Selon le fournisseur de services, le serveur d’origine transmettra directement le trafic à un domaine spécifié, que nous pointerons vers notre serveur d’équipe, ou une application proxy sera nécessaire pour effectuer le dernier saut de transfert.
Pour des informations plus détaillées sur le fonctionnement du Domain Fronting, consultez le livre blanc Blocking-resistant communication through domain fronting et la documentation meek du projet TOR.
En plus des domaines frontables standard, tels que tout domaine google.com, il est possible de tirer parti d’autres domaines légitimes pour le fronting.
Pour plus d’informations sur la recherche de domaines frontables, consultez :
De nombreux fournisseurs PaaS et SaaS fournissent un sous-domaine ou une URL statique pour une instance provisionnée. Si le domaine associé est généralement hautement fiable, les instances peuvent apporter une confiance supplémentaire à votre infrastructure C2 par rapport à un domaine acheté et un VPS.
Pour configurer la redirection, vous devrez identifier un service qui émet un sous-domaine ou une URL statique dans le cadre d’une instance. Ensuite, l’instance devra être configurée avec une redirection basée sur le réseau ou l’application. L’instance agira comme un proxy, similaire aux autres redirecteurs abordés dans ce wiki.
Une autre technique intéressante qui mérite des recherches supplémentaires est l’utilisation de compartiments Amazon S3 trop permissifs pour le C2. Consultez l’article S3 Buckets for Good and Evil d’Andrew Luke (@Sw4mp_f0x) pour plus de détails sur la façon dont les compartiments S3 pourraient être utilisés pour le C2. Cette technique pourrait être combinée avec les capacités C2 tierces d’Empire pour utiliser les compartiments S3 légitimes de la cible contre elle.
Pour un autre exemple d’utilisation de PaaS pour le C2, consultez Databases and Clouds: SQL Server as a C2 de Scott Sutherland (@_nullbind).
D’autres services tiers ont été utilisés dans la nature pour le C2 par le passé. Tirer parti de sites web tiers qui permettent la publication ou la modification rapide de contenu généré par les utilisateurs peut vous aider à contourner les contrôles basés sur la réputation, surtout si le site tiers est généralement fiable.
Consultez ces ressources pour d’autres options de C2 tiers :
L’infrastructure d’attaque est souvent facile à identifier, apparaissant comme une coquille de serveur légitime. Nous devrons prendre des mesures supplémentaires avec notre infrastructure pour augmenter les chances de se fondre parmi les serveurs réels, que ce soit au sein de l’organisation cible ou des services que la cible pourrait raisonnablement utiliser.
Les redirecteurs peuvent aider à se fondre en redirigeant les URI invalides, en faisant expirer les liens de payloads de phishing, ou en bloquant les techniques courantes des intervenants en réponse aux incidents ; cependant, une attention particulière doit également être portée à l’hôte sous-jacent et à ses indicateurs.
Par exemple, dans l’article Fall of an Empire, John Menerick (@Lord_SQL) couvre les méthodes pour détecter les serveurs Empire sur Internet.
Pour contrer ces indicateurs et d’autres similaires, il est judicieux de modifier les modèles de trafic C2, de modifier les pages d’accueil du serveur, de restreindre les ports ouverts et de modifier les en-têtes de réponse par défaut.
Pour plus de détails sur la façon de procéder et d’autres tactiques pour plusieurs frameworks d’attaque, consultez ces articles :
L’infrastructure d’attaque peut être attaquée tout comme n’importe quel autre hôte connecté à Internet, et elle doit être considérée comme TRÈS sensible en raison des données utilisées et des connexions vers les environnements cibles.
En 2016, des vulnérabilités d’exécution de code à distance ont été divulguées sur les outils d’attaque les plus courants :
iptables doit être utilisé pour filtrer le trafic indésirable et restreindre le trafic entre les éléments d’infrastructure requis. Par exemple, si un serveur d’équipe Cobalt Strike ne sert des ressources qu’à un redirecteur Apache, les règles iptables ne doivent autoriser que le port 80 depuis l’IP source du redirecteur. Cela est particulièrement important pour toute interface de gestion, comme SSH ou le port par défaut 50050 de Cobalt Strike. Pensez également à bloquer les IP de pays non ciblés. En alternative, envisagez d’utiliser les pare-feu d’hyperviseur fournis par vos fournisseurs VPS. Par exemple, Digital Ocean propose des Cloud Firewalls qui peuvent protéger un ou plusieurs droplets.
chattr peut être utilisé sur les serveurs d’équipe pour empêcher la modification des répertoires cron. Avec chattr, vous pouvez restreindre tout utilisateur, y compris root, de modifier un fichier jusqu’à ce que l’attribut chattr soit supprimé.
SSH doit être limité à l’authentification par clé publique uniquement et configuré pour utiliser des utilisateurs à droits limités pour la connexion initiale. Pour une sécurité accrue, envisagez d’ajouter une authentification multifacteur à SSH.
Mise à jour ! Aucune liste de sécurisation n’est complète sans un rappel de mettre régulièrement à jour les systèmes et d’appliquer les correctifs nécessaires pour remédier aux vulnérabilités.
Bien sûr, cette liste n’est pas exhaustive de ce que vous pouvez faire pour sécuriser un serveur d’équipe. Suivez les pratiques courantes de durcissement sur toute l’infrastructure :
Il existe un certain nombre de ressources en ligne traitant de la configuration et de la conception sécurisées des infrastructures. Toutes les considérations de conception ne seront pas appropriées pour chaque infrastructure d’attaque, mais il est utile de savoir quelles options sont disponibles et ce que font les autres testeurs.
Voici certaines de ces ressources :
Les sujets abordés dans ce wiki renforcent les infrastructures d’attaque, mais nécessitent généralement beaucoup de temps pour être conçus et mis en œuvre. L’automatisation peut être utilisée pour réduire considérablement les temps de déploiement, vous permettant de déployer des configurations plus complexes en moins de temps.
Consultez ces ressources sur l’automatisation de l’infrastructure d’attaque :
Documentez tout - Gérer une infrastructure Red Team complexe implique de nombreuses pièces mobiles. Assurez-vous de documenter la fonction de chaque ressource et où son trafic est envoyé.
Répartissez les ressources entre différents fournisseurs de services et régions - Les ressources d’infrastructure doivent être réparties entre plusieurs fournisseurs de services et régions géographiques. Les membres de l’équipe bleue peuvent augmenter les seuils de surveillance contre les fournisseurs identifiés comme menant activement une attaque et peuvent même bloquer complètement un fournisseur de services donné. Remarque : gardez à l’esprit les lois internationales sur la confidentialité si vous envoyez des données chiffrées ou sensibles au-delà des frontières.
N’en faites pas trop - Il est facile de s’enthousiasmer pour des techniques avancées et de vouloir tout jeter sur une cible. Si vous émulez une menace adverse spécifique, n’utilisez que les techniques employées par le véritable acteur de la menace ou des techniques relevant des compétences de cet acteur. Si vos tests Red Team attaquent la même cible à long terme, envisagez de commencer « simple » et de progresser vers des techniques plus avancées au fil de vos évaluations. Faire évoluer les techniques de l’équipe rouge parallèlement à celles de l’équipe bleue fera constamment progresser l’organisation, alors que frapper l’équipe bleue avec tout à la fois peut la submerger et ralentir le processus d’apprentissage.
Surveillez les journaux - Tous les journaux doivent être surveillés tout au long de l’engagement : journaux SMTP, journaux Apache, tcpdump sur les redirecteurs socat, journaux iptables (spécifiques au transfert de trafic ou au filtrage ciblé), journaux web, journaux Cobalt Strike/Empire/MSF. Transférez les journaux vers un emplacement central, par exemple avec rsyslog, pour une surveillance plus facile. La conservation des données du terminal de l’opérateur peut s’avérer utile pour examiner l’utilisation historique des commandes lors d’une opération. @Killswitch_GUI a créé un programme facile à utiliser nommé lTerm qui journalise toutes les commandes du terminal bash vers un emplacement central. Journalisez toute la sortie du terminal avec lTerm. Consultez l’article de Vincent Yiu CobaltSplunk pour un exemple d’envoi des journaux Cobalt Strike vers Splunk pour une surveillance et une analyse avancées de l’infrastructure.* Implémenter l'alerte sur les événements à forte valeur - Configurez l'infrastructure d'attaque pour générer des alertes sur les événements à forte valeur, comme les nouvelles sessions C2 ou les captures d'identifiants. Une méthode populaire pour implémenter l'alerte passe par l'API d'une plateforme de chat, comme Slack. Consultez les articles suivants sur l'alerte Slack : Slack Shell Bot - Russel Van Tuyl (@Ne0nd0g), Slack Notifications for Cobalt Strike - Andrew Chiles (@AndrewChiles), Slack Bots for Trolls and Work - Jeff Dimmock (@bluscreenfojeff)
Empreinte de la réponse aux incidents - Si possible, essayez d'identifier passivement ou activement les actions de réponse aux incidents avant le début de l'évaluation. Par exemple, envoyez un e-mail de phishing médiocre à la cible (en utilisant une infrastructure non liée) et surveillez le trafic que cette infrastructure reçoit. Les investigations des équipes de réponse aux incidents peuvent révéler une bonne quantité d'informations sur la façon dont l'équipe opère et sur l'infrastructure qu'elle utilise. Si cela peut être déterminé avant l'évaluation, cela peut être filtré ou redirigé directement.
UN GRAND MERCI à toutes les personnes suivantes (listées par ordre alphabétique) qui ont contribué des outils, des astuces ou des liens à inclure dans le wiki, et un autre MERCI à toute personne ayant écrit un outil ou un article référencé dans ce wiki !