En enquêtant sur des affaires impliquant le phishing, les botnets, les transactions frauduleuses et les groupes de hackers criminels, les experts de Group-IB utilisent depuis de nombreuses années l'analyse graphique pour détecter divers types de relations. Dans différents cas, il existe des ensembles de données, des algorithmes de détection de relations et des interfaces adaptés à des tâches spécifiques. Tous ces outils ont été développés en interne par Group-IB et n'étaient disponibles que pour nos employés.

L'analyse graphique de l'infrastructure réseau (graphique réseau) est devenu le premier outil interne que nous avons intégré dans tous les produits publics de l'entreprise. Avant de créer notre graphique réseau, nous avons analysé de nombreux développements similaires sur le marché et n'avons trouvé aucun produit répondant à nos besoins spécifiques. Dans cet article, nous expliquerons comment nous avons créé le graphique réseau, comment nous l'utilisons et les difficultés que nous avons rencontrées.

Dmitry Volkov, CTO de Group-IB et responsable de la direction de la cyberintelligence

Quelles sont les capacités du graphique réseau de Group-IB ?

Enquêtes

Depuis la fondation de Group-IB en 2003 jusqu'à aujourd'hui, l'identification, le dé-anonymat et la poursuite des cybercriminels sont nos principales priorités. Aucune enquête sur une cyberattaque n'a été menée sans analyse de l'infrastructure réseau des attaquants. Au début de notre parcours, il s'agissait d'un travail manuel minutieux à la recherche de liens pouvant aider à identifier les criminels : informations sur les noms de domaine, adresses IP, empreintes numériques des serveurs, etc.

La plupart des attaquants essaient d'agir de manière aussi anonyme que possible en ligne. Cependant, comme tout le monde, ils font des erreurs. L'objectif principal de cette analyse est de trouver des projets historiques « blancs » ou « gris » des cybercriminels qui ont des liens avec l'infrastructure malveillante utilisée dans l'incident actuel que nous enquêtons. Si nous parvenons à découvrir des « projets blancs », il devient généralement trivial de trouver l'attaquant. En ce qui concerne les « gris », la recherche prend plus de temps et d'efforts, car leurs propriétaires essaient d'anonymiser ou de cacher les données d'enregistrement, mais les chances restent suffisamment élevées. En général, au début de leurs activités criminelles, les attaquants prêtent moins attention à leur sécurité et commettent plus d'erreurs, donc plus nous pouvons nous plonger dans l'historique, plus les chances de succès de l'enquête augmentent. C'est pourquoi un graphe réseau avec une bonne histoire est un élément extrêmement important de ce type d'enquête. En d'autres termes, plus une entreprise dispose de données historiques approfondies, plus son graphe sera de qualité. Supposons qu'une histoire de 5 ans puisse aider à résoudre, conditionnellement, 1 à 2 des 10 crimes, tandis qu'une histoire de 15 ans offre des chances de résoudre les dix.

Détection du phishing et de la fraude

Chaque fois que nous recevons un lien suspect vers des ressources de phishing, frauduleuses ou piratées, nous construisons automatiquement un graphe des ressources réseau liées et vérifions tous les hébergeurs trouvés pour voir s'ils contiennent du contenu similaire. Cela nous permet de trouver à la fois de vieux sites de phishing qui étaient actifs mais inconnus, ainsi que des sites totalement nouveaux, qui sont préparés pour de futures attaques mais ne sont pas encore utilisés. Un exemple élémentaire, qui se rencontre assez souvent : nous avons trouvé un site de phishing sur un serveur où il n'y a que 5 sites. En vérifiant chacun d'eux, nous trouvons également du contenu de phishing sur les autres sites, ce qui signifie que nous pouvons bloquer 5 au lieu de 1.

Recherche de backends

Ce processus est nécessaire pour déterminer où se trouve réellement le serveur malveillant.
99 % des card shops, des forums de hackers, de nombreux sites de phishing et d'autres serveurs malveillants se cachent derrière à la fois leurs propres serveurs proxy et ceux de services légitimes, comme Cloudflare. Connaître le véritable backend est crucial pour les enquêtes : il devient possible d'identifier le fournisseur d'hébergement dont le serveur peut être saisi, et de créer des liens avec d'autres projets malveillants.

