Conseils de meilleures pratiques pour l’intelligence sur les menaces

Beaucoup de gens disent que l’intelligence sur les menaces (TI) est bonne, mais peu comprennent comment la cuisiner. Il y a encore moins de personnes qui savent quels processus engager pour que la TI fonctionne et génère des profits. De plus, un nombre négligeable de personnes savent comment choisir un fournisseur de flux, où vérifier un indicateur de faux positifs et si cela vaut la peine de bloquer un domaine que votre collègue vous a envoyé via WhatsApp.

Nous avions deux abonnements APT commerciaux, dix échanges d’informations, une dizaine de flux gratuits et une liste étendue de nœuds de sortie TOR. Nous avons également utilisé quelques reverseurs puissants, des scripts Powershell maîtrisés, un scanner Loki et un abonnement payant à VirusTotal. Non que le centre de réponse aux incidents de sécurité ne fonctionne pas sans tout cela, mais si vous voulez attraper des attaques complexes, vous devez aller jusqu’au bout.

Ce qui m’inquiétait particulièrement, c’était la potentialité d’automatiser la vérification des indicateurs de compromission (IOCs). Il n’y a rien de plus immoral que l’intelligence artificielle remplaçant un humain dans une activité qui nécessite de la réflexion. Cependant, j’ai réalisé que mon entreprise rencontrerait ce défi tôt ou tard, car le nombre de nos clients augmentait.

Pendant plusieurs années d’activité permanente de TI, j’ai marché sur un tas de râteaux et j’aimerais fournir quelques conseils qui aideront les débutants à éviter les erreurs courantes.

Conseil 1. Ne mettez pas trop d’espoirs dans la détection par hachage : la plupart des malwares sont polymorphes aujourd’hui

Les données d’intelligence sur les menaces viennent dans différents formats et manifestations. Elles peuvent inclure des adresses IP de centres de commandement et de contrôle de botnet, des adresses e-mail impliquées dans des campagnes de phishing, et des articles sur les techniques d’évasion que les groupes APT sont sur le point d’utiliser. Pour résumer, ce peuvent être différentes choses.

Pour trier tout ce désordre, David Bianco a suggéré d’utiliser ce qu’on appelle le Pyramide de douleur. Elle décrit une corrélation entre les différents indicateurs que vous utilisez pour détecter un attaquant et la quantité de “douleur” que vous causerez à l’attaquant si vous identifiez un IOC spécifique.

Par exemple, si vous connaissez le hachage MD5 du fichier malveillant, il peut être détecté facilement et avec précision. Cependant, cela ne causera pas beaucoup de douleur à l’attaquant, car ajouter seulement 1 bit d’information à ce fichier changera complètement son hachage.

Conseil 2. Essayez d’utiliser les indicateurs que l’attaquant trouvera techniquement compliqués ou coûteux à changer

En anticipant la question de savoir comment découvrir si un fichier avec un hachage donné existe dans notre réseau d’entreprise, je dirai ce qui suit : il y a différentes façons. L’une des méthodes les plus simples consiste à utiliser une solution qui maintient la base de données des hachages MD5 de tous les fichiers exécutables dans l’entreprise.

Revenons à la Pyramide de douleur. Contrairement à la détection par hachage, il est plus productif d’identifier les tactiques, techniques et procédures (TTP) de l’attaquant. C’est plus difficile à faire et nécessite plus d’efforts, mais vous infligerez plus de douleur à l’adversaire.

Par exemple, si vous savez que le groupe APT qui cible votre secteur de l’économie envoie des e-mails de phishing avec des fichiers *.HTA à bord, alors la création d’une règle de détection qui recherche ces pièces jointes d’e-mail frappera l’attaquant en dessous de la ceinture. Ils devront modifier la tactique de spam et peut-être même dépenser de l’argent pour acheter des exploits 0-day ou 1-day qui ne sont pas bon marché.

Conseil 3. Ne mettez pas trop d’espoirs dans les règles de détection créées par quelqu’un d’autre, car vous devez vérifier ces règles pour les faux positifs et les ajuster

