Suivi de l'infrastructure persistante avancée

Introduction

La plupart des cyberactivités menées par des acteurs malveillants nécessitent des infrastructures telles que des serveurs sur l'internet. Plus la campagne est importante, plus le nombre de serveurs nécessaires est élevé. Certains groupes APT ont utilisé plusieurs milliers de serveurs de commande et de contrôle (C2) au fil des ans. Pour les services de renseignement sur les menaces, cela offre des possibilités uniques de suivre ces activités, car les serveurs C2 doivent souvent être configurés d'une manière spécifique et de nombreux acteurs ont développé des habitudes idiosyncrasiques de configuration des serveurs. Un avantage essentiel par rapport aux enquêtes purement judiciaires sur les incidents est que l'analyse de l'infrastructure permet parfois d'identifier les serveurs C2 avant même qu'ils ne soient utilisés dans une attaque. Les moteurs de recherche Internet tels que Censys jouent un rôle crucial dans ce type d'analyse. Ils recueillent des informations sur les hôtes présents sur l'internet et leurs configurations, ce qui évite aux chercheurs de devoir analyser eux-mêmes de vastes espaces d'adresses.

Cet article explique pourquoi il est possible de suivre une infrastructure, quels sont les attributs qu'il peut être important d'examiner, présente deux exemples récents ainsi qu'un exemple de processus et donne quelques conseils pour débuter dans l'analyse de l'infrastructure. N'oubliez pas que cet article ne traite que des méthodes passives de recherche et de regroupement d'infrastructures malveillantes. Les méthodes actives, telles que l'analyse des hôtes par l'utilisateur lui-même, offrent d'autres possibilités telles que l'imitation de la poignée de main d'un logiciel malveillant afin d'identifier les serveurs C2 ou les victimes avec un degré de confiance élevé. En outre, cet article ne couvre que les infrastructures basées sur le protocole HTTP(S).

Contexte

Il existe de multiples raisons pour lesquelles une infrastructure malveillante peut être trouvée via Censys et des services similaires, et la plupart d'entre elles sont dues à des erreurs dans la sécurité des opérations (OPSEC). Le paragraphe suivant n'est certainement pas exhaustif, mais il mentionne quelques points clés qui expliquent ces erreurs. Certains acteurs peuvent ne pas être conscients de leurs erreurs, mais d'autres peuvent même être conscients de l'impact sur l'OPSEC. Pourtant, comme ils doivent faire un compromis entre l'OPSEC et l'efficacité, ils semblent parfois décider de prendre le risque.

1. Le rythme des cyberattaques s'est considérablement accéléré Alors que les cyberattaques étaient l'exception il y a quelques années, elles font aujourd'hui partie du quotidien. En raison du nombre croissant de cibles, la demande d'infrastructure a également augmenté. Afin de gagner un temps précieux, une certaine forme d'automatisation de l'infrastructure est utilisée pour installer et configurer les serveurs. Certains acteurs ont choisi la méthode la plus simple en déployant des images préparées, tandis que d'autres semblent configurer les serveurs C2 à l'aide de scripts.

2. Différentes équipes sont responsables de l'organisation des campagnes et de la mise en place de l'infrastructure Alors que certains opérateurs expérimentés (qui mènent les attaques proprement dites) peuvent connaître les pièges de l'OPSEC, dans certains groupes, l'infrastructure est mise en place par une autre équipe qui n'est pas consciente des possibilités techniques d'identification de ses serveurs.

3. Des termes spécifiques doivent être utilisés pour paraître légitimes aux yeux des victimes potentielles Il est souvent nécessaire de tromper les victimes en leur faisant croire que l'infrastructure utilisée est légitime. Il peut s'agir de se dissimuler dans le trafic général du réseau ou de faire en sorte que la victime reconnaisse les adresses suspectes dans la barre d'URL, par exemple dans le cadre de campagnes d'hameçonnage.

4. Pas d'OPSEC par conception En général, de nombreux acteurs ne semblent pas suivre l'OPSEC par conception. Au lieu de réfléchir à l'avance à la manière dont les analystes du renseignement sur les menaces pourraient identifier leurs serveurs, ils semblent vivre par essais et erreurs ou, du moins, n'améliorent leur OPSEC qu'après avoir été démasqués dans un rapport de renseignement sur les menaces.¹. Comme nous ne voulons pas fournir de conseils OPSEC pour les menaces récentes, cet article de blog ne couvre que les infrastructures déjà connues qui ont fait l'objet de blogs.

Critères de regroupement des hôtes

Il existe de nombreux critères qui peuvent être utilisés pour trouver et regrouper les infrastructures. Certains d'entre eux sont énumérés ici, y compris les attributs respectifs qui peuvent être utilisés pour rechercher cet hôte - comme précédemment, cette liste n'est pas exhaustive. En général, il existe trois groupes de critères : l'en-tête de la réponse, le contenu de la réponse et les certificats. Étant donné que certains acteurs de la menace utilisent des logiciels personnalisés côté serveur ou des versions spécifiques de bibliothèques, les réponses aux requêtes HTTP comprennent souvent une combinaison caractéristique d'en-têtes. Les hôtes peuvent donc être regroupés soit en raison de l'absence d'un en-tête, soit en raison de chaînes d'en-tête spécifiques. Nous verrons plus loin un exemple de regroupement d'hôtes en fonction des en-têtes de réponse. Avec les requêtes Censys , les en-têtes peuvent être filtrés via

