Acelerando a confirmação de ataques APT com descoberta de ataques, fluxos de trabalho e construtor de agentes.

9:15 AM: O Não-Evento - Uma manchete surge: "Chrysalis Backdoor: Uma Análise Detalhada da Flor de Lótus ". Seu CISO envia uma mensagem no Slack: "Somos afetados?"

Em um SOC tradicional, você está prestes a perder toda a sua manhã em uma correria manual — analisando dezenas de alertas, escrevendo consultas, verificando manualmente o VirusTotal e comparando padrões de índice para construir uma linha do tempo, na esperança de não perder nada.

Mas em um SOC Agentic, o trabalho já está feito. O Attack Discovery, executado em sua programação horária, já havia correlacionado 5 alertas críticos de mais de 30 em uma única narrativa de ataque: "Malware com persistência de carregamento lateral de DLL". Essa descoberta acionou automaticamente um fluxo de trabalho, que encaminhou os resultados a um agente. O agente usou suas ferramentas e verificou o hash do malware no VirusTotal, pesquisou seus logs com o ES|QL, verificou a escala de plantão, criou um chamado e abriu um canal de incidente no Slack com o analista de plantão já adicionado, além de gerar um resumo pronto para o CISO — tudo isso antes mesmo de você se sentar para tomar um café.

Você responde ao seu CISO: "Já confirmado e triado." O caso está em aberto. Aqui está o link."

Esta publicação explica como construímos esse pipeline: a integração do Attack Discovery, Workflows e Agent Builder.

A ameaça: a brecha Chrysalis criada pela Lotus Blossom

Perfil do agente de ameaça

Visão geral da campanha

A Lotus Blossom executou uma violação da cadeia de suprimentos da infraestrutura de atualização do Notepad++:

• Janela de ataque: junho 2025 – dezembro 2025 (aproximadamente 6 meses)
• Vector: Mecanismo de atualização do Notepad++ sequestrado (WinGUp)
• Método: Redirecionamento seletivo de usuários-alvo para servidores de atualização maliciosos.
• Carga útil: Backdoor "Chrysalis" não documentado anteriormente
• Descoberta: Equipe Rapid7 MDR, publicada em 02/02/2026

Capacidades de backdoor da Chrysalis

O sistema de segurança Chrysalis é um implante sofisticado e repleto de recursos:

• Criptografia personalizada (LCG, hash FNV-1a, MurmurHash)
• Carregamento reflexivo de DLL
• Hashing de API para evasão
• Carregamento lateral de DLL via binário legítimo do Bitdefender (BluetoothService.exe)
• Capacidades completas de acesso remoto
• Instalação persistente do serviço do Windows

Cadeia de ataque

[1] INITIAL ACCESS
    └── User executes malicious NSIS installer from Desktop
              ↓
[2] EXECUTION
    └── Installer drops files to hidden AppData folder
        ├── BluetoothService.exe (legitimate binary)
        └── log.dll (malicious Chrysalis loader)
              ↓
[3] PERSISTENCE
    └── BluetoothService.exe registered as Windows service
        └── Runs under SYSTEM context
              ↓
[4] DEFENSE EVASION
    └── DLL sideloading via legitimate signed binary
              ↓
[5] COMMAND & CONTROL
    └── DNS beacon to api[.]skycloudcenter[.]com ✅ CONFIRMED

Mapeamento MITRE ATT&CK

O Desafio: Velocidade vs. Precisão

Quando informações de inteligência sobre ameaças revelam uma campanha APT (Ameaça Persistente Avançada) patrocinada por um Estado-nação, as equipes de SOC (Centro de Operações de Segurança) enfrentam uma escolha difícil:

Rapidez: Executivos querem respostas agora. "Estamos comprometidos?"

Precisão: Os analistas precisam de tempo para pesquisar, correlacionar e confirmar informações antes de tomar uma decisão.

Os fluxos de trabalho tradicionais exigem que os analistas:

1. Determine o escopo da análise e os critérios de pesquisa relevantes.
2. Realizar busca manual por indicadores de comprometimento (IOCs) em diversas fontes de dados.
3. Correlacione alertas que podem abranger dias ou semanas.
4. Validar as descobertas em relação à inteligência de ameaças.
5. Construa o cronograma do ataque
6. Aumente sua confiança