Lorsque vous commencez à créer des règles de détection, il y a toujours une tentation d’utiliser des règles prêtes à l’emploi. Sigma est un exemple de référentiel gratuit. Il s’agit d’un format de méthodes de détection indépendant de SIEM qui vous permet de traduire les règles du langage Sigma en règles ElasticSearch ainsi que des règles Splunk ou ArcSight. Le référentiel comprend des centaines de règles. Cela semble être une bonne chose, mais le diable, comme toujours, se cache dans les détails.

Examinons l’une des règles de détection de mimikatz. Cette règle détecte les processus qui ont tenté de lire la mémoire du processus lsass.exe. Mimikatz fait cela lorsqu’il tente d’obtenir des hachages NTLM, et la règle identifiera le malware.

Cependant, il est crucial pour nous – les experts qui ne détectent pas seulement mais répondent également aux incidents – de nous assurer qu’il s’agit réellement d’un acteur malveillant. Malheureusement, il existe de nombreux processus légitimes qui lisent la mémoire de lsass.exe (par exemple, certains outils antivirus). Par conséquent, dans un scénario réel, une règle comme celle-ci causera plus de faux positifs que de bénéfices.

Je ne veux accuser personne à ce sujet – toutes les solutions génèrent des faux positifs ; c’est normal. Cependant, les spécialistes de l’intelligence sur les menaces doivent comprendre qu’il est toujours nécessaire de vérifier et d’ajuster les règles obtenues à la fois à partir de sources ouvertes et fermées.

Conseil 4. Vérifiez les noms de domaine et les adresses IP pour un comportement malveillant, non seulement sur le serveur proxy et le pare-feu, mais également dans les journaux du serveur DNS – et assurez-vous de vous concentrer à la fois sur les tentatives de résolution réussies et échouées

Les noms de domaine et les adresses IP malveillants sont les indicateurs les plus optimaux du point de vue de la simplicité de détection et de la quantité de douleur que vous infligez à l’attaquant. Cependant, ils semblent faciles à gérer seulement à première vue. Au moins, vous devriez vous poser la question de savoir où obtenir le journal de domaine.

Si vous vous limitez à vérifier les journaux du serveur proxy uniquement, vous pouvez manquer du code malveillant qui tente de requêter le réseau directement ou demande un nom de domaine non existant généré avec DGA, sans oublier le tunneling DNS – none de ces éléments ne seront répertoriés dans les journaux du serveur proxy d’entreprise. Les criminels peuvent également utiliser des services VPN avec des fonctionnalités avancées ou créer des tunnels personnalisés.

Conseil 5. Surveillez ou bloquez – décidez quel choix faire uniquement après avoir découvert quel type d’indicateur vous avez découvert et en reconnaissant les conséquences possibles du blocage

Chaque expert en sécurité informatique a été confronté à un dilemme non trivial : bloquer une menace ou surveiller son comportement et commencer à enquêter une fois qu’il déclenche des alertes. Certaines instructions encouragent sans équivoque à choisir le blocage, mais parfois, le faire est une erreur.

Si l’indicateur de compromission est un nom de domaine utilisé par un groupe APT, ne le bloquez pas – commencez à le surveiller à la place. Les tactiques actuelles de déploiement d’attaques ciblées supposent la présence d’un canal de connexion secret supplémentaire, comme par exemple des applications de suivi de cellules qui ne peuvent être découvertes qu’à travers une analyse approfondie. Le blocage automatique vous empêchera de trouver ce canal dans ce scénario ; en outre, les adversaires réaliseront rapidement que vous avez remarqué leurs manigances.

D’un autre côté, si l’IOC est un domaine utilisé par un crypto-ransomware, il doit être bloqué immédiatement. Mais n’oubliez pas de surveiller toutes les tentatives de requêter les domaines bloqués – la configuration de l’encodeur malveillant peut inclure plusieurs URL de serveurs de commandement et de contrôle. Certains d’entre eux peuvent ne pas être dans les flux et ne seront donc pas bloqués. Tôt ou tard, l’infection atteindra ces serveurs pour obtenir la clé de chiffrement qui sera utilisée instantanément pour chiffrer l’hôte. La seule façon fiable de vous assurer que vous avez bloqué tous les serveurs de commandement et de contrôle est de retourner l’exemple.