Par exemple, vous avez un site de phishing pour collecter des données de cartes bancaires qui resolve à l'adresse IP 11.11.11.11, et l'adresse du card shop qui resolve à l'adresse IP 22.22.22.22. En analysant, il peut s'avérer que le site de phishing et le card shop partagent une adresse IP backend commune, par exemple, 33.33.33.33. Ces informations permettent d'établir un lien entre les attaques de phishing et le card shop, où des données de cartes bancaires sont probablement vendues.

Corrélation des événements

Lorsque vous avez deux alertes différentes (supposons, sur IDS) avec des malwares différents et des serveurs distincts pour la gestion de l'attaque, vous les considérerez comme deux événements indépendants. Mais s'il existe de bonnes liaisons entre les infrastructures malveillantes, il devient évident qu'il ne s'agit pas de différentes attaques, mais des étapes d'une attaque plus complexe et multi-niveaux. Et si l'un des événements a déjà été attribué à un groupe d'attaquants, le second peut également être attribué à ce même groupe. Bien sûr, le processus d'attribution est beaucoup plus complexe, donc considérez ce qui précède comme un simple exemple.

Enrichissement des indicateurs

Nous n'allons pas nous attarder trop là-dessus, car il s'agit du scénario d'utilisation le plus courant des graphes en cybersécurité : vous entrez un indicateur, et en sortie, vous obtenez un ensemble d'indicateurs liés.

Détection de motifs

La détection de motifs est essentielle pour une chasse efficace. Les graphes permettent non seulement de trouver des éléments connexes, mais aussi de dégager des propriétés communes qui sont propres à un certain groupe de hackers. Connaître de telles caractéristiques uniques permet de reconnaître l'infrastructure des attaquants dès la phase de préparation, et sans les preuves qui confirment l'attaque, telles que des emails de phishing ou des logiciels malveillants.

Pourquoi avons-nous créé notre graphe réseau ?

Je me répète, nous avons examiné des solutions de différents fournisseurs avant de conclure qu'il nous fallait développer notre propre outil capable de réaliser ce qu'aucun produit existant ne peut faire. Sa création a pris plusieurs années, période durant laquelle nous l'avons entièrement refondu à plusieurs reprises. Toutefois, malgré la longue durée de développement, nous n'avons toujours pas trouvé d'analogue répondant à nos exigences. Grâce à notre produit, nous avons finalement pu résoudre presque tous les problèmes identifiés dans les graphes réseau existants. Examinons ces problèmes en détail ci-dessous :

Le problème
Solution

Absence de fournisseur avec différentes collections de données : domaines, DNS passifs, SSL passif, enregistrements DNS, ports ouverts, services en cours d'exécution sur les ports, fichiers interagissant avec les noms de domaine et les adresses IP. Explication. En général, les fournisseurs proposent des types de données séparés, et pour obtenir une image complète, il faut acheter des abonnements chez chacun. Mais même dans ce cas, il n'est pas toujours possible d'obtenir toutes les données : certains fournisseurs de SSL passif ne fournissent des données que sur les certificats émis par des CA de confiance, et la couverture des certificats auto-signés est très faible. D'autres fournissent également des données sur les certificats auto-signés, mais ne les recueillent que sur des ports standards.
Nous avons collecté toutes les collections mentionnées ci-dessus nous-mêmes. Par exemple, pour recueillir des données sur les certificats SSL, nous avons développé notre propre service qui les collecte tant auprès des CA de confiance qu'en scannant l'intégralité de l'espace IPv4. Les certificats étaient collectés non seulement à partir des adresses IP, mais aussi de tous les domaines et sous-domaines de notre base : si vous avez un domaine example.com et son sous-domaine www.example.com et tous se résolvent en IP 1.1.1.1, lorsque vous essayez d'obtenir un certificat SSL sur le port 443 via l'IP, le domaine et son sous-domaine, vous pouvez obtenir trois résultats différents. Pour collecter des données sur les ports ouverts et les services en cours d'exécution, nous avons dû créer notre propre système de scan distribué, car d'autres services avaient souvent les adresses IP de leurs serveurs de scan « blacklistées ». Nos serveurs de scan sont également inscrits sur des « listes noires », mais le taux de détection des services recherchés est supérieur à celui de ceux qui se contentent de scanner le maximum de ports possible et de vendre l'accès à ces données.

