Threat intelligence et APT

1. Théorie

1.1 Un peu d'histoire

Commençons par quelques généralités pour nous mettre en bouche. La terminologie « threat intelligence » est apparue vers le début de l’année 2011. À cette période, le monde est en effervescence à cause des premiers grands cas d’APT médiatisés. Les industriels fourbissent leurs premières armes dans le champ de bataille « cyber ».

Pour autant, le concept de threat intelligence n’est pas nouveau et certaines organisations, de type étatique et de type défense utilisaient déjà le concept de renseignement opérationnel sur Internet via diverses techniques bien avant 2011.

Aujourd’hui, ce terme est devenu un vrai buzz word et est pour ainsi dire utilisé à toutes les sauces. Quelle société de conseil, quel vendeur de solutions ne dispose pas (sur le papier et les PowerPoint) de sa capacité de threat intelligence ?

1.2 Les concepts : cycle du renseignement

Il est peut être nécessaire de préciser au lecteur qu’intelligence en anglais signifie renseignement en français. Et par essence, la threat intelligence (soit donc le renseignement sur la menace) se base sur les mêmes grands principes que le renseignement traditionnel.

Le renseignement fonctionne sur la base d’un cycle [1]. Chaque opération suit ainsi un processus assez logique passant par plusieurs étapes :

• La planification et la direction constituent les notions de base permettant de définir l’objectif à atteindre. Cette direction peut elle-même être conditionnée par des premières conclusions d’investigation.
• La collecte passe par la capture de données en orientant des capteurs de tout type. Différents types de capteurs peuvent être utilisés comme des capteurs humains (renseignement historique), des capteurs électroniques, des capteurs satellitaires, des capteurs de signaux et des capteurs sur données ouvertes. Bien évidemment, la collecte non étatique reste cantonnée au dernier secteur.
• La mise à profit des données permet de tirer le bénéfice d’outils ou de traitements qui vont consolider des informations nécessaires à la suite des opérations à partir des données collectées.
• La phase d’analyse permet un traitement plus qualifié, plus humain aussi dans lequel un analyste (logique) vient apporter son expertise métier pour agréger des informations de prime abord décorrélées, pour les interpréter et effectuer une synthèse qui viendra s’ajouter à une base de renseignements.
• La phase de dissémination consiste à mettre à profit le renseignement généré à un donneur d’ordre ou à un public plus large.

Faisons maintenant un parallèle simple avec les activités de threat intelligence pour que tout s’éclaire :

• La direction consiste à investiguer autour d’un groupe d’attaquants ;
• La collecte s’appuie sur une capacité à capturer des contenus OSINT intéressants (diverses sources d’information fournissant de la matière pertinente) ;
• Le traitement (automatique) consiste à simplifier les données collectées, les regrouper, les enrichir, les corréler, les structurer et certainement les indexer ;
• L’analyse (traitement manuel) consiste à utiliser les informations consolidées pour les valider, les affiner, les agréger, les contextualiser et les structurer dans un format opérationnellement exploitable ;
• La dissémination permet de partager les renseignements obtenus auprès d’une communauté intéressée.

1.3 Formats de modélisation

Pour mettre en œuvre la dissémination, il est bien nécessaire d’utiliser des supports et des formats définis. Cela va permettre à l’émetteur et au destinataire de pouvoir échanger des informations structurées mettant en évidence des caractéristiques précises d’une menace particulière.

Le problème c’est que selon la menace concernée, la façon de la représenter est différente. Historiquement, le problème vient de l’industrie éditrice qui a orienté la façon de percevoir une menace non pas par rapport à ce qu’elle est ou ce qu’elle représente, mais par rapport à la capacité de l’éditeur de l’aborder.

Ainsi, il existe plusieurs formats plus ou moins utilisés pour décrire les menaces :

1.3.1 SNORT

Le format SNORT est apparu avec la solution open source du même nom et a été très largement utilisé jusqu’à aujourd’hui pour détecter des menaces se propageant sur le réseau.

Il a l’avantage d’être très pertinent pour décrire un comportement réseau particulier.

La règle SNORT ci-dessous peut être utilisée en contexte APT pour détecter des infections initiales associées à Scanbox (crédit AlienVault [2]) :

1.3.2. Open IOC