<port>.http(s).get.headers.

Le contenu de la réponse peut également contenir des artefacts caractéristiques. Certains serveurs de commande et de contrôle tentent d'imiter un serveur web spécifique et fournissent donc une sorte de page par défaut comme page d'index ou d'erreur. Un exemple bien connu est l'utilisation de la page web par défaut de Microsoft Internet Information Service (IIS) comme page d'index pour Powershell Empire². Les services d'analyse n'accèdent généralement qu'à la page d'index ou reçoivent une page d'erreur en réponse si le serveur C2 s'attend à ce qu'un certain chemin d'accès soit emprunté. Dans ces cas, la valeur de hachage du corps de la réponse peut souvent être utilisée pour la mise en cluster des hôtes.

D'autres acteurs utilisent parfois une configuration par défaut, dans laquelle un site web est d'abord entièrement cloné, puis modifié. Dans ce cas, il peut être utile de rechercher des ressources spécifiques dans le site web, telles que les favicons utilisés, les extraits de javascript intégrés (et les identifiants de réseau publicitaire ou de suivi qui peuvent s'y trouver) ou les fichiers css inclus. Le dernier groupe de critères concerne les certificats. Le filtrage par numéro de série, empreinte digitale ou nom distinctif (voir l'exemple 2 ci-dessous) peut être un moyen utile de regrouper les hôtes en fonction de leurs certificats. Les acteurs peuvent avoir tendance à utiliser une autorité de certification spécifique avec des termes assez uniques dans le nom commun ou même à réutiliser des certificats auto-signés dans toute leur infrastructure.
Le contenu de la réponse et les certificats sont parfois créés de manière à paraître légitimes aux yeux des victimes potentielles et comprennent donc des éléments spécifiques.

Exemple 1 - Suivi basé sur les en-têtes HTTP