Conseil 6. Vérifiez tous les nouveaux indicateurs pour la pertinence avant de les surveiller ou de les bloquer

Gardez à l’esprit que les données de menaces sont générées par des humains qui sont sujets à l’erreur, ou par des algorithmes d’apprentissage automatique qui ne sont pas non plus infaillibles. J’ai été témoin de différents fournisseurs de rapports payants sur l’activité des groupes APT qui ajoutaient accidentellement des exemples légitimes à la liste des hachages MD5 malveillants. Étant donné que même les rapports de menaces payants contiennent des IOC de mauvaise qualité, ceux obtenus via l’intelligence ouverte doivent certainement être vérifiés pour la pertinence. Les analystes de TI ne vérifient pas toujours leurs indicateurs pour les faux positifs, ce qui signifie que le client doit effectuer le travail de vérification pour eux.

Par exemple, si vous avez obtenu une adresse IP utilisée par une nouvelle itération de TrickBot, avant de l’utiliser dans vos systèmes de détection, vous devriez vous assurer qu’il ne s’agit pas d’un service d’hébergement ou d’une adresse émanant de votre IP. Sinon, vous aurez du mal à gérer de nombreux faux positifs chaque fois que les utilisateurs visitant un site résidant sur cette plate-forme d’hébergement vont à des pages Web complètement inoffensives.

Conseil 7. Automatisez tous les flux de données de menaces au maximum. Commencez par automatiser complètement la vérification des faux positifs via une liste d’avertissement, tout en instruisant le SIEM pour surveiller les IOC qui ne déclenchent pas de faux positifs

Pour éviter un grand nombre de faux positifs liés à l’intelligence et obtenus à partir de sources ouvertes, vous pouvez effectuer une recherche préliminaire pour ces indicateurs dans les listes d’avertissement. Pour créer ces listes, vous pouvez utiliser les 1000 premiers sites Web par trafic, les adresses des sous-réseaux internes, ainsi que les domaines utilisés par les principaux fournisseurs de services tels que Google, Amazon AWS, MS Azure et autres. Il est également une excellente idée de mettre en œuvre une solution qui modifie dynamiquement les listes d’avertissement consistant en les principaux domaines / adresses IP que les employés de l’entreprise ont accédés au cours de la semaine ou du mois précédent.

La création de ces listes d’avertissement peut être problématique pour un SOC de taille moyenne, il est donc judicieux de considérer l’adoption de plateformes d’intelligence sur les menaces.

Conseil 8. Analysez l’ensemble de l’entreprise pour les indicateurs d’hôte, et non seulement les hôtes connectés au SIEM

En règle générale, tous les hôtes de l’entreprise ne sont pas connectés au SIEM. Par conséquent, il est impossible de les vérifier pour un fichier malveillant avec un nom ou un chemin spécifique en utilisant uniquement la fonctionnalité standard du SIEM. Vous pouvez résoudre ce problème de la manière suivante :

1. Utilisez des analyseurs d’IOC tels que Loki. Vous pouvez utiliser SCCM pour le lancer sur tous les hôtes de l’entreprise, puis transférer les résultats vers un dossier réseau partagé.
2. Utilisez des analyseurs de vulnérabilités. Certains d’entre eux ont des modes de conformité qui vous permettent de vérifier le réseau pour un fichier spécifique dans un chemin spécifique.
3. Écrivez un script Powershell et exécutez-le via WinRM.

Comme mentionné ci-dessus, cet article n’est pas destiné à être une base de connaissances complète sur la façon de faire de l’intelligence sur les menaces correctement. Mais, à en juger par notre expérience, le respect de ces règles simples permettra aux débutants d’éviter des erreurs critiques lors de la manipulation de différents indicateurs de compromission.