Le format OpenIOC a déjà été décrit dans un article MISC [3] dédié. En synthèse, on retiendra que ce format a été proposé à la communauté par la société Mandiant®. Ce format est utilisé par les outils de la même société (maintenant FireEye®) pour définir ce qui est malveillant. À l’inverse du format SNORT, le format IOC a l’avantage d’être pertinent pour caractériser une malveillance affectant un poste de travail.

La règle IOC ci-dessous peut être utilisée en contexte APT pour détecter la présence d’une payload délivrée par Sofacy (crédit FireEye [4]) :

1.3.3 Yara

Le format Yara est très largement utilisé dans la communauté threat intelligence pour pouvoir caractériser des codes malveillants. Il a été décrit dans un article MISC [5] dédié. Ce format ne se focalise que sur les caractéristiques intrinsèques d’un fichier et est particulièrement pertinent pour identifier des souches de familles de code malveillant.

La règle Yara ci-dessous peut être utilisée en contexte APT pour détecter un malware de type Pitty Tiger (crédit Airbus Defence & Space [6]) :

1.3.4 STIX

STIX fait partie d’un ensemble de modélisation proposé par le MITRE [7]. Autour de cette famille, figurent également TAXII, Cybox, CAPEC, MAEC. Pour la suite de cet article et pour rendre le discours plus limpide, le terme STIX sera utilisé (abusivement) pour décrire l’ensemble de ces catégories.

STIX s’insère à un niveau de représentation au-dessus des autres formats évoqués précédemment. En effet, STIX a pour vocation de pouvoir modéliser un attaquant plutôt que de mettre l’accent sur un événement particulier causé par ce même attaquant. La figure 4 donne un bon aperçu.

Dans STIX, les éléments observables (NDLA : « on devrait ici parler de Cybox ») représentent certainement ce qui est le plus facilement utilisable pour caractériser les activités unitaires d’un attaquant et générer des contenus assimilables à des signatures :

La structure ci-dessous peut être utilisée en contexte APT pour exprimer qu’un bloc d’adresse particulier était utilisé dans le contexte des attaques observées par le groupe APT1/Comment Crew.

1.4 Les mots clés essentiels

STIX permet de modéliser les concepts clés de threat intelligence de manière assez logique. Toutes les structures qui y sont rattachées ont du sens dans une approche de threat intelligence. Les concepts les plus intéressants sont les suivants :

• L’observation correspond à la caractéristique unitaire de la concrétisation d’une attaque sur le système d’information (ie : création d’une clé dans la base de registre).
• L’indicateur correspond à un ensemble d’observations qui attestent d’un comportement propre d’une attaque. L’indicateur peut être borné dans le temps ou bien encore associé à une sensibilité particulière.
• TTP (Tactics, Techniques and Procedures) est un acronyme revenant souvent en threat intelligence et décrivant les modes opératoires de l’attaquant. C’est le point d’articulation majeur menant à l’attribution.
• L’attaquant est utilisé pour décrire l’agresseur, celui-ci pouvant être un acteur individuel ou une structure étatique particulièrement complexe.
• La campagne correspond à une instance d’attaque opérée par l’attaquant et associée à certaines caractéristiques de son mode opératoire.
• L’incident correspond à ce à quoi est confrontée la victime lorsque l’attaquant vise son système d’information lors d’une campagne particulière.
• Le plan d’action correspond à une stratégie opérationnelle que la victime peut déployer lorsqu’un incident avec certaines caractéristiques se produit.

2. La threat intelligence par la pratique

Maintenant que les fondations théoriques sont posées, passons au concret. Comme tout bon bricoleur, le spécialiste threat intelligence a besoin d’une trousse à outils et idéalement d’avoir survolé les notices des outils les plus complexes.

2.1 Les outils

Un attaquant cherche souvent à amortir son investissement. D’un point de vue technique, cela signifie que l’infrastructure qu’il met en place lui sert plusieurs fois et que des familles de malwares (développées en interne ou intégrés) seront utilisées (beaucoup) plus d’une fois.

Pour que son infrastructure serve, il faut qu’elle existe (adresse(s) IP), qu’elle soit routée (distribution de préfixes via BGP), voire qu’elle passe inaperçue lorsqu’elle est sollicitée via un proxy d’entreprise (utilisation de records DNS).

