Données d'un exercice d'émulation d'adversaires automatisé BRAWL
L’un des problèmes difficiles pour les chercheurs en cybersécurité qui développent des capacités de détection et de réponse est de trouver un environnement réaliste dans lequel tester leurs hypothèses et leurs capacités.
La méthode la moins coûteuse consiste à tester les capacités sur un petit réseau de laboratoire. Mais cet environnement manque de l’échelle d’un véritable réseau d’entreprise et du bruit des environnements réels qui rend la détection beaucoup plus difficile. À bien des égards, le meilleur environnement serait de tester sur plusieurs réseaux à l’échelle d’une entreprise avec un attaquant contrôlé mais réaliste et du bruit réel provenant des utilisateurs, des administrateurs système et des logiciels/périphériques tiers. Le défi de tester dans cet environnement est qu’il est coûteux et, dans certains scénarios, à haut risque.
BRAWL cherche à créer un compromis en créant un système pour créer automatiquement un réseau d’entreprise dans un environnement cloud. OpenStack est le seul environnement actuellement supporté, mais il est conçu de manière à pouvoir facilement supporter d’autres environnements cloud à l’avenir. BRAWL construit également un réseau d’analyse contenant un pipeline d’ingestion et de traitement des données utilisant LogStash et Kafka. Dans le cadre du réseau d’analyse, il crée un système de stockage et de recherche d’événements utilisant Elasticsearch et Kibana. BRAWL déploie un « Game Board » de réseau d’entreprise avec des images Windows. Ces images ont Microsoft Sysmon et d’autres capteurs déjà installés et configurés pour transmettre les journaux dans le framework d’ingestion de données.
BRAWL a également un concept de bots, qui peuvent être Rouges, Bleus ou Gris. Les bots Rouges sont offensifs, les bots Bleus sont défensifs, et les bots Gris émulent le comportement légitime des utilisateurs afin de fournir du bruit rendant la détection plus difficile. Lorsqu’un utilisateur souhaite tester des hypothèses de recherche, il implémente un bot BRAWL. Le bot BRAWL s’enregistre auprès du Contrôleur BRAWL, qui orchestre ensuite des jeux entre les bots BRAWL sur le Game Board.
Note : En raison de problèmes de taille de fichier et de quotas GitHub, nous plaçons tous les fichiers dans un fichier zip au lieu de les laisser en texte brut dans le dépôt git. Toutes les données sont dans le fichier
Cette version contient des données provenant d’un prototype BRAWL. Nous avons créé un petit réseau d’entreprise, décrit ci-dessous. Nous avons ensuite exécuté un seul jeu en utilisant le projet de recherche MITRE CALDERA comme bot rouge.
CALDERA est un projet de recherche connexe de MITRE qui automatise l’émulation d’adversaires basée sur les informations du modèle Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK). Il implémente un ensemble de tactiques et techniques ATT&CK et utilise un système de planification (https://dl.acm.org/citation.cfm?id=2991111) pour automatiser l’activation de ces techniques et générer un comportement d’adversaire post-compromission dans un réseau d’entreprise.
Ces données sont publiées sous la Licence Creative Commons BY
Notre petit réseau d’entreprise est un réseau plat qui se compose d’un contrôleur de domaine (dc.brawlco.com) et de 16 postes de travail. Chaque PC porte le nom de l’utilisateur principal dans le nom du PC (par exemple, l’utilisateur beane se connecte généralement à beane-pc). Cet utilisateur dispose de privilèges d’administrateur local sur l’ordinateur.
Tous les PC fonctionnent sous Windows 8.1. Le contrôleur de domaine fonctionne sous Windows Server 2012 R2.
Sur les PC Windows 8, nous avons apporté des modifications pour activer WDigest pour conserver les mots de passe en texte clair dans la mémoire de LSASS en utilisant la commande de registre suivante : reg ADD HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\ /v UseLogonCredential /t REG_DWORD /d 1 /F
Pour cet exercice, CALDERA était le seul bot BRAWL participant. Bien que conceptuellement BRAWL puisse être utilisé pour tester une variété de comportements d’attaquants et de détections, bon nombre des travaux de recherche de MITRE suivent une philosophie d’« hypothèse de compromission ». Par conséquent, nous donnons à CALDERA un point de départ en tant qu’administrateur local sur une boîte du réseau au début de l’exercice.
De plus, sans un bot gris effectuant des connexions sur différents hôtes, le Game Board BRAWL est stérile du point de vue des identifiants qui peuvent être volés et utilisés par les bots rouges. Pour permettre le mouvement latéral, le Contrôleur BRAWL utilise psexec pour créer des événements de connexion sur les hôtes avec les identifiants d’autres utilisateurs du réseau.
CALDERA a effectué les techniques ATT&CK suivantes pendant l’exercice :
Il y a cinq types de données dans ce dépôt. Chacun est contenu dans son propre fichier dans le dossier data/.
| Type de données | Description |
|---|---|
| game_metadata | Données décrivant le scénario BRAWL |
| sysmon | Données recueillies à partir de Sysmon exécuté sur chaque poste de travail |
| win_event | Journaux d’événements Windows |
| computer_properties | Données recueillies à partir de scripts personnalisés fournissant des informations sur les ordinateurs du réseau |
| bsf | Actions du bot rouge au format BRAWL Shared Format (BSF) |
Les bots rouges et les bots bleus sont encouragés à enregistrer des informations sur leurs activités ou détections au format BRAWL Shared Format (BSF). L’objectif est de faciliter la comparaison des détections/actions des bots bleus avec les actions des bots rouges.
Le format est actuellement en développement et pourrait changer dans les futurs ensembles de données.
Les champs du BSF sont décrits ci-dessous dans la section Détail des sources de données.
Différentes sources d’événements dans BRAWL gèrent le temps différemment. Le temps est soit le moment où un événement a atteint notre framework d’ingestion de journaux, soit le moment où l’événement a été généré sur l’hôte/point de terminaison, soit le moment enregistré par un bot sur le réseau. En général, ces temps devraient être à quelques millisecondes les uns des autres. Lorsque c’est possible, le framework d’ingestion utilise le temps de l’événement stocké dans l’événement plutôt que le moment où l’événement atteint les nœuds d’ingestion. Le tableau ci-dessous détaille la méthode utilisée pour chaque type de données.
| Source de données | Notes sur le temps |
|---|---|
| computer_properties | du champ time |
| game_metadata | moment où il atteint le framework d’ingestion |
| sysmon | du champ utc_time |
| win_event | extrait du temps de l’événement Windows |
| bsf | Le champ @timestamp est le moment où il atteint le framework d’ingestion. Cependant, les champs liés au temps dans BSF (par exemple, happened_after, happened_before, etc.) sont les moments où les événements ont commencé ou se sont terminés en fonction du temps sur le serveur de commande et de contrôle de CALDERA. |
| Nom du champ | Description |
|---|---|
| @timestamp | Temps lié à l’événement. Voir la note sur le temps ci-dessus. |
| @uuid | Identifiant unique d’événement |
| game_id | Le game_id unique pour cet exercice. |
| type | Type d’événement. Toujours game_metadata pour ces enregistrements |
| hosts | Une liste des hôtes qui faisaient partie de l’exercice et « dans les limites » pour le bot rouge |
| randomization_seed | Une graine qui peut être utilisée par les participants bots BRAWL pour implémenter un comportement « aléatoire » qui est le même d’une exécution à l’autre de BRAWL |
| starting_host | Hôte sur lequel le bot rouge commence. |
| Nom du champ | Description |
|---|---|
| @timestamp | Temps lié à l’événement. Voir la note sur le temps ci-dessus. |
| @uuid | Identifiant unique d’événement |
| type | Type d’événement. Toujours sysmon pour ces enregistrements |
| game_id | Le game_id unique pour cet exercice. |
| data_model.object | L’objet du CAR sur lequel on agit. |
| data_model.action | L’action du CAR effectuée sur l’objet. Ce champ est un tableau car certains événements peuvent correspondre à plus d’une action dans le modèle de données CAR. Un exemple est les événements de création de thread distant. |
| data_model.fields.* | Les champs pertinents pour la paire objet/action donnée. |
| game_id | Le game_id unique pour cet exercice. |
| host | Nom d’hôte à partir duquel l’événement a été enregistré. |
Nous utilisons Sysmon v3.11. sysmon_config.txt contient la sortie de la commande sysmon -c détaillant notre configuration.
Sysmon génère de nombreux types d’événements différents, qui correspondent à différentes paires objet/action CAR. Les champs pour chaque type sont expliqués plus en détail sur le site Web de CAR : https://car.mitre.org/wiki/Data_Model
Les paires objet/action générées par Sysmon dans notre configuration sont :
driver/loadfile/attr_modifyflow/startmodule/loadprocess/createprocess/terminatethread/createthreat/remote_createUtilisez le modèle de données CAR pour déterminer les noms de champs et la sémantique des champs contenus dans data_model.fields.* pour chaque paire objet/action ci-dessus.
| Nom du champ | Description |
|---|---|
| @timestamp | Temps lié à l’événement. Voir chaque événement ci-dessous pour les détails sur la façon dont il est calculé |
| @uuid | Identifiant unique d’événement |
| type | Type d’événement. Toujours win_event pour ces enregistrements |
| game_id | Le game_id unique pour cet exercice. |
| host | Hôte qui a enregistré l’événement |
| raw | L’entrée du journal des événements Windows dans son format XML brut |
| data_model.fields.log_name | Nom du journal Windows (Application, Système ou Sécurité) |
| data_model.fields.log_type | Le type de journal pour un log_name donné |
| Nom du champ | Description |
|---|---|
| @timestamp | Temps lié à l’événement. Voir la note sur le temps ci-dessus. |
| @uuid | Identifiant unique d’événement |
| type | Type d’événement. Toujours computer_properties pour ces enregistrements |
| game_id | Le game_id unique pour cet exercice. |
| host | Nom de l’ordinateur sur lequel le script a été exécuté |
| netinfo | Collection d’objets netinfo |
| netinfo.DNSServers | Collection de résolveurs DNS configurés pour cet hôte |
| netinfo.Gateway | Passerelle pour cette interface |
| netinfo.IPAddress | Adresses IP pour cette interface |
| netinfo.IsDHCPEnabled | DHCP activé ? |
| netinfo.MACAddress | Adresse MAC pour cette interface |
| netinfo.SubnetMask | Masque de sous-réseau pour les adresses IP respectives |
| pcinfo | Objet décrivant les informations sur le PC |
| pcinfo.AssetTag | Numéro d’inventaire si accessible |
| pcinfo.CPU | Informations sur le(s) CPU |
| pcinfo.ChassisType | Non utilisé dans BRAWL. « Inconnu » |
| pcinfo.Disks | Informations sur le(s) disque(s) attaché(s) |
| pcinfo.DomainName | Domaine dont le système fait partie |
| pcinfo.LastBootUpTime | Heure de démarrage du système |
| pcinfo.Memory | Informations sur la mémoire du système |
| pcinfo.OS | Informations sur le système d’exploitation en cours |
| pcinfo.SerialNumber | Numéro de série matériel |
| time | Heure à laquelle le script a été exécuté |
| userinfo | Tableau contenant des objets userinfo décrivant les utilisateurs qui se sont connectés au système depuis le dernier démarrage |
| userinfo.AuthenticationPackage | Package d’authentification utilisé pour l’authentification |
| userinfo.Domain | Domaine (ou PC local) auquel appartient le compte |
| userinfo.LogonId | Identifiant de connexion |
| userinfo.LogonTime | Heure de la connexion |
Ces données ont été collectées périodiquement à l’aide du module unified_json.ps1 de PowerShell Utilities for Security Situational Awareness de MITRE. Le champ userinfo peut être utile pour déterminer quels identifiants peuvent avoir été compromis si un extracteur d’identifiants tel que Mimikatz a été exécuté sur le système.
| Nom du champ | Description |
|---|---|
| @timestamp | Temps lié à l’événement. Voir la note sur le temps ci-dessus. |
| @uuid | Identifiant unique d’événement |
| type | Type d’événement. Toujours bsf_events pour ces enregistrements |
| game_id | Le game_id unique pour cet exercice. |
| bsf | Tableau d’événements BSF décrivant l’activité du bot. Les champs de ce tableau sont décrits plus en détail ci-dessous. |
| bsf_version | Version du schéma BSF utilisé pour le tableau d’événements bsf |
| producer_id | Bot qui a produit ces données BSF. |
Les objets à l’intérieur du champ tableau bsf sont de type operation, step ou event. Tous les objets ont un champ nodetype qui peut être utilisé pour déterminer le type d’objet.
event| Champ | Description |
|---|---|
| id | Un identifiant unique pour chaque événement. |
| nodetype | Le type de ce nœud. L’un de : {"operation", "step", "event"}. |
| host | Nom d’hôte ou IP auquel cet événement a été exécuté / détecté. |
| time | Note : Au moins un des trois champs de temps suivants (c’est-à-dire "time", "happened_after" ou "happened_before") doit être rapporté. "time" est particulièrement souhaité ; les trois sont encouragés. Veuillez consulter la note 1 dans les remarques générales ci-dessous. Note sur le format de temps : Toutes les informations de temps doivent être au format ISO 8601. Plus précisément comme : 'yyyy-mm-ddThh:nn:ss.llll00'. Où y est année, m est mois, d est jour, h est heure, n est minute, s est seconde, l est milliseconde (et il y a deux zéros de fin). Par exemple : 2017-02-22T18:38:14.060000 Optionnel : Estimation du moment où cet événement s’est produit. |
| happened_after | Optionnel : Une borne inférieure (« crochet temporel gauche ») sur l’incertitude dans "time". |
| happened_before | Optionnel : Une borne supérieure (« crochet temporel droit ») sur l’incertitude dans "time". |
| confidence | Optionnel : Permet aux bots bleus de communiquer la confiance (un nombre réel entre 0.0 et 1.0) dans l’association de cet événement avec une attaque. |
| object | Objet sur lequel on agit ; voir le tableau ci-dessous pour les valeurs autorisées. Basé librement sur le Modèle de données CAR |
| action | Actions pour un objet donné. Basé librement sur le Modèle de données CAR |
| specific_field_1 .. N | 1 à N attributs descriptifs (voir ci-dessous). Basé librement sur le Modèle de données CAR |
| Objet | Action | Champ(s) requis | Champ(s) optionnel(s) |
|---|---|---|---|
| process | create terminate scanned | Au moins un de : {pid, command_line, exe, image_path} | fqdn hostname md5_hash parent_exe parent_image_path ppid sha1_hash sha256_hash sid signer user |
| flow | start end message | Au moins un de : {src_hostname, src_ip} Au moins un de : {dest_hostname, dest_ip} Au moins un de : {src_port, dest_port, protocol} | content dest_fqdn exe flags fqdn hostname image_path packet_count pid ppid proto_info src_fqdn user |
| file | create delete modify read timestomp write | file_path | company file_name fqdn hostname image_path md5_hash pid ppid sha1_hash sha256_hash signer user |
Vous pouvez en savoir plus sur la sémantique des champs requis et optionnels en trouvant l’objet associé dans le Modèle de données CAR
stepLes objets Step connectent un ou plusieurs événements en un regroupement de plus haut niveau d’activité. Les objets Step offrent également un endroit pour que les émetteurs BSF étiquettent l’activité avec des libellés ATT&CK.
| Nom du champ | Description |
|---|---|
| id | Un identifiant unique pour les étapes d’opération. |
| nodetype | Le type de ce nœud. L’un de : {"operation", "step", "event"}. |
| attack_info | Un tableau d’objets technique (défini dans le tableau directement ci-dessous), décrivant comment cette étape se rapporte à la taxonomie ATT&CK. Pourquoi un tableau ? Bien qu’une seule technique décrive souvent une étape et tous ses événements, dans certains cas, plusieurs techniques peuvent être implémentées. |
| attack_info.technique_id | Un ID de technique ATT&CK (par exemple, « T1059 ») décrivant le mécanisme d’attaque employé par le rouge dans cette étape et ses événements référencés. |
| attack_info.technique_name | Une chaîne lisible décrivant cette technique (par exemple, « Command-Line Interface »). |
| attack_info.tactic | Un tableau d’un ou plusieurs libellés de tactique ATT&CK décrivant l’intention/stratégie de cette technique. (Notez qu’une seule technique peut exercer plusieurs tactiques.) Par exemple : ["Lateral Movement", "Execution"] |
| description | Optionnel : Des notes ou annotations pour cette étape vont ici. |
| events | Un tableau d’identifiants des objets event composant cette étape. |
operationLes objets Operation connectent plusieurs objets step ensemble. Cependant, il n’y a pas d’objets Operation présents dans cet ensemble de données.
Descriptions et notes pour les champs d’événement (surtout les « Au moins un de ») :1. Champs temporels.
event. Les autres champs sont optionnels, mais devraient être rapportés s'ils sont connus. En particulier, les bots sont encouragés à rapporter une valeur pour "time" qui est leur meilleure estimation, même s'ils n'ont pas un moment exact.command_line qui a lancé le processus, ou le exe / image_path qui a été exécuté peuvent être fournis.Hôtes sur notre réseau BRAWL pour cette partie :
| userinfo.LogonType | Constantes de type de connexion Windows |
| userinfo.LogonTypeName | Description du type de connexion |
| userinfo.UserName | Nom d’utilisateur du principal se connectant |