Esse processo leva de horas a dias, período durante o qual um atacante ativo pode exfiltrar dados ou se movimentar lateralmente.

A solução: Descoberta de ataques + Fluxos de trabalho + Construtor de agentes

A plataforma de automação com inteligência artificial da Elastic Security transforma esse fluxo de trabalho de busca manual para confirmação automatizada. Mas antes de nos aprofundarmos na configuração específica, vale a pena entender como os componentes se encaixam.

Agentes e fluxos de trabalho: dois pontos de entrada, uma arquitetura componível.

O Agent Builder oferece duas funcionalidades básicas que trabalham em conjunto:

• Os agentes constituem a camada de inteligência. Eles raciocinam sobre uma tarefa, decidem quais ferramentas utilizar e se adaptam com base no que descobrem. Um agente pode utilizar ferramentas de busca, ferramentas MCP e, crucialmente, fluxos de trabalho como ferramentas.
• Os fluxos de trabalho constituem a camada estrutural. São fluxos de trabalho determinísticos: as etapas são executadas em ordem, de forma confiável e repetível. Qualquer etapa em um fluxo de trabalho pode, opcionalmente, ser uma etapa de agente, dando-lhe a capacidade de raciocinar no meio do processo.

Os dois são totalmente combináveis. Um fluxo de trabalho pode invocar um agente. Um agente pode chamar um fluxo de trabalho. Uma etapa de agente dentro de um fluxo de trabalho pode chamar outro fluxo de trabalho. Cada conexão é opcional, permitindo que você combine as opções de acordo com as necessidades do problema.

É isso que torna a arquitetura poderosa: os agentes raciocinam e decidem; os fluxos de trabalho executam e coordenam. Para o nosso cenário de ataque Chrysalis, usamos ambos.

Nosso fluxo

O Fluxo:

1. A funcionalidade "Vários Alertas → Descoberta de Ataques" correlaciona alertas distintos em uma narrativa de ataque única.
2. Descoberta de ataques → Gera um alerta que aciona o fluxo de trabalho
3. Fluxo de trabalho → Invoca o Agent Builder para analisar os resultados da descoberta de ataques.
4. Construtor de Agentes → Fluxos de trabalho de enriquecimento de chamadas (VirusTotal, Inteligência de Ameaças, consultas ES|QL)
5. O Construtor de Agentes chama um fluxo de trabalho → O Construtor de Agentes continua com as ações de resposta a incidentes, utilizando o fluxo de trabalho como ferramenta (ações de caso, isolar o host, notificar a equipe).

Etapa 1: A Descoberta de Ataques revela a ameaça.

A ferramenta de Descoberta de Ataques utiliza Modelos de Aprendizagem Baseados em Nível (LLMs) para analisar alertas de segurança e identificar padrões de ataque. Diferentemente do agrupamento de alertas tradicional, ele compreende as relações semânticas entre os alertas.

A fila de alertas: uma agulha num palheiro.

Eis a realidade para um analista de SOC. Você abre a página de alertas e vê dezenas de alertas em vários hosts, usuários e regras, uma combinação de gravidades e tipos variados, muitos deles ruído.

Dezenas de alertas. Várias regras sendo executadas. Níveis de gravidade que variam de baixo a crítico. Alguns são o ataque da Crisálida. Alguns são eventos não relacionados do Windows Defender. Algumas são detecções de alterações SIEM provenientes de um fluxo de trabalho completamente diferente. É difícil encontrar um ataque coordenado nessa parede de ruído.

O que o Attack Discovery descobriu

A ferramenta de Descoberta de Ataques analisou todos esses alertas e identificou 5 alertas que pertenciam a um único ataque coordenado, separando-os do ruído e correlacionando-os em uma narrativa coerente:

Em vez de apresentar 5 alertas individuais, o Attack Discovery os correlacionou em uma única descoberta:

Malware com persistência por carregamento lateral de DLL

Executável malicioso em srv-win-defend-01 escalado para persistência via BluetoothService.exe com carregamento lateral de DLL

• Host: srv-win-defend-01
• Usuário: james_spiteri
• Gravidade: Crítica
• Cadeia de ataque: Acesso inicial → Execução → Persistência → Evasão de defesa → C2

A descoberta de ataques também:

• Mapeamento de alertas para táticas do MITRE ATT&CK
• Identificou a técnica de carregamento lateral de DLLs.
• Sinalizou o mecanismo de persistência suspeito.
• Destacou o indicador de rede C2

Etapa 2: A descoberta agendada aciona o fluxo de trabalho.

A ferramenta de descoberta de ataques não exige que o analista clique em um botão. Configuramos o sistema para ser executado em intervalos de hora em hora, analisando continuamente os alertas mais recentes em busca de ataques coordenados.

Quando nossa execução horária foi iniciada, ela incorporou todos os alertas da última hora, incluindo os alertas relacionados ao Chrysalis que estavam ocultos entre as detecções de rotina, e revelou o ataque de carregamento lateral de DLL como uma descoberta.

Vincular um fluxo de trabalho como uma etapa de ação da descoberta de ataques significa que, sempre que a Descoberta de Ataques encontrar um ataque coordenado, ela acionará automaticamente o fluxo de trabalho.

Mas eis o que diferencia essa abordagem dos manuais tradicionais do SOAR: o fluxo de trabalho não descreve cada etapa detalhadamente. Ele entrega toda a descoberta do ataque ao Agent Builder e diz "descubra".

Definição de fluxo de trabalho

Este é o fluxo de trabalho real que usamos, consistindo em duas etapas, só isso:

name: Auto Triage AD
description: >-
  Demonstrates the application of AI agents and workflows 
  to enable agentic alert triaging.
enabled: true
tags:
  - Example
  - Agentic Workflow

triggers:
  - type: alert                          # Fires when Attack Discovery generates an alert

steps:
  # Step 1: Hand the attack discovery to the agent with clear instructions
  - name: initial_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        agent_id: <your-agent-id>        # Your custom Hunting Agent
        input: |
          Confirm the attack by searching for behaviour in the logs 
          (all logs which are relevant), always leverage security labs tools, 
          always leverage virustotal if file hashes are available. 
          If this is a true positive, create a case with all the relevant content too.

          {{event|json}}

          Create a slack channel for this incident, check who's on call, 
          add them to it, and send a formatted message with what's happening 
          and next steps. If this is a true positive, create a case with all 
          the relevant content too - add a button to the slack message linking 
          to the case, and another button leading to the result of the attack. 
          Lastly, include a button that will take me to this agent conversation, 
          just replace the conversation ID with the actual one from this conversation 
          (https://<your-kibana-url>/app/agent_builder/conversations/<conversation-id>)

          Change the attack discovery status to acknowledged, or, 
          if false positives, close it.
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

  # Step 2: Follow up to catch anything that didn't complete
  - name: followup_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        conversation_id: "{{ steps.initial_analysis.output.conversation_id }}"
        agent_id: <your-agent-id>
        input: |
          Complete any previous steps which might not have ran successfully. 
          Just in case, the conversation ID is 
          {{ steps.initial_analysis.output.conversation_id }}
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

Por que esse fluxo de trabalho é tão curto?

A automação completa consiste em duas etapas:

1. initial_analysisEnvie a descoberta do ataque para o Agent Builder com instruções em linguagem natural descrevendo o que você deseja que seja feito.
2. followup_analysisUm mecanismo de segurança que retoma a mesma conversa e pede ao agente para verificar se todas as tarefas foram concluídas. Como os agentes chamam várias ferramentas em sequência e qualquer chamada individual a uma ferramenta pode expirar ou apresentar um erro transitório, esta etapa garante que nada passe despercebido.

Essa é a mudança fundamental: o fluxo de trabalho é o gatilho e a rede de segurança; o agente é o cérebro.

Nos bastidores: Como ampliamos o Agente de Busca de Ameaças

Antes de prosseguirmos com os resultados, vale a pena refletir sobre o que tornou isso possível. Uma das funcionalidades mais poderosas do Agent Builder é a possibilidade de expandir os agentes existentes com ferramentas adicionais. Em vez de construir do zero, pegamos o Agente de Busca de Ameaças padrão e adicionamos ferramentas personalizadas baseadas em fluxos de trabalho para dar a ele os recursos específicos que esse cenário exigia.

O que adicionamos

O Agent Builder é fornecido com ferramentas de plataforma integradas, como platform.core.generate_esql e platform.core.product_documentation. Mas o verdadeiro poder vem de adicionar o seu próprio. Ampliamos o Agente de Busca de Ameaças com ferramentas em diversas categorias:

Cinco ferramentas personalizadas. Foi só isso que bastou para transformar o Agente de Busca padrão em um sistema que verifica automaticamente malware, pesquisa logs, encontra o responsável de plantão, cria um caso e inicia um canal de incidentes — tudo isso acelerando o tempo de detecção de uma possível ameaça.

A cadeia de raciocínio do agente

O que é notável é o seguinte: dado o contexto de descoberta de ataques, o agente decidiu automaticamente quais ferramentas utilizar e em que ordem. Nenhum ser humano programou esses passos.

Etapa 1: Consulta no VirusTotal: vt.hash.lookup

• Primeiro passo do agente: verificar o hash do malware.

Etapa 2: Gerar consulta ES|QL: platform.core.generate_esql

• Com a confirmação da presença de malware, o agente buscou por todas as atividades relacionadas.

Etapa 3: Documentação do produto: platform.core.product_documentation

• O agente consultou a documentação do Elastic Security para gerar comandos de correção para o Console de Resposta.

Etapas de raciocínio mostrando quais ferramentas foram chamadas em sequência para maior transparência.

Mostra a cadeia de raciocínio adicional: consulta à documentação do produto, verificação das informações de plantão antes de criar um chamado com todas as informações relevantes e notificar o analista de plantão via Slack.

Passo 4: Verifique a hora atual: get.time

Etapa 5: Verificar escala de plantão: check.on.call.schedule

• O agente executou uma consulta ES|QL no índice on-call-schedule para encontrar o respondente atual:

Etapa 6: Criar Caso: create.case

Etapa 7: Criar canal do Slack: create.channel

Por que isso é importante

O agente não estava seguindo um roteiro. Analisou a situação e decidiu:

1. Primeiro, verifique se o malware é real (VirusTotal).
2. Em seguida, compreenda o impacto (pesquisa de log ES|QL)
3. Em seguida, descubra como corrigir (documentação do produto).
4. Em seguida, encontre a pessoa certa para responder (escala de plantão).
5. Em seguida, crie artefatos de rastreamento (caso).
6. Por fim, coordene a equipe (canal do Slack).

Essa é a diferença entre um fluxo de trabalho (que segue uma sequência fixa) e um agente (que raciocina sobre o que fazer em seguida). O fluxo de trabalho acionou o agente; o agente resolveu o resto.

Etapa 3: Resposta automatizada a incidentes

Com confirmação de alta confiança, o fluxo de trabalho é executado automaticamente:

1. Cria um caso de incidente

É criado um caso estruturado com todas as provas relevantes anexadas:

• Resultados da descoberta de ataques
• Resultados da análise do VirusTotal
• Correspondências de inteligência de ameaças
• Análise do Agent Builder
• Ações de resposta recomendadas

2. Notifica o SOC

Uma mensagem no Slack é enviada para o canal correto, informando os analistas sobre o incidente crítico.

3. Habilita ações de resposta

O fluxo de trabalho pode, opcionalmente, acionar ações de resposta automatizadas:

• Isolamento do host: Isolar srv-win-defend-01 via Elastic Defend
• Suspensão de usuário: Desativar james_spiteri no Active Directory
• Bloqueio de rede: Adicionar o domínio C2 à lista de bloqueio do firewall.
• Varredura IOC: Inicie uma varredura em toda a frota em busca de indicadores Chrysalis.

---

Tempo para confirmação: Antes e depois

---

Outra opção: basta perguntar ao agente.

Tudo o que foi descrito acima representa o pipeline automatizado : o Attack Discovery encontra a ameaça, o fluxo de trabalho é acionado, o agente a tria e o(s) analista(s) correto(s) é(são) notificado(s).

Mas existe outra maneira igualmente eficaz de usar isso: acesse diretamente o Construtor de Agentes e faça a pergunta em linguagem simples.

Cenário: Você primeiro lê sobre a ameaça

Imagine que você está navegando pelos seus feeds de informações sobre ameaças e vê a postagem do blog da Rapid7 sobre a porta dos fundos Chrysalis. Você só quer saber: estamos comprometidos?

É isso. O mesmo agente, com as mesmas ferramentas, faz o resto:

1. Lê o relatório de ameaças usando a ferramenta web.search para extrair indicadores de comprometimento (IOCs) e táticas, técnicas e procedimentos (TTPs) do blog da Rapid7.
2. Gera consultas ES|QL para buscar indicadores do Chrysalis em seus logs de eventos de arquivos, rede e processos.
3. Verifica no VirusTotal se há hashes de arquivo correspondentes encontrados em seu ambiente.
4. Gera um resumo pronto para o CISO, contendo as conclusões, o nível de confiança e as ações recomendadas.

O agente utiliza as mesmas ferramentas que utilizaria no pipeline automatizado. A diferença está no ponto de entrada: em vez de uma Descoberta de Ataque agendada acionar um fluxo de trabalho, você acionou o agente com uma pergunta.

Por que isso muda as regras do jogo para os analistas

Esta é a parte que é fácil de ignorar, mas profundamente importante: o analista não precisava conhecer nenhuma linguagem de consulta, padrão de índice ou nome de ferramenta.

Eles não escreveram ES|QL. Eles não precisavam se lembrar onde seus diferentes dados estavam armazenados. Eles não precisavam memorizar a sintaxe da API do VirusTotal nem descobrir qual índice de inteligência de ameaças consultar.

Eles fizeram uma pergunta em linguagem natural. O agente descobriu o resto, incluindo quais índices pesquisar, quais consultas escrever, quais ferramentas usar e como sintetizar os resultados.

Para um analista júnior que se juntou à equipe no mês passado, isso é transformador. Para um analista sênior que trabalha nessa área há uma década, são horas de vida recuperadas. Para um CISO que deseja uma atualização de status, basta uma pergunta.

A barreira para uma busca eficaz de ameaças acaba de cair de "conhecer padrões de índice ES|QL e 47 " para "conseguir descrever o que está procurando".

Principais conclusões

1. A detecção de ataques programada significa que você não perderá nenhum ataque — ela analisa continuamente seus alertas, de modo que ameaças coordenadas sejam identificadas mesmo quando ninguém estiver monitorando a fila.
2. Os fluxos de trabalho orquestram a resposta, sendo acionados por descobertas, invocando agentes e executando ações.
3. O Agent Builder permite que você crie ou estenda agentes de acordo com suas necessidades — seja começando do zero ou adicionando ferramentas personalizadas a um agente existente, você molda as funcionalidades para se adequarem ao seu ambiente.
4. Os agentes raciocinam, os fluxos de trabalho são executados - o agente decidiu autonomamente consultar o VirusTotal, pesquisar registros, verificar a escala de plantão e criar um canal no Slack. Nenhum ser humano roteirizou essa sequência.
5. Dois pontos de entrada, mesma potência : o pipeline automatizado e a interface de chat utilizam o mesmo agente e as mesmas ferramentas. Quer seja desencadeado por uma descoberta agendada ou por uma pergunta feita por um analista, o resultado é o mesmo.
6. A linguagem natural é a nova linguagem de consulta – os analistas não precisam conhecer ES|QL, padrões de índice ou sintaxe de API. Eles descrevem o que estão procurando, e o agente cuida do resto.

A campanha de infiltração Chrysalis demonstra por que isso é importante. Quando agentes estatais conseguem comprometer sua cadeia de suprimentos e estabelecer persistência em 4 segundos, você precisa de defesas que acompanhem essa velocidade – seja um pipeline automatizado funcionando enquanto você dorme ou uma conversa direta com um agente quando você for o primeiro a detectar a ameaça.