Pour que son logiciel attaquant serve, il faut qu’il existe (MD5/SHA1), qu’il fonctionne (entry point, table d’import, MUTEX…) et qu’il communique vers un serveur de contrôle (C&C).

Toutes ces informations sont autant de potentielles pistes qui peuvent être activées pour creuser durant l’investigation avec différents outils.

2.1.1 Moteurs de recherche

Pour reprendre un vieil adage, Google est ton ami. Toutes les investigations threat intelligence démarrent (si le contexte le permet) par des recherches en source ouverte. Tous les candidats sont bons : un MD5 pour identifier un résultat indexé de sandbox, un MUTEX pour identifier un article blog, une adresse IP pour identifier un document technique de référence.

Il est presque rare de ne pas trouver le moindre indice sur Google lors d’une investigation. Lorsque cela arrive, il faut déployer de plus grands moyens…

Commençons donc une investigation sur le magazine MISC, cf. figure 5.

Ceci nous amène sur l’intérêt de mettre le focus sur le site miscmag.com.

2.1.2 Investigation DNS

L’utilisation de noms de domaines est très souvent mise à profit par les attaquants en contexte APT. En effet, les communications en dur sur adresse IP sont de moins en moins utilisées et donc facilement identifiables dans des logs de proxy par exemple.

Pour chaque nom de domaine utilisé, l’attaquant va utiliser une ou plusieurs entrées. Ces entrées vont être associées à une adresse IP au niveau d’un serveur DNS d’autorité.

L’attaquant a plusieurs alternatives pour utiliser des enregistrements DNS :

• utiliser des noms de domaine en propre qu’il acquiert ;
• utiliser des services de noms de domaine dynamiques et s’attribuer un enregistrement qu’il fait pointer sur différentes adresses ;
• compromettre un serveur DNS d’autorité et rajouter des enregistrements ;
• compromettre des identifiants d’accès à un registrar et rajouter des enregistrements.

Les deux premières alternatives sont les plus couramment utilisées en contexte d’attaque ciblée.

Il est bien entendu possible de faire la correspondance entre un enregistrement DNS et son adresse IP à un instant T, mais il est également possible de retrouver les traces de ces associations dans le passé via des services de « passive DNS ». Ces solutions sont associées à des serveurs DNS récursifs souvent chargés de jouer le rôle de cache DNS à l’échelle d’une organisation ou d’un fournisseur d’accès. Les solutions de « passive DNS » historisent tous les changements d’association enregistrement-adresse IP et permettent ainsi de « remonter le temps » pour savoir à quelle infrastructure physique était raccroché un enregistrement dans le passé.

L’exemple figure 6 montre ainsi l’évolution du site miscmag.com.

Depuis 2010, le site a ainsi été « déplacé » selon la succession suivante :

Complétons l’analyse par la mise en correspondance de webredir.vip.gandi.net, cf. figure 7.

Nous obtenons donc une succession sur 3 adresses :

2.1.3 Investigation IP

L’attaquant n’a pas d’autre choix que d’utiliser un point physique sur le système d’information de sa cible et un point physique pour en sortir. D’un point de vue séquencement d’une attaque ciblée, cela signifie qu’une (ou plusieurs) adresse a été utilisée pour la compromission initiale, qu’une (ou plusieurs) adresse a été utilisée pour le maintien sur le système d’information et qu’une (ou plusieurs) adresse a été utilisée pour l’exfiltration. Toutes ces adresses peuvent en être une seule et même.

Quelques outils sont intéressants pour savoir ce qui se cache derrière une adresse :

• La résolution inverse DNS (enregistrement PTR) nous renseigne sur une éventuelle association avec un enregistrement DNS. Dans notre cadre, nous n’avons aucun résultat probant :

• La recherche de correspondance DNS passée (passive DNS) est une autre piste puisqu’elle peut être ciblée sur les réponses (les adresses IP). Dans notre investigation, cette piste est probante pour l’adresse 94.23.37.165 comme le montre la figure 8.

Quasiment tous ces sites sont associés aux Éditions Diamond. Seul le site institutionnel d’un avocat étonne quelque peu. Il s’agit probablement d’un proche des Éditions Diamond ou bien du « Maître » de MISC…