Cobalt Strike (CS), boîte à outils commerciale de test de pénétration largement connue, n'est pas seulement utilisée par les équipes rouges. Au fil du temps, de nombreux acteurs de la menace l'ont utilisé (et continuent probablement à l'utiliser) comme première étape. La réponse typique du serveur pour Cobalt Strike peut être caractérisée comme suit :

• HTTP 404 Non trouvé
• Content-Type : text/plain
• Contenu-Longueur : 0
• En-tête de date
• Pas d' en-tête de serveur

Grâce à ces critères, nous pouvons facilement trouver des serveurs à l'aide de la requête suivante : Censys :

80.http.get.status_line : "404 Not Found" 
AND 80.http.get.headers.content_type : "text/plain" 
AND 80.http.get.headers.content_length : 0 
NOT _exists_:80.http.get.headers.server

_{Censys recherche d'instances Cobalt Strike sur le port 80}

Sachez que tous les résultats que vous voyez ne sont pas nécessairement des instances Cobalt Strike, mais il s'agit d'un bon indicateur. En outre, comme vous l'avez peut-être déjà deviné, Cobalt Strike n'est pas limité au port 80. Outre le certificat TLS par défaut utilisé par l'outil, vous pouvez trouver d'autres instances utilisant TLS en recherchant également des autorités de certification populaires ou des certificats auto-signés.

87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390c

_{Censys en utilisant le hachage SHA256 de l'empreinte digitale du certificat Cobalt Strike par défaut}

Il existe une quantité considérable d'infrastructures Cobalt Strike disponibles en ligne, vous aurez donc probablement besoin d'un autre type de source de données, telles que des données DNS passives, afin de regrouper correctement les instances trouvées.
Résultats des en-têtes typiques de Cobalt Strike sur le port 80 :

Exemple 2 - Suivi basé sur les données du certificat

En juillet 2020, le NCSC UK, l'autorité nationale de cybersécurité du Royaume-Uni, a publié un avis sur l'APT29 ciblant la^recherche sur le vaccin COVID-193^. Le groupe également connu sous le nom de "The Dukes" ou "Cozy Bear" a utilisé des vulnérabilités Citrix et VPN pour attaquer diverses entreprises liées au développement de vaccins. Pour ces campagnes, le groupe a utilisé deux familles de logiciels malveillants personnalisés, WellMess et WellMail. L'infrastructure utilisée par les auteurs comprenait des certificats auto-signés très spécifiques qui les rendaient faciles à tracer, comme l'ont rapporté plusieurs sources. PwC a récemment publié un rapport sur le logiciel serveur utilisé par les malfaiteurs.^4.

Emetteur : C=Tunis, O=IT, CN=* Objet : C=Tunis, O=IT

En utilisant les noms distinctifs des certificats indiqués dans le tableau 1, nous pouvons créer une requête afin de trouver l'infrastructure récente :

443.https.tls.certificate.parsed.subject_dn : "C=Tunis, O=IT" AND 443.https.tls.certificate.parsed.issuer_dn : "C=Tunis, O=IT, CN=*"

Avec la requête du tableau 2, 20 hôtes peuvent être trouvés en utilisant les détails du certificat.

Exemple de processus

Lorsque j'ai commencé à suivre les infrastructures, j'ai écrit un simple outil python qui interrogeait différentes sources de données sur la base d'une règle donnée.

La règle (voir figure 3) comprenait la requête nécessaire et le script envoyait les résultats à d'autres systèmes. Comme ces résultats n'étaient utilisés que comme notifications au départ, j'ai appelé cette section "alertes". Après avoir mis en place des cronjobs pour exécuter vos scripts, vous êtes prêt à partir - sans avoir besoin d'une énorme pile logicielle. Au cas où j'aurais besoin de la réponse brute des sources interrogées, je stocke toutes les réponses de l'API dans un fichier JSON. De cette manière, je peux créer une structure de données entièrement nouvelle si nécessaire,
sans perdre de données.

Conseils pour les débutants

Même si vous allez développer vos propres procédures de suivi des infrastructures, je souhaite donner quelques conseils aux personnes qui débutent, en espérant que les conseils suivants vous seront utiles.

1. Combiner différentes ressources.

Afin d'obtenir l'image la plus précise possible de l'infrastructure utilisée par les adversaires, il est très utile de combiner plusieurs services qui fournissent différents types d'informations. Outre les données relatives à l'hôte (par exemple Censys ou Shodan), la navigation dans l'infrastructure peut être améliorée grâce aux données DNS passives (par exemple RiskIQ ou Domaintools) et aux données relatives aux certificats (par exemple Censys ou crt.sh). Si vous consommez des données provenant de différents fournisseurs, vous pouvez utiliser un modèle de données commun.⁵.

2. Stocker les résultats de manière flexible et consultable.

Après avoir commencé le suivi de l'infrastructure, vous allez finir par avoir beaucoup de données entre les mains et vous voudrez certainement être en mesure d'effectuer des recherches dans ces données très rapidement. Le fait d'avoir vos données dans un cluster elasticsearch ou un stockage de données consultable similaire vous fera gagner beaucoup de temps. Lorsque vous configurez votre ensemble d'outils, gardez à l'esprit que vous souhaiterez peut-être effectuer des recherches dans vos données à l'aide d'expressions régulières.

3. Conserver les anciens résultats.

Ne supprimez pas les résultats des anciennes recherches. La conservation et la mise à jour des informations sur les hôtes permettent de découvrir des modèles intéressants. Il est également très utile de disposer des dates de première et de dernière consultation des serveurs C2.

4. Documentez vos demandes.

Le nombre croissant de requêtes doit être documenté d'une manière ou d'une autre, faute de quoi vous perdrez la vue d'ensemble. Un bon point de départ consiste à créer un schéma2 qui inclut des métadonnées telles qu'une description.

Conclusion

Les acteurs de la menace sont soumis aux mêmes contraintes que les défenseurs du réseau : temps, argent, compétences et paresse. Cela les conduit à commettre des erreurs ou à prendre certaines habitudes lors de la mise en place de leur infrastructure. Avec un peu de créativité et d'outils, les défenseurs du réseau peuvent exploiter ces erreurs et ces habitudes pour traquer l'infrastructure malveillante. La récompense sera des IoC et des informations sur les activités des attaquants. Censys et d'autres outils donnent aux analystes une bonne longueur d'avance. La magie réside alors dans les requêtes que vous écrivez. J'espère que les techniques et les conseils ci-dessus vous ont été utiles. Je serais heureux de connaître vos expériences, vous pouvez me contacter via Twitter.⁶ ou Keybase⁷.

1. _{Comparer p. 75 Steffens, Timo (2020). Attribution des menaces persistantes avancées.
   https:// doi.org/10.1007/978-3-662-61313-9}
2. _{Comparez https://github.com/BCSECURITY/Empire/blob/master/lib/listeners/http.py#L262}
3. _{NCSC-UK (2020). L'APT29 cible le développement du vaccin COVID-19.
   https://www.ncsc.gov.uk/files/Advisory-APT29-targets-COVID-19-vaccinedevelopment.pdf (consulté le 2020-09-21)}
4. _{PwC UK (2020). Logiciel malveillant WellMess : analyse de son serveur de commande et de contrôle (C2)
   server. https://www.pwc.co.uk/issues/cyber-security-services/insights/wellmessanalysis-command-control.html (consulté le 2020-09-21)}
5. _{Modèle de données OSINT commun pour l'analyse des infrastructures :
   https://github.com/3c7/common-osint-model (consulté le 2020-09-21)}
6. _{https:// twitter.com/0x3c7}
7. _{https://keybase.io/nkuhnert}