Requisitos para uma emulação efetiva

Last updated: April 23, 2026

Para obter resultados precisos e relevantes nas threat emulations, é fundamental configurar corretamente o acesso, o contexto e as informações do ativo. Uma boa configuração inicial não apenas melhora a qualidade do testing, mas também permite detectar vulnerabilidades mais profundas e reduzir ruído.

Quando o ativo conta com as informações adequadas, os agentes podem operar com maior contexto, alcançando melhor cobertura, priorização mais precisa e achados mais acionáveis.


Acesso e permissões necessárias

Para que as emulações sejam executadas sem interferências, é importante garantir o acesso correto ao ativo.

Whitelisting de IPs

É necessário permitir as IPs da Strike dentro dos controles de segurança (WAF, IDS, rate limiting, etc.).

IPs para whitelistear:

  • 52.4.41.179/32

  • 3.217.45.182/32

  • 18.210.150.0/32

  • 3.91.124.199/32

👉 Essas IPs devem ser habilitadas antes de iniciar o testing.

Isso permite:

  • Evitar bloqueios durante os testes

  • Simular ataques reais sem interrupções

  • Reduzir falsos negativos

Sem essa configuração:

⚠ Os testes podem ser bloqueados.

⚠ A cobertura é afetada.

⚠ Os resultados podem não refletir o risco real.

👉 O whitelisting é fundamental para garantir a qualidade e a precisão do testing.


Autenticação

Se o ativo requer login ou acesso restrito, é recomendável configurar métodos de autenticação.

Tipos suportados:

  • Usuário e senha

  • Tokens / API keys

  • Headers personalizados

💡 Sem autenticação, o testing se limita apenas às superfícies públicas do ativo.


Acesso a ambientes privados

Se o ativo não é público, pode-se configurar o acesso por meio de:

  • VPN

  • Redes privadas

  • Configurações específicas de acesso

Isso permite estender o testing a ambientes internos ou protegidos.

Se o ativo não é público, é necessário configurar o acesso por meio de VPN.

Atualmente, a Strike suporta apenas os seguintes protocolos:

  • OpenVPN

  • WireGuard

👉 Outros métodos de acesso podem ser avaliados em casos muito pontuais.

Isso permite estender o testing a ambientes internos ou protegidos.


Contexto e documentação

O contexto é um dos fatores mais importantes para melhorar a qualidade das emulações.

Asset context

Descrever o funcionamento do ativo ajuda a focar melhor os testes:

  • O que o sistema faz

  • Fluxos críticos

  • Dados sensíveis

  • Lógica de negócio relevante

💡 Quanto mais contexto for fornecido, mais relevantes serão os cenários de ataque simulados.


Documentação técnica

É fundamental anexar documentação técnica durante a criação do ativo. Sem essa informação, a cobertura do testing é significativamente limitada, as rotas de ataque que podem ser analisadas são reduzidas e os resultados podem ser incompletos ou de menor qualidade. A qualidade das threat emulations depende diretamente do nível de contexto disponível.

Tipos suportados:

  • Swagger / OpenAPI

  • Postman collections

  • Diagramas de arquitetura ou fluxos

Isso permite:

  • Identificar rotas de ataque mais complexas

  • Melhorar a cobertura do testing

  • Reduzir falsos positivos


Configuração do testing

A plataforma permite ajustar como e quando as emulações são executadas.

Restrições de execução

É possível definir condições para adaptar o testing ao ambiente:

  • Rate limit (quantidade de requisições por minuto)

  • Janelas de horário em que não devem ser executados testes

  • Exclusão de certos tipos de testes

Exemplos de exclusões:

  • Ataques de negação de serviço (DoS)

  • Força bruta agressiva

  • Testes destrutivos

Isso é especialmente útil em ambientes produtivos.


Boas práticas

Para maximizar o valor do testing:

✔ Fornecer contexto claro e atualizado do ativo ✔ Adicionar documentação técnica quando disponível ✔ Configurar autenticação para ampliar a cobertura ✔ Revisar restrições de acordo com o ambiente

O que evitar

Para manter a qualidade e a segurança do processo:

✖ Subir logs sem contexto ✖ Incluir documentação irrelevante ou desatualizada ✖ Compartilhar credenciais sensíveis em arquivos ✖ Adicionar informações que não contribuam ao testing

Uma configuração inicial correta permite que as threat emulations sejam mais precisas, relevantes e alinhadas com o risco real do negócio.


📄 Artículo 3: Cómo funciona el agente de Strike

🇬🇧 English — How the Strike agent works

The Strike agent is the core component that executes threat emulations on assets, combining artificial intelligence with an architecture designed to simulate the behavior of a real attacker.

Its design allows systems to be evaluated continuously, automatically, and in a controlled way, maintaining accuracy, speed, and security in every execution.

