jconwell/secret_handshakeUn prototype de canal C2 pour malware utilisant des certificats x509 sur mTLS
Tout d'abord, pourquoi publier ce projet en open source ?
MITRE ATT&CK ne mentionne que les certificats volés ou auto-signés, et les NDR (dans la mesure où je peux en juger) accordent très peu d'attention au contenu des certificats x509 en dehors de l'identité de l'autorité de certification émettrice. En général, les certificats x509 sont considérés comme fiables et autorisés à traverser nos pare-feu en toute impunité. Mais en substance, ce ne sont que des fichiers qui peuvent facilement contenir des charges malveillantes, comme n'importe quel autre. Nous leur faisons confiance et les ignorons parce qu'ils sont un composant essentiel d'un processus de chiffrement que nous en sommes venus à tenir pour acquis. L'objectif principal de ce projet est de sensibiliser davantage à une classe d'indicateurs de sécurité à laquelle nous avons appris à faire confiance, et de mettre en évidence les méthodes qui peuvent être utilisées pour détecter ses utilisations malveillantes.
Je me suis toujours demandé si des acteurs de la menace avaient déjà utilisé des certificats x509 dans le cadre de leur communication C2, non pas pour chiffrer le trafic réseau, mais pour réellement intégrer la communication C2 dans le certificat x509. Après avoir cherché quelque chose de ce genre dans la nature pendant 5 ans, j'ai finalement décidé de simplement le coder moi-même pour voir si c'était possible... et ça l'est.
Chaque message chiffré envoyé via HTTPS/TLS est rendu possible par le transfert d'un certificat x509. Lors de l'établissement d'une poignée de main TLS (figure ci-dessous), à la quatrième étape, le serveur envoie son certificat x509 au client. Le client vérifie le certificat, compare les algorithmes de chiffrement pris en charge par le serveur et choisit l'algorithme à utiliser pour toutes les communications suivantes.
Comme le montre ce schéma, il s'agit uniquement d'un transfert unidirectionnel du certificat x509 du serveur vers le client. Cela ne se prête pas bien à la communication C2, car le client n'a aucun moyen de répondre au serveur. Au mieux, il ne pourrait être utilisé que comme un mécanisme de transfert de données unidirectionnel (voir la section sur les travaux antérieurs ci-dessous).
Mais il existe un autre type de session TLS appelé authentification mutuelle TLS (mTLS), où le client et le serveur échangent des certificats x509 pour s'authentifier mutuellement.
Comme le montre la figure ci-dessus, lors de l'authentification mutuelle, le certificat x509 du serveur est envoyé au client pour authentification, puis le certificat x509 du client est envoyé au serveur pour authentification. Cet échange de certificats représente une opportunité de créer un canal de communication bidirectionnel pour les serveurs C2.
Comme les certificats du serveur et du client sont échangés par la bibliothèque SSL sous-jacente, le client n'a pas la possibilité d'extraire le message du certificat du serveur, d'exécuter la commande et de générer un certificat de réponse le tout au sein d'une seule connexion mTLS. Cela signifie que le canal C2 doit être conçu de telle sorte que l'échange requête-réponse s'effectue sur deux connexions TLS mutuelles différentes, un peu comme un mode de transmission pseudo-half-duplex.
Le processus de requête/réponse suit les étapes suivantes :
Après avoir réussi à faire fonctionner tout ça, j'étais plutôt fier de moi pour ma créativité et tout le reste.
Puis je suis tombé sur cette présentation BSides de 2018 par Jason Reaves qui a écrit un dropper de binaire malveillant utilisant des certificats x509 sur TLS. Un an plus tard, Jason a publié cet article détaillant un canal de communication bidirectionnel complet utilisant mTLS.
mTLS exige que les certificats du client et du serveur soient signés par le même certificat d'autorité de certification (CA), la première étape consiste donc à générer votre propre paire clé privée / certificat CA.
Créez la clé privée CA racine :
openssl genrsa -des3 -out hmCA.key 2048
remarque : La phrase secrète empêchera quiconque obtiendrait votre clé privée de générer son propre certificat racine.
Créez le certificat CA racine
openssl req -x509 -new -nodes -key hmCA.key -sha256 -days 1825 -out hmCA.pem
Copiez les fichiers de clé et de certificat générés dans le dossier certs/ca_certs. Le projet est livré avec une paire
clé/certificat de démonstration, vous pouvez donc ignorer cette étape si vous le souhaitez.
Démarrez le client :
python client.py
Démarrez le serveur :
python server.py
Je ne veux jamais publier quelque chose de potentiellement malveillant sans aussi détailler comment le détecter dans vos journaux réseau.
On pourrait penser que détecter ce type de schéma TLS serait facile, mais ce n'est pas si simple. L'un des principaux indices de ce canal C2 est son style de communication half-duplex ; il faut deux flux d'authentification mutuelle pour compléter une requête/réponse complète entre le serveur et le client. Cela se produira ensuite plusieurs fois à mesure que le serveur envoie différentes commandes au client.
Cela signifie que vous devriez chercher :
Cela semble être un ensemble de règles de détection imparable, mais comme je l'ai dit précédemment, ce n'est pas si facile. Il s'avère qu'il existe un ensemble de services d'entreprise qui présentent également un schéma de trafic mTLS similaire, notamment :
Plusieurs de ces services semblent être des services de gestion d'actifs/périphériques. En théorie, ils devraient donc envoyer le même ensemble de certificats à chaque fois qu'ils parcourent tous leurs appareils. Vous pourriez vérifier s'il existe des ensembles de sessions mTLS multiples se répétant toutes les N heures, puis voir si les empreintes des certificats entre deux ensembles différents de sessions mTLS correspondent, ou correspondent en grande partie. Vous pouvez également chercher des certificats clients différents pour chaque session mTLS, mais le même certificat serveur pour toutes les sessions.
L'inspection SSL est un moyen de potentiellement bloquer ce type de canal de communication C2, car le serveur d'inspection SSL ne disposerait pas du certificat CA malveillant nécessaire pour authentifier le certificat du client.
