Framework forensique de réponse aux incidents
Application conçue sur mesure pour la présentation asynchrone de données forensiques sur un backend Elasticsearch.
Cette application est conçue pour ingérer un fichier de « collections » Mandiant Redline et offrir une flexibilité dans la recherche, l'empilement et le marquage.
L'application est née de l'incapacité à contrôler de multiples investigations (ou des centaines de points de terminaison) dans un seul et même panneau de verre.
Pour ingérer les audits Redline, nous avons créé nightHawkResponse, une application GOpher complète conçue pour accompagner ce framework. Le code source de l'application est disponible dans ce dépôt, un binaire a été compilé et s'exécute à l'intérieur de l'ISO, prêt à ingérer dès le premier démarrage.
Nous développons actuellement une nouvelle version majeure et la publierons d'ici mars 2020. La nouvelle version vise à accomplir les éléments suivants.
Nous avons réalisé qu'il y avait trop de pièces mobiles pour opérer efficacement l'ensemble du dépôt, gérer facilement les entités et maintenir tout à jour. Nous croyons également que les données de base résidant dans Elastic devraient être utilisées plus efficacement par Kibana, et nous avons donc décidé de concrétiser cela en développant un plugin qui le fait aux côtés du flux de travail incroyable de Kibana.
Installation
La documentation de l'API suivra dans le Wiki
01/09/2016: Version 1.0.3
Fonctionnalités :
Vidéo de démonstration : Plateforme nightHawk Response
Pour simplifier l'utilisation pour les utilisateurs de nightHawk, nous avons construit une ISO avec tout prêt à l'emploi. Cela signifie que vous obtenez ce qui suit ;
/opt/nighthawk/etc/nightHawk.json. Démarrage du système :
Avant de construire votre VM avec l'ISO fournie, prenez en considération ce qui suit ;
En attente : Configurer le service Elastic pour être des nœuds doubles avec 1/4 de la mémoire système allouée par nœud. Cela signifie que si vous lui donnez 2 Go de RAM, chaque nœud ES aura 512 Mo et le système conservera 1 Go pour fonctionner.
Si vous souhaitez configurer cela différemment, connectez-vous en SSH à la machine et configurez selon vos souhaits.
Un minimum de 20 Go doit être envisagé. Un fichier d'audit peut être volumineux, il est donc conseillé d'allouer beaucoup d'espace de stockage pour gérer l'ingestion de nombreuses collections.
En attente : Configuration de stockage basée sur l'utilisateur pour les instances à grande échelle. Si vous souhaitez configurer des partitions supplémentaires, vous pouvez le faire vous-même, quelques modifications peuvent être apportées pour pointer le stockage de données ES vers votre nouvelle partition.
Installation :
Télécharger l'ISO : nightHawk v1.0.3
Configurez le matériel, montez l'ISO dans la VM, démarrez le script d'installation.
Une fois terminé, dans votre navigateur (Chrome/FireFox), allez à ; https://192.168.42.173.
Connectez-vous au système avec 'nighthawk/nighthawk' - cliquez sur "goto site" pour accéder à l'application
Si vous devez accéder à Kibana, allez à ; https://192.168.42.173:8443.
Si vous devez vous connecter en SSH à la machine, les identifiants sont ; admin/nightHawk.
Si vous souhaitez changer l'adresse IP (réfléchi dans toute l'application) ; /opt/nighthawk/bin/nighthawkctl set-ip <nouvelle_adresse_ip>
Le script de collecte d'audit Redline se trouve à la racine de ce dépôt. Utilisez-le lorsque vous utilisez le collecteur Redline autonome, car il renverra les documents nécessaires pour peupler correctement nightHawk.
Téléversement :
IMPORTANT :
Création d'un fichier zip d'audit à téléverser (Collecteur autonome Redline) :
étape_1 : Accédez à Sessions\AnalysisSessionX\Audits<NomOrdinateur> où X est le numéro d'analyse, généralement 1.
étape_2 : Créez un zip du dossier contenant les fichiers d'audit, par exemple 20160708085733
étape_3 : Téléversez 20160708085733.zip
IMPORTANT : Utiliser un fichier d'audit HX existant (Collecteur HX) : Les audits FireEye HX ont une extension se terminant par .mans. L'audit de HX diffère du collecteur Redline car le .mans qu'il renvoie est en fait un fichier zip. Cela signifie qu'il peut être téléversé directement, contrairement à l'audit Redline pour lequel vous devez suivre les instructions ci-dessus.
Accédez à l'icône « Téléverser » dans la barre de navigation, sélectionnez un .zip d'audit (ou plusieurs), un nom de cas (sinon le système vous en fournira un) et soumettez. Si vous avez utilisé notre script d'audit Redline pour construire votre collection, suivez les instructions « Collecteur Redline » juste au-dessus.
Une fois traité, le point de terminaison apparaîtra dans le nœud de l'arborescence « Enquêtes en cours ». Sous le point de terminaison, tous les types d'audit disponibles pour ce point de terminaison seront présentés. La fonction de téléversement de cette application web génère des sous-processus pOpen qui appellent l'application GO pour analyser l'audit Redline et pousser les données dans Elasticsearch. Il y a 2 options pour le téléversement : l'une est séquentielle, l'autre est concurrente.
Veuillez noter : Les téléversements concurrents sont limités à 5 à la fois et peuvent être gourmands en ressources. Si vous disposez d'une machine sous-alimentée, limitez l'utilisation de cette fonctionnalité à 2-3.
Marquage :
Vous pouvez cliquer sur n'importe quelle ligne d'un tableau (dans la vue de réponse) pour marquer ces données. Une fois marquées, vous pouvez voir les commentaires dans la vue des commentaires.
Elasticsearch :
Il existe des mappages personnalisés (fournis dans la racine du dépôt) et des commentaires consultatifs sur les points suivants ;
Les documents sont indexés via l'application GO en tant que relation parent/enfant. Cela a été choisi car il permet de donner un chemin relativement logique pour visualiser les documents, c'est-à-dire que le parent est le nom du point de terminaison et les enfants sont les types d'audit. Effectuer des agrégations sur une relation de document parent/enfant à grande échelle semble également logique. Le framework d'empilement repose sur la construction de parents dans un tableau pour ensuite obtenir toutes les agrégations de documents enfants pour certains types d'audit.
Les configurations Elasticsearch nécessitent un réglage et une reconnaissance de conception appropriés. Le partitionnement est important à comprendre en raison de la manière dont nous lions les documents parent/enfant. L'enfant est TOUJOURS routé vers le parent, il ne peut pas exister seul. Cela signifie qu'il faut considérer le nombre de partitions résidentes sur l'index. D'après ce que nous comprenons, il peut être judicieux de choisir une configuration qui intègre de nombreux nœuds avec des partitions uniques. Pour gagner en performance avec ce type de configuration, nous travaillons sur des recherches routées par partition.
Nous travaillons actuellement à concevoir la meilleure configuration possible pour des recherches rapides.
Cette application est conçue pour passer à l'échelle de manière massive. Dès la conception initiale, nous avons pu la faire fonctionner en douceur sur une VM Ubuntu à 1 CPU et 2 Go de RAM avec 3 nœuds ES (Macbook Pro), avec environ 4 millions de documents (ou 50 points de terminaison ingérés). Si vous passez en production avec une configuration de 64/128 Go de RAM et du stockage SAS, vous serez en mesure de maintenir un temps de réponse très rapide sur la récupération des documents tout en ayant de nombreux analystes travaillant simultanément sur l'application.
Considérations :
Traitement mixte DataTables :
Plusieurs types d'audit ingérés sont trop volumineux pour renvoyer tous les documents au tableau. Par exemple, l'historique des URL et le registre peuvent renvoyer 15 000 documents au DOM, ce qui mettrait à rude épreuve le navigateur client. Pour contrer cela, nous utilisons un traitement côté serveur pour paginer les résultats de certains types d'audit. Cela signifie que vous pouvez également rechercher des documents dans un type d'audit en utilisant Elasticsearch en backend.
Marquage :
Actuellement, nous pouvons marquer des documents et voir ces commentaires. Nous pouvons les mettre à jour ou les modifier. L'analyste peut donner un contexte tel que la date, le nom de l'analyste et le commentaire au document.
Dépendances (toutes préinstallées) :
elasticsearch-dsl.py
django 1.8
python requests
À faire :
Gestion des handles (en cours).
Curseurs de sélection temporelle pour les générateurs basés sur le temps (en cours).
Menu contextuel pour les investigations en cours/précédentes.
Contexte de marquage. Le système de marquage s'intégrera dans une boucle websocket pour les commentaires en direct entre les panneaux des analystes (en cours).
Contexte de l'application.
Capacité de déplacer des points de terminaison entre les contextes.
Potentiellement, reconcevoir l'arborescence des nœuds pour qu'elle soit basée sur la date de l'investigation.
Empilement sélectif, actuellement le sélecteur de nœud racine est activé.
Recherches routées par partition.
Modèle de script de collecte d'audit Redline.
Intégration plus poussée avec AngularJS (en cours).
Design responsive. (en cours).
Page de contrôle administratif pour la configuration des paramètres de base (en cours).
Auteurs et notes :
Nous sommes toujours à la recherche de personnes partageant les mêmes idées souhaitant contribuer à ce projet. Nous ne sommes en aucun cas des gourous du design web ; si vous pensez que nous pouvons faire mieux, veuillez soumettre une pull request et si elle nous plaît, nous la fusionnerons.
Daniel Eden & Roshan Maskey
Crédits :
Développeurs de Mandiant Redline, AngularJS, Django, Angular-DataTables/DataTables, D3 (Bostock), Elasticsearch/ES-dsl.py, jsTree, qTip, GOlang, Python, Fahad Abdulaal (Logo/Vidéo).
