Le décryptage des charges utiles des paquets est-il efficace sur le plan opérationnel pour aider les défenseurs à détecter les signes d'attaques avancées de l'État-nation ou d'attaques exécutées manuellement comme les RansomOps dans un réseau ?
La réponse courte est non.
- Le décryptage passif d'un chiffrement standard tel que TLS est coûteux sur le plan opérationnel (avec TLS 1.3, il faut installer un agent sur tous les points d'extrémité connectés).
- Le décryptage n'apporte que peu d'avantages au défenseur que le décryptage actif avec des pare-feu ou des proxies n'apporte pas déjà.
- Ni l'un ni l'autre n'aide les défenseurs à repérer le canal C2 d'un attaquant avancé ou à exfiltrer des données.
Nous examinons le trafic à la frontière du réseau d'une organisation, où le chiffrement est prédominant, et nous recherchons des signes de commande et de contrôle et d'exfiltration de données. Nous constatons que le décryptage n'offre que très peu d'avantages, voire aucun, aux défenseurs lorsqu'il s'agit de détecter des attaques avancées d'États-nations ou des attaques criminelles exécutées manuellement comme les RansomOps. Voici pourquoi.
Les outils d'attaque des États-nations sont personnalisés
Les acteurs étatiques nationaux assemblent généralement des chaînes d'outils à l'usage de leurs équipes d'attaquants. Ces chaînes d'outils comprennent souvent des outils développés en interne et des outils plus standard. Les outils prêts à l'emploi sont fortement personnalisés pour éviter d'être détectés par des méthodes simples qui recherchent leur simple présence.
Et les acteurs étatiques les plus compétents ajouteront encore de l'entropie - ils configureront les outils personnalisés et prêts à l'emploi qu'ils utilisent différemment pour chaque cible qu'ils poursuivent, et ne réutiliseront aucune des infrastructures (pour le C2 et l'Exfil) utilisées pour mener des attaques sur des cibles différentes. Par conséquent, le décryptage des charges utiles pour exécuter des signatures ne présente aucun avantage significatif en matière de détection.
Les outils des attaquants criminels (RansomOps) sont modifiés
Les attaques exécutées manuellement, comme celles utilisées pour la plupart des attaques RansomOps, sont au service d'un modèle commercial à but lucratif. Il n'est pas judicieux de consacrer beaucoup de recherche et développement à la création d'outils à partir de zéro, car cela réduit les bénéfices potentiels.
Au lieu de cela, presque toutes les attaques criminelles font un usage intensif d'outils disponibles sur le marché, mais ces acteurs en savent suffisamment pour ne pas utiliser ces outils avec les paramètres par défaut fournis, ce que la plupart des produits de signature détecteraient.
Au lieu de cela, ils remplaceront la configuration standard fournie avec les outils standard, ce qui rendra les signatures inutiles. L'infrastructure est plus souvent réutilisée, mais elle peut être identifiée par le biais de domaines et/ou d'adresses IP sans décryptage. Tout comme dans le cas des États-nations, le décryptage des charges utiles pour exécuter les signatures ne présente donc aucun avantage significatif en termes de détection.
Le fonctionnement interne de Cobalt Strike
Examinons ce que cela signifie de remplacer les paramètres standard de Cobalt Strike, qui est l'un des frameworks de test de la plume les plus connus. Cet exemple est illustratif - le même degré de configurabilité existe dans n'importe quel outil de test d'intrusion mature, ce qui rend trivial le fait d'outrepasser les paramètres par défaut pour échapper aux signatures.
Le guide de l'utilisateur de Cobalt Strike est disponible ici. Examinons la capacité Malleable Command and Control qui fait partie de ce paquet. Pour utiliser la fonctionnalité C2 malléable, vous devez composer toutes les options que vous souhaitez utiliser dans un profil.
Dans le profil, chaque élément de la requête et de la réponse HTTPS utilisées pour la communication C2 est (comme le titre l'indique) malléable. Cela inclut le certificat que vous utilisez pour sécuriser le canal TLS transportant le trafic HTTP, l'URI codé dans la requête HTTP, l'User-Agent spécifié, la présence ou l'absence d'une balise referrer, et tout ce que l'attaquant veut mettre dans la requête pour qu'elle ait l'air normale ou inintelligible.
Toute donnée réelle devant être transférée sur le canal C2 peut être encodée dans une variété de formats (Base64, NetBIOS, etc.) et peut facilement être masquée par XOR dans une clé aléatoire connue uniquement par l'attaquant (considérez ceci comme une forme légère mais efficace de cryptage "interne").
Résumé
Qu'il s'agisse d'un État-nation ou d'un attaquant RansomOps (qui applique une bonne hygiène de sécurité en ne réutilisant pas les mêmes balises/valeurs et clés pour différentes cibles), briser le cryptage TLS externe pour accéder à la requête HTTP interne n'aide pas le défenseur. Il n'existe pas de modèle fixe de signature à cibler et la charge utile réelle (commandes envoyées, résultats des commandes renvoyés, logiciels téléchargés, etc.) est masquée par un chiffrement léger utilisant la clé générée de manière aléatoire par l'attaquant.
Ainsi, à moins qu'une organisation ne soit disposée à appliquer une politique d'accès à l'internet très restrictive (en dressant une liste blanche de la partie de l'internet à laquelle elle fait confiance), les canaux C2 ne peuvent pas être détectés en recherchant des motifs d'octets dans les charges utiles HTTP décryptées. La détection de l'exfiltration suit à peu près la même logique. Les charges utiles internes cryptées sont imperméables aux approches DLP standard. Les seuls autres moyens de détection C2 ou Exfil sont basés sur l'analyse de séries chronologiques de transferts de données ou sur l'observation de simples anomalies de volume - qui ne nécessitent pas le décryptage de l'enveloppe extérieure.