L'absence d'accès à l'ensemble de la base de données historiques. Explication. Chaque fournisseur normal dispose d'une bonne histoire accumulée, mais pour des raisons évidentes, nous en tant que client n'avons pas pu accéder à toutes les données historiques. C'est-à-dire que vous pouvez obtenir toute l'histoire d'un enregistrement particulier, par exemple, d'un domaine ou d'une adresse IP, mais vous ne pouvez pas voir l'historique global — sans cela, il est impossible de voir le tableau complet.
Pour rassembler le plus d'enregistrements historiques possibles sur les domaines, nous avons acquis diverses bases de données, exploré de nombreuses ressources ouvertes qui possédaient cet historique (heureusement, il y en avait beaucoup), et négocié avec les registraires de noms de domaine. Toutes les mises à jour dans nos propres collections sont bien sûr conservées avec un historique complet des modifications.

Toutes les solutions existantes permettent de construire le graphe manuellement. Explication. Supposons que vous ayez acheté de nombreux abonnements auprès de tous les fournisseurs de données possibles (généralement appelés « enrichisseurs »). Lorsque vous devez construire un graphe, vous donnez manuellement l'ordre de l'étendre à partir de l'élément de connexion souhaité, puis parmi les éléments apparus, vous choisissez les nécessaires et donnez l'ordre d'étendre encore les connexions, et ainsi de suite. Dans ce cas, la responsabilité de la qualité de la construction du graphe repose entièrement sur l'homme.
Nous avons automatisé la construction des graphes. C'est-à-dire que si vous devez créer un graphe, les connexions à partir du premier élément se construisent automatiquement, puis celles de tous les suivants également. Le spécialiste indique simplement la profondeur à partir de laquelle le graphe doit être construit. Le processus d'extension automatique des graphes est simple, mais d'autres fournisseurs ne l'implémentent pas car il génère un grand nombre de résultats non pertinents, et cet inconvénient a également dû être pris en compte (voir ci-dessous).

De nombreux résultats non pertinents sont un problème commun à tous les graphes d'éléments réseau. Explication. Par exemple, un « mauvais domaine » (qui a participé à une attaque) est lié à un serveur avec lequel 500 autres domaines ont été associés au cours des 10 dernières années. Lors de l'ajout manuel ou de la construction automatique du graphe, tous ces 500 domaines doivent également apparaître dans le graphe, même s'ils n'ont aucun lien avec l'attaque. Ou, par exemple, lorsque vous vérifiez un indicateur IP d'un rapport d'un fournisseur de sécurité. En général, ces rapports sortent avec un délai important et couvrent souvent une période d'un an ou plus. Il est très probable que, au moment où vous lisez le rapport, le serveur avec cette adresse IP ait déjà été loué à d'autres personnes avec d'autres connexions, et la construction du graphe aboutira encore une fois à des résultats non pertinents.
Nous avons formé le système à identifier les éléments non pertinents selon la même logique que celle utilisée par nos experts manuellement. Par exemple, vous vérifiez un mauvais domaine example.com, qui se résout actuellement en IP 11.11.11.11, et qui, il y a un mois, se résolvait en IP 22.22.22.22. L'IP 11.11.11.11 est liée, en plus du domaine example.com, à example.ru, tandis que l'IP 22.22.22.22 est liée à 25 000 autres domaines. Le système, comme un humain, comprend que 11.11.11.11 est probablement un serveur dédié, et puisque le domaine example.ru est similaire par son écriture à example.com, ils sont très probablement liés et doivent figurer sur le graphe ; en revanche, l'IP 22.22.22.22 appartient à un hébergement mutualisé, donc tous ses domaines ne doivent pas apparaître sur le graphe, sauf s'il existe d'autres liens indiquant que l'un de ces 25 000 domaines doit également y figurer (par exemple, example.net). Avant que le système ne comprenne qu'il doit rompre ces liens et ne pas afficher une partie des éléments sur le graphe, il prend en compte de nombreuses propriétés des éléments et des clusters auxquels ces éléments sont réunis, ainsi que la robustesse des liens actuels. Par exemple, si nous avons un petit cluster sur le graphe (50 éléments) qui contient le mauvais domaine, et un autre grand cluster (5 000 éléments) et que les deux clusters sont liés par un lien avec une très faible robustesse (poids), alors ce lien sera rompu et les éléments du grand cluster seront supprimés. Mais si les liens entre le petit et le grand cluster sont nombreux et que leur robustesse augmente progressivement, dans ce cas, le lien ne sera pas rompu et les éléments nécessaires des deux clusters resteront sur le graphe.

