Traitement de courriels d’hameçonnage avec TheHive & Cortex

Par

Léonard Jérôme

Forensic

Tag(s)

DFIR

CERT

CSIRT

ransomware

Cybercriminalité

phishing

Face au nombre toujours plus important d'alertes de sécurité à qualifier et d'incidents à traiter, il devient primordial pour un SOC ou une équipe CSIRT de mettre en œuvre des solutions permettant d’identifier les sujets prioritaires. L’actualité de ces derniers mois et l’accroissement du nombre de victimes de rançongiciels met en évidence le besoin de détecter et de réagir au plus vite. Cet article propose de montrer comment intégrer TheHive et Cortex au processus de détection et de réponse pour automatiser un certain nombre de tâches, et donc gagner du temps, toujours précieux dans ces situations.

1. TheHive & Cortex

TheHive et son compagnon Cortex [THP] forment une plateforme collaborative de réponse aux incidents de sécurité ou SIRP (Security Incident Response Plateform). Ces applications sont libres et développées sous licence open source depuis 2016.

Les applications TheHive, Cortex et les librairies clientes des API sont open source, sous licence AGPLv3. Elles sont aujourd’hui développées et maintenues exclusivement par la société StrangeBee fondée en 2018 par trois des co-créateurs initiaux de TheHive-Project.

TheHive permet d’enregistrer une investigation sous la forme d’un Case qui est constitué d’observables et d’un ensemble de tâches qu’il est possible d’assigner à un membre de l’organisation.

Les observables correspondent aux éléments techniques qu’une équipe peut collecter lors d’une investigation (URL, adresses IP, noms d’hôtes ou de domaines, fichiers, adresses e-mail, empreintes cryptographiques…). Afin d’extraire ou de collecter des informations complémentaires, des programmes appelés Analyzers peuvent être exécutés sur ces observables. Les résultats de ces Analyzers viennent enrichir le Case. TheHive délègue la gestion et l’orchestration de ces programmes à Cortex.

TheHive dispose également d’une fonctionnalité dédiée aux alertes et au triage. Son API REST permet d’intégrer différentes sources telles que les SIEM, des services de renseignements sur les menaces (Threat Intelligence), les logiciels de suivi de tickets, ou encore des boites de messagerie à disposition des utilisateurs et dédiées aux signalements de messages suspects.

Fig. 1 : Exemple d’intégration de TheHive et Cortex.

TheHive & Cortex ont déjà fait l’objet d’une présentation détaillée dans l’article écrit par Saâd Kadhi dans le numéro 94 de MISC publié en novembre 2017 [MISC 94]. Depuis, de nombreuses nouveautés ont fait leur apparition.

Cortex supporte une nouvelle famille de composants appelés Responders. À l’instar des Analyzers, il s’agit de programmes qu’il est possible de déclencher dans TheHive sur des Observables, mais également depuis une Alerte, un Case, une Tâche ou un Worklog. Les Responders peuvent être vus comme des « assistants » mettant en œuvre des « réponses actives » sur le réseau, sur des applications ou sur des services tiers. Par exemple, demander une action spécifique à une équipe tierce en créant un ticket dans un outil ITSM (IT Service Management), ajouter une règle de filtrage particulière sur un serveur proxy ou encore isoler un poste ou un serveur sans l’éteindre à travers un EDR (Endpoint Detection & Response).

TheHive a connu une évolution majeure en juillet 2020 : [THEHIVE4]. La version 4.0 apporte notamment le support des Organisations ainsi qu’un contrôle avancé des accès et des permissions. Plusieurs Organisations peuvent se partager l’usage d’une même instance de l’application. Elles ont la possibilité d’être indépendantes, c’est-à-dire, qu’elles ignorent alors l’existence les unes des autres sur la plateforme, ou elles peuvent au contraire être liées entre elles. Dans ce dernier cas, et avec le jeu des permissions, plusieurs Organisations peuvent collaborer sur des investigations en partageant des Cases, des Tâches et/ou des Observables.

Voyons maintenant comment préparer cette plateforme pour automatiser un certain nombre d’opérations et couvrir l’un des vecteurs les plus utilisés par les attaquants pour distribuer du contenu malveillant : la campagne d’hameçonnage, notamment observée dans les récentes attaques informatiques par rançongiciels.

L’article se concentre sur le traitement du vecteur d’infection et montre comment TheHive et Cortex sont en mesure d’assister l’analyste sur des actions cruciales pour empêcher l’attaquant de mettre un pied dans le système d’information.

