withsecurelabs/esfangESF modular ingestion tool for development and research.
Cet outil est conçu pour la consommation modulaire des événements du framework EndpointSecurity (ESF) depuis l'environnement macOS. Il s'agit de ma tentative pour surmonter un certain nombre de problèmes rencontrés avec les outils existants, notamment la perte silencieuse de données, la consommation stricte des types d'événements, le manque de prise en charge de types de données alternatifs et la surcharge du gestionnaire d'accès aux fichiers.
Cet outil s'appuie fortement sur l'excellent travail réalisé par Chris Ross, Omark-Ikram et l'équipe d'Objective-See pour leurs outils ProcessMonitor, Appmon et EndpointSecurityDemo. Ma compréhension fondamentale et l'applicabilité de l'ingestion de données ESF ont été grandement améliorées et lancées en examinant leurs travaux, qui ont fait l'essentiel du travail pour rendre ce développement possible. Cet outil tente d'extrapoler les meilleurs éléments de ces outils et de les développer afin de permettre une action de consommation ESF au cas par cas, en fonction des besoins des enquêteurs.
Les outils existants, y compris des outils plus raffinés comme Crescendo de FireEye, souffrent d'un certain nombre de problèmes associés à ESF lui-même, qui, lors des tests, semblent liés à la manière dont le client ESF ingère les données du sous-système. Le principal problème rencontré était la perte silencieuse de données. Lors des tests, lorsque de nombreux types d'événements étaient ingérés, les résultats comparés à l'ingestion d'un seul type d'événement montraient une disparité dans les données accumulées. Lors des tests, des événements critiques liés à une activité malveillante n'étaient pas présents dans l'ensemble de données acquis, alors qu'ils l'étaient lors de l'ingestion d'un seul type d'événement.
L'objectif principal de cet outil était triple :
À cette fin, l'outil permet à l'utilisateur de spécifier quels types d'événements il souhaite collecter pendant les opérations parmi les 51 types d'événements NOTIFY disponibles (les types d'événements AUTH ont été omis pour cet outil). Cela signifie que les chercheurs peuvent cibler des types d'événements spécifiques liés aux opérations particulières qu'ils souhaitent surveiller, tout en contribuant à réduire la perte silencieuse de données associée en diminuant le nombre total de types d'événements collectés par le client.
La sortie des données est répartie dans des fichiers journaux individuels par type d'événement, eux-mêmes regroupés sous des fichiers de genre d'événements tels que processus, fichiers, sockets, etc. Tous les journaux sont écrits en JSON pour une ingestion facile et peuvent être étendus par les utilisateurs en modifiant le code source pour collecter des champs supplémentaires décrits dans la documentation event_type fournie par Apple.
NOTES FUTURES -
Afin d'empêcher la perte silencieuse de données, une solution potentielle serait de multithreader l'outil afin de permettre à plusieurs clients ESF de s'exécuter simultanément, chacun collectant un sous-ensemble des types d'événements. Cela pourrait potentiellement surmonter le seuil interne atteint qui provoque la perte de données observée. Je n'ai simplement pas eu le temps d'employer les contrôles supplémentaires nécessaires pour cela.
COMMENT L'UTILISER
Nécessite la désactivation de SIP !
Malheureusement, comme il s'agit d'un code POC de développement, vous ne pourrez pas l'utiliser avec SIP activé, car l'accès au sous-système ESF est restreint aux binaires signés. Comme celui-ci n'est pas signé, SIP doit être désactivé pour son utilisation. Par conséquent, utilisez-le uniquement sur des machines non destinées à la production.
Il existe trois types d'exécution : vous pouvez spécifier l'ID d'un event_id à partir du fichier de configuration, spécifier un group_id à partir du fichier de configuration, ou référencer le fichier de configuration avec les lignes des ID de types d'événements ou des groupes décommentées.
Exemple 1 = Collecter uniquement les événements ES_EVENT_TYPE_NOTIFY_EXEC : ./ESFang -id 2
Exemple 2 = Collecter les événements du genre Fichier : ./ESFang -group 2
Exemple 3 = Collecter les types d'événements ou les groupes spécifiés par le fichier de configuration : ./ESFang -config ./ESF_config.txt
NOTE SUR LE FILTRE CODÉ EN DUR
Dans le code source se trouve un filtre de processus codé en dur, situé aux lignes 460 à 469. Ce filtre peut être manipulé pour capturer un PID, un PPID ou un nom de processus spécifique. Il a été ajouté comme solution de contournement "bricolée" à des fins de filtrage spécifiques. Les tentatives pour le rendre dynamique en ligne de commande afin de l'alimenter dans Inspector ont toutes échoué. Il est donc laissé codé en dur.
NOTE SUR LE MUTEUR DE PROCESSUS CODÉ EN DUR
Dans le code source se trouve une capacité de mise en sourdine de processus codée en dur, située aux lignes 471 à 491. Ce filtre peut être utilisé pour mettre en sourdine la capture d'événements spécifiques en fonction du chemin du processus ou du processus parent, respectivement. Il doit être utilisé avec prudence, car tous les processus correspondant au nom spécifié seront mis en sourdine si le processus ou le parent de toute activité correspond. Cette fonctionnalité était en phase de test bêta lors de la publication.
