Threat Hunting ou TH est une recherche proactive de traces de piratage ou de fonctionnement de malwares non détectés par les moyens de protection standards. Aujourd'hui, nous allons parler du fonctionnement de ce processus, des outils pouvant être utilisés pour rechercher des menaces et de ce qu'il faut garder à l'esprit lors de la formulation et du test d'hypothèses.
Qu'est-ce que la chasse aux menaces et pourquoi est-elle nécessaire
Dans le processus de recherche de menaces, l'analyste n'attend pas le déclenchement des capteurs des systèmes de protection, mais recherche délibérément des traces de compromis. Pour ce faire, il développe et vérifie les hypothèses sur la façon dont les attaquants auraient pu pénétrer le réseau. Ces contrôles doivent être cohérents et réguliers.
La mise en œuvre correcte du processus doit prendre en compte les principes:
- Il faut supposer que le système a déjà été compromis. L'objectif principal est de trouver des traces de pénétration.
- Pour effectuer une recherche, vous avez besoin d'une hypothèse sur la façon dont le système a été compromis.
- La recherche doit être effectuée de manière itérative, c'est-à-dire qu'après avoir testé l'hypothèse suivante, l'analyste en propose une nouvelle et continue la recherche.
Souvent, les défenses automatisées traditionnelles manquent des attaques ciblées sophistiquées . La raison en est que ces attaques sont souvent étalées dans le temps, de sorte que les outils de sécurité ne peuvent pas corréler les deux phases d'une attaque. Dans le même temps, les attaquants réfléchissent attentivement aux vecteurs de pénétration et développent des scénarios d'actions dans l'infrastructure. Cela leur permet de ne pas effectuer d'actions de démasquage et de faire passer leur activité comme légitime. Les attaquants améliorent constamment leurs connaissances, achètent ou développent de nouveaux outils.
Les problèmes d'identification des attaques ciblées sont particulièrement pertinents pour les organisations qui ont été précédemment piratées. Selon le rapportFireEye M-Trends, 64% des organisations précédemment compromises ont de nouveau été attaquées. Il s'avère que plus de la moitié des entreprises piratées sont toujours à risque. Cela signifie qu'il est nécessaire d'appliquer des mesures pour la détection précoce des faits de compromis - cela peut être réalisé avec l'aide de TH.
La recherche de menaces aide les spécialistes de la sécurité de l'information à réduire le temps de détection d'une faille, ainsi qu'à mettre à jour les connaissances sur l'infrastructure protégée. TH est également utile lors de l'utilisation de l'intelligence sur les menaces (TI), en particulier lorsque des indicateurs TI sont utilisés lors de la formulation d'une hypothèse.
Comment formuler des hypothèses pour tester
Puisque lors de la réalisation de TH, on suppose a priori que l'attaquant a déjà pénétré dans l'infrastructure, la première chose à faire est de localiser l'emplacement de la recherche de traces de piratage. Il peut être déterminé en émettant une hypothèse sur la manière dont la pénétration s'est produite et sur la confirmation de celle-ci dans l'infrastructure. Après avoir formulé une hypothèse, l'analyste vérifie la véracité de son hypothèse. Si l'hypothèse n'est pas confirmée, l'expert procède à la mise au point et en teste une nouvelle. Si, à la suite du test de l'hypothèse, des traces de piratage sont découvertes ou la présence de logiciels malveillants est établie, une enquête commence.
Figure 2. Schéma de chasse aux menaces
L'idée d'une hypothèse peut naître de l'expérience personnelle de l'analyste, mais il existe d'autres sources pour sa construction, par exemple:
- threat intelligence (TI-). , : X, MD5- Y.
- , (TTPs). TTPs MITRE ATT&CK. : .
- . . , asset management . .
- , .
threat hunting
Après avoir formulé une hypothèse, il est nécessaire d'identifier les sources de données pouvant contenir des informations pour la tester. Souvent, ces sources contiennent trop de données, parmi lesquelles vous devez trouver des informations pertinentes. Ainsi, le processus TH se résume à rechercher, filtrer et analyser une énorme quantité de données sur ce qui se passe dans l'infrastructure. Considérez les sources dans lesquelles les informations peuvent être trouvées pour tester l'hypothèse de recherche:
Figure 3. Classification des sources d'informations pour la conduite de TH
La plus grande quantité d'informations pertinentes est contenue dans les journaux et le trafic réseau. Les produits des classes SIEM (Security Information and Event Management) et NTA (Network Traffic Analysis) aident à analyser les informations qui en découlent. Les sources externes (telles que les flux TI) doivent également être incluses dans le processus d'analyse.
Comment ça marche dans la pratique
L'objectif principal de TH est de détecter une faille qui n'a pas été détectée par des outils de sécurité automatisés.
Par exemple, envisagez de tester deux hypothèses. En pratique, nous montrerons comment les systèmes d'analyse du trafic et d'analyse des journaux se complètent dans le processus de test d'hypothèse.
Hypothèse n ° 1: un attaquant est entré dans le réseau via un poste de travail et tente de prendre le contrôle d'autres nœuds du réseau, en utilisant l'exécution de la commande WMI pour avancer.
Les attaquants ont obtenu les informations d'identification d'un utilisateur root. Après cela, ils essaient de prendre le contrôle d'autres nœuds du réseau afin d'accéder à l'hôte avec des données précieuses. L'une des méthodes de lancement de programmes sur un système distant utilise la technologie Windows Management Instrumentation (WMI). Elle est responsable de la gestion centralisée et du suivi des différentes parties de l'infrastructure informatique. Cependant, les créateurs ont prévu la possibilité d'appliquer cette approche aux composants et aux ressources non seulement d'un seul hôte, mais également d'un ordinateur distant. Pour cela, la transmission des commandes et des réponses via le protocole DCERPC a été mise en œuvre.
Par conséquent, pour tester l'hypothèse, vous devez examiner les requêtes DCERPC. Voyons comment cela peut être fait en utilisant l'analyse du trafic et un système SIEM. En figue. 4 montre toutes les interactions réseau DCERPC filtrées. Par exemple, nous avons choisi l'intervalle de temps de 06:58 à 12:58. Figure 4. Sessions DCERPC filtrées . 4 nous voyons deux tableaux de bord. Sur la gauche se trouvent les nœuds qui ont initié les connexions DCERPC. Sur la droite se trouvent les nœuds auxquels les clients se sont connectés. Comme vous pouvez le voir sur la figure, tous les clients du réseau accèdent uniquement au contrôleur de domaine. Il s'agit d'une activité légitime, car les hôtes réunis dans un domaine Active Directory utilisent le protocole DCERPC pour contacter un contrôleur de domaine pour la synchronisation. Cela serait considéré comme suspect en cas de communication entre les hôtes utilisateurs.
Puisque rien de suspect n'a été identifié pour la période sélectionnée, en se déplaçant le long de la chronologie, nous sélectionnons les 4 prochaines heures. C'est maintenant un intervalle de 12h59 à 16h46. Dans celui-ci, nous avons remarqué un changement étrange dans la liste des hôtes de destination (voir Fig. 5). Figure 5. Après avoir modifié l'intervalle de temps, deux nouveaux nœuds sont apparus dans la liste des serveurs Dans la liste des hôtes de destination, il y a deux nouveaux nœuds. Considérez celui sans nom DNS (10.125.4.16). Figure 6. Raffinement du filtre pour savoir qui s'est connecté à 10.125.4.16 Comme vous pouvez le voir sur la fig. 6, le contrôleur de domaine 10.125.2.36 y accède (voir figure 4), ce qui signifie que cette interaction est légitime.
Ensuite, vous devez analyser qui s'est connecté au deuxième nouveau nœud, dans la Fig. 5 est win-admin-01.ptlab.ru (10.125.3.10). Du nom du nœud, il s'ensuit qu'il s'agit de l'ordinateur de l'administrateur. Une fois le filtre affiné, il ne reste que deux nœuds source de session. Figure 7. Affinez le filtre pour savoir qui s'est connecté à win-admin-01 De la même manière que dans le cas précédent, l'un des initiateurs était un contrôleur de domaine. Ces sessions ne sont pas suspectes car elles sont courantes dans un environnement Active Directory. Cependant, le deuxième nœud (w-user-01.ptlab.ru), à en juger par le nom, est l'ordinateur de l'utilisateur - de telles connexions sont des anomalies. Si vous accédez à l'onglet Sessions avec ce filtre, vous pouvez télécharger le trafic et voir les détails dans Wireshark. Figure 8. Téléchargement des sessions pertinentes
Dans le trafic, vous pouvez voir un appel à l'interface IWbemServices, qui indique l'utilisation d'une connexion WMI. Figure 9. Appel de l'interface IWbemServices (Wireshark) De plus, les appels transmis sont chiffrés, de sorte que les commandes spécifiques sont inconnues. Figure 10. Le trafic DCERPC est chiffré, donc la commande transmise n'est pas visible (Wireshark) Pour enfin confirmer l'hypothèse qu'une telle communication est illégitime, il est nécessaire de vérifier les logs de l'hôte. Vous pouvez accéder à l'hôte et voir les journaux système localement, mais il est plus pratique d'utiliser un système SIEM. Dans l'interface SIEM, nous avons introduit une condition dans le filtre qui ne laissait que les journaux du nœud cible au moment de l'établissement d'une connexion DCERPC, et avons vu l'image suivante:
Figure 11. Journaux système win-admin-01 au moment de l'établissement d'une connexion DCERPC
Dans les journaux, nous avons vu une correspondance exacte avec l'heure de début de la première session (voir Fig. 9), l'initiateur de la connexion est l'hôte w-user-01. Une analyse plus approfondie des journaux montre qu'ils se sont connectés sous le compte PTLAB \ Admin et ont exécuté la commande (voir Fig. 12) pour créer l'utilisateur john avec le mot de passe mot de passe !!!: net user john password !!! / ajouter. Figure 12. Commande exécutée pendant la connexion
Nous avons découvert qu'à partir du nœud 10.125.3.10, quelqu'un utilisant WMI au nom du compte PTLAB \ Admin a ajouté un nouvel utilisateur à l'hôte win-admin-01.ptlab.ru. Lors de la réalisation d'une TH réelle, l'étape suivante consiste à déterminer s'il s'agit d'une activité administrative. Pour ce faire, vous devez contacter le propriétaire du compte PTLAB \ Admin et savoir s'il a effectué les actions décrites. Puisque l'exemple considéré est synthétique, nous supposerons que cette activité est illégitime. Aussi, lors de la réalisation d'un vrai TN, en cas de révélation du fait d'une utilisation illégale du compte, vous devez créer un incident et mener une enquête approfondie.
Hypothèse n ° 2: un attaquant a pénétré le réseau et est au stade de l'exfiltration des données, utilisant le tunneling du trafic pour sortir les données.
Tunneling trafic - organiser un canal de telle manière que les paquets d'un protocole réseau (éventuellement sous une forme modifiée) soient transmis à l'intérieur des champs d'un autre protocole réseau. Un exemple courant de tunneling est la création de canaux cryptés comme SSH. Les canaux cryptés garantissent la confidentialité des informations transmises et sont courants dans les réseaux d'entreprise modernes. Cependant, il existe des options exotiques telles que les tunnels ICMP ou DNS. Ces tunnels sont utilisés par les cybercriminels pour déguiser leur activité comme légitime.
Commençons par trouver le moyen le plus courant de tunneliser le trafic via le protocole SSH. Pour ce faire, nous filtrerons toutes les sessions à l'aide du protocole SSH: Figure 13. Recherche de sessions DNS dans le trafic
Dans la figure, vous pouvez voir qu'il n'y a pas de trafic SSH dans l'infrastructure, vous devez donc choisir le protocole suivant qui pourrait être utilisé pour le tunneling. Le trafic DNS étant toujours autorisé dans les réseaux d'entreprise, nous le considérerons ci-dessous.
Si vous filtrez le trafic par DNS, vous pouvez voir que l'un des nœuds a un nombre anormalement élevé de requêtes DNS.
Figure 14. Widget avec statistiques des sessions des clients DNS
Après avoir filtré les sessions par source de requêtes, nous avons appris où cette quantité anormale de trafic est envoyée et comment elle est répartie entre les nœuds de destination. En figue. La figure 15 montre qu'une partie du trafic va au contrôleur de domaine, qui agit en tant que serveur DNS local. Cependant, une grande partie des demandes est adressée à un hôte inconnu. Dans un réseau d'entreprise basé sur Active Directory, les ordinateurs des utilisateurs pour la résolution de noms DNS ne doivent pas utiliser de serveur DNS externe pour contourner celui de l'entreprise. Si une telle activité est détectée, vous devez savoir ce qui est transmis dans le trafic et où toutes ces demandes sont envoyées. Figure 15. Recherche de trafic pour les sessions SSH
Si vous allez dans l'onglet "Sessions", vous pouvez voir ce qui est transmis dans les requêtes au serveur suspect. Le temps entre les demandes est assez court et les sessions sont nombreuses. De tels paramètres sont rares pour le trafic DNS légitime.
Figure 16. Paramètres de trafic DNS
Après avoir ouvert une carte de session, nous voyons une description détaillée des demandes et des réponses. Les réponses du serveur ne contiennent pas d'erreurs, mais les enregistrements demandés semblent très suspects, car généralement les nœuds ont des noms DNS plus courts et plus significatifs. Figure 17. Demande d'enregistrement DNS suspect L'analyse du trafic a montré qu'une activité suspecte lors de l'envoi de requêtes DNS a lieu sur l'hôte win-admin-01. Il est temps d'analyser les journaux du nœud de réseau - la source de cette activité. Pour ce faire, accédez à SIEM.
Nous devons trouver les journaux système win-admin-01 et voir ce qui s'est passé vers 17h06. Vous pouvez voir qu'un script PowerShell suspect était en cours d'exécution en même temps. Figure 18. Exécution de PowerShell en même temps que l'envoi de requêtes suspectes Les journaux enregistrent le script en cours d'exécution. Figure 19. Correction du nom du script en cours d'exécution dans les journaux Le nom du script exécuté admin_script.ps1 fait allusion à la légitimité, mais les administrateurs nomment généralement les scripts pour une fonction spécifique, et ici le nom est général. De plus, le script se trouve dans le dossier des fichiers temporaires. Il est peu probable qu'un script administratif important se retrouve dans un dossier qui peut être vidé à tout moment.
Parmi les événements découverts figurait la création d'une classe cryptographique inhabituelle à partir de la bibliothèque Logos.Utility. Cette bibliothèque est rare et n'est plus prise en charge par le développeur, donc la création de ses classes est inhabituelle. Essayons de trouver des projets qui l'utilisent. Figure 20. Création d'une classe cryptographique personnalisée Si vous utilisez la recherche, vous pouvez trouver un utilitaire qui organise un tunnel DNS et utilise cette classe à l'aide du deuxième lien. Figure 21. Recherche d'informations sur un script par nom de classe Pour nous assurer enfin que c'est bien l'utilitaire dont nous avons besoin, recherchons des signes supplémentaires dans les journaux. Les preuves sont donc apparues. La première consiste à exécuter l'utilitaire nslookup à l'aide d'un script. Figure 22. Exécution de l'utilitaire nslookup par le script
L'utilitaire nslookup.exr est utilisé lors des diagnostics réseau et est rarement exécuté par les utilisateurs réguliers. Le début est visible dans les codes source de l'utilitaire. Figure 23. Code de lancement de l'utilitaire nslookup (GitHub) La deuxième preuve est une chaîne assez unique pour générer des valeurs aléatoires. Figure 24. Génération de valeurs aléatoires par le script Si vous utilisez la recherche dans les codes source, vous pouvez voir cette ligne même. Figure 25. Code pour générer une valeur aléatoire L'hypothèse du tunnel a été confirmée, mais l'essence des actions effectuées n'est pas claire. Lors de l'analyse ultérieure des logs, nous avons remarqué deux lancements de processus. Figure 26. Recherche de documents de bureau pour une exfiltration ultérieure
Les lignes de lancement des processus trouvés indiquent la recherche des documents à télécharger. Ainsi, l'hypothèse a été pleinement confirmée, les attaquants ont vraiment utilisé le tunneling du trafic pour télécharger des données.
conclusions
Comme le montrent les derniers rapports de recherche , le temps moyen que les attaquants restent dans l'infrastructure reste long. Par conséquent, n'attendez pas les signaux des défenses automatisées - agissez de manière proactive. Étudiez votre infrastructure et vos méthodes d'attaque modernes, et utilisez les recherches menées par les équipes TI ( FireEye , Cisco , PT Expert Security Center ).
Je ne demande pas l'abandon des protections automatisées. Cependant, il ne faut pas supposer que l'installation et la configuration correcte d'un tel système sont le point final. Ce n'est que la première étape nécessaire. Ensuite, vous devez surveiller le développement et le fonctionnement de l'environnement réseau contrôlé, gardez le doigt sur le pouls.
Les conseils suivants vous aideront:
- . . , .
- . , .
- . , . . , TH , .
- Automatisez les tâches de routine afin d'avoir plus de temps pour faire preuve de créativité et essayer des solutions créatives.
- Simplifiez le processus d'analyse de grandes quantités de données. Pour ce faire, il est utile d'utiliser des outils qui aident l'analyste à voir ce qui se passe sur le réseau et sur les nœuds du réseau comme une image unique. Ces outils comprennent une plateforme d'échange d'indicateurs TI , un système d'analyse du trafic et un système SIEM .
Publié par Anton Kutepov, PT Expert Security Center chez Positive Technologies.
Toute l'analyse a été réalisée dans le système d'analyse du trafic PT Network Attack Discovery et le système de gestion des événements de sécurité MaxPatrol SIEM.