2. Cas d’usage : campagne de courriels malveillants

De nombreux courriels d’hameçonnage arrivent à passer entre les mailles des équipements de filtrage et de désinfection automatique pour atterrir dans les boîtes aux lettres des utilisateurs. C’est souvent grâce aux utilisateurs sensibilisés que les premières alertes arrivent aux oreilles des équipes SOC ou CSIRT. Pour la suite de cet article, nous considérons le signalement d’un message malveillant par un utilisateur à l’équipe d’analystes comme évènement de sécurité initial. Ce signalement peut être fait manuellement ou en utilisant une solution comme [NOTIFYSECURITY] développée par le CERT-SG.

Avant d’être identifiés comme malveillants, ces signalements sont considérés comme suspects. Une phase de qualification et d’analyse doit permettre de se positionner sur le contenu du message signalé et de définir la posture à adopter. Quelles procédures suivre pour traiter ces signalements ? Quelles mesures prendre en cas de contenu malveillant ?

Lorsque la malveillance est avérée, l’identification exhaustive des cibles et la mise en place de mesures de protection contre les infections font partie des tâches prioritaires à accomplir ; l’objectif étant de limiter la probabilité qu’un utilisateur ouvre ce message et active une charge malveillante.

3. Intégration du processus dans TheHive & Cortex

Dans la suite de cet article, nous allons découvrir comment utiliser efficacement TheHive & Cortex pour :

centraliser les signalements des utilisateurs ;
préparer la réponse : rappeler à l’analyste quelles étapes il doit accomplir pour répondre à ces signalements ;
automatiser un certain nombre d’opérations, souvent chronophages pour l’analyste. L’appel à des fonctions automatisées peut se faire à plusieurs moments dans l’investigation.

Fig. 2 : TheHive & Cortex dans le processus de réponse aux incidents de sécurité

3.1 Réception des signalements

L’API de TheHive et la librairie python [THEHIVE4PY] facilitent grandement l’écriture de programmes d’intégration. Suivant la solution de messagerie employée, il est possible d’imaginer un programme intermédiaire appelé Feeder, en mesure de lire une boite de messagerie et de collecter ces signalements pour les traiter et créer des Alertes dans TheHive.

Chaque nouveau message est pris en charge par le Feeder qui commence par extraire les informations techniques qui seront utiles par la suite (adresse e-mail de l’émetteur, objet du courriel suspect, sources complètes du courriel, fichiers attachés, etc.). Ces éléments sont ainsi mis en forme comme Observables ou autre donnée de l’Alerte.

Pour illustrer cet exemple, la création d’une alerte et de ses observables est assurée par les constructeurs Alert() et AlertArtifact() présents dans thehive4py. Une fois l’objet Alert construit, un appel à l’API de TheHive permet de créer l’alerte dans l’application.

from thehive4py.api import TheHiveApi

from thehive4py.models import Alert, AlertArtifact,

## Ajout du sujet de l’e-mail aux Observables