Le nombre de résultats figures 9 et 10 nous montre l’utilisation de serveurs fortement mutualisés.

Nous pouvons d’ores et déjà établir que miscmag.com :

• était localisé sur une machine dédiée de 2010 à 2012 ;
• était localisé sur un serveur mutualisé chez Gandi de 2012 à 2014 ;
• était localisé sur un serveur mutualisé de 2014 à 2015.

2.1.4 Investigation Whois

Si l’attaquant utilise un nom de domaine qui n’est pas volé, il aura dû au préalable créer un compte auprès d’un opérateur d’enregistrement de noms de domaines (plus communément appelé registrar ou encore bureau d’enregistrement). Ce registrar va stocker les données déclarées par le déposant et procéder à l’enregistrement du domaine avec les données associées dans un registre central qui a autorité sur la zone extension (par exemple l’AFNIC pour le .fr). Chaque registre met (la plupart du temps) à disposition un serveur whois qui va permettre de faire l’association entre un domaine précis et les informations saisies par l’attaquant.

La démarche est globalement à peu près similaire entre un opérateur de registre de noms de domaines et un opérateur de blocs d’adresses IP (ie RIPE pour la plaque Europe). Dans ce cas, il y a distinction entre le « domain whois » et le « network whois ».

Considérons le network whois, et avançons notre investigation :

Nous voyons qu’il s’agit d’une plage dédiée chez OVH.

La même commande whois sur l’adresse 213.186.33.3 nous donne :

Nous en sommes donc au stade suivant, miscmag.com était hébergé :

• sur un serveur dédié OVH de 2010 à 2012 ;
• sur un serveur mutualisé Gandi de 2012 à 2014 ;
• sur un serveur mutualisé OVH de 2014 à 2015.

L’investigation des données « fraîches » s’avère souvent peu fructueuse pour trouver des informations intéressantes. Par contre, la genèse du nom de domaine présente souvent un gros potentiel. Ainsi, le premier enregistrement peut correspondre :

• à un domaine créé par l’attaquant avec ses vraies coordonnées ;
• à un domaine créé par l’attaquant avec des informations qui se recoupent rapidement vers d’autres zones de malveillance.

Poursuivons notre petite investigation via cette approche à l’aide de Domain Tools. Nous observons de nombreux changements sur le domaine depuis 2003. Certains de ces changements sont particulièrement intéressants. Ainsi en 2003, un certain Frédéric Raynal apparaît dans l’enregistrement technique whois :

En septembre 2006, ce même Frédéric décide de changer d’adresse, de rentrer des coordonnées téléphoniques douteuses et d’anonymiser son adresse e-mail :

Le 27 février 2008, une petite blague apparaît pour un retour à la normale le 13 mai :

Le 11 septembre 2011, le siège de Diamond change pour passer du 6 rue de la Scheer à Sélestat au 4 rue Antoine Jeanjean dans la même ville. Google Street View ® nous permettra d’ailleurs de voir l’enseigne à la nouvelle adresse.

Le 24 octobre 2013, les coordonnées physiques s’offusquent et deviennent celles du registrar (Gandi) :

Accessoirement, de vieilles entrées récupérées via whois nous indiquent aussi que l’hébergement a évolué plus que ce que nous avions déjà identifié pour suivre la chaîne suivante :

• 15/05/2004 : 194.246.101.80 ;
• 22/10/2005 : 213.251.163.117 ;
• 21/10/2007 : 213.186.60.195 ;
• 29/06/2008 : 91.121.166.153 ;
• 25/08/2009 : 94.23.37.165 ;
• 14/03/2012 : 217.70.184.38 ;
• 02/10/2014 : 213.186.33.3.

Une recherche dans les bases Whois de l’adresse e-mail 70a5ec4857790f2c16298597c942a6c1-–REDACTED-@contact.gandi.net nous montre quelques domaines associés plus ou moins connus :