Le temps de possession d'un serveur ou d'un domaine n'est pas pris en compte. Explication. La période d'enregistrement des « mauvais domaines » finit par expirer tôt ou tard, et ils sont de nouveau achetés à des fins malveillantes ou légitimes. Même les hébergements bulletproof louent leurs serveurs à différents hackers, il est donc crucial de connaître et de prendre en compte la période pendant laquelle tel ou tel domaine ou serveur était sous la gestion d'un même propriétaire. Nous faisons souvent face à une situation où un serveur avec l'IP 11.11.11.11 est actuellement utilisé comme C&C pour des bots bancaires, alors qu'il y a deux mois, il était contrôlé par un ransomware. Si l'on établit des liens sans considérer les intervalles de possession, il semblerait qu'il existe un lien entre les propriétaires du réseau de bots bancaires et les extorqueurs, alors qu'en réalité, ce n'est pas le cas. Dans notre travail, une telle erreur est critique.
Nous avons appris au système à déterminer les intervalles de possession. Pour les domaines, c'est relativement simple, car dans le whois, les dates de début et d'expiration de l'enregistrement sont souvent indiquées, et lorsqu'il y a un historique complet des modifications whois, il est facile de déterminer les intervalles. Lorsque la période d'enregistrement d'un domaine n'est pas expirée mais que sa gestion a été transférée à d'autres propriétaires, cela peut également être suivi. Pour les certificats SSL, ce problème n'existe pas, car ils sont émis une seule fois, ne sont pas renouvelés et ne sont pas transférés. Mais pour les certificats auto-signés, il ne faut pas faire confiance aux dates indiquées dans la période de validité du certificat, car il est possible de générer un certificat SSL aujourd'hui tout en indiquant la date de début de validité du certificat à partir de 2010. La tâche la plus difficile est de déterminer les intervalles de possession pour les serveurs, car seules les sociétés d'hébergement ont les dates et les périodes de location. Pour déterminer la période de possession d'un serveur, nous avons commencé à utiliser les résultats d'analyse des ports et la création d'empreintes des services en cours d'exécution sur les ports. Grâce à ces informations, nous pouvons assez précisément dire quand le propriétaire d'un serveur a changé.

Peu de liens. Explication. Il n'est même pas difficile d'obtenir gratuitement une liste de domaines dont le whois indique une certaine adresse e-mail, ni de connaître tous les domaines associés à une certaine adresse IP. Cependant, lorsqu'il s'agit de hackers qui font tout leur possible pour rendre leur traçabilité difficile, des « astuces » supplémentaires sont nécessaires pour découvrir de nouvelles propriétés et établir de nouveaux liens.
Nous avons consacré beaucoup de temps à explorer comment extraire des données qui ne sont pas accessibles par des moyens conventionnels. Nous ne pouvons pas expliquer comment cela fonctionne pour des raisons évidentes, mais dans certaines circonstances, les hackers commettent des erreurs lors de l'enregistrement de domaines ou de la location et la configuration de serveurs, ce qui permet de découvrir des adresses électroniques, des pseudonymes de hackers et des adresses de backend. Plus vous extrayez de liens, plus il est possible de construire des graphes précis.

Comment fonctionne notre graphe

Pour commencer à utiliser le graphe réseau, vous devez entrer dans la barre de recherche un domaine, une adresse IP, un email ou une empreinte de certificat SSL. Il y a trois conditions que l'analyste peut gérer : le temps, la profondeur des étapes et le nettoyage.

Temps