Agent architecture

The agent operates under a multi-agent architecture organized in a model of planning, orchestration, and execution.

It is composed of three main layers:

  • Planner (planning) Analyzes the asset's context, defines the strategy, and breaks down testing into specific tasks.

  • Manager / Supervisor (orchestration) Coordinates the execution of multiple tests in parallel and ensures the overall objective is met.

  • Specialized agents (execution) Execute specific techniques based on the type of vulnerability.

👉 This allows running complex evaluations faster and more completely than traditional approaches.

How tests are executed

The agent:

  • Simulates real attack paths

  • Executes multiple tests in parallel

  • Adapts to the asset's context

  • Prioritizes based on dependencies and complexity

👉 This helps detect both technical and business-logic vulnerabilities.

Human validation of results

Although execution is automated, results go through a layer of expert validation.

The Hacking Governance team:

  • Confirms vulnerabilities

  • Eliminates false positives

  • Reproduces findings

  • Evaluates real impact

👉 This guarantees results are accurate and actionable.

Operational controls and security

The agent is designed to operate safely in production environments.

It includes:

  • Execution within limits defined by the client

  • Exclusion of destructive actions

  • Real-time monitoring

  • Immediate stop mechanism (kill switch)

  • Automatic stop in case of anomalous behavior

👉 This allows continuous testing without affecting operations.

Infrastructure and execution

The agent runs on cloud infrastructure (AWS), guaranteeing:

  • Isolation between clients

  • Independent execution environments

  • Automatic environment removal upon completion

  • Access control and full traceability

👉 Each execution is independent and does not share state with others.

Testing scope

The agent mainly evaluates:

  • Web applications (public and private)

  • APIs and backend services

  • Exposed business logic

It can operate on private environments through:

  • VPN

  • Whitelisting

👉 This allows covering both public and internal surfaces.

The Strike agent combines automation, parallel execution, and expert validation to deliver continuous, accurate testing aligned with the real business risk.


🇧🇷 Português (Brasil) — Como funciona o agente da Strike

O agente da Strike é o componente central que executa as threat emulations sobre os ativos, combinando inteligência artificial com uma arquitetura desenhada para simular o comportamento de um atacante real.

Seu design permite avaliar sistemas de forma contínua, automatizada e controlada, mantendo precisão, velocidade e segurança em cada execução.

Arquitetura do agente

O agente funciona sob uma arquitetura multiagente organizada em um modelo de planejamento, orquestração e execução.

É composta por três camadas principais:

  • Planner (planejamento) Analisa o contexto do ativo, define a estratégia e decompõe o testing em tarefas específicas.

  • Manager / Supervisor (orquestração) Coordena a execução de múltiplos testes em paralelo e assegura o cumprimento do objetivo global.

  • Agentes especializados (execução) Executam técnicas específicas conforme o tipo de vulnerabilidade.

👉 Isso permite executar avaliações complexas de forma mais rápida e completa do que as abordagens tradicionais.

Como os testes são executados

O agente:

  • Simula rotas de ataque reais

  • Executa múltiplos testes em paralelo

  • Adapta-se ao contexto do ativo

  • Prioriza de acordo com dependências e complexidade

👉 Isso permite detectar vulnerabilidades tanto técnicas quanto de lógica de negócio.

Validação humana dos resultados

Embora a execução seja automatizada, os resultados passam por uma camada de validação especializada.

A equipe de Hacking Governance:

  • Confirma vulnerabilidades

  • Elimina falsos positivos

  • Reproduz achados

  • Avalia o impacto real

👉 Isso garante que os resultados sejam precisos e acionáveis.

Controles e segurança operacional

O agente foi desenhado para operar de forma segura em ambientes produtivos.

Inclui:

  • Execução dentro de limites definidos pelo cliente

  • Exclusão de ações destrutivas

  • Monitoramento em tempo real

  • Mecanismo de interrupção imediata (kill switch)

  • Parada automática diante de comportamentos anômalos

👉 Isso permite executar testing contínuo sem afetar a operação.

Infraestrutura e execução

O agente é executado sobre infraestrutura em nuvem (AWS), garantindo:

  • Isolamento entre clientes

  • Ambientes de execução independentes

  • Eliminação automática dos ambientes ao finalizar

  • Controle de acessos e rastreabilidade completa

👉 Cada execução é independente e não compartilha estado com outras.

Alcance do testing

O agente avalia principalmente:

  • Aplicações web (públicas e privadas)

  • APIs e serviços backend

  • Lógica de negócio exposta

Pode operar sobre ambientes privados por meio de:

  • VPN

  • Whitelisting

👉 Isso permite cobrir tanto superfícies públicas quanto internas.

O agente da Strike combina automação, execução paralela e validação especializada para oferecer um testing contínuo, preciso e alinhado ao risco real do negócio.