observables.append(

AlertArtifact(

dataType='mail-subject',

data=suspiciousSubject,

tags=["suspicious_email:mail-subject"]

)

## Création de l’objet “Alert”

alert = Alert(

title=alertTitle,

tags=['suspicious email'],

description=reportedBody,

type='email report',

source='Internal mail Server',

sourceRef=sourceRef,

artifacts=observables

)

## Initialisation d’un client d’API TheHive

api = TheHiveApi(URL ,API_KEY, organisation=ORG )

## Appel à l’API de création d’Alert

api.create_alert(alert)

Fig. 3 : Nouvelle alerte issue du signalement d’un courriel suspect par un utilisateur.

3.2 Workflow de réponse

Une alerte doit être promue en Case pour débuter l’investigation. Pour ce faire, l’analyste a le choix entre créer un Case « vide », uniquement à partir de l’alerte, ou créer le Case depuis un modèle.

Un modèle de Case, ou Case Template, peut être appliqué à la création de tout nouveau Case, qu’il soit issu d’une alerte ou non. Un Case Template est défini par :

Des métadonnées qui seront appliquées par défaut au Case, comme la sévérité ou les niveaux de TLP (Traffic Light Protocol) ou PAP (Permissive Action Protocol). Ces informations pourront être mises à jour durant l’investigation.
Un ensemble de tâches et leur description. Ces tâches viendront guider les analystes au démarrage et au cours d’une nouvelle investigation.
Des champs configurables ou Custom Fields. Ces champs serviront à contextualiser l’investigation et seront actualisés par les analystes ou par les automates lors de l’investigation.

Pour traiter notre signalement, nous considérons la procédure suivante :

Vérifier le signalement : l’analyse du courriel signalé doit permettre d’établir le caractère malveillant ou non, puis d’enrichir le Case avec de nouveaux observables, de nouvelles informations. Ceux-ci seront utiles pour les autres tâches.
Rechercher d’autres destinataires ciblés par le même courriel.
Mettre en place des alertes au niveau du SIEM pour signaler la distribution de nouveaux courriels.
Mettre en place des moyens de protection pour arrêter la distribution de courriels et/ou l’infection post-exécution (la connexion vers un serveur de Command & Control par exemple).

Cette procédure n’est pas exhaustive et ne préfigure pas la tournure que prendra l’investigation. Elle contient cependant les premières tâches ou actions qui doivent être mises en œuvre au plus vite après la détection.

Fig. 4 : Case Template : traitement d’un courriel d’hameçonnage.

Ce Case Template peut être utilisé pour tous les nouveaux Cases issus d’un signalement. De nouvelles tâches pourront être identifiées et ajoutées au fur et à mesure de l’avancée de l’investigation ; par exemple, l’isolement et/ou l’analyse de postes compromis.

3.3 Qualification du contenu et analyses

Cette étape est terminée lorsqu’on a conclu sur le caractère malveillant ou non du contenu signalé. Elle consiste à analyser le message suspect en lui-même et tout ce qui le constitue : les en-têtes, le corps du message, les URL sur lesquelles le destinataire est invité à cliquer ainsi que les éventuels fichiers attachés.

Les observables de l’alerte sont ajoutés au Case. Depuis TheHive, et sur chaque observable, il est possible d’actionner des Analyzers dans Cortex. Certains d’entre eux permettent de visualiser le contenu du message signalé (EmlParser, FileInfo) et d’extraire de nouveaux éléments techniques comme des URL ou des fichiers attachés. Ces nouveaux observables peuvent être ajoutés à la collection du Case sur lesquels il est ensuite possible de pivoter et de lancer de nouveaux Analyzers : rechercher des évènements remarquables dans MISP, consulter des services comme VirusTotal, soumettre à des services de sandbox (Cuckoo, Joe Sandbox, Hybrid-Analysis …), collecter de l’information sur des noms d’hôtes ou sur l’adresse IP du serveur émetteur des courriels.

En présence de contenu malveillant, cette étape est aussi l’occasion de collecter de l’information et d’extraire un grand nombre d’éléments techniques qui pourront servir à mettre en œuvre une partie des tâches suivantes.

La librairie de composants pour python [CORTEXUTILS] facilite l’écriture d’Analyzers ou de Responders. Il suffit de créer une classe fille d’Analyzer, de surcharger quelques méthodes, notamment :

run(), qui se charge de spécifier le contenu de self.report() représentant le rapport renvoyé à TheHive ;
summary(), précisant le contenu des mini rapports affichés sous forme d’étiquettes dans TheHive ;
artifacts(), spécifiant la liste des observables extraits du rapport ; laissé vide si cela n’a pas d’intérêt.

from virus_total_apis import PublicApi as VirusTotalPublicApi

from cortexutils.analyzer import Analyzer

class VirusTotalAnalyzer(Analyzer):

def __init__(self):

Analyzer.__init__(self)

self.service = self.get_param('config.service', None, 'Service parameter is missing')

self.virustotal_key = self.get_param('config.key', None, 'Missing VirusTotal API key')

[..]

self.proxies = self.get_param('config.proxy', None)

self.vt = VirusTotalPublicApi(self.virustotal_key, self.proxies)

[..]

def run(self):

[..]

elif self.service == 'get':

[..]

elif self.data_type == 'hash':

data = self.get_param('data', None, 'Data is missing')

self.report(self.check_response(self.vt.get_file_report(data)))

[..]

if __name__ == '__main__':

VirusTotalAnalyzer().run()

Fig. 5 : Rapport d’une demande d’information auprès du service VirusTotal.

3.4 Identification des cibles et mesures préventives

Le caractère malveillant établi lors de la phase d’analyse indique que les équipements censés filtrer ce contenu ont défailli ; ceci signifie également que le courriel en question a pu être délivré à d’autres utilisateurs ; de nouvelles cibles potentielles qu’il faut d’identifier en procédant à de nouvelles actions :

Certains IOC (Indicator of Compromise), extraits des rapports d’analyse, se révèlent utiles pour identifier d’autres destinataires éventuels. Suivant les cas, le sujet, l’adresse e-mail de l’émetteur, le serveur SMTP distant, les noms des fichiers attachés et/ou leur empreinte cryptographique sont exploités pour mener des recherches dans une solution de collecte et de corrélation de logs, ou directement dans les journaux des serveurs de messagerie.
Des alertes sur ces mêmes IOC peuvent également être mises en place au niveau du SIEM afin d’être notifié si jamais un message similaire venait à être distribué à un utilisateur dans le futur.

En parallèle, des mesures de protection à plusieurs niveaux du système d’information peuvent être considérées pour réduire la probabilité d’une compromission. Certains éléments techniques récoltés lors de la qualification et l’analyse, une adresse IP, un nom d’hôte, l’URL vers un site d’hameçonnage ou vers un serveur de Command & Control viendront alimenter des règles de filtrage de pare-feux ou de serveurs proxy web.

Quelle que soit l’action, il est fort probable que chaque équipe SOC ou CISRT requiert une mise en œuvre différente. Par exemple, certaines devront s’appuyer sur des équipes d’administration qu’elles notifient par un e-mail ou un ticket. Pour réaliser ces mêmes actions, d’autres pourront directement accéder aux applications concernées en utilisant les API appropriées.

Si les applications ou services en question le permettent, l’automatisation de ces actions par l’intermédiaire de Responders est indispensable pour épauler l’équipe d’analystes tout au long de la réponse à un incident.

À la différence des Analyzers, les Responders ne retournent pas de rapport détaillé. Ils sont programmés pour exécuter des actions sur les données d’entrée, et peuvent être déclenchés sur une Alerte, un Case, une Tâche, un Worklog ou un Observable. En outre, si l’action réalisée s’est bien déroulée, des opérations spécifiques sont susceptibles d’être réalisées dans TheHive ; ajouter un Worklog ou fermer une Tâche, ajouter des tags, des Custom Fields, assigner un Case, marquer une Alerte comme lue.

Là encore la librairie python [CORTEXUTILS] met à disposition la classe Responder et les méthodes pour s’intégrer rapidement avec les différents services :

run() est la méthode principale, en charge de lancer la ou les actions du Responder ;
operations() est la méthode qui retourne une liste d’opérations compréhensibles par TheHive ; ces opérations sont réalisées si les actions lancées par la méthode run() se déroulent comme attendu.

from cortexutils.responder import Responder

[..]

class ProxyBlocklist(Responder):

[..]

def run(self):

blocked = self.block(url)

if blocked:

self.report(

{'message': '{} added to web proxy blocklist'.format(self.data)}

)

else:

self.error('Error')

def operations(self, raw):

return [

self.build_operation(

'AddTagToArtifact',

tag='Containment:WebProxy=Added to custom blocklist'

)

]

if __name__ == '__main__':

ProxyBlocklist().run()

Pour aller plus loin, et dans la perspective d’automatiser davantage la réponse à incidents, des outils d’orchestration comme [N8N] proposent déjà des intégrations avec TheHive & Cortex. Par exemple, il est possible d’attribuer des tâches à l’« analyste automate » qui se chargera de les réaliser automatiquement. La nature des tâches pouvant être ainsi déléguées est très vaste : toute action pouvant être réalisée par un appel à une API tierce et qui ne nécessite pas d’intervention humaine. Des articles détaillés sur l’utilisation de N8N avec TheHive seront prochainement publiés sur le blog [MEDIUM] de StrangeBee.

Conclusion

TheHive & Cortex visent à épauler les analystes dans leurs travaux d’investigations sans imposer de « bonne » façon de procéder pour répondre à un incident de sécurité. L’ouverture des API et les librairies clientes disponibles offrent de nombreuses possibilités d’intégration que chaque équipe peut s’approprier, suivant ses besoins, son environnement, ses processus et son niveau de maturité.

De nombreuses intégrations partagées par la communauté existent déjà et sont disponibles gratuitement sur les dépôts [GITHUB] du projet.

La communauté des utilisateurs de TheHive & Cortex est également très active sur [DISCORD]. Une liste non exhaustive de projets tiers associés à TheHive & Cortex, qu’il s’agisse d’Analyzers, de Responders ou de Feeders, sont également référencés sur le dépôt GitHub [AWESOME].

Remerciements

Un grand merci à notre communauté d’utilisateurs, à toute l’équipe de StrangeBee, et particulièrement à Nabil Adouani et Alexandre Gohier pour leur relecture attentive.