Framework Forense de Resposta a Incidentes
Aplicação personalizada para apresentação assíncrona de dados forenses em um backend Elasticsearch.
Esta aplicação foi projetada para ingerir um arquivo de "coleções" do Mandiant Redline e oferecer flexibilidade em pesquisa/empilhamento e marcação.
A aplicação nasceu da incapacidade de controlar múltiplas investigações (ou centenas de endpoints) em um único painel.
Para ingerir auditorias do Redline, criamos o nightHawkResponse, uma aplicação GOpher completa projetada para acompanhar este framework. O código fonte da aplicação está disponível neste repositório, um binário foi compilado e está em execução dentro da ISO, pronto para ingerir desde o primeiro boot.
Estamos atualmente desenvolvendo uma nova versão principal e a lançaremos até março de 2020. A nova versão tem como objetivo realizar o seguinte.
Percebemos que havia muitas partes móveis para operar efetivamente todo o repositório, gerenciar facilmente entidades e manter tudo atualizado. Acreditamos também que os dados principais que residem no Elastic devem ser usados de forma mais eficaz pelo Kibana e, por isso, decidimos tornar isso realidade desenvolvendo um plugin que faz isso junto com o incrível fluxo de trabalho do Kibana.
Instalação
Documentação da API a seguir na Wiki
01/09/2016: Versão 1.0.3
Funcionalidades:
Demonstração em vídeo: Plataforma nightHawk Response
Para facilitar para os usuários do nightHawk, construímos uma ISO com tudo configurado e pronto para uso. Isso significa que você obtém o seguinte;
/opt/nighthawk/etc/nightHawk.json. Iniciando o sistema:
Antes de construir sua VM com a ISO fornecida, considere o seguinte;
Pendente: Configurar o serviço Elastic como nós duplos com 1/4 da memória do sistema alocada por nó. Isso significa que se você der 2GB de RAM, cada nó ES terá 512MB e o sistema permanecerá com 1GB para operar.
Se você quiser configurar de forma diferente, faça SSH na máquina e configure da maneira desejada.
Um mínimo de 20GB deve ser considerado. Um arquivo de auditoria pode ser grande, portanto, é aconselhável alocar muito armazenamento para lidar com a ingestão de muitas coleções.
Pendente: Configuração de armazenamento baseada em usuário para instâncias de grande escala. Se desejar configurar partições extras, você pode fazer isso; algumas alterações podem ser feitas para apontar o armazenamento de dados do ES para sua nova partição.
Instalação:
Baixar ISO: nightHawk v1.0.3
Configure o hardware, monte a ISO na VM, inicie o script de instalação.
Uma vez concluído, no seu navegador (Chrome/FireFox), acesse; https://192.168.42.173.
Faça login no sistema com 'nighthawk/nighthawk' - clique em "goto site" para entrar na aplicação
Se precisar acessar o Kibana, acesse; https://192.168.42.173:8443.
Se precisar fazer SSH na máquina, os detalhes de login são; admin/nightHawk.
Se quiser alterar o endereço IP (refletido em toda a aplicação); /opt/nighthawk/bin/nighthawkctl set-ip <novo_endereco_ip>
O Script de Coleta de Auditoria Redline pode ser encontrado na raiz deste repositório. Use-o ao usar o coletor autônomo Redline, pois ele retornará os documentos necessários para preencher o nightHawk corretamente.
Upload:
IMPORTANTE:
Criando arquivo zip de auditoria para upload (Coletor autônomo Redline):
passo_1: Navegue até Sessions\AnalysisSessionX\Audits<ComputerName> onde X é o número da análise, que é 1 na maioria dos casos.
passo_2: Crie um zip da pasta contendo os arquivos de auditoria, ex: 20160708085733
passo_3: Faça upload de 20160708085733.zip
IMPORTANTE: Use o arquivo de auditoria HX existente (Coletor HX): As auditorias do FireEye HX são uma extensão que termina em .mans. A auditoria do HX difere do coletor Redline porque o .mans que ele retorna é na verdade um arquivo zip. Isso significa que pode ser enviado diretamente, ao contrário da auditoria Redline, para a qual você precisa seguir as instruções acima.
Navegue até o ícone "Upload" na barra de navegação, selecione um .zip de auditoria (ou vários), um nome de caso (caso contrário, o sistema fornecerá um) e envie. Se você usou nosso script de auditoria Redline para construir sua coleção, siga as instruções do "Coletor Redline" acima.
Uma vez processado, o endpoint aparecerá no nó da árvore "Investigações Atuais". Abaixo do endpoint, você verá todos os tipos de auditoria disponíveis para aquele endpoint. O recurso de upload desta aplicação web cria subprocessos pOpen que chamam a aplicação GO para analisar a auditoria Redline e enviar dados para o Elasticsearch. Existem 2 opções para upload, uma é sequencial, a outra é simultânea.
Por favor, observe: Uploads simultâneos são limitados a 5 por vez e podem consumir muitos recursos; se você tiver uma máquina com pouca potência, restrinja o uso deste recurso a 2-3.
Marcação:
Você pode clicar em qualquer linha de qualquer tabela (na visualização de resposta) para marcar esses dados. Uma vez marcados, você pode visualizar os comentários na visualização de comentários.
Elasticsearch:
Existem mapeamentos personalizados (fornecidos na raiz do git) e comentários consultivos sobre o seguinte;
Os documentos são indexados via aplicação GO como relação pai/filho. Isso foi escolhido porque é capaz de fornecer um caminho relativamente lógico para visualizar documentos, ou seja, o pai é o nome do endpoint e os filhos são os tipos de auditoria. Realizar agregações em um documento relacional pai/filho em escala também parece fazer sentido. A estrutura de empilhamento depende da construção de pais em um array para então obter todas as agregações de documentos filhos para certos tipos de auditoria.
As configurações do Elasticsearch exigem ajustes e reconhecimento de design adequado. A fragmentação é importante de entender por causa da forma como estamos vinculando documentos pai/filho. O filho é SEMPRE roteado para o pai, não pode existir sozinho. Isso significa que deve-se considerar quantos fragmentos residem no índice. Pelo que entendemos, pode ser sábio escolher uma configuração que incorpore muitos nós com fragmentos únicos. Para ganhar desempenho com esse tipo de configuração, estamos trabalhando em pesquisas roteadas por fragmentos.
Atualmente, estamos trabalhando no design da melhor configuração possível para pesquisa rápida.
Esta aplicação é projetada para escalar imensamente. Desde o conceito inicial de design, fomos capazes de executá-la suavemente em uma VM Ubuntu de CPU única e 2GB com 3 nós ES (Macbook Pro), com cerca de 4 milhões+ de documentos (ou 50 endpoints ingeridos). Se for para produção, executando uma configuração com 64/128GB de RAM e armazenamento SAS, você seria capaz de manter um tempo de resposta extremamente rápido na recuperação de documentos, enquanto muitos analistas trabalham na aplicação ao mesmo tempo.
Considerações:
Processamento misto de DataTables:
Existem vários tipos de auditoria ingeridos que são grandes demais para retornar todos os documentos à tabela. Por exemplo, histórico de URL e Registro podem retornar 15k documentos ao DOM, renderizar isso colocaria pressão no navegador do cliente. Para combater isso, estamos usando processamento no lado do servidor para paginar os resultados de certos tipos de auditoria. Isso significa que você também pode pesquisar documentos no tipo de auditoria usando o Elasticsearch no backend.
Marcação:
Atualmente, podemos marcar documentos e visualizar esses comentários. Podemos atualizá-los ou alterá-los. O analista pode fornecer contexto como Data/Nome do Analista/Comentário ao documento.
Dependências (todas pré-instaladas):
elasticsearch-dsl.py
django 1.8
python requests
A fazer:
Manipuladores de Processo (em andamento).
Controles deslizantes de seleção de tempo para geradores baseados em tempo (em andamento).
Menu de contexto para Investigações Atuais/Anteriores.
Contexto de marcação. O sistema de marcação será integrado em um loop de websocket para comentários ao vivo entre painéis de analistas (em andamento).
Contexto da aplicação.
Capacidade de mover endpoints entre qualquer contexto.
Potencialmente redesenhar a árvore de nós para ser orientada por data de investigação.
Empilhamento seletivo; atualmente, o seletor de nó raiz está ativado.
Pesquisas roteadas por fragmentos.
Modelo de script de auditoria Redline.
Integração mais extensa com AngularJS (em andamento).
Design responsivo. (em andamento).
Página de controle administrativo para configuração de configurações principais (em andamento).
Autores e Notas:
Estamos sempre procurando pessoas com interesses semelhantes que queiram contribuir com este projeto; de forma alguma somos gurus de design web; se você acha que podemos fazer algo melhor, por favor, solicite um pull e, se gostarmos, faremos o merge.
Daniel Eden & Roshan Maskey
Créditos:
Mandiant Redline devs, AngularJS, Django devs, Angular-DataTables/DataTables, D3 (Bostock), Elasticsearch/ES-dsl.py, jsTree, qTip, GOlang, Python, Fahad Abdulaal (Logo/Video).