• miscmag.com créé en décembre 2001 et hébergé sur 213.186.33.3 (OVH mutualisé) ;
• security-labs.org créé en août 2002 et hébergé sur 91.121.7.10 (OVH dédié) ;
• gotham-city.org créé en mars 2003 et pointant sur security-labs.com ;
• seclabs.org créé en juillet 2007 et pointant sur security-labs.com ;
• aslr.org créé en août 2010 et hébergé sur 88.191.145.194 (Dedibox) ;
• quarkslab.com, net et org créés en septembre 2011 et hébergés sur 5.135.189.206 (OVH dédié) ;
• etchegroup.com créé en février 2012 et hébergé sur 195.154.127.203 (Iliad dédié) ;
• my-little-french-entrepreneurship.com, net et org créés en juin 2014 et hébergés sur 217.70.180.153 (gandi) ;
• irma-project.com créé en août 2014 et hébergé sur une page générique hébergeur ;
• cappsule.org créé en août 2014 et hébergé sur une page générique hébergeur.

Bref, à partir de ce cas concret sur MISC, beaucoup de choses potentiellement intéressantes ressortent. Cette approche essentiellement focalisée sur des données techniques réseau nous permet de la même façon de modéliser une infrastructure attaquante rapidement.

Dans une activité professionnelle, tout ce que nous avons vu doit aller très vite (quelques minutes). L’automatisation permet d’accélérer les choses et de représenter les résultats d’investigation rapidement comme le montre la figure 11.

2.1.5 Investigation malware

Quasiment toutes les campagnes d’attaques utilisent des codes malveillants. Penser threat intelligence sans considérer la partie malware serait une grave erreur. De nombreuses informations extractibles de l’analyse statique ou dynamique d’un code malveillant sont intéressantes pour établir des relations. La petite liste ci-dessous est bien entendu non exhaustive :

• hash du binaire ;
• table d’imports / ImpHash ;
• points de communication ;
• MUTEX ;
• MD5 de sections ;
• clés de chiffrements ;
• CVE utilisés ;
• certificats associés ;
• URI ;
• …

Toutes ces informations permettent de faire des recoupements permettant par exemple :

• d’observer l’évolution de souches vers des variantes plus complexes ;
• d’identifier un groupe APT « state sponsored » utilisant les mêmes outils pour des campagnes avec des objectifs bien distincts ;
• d’associer un logiciel malveillant à une plateforme d’attaquants connue ;
• d’identifier la montée en puissance d’un groupe dans l’acquisition d’exploits 0day.

2.1.6 Investigation sur individus

Un groupe d’attaquants est constitué de personnes. Ces dernières laissent parfois des traces qui permettent de prolonger l’investigation. Nous avons touché du doigt la liaison entre des individus et des enregistrements Whois, mais un malware peut également présenter des chaînes de caractères (strings) permettant d’identifier son auteur.

Une fois la piste activée, plusieurs canaux sont pertinents pour retrouver de l’information sur ces personnes, les plus intéressants étant les moteurs de recherche, les réseaux sociaux et les forums fermés.

2.1.7 Autres investigations

Le champ des possibles est encore vaste pour dresser le panorama des différents moyens utilisables pour densifier une investigation. Celles que nous avons présentées sont conformes à la réglementation.

2.2 Des données aux renseignements

Conformément au cycle du renseignement, à l’issue de la phase de collecte, les données sont traitées pour produire des informations. Ces informations sont quant à elles analysées pour produire des renseignements.

Dans notre investigation didactique précédente, nous avons manipulé des données et obtenu des informations. Les quelques pistes d’intérêt que nous avons identifiées mériteraient alors d’être complétées pour être traduites en connaissance exploitable.

2.2.1 Les flux de données

La calibration des sources de données est essentielle pour rendre plus efficaces les étapes en aval. Différentes sources sont pertinentes en matière de threat intelligence comme :

• des bases de connaissances disponibles en source ouverte ;
• des flux de données commerciaux (ou communautaires) fournissant des synthèses de détection de menaces provenant elles-mêmes d’autres sources ;
• des rapports d’éditeurs spécialisés ;
• des listes d’échange fermées.

Toutes ces données collectées sont intéressantes, mais certaines contraintes doivent être prises en compte :

• certaines données sont plus ou moins fiables et il faut donc prendre en compte la confiance dans la source avant de les utiliser ;
• certaines données anciennes ont moins d’intérêt que des données récentes (en opposition avec les enregistrements whois), leur importance est donc à sous-pondérer ;
• certaines données sont associées à des critères de diffusion (TLPi [8]) particuliers et ne sont potentiellement pas réutilisables dans la chaîne de traitement.