Temps – date ou intervalle pendant lequel l'élément recherché a été utilisé à des fins malveillantes. Si ce paramètre n'est pas précisé, le système déterminera par lui-même le dernier intervalle de possession de cette ressource. Par exemple, le 11 juillet, la société Eset a publié un rapport sur la façon dont Buhtrap utilise un exploit 0-day pour l'espionnage informatique. À la fin du rapport, il y a 6 indicateurs. L'un d'eux, secure-telemetry[.]net, a été à nouveau enregistré le 16 juillet. Donc, si vous construisez le graphe après le 16 juillet, vous obtiendrez des résultats non pertinents. Mais si vous indiquez que ce domaine a été utilisé avant cette date, 126 nouveaux domaines et 69 adresses IP qui ne figurent pas dans le rapport Eset apparaîtront dans le graphe :

• ukrfreshnews[.]com
• unian-search[.]com
• vesti-world[.]info
• runewsmeta[.]com
• foxnewsmeta[.]biz
• sobesednik-meta[.]info
• rian-ua[.]net
• et autres.

En plus des indicateurs réseau, nous trouvons immédiatement des liens avec des fichiers malveillants qui ont été associés à cette infrastructure et des tags qui nous indiquent que Meterpreter et AZORult ont été utilisés.

Ce qui est remarquable, c'est que vous obtenez ce résultat en une seconde et vous n'avez plus besoin de passer des jours à analyser les données. Ce type d'approche réduit sans aucun doute parfois considérablement le temps d'enquête, ce qui est souvent critique.

Le nombre d'étapes ou la profondeur de récursivité avec laquelle le graphe sera construit

Par défaut, la profondeur est de 3. Cela signifie que tous les éléments directement liés à l'élément recherché seront trouvés, puis de nouvelles relations seront établies à partir de chaque nouvel élément vers d'autres éléments, et déjà à partir des nouveaux éléments du pas précédent, de nouveaux éléments seront trouvés.

Prenons un exemple qui n'est pas lié aux exploits APT et 0-day. Récemment, un cas intéressant de fraude lié aux cryptomonnaies a été décrit sur Habr. Le rapport mentionne un domaine — themcx[.]co, utilisé par des escrocs pour héberger un site prétendument d'échange Miner Coin Exchange, et phone-lookup[.]xyz, pour attirer du trafic.

De la description, il est évident que le schéma nécessite une infrastructure assez importante pour attirer du trafic vers des ressources frauduleuses. Nous avons décidé d'examiner cette infrastructure en construisant un graphe en 4 étapes. Nous avons obtenu un graphe avec 230 domaines et 39 adresses IP. Ensuite, nous avons divisé les domaines en 2 catégories : ceux qui ressemblent à des services liés aux cryptomonnaies et ceux destinés à générer du trafic via des services de recherche de numéros de téléphone :

Liés aux cryptomonnaies
Liés aux services de recherche de numéros de téléphone

coinkeeper[.]cc
caller-record[.]site.

mcxwallet[.]co
phone-records[.]space

btcnoise[.]com
fone-uncover[.]xyz

cryptominer[.]watch
number-uncover[.]info

Nettoyage

Par défaut, l'option "Nettoyage du graphe" est activée et tous les éléments non pertinents seront supprimés du graphe. En passant, elle a également été utilisée dans tous les exemples précédents. Je prévois la question naturelle : comment éviter de supprimer quelque chose d'important ? Je réponds : pour les analystes qui préfèrent construire des graphes manuellement, le nettoyage automatisé peut être désactivé et le nombre d'étapes choisi = 1. Ensuite, l'analyste pourra compléter le graphe avec les éléments nécessaires et supprimer les éléments non pertinents à sa tâche du graphe.

Déjà dans le graphe, l'analyste a accès à l'historique des modifications whois, DNS, ainsi qu'aux ports ouverts et aux services en cours d'exécution sur ceux-ci.

Phishing financier

Nous avons étudié les actions d'un groupe APT qui, pendant plusieurs années, a mené des attaques de phishing contre des clients de diverses banques dans différentes régions. Une caractéristique de ce groupe était l'enregistrement de domaines très similaires aux noms de banques réelles, et la plupart des sites de phishing avaient un design identique, seules les noms des banques et leurs logos différaient.

