Automatizando o GOAD e os Laboratórios de Malware em Tempo Real

Introdução: A necessidade de uma gama de simulação escalável e automatizada

Nas operações de segurança modernas, a engenharia de detecção deixou de ser uma disciplina do tipo "configure e esqueça". O principal desafio para qualquer equipe de segurança – e a questão que fundamenta toda a abordagem de equipe roxa – é simples: como saber se as regras de detecção realmente funcionam? A validação contínua da lógica de detecção em relação a um conjunto de ferramentas adversárias em constante evolução tornou-se um requisito fundamental.

Sem dúvida, o maior obstáculo para este exercício sempre foi a montagem do laboratório. Provisionar manualmente uma floresta do Active Directory com vários domínios, configurá-la com vulnerabilidades específicas e implantar um ambiente de análise de malware separado e isolado é um processo complexo e demorado. Esse trabalho repetitivo de configuração consome significativamente o recurso mais valioso de uma organização: o tempo de seus analistas de segurança seniores. Discussões na comunidade ecoam essa frustração, destacando as horas perdidas com a configuração manual antes que um único teste possa ser executado.

Este blog detalha uma solução moderna que elimina esse gargalo, combinando a rápida automação da infraestrutura com uma plataforma unificada de análise de segurança. A solução utiliza dois componentes principais:

1. LudusUma plataforma de automação de código aberto que implementa e configura ambientes cibernéticos complexos com múltiplas máquinas virtuais a partir de um único comando.
2. Elastic SecurityA plataforma que unifica o Gerenciamento de Eventos e Informações de Segurança (SIEM), a Detecção e Resposta Estendida (XDR) e a segurança na nuvem, fornecendo uma solução consolidada para ingerir, detectar e responder a ameaças. Oferece a "visibilidade ilimitada" necessária para observar cada ação dentro do ambiente simulado.

O objetivo deste guia é fornecer um roteiro definitivo, passo a passo, para a construção deste sistema integrado. Este curso mostrará como migrar de testes de laboratório lentos, manuais e inconsistentes para um fluxo de trabalho de engenharia de detecção contínuo, automatizado e escalável, que vai além do que o Elastic Cortado oferece.

Arquitetura da solução: Ludus + Elastic

Essa arquitetura representa uma simulação de alta fidelidade de uma empresa híbrida moderna. A gama Ludus funciona como o centro de dados "local" ou IaaS, enquanto a implementação do Elastic Cloud representa a pilha de segurança "SaaS". Este modelo espelha perfeitamente os ambientes híbridos e multicloud que o Elastic Security foi projetado para proteger, tornando a arquitetura do teste tão valiosa quanto os próprios ataques.

A compilação consiste nos seguintes componentes principais.

Componente 1: A Fundação (Ludus)

O Ludus funciona como a camada de Infraestrutura como Serviço (IaaS). Construído para funcionar no Proxmox 8/9 ou Debian 12/13, ele usa arquivos de configuração YAML para definir redes virtuais complexas, suportando até 255 VLANs distintas. Nos bastidores, o Ludus utiliza facilmente o Packer e o Ansible para construir, configurar e implantar os modelos de máquinas virtuais a partir desse único arquivo.
Consulte e siga os passos de instalação e os requisitos de hardware no guia de início rápido do Ludus.

Componente 2: Os Alvos (Os Laboratórios)

Este guia combina dois ambientes distintos do Ludus em um único conjunto abrangente para testar um espectro mais amplo de ameaças:

• Jogo do Active Directory (GOAD)Um laboratório de Active Directory construído especificamente para esse fim , projetado por pesquisadores de segurança da Orange Cyberdefense. Ele vem pré-configurado com as configurações incorretas e vulnerabilidades específicas necessárias para simular caminhos de ataque comuns baseados em identidade, como Kerberoasting, NTLM Relay e abuso do Active Directory Certificate Services (ADCS).
• Laboratório de Malware XZbotUm ambiente de malware de alto risco e alta fidelidade. Este laboratório contém a backdoor funcional real CVE-2024-3094. Isso proporciona um caso de teste perfeito e moderno para um ataque sofisticado à cadeia de suprimentos de software.

Aviso importante

Lidar com malware em execução, mesmo para fins de pesquisa, pode violar as Políticas de Uso Aceitável (PUAs) de provedores de serviços de internet ou de nuvem. Certifique-se de que você possui a infraestrutura (o Ludus está instalado localmente) e verifique se seu provedor de internet permite esse tipo de pesquisa ou direcione o tráfego por meio de uma VPN.

Componente 3: A Rede de Sensores (Agente Elástico e Defesa)

Para obter visibilidade, todas as máquinas virtuais do ambiente Ludus, tanto nos laboratórios GOAD quanto nos XZbot, serão equipadas com o Elastic Agent, um agente único e unificado para coleta e proteção de dados (via Elastic Defend).

Essa instrumentação é automatizada por meio da função Ansible badsectorlabs/ludus_elastic_agent . Essa função é o elo fundamental que conecta programaticamente a fase de provisionamento de infraestrutura (Ludus/Ansible) com a fase de instrumentação de segurança (Elastic), possibilitando um verdadeiro fluxo de trabalho de "infraestrutura como código".

Fundamentalmente, a política do Elastic Agent será configurada com a integração do Elastic Defend . Isso eleva o agente de um simples coletor de logs para uma solução completa de Detecção e Resposta de Endpoint (EDR)/Detecção e Resposta Estendida (XDR), fornecendo detecções baseadas no host (incluindo detecção de malware e ransomware orientada por Aprendizado de Máquina (ML)) e a telemetria profunda em nível de kernel essencial para a detecção.

Nota: Para a abordagem da equipe roxa descrita neste blog, defina as políticas para o modo Detectar .

Componente 4: O Cérebro (Elastic Cloud Hosted / Elastic Serverless)