2.2.2 L'enrichissement via les traitements

Notre investigation précédente a bien montré l’intérêt d’utiliser des solutions tierces pour enrichir la donnée ciblée. L’enrichissement peut être fait selon deux angles :

• l’axe temporel visant à connaître l’histoire de cette donnée ;
• l’axe environnemental visant à comprendre le contexte dans lequel cette donnée évolue.

Deux exemples ultra simples pour éclairer le propos :

• temporel : un enregistrement DNS potentiellement suspect résout vers localhost, mais des analyses de résolutions passées peuvent montrer une association avec une adresse IP connue comme malveillante.
• environnemental : un C&C est hébergé sur un serveur dédié fortement suspect, mais le contexte peut montrer que ce même serveur est celui d’une victime compromise qui n’aura pas appliqué des mises à jour.

De multiples algorithmes peuvent rentrer en compte pour valoriser temporellement et contextuellement les données d’entrée pour en faire des informations à forte valeur ajoutée.

2.2.3 L'analyse et la mise en relation

Les outils c’est bien, mais l’humain c’est mieux ! La phase la plus intéressante, mais aussi la plus complexe reste le travail d’association, d’investigation manuelle et de génération d’hypothèses. C’est celle qui est dévolue aux analystes.

Au final, ce travail de modélisation de la menace a pour but de caractériser les capacités d’un groupe d’attaquants.

Attention, nous parlons ici d’attribution, le mot qu’il est interdit de prononcer… Le terme fait peur et pourtant il s’agit ni plus ni moins que de consolider des faisceaux de présomptions pouvant se transformer en preuves.

À ce stade, trois écoles « s’affrontent » pour tenter de faire de l’attribution :

Le premier modèle utilise STIX. Il est très complet, comme vu précédemment et propose d’utiliser les campagnes d’attaque, les incidents, et les TTP pour établir des liens vers un attaquant ;

Le deuxième modèle, appelé modèle diamant, beaucoup plus simple, propose quant à lui une approche basée sur quatre éléments :

• L’adversaire, correspondant à celui qui réalise les attaques ;
• L’infrastructure mise à profit par l’attaquant et qui est utilisée dans l’environnement de la victime ;
• Les capacités techniques qui sont déployées sur le système d’information de la victime (logiciel malveillant par exemple) et qui utilisent notamment l’infrastructure ;
• La victime qui est confrontée à tout cela.

Le dernier modèle, plus pragmatique consiste à utiliser le meilleur des deux mondes, mais sans structure particulière, en faisant simplement confiance à l’expérience ou à l’intuition des analystes expérimentés. En pratique, cela fonctionne aussi assez bien.

Conclusion

APT ou pas, les techniques de threat intelligence vues dans cet article restent les mêmes (à quelques « équations » près).

La réalité Internet est la même pour tout le monde, acteur étatique ou petit cybercriminel. La threat intelligence utilise ce constat à outrance.

Soyons bien clairs cependant, il s’agit ici de techniques de base d’investigation. Des investigations complètes et complexes mélangent souvent des outils publics, des outils non publics, de la méthode, des contacts, de l’expérience et de l’intuition.

Merci à Cédric Pernet pour sa relecture ainsi qu’à Yoann Francou qui s’est « investy » sur ce sujet.

Références

[1] http://en.wikipedia.org/wiki/Intelligence_cycle

[2] http://www.alienvault.com/open-threat-exchange/blog/scanbox-a-reconnaissance-framework-used-on-watering-hole-attacks

[3] MISC n°64, IOC, indicateurs de compromission (Saâd Kadhi) : https://connect.ed-diamond.com/MISC/MISC-064/IOC-indicateurs-de-compromission

[4] https://github.com/fireeye/iocs/blob/master/APT28/a6c6dbf0-d72a-4f07-8b11-55527aef4755.ioc

[5] MISC n°65, Détection et classification de malware par Yara (Cédric Pernet) : https://connect.ed-diamond.com/MISC/MISC-065/Detection-et-classification-de-malwares-par-Yara

[6] http://blog.cassidiancybersecurity.com/post/2014/07/The-Eye-of-the-Tiger2

[7] https://stix.mitre.org/

[8] https://www.us-cert.gov/tlp