Dans ce cas, l'analyse graphique automatisée nous a été d'une grande aide. En prenant l'un de leurs domaines — lloydsbnk-uk[.]com, nous avons construit en quelques secondes un graphique de profondeur 3, qui a révélé plus de 250 domaines malveillants utilisés par ce groupe depuis 2015 et qui continuent d'être utilisés. Certains de ces domaines ont déjà été acquis par des banques, mais les enregistrements historiques montrent qu'ils avaient été enregistrés auparavant par les attaquants.

Pour plus de clarté, la figure montre un graphique de profondeur 2.

Fait remarquable, dès 2019, les attaquants ont légèrement modifié leur tactique et ont commencé à enregistrer non seulement des domaines bancaires pour l'hébergement de phishing web, mais aussi des domaines de diverses sociétés de conseil pour envoyer des courriels de phishing. Par exemple, les domaines swift-department.com, saudconsultancy.com, vbgrigoryanpartners.com.

Cobalt gang

En décembre 2018, le groupe de hackers Cobalt, spécialisé dans les attaques ciblées sur les banques, a effectué des envois au nom de la Banque nationale du Kazakhstan.

Les courriels contenaient des liens vers hXXps://nationalbank.bz/Doc/Prikaz.doc. Le document téléchargeable contenait un macro qui lançait PowerShell, tentant de télécharger et d'exécuter un fichier de hXXp://wateroilclub.com/file/dwm.exe dans %Temp%einmrmdmy.exe. Le fichier %Temp%einmrmdmy.exe, alias dwm.exe — CobInt stager, configuré pour interagir avec le serveur hXXp://admvmsopp.com/rilruietguadvtoefmuy.

Imaginez que vous n'avez pas la possibilité d'obtenir ces courriels de phishing et de réaliser une analyse complète des fichiers malveillants. Le graphique pour le domaine malveillant nationalbank[.]bz montre immédiatement les liens vers d'autres domaines malveillants, l'attribue à un groupe et montre quels fichiers ont été utilisés dans l'attaque.

Prenons dans ce graphique l'adresse IP 46.173.219[.]152 et construisons un graphique en un seul passage sans activer le nettoyage. Celui-ci est lié à 40 domaines, par exemple, bl0ckchain[.]ug.
paypal.co.uk.qlg6[.]pw
cryptoelips[.]com

À en juger par les noms de domaine, il semble qu'ils soient utilisés dans des systèmes frauduleux, mais l'algorithme de nettoyage a compris qu'ils n'avaient rien à voir avec cette attaque et ne les a pas inclus dans le graphique, ce qui simplifie considérablement le processus d'analyse et d'attribution.

Si vous reconstruisez le graphique pour nationalbank[.]bz, mais en désactivant l'algorithme de nettoyage du graphique, il y aura plus de 500 éléments, dont la majorité n'a rien à voir avec le groupe Cobalt ni avec leurs attaques. Un exemple de ce à quoi ressemble un tel graphique est montré ci-dessous :

Conclusion

Après plusieurs années de réglages fins, de tests sur des enquêtes réelles, d'études de menaces et de chasse aux attaquants, nous avons réussi non seulement à créer un outil unique, mais aussi à changer la perception qu’en ont les experts au sein de l'entreprise. Au début, les experts techniques désiraient un contrôle total sur le processus de construction du graphe. Les convaincre que la construction automatique du graphe pourrait le faire mieux qu'un homme avec des années d'expérience a été extrêmement difficile. Le temps et les multiples vérifications manuelles des résultats fournis par le graphe ont tout changé. Maintenant, nos experts non seulement font confiance au système, mais utilisent également les résultats qu'il génère dans leur travail quotidien. Cette technologie fonctionne au sein de chacun de nos systèmes et permet de mieux identifier les menaces de tout type. L'interface pour l'analyse manuelle du graphe est intégrée dans tous les produits de Group-IB et élargit considérablement les possibilités de chasse à la cybercriminalité. Cela est confirmé par les retours des analystes de nos clients. Et nous, de notre côté, continuons d'enrichir le graphe avec des données et de travailler sur de nouveaux algorithmes utilisant l'intelligence artificielle pour obtenir le graphe réseau le plus précis possible.

Source : habr.com