Dados de um Exercício BRAWL de Emulação Automatizada de Adversários
Um dos problemas desafiadores para pesquisadores de segurança cibernética que desenvolvem capacidades de detecção e resposta é encontrar um ambiente realista para testar suas hipóteses e capacidades.
O método mais barato é testar capacidades em uma pequena rede de laboratório. Mas esse ambiente carece da escala de uma rede empresarial real e do ruído de ambientes reais que torna a detecção muito mais difícil. Em muitos aspectos, o melhor ambiente seria testar em múltiplas redes de escala empresarial com um atacante controlado, mas realista, e ruído real de usuários, administradores de sistema e software/dispositivos de terceiros. O desafio de testar neste ambiente é que é caro e, em alguns cenários, de alto risco.
O BRAWL busca criar um compromisso ao gerar um sistema para criar automaticamente uma rede empresarial dentro de um ambiente de nuvem. OpenStack é o único ambiente atualmente suportado, mas está sendo projetado de forma a suportar facilmente outros ambientes de nuvem no futuro. O BRAWL também constrói uma rede de análise contendo um pipeline de ingestão e processamento de dados usando LogStash e Kafka. Como parte da rede de análise, ele cria um sistema de armazenamento e pesquisa de eventos usando Elasticsearch e Kibana. O BRAWL inicia um "Tabuleiro de Jogo" de rede empresarial com imagens Windows. Essas imagens têm o Microsoft Sysmon e outros sensores já instalados e configurados para encaminhar logs para o framework de ingestão de dados.
O BRAWL também possui um conceito de bots, que podem ser Vermelhos, Azuis ou Cinzas. Os bots Vermelhos são ofensivos, os Azuis são defensivos e os Cinzas emulam comportamento legítimo de usuário para fornecer ruído, tornando a detecção mais difícil. Quando um usuário deseja testar hipóteses de pesquisa, ele implementa um bot BRAWL. O bot BRAWL se registra no Controlador BRAWL, que então orquestra jogos entre bots BRAWL no Tabuleiro de Jogo.
Nota: Devido a problemas com tamanhos de arquivos e cotas do GitHub, estamos colocando todos os arquivos em um arquivo zip em vez de mantê-los como texto simples no repositório git. Todos os dados estão no arquivo
Este lançamento consiste em alguns dados de um protótipo do BRAWL. Criamos uma pequena rede empresarial, descrita abaixo. Em seguida, executamos um único jogo usando o projeto de pesquisa CALDERA da MITRE como um bot vermelho.
O CALDERA é um projeto de pesquisa relacionado da MITRE que automatiza atividades de emulação de adversários com base nas informações do modelo Táticas, Técnicas e Conhecimento Comum do Adversário (ATT&CK). Ele implementa um conjunto de táticas e técnicas ATT&CK e usa um sistema de planejamento (https://dl.acm.org/citation.cfm?id=2991111) para automatizar a atuação dessas técnicas e gerar comportamento adversário pós-comprometimento dentro de uma rede empresarial.
Estes dados são lançados sob a Licença Creative Commons BY
Nossa pequena rede empresarial é uma rede plana que consiste em um Controlador de Domínio (dc.brawlco.com) e 16 estações de trabalho. Cada PC tem o nome do usuário principal no nome do PC (por exemplo, o usuário beane normalmente faz login em beane-pc). Esse usuário tem privilégios de Administrador Local no computador.
Todos os PCs estão executando Windows 8.1. O Controlador de Domínio está executando Windows Server 2012 R2.
Nos PCs com Windows 8, fizemos alterações para habilitar o WDigest para manter senhas em texto simples na memória do LSASS usando o seguinte comando de registro: reg ADD HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\ /v UseLogonCredential /t REG_DWORD /d 1 /F
Para este exercício, o CALDERA foi o único bot BRAWL participante. Embora conceitualmente o BRAWL possa ser usado para testar uma variedade de comportamentos de atacantes e detecções, muitos dos esforços de pesquisa da MITRE seguem uma filosofia de "assumir violação". Portanto, damos ao CALDERA um ponto de partida como Administrador Local em uma máquina na rede no início do exercício.
Além disso, sem um bot Cinza realizando logon em diferentes hosts, o Tabuleiro de Jogo do BRAWL é estéril da perspectiva de credenciais que podem ser roubadas e usadas por bots Vermelhos. Para permitir movimento lateral, o Controlador BRAWL usa psexec para criar eventos de logon em hosts com as credenciais de outros usuários da rede.
O CALDERA executou as seguintes técnicas ATT&CK durante o exercício:
Existem cinco tipos de dados neste repositório. Cada um está contido em seu próprio arquivo na pasta data/.
| Tipo de Dado | Descrição |
|---|---|
| game_metadata | Dados descrevendo o cenário BRAWL |
| sysmon | Dados coletados do Sysmon em execução em cada uma das estações de trabalho |
| win_event | Logs de Eventos do Windows |
| computer_properties | Dados coletados de scripts personalizados que fornecem algumas informações sobre os computadores na rede |
| bsf | Ações do bot Vermelho no Formato Compartilhado BRAWL (BSF) |
Bots Vermelhos e bots Azuis são incentivados a registrar informações sobre suas atividades ou detecções no Formato Compartilhado BRAWL (BSF). O objetivo disso é facilitar a comparação entre detecções/ações do bot Azul e ações do bot Vermelho.
O formato está atualmente em desenvolvimento e pode mudar em conjuntos de dados futuros.
Os campos para BSF são descritos abaixo na seção Detalhes das Fontes de Dados.
Diferentes fontes de eventos no BRAWL lidam com o tempo de forma diferente. O tempo é ou o momento em que um evento atingiu nosso framework de ingestão de logs, o momento em que o evento foi gerado no host/endpoint, ou o momento registrado por um bot na rede. Em geral, esses tempos devem estar dentro de alguns milissegundos uns dos outros. Quando possível, o framework de ingestão de logs usa o tempo do evento armazenado no evento em vez do tempo do evento ao atingir os nós de ingestão. A tabela abaixo detalha o método usado para cada tipo de dado.
| Fonte de Dados | Notas sobre o Tempo |
|---|---|
| computer_properties | do campo time |
| game_metadata | tempo em que atinge o framework de ingestão |
| sysmon | do campo utc_time |
| win_event | extraído do tempo do evento do Windows |
| bsf | O campo @timestamp é o tempo em que atinge o framework de ingestão. No entanto, os campos BSF relacionados ao tempo (por exemplo, happened_after, happened_before, etc.) são os horários em que os eventos começaram ou terminaram com base no horário no servidor de comando e controle do CALDERA. |
| Nome do Campo | Descrição |
|---|---|
| @timestamp | Tempo relacionado ao evento. Veja a nota sobre o tempo acima. |
| @uuid | ID Único do Evento |
| game_id | O game_id único para este exercício. |
| type | Tipo de Evento. Sempre game_metadata para esses registros |
| hosts | Uma lista de hosts que fizeram parte do exercício e "dentro dos limites" para o bot vermelho |
| randomization_seed | Uma semente que pode ser usada pelos Participantes do Bot BRAWL para implementar comportamento "aleatório" que seja o mesmo em diferentes execuções do BRAWL |
| starting_host | host no qual o bot vermelho começa. |
| Nome do Campo | Descrição |
|---|---|
| @timestamp | Tempo relacionado ao evento. Veja a nota sobre o tempo acima. |
| @uuid | ID Único do Evento |
| type | Tipo de Evento. Sempre sysmon para esses registros |
| game_id | O game_id único para este exercício. |
| data_model.object | O CAR objeto sendo atuado. |
| data_model.action | A CAR ação sendo executada no objeto. Este campo é um array porque alguns eventos podem corresponder a mais de uma ação no modelo de dados CAR. Um exemplo disso são eventos de criação de thread remota. |
| data_model.fields.* | Os campos relevantes para o par objeto/ação fornecido. |
| game_id | O game_id único para este exercício. |
| host | Nome do host do qual o evento foi registrado. |
Estamos usando Sysmon v3.11. sysmon_config.txt contém a saída do comando sysmon -c detalhando nossa configuração.
O Sysmon gera muitos tipos diferentes de eventos, que mapeiam para diferentes pares CAR objeto/ação. Os campos para cada tipo são explicados em mais detalhes no site do CAR: https://car.mitre.org/wiki/Data_Model
Os pares objeto/ação gerados pelo Sysmon em nossa configuração são:
driver/loadfile/attr_modifyflow/startmodule/loadprocess/createprocess/terminatethread/createthreat/remote_createUse o modelo de dados CAR para determinar os nomes dos campos e as semânticas para os campos contidos em data_model.fields.* para cada par objeto/ação acima.
| Nome do Campo | Descrição |
|---|---|
| @timestamp | Tempo relacionado ao evento. Veja cada evento abaixo para detalhes sobre como isso é calculado |
| @uuid | ID Único do Evento |
| type | Tipo de Evento. Sempre win_event para esses registros |
| game_id | O game_id único para este exercício. |
| host | Host que registrou o evento |
| raw | A entrada do log de eventos do Windows em seu formato XML bruto |
| data_model.fields.log_name | Nome do Log do Windows (Aplicação, Sistema ou Segurança) |
| data_model.fields.log_type | O tipo de log para um determinado log_name |
| Nome do Campo | Descrição |
|---|---|
| @timestamp | Tempo relacionado ao evento. Veja a nota sobre o tempo acima. |
| @uuid | ID Único do Evento |
| type | Tipo de Evento. Sempre computer_properties para esses registros |
| game_id | O game_id único para este exercício. |
| host | Nome do computador no qual o script foi executado |
| netinfo | Coleção de objetos netinfo |
| netinfo.DNSServers | coleção de resolvedores DNS configurados para este host |
| netinfo.Gateway | Gateway para esta interface |
| netinfo.IPAddress | Endereços IP para esta interface |
| netinfo.IsDHCPEnabled | O DHCP está habilitado? |
| netinfo.MACAddress | Endereço MAC para esta interface |
| netinfo.SubnetMask | Máscara de Sub-rede para os respectivos endereços IP |
| pcinfo | Objeto descrevendo informações sobre o PC |
| pcinfo.AssetTag | AssetTag se acessível |
| pcinfo.CPU | Informações sobre a(s) CPU(s) |
| pcinfo.ChassisType | Não usado no BRAWL. "Desconhecido" |
| pcinfo.Disks | Informações sobre o(s) disco(s) anexado(s) |
| pcinfo.DomainName | domínio do qual o sistema faz parte |
| pcinfo.LastBootUpTime | Horário em que o sistema foi inicializado |
| pcinfo.Memory | Informações sobre a memória nos sistemas |
| pcinfo.OS | Informações sobre o SO em execução |
| pcinfo.SerialNumber | Número de Série do HW |
| time | Horário em que o script foi executado |
| userinfo | Array contendo objetos userinfo descrevendo usuários que fizeram login no sistema desde a última inicialização |
| userinfo.AuthenticationPackage | Pacote de Autenticação usado para autenticação |
| userinfo.Domain | Domínio (ou PC local) ao qual a conta pertence |
| userinfo.LogonId | LogonId |
| userinfo.LogonTime | Horário do logon |
| userinfo.LogonType |
Estes dados foram coletados periodicamente usando o módulo unified_json.ps1 do PowerShell Utilities for Security Situational Awareness da MITRE. O campo userinfo pode ser útil para determinar quais credenciais podem ter sido comprometidas se um extrator de credenciais como o Mimikatz foi executado no sistema.
| Nome do Campo | Descrição |
|---|---|
| @timestamp | Tempo relacionado ao evento. Veja a nota sobre o tempo acima. |
| @uuid | ID Único do Evento |
| type | Tipo de Evento. Sempre bsf_events para esses registros |
| game_id | O game_id único para este exercício. |
| bsf | Array de eventos BSF descrevendo a atividade do bot. Os campos para este array são descritos em mais detalhes abaixo. |
| bsf_version | Versão do esquema BSF usado para o array de eventos bsf |
| producer_id | Bot que produziu estes dados BSF. |
Os objetos dentro do campo do array bsf são do tipo operation, step ou event. Todos os objetos possuem um campo nodetype que pode ser usado para determinar o tipo do objeto.
event| Campo | Descrição |
|---|---|
| id | Um identificador único para cada evento. |
| nodetype | O tipo deste nó. Um de: {"operation", "step", "event"}. |
| host | Nome do host ou IP no qual este evento foi executado / detectado. |
| time | Nota: Pelo menos um dos três campos de tempo a seguir (ou seja, "time", "happened_after" ou "happened_before") deve ser informado. "time" é especialmente desejado; todos os três são encorajados. Veja a nota 1 nas Notas Gerais abaixo. Nota sobre o formato do tempo: Toda informação de tempo deve estar no formato ISO 8601. Mais especificamente como: 'yyyy-mm-ddThh:nn:ss.llll00'. Onde y é ano, m é mês, d é dia, h é hora, n é minuto, s é segundo, l é milissegundo (e há dois zeros à direita). Por exemplo: 2017-02-22T18:38:14.060000 Opcional: Estimativa do momento em que este evento ocorreu. |
| happened_after | Opcional: Um limite inicial ("colchete temporal esquerdo") para incerteza em "time". |
| happened_before | Opcional: Um limite tardio ("colchete temporal direito") para incerteza em "time". |
| confidence | Opcional: Permite que bots Azuis comuniquem a confiança (um número real entre 0.0 e 1.0) na associação deste evento com um ataque. |
| object | Objeto sobre o qual se age; veja a tabela abaixo para valores permitidos. Vagamente baseado no Modelo de Dados CAR |
| action | Ações para um determinado objeto. Vagamente baseado no Modelo de Dados CAR |
| specific_field_1 .. N | 1-N atributos descritivos (veja abaixo). Vagamente baseado no Modelo de Dados CAR |
| Objeto | Ação | Campo(s) Obrigatório(s) | Campo(s) Opcional(is) |
|---|---|---|---|
| process | create terminate scanned | Pelo menos um 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 | Pelo menos um de: {src_hostname, src_ip} Pelo menos um de: {dest_hostname, dest_ip} Pelo menos um 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 |
Você pode ler mais sobre as semânticas dos Campos Obrigatórios e Opcionais encontrando o objeto associado no Modelo de Dados CAR
stepObjetos step conectam um ou mais eventos em um agrupamento de nível superior de atividade. Objetos step também apresentam um lugar para emissores BSF rotularem a atividade com rótulos ATT&CK.
| Nome do campo | Descrição |
|---|---|
| id | Um identificador único para etapas de operação. |
| nodetype | O tipo deste nó. Um de: {"operation", "step", "event"}. |
| attack_info | Um array de objetos de técnica (definidos na tabela diretamente abaixo), descrevendo como esta etapa se relaciona com a taxonomia ATT&CK. Por que um array? Embora uma única técnica frequentemente descreva uma etapa e todos os seus eventos, em alguns casos, múltiplas técnicas podem ser implementadas. |
| attack_info.technique_id | Um ID de técnica ATT&CK (por exemplo, "T1059") descrevendo o mecanismo de ataque que o Vermelho empregou nesta etapa e seus eventos referenciados. |
| attack_info.technique_name | Uma string legível por humanos descrevendo esta técnica (por exemplo, "Interface de Linha de Comando"). |
| attack_info.tactic | Um array de um ou mais rótulos de tática ATT&CK descrevendo a intenção/estratégia desta técnica. (Observe que uma única técnica pode exercer múltiplas táticas.) Por exemplo: ["Movimento Lateral", "Execução"] |
| description | Opcional: Notas ou anotações para esta etapa vão aqui. |
| events | Um array de ids dos objetos event que compõem esta etapa. |
operationObjetos operation conectam múltiplos objetos step juntos. No entanto, não há objetos Operation presentes neste conjunto de dados.
Descrições e Notas para Campos de Evento (especialmente "Pelo menos um de"s):1. Campos de tempo.
time. No entanto, é possível que nem o vermelho nem o azul saibam o timestamp exato. Por exemplo, bots vermelhos podem iniciar um processo para realizar alguma ação dentro de uma janela de tempo, mas o momento exato em que a ação ocorre é desconhecido. Bots azuis podem usar sensores que envolvem atrasos de detecção. Assim, o BSF também fornece dois campos de tempo happened\_after e happened\_before como colchetes temporais esquerdo e direito, respectivamente, definindo limites para um intervalo de incerteza do evento real. Pelo menos um desses três campos (ou seja, time, happened_after, happened_before) deve ser informado em cada objeto event. Os outros campos são opcionais, mas devem ser informados conforme são conhecidos. Em particular, os bots são incentivados a reportar um valor para "time" que seja sua melhor estimativa, mesmo que não tenham um horário exato.pid é usado para identificar um processo, no entanto o pid nem sempre é conhecido, especialmente pelo bot vermelho. Alternativamente, o command_line que iniciou o processo, ou o exe / image_path que foi executado podem ser fornecidos.Hosts na nossa rede BRAWL para este jogo:
| Constantes de Tipo de Logon do Windows |
| userinfo.LogonTypeName | Descrição do LogonType |
| userinfo.UserName | Nome de Usuário do principal que está fazendo logon |