Todas as telemetrias e alertas de segurança dos Elastic Agents no ambiente Ludus são transmitidos para uma implantação centralizada do Elastic Cloud Hosted (ECH) ou do Elastic Serverless . É aqui que o poder analítico da plataforma unificada ganha vida. Utilizar uma plataforma nativa da nuvem não serve apenas para hospedagem; é o que desbloqueia os recursos mais avançados e poderosos da Elastic, incluindo a Descoberta de Ataques e o Assistente de IA. Clique aqui para iniciar um teste gratuito no Elastic Cloud.

O diagrama abaixo fornece uma visão geral da construção, que é baseada no laboratório GOAD.

Fase 1: Construção e Instrumentação do Campo de Testes

Esta seção fornece um guia técnico passo a passo para configurar e implantar o sistema automatizado de alcance. O processo segue um modelo claro de "infraestrutura como código" (IaC), onde a instrumentação de segurança é definida juntamente com a própria infraestrutura, garantindo uma postura de monitoramento consistente e repetível para cada implementação. A instância do Elastic Cloud e suas configurações podem ser gerenciadas com o provedor Terraform do Elastic Cloud e do Elastic Stack para um modelo IaC completo, abrangendo toda a gama de serviços e SIEM.

3.1 Configurando a política do agente elástico (no Kibana)

Antes de executar a implantação do Ludus Range, a política do agente deve ser criada na instância do Elastic Cloud. Essa política é o que possibilita a poderosa telemetria EDR/XDR.

O fluxo operacional é o seguinte:

1. Faça login na instância do Kibana no Elastic Cloud (ECH) ou no Elastic Serverless.
2. Acesse Gerenciamento > Frota.
3. Crie uma nova política de agente (por exemplo, "ludus-range-policy"). A função ludus_elastic_agent irá inscrever os agentes na política que você especificar na personalização em nível de máquina virtual ou na política padrão vinculada à variável global.
4. Adicione a integração do Elastic Defend a esta política.
5. Configure a integração do Elastic Defend para ser executada no modo Detect . Isso ativa o conjunto completo de telemetrias EDR.
6. Salve a política e clique em "Adicionar agente". Isso fornecerá o token de inscrição (para ludus_elastic_enrollment_token) e a URL do servidor Fleet (para ludus_elastic_fleet_server) necessários para o arquivo ludus.yml.
7. (Opcional) Repita os passos 3 a 6 para criar políticas personalizadas que se alinhem com as funções e capacidades do host para personalização de políticas no nível da máquina virtual.

Após a criação dessa política e a inserção do token no arquivo ludus.yml, a execução do comando Ludus range deploy iniciará o fluxo de trabalho completo e automatizado. O Ludus provisiona as VMs e o Ansible instala o Elastic Agent, que então se inscreve no Fleet e baixa automaticamente a política que contém a integração com o Elastic Defend. Isso fornece a telemetria EDR completa – eventos de processo, arquivo, rede e registro em nível de kernel – desde o momento em que o laboratório é criado.

3.2 A configuração Ludus YAML (ludus.yml)

A Ludus fornece aqui os passos para implementar a gama GOAD. A configuração do intervalo está armazenada no arquivo de configuração ludus.yml. Para o intervalo GOAD, ele está localizado em ad/GOAD/providers/ludus/config.yml.
A configuração completa no apêndice é um exemplo baseado em uma configuração de teste que combina um laboratório GOAD completo (na VLAN 10) com o laboratório XZbot (na VLAN 20).

Para implantar uma versão personalizada durante a instalação, atualize o arquivo ad/GOAD/providers/ludus/config.yml antes de executar o script goad.sh na etapa 2.

git clone https://github.com/Orange-Cyberdefense/GOAD.git
cd GOAD
sudo apt install python3.11-venv
export LUDUS_API_KEY='myapikey'  # put your Ludus admin api key here nano ad/GOAD/providers/ludus/config.yml # customize the configuration here
./goad.sh -p ludus
GOAD/ludus/local > check
GOAD/ludus/local > set_lab GOAD # GOAD/GOAD-Light/NHA/SCCM
GOAD/ludus/local > install

Duas opções de configuração principais podem ser usadas para personalizar o intervalo:

1. Variáveis globais: Para simplificar a configuração e evitar repetição, as variáveis do Elastic Agent são definidas uma única vez no nível superior em um bloco global Ansible.vars e são herdadas por todas as VMs.

   O token de inscrição determina a política do Elastic Agent que será utilizada.

# ludus.yml
---
# --- GLOBAL ANSIBLE VARS (Simplification) ---
# Define Elastic agent vars once and apply globally
global_role_vars:
  ludus_elastic_fleet_server: "<your-fleet.example.com:443>" # Use 443 for cloud
  ludus_elastic_enrollment_token: "<your_enrollment_token>"
  ludus_elastic_agent_version: "9.2.1"

2. Variáveis de nível de VM: As variáveis do Elastic Agent podem ser configuradas no nível da VM para personalizar a política aplicada. Essas opções podem ser combinadas com a variável global, por exemplo, onde a versão do agente e o fleet_server são definidos por meio de variáveis globais, e os tokens de inscrição são definidos no nível da VM para aplicar políticas diferentes às VMs.

# --- VM DEFINITIONS ---
vms:
  # --- GOAD LAB (VLAN 10) ---
  - name: "{{ range_id }}-GOAD-DC01"
    hostname: "{{ range_id }}-DC01"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 10
    ram_gb: 4
    cpus: 2
    windows: { sysprep: true }
    ansible:
      roles:
        - badsectorlabs.ludus_elastic_agent
      role_vars:
        ludus_elastic_enrollment_token: "<your_enrollment_token>" # different token for different policies
  # (Definitions for GOAD-DC02, GOAD-DC03, GOAD-SRV02, GOAD-SRV03 
  #  would follow, all inheriting the global ansible vars)

Automatizando a Implantação do Agente Elástico

O trecho de código ludus.yml acima demonstra a automação. Ao adicionar a função badsectorlabs.ludus_elastic_agent à seção ansible.roles de cada definição de VM, o Ludus instalará e configurará automaticamente o agente durante a implantação.

Essa única função do Ansible é compatível com todos os sistemas operacionais em nosso laboratório heterogêneo, incluindo Windows (para GOAD), Kali e Debian (para XZbot).

Conforme mostrado no YAML simplificado, o bloco ansible.vars no nível superior passa os parâmetros críticos para a função:

• ludus_elastic_fleet_server: O URL e a porta do servidor Fleet para sua implantação no Elastic Cloud (por exemplo, your-fleet.example.com:443).
• ludus_elastic_enrollment_token: O token que inscreve o agente.
  O exemplo completo define o ludus_elastic_enrollment_token no nível da máquina virtual para demonstrar a capacidade de usar políticas diferentes.
• ludus_elastic_agent_version: A versão específica do agente a ser instalada (ex.: 9.2.1).

Observação: O host Kali também terá o Elastic Defend implantado para monitorar o comportamento do invasor; isso não será possível em um cenário real.

Segurança em primeiro lugar: isolamento, OPSEC e malware em execução.

Esta seção contém um aviso crítico de segurança e proteção operacional (OPSEC). Essa configuração envolve um risco significativo e não trivial que deve ser gerenciado profissionalmente.

4.1 A Ameaça: Isto Não É uma Simulação

É preciso afirmar categoricamente: o guia de laboratório Ludus XZbot e a função Ansible associada instalam o backdoor funcional CVE-2024-3094. Este não é um código simulado benigno. A própria documentação do laboratório afirma: "Perigo: Esta função contém malware (propositalmente)."

Embora seja descrita como uma "porta dos fundos passiva" (ou seja, requer que um invasor a acione ativamente), qualquer máquina virtual que execute esse código com uma conexão aberta à internet representa um risco catastrófico. Poderia ser escaneado, explorado por agentes desconhecidos ou usado como ponto de partida para atacar outras redes.

4.2 A Contradição: Isolamento vs. Conectividade em Nuvem

Essa arquitetura cria um conflito operacional direto e crítico:

1. Requisito 1 (Segurança): O laboratório de malware deve ser isolado da internet pública para evitar comprometimento ou fuga.
2. Requisito 2 (Função): O Elastic Agent deve ter conectividade de internet de saída para alcançar os endpoints Elastic Cloud Hosted / Elastic Serverless para inscrição e streaming de dados.

Um usuário inexperiente fracassaria aqui, seja expondo seu laboratório infectado ao mundo ou isolando-o tão completamente que nenhuma telemetria de segurança possa ser coletada.

4.3 A Solução: Saída por Orifício Estenopeico via Modo de Teste Ludus

O conflito é resolvido usando o modo "teste" integrado do Ludus, que fornece controle granular sobre a saída de rede. Essa funcionalidade é utilizada para a saída por orifício, que permite o controle do agente, a telemetria e a saída de registros.

# 1. Start the isolated testing session
ludus testing start # Note external DNS resolvers may also need to be added # ludus testing allow -i 1.1.1.1,8.8.8.8

# 2. Allow Elastic Fleet Server (Control Plane)
# Replace <id> with your specific deployment ID # Note the endpoint will differ based on the cloud providers
ludus testing allow -d <your-deployment-id>.fleet.us-central1.gcp.cloud.es.io

# 3. Allow Elasticsearch Ingest (Data Plane) # Note the endpoint will differ based on the cloud providers
ludus testing allow -d <your-deployment-id>.es.us-central1.gcp.cloud.es.io

Esta configuração oferece uma solução de nível especialista: o malware é contido com segurança, enquanto o Elastic Agent recebe apenas a conectividade mínima necessária para fazer atualizações de política (via comunicação com o endpoint fleet ) e para ingerir dados (via comunicação com o endpoint ES ).

4.4 Acessando o alcance no modo de teste (WireGuard)

Quando o Modo de Teste é ativado, o roteamento padrão falha. Você não pode simplesmente acessar sua máquina virtual Kali via SSH a partir da sua rede local (LAN) porque o roteador bloqueia o tráfego. O Ludus fornece um canal de gerenciamento fora de banda usando o WireGuard.

O Ludus configura uma interface WireGuard (wg0) na VM do roteador (198.51.100.1) e atribui a você um IP de cliente estático (por exemplo, 198.51.100.2).

• Regras de permissão persistentes: A configuração do firewall do roteador inclui regras específicas na cadeia LUDUS_DEFAULTS. Essas regras ACEITAM explicitamente o tráfego originado ou destinado à sub-rede WireGuard (198.51.100.0/24).
• Prioridade: Como essas regras existem na cadeia LUDUS_DEFAULTS, elas substituem as regras DROP aplicadas pelo Modo de Teste.

Como conectar:

1. Gere sua configuração: usuário ludus wireguard > ludus.conf
2. Importe este arquivo para o seu cliente WireGuard local e ative o túnel.
3. Conecte-se diretamente aos IPs privados de suas VMs (por exemplo, 10.10.10.11) através do túnel.

Fase 2: Executando os ataques

Com o campo de testes de alta fidelidade e totalmente instrumentado já implantado, a fase da "Equipe Vermelha" pode começar. Isso envolve fazer login em uma máquina virtual dedicada ao atacante (como a máquina virtual Kali incluída ou uma máquina virtual remnux-analyzer) e executar os ataques. Essa atividade gera a telemetria rica e maliciosa que o Elastic Defend irá capturar.

Essa gama combinada permite testar as defesas contra os dois vetores de ameaça dominantes em nível macro: ataques de "sobrevivência à terra" (LotL, na sigla em inglês) baseados em identidade e intrusões na cadeia de suprimentos baseadas em vulnerabilidades.

5.1 Simulação do Active Directory (GOAD)

• Acesso inicial (preenchimento de credenciais)
  1. O atacante tem como alvo o perímetro externo. Utilizando uma lista de credenciais comprometidas, você executa um ataque de preenchimento de senhas contra o domínio Essos.local. Você validou com sucesso as credenciais do usuário khal.drogo.
  2. Ferramenta de exemplo: kerbrute ou smartbrute
  3. Resultado: Credenciais válidas para um usuário de domínio com privilégios limitados.
• Escalada de privilégios (PrintNightmare)
  1. khal.drogo tem direitos limitados. Para obter acesso ao servidor CastelBlack, você explora a vulnerabilidade PrintNightmare (CVE-2021-34527). Essa vulnerabilidade no serviço Spooler de Impressão do Windows permite que qualquer usuário autenticado instale um driver de impressão malicioso. Você carrega um driver que adiciona um novo usuário administrador local ao servidor.
  2. Ferramenta de exemplo: script de exploração CVE-2021-34527.py
  3. Resultado: Acesso ao SISTEMA local em CastelBlack.
• Despejo de credenciais (preparação do DCSync)
  1. Agora, executando como SYSTEM/Admin no CastelBlack, você inspeciona a máquina em busca de credenciais em cache. Você executa o secretsdump do Impacket para extrair hashes do banco de dados SAM e da memória LSASS. Você descobre o hash NTLM da conta de Administrador integrada, que foi deixado na memória de uma sessão de suporte anterior.
  2. Ferramenta de exemplo: impacket-secretsdump
  3. Resultado: Hash NTLM de uma conta de administrador de domínio ou de uma conta com altos privilégios.
• Kerberoasting
  1. Com credenciais de domínio válidas, você pode acessar a rede interna. Você solicita Tickets de Serviço Kerberos (TGS) para Nomes Principais de Serviço (SPNs) no ambiente. Você está direcionando a conta MSSQLSvc. Você pega o ticket criptografado e o decifra para revelar a senha em texto simples da conta de serviço do SQL Server.
  2. Ferramenta de exemplo: Rubeus ou GetUserSPNs.py
  3. Resultado: Senha em texto simples para a conta de serviço do MSSQL.
• Ataques ao MSSQL
  1. Você usa as credenciais SQL quebradas para autenticar diretamente no servidor SQL Braavos. Como a conta de serviço possui direitos de administrador do sistema, você está abusando do procedimento armazenado xp_cmdshell. Este recurso permite que você abra um shell de comando do Windows diretamente a partir de uma consulta SQL, efetivamente fornecendo Execução Remota de Código (RCE) no servidor de banco de dados.
  2. Ferramenta de exemplo: mssqlclient.py
  3. Resultado: Execução remota de código (RCE) no servidor de banco de dados.
• Persistência (Tarefa Agendada)
  1. Para garantir que você não perca o acesso caso a senha do SQL seja alterada, você configura a persistência. Você cria uma Tarefa Agendada do Windows no servidor SQL comprometido. Esta tarefa está configurada para executar um binário de sinalização diariamente, com privilégios de SYSTEM.
  2. Ferramenta de exemplo: schtasks.exe ou PowerShell
  3. Resultado: Persistência a longo prazo.

5.2 Simulação de Laboratório de Malware (XZbot)

• Etapa 7: Mudança de rumo na cadeia de suprimentos (Porta dos fundos XZ)
• Simultaneamente, você tem como alvo a infraestrutura Linux na DMZ. Você aciona o backdoor XZ pré-implantado (CVE-2024-3094) na VM xz-backdoor-dect. Ao manipular o handshake SSH com uma chave criptográfica específica, você ignora completamente a autenticação e executa comandos como root sem deixar registros SSH padrão.
• Ferramenta: xzbot
• Resultado: Acesso root na infraestrutura Linux por meio de comprometimento da cadeia de suprimentos.
• O atacante utiliza o cliente xzbot fornecido no laboratório Ludus.
• A partir da máquina virtual do atacante, o seguinte comando é executado para ativar a porta dos fundos no host Debian vulnerável:
  xzbot --ssh-addr '10.XXX:22' -cmd 'setsid sh -c "echo test"' 2>&1
• Essa ação faz com que o processo sshd no alvo inicie um shell de forma anômala e execute o comando como root, criando uma prova definitiva de execução.

Fase 3: Detecção e Investigação Unificadas com Segurança Elástica

Esta é a recompensa da "Equipe Azul". A telemetria e os alertas gerados na Fase 2 estão agora disponíveis para análise na plataforma unificada Elastic Security.

6.1 O "SIEM Poderoso": Visibilidade Centralizada e Detecções Pré-configuradas

O poder do Elastic SIEM não reside apenas na sua capacidade de coletar logs passivamente. Seu poder reside na análise ativa que realiza sobre os dados contextuais e detalhados fornecidos pelo Elastic Defend. O recurso "Visibilidade Completa do Endpoint" da Defend fornece não apenas logs básicos, mas também telemetria em nível de kernel — criação de processos, modificações de arquivos, conexões de rede e alterações no registro.

Esses dados abrangentes, todos normalizados para o Elastic Common Schema (ECS), alimentam a extensa biblioteca da Elastic, que contém mais de 1500 regras de detecção pré-construídas e mapeadas pelo MITRE. Essas regras são pesquisadas, desenvolvidas e mantidas pela equipe do Elastic Security Labs, proporcionando valor de detecção imediato.

A gama Ludus serve como a plataforma de validação perfeita para esse valor. Os ataques executados na Fase 2 não são teóricos; eles são mapeados diretamente para artefatos específicos esperados ("prova irrefutável"). Neste exemplo, uma combinação de regras predefinidas e regras personalizadas é usada intencionalmente em conjunto para gerar alertas sobre comportamentos específicos.

Nota: As regras de detecção elástica são abertas e transparentes. Você pode visualizar a lógica, contribuir ou relatar problemas diretamente em (https://github.com/elastic/detection-rules).

6.2 Análise Detalhada: Rastreando Cadeias de Processos com o Analisador de Eventos

Os dois laboratórios (GOAD e XZbot) oferecem uma oportunidade perfeita para usar as ferramentas de investigação especializadas da Elastic. A interface do usuário do Analisador de Eventos foi projetada para abstrair a complexidade dos logs JSON em um modelo cognitivo que se alinha à forma como os analistas de segurança pensam: Cadeias de Processos. A interface é composta por três zonas de interação principais: a Tela Gráfica, o Painel de Detalhes e a integração da Linha do Tempo.

O que estamos vendo?

A Tela Gráfica (A Árvore de Processos)

A visão central é um grafo acíclico direcionado onde:

• Nós (Cubos): Cada cubo representa uma execução de processo distinta. A visualização distingue entre o evento "Âncora" (destacado com um halo azul) e o contexto circundante.
• Arestas (Linhas): As linhas representam a relação entre pais e filhos. A direcionalidade é implícita (de cima para baixo ou da esquerda para a direita), mostrando o fluxo de execução.
• Identificação visual: os nós não são ícones estáticos; são indicadores dinâmicos.
  • Indicadores de alerta: Se um processo específico acionar uma regra de detecção (por exemplo, "Malware detectado"), um indicador colorido aparecerá no cubo. Isso permite que um analista identifique instantaneamente qual etapa da cadeia foi sinalizada pelo mecanismo de detecção.
  • Contexto do usuário: Indícios visuais podem apontar se um processo alterou o contexto do usuário (por exemplo, de um usuário local para o SISTEMA), sinalizando uma escalada de privilégios.

Painel de Detalhes (Metadados Forenses)

Clicar em qualquer nó aciona o Painel de Detalhes, geralmente deslizando da direita para a esquerda. Este painel é a principal fonte de "O que você pode ver" em um nível granular. Ele expõe campos essenciais para a verificação:

• Argumentos da linha de comando: Este é, sem dúvida, o artefato forense mais valioso. O analisador exibe a string completa, expondo flags, scripts e payloads codificados (por exemplo, powershell.exe -w hidden -enc Base64).
• Caminho e hash do processo: O caminho completo do arquivo ajuda a identificar falsificações (por exemplo, svchost.exe sendo executado a partir de C:\Temp em vez de C:\Windows\System32). Os hashes dos arquivos (MD5, SHA-1, SHA-256) são apresentados para comparação com informações de inteligência contra ameaças.
• Informações sobre a assinatura: As informações sobre a assinatura digital do binário ajudam a distinguir entre binários confiáveis da Microsoft e malware não assinado.
• Contagem de eventos relacionados: em vez de sobrecarregar o gráfico com milhares de modificações de arquivos, o nó exibe estatísticas resumidas (por exemplo, "15 eventos de arquivo", "3 conexões de rede"). Clicar nessas estatísticas geralmente leva a uma visualização em lista ou linha do tempo dessas ações específicas.

A Dimensão Temporal (Filtro Temporal)

Um aspecto crucial, e muitas vezes negligenciado, do Analisador é a sua gestão do tempo. Os ataques podem ter longos "tempos de permanência". Um processo principal pode ter sido iniciado há semanas (por exemplo, um serviço legítimo), enquanto o processo filho malicioso foi gerado hoje. O analisador inclui um controle deslizante de tempo que permite ao analista expandir a janela de consulta. Por padrão, ele pode analisar uma janela estreita em torno do alerta, mas expandir isso permite que o gráfico "alcance" os níveis de dados Quente ou Frio para encontrar o processo pai de longa duração.

Como funciona?

A capacidade operacional do Analisador de Eventos aproveita o Elastic Common Schema (ECS). Em um ambiente de segurança heterogêneo, os registros se originam de diversas fontes — endpoints Windows, servidores Linux, firewalls de rede e provedores de serviços em nuvem — cada um com uma taxonomia única. Um agente da CrowdStrike pode rotular um ID de processo como TargetProcessId, enquanto um evento do Sysmon usa ProcessId. Sem normalização, correlacionar esses eventos em uma única cadeia é algoritmicamente impossível.
O ECS resolve isso impondo uma hierarquia de campos rígida. O Analisador de Eventos utiliza campos ECS específicos e de alta fidelidade para construir o gráfico visual:

• process.entity_id: Este é o princípio fundamental da lógica do Analisador. Os sistemas operacionais reciclam os IDs de processo (PIDs). Um PID de 1234 pode pertencer a svchost.exe em 09:00 e malware.exe em 14:00. A utilização do PID para análises históricas de longo prazo introduz colisões que corromperiam o gráfico visual, ligando eventos não relacionados. O process.entity_id é uma string única gerada pelo Elastic Agent (ou beats compatíveis com ECS) que persiste exclusivamente no índice, garantindo que o grafo represente uma instância de execução distinta, independentemente da reutilização do PID.
• process.parent.entity_id: Este campo estabelece a aresta direcionada entre os nós. Ao consultar recursivamente os eventos em que o process.entity_id de um evento corresponde ao process.parent.entity_id de outro, o Analyzer reconstrói a linhagem.

sequência de eventos: Em ambientes de alta velocidade, a ordem dos eventos (por exemplo, a modificação do arquivo ocorreu antes ou depois da conexão de rede?) é crucial. Os registros de data e hora e os números de sequência do ECS permitem que o analisador ordene os eventos cronologicamente nos detalhes visuais do nó.

6.3 Análise Detalhada: Reconstruindo a Atividade do Usuário com o Visualizador de Sessões

Para o ataque XZbot (Linux), o Session Viewer é a ferramenta mais adequada. Ele foi projetado especificamente para "monitorar e investigar a atividade da sessão na infraestrutura Linux".

Quando o alerta de Potencial Execução via XZBackdoor é acionado, o analista investiga o processo sshd associado. O visualizador de sessão apresenta um "formato altamente legível inspirado no terminal". Ele reconstrói a sessão do atacante, mostrando o processo sshd e seu processo filho anômalo (sh).

Além disso, mostrará o comando exato que foi executado (sh -c setsid sh -c "usermod -aG sudo sysadmin_backup") e pode até exibir a saída desse comando. Esta é a prova definitiva, a "prova cabal", apresentada ao analista em texto simples e legível, permitindo-lhe efetivamente assistir à sessão TTY do atacante posteriormente.

O que estamos vendo?

A interface do usuário do Session Viewer foi explicitamente projetada para preencher a lacuna entre a análise abstrata de logs e a experiência nativa de terminal de um administrador Linux. Ao contrário do Analisador de Eventos, que se concentra em cadeias de processos de malware, o Visualizador de Sessões apresenta uma visualização em árvore, ordenada cronologicamente, que reconstrói a narrativa linear de uma sessão de shell.

Árvore de Processos e Cronograma

O componente central da visualização é um Grafo Acíclico Direcionado (DAG) exibido como uma lista hierárquica.

• Fluxo Vertical: O Visualizador de Sessões organiza os processos verticalmente, imitando o fluxo de um arquivo de histórico de terminal, mas preservando a hierarquia. Os processos filhos são recuados em relação aos seus pais. Isso permite que um analista distinga imediatamente entre um comando executado diretamente pelo usuário (por exemplo, curl) e um processo gerado pela execução de um script (por exemplo, curl sendo executado dentro de um script setup.sh).
• Modo Detalhado: Uma opção permite que os analistas alternem entre uma visualização filtrada (mostrando a atividade significativa do usuário) e o "Modo Detalhado". Quando ativado, este modo revela eventos normalmente ruidosos, como scripts de inicialização do shell (execução do .bashrc), funções auxiliares de autocompletar do shell e processos bifurcados (forks) causados por comandos internos. Isso é crucial para detectar mecanismos de persistência ocultos em scripts de perfil.

Identificação e indicadores visuais

A interface do usuário emprega um sistema sofisticado de emblemas e ícones para fornecer contexto imediato sem exigir que o analista explore cada nó em detalhes. Esses sinais visuais são essenciais para uma triagem rápida.

Indicadores visuais no Elastic Session Viewer

Visualização da saída do terminal

Ao posicionar o cursor sobre o botão Saída do Terminal em um nó de processo, um indicador mostra o tamanho da saída capturada. Clicar neste botão abre a visualização de Saída do Terminal, que exibe os dados do arquivo process.io.text. Essa é a "prova irrefutável" para investigações em Linux.

• Capacidade de reprodução: Permite ao analista ver exatamente o que o usuário viu. Se um atacante executar o comando `cat /etc/passwd`, a árvore de processos mostrará a execução; a visualização de Saída do Terminal mostrará o conteúdo do arquivo passwd conforme foi exibido para o atacante.
• Reconstrução de entrada: Como o visualizador captura a entrada/saída do TTY, ele captura não apenas a execução do comando, mas também a digitação. Isso pode revelar apagamentos, erros de digitação e correções (por exemplo, digitar sdo [backspace] sudo), que são fortes indicadores comportamentais de um adversário humano em vez de um script automatizado.

A Vantagem Elástica: Caça Automatizada com Inteligência Artificial

O processo descrito na Fase 3 demonstra uma investigação poderosa, conduzida pelo analista. No entanto, a principal vantagem de usar o Elastic Cloud Hosted (ECH) ou o Elastic Serverless é o acesso programático a uma pilha integrada de IA generativa. Essa estrutura eleva o processo da correlação manual à busca automatizada orientada por IA.

Observação: os recursos de IA da Elastic funcionam com os LLMs gerenciados padrão da Elastic ou com LLMs de terceiros configurados usando um dos conectores disponíveis.

7.1 De alertas a ataques: Correlação automatizada com a descoberta de ataques

Os laboratórios GOAD + XZbot gerarão vários alertas distintos, conforme mostrado na tabela acima. Um analista júnior se depararia com uma fila de alertas: Potencial Kerberoasting, Solicitação de Certificado Suspeita e Potencial XZBackdoor, e teria que "juntar" manualmente esse ataque complexo entre domínios.

Este é o problema resolvido pela Descoberta de Ataques. Este recurso do GenAI, disponível nos planos Enterprise e Serverless, "oferece busca de ameaças totalmente automatizada em escala". A inteligência artificial analisa cada alerta para descobrir ameaças ocultas, correlacionando automaticamente os sinais díspares do laboratório Ludus em uma única investigação de "ataque" de alta fidelidade.

A principal vantagem da Descoberta de Ataques para um analista forense é a compressão do tempo. Automatiza a "costura mental" que define a análise de primeiro e segundo nível.

Desconstruindo a "Costura Mental"

Considere uma investigação de exemplo sem a descoberta de ataques.

1. Gatilho: Você vê um alerta: "Execução suspeita do PowerShell".
2. Consulta: Você pivota para a linha do tempo do host.
3. Escanear: Você rola para trás 15 minutos. Você vê um evento de "Download de Arquivo".
4. Hipótese: "Talvez o usuário tenha baixado um arquivo corrompido, que iniciou o PowerShell."
5. Verificação: Você verifica o nome do arquivo. É o invoice.js.
6. Conclusão: "Download de malware confirmado."

Este processo demora entre 10 e 30 minutos, dependendo da habilidade do analista e da sua familiaridade com o ambiente. O Attack Discovery executa toda essa sequência em segundos. O sistema analisa o alerta do PowerShell, observa o evento de download do arquivo no contexto relacionado e apresenta uma descoberta informando: "O usuário executou um script suspeito do PowerShell, provavelmente originado do arquivo baixado 'invoice.js'."

Essa funcionalidade inclui Persistência de Dados (os resultados são salvos para rastreamento histórico) e Agendamento e Ações (ela é executada automaticamente e pode acionar respostas ou Fluxos de Trabalho Elásticos subsequentes), transformando o SOC de uma postura reativa para uma proativa.

Exemplo

Em nosso exemplo, à medida que o ataque ocorre, começamos a ver alertas. Em vez de analisar os alertas individualmente, utilizamos a Descoberta de Ataques para essa triagem.
Comprimir o tempo médio de triagem para segundos e identificar rapidamente os ataques 2 .

7.2 Acelerando a triagem com o assistente de IA

O Elastic Security Assistant usa IA generativa para ajudar você a encontrar, corrigir e entender ameaças à segurança. Ele funciona diretamente dentro do Elastic Security. Você interage com ele por meio de uma interface de bate-papo para investigar alertas e escrever código.

Em nosso exemplo, assim que a Descoberta de Ataques identifica um ataque correlacionado, usamos o Assistente de IA para investigar. O assistente oferece duas funcionalidades principais:

1. Investigações em linguagem natural: O analista pode fazer perguntas em linguagem natural, como "Resuma este ataque" ou "Qual é a tática MITRE para este processo?". "O que é um spooler de impressão?" ou "Forneça algumas sugestões de correção."

2. Fluxo de trabalho de Validação de Consultas Agéticas: Este recurso avançado permite que a IA "gere consultas ES|QL personalizadas e validadas". Um analista pode perguntar: "Encontre todas as conexões de rede do host envolvido no alerta do XZbot", e o assistente irá escrever, validar e corrigir automaticamente a consulta antes de apresentá-la, reduzindo drasticamente a barreira de conhecimento para a busca de ameaças
   alto nível.

Como funciona

O Assistente conecta seu Elastic Stack a um LLM de sua escolha (por exemplo, GPT-5, Claude, Gemini). Ele utiliza a Geração Aumentada de Recuperação (RAG, na sigla em inglês) para buscar dados relevantes — logs, alertas e documentação interna — do seu ambiente. Você pode configurá-lo para anonimizar campos sensíveis (informações pessoais identificáveis ou metadados de host/IP) antes de enviar a solicitação ao modelo, garantindo que seus dados permaneçam privados enquanto o modelo analisa os padrões de comportamento.

7.3 Automação Inteligente com Fluxos de Trabalho Elásticos

Os ataques descritos acima geram alertas complexos e de múltiplas etapas. Lidar com isso manualmente é lento. A Elastic resolveu isso adquirindo a Keep, uma plataforma de código aberto de AIOps e gerenciamento de alertas. No Elastic 9.3, essa tecnologia está integrada diretamente ao Kibana em versão de pré-visualização técnica como Elastic Workflows.

O que são fluxos de trabalho?

O Elastic Workflows é um mecanismo de automação integrado à plataforma Elasticsearch. Você define os fluxos de trabalho em YAML — o que os aciona, quais etapas eles executam, quais ações eles realizam — e a plataforma cuida da execução. Um fluxo de trabalho pode consultar seu ambiente, transformar e enriquecer dados de segurança, ramificar com base em condições, chamar APIs externas e integrar-se a serviços como Slack, Jira, PagerDuty e outros por meio de conectores que você já configurou. Os fluxos de trabalho também podem acionar agentes de IA para analisar investigações complexas e, em seguida, prosseguir com ações de resposta com base no que o agente descobrir. O Elastic Workflows combina automação por script com raciocínio de IA nativamente em seu SIEM, onde seus dados de segurança já residem.

Como funciona: O "Agregador de Alertas e Motor de Fluxo de Trabalho"

Os fluxos de trabalho tornam-se a camada intermediária entre a detecção e a remediação, funcionando por meio de três mecanismos principais:

• Ingestão de múltiplas fontes: os fluxos de trabalho vão além do Elasticsearch. Coletar dados adicionais para enriquecimento, análise ou triagem inicial.
• Fluxo de trabalho como código (YAML): Os fluxos de trabalho são definidos em arquivos YAML. Isso permite que as equipes controlem as versões de seus procedimentos de resposta a incidentes como código.
• O mecanismo de fluxo de trabalho: quando um alerta é acionado no Elastic (ou em uma ferramenta externa), o mecanismo de fluxo de trabalho executa uma série de etapas:
  1. Enriquecimento: Consultar uma API (como o VirusTotal ou o Active Directory) para adicionar contexto.
  2. Lógica: Utilizando instruções if/else para determinar a gravidade.
  3. Ação: Enviar uma mensagem no Slack, criar um ticket no Jira ou acionar uma ação de resposta do Elastic Defend.

Considere um exemplo de fluxo de Alerta e Ação.

• Gatilho: Você conecta o fluxo de trabalho a uma regra específica, como "Alerta de Detecção Maliciosa".
• Etapas: Você define uma sequência de ações.
  1. Triagem (Agente): Passe o alerta para o Assistente de IA. Faça as seguintes perguntas: "Como podemos remediar e responder ao alerta abaixo?"
  2. Enriquecer: Anexe a resposta do Assistente de IA como uma nota ao alerta.
  3. Resposta: Crie um caso com um link para a nota de alerta.

Exemplo

Em nosso exemplo, temos alertas que acionam nosso fluxo de trabalho - Enriquecimento de Alertas e Criação de Casos.
Também iremos acioná-lo diretamente da interface do usuário de Fluxos de Trabalho para demonstrar as várias etapas.

• O contexto do alerta é fornecido como entrada para o Assistente de IA de Segurança.
• A resposta é adicionada como uma nota aos alertas de segurança.
• Um caso é criado com metadados do Alerta (data e hora, gravidade, nome da regra e motivo do alerta).
• Um link para o caso é adicionado ao caso como um comentário. Nota: isto não é mostrado no GIF.

Conclusão: Da configuração manual à emulação contínua

Este blog forneceu um projeto completo para uma gama de simulação avançada, escalável e, mais importante, segura.

1. Construímos: Uma complexa gama de laboratórios (GOAD + XZbot) foi implantada com um único comando usando o Ludus.
2. Nós realizamos a instrumentação: Toda a gama de produtos foi instrumentada de forma integrada com o Elastic Agent e o Defend como parte da implantação automatizada, utilizando a função Ansible ludus_elastic_agent.
3. Garantimos a segurança do conflito crítico entre o isolamento de malware e a conectividade do agente na nuvem, resolvido com os controles granulares de "OPSEC" da Ludus.
4. Validamos: Os poderosos recursos de SIEM da plataforma foram comprovados pela validação das regras de detecção pré-configuradas e prontas para uso da Elastic contra ataques maliciosos conhecidos em ambiente real.
5. Investigamos o seguinte: As ferramentas de investigação especializadas, Event Analyzer e Session Viewer, foram utilizadas para rastrear os caminhos exatos do ataque em hosts Windows e Linux.
6. Automatizamos: Demonstramos o "multiplicador de força" da plataforma GenAI da Elastic, com o Attack Discovery correlacionando automaticamente alertas distintos em um único ataque e o Assistente de IA acelerando a investigação final.
7. Nossa resposta: O poder dos Fluxos de Trabalho Elásticos fornece a inteligência e a automação necessárias para ações de resposta complexas e fluxos de remediação.

Essa arquitetura não é um projeto isolado. Trata-se de um modelo para um fluxo de trabalho de engenharia de detecção contínua. Ela "moderniza as operações de segurança" ao capacitar as equipes roxas a desmontar, reconstruir e testar novamente suas defesas sob demanda, garantindo que sua postura de detecção evolua tão rapidamente quanto as ameaças.

Dê o próximo passo: Capacite sua equipe de segurança.

A arquitetura apresentada neste blog é mais do que um exercício técnico; é um projeto para validação contínua de segurança. Ao combinar esse intervalo automatizado com a plataforma unificada SIEM e XDR da Elastic, você pode passar de testes periódicos para um estado de prontidão constante.

Convidamos você a iniciar seu próprio teste, aproveitar este guia para testar e avaliar a plataforma contra ameaças reais e capacitar sua equipe de segurança com as ferramentas necessárias para se manter um passo à frente do adversário.

Está usando outro SIEM?

Sem problemas. Você pode aproveitar o Elastic Serverless e ampliar seu SIEM existente, obtendo assim todos os insights acima enquanto utiliza os dados subjacentes do seu SIEM nativo. Comece hoje mesmo a implementar o Elastic Serverless. O pacoteElastic AI SOC Engine (EASE) oferece esses recursos orientados por IA, permitindo que as organizações adicionem rapidamente análises poderosas e uma camada de IA às suas ferramentas existentes antes da migração completa.

Apêndice

Exemplo de gama completa

Nota: A VLAN da máquina virtual Kali está fora dos hosts backdoor GOAD e XZ para simular uma rede segmentada ou um atacante remoto. A VLAN da máquina virtual Kali pode ser alterada para 10/20 para simular cenários de "suposta violação" ou ataques internos.

global_role_vars:
  ludus_elastic_fleet_server: "https://<fleet_domain>:<fleet_port>" #443 by default for cloud   ## Note on prem fleet server defaults to 8220
  ludus_elastic_agent_version: "9.2.1"
ludus:
  - vm_name: "{{ range_id }}-GOAD-DC01"
    hostname: "{{ range_id }}-DC01"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 10
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:           # Any values in this array will be added to DNS for the range and return an A record for this VM's IP
      - sevenkingdoms.local
      - kingslanding.sevenkingdoms.local
      - kingslanding
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-DC02"
    hostname: "{{ range_id }}-DC02"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 11
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - winterfell.north.sevenkingdoms.local
      - north.sevenkingdoms.local
      - winterfell
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-DC03"
    hostname: "{{ range_id }}-DC03"
    template: win2016-server-x64-template
    vlan: 10
    ip_last_octet: 12
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - essos.local
      - meereen.essos.local
      - meereen
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-SRV02"
    hostname: "{{ range_id }}-SRV02"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 22
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - castelblack.north.sevenkingdoms.local
      - castelblack
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-SRV03"
    hostname: "{{ range_id }}-SRV03"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 23
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - braavos.essos.local
      - braavos
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<your_enrollment>"
  - vm_name: "{{ range_id }}-xz-backdoor-dect"
    hostname: "{{ range_id }}-xz-backdoor-dect"
    template: debian-12-x64-server-template
    vlan: 20
    ip_last_octet: 1
    ram_gb: 2
    cpus: 2
    linux:
      packages: # You can define packages to install on Linux hosts
        - ca-certificates
        - netcat-openbsd
        - net-tools
    roles:
      - badsectorlabs.ludus_xz_backdoor
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_xz_backdoor_install_xzbot: true
      ludus_xz_backdoor_install_backdoor: true
      ludus_elastic_enrollment_token: "<linux_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-kali"
    hostname: "{{ range_id }}-kali"
    template: kali-x64-desktop-template
    vlan: 50
    ip_last_octet: 99
    ram_gb: 8
    cpus: 4
    linux: true
    testing:
      snapshot: false # Snapshot this VM going into testing, and revert it coming out of testing. Default: true
      block_internet: false # Allow internet access for Kali, default is true
    roles:
      - badsectorlabs.ludus_xz_backdoor
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_xz_backdoor_install_xzbot: true
      ludus_elastic_enrollment_token: "<linux_policy_enrollment_token>"

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.