Threat Hunting avec OpenCTI + OpenAEV + Splunk ESCU

Définir le périmètre d'une chasse aux menaces est un défi. Les équipes doivent prioriser les ressources tout en comprenant le comportement et l'impact des menaces potentielles et en évitant l'élargissement du périmètre.

En suivant les principes de Threat-Informed Defense de MITRE, une chasse aux menaces efficace est guidée par l'intelligence sur les cybermenaces et validée par rapport aux mesures défensives. Cet article montre comment :

• Utiliser les Priority Intelligence Requirements (PIR) dans OpenCTI pour cibler les chasses
• Identifier les détections pertinentes de Splunk ESCU mappées aux techniques ATT&CK
• Tirer parti d'OpenAEV pour simuler les menaces et valider les détections afin de combler les lacunes

TL;DR

• Prioriser la CTI avec les PIR pour mener des chasses basées sur des hypothèses
• Construire un tableau de bord APT38/Sapphire Sleet dans OpenCTI pour définir le périmètre des chasses
• Ingérer les détections Splunk ESCU et les mapper aux patterns ATT&CK
• Réduire le périmètre via les campagnes récentes et les comportements ClickFix
• Chasser avec SPL et valider les détections via des scénarios OpenAEV
• Transformer les résultats en améliorations sur les personnes, les processus et la technologie

Threat-Informed Hunting : Chasse aux menaces avec MITRE Threat-Informed Defense

La chasse aux menaces est bien plus que la recherche d'anomalies — c'est la poursuite délibérée et proactive du comportement des adversaires avant qu'une intrusion ne se déploie complètement. Et comme toute investigation disciplinée, la chasse n'est aussi bonne que le cadre qui la guide. Pour rester concentré, reproductible et aligné sur les tactiques adverses, nous nous appuyons sur des modèles structurés tels que le PEAK Threat Hunting Framework de Splunk SURGE.

Dans cette procédure en 5 actes, nous allons reconstituer une chasse guidée par l'intelligence, de bout en bout — de la définition d'une hypothèse testable, au mapping de l'intelligence via MITRE ATT&CK, jusqu'à la validation de l'exposition via OpenAEV.

Acte 1 : Structurer une chasse : Hypothèse testable, MITRE et PEAK

Hypothèse testable

La chasse aux menaces comprend plusieurs types de chasse : basée sur des hypothèses, basée sur des références, et assistée par modèle. Dans ce cas d'usage, nous nous concentrerons sur une chasse basée sur des hypothèses — la plus alignée avec Threat‑Informed Defense — qui commence par une déclaration testable.

Par déclaration « testable », nous entendons une affirmation claire, spécifique et fondée sur des preuves concernant un comportement adversaire potentiel qui peut être validée ou réfutée. Par exemple :

• « Lazarus veut voler mes données. » → Non testable
• « Lazarus utilise un proxy de connexion pour router le trafic entre les hôtes internes et le C2. » → Testable

Avec cette seconde déclaration, nous pouvons définir le périmètre d'une chasse car elle est testable. C'est là que MITRE Threat‑Informed Defense apporte de la structure :

MITRE Threat-Informed Defense

Threat-informed defense est un processus continu dans lequel défenseurs et adversaires apprennent et évoluent constamment.

Lors de la priorisation des hypothèses à poursuivre, MITRE Threat-Informed Defense aide à connecter la CTI aux Tests & Évaluations, qui peuvent ensuite être utilisés pour les Mesures Défensives.

Le Triangle Threat-Informed Defense

Comme illustré ci-dessus, Threat-Informed Defense met l'accent sur un cycle en trois phases : identifier la CTI pertinente, tester et évaluer les comportements dans votre environnement, combler les lacunes défensives, et recommencer.

Pour la chasse aux menaces, cela se traduit par :

• Identifier et prioriser la CTI pertinente pour votre secteur, région et actifs
• Extraire les détails tels que les patterns d'attaque, indicateurs et malwares pour définir le périmètre des hypothèses
• Tester les comportements dans vos données et environnement, y compris la simulation si approprié
• Examiner les détections, préventions et lacunes de processus

Framework PEAK

Maintenant que nous avons une hypothèse et notre processus défini, assurons-nous d'avoir une structure avec un framework.

Les frameworks de chasse en cybersécurité aident à définir et affiner nos processus de chasse de manière structurée avec des phases et étapes appropriées à suivre. Les options populaires incluent Sqrrl et TaHiTI. Dans ce cas, nous utiliserons le Framework PEAK de Splunk SURGE, qui signifie :

• Prepare : PIR, tableaux de bord et définition d'hypothèses
• Execute : chasses ciblées avec observables clairs et points de décision
• Act : valider les détections, mettre à jour les SOP et suivre les améliorations
• Knowledge : connaissance du scripting Windows et macOS utilisé dans les campagnes APT38

[Pour plus d'informations sur PEAK, consultez le document Splunk : PEAK Threat Hunting Framework.]

À ce stade, il convient de noter que la chasse aux menaces ne consiste pas seulement à prouver une hypothèse. Elle devrait également être stratégiquement utilisée pour améliorer les résultats SecOps tels que la couverture de détection, la clarté de la réponse et la préparation de l'équipe.

Acte 2 : Commencer une chasse : Utiliser les PIR pour prioriser la CTI

Donnons vie à la structure et au processus décrits ci-dessus à travers un exemple concret : une chasse de bout en bout pour les menaces ciblant le secteur éducatif de Singapour, alimentée par OpenCTI, Splunk ESCU et OpenAEV.

Définir les Priority Intelligence Requirements (PIR)

Pour commencer la chasse, il est essentiel de prioriser l'intelligence avec les Priority Intelligence Requirements (PIR).

Définissons le PIR suivant dans le gestionnaire PIR d'OpenCTI :

« Menaces ciblant le secteur de l'éducation à Singapour au cours des 90 derniers jours. »

OpenCTI transforme immédiatement cette exigence en une vue d'intelligence multidimensionnelle : cartes de menaces, ensembles d'intrusion tendance, chronologies de campagnes et résumés de victimologie.

Nous pouvons utiliser cela pour approfondir notre PIR initial pour obtenir des informations et visuels spécifiques.

Découverte de menace

Dans ce cas, l'ensemble d'intrusion « Sapphire Sleet » se démarque clairement sur la Carte des menaces comme une menace hautement prioritaire, basée sur l'alignement régional, la haute pertinence et l'activité récente.

Concentrons-nous sur Sapphire Sleet comme notre acteur de menace principal.

Identifier la CTI à partir du PIR pour la chasse aux menaces

En revenant à la vue PIR dans OpenCTI, nous pouvons accéder aux détails granulaires sur cet acteur de menace spécifique « Sapphire Sleet ». Cela inclut :

• Alias de menace (BlueNoroff/APT38)
• Zones géographiques ciblées (incluant Singapour)
• Campagnes connues
• Malwares associés
• Techniques ATT&CK
• Références et rapports

Parmi une série d'autres détails contextuels, nous apprenons que Sapphire Sleet est associé à APT38/BlueNoroff dans les rapports publics. La victimologie inclut Singapour et des cibles universitaires — ce qui s'aligne bien avec notre PIR initial.

Pour définir cette chasse, nous pouvons examiner les comportements en approfondissant différents patterns d'attaque et malwares.

En parcourant les vues de campagnes et de TTP, nous révélons de gros volumes d'activité historique. Pour éviter de mener une chasse sans focus, nous réduisons le périmètre aux campagnes récentes uniquement.

Acte 3 : Configurer un cockpit opérationnel piloté par la CTI

Tableau de bord contextuel de chasse aux menaces

OpenCTI fournit des tableaux de bord préconfigurés, ainsi que la possibilité de configurer les vôtres. Dans ce cas, construisons un tableau de bord personnalisé autour de Sapphire Sleet (APT38/BlueNoroff) pour soutenir notre création d'hypothèses et notre définition de périmètre spécifiques.

Donnons à notre tableau de bord quatre sections pour le reporting et les insights actionnables : Vue d'ensemble et Indicateurs de haut niveau, Vue d'ensemble des menaces, Activités récentes, et Mitigations et Détections suggérées.

Vue d'ensemble et Indicateurs de haut niveau

Obtenir un aperçu de l'objectif du tableau de bord et visualiser des indicateurs de haut niveau tels que les comptes de malwares, rapports, campagnes, patterns d'attaque et détections SIEM pertinentes (Splunk ESCU).

Cela aide à décider s'il faut définir le périmètre autour de malwares, rapports, campagnes ou patterns d'attaque spécifiques.

Vue d'ensemble des menaces

Met en évidence les principaux TTP et malwares utilisés par Sapphire Sleet, et une carte des pays ciblés. Cela peut être utilisé pour prioriser les hypothèses par technique ou malware, filtrées par région.

Activités récentes

Liste toutes les campagnes et rapports issus de l'intelligence ingérée.

Utilisez cela pour décider s'il faut se concentrer sur l'ensemble d'intrusion global ou se concentrer sur une campagne/rapport récent avec un contexte plus riche.

Mitigations et Détections suggérées

Détections et Mitigations suggérées montre les objets de cours d'action (COA) avec la couverture ATT&CK la plus élevée et les COA les plus récents par pattern d'attaque. Ici, les COA représentent les détections Splunk ESCU importées depuis Splunk Enterprise Security. Traitez-les comme des points de départ qui doivent être validés dans votre environnement.

Ingérer Splunk ESCU dans OpenCTI et mapper aux patterns ATT&CK

Pour opérationnaliser la CTI, nous intégrons les détections Splunk ESCU dans OpenCTI en tant que COA.

Notez que pour ce faire, nous avons besoin des prérequis suivants :
– Accès à Splunk Enterprise Security et à l'application DA-ESS-ContentUpdate (ESCU)
– Permission d'exécuter des recherches REST
– Accès OpenCTI et capacité CSV Mapper

Exporter les détections ESCU via REST

Nous pouvons exporter le contenu ESCU depuis Splunk ES, en nous concentrant sur l'application DA-ESS-ContentUpdate (détections ESCU uniquement). Les champs clés incluent le titre de détection, la description, le SPL, l'ID de technique ATT&CK et le nom de technique.

Voici un exemple de SPL pour extraire les champs pertinents :

Copied!

1| rest /services/saved/searches splunk_server=local
2| search eai:acl.app="DA-ESS-ContentUpdate" is_visible=1 disabled=0
3| table title description search annotations.mitre_technique_id annotations.mitre_technique
Copy

Nous pouvons également construire un exemple de colonnes de sortie comme suit : title, description, search, mitre_technique_id, mitre_technique.

Mapper les détections aux ID ATT&CK

Pour simplifier, les détections sont exportées au format CSV, que nous avons ingérées dans OpenCTI via un mappeur CSV configuré

Logique de mapping :

• Créer chaque détection en tant que Course of Action (COA) STIX 2.1 avec nom et description+contenu de recherche
• Mapper mitre_technique_id et mitre_technique aux SDO Attack Pattern ATT&CK
• Créer des relations COA → Attack Pattern avec le type « mitigates »
• Étiqueter toutes les détections importées avec « siem-splunk-escu-detection » pour un filtrage et une déduplication faciles

Remarque : Cette ingestion a été effectuée manuellement pour les tests. Elle peut être automatisée en étendant le connecteur Splunk. (Issue GitHub ou repo)

Maintenant, nous pouvons retourner dans OpenCTI et voir les objets résultants :

Cela transforme OpenCTI en un catalogue de détection piloté par la CTI, révélant quelles détections ESCU couvrent quelles techniques ATT&CK — et si ces techniques importent pour notre acteur de menace choisi.

Acte 4 : Exécuter la chasse

Réduire le périmètre de chasse

Des chasses larges et sans focus créent un drainage des ressources et des impasses. Il est donc très important de mettre en évidence et de se concentrer sur des éléments spécifiques de votre chasse.

En revenant à notre tableau de bord, dans les Activités récentes, nous pouvons voir deux campagnes qui se démarquent : BlueNoroff « GhostCall » et « GhostHire ».

À l'intérieur de ces campagnes, une observation clé apparaît :

Les victimes sont amenées par ingénierie sociale à « mettre à jour Zoom », déclenchant un script ClickFix qui télécharge des payloads basés sur ZIP. La surface d'attaque s'étend sur macOS et Windows.

Nous pouvons maintenant dériver une déclaration testable précise :

« Sapphire Sleet utilise des scripts ClickFix sur macOS et Windows pour télécharger et exécuter des artefacts multi-étapes. »

Avec cela en tête, nous pouvons tester spécifiquement le comportement ClickFix dans la vue ATT&CK de campagne d'OpenCTI.

Là, la technique la plus proche est Command and Scripting Interpreter → AppleScript, indiquant une exécution basée sur des scripts.

Instantanément, nous pouvons voir que les objets liés montrent des liens entre AppleScript et ClickFix.

Les mitigations montrent deux détections Splunk ESCU pertinentes (une centrée sur Windows, une centrée sur macOS).

Par exemple, « Windows PowerShell FakeCAPTCHA Clipboard Execution » note un potentiel détournement de presse-papiers FakeCAPTCHA/ClickFix et inclut une recherche SPL de référence.

Maintenant que nous avons cette information, nous pouvons utiliser ces détections comme point de départ.

Chasser contre notre périmètre

Dans l'ESCU de Splunk, beaucoup de SPL derrière les détections sont basés sur l'exécution de tstats contre les modèles de données de bonnes pratiques de Splunk connus sous le nom de Common Information Model (Splunk CIM) pour des raisons d'efficacité et d'économie de ressources.

Nous pouvons utiliser le SPL basé sur tstats de Splunk derrière le SPL de détection ESCU comme point de départ. Cependant, pour ce faire, il faut un mapping CIM approprié qui peut être réalisé avec des Technology Add-ons (TA) téléchargeables depuis Splunkbase pour la plupart des sources de données bien connues.

Si le CIM n'est pas en place, nous pouvons pivoter vers des événements bruts tout en maintenant la même logique. Exemple de chasse centrée sur Windows (simplifiée) :

Copied!

1index=windows EventCode=4104 OR SourceName=PowerShell
2| search (Clipboard OR Set-Clipboard OR Get-Clipboard OR FromBase64String)
3| stats count min(_time) as first_seen max(_time) as last_seen by host user ProcessName ScriptBlockText
4| where count > 0
Copy

Si aucun résultat n'est trouvé, des recherches supplémentaires sur ClickFix peuvent être trouvées en ligne, qui peuvent être utilisées pour améliorer les recherches SPL.

Dans notre cas, aucun événement correspondant n'a été trouvé. Cela ne signifie pas que la chasse a échoué — cela suggère simplement soit une absence d'activité, soit des lacunes dans la couverture de la source de logs/détection. Les deux sont des résultats précieux.

Cela nous amène à la phase suivante.

Acte 5 : Identifier et améliorer les lacunes avec les résultats de chasse aux menaces

Poser les bonnes questions

Lorsqu'une hypothèse ne peut être confirmée, traitez les résultats comme des opportunités d'amélioration sur les personnes, les processus et la technologie. Par exemple, nous pouvons examiner :

• Sources de données : Quels endpoints, gestionnaires EDR ou logs manquent ? Planifiez l'intégration.
• Détections : Quelles détections ESCU nécessitent un ajustement ou de nouvelles détections personnalisées ? Améliorez l'Ingénierie de Détection.
• Processus : Les SOP sont-elles claires pour le triage et la déclaration d'incident ? Mettez à jour les runbooks et RACI.

Nous pouvons également nous poser une question clé pour aider à faire ressortir d'autres résultats :

La menace ne s'est-elle pas produite et l'hypothèse est-elle négative ? Si oui, comment nous préparons-nous pour de futures tentatives ?

Tirer parti de la gestion de l'exposition avec OpenAEV

Dans ce cas, plutôt que d'attendre l'occurrence du vrai APT38, il est beaucoup plus sage de le valider de manière proactive via une simulation, nous permettant d'évaluer notre exposition actuelle à cette menace.

En utilisant Threat-Informed Defense, nous avons de l'intelligence sur les campagnes BlueNoroff et ClickFix avec AppleScript. À partir d'OpenAEV, nous pouvons construire un scénario d'attaque pour simuler en toute sécurité les patterns d'attaque et comportements de cette campagne de menace dans notre environnement. Cela nous permettra de valider les détections, les processus et les réponses humaines à cette menace.

Créer un scénario de simulation

Examinons comment nous pouvons concevoir un scénario pour simuler l'attaque dans notre environnement en utilisant la conception suivante :

• Objectif : valider la détection et la réponse pour les comportements ClickFix
• Techniques : exécution AppleScript
• Actifs : endpoints sélectionnés avec agents EDR
• Injects : simulations techniques et exercices de processus
• Critères de succès : événements notables Splunk attendus, reconnaissances d'analystes, adhésion aux SOP
• Collecte de données : index notable Splunk, logs EDR, résultats OpenAEV

Avec cette conception, nous pouvons facilement générer un scénario à partir de la technique liée à AppleScript. Nous pouvons ensuite placer tous les injects pertinents sur une chronologie, représentant l'escalade au fil du temps.

Nous pouvons ajouter différents types d'injects. Dans ce cas, nous ajouterons :

• Injects techniques pour l'exécution de payload
• Injects processus/humains qui peuvent simuler des notifications par e-mail, des défis internes ou une pression médiatique

Cela nous permet de tester à la fois les contrôles de sécurité techniques et humains/processus pour cette exposition.

Pour le payload technique, nous simulons le comportement AppleScript/ClickFix avec un payload contrôlé :

Ensuite, nous sélectionnons les actifs cibles pour les exécutions :

Remarque : Assurez-vous que le gestionnaire EDR transmet la télémétrie à Splunk et intégrez Splunk en tant que Collecteur dans OpenAEV afin que les résultats notables soient renvoyés dans OpenAEV.

Pour les injects orientés personnes, nous pouvons notifier le SOC et l'Ingénierie de Détection que le scénario a commencé, et leur demander de valider si Splunk Enterprise Security a produit les résultats attendus et à partir de quelles détections :

Coordonnons également une action de réponse et vérifions la clarté des SOP via un inject supplémentaire.

Examiner les résultats

OpenAEV dispose d'une large bibliothèque d'intégrations pour exploiter divers EDR, collecteurs et injecteurs.

Avec l'EDR et Splunk intégrés, OpenAEV rapporte les résultats de prévention, détection, vulnérabilité et réponse humaine.

Par exemple, dans la capture d'écran ci-dessous, aucun des contrôles de prévention n'a arrêté les payloads injectés, un faible pourcentage de détections a pu détecter certains des injects, et tous les joueurs impliqués dans l'exercice de simulation n'ont pas été en mesure de répondre aux attentes en termes de réponses humaines.

Celles-ci peuvent être approfondies pour déterminer exactement quels injects et quels patterns d'attaque ont réussi ou échoué, qui peuvent ensuite être renvoyés dans la couverture de sécurité originale et le rapport de menace dans OpenCTI pour rapporter l'efficacité de la couverture réelle contre le rapport de menace CTI en question.

Avec ces métriques et couvertures de sécurité à la fois dans OpenCTI et OpenAEV, vous pouvez ensuite facilement les utiliser pour identifier et combler les lacunes. Par exemple, une telle métrique peut inclure la couverture de détection par technique, le temps jusqu'à l'alerte et l'adhésion aux SOP.

Conclusion

En conclusion, la valeur de la chasse aux menaces va au-delà de la preuve d'une hypothèse — c'est un processus clé pour détecter, tester, valider et remédier aux expositions potentielles.

En utilisant ce processus de Threat-Informed Hunting, nous avons pu compléter le workflow suivant :

• Commencer avec une intelligence pilotée par PIR dans OpenCTI et l'utiliser comme base pour l'hypothèse et la définition du périmètre de chasse aux menaces.
• Tirer parti de la logique de détection Splunk ESCU comme base pour opérationnaliser notre chasse.
• Valider notre périmètre de chasse aux menaces via un scénario OpenAEV pour simuler le comportement de chasse afin d'identifier de manière proactive les lacunes Personnes, Processus et Technologie.
• Renvoyer ces métriques d'OpenAEV dans OpenCTI en tant que couvertures de sécurité pour aider à informer l'ingénierie de détection et les périmètres de chasse aux menaces ultérieurs.

Avec Threat-Informed Hunting, vous pouvez améliorer de manière mesurable vos chasses aux menaces pour obtenir des résultats précieux et améliorer en retour votre programme de sécurité global.

Extended Threat Management pour la chasse aux menaces

Ce cas d'usage fournit un exemple de ce que les utilisateurs de la plateforme XTM de Filigran et les chasseurs de menaces peuvent accomplir en combinant l'intelligence sur les menaces avec les capacités de validation d'exposition — le tout à partir d'une plateforme unique et open-source.

En savoir plus :

• La plateforme XTM de Filigran
• Réserver une démo personnalisée pour commencer