L'élaboration de requêtes pour l'infrastructure des logiciels malveillants peut constituer une étape précieuse dans le cycle de vie de la sécurité. Malheureusement, il existe peu de ressources sur la façon de commencer et sur les indicateurs qui peuvent être utilisés pour construire des requêtes. Aujourd'hui, nous souhaitons combler cette lacune en présentant des méthodes accessibles et de grande valeur qui peuvent être utilisées pour rechercher des infrastructures de logiciels malveillants.
Qu'est-ce que la construction de requêtes pour l'infrastructure de lutte contre les logiciels malveillants ?
L'élaboration de requêtes est le processus d'observation d'une infrastructure malveillante suspecte ou connue et la création de requêtes pour identifier le modèle de configuration utilisé par le créateur de l'infrastructure. Étant donné que les acteurs de la menace réutilisent souvent une configuration identique ou similaire sur plusieurs serveurs déployés, il existe souvent un modèle qui peut être utilisé pour identifier plusieurs serveurs à partir d'un seul indicateur initial.
Une requête bien construite permet à un analyste d'identifier des serveurs supplémentaires liés à l'infrastructure de l'acteur. L'analyste peut alors bloquer de manière proactive, enquêter ou effectuer toute autre action nécessaire pour limiter la compromission et recueillir des renseignements.
Pourquoi construire des requêtes sur l'infrastructure des logiciels malveillants ?
L'élaboration de requêtes sur l'infrastructure des logiciels malveillants peut être un moyen très efficace d'obtenir des COI pour le blocage et la chasse.
Les méthodes traditionnelles pour répertorier l'infrastructure des logiciels malveillants consistent à obtenir un grand nombre d'échantillons uniques de logiciels malveillants et à extraire les codes d'identification de chaque fichier.
Il peut s'agir d'un processus très fastidieux et technique qui nécessite un rétro-ingénieur spécialisé pour déconstruire un échantillon, développer et tester une règle de chasse de Yara, acquérir de nouveaux échantillons, puis développer et appliquer un extracteur de configuration afin d'obtenir des COI individuels.
Cette capacité de rétro-ingénierie implique un savoir-faire technique important que la plupart des équipes confient à des services de renseignement sur les menaces. L'externalisation des flux de renseignements sur les menaces peut être efficace et il existe de bons flux payants, mais ils sont souvent coûteux et peuvent varier considérablement en termes de qualité et de rapidité.
Avantages de l'interrogation sur l'infrastructure des bâtiments
En développant vos propres requêtes d'infrastructure à des fins de chasse, vous pouvez établir une liste beaucoup plus importante d'IOC de logiciels malveillants avec un ensemble d'échantillons de logiciels malveillants, une expertise technique et un coût global nettement inférieurs. Vous pouvez également exploiter les requêtes pour étendre les alertes de votre propre environnement, ce qui vous permet d'établir une liste d'IOC liés à des logiciels malveillants connus ayant un impact sur votre organisation.
En utilisant les techniques présentées dans cet article, vous pouvez potentiellement identifier des dizaines de CIO et d'infrastructures de logiciels malveillants avec un seul échantillon ou une seule alerte disponible.
Quels sont les indicateurs que nous pouvons utiliser ?
Une seule adresse IP malveillante contient un grand nombre d'informations qui peuvent être utilisées pour identifier d'autres serveurs. Cela est dû à des modèles uniques liés au logiciel et à la configuration déployés par un acteur.
Étant donné que les acteurs de la menace réutilisent souvent les mêmes logiciels et configurations dans plusieurs instances d'infrastructures malveillantes, un modèle unique peut être utilisé pour identifier d'autres serveurs.
Les indicateurs les plus courants que les acteurs de la menace réutilisent sont les suivants :
- Informations sur les certificats - Champs contenus dans les certificats TLS et SSL. Les valeurs codées en dur sont souvent réutilisées.
- En-têtes de serveur - Les acteurs qui déploient des logiciels personnalisés peuvent oublier de modifier les en-têtes par défaut qui contiennent des indicateurs.
- Données dans les réponses HTTP - Logiciel personnalisé contenant des valeurs uniques dans les réponses HTTP
- Localisation, ASN et fournisseurs d'hébergement - Les acteurs réutilisent les fournisseurs d'hébergement pour l'infrastructure. Des serveurs similaires peuvent être hébergés dans le même ASN.
- Hachures JA3 - Les acteurs déployant des configurations logicielles peu communes peuvent être identifiés par des signatures JA3.
- Configurations des ports - Les acteurs laissent souvent les mêmes ports ouverts dans l'infrastructure.
- Expressions régulières - Les acteurs peuvent déployer des valeurs uniques avec une structure très similaire qui peut être capturée avec des expressions régulières.
Maintenant que nous avons abordé les concepts clés, nous allons nous plonger dans quelques exemples.
Chasser l'infrastructure avec des certificats TLS
Les acteurs de la menace et les développeurs de logiciels malveillants utilisent des certificats TLS pour chiffrer les communications et établir des connexions entre un hôte cible et une infrastructure malveillante.
Pour de nombreuses raisons, les acteurs déploient rarement des certificats uniques pour chaque échantillon déployé. Il en résulte que les valeurs d'un seul certificat TLS sont présentes sur de nombreux autres serveurs, ce qui introduit des modèles simples qui peuvent être signés et interrogés.
Exemple 1 : Chasser AsyncRAT avec des certificats TLS
La famille de logiciels malveillants AsyncRAT contient un certificat TLS codé en dur laissé par le développeur. Ce certificat contient le nom commun du sujet codé en dur du serveur AsyncRAT.
Prenons par exemple l'adresse IP 91.109.176[.]4. L'interrogation de cette adresse IP dans Censys Search confirme la valeur du nom commun du sujet (CN) du serveur AsyncRAT sur le port 8808.
En développant les informations sur l'hôte et en localisant le champ exact où la valeur du serveur AsyncRAT est stockée services.tls.certificates.leaf_data.subject_dn, nous pouvons construire une requête pour localiser des serveurs supplémentaires.
Dans ce cas, les champs subject_dn ou issuer_dn peuvent être utilisés car ils contiennent tous deux la même valeur codée en dur.
En recherchant AsyncRAT Server dans l'un ou l'autre de ces champs, nous pouvons localiser 110 serveurs supplémentaires ayant la même valeur de certificat.
Exemple 2 : Chasser le Cobalt Strike avec des certificats TLS
La tristement célèbre boîte à outils Cobalt Strike peut également être repérée à l'aide des valeurs des certificats TLS.
Ceci est principalement dû à un nom commun de sujet par défaut, à savoir Major Cobalt Strike.
Prenons par exemple l'adresse IP 23.98.137[.]196 avec le certificat suivant sur le port 50050.
Plusieurs valeurs codées en dur peuvent être utilisées, mais pour des raisons de simplicité, nous utiliserons le nom commun de l'émetteur, à savoir Une importante grève du cobalt.
Nous pouvons développer à nouveau la vue détaillée de l'hôte pour déterminer le nom exact du champ. Services.tls.certificates.leaf_data.issuer.common_name.
L'interrogation de cette valeur renvoie 236 résultats. La probabilité qu'un logiciel légitime contienne "Major Cobalt Strike" est très faible, il s'agit donc probablement de tous les déploiements actifs de Cobalt Strike.
Chasser l'infrastructure avec les titres des réponses HTTP
Les développeurs de serveurs de contrôle de logiciels malveillants laissent souvent des chaînes de caractères uniques et identifiables dans les données des pages web.
Le plus souvent, ils se trouvent dans les titres HTML et les corps HTTP.
Il est utile de noter que ces valeurs peuvent être modifiées, mais de nombreux acteurs ne font pas cet effort et laissent les chaînes d'identification intactes.
Exemple 1 : Cadre mythique C2
Le cadre Mythic C2 est souvent utilisé par les acteurs de la menace et contient un titre HTML par défaut de Mythic.
En examinant l'adresse IP 89.223.66[.]195, nous pouvons confirmer la présence de la chaîne Mythic dans le titre HTML.
En recherchant la chaîne Mythic dans services.http.response.html_title, nous pouvons localiser un total de 75 serveurs.
Un grand nombre de ces serveurs ont déjà été marqués comme serveurs C2 par la plateforme Censys . (Vous pouvez localiser d'autres C2 avec la requête labels:C2)
Chasser l'infrastructure avec des bannières de service
Les acteurs de la menace et les développeurs de logiciels malveillants laissent souvent des chaînes d'identification à l'intérieur des bannières de service. Ces chaînes sont souvent laissées intentionnellement par l'auteur afin de limiter l'utilisation abusive du logiciel.
Ils peuvent être identifiés, interrogés et suivis en utilisant des méthodes similaires à celles des titres HTML.
Notez que les bannières de service peuvent ne pas être affichées par défaut et que vous devrez peut-être ouvrir la vue détaillée de l'hôte pour les voir.
Exemple 1 : Cadre Havoc C2
Prenons l'exemple du cadre C2 Havoc. Havoc est un cadre C2 open source développé par C5pider qui a été exploité par les acteurs de la menace en raison de sa mise en œuvre de haute qualité des techniques offensives modernes.
Avec les paramètres par défaut , Havoc Team Server contient la chaîne X-Havoc à l'intérieur de la bannière de service. Cela a été laissé intentionnellement par l'auteur pour limiter l'utilisation abusive du logiciel.
La recherche de services.banner avec la chaîne X-Havoc donne un total de 71 résultats.
Une telle chaîne est spécifique et peu susceptible de générer des faux positifs. Il y a donc de fortes chances qu'il s'agisse de déploiements actifs de Havoc.
Exemple 2 : Chasser DarkComet avec des bannières de service
Un deuxième exemple de chasse aux bannières de services est donné par le logiciel malveillant DarkComet.
En regardant l'adresse IP de 187.135.84[.]89, nous pouvons observer une bannière de service d'apparence unique de BF7CAB464EFB sur le port 2000.
Nous pouvons rechercher services.banner avec la valeur BF7CAB464EFB pour identifier un total de 25 serveurs.
Résumé - Chasser l'infrastructure avec des bannières de service
Les acteurs de la menace travaillent souvent dans l'urgence et évitent de modifier les chaînes par défaut dans les logiciels personnalisés ou open source. Lors de l'examen d'un hôte, veillez à vérifier toutes les bannières de service pour y trouver des chaînes uniques ou intéressantes.
Ces chaînes par défaut sont d'excellents indicateurs pour l'élaboration des requêtes et vous devez absolument les utiliser à votre avantage.
Si vous voulez voir par vous-même, voici une requête préconstruite pour Havoc et DarkComet.
Chasse aux emplacements et aux fournisseurs d'ASN
Les acteurs de la menace réutilisent souvent les mêmes fournisseurs d'hébergement lorsqu'ils déploient plusieurs serveurs à des fins malveillantes.
Souvent, cela est fait pour éviter les démantèlements et les enquêtes. D'autres fois, c'est parce qu'il est plus facile d'obtenir des fournisseurs d'hébergement dans le pays d'origine d'un acteur.
Quelles que soient les raisons, les acteurs réutilisent souvent les fournisseurs, ce qui nous permet de localiser les serveurs malveillants et d'affiner les requêtes existantes sur d'autres indicateurs.
Exemple 1 : Serveurs bot d'Amadey
Examinons l'adresse IP 185.215.113[.]68. Cette adresse IP a un corps de réponse HTTP relativement unique, à savoir aucun.
En se concentrant sur la question de la services.http.response.body="none"Nous avons un premier résultat de 84 serveurs. Un grand nombre de ces serveurs sont situés aux États-Unis et ne semblent pas être de nature malveillante.
En revenant aux résultats initiaux de la page d'accueil pour 185.215.113[.]68, nous pouvons voir que le serveur est hébergé à Moscou avec un numéro de système autonome de 51381.
Nous pouvons ajouter ce chiffre comme filtre supplémentaire pour affiner les résultats de notre requête.
En ajoutant autonomous_system.asn=51381 à notre recherche, nous avons maintenant limité notre recherche à seulement 4 résultats. L'interrogation de ces résultats dans Virustotal montre qu'ils sont tous liés au malware Amadey Bot.
Résumé - Recherche de sites et de fournisseurs d'hébergement
Les acteurs de la menace utilisent souvent les mêmes fournisseurs d'hébergement lorsqu'ils déploient leur infrastructure. Le fournisseur d'hébergement n'est pas nécessairement un indicateur en soi, mais il peut être combiné à d'autres indicateurs pour produire une requête très efficace.
Lorsque vous enquêtez sur un CIO et que vous constatez qu'il y a trop de résultats de recherche. Essayez d'ajouter l'emplacement physique du serveur ou le numéro ASN pour affiner votre recherche.
Vous pouvez expérimenter l'exemple d'Amadey en utilisant cette requête prédéfinie.
Chasser l'infrastructure avec les annuaires ouverts
Les acteurs de la menace hébergent souvent des logiciels malveillants et des logiciels de soutien dans des répertoires ouverts qui sont exposés à l'internet public. Ces répertoires sont généralement déployés de manière à ce que les logiciels malveillants puissent facilement récupérer des fichiers supplémentaires pour faciliter l'exploitation.
Pour localiser les annuaires ouverts, nous pouvons rechercher des titres d'annuaires courants tels que Directory Listing ou Index Of.
Nous pouvons également rechercher des serveurs pré-étiquetés avec l'étiquette open-dir fournie par Censys.
Exemple 1 : Chasse aux répertoires ouverts avec des noms de fichiers communs
Une recherche sur les annuaires ouverts peut à elle seule donner des centaines de milliers de résultats. Nombre d'entre eux sont bénins et non malveillants.
Pour identifier les cas malveillants, nous pouvons combiner la recherche avec un nom de fichier spécifique lié à un logiciel suspect.
Prenons l'exemple de nc.exe, qui est un nom de fichier courant pour l'outil netcat.
En examinant l'une des premières adresses renvoyées, 123.57.56[.]129, nous pouvons observer un répertoire ouvert contenant nc.exe ainsi que des références à Hacktools et un script .bat avec des caractères étrangers. Ces informations sont suffisantes pour supposer que l'adresse IP est hautement suspecte.
Une fois ces indicateurs identifiés, nous pouvons tenter de récupérer les fichiers pour effectuer des analyses supplémentaires et confirmer leur caractère malveillant, ou nous pouvons utiliser les nouveaux noms de fichiers pour affiner la requête et identifier d'autres serveurs.
Par exemple, nous pouvons exploiter la chaîne de caractères nouvellement identifiée de hacktools pour créer une nouvelle requête.
Nous pouvons le faire avec des étiquettes:open-dir et des corps de réponse contenant des hacktools.
Dans ce cas, un seul résultat est renvoyé, mais cela démontre le concept d'utilisation des résultats initiaux pour établir de nouvelles requêtes. Cette requête pourrait facilement être réexécutée à une date ultérieure pour identifier de nouvelles instances du serveur suspect.
Exemple 2 : Ouvrir les répertoires contenant Procdump.exe
Pour illustrer davantage le concept, nous pouvons rechercher les répertoires ouverts contenant des références à l'outil de vidage de processus procdump.exe.
L'un des résultats est un serveur hébergeant procdump.exe, beacon.exe et shell.exe.
Nous pouvons utiliser ces résultats pour identifier de nouvelles chaînes et pivoter pour ouvrir les répertoires contenant beacon.exe.
Ceci identifie un nouveau serveur avec l'IP 62.204.41[.]104. Ce serveur contient des références à `beacon.exe` mais pas le netcat initial ou procdump. Ceci met en évidence l'utilité de construire de nouvelles requêtes basées sur les résultats initiaux.
Résumé - Chasser les répertoires ouverts
La chasse aux répertoires ouverts peut s'avérer utile pour repérer les serveurs suspects. C'est particulièrement utile lorsqu'il s'agit d'un logiciel malveillant de téléchargement qui a fait appel à un serveur doté d'un répertoire ouvert.
Lors de l'élaboration des requêtes, utilisez la balise open-dir prédéfinie et exploitez les noms de fichiers connus. Ajoutez ensuite de nouveaux noms de fichiers et de nouvelles chaînes de caractères en fonction de vos résultats.
Nous avons inclus ici quelques requêtes prédéfinies pour beacon.exe, procdump.exe et nc.exe.
Incorporation d'expressions régulières dans les requêtes de chasse
Les auteurs de menaces avancées évitent souvent d'utiliser des valeurs codées en dur sur plusieurs serveurs.
Lorsque des valeurs uniques sont déployées, cela se fait souvent par le biais de scripts et de programmes automatisés. Cela signifie que même si les valeurs sont uniques, la "structure" des valeurs est souvent répétée et peut être signée à l'aide d'expressions régulières.
Voyons quelques exemples de valeurs uniques qui peuvent être signées à l'aide d'expressions régulières. Notez que la recherche par expressions régulières est une fonctionnalité payante de Censys Search.
Exemple 1 : Attraper les serveurs Qakbot avec des expressions régulières
Un bon exemple de valeurs uniques avec la même structure est celui de Qakbot.
Qakbot utilise un système automatisé pour déployer et actualiser les valeurs uniques des certificats TLS sur l'ensemble des serveurs. Mais ces valeurs ont une structure similaire qui peut être interrogée à l'aide d'expressions régulières.
Deux de ces certificats sont présentés dans les captures d'écran ci-dessous.
En observant les deux valeurs de certificat, nous pouvons voir qu'elles sont très différentes. Cependant, elles suivent un schéma similaire qui peut être détecté à l'aide d'expressions régulières.
Nous pouvons le vérifier en copiant les valeurs et en introduisant Cyberchef. Cela nous permet de prototyper une expression régulière et de confirmer que nous pouvons faire correspondre les deux valeurs.
En répétant ce processus pour les deux émetteur et champs thématiques du certificat TLS, nous pouvons développer une requête qui attrape un total de 64 serveurs.
Pour vérifier que les résultats correspondent à ce qui était prévu, nous pouvons générer un rapport Censys sur les résultats renvoyés. Cela nous permet de répertorier toutes les valeurs de certificat renvoyées dans une liste facile à lire.
Vous trouverez ci-dessous un court extrait des résultats, confirmant que la requête fonctionne comme prévu.
Exemple 2 : Attraper les serveurs BianLian avec des expressions régulières
Le logiciel malveillant BianLian est un autre exemple de valeurs de certificat TLS uniques contenant une structure et un formatage identiques.
Ci-dessous, nous pouvons observer deux certificats. Le sujet et l'émetteur ne contiennent que les champs "C", "O" et "OU". (Contrairement à un certificat "classique", qui contiendrait également les champs "ST" et "L").
Chaque valeur contient exactement 16 caractères, sans espacement ni utilisation de caractères spéciaux.
En apportant les deux valeurs de l'émetteur à Cyberchef, nous pouvons prototyper une expression régulière qui capture les valeurs des deux certificats.
Nous pouvons maintenant effectuer une recherche sur services.tls.certificate.parsed.issuer_dn avec notre expression régulière. Nous obtenons un total de 24 serveurs.
Nous pouvons continuer et générer un autre rapport de recherche sur services.tls.certificate.parsed.issuer_dn pour confirmer que les résultats correspondent à ce qui était prévu.
Exemple 3 : serveurs Viper avec certificats TLS et expressions régulières
Pour illustrer un autre exemple, nous pouvons examiner une adresse IP de 139.155.90[.]81 qui a été marquée comme Viper Malware sur ThreatFox.
Nous pouvons visualiser les informations du certificat TLS sur Censys. Afficher les champs " subject " et " issuer " qui contiennent exactement 8 caractères et uniquement des lettres minuscules et des chiffres.
En introduisant l'une des valeurs dans Cyberchef, nous pouvons à nouveau prototyper une expression régulière pour qu'elle corresponde à la structure identifiée.
Nous pouvons ensuite rechercher cette expression régulière dans le champ services.tls.certificates.leaf_data.issuer_dn. Nous obtenons un total de 1593 résultats.
La génération d'un autre rapport de recherche permet de vérifier que nombre de ces résultats contiennent la même structure TLS que le serveur initial.
Résumé - Chasser l'infrastructure avec des expressions régulières
Dans certains cas, les valeurs codées en dur ne suffiront pas pour chasser l'infrastructure.
La plupart de ces situations peuvent être gérées en identifiant la structure des valeurs apparemment uniques et en incorporant des expressions régulières dans vos requêtes.
Si vous n'êtes pas familier avec les expressions régulières, il existe une excellente ressource gratuite sur regexone qui vous aidera à démarrer.
Comment puis-je commencer ?
Toutes les requêtes (à l'exception des expressions régulières) peuvent être effectuées avec un compte de la communauté de recherche Censys . Vous pouvez vous inscrire dès aujourd'hui et commencer la chasse aux menaces, la collecte de renseignements et l'élaboration de listes de CIO.
Pour obtenir les premiers IOC, nous vous recommandons d'utiliser les dépôts publics d'IOC tels que ThreatFox et URLHaus et de commencer votre chasse à partir de là. Nous vous recommandons également d'utiliser des requêtes prédéfinies comme celles de drb_ra et Michael Koczwara.
Conclusion
Nous venons d'examiner plusieurs indicateurs permettant d'identifier une infrastructure malveillante. Vous pouvez et devez utiliser tous ces indicateurs à votre avantage lorsque vous enquêtez sur une adresse IP ou que vous effectuez une chasse aux menaces.
Les acteurs de la menace varient en qualité et en sophistication, certains seront plus difficiles à traquer que d'autres. Mais dans de nombreux cas, il est possible de suivre les acteurs en utilisant uniquement les techniques présentées ici aujourd'hui.
