Preâmbulo
Em nossa primeira postagem da série Detonate, apresentamos o sistema Detonate e para que o usamos na Elastic. Também discutimos os benefícios que isso proporciona à nossa equipe ao avaliar o desempenho de nossos artefatos de segurança.
Nesta publicação, detalharemos como o Detonate funciona e nos aprofundaremos na implementação técnica. Isso inclui como conseguimos criar esse ambiente de sandbox na prática, a tecnologia que dá suporte ao pipeline geral e como enviamos e lemos informações do pipeline.
Interessado em outras postagens no Detonate? Confira a Parte 1 - Clique, Clique…Boom! onde apresentamos o Detonate, por que o construímos, exploramos como o Detonate funciona, descrevemos estudos de caso e discutimos testes de eficácia.
Arquitetura
Abaixo está uma visão geral de alto nível da arquitetura de ponta a ponta do Detonate.
O sistema geral consiste em uma série de filas de mensagens e trabalhadores Python. Tarefas de detonação são criadas por um servidor de API ao aceitar uma solicitação com o mínimo de informações possível, como o hash do arquivo de amostra. A tarefa então passa de uma fila para outra, sendo assumida por trabalhadores que executam várias operações ao longo do caminho.
O servidor e os trabalhadores são executados em um contêiner no Amazon ECS. O pipeline também pode ser criado localmente usando o Docker Compose para desenvolvimento inicial e testes de recursos.
Servidor API
O servidor Detonate API é um aplicativo Python FastAPI que aceita uma variedade de solicitações de destino de execução: hashes de amostras, comandos nativos (em bash ou Powershell, com ou sem argumentos) e arquivos enviados. O servidor também expõe endpoints para buscar alertas e telemetria bruta de agentes de um cluster Elastic.
A documentação da API é gerada automaticamente pelo FastAPI e incorporada ao nosso esquema global de API.
Interagindo com o servidor API - CLI
Criamos uma ferramenta Python CLI (interface de linha de comando) personalizada para interagir com nosso servidor Detonate. A ferramenta CLI é criada usando a biblioteca Python click juntamente com rich para uma bela experiência de formatação em uma janela de terminal. A ferramenta é particularmente útil para depurar o pipeline, pois também pode ser executada em uma configuração de pipeline local. A ferramenta é instalada e executada usando o Poetry, nossa ferramenta preferida para gerenciar dependências e executar scripts.
❯ DETONATE_CLI_API_ROOT_URL="${API_ENDPOINT_URL}" \
DETONATE_CLI_API_AUTH_HEADER="${API_KEY}" \
poetry run cli \
--hash "${MY_FILE_HASH}"Interagindo com o servidor de API - Web UI
Internamente, hospedamos um site chamado Portal de Proteções (escrito usando componentes Elastic UI ) para auxiliar nossa equipe com pesquisas. Para uma experiência mais interativa com a API do Detonate, criamos uma página no Portal para interagir com ela. Além de enviar tarefas, a interface da Web permite que os usuários vejam o feed de todas as detonações e os detalhes de cada tarefa.
Cada tarefa pode ser expandida para ver todos os detalhes. Fornecemos os links para os dados e telemetria coletados durante a detonação.
Interagindo com o servidor API - cliente HTTP
Se nossos usuários quiserem personalizar como interagem com a API Detonate, eles também podem executar comandos usando o cliente HTTP de sua escolha (como curl , httpie , etc.). Isso permite que eles adicionem detonações aos scripts ou como etapas finais no final de seus próprios fluxos de trabalho.
Queues
O pipeline é construído em uma série de filas e trabalhadores. Tendo requisitos muito básicos para o mecanismo de filas de mensagens, decidimos usar o Amazon SQS. Um dos muitos benefícios de usar um serviço popular como o SQS é a disponibilidade de recursos e bibliotecas de código aberto nos quais podemos construir. Por exemplo, usamos imagens Docker softwaremill/elasticmq como um mecanismo de fila ao executar o pipeline localmente.
As filas são configuradas e implantadas com o código Terraform que cobre toda a nossa infraestrutura de produção e preparação.
Trabalhadores
Cada trabalhador é um script Python que atua como um consumidor e um produtor de fila. Os trabalhadores são implementados em nosso mini-framework personalizado, com o código padrão para tratamento de erros, novas tentativas e monitoramento integrado. Nossa base de trabalhadores é facilmente estendida, o que nos permite adicionar novos trabalhadores e desenvolver os existentes caso surjam requisitos adicionais.
Para monitoramento, usamos a solução de observabilidade Elastic APM . Ele é incrivelmente poderoso, nos dá uma visão do fluxo de execução e facilita a depuração de problemas de pipeline. Abaixo, podemos ver uma tarefa Detonate se movendo entre os trabalhadores na interface do usuário do APM:
Esses componentes de software e infraestrutura nos fornecem tudo o que precisamos para realizar o envio, a execução e a coleta de dados que compõem uma detonação.
Detonações
O pipeline pode executar comandos e amostras em máquinas virtuais (VMs) Windows, Linux e macOS. Para ambientes Windows e Linux, usamos instâncias de VM no Google Compute Engine. Com a ampla seleção de imagens públicas, podemos provisionar ambientes sandbox com diferentes versões do Windows, Debian, Ubuntu, CentOS e RHEL.
Para ambientes macOS, usamos instâncias mac1.metal na AWS e uma solução de provisionamento de VM macOS sob demanda da Veertu chamada Anka. O Anka nos dá a capacidade de rotacionar rapidamente várias VMs do macOS em execução na mesma instância bare metal do macOS.
Atualmente, o Detonate está focado na amplitude da nossa cobertura de sistema operacional, na escalabilidade e na coleta de dados contextualmente relevantes do pipeline. A adaptação de sofisticadas contramedidas antianálise ao Detonate está sendo pesquisada e desenvolvida atualmente.
Provisionamento de VM
Para manter nossa pegada na VM no mínimo, usamos scripts de inicialização para provisionamento. Minimizar nossa pegada é importante porque nossas atividades dentro de uma VM são incluídas nos eventos que coletamos, tornando a análise mais complicada após uma execução. Para VMs Windows e Linux, scripts de inicialização do GCP escritos em Powershell e bash são usados para configurar o sistema; para VMs macOS, escrevemos scripts bash e AppleScript personalizados.
Os scripts de inicialização executam estas etapas:
- Configurar o sistema. Por exemplo, desabilitar o MS Defender, habilitar a execução de macros no MS Office, desabilitar atualizações automáticas do sistema, etc.
- Baixe e instale o agente Elastic. O script verifica se o agente está devidamente registrado no Fleet Server e se as políticas foram aplicadas.
- Baixe e detone uma amostra ou execute um conjunto de comandos. A execução acontece em um processo em segundo plano, enquanto o script principal coleta os fluxos de dados STDOUT / STDERR e dorme por N segundos.
- Colete arquivos do sistema de arquivos (se necessário) e carregue-os no armazenamento. Isso nos permite fazer qualquer verificação ou depuração adicional depois que a detonação estiver concluída.
O ciclo de vida da VM é gerenciado pelos trabalhadores start_vm e stop_vm . Como esperamos que algumas detonações interrompam o fluxo de execução do script de inicialização (por exemplo, no caso de ransomware), cada VM tem um TTL definido, o que permite que o trabalhador stop_vm exclua VMs que não estão mais em uso.
Essa abordagem de limpeza, com o script de inicialização usado para configurar tudo o que é necessário para uma detonação, nos permite usar imagens de VM dos fornecedores do catálogo de imagens públicas do Google Cloud sem nenhuma modificação!
Configuração de rede
Algumas das amostras que detonamos são maliciosas e podem produzir tráfego malicioso, como varreduras de rede, chamadas C2, etc. Para manter nossos recursos de nuvem e a infraestrutura de nossos fornecedores seguros, limitamos todo o tráfego de saída de VMs. As instâncias são colocadas em uma VPC bloqueada que permite conexão de saída apenas para uma lista predefinida de destinos. Restringimos os fluxos de tráfego no VPC usando as rotas e regras de firewall do Google Cloud e os grupos de segurança da AWS.
Também usamos VPC Flow Logs no GCE. Esses logs nos permitem ver o tráfego de rede privada iniciado por VMs sandbox em nossa VPC.
Coleta de telemetria
Para observar detonações, usamos o Elastic Agent com a integração Elastic Defend instalada com todas as proteções no modo “Detectar” (em vez de “Proteger”). Isso nos permite coletar o máximo de informações possível de uma VM e, ao mesmo tempo, permitir que a solução Elastic Security produza alertas e detecções.
Cobrimos dois casos de uso com essa arquitetura: podemos validar proteções (comparando eventos e alertas produzidos para diferentes versões de SO, versões de agentes, artefatos de segurança implantados, etc.) e coletar telemetria para análise (para novas amostras ou malware novo) ao mesmo tempo. Todos os dados coletados são mantidos em um cluster Elastic persistente e ficam disponíveis para nossos pesquisadores.
Em produção
Recentemente, concluímos um mês inteiro de execução do pipeline Detonate em produção, sob a carga de múltiplas integrações de dados, atendendo usuários internos por meio da interface do usuário ao mesmo tempo. Nosso recorde até agora é de 1034 detonações em um único dia e, até agora, não vimos nenhum problema de escalabilidade ou confiabilidade.
A maior parte dos envios são amostras específicas do Windows, por enquanto. Estamos trabalhando para aumentar nossa cobertura sobre Linux e macOS também – fique ligado nas postagens do blog de pesquisa que serão lançadas em breve!
Estamos constantemente melhorando nosso suporte para vários tipos de arquivo, garantindo que a detonação seja o mais próxima possível do comportamento de disparo pretendido.
Observando as detonações do último mês, vemos que a maioria das tarefas foi concluída em menos de 13 minutos (com uma mediana de 515 segundos). Esse tempo inclui preparação de dados de tarefas, provisionamento e limpeza de VM, execução de amostra e processamento pós-detonação.
Ainda estamos nos primórdios do serviço, então é normal ver exceções. Como a maior parte do tempo de uma tarefa é gasto esperando o provisionamento de uma VM, podemos melhorar o tempo geral de execução usando imagens de VM personalizadas, pré-iniciando instâncias de VM e otimizando os scripts de inicialização.
E o que vem em seguida?
Agora que você viu como o Detonate funciona, nossas próximas postagens abordarão casos de uso mais detalhados do Detonate. Iremos nos aprofundar mais em como essas detonações se transformam em proteção para mais usuários, inclusive aqui na Elastic!