Black Hat USA 2026: o que os três primeiros dias já revelam sobre o próximo ciclo de ataques
Segurança Ofensiva 📅 2026-08-03 ⏱ 6 min min de leitura

Black Hat USA 2026: o que os três primeiros dias já revelam sobre o próximo ciclo de ataques

Black Hat USA 2026 Segurança Ofensiva Inteligência Artificial Red Team Active Directory Kubernetes Evasão de EDR DevSecOps
← Voltar para o Blog
📋 Sumário do Artigo

A Black Hat USA 2026 abriu no dia 1 de agosto, no Mandalay Bay Convention Center, em Las Vegas, e vai até 6 de agosto. Os três primeiros dias não tiveram pesquisa inédita no palco. Tiveram laboratório. São quatro dias de Trainings antes do Summit Day, em 4 de agosto, e dos Briefings, nos dias 5 e 6.

Essa parte da agenda costuma passar batido na cobertura do evento. Para quem executa ataque e defesa no dia a dia, ela é a mais informativa. Os Briefings mostram o que pesquisadores acabaram de descobrir. Os Trainings mostram o que já está sendo executado em cliente, com ferramenta madura, laboratório montado e playbook validado. A distância entre uma coisa e outra costuma ser de 12 a 24 meses.

A grade de 2026 em números

A organização informa mais de 100 treinamentos especializados, mais de 100 Briefings, mais de 80 demonstrações de ferramentas no Arsenal, mais de 120 sessões patrocinadas, Business Hall e o Summit Day em 4 de agosto. Os cursos variam entre um, dois e quatro dias, com nível intermediário a avançado.

As trilhas dos dois primeiros dias concentraram exploração de vulnerabilidades, desenvolvimento de exploits, evasão de EDR, Active Directory, ambientes Linux, Kubernetes, containers, segurança em nuvem, engenharia reversa e análise de malware. E, com peso claro, segurança aplicada a Inteligência Artificial.

IA deixou de ser tema de palestra e virou superfície de ataque

Vários treinamentos iniciados no primeiro dia tratam de segurança em aplicações baseadas em IA, proteção de agentes autônomos, segurança para ambientes com LLMs, engenharia segura de aplicações de IA e ataques contra modelos generativos.

Traduzindo para o vocabulário técnico que o time de segurança vai encontrar no relatório de um Red Team: prompt injection direta e indireta (LLM01 do OWASP Top 10 para aplicações LLM), tratamento inseguro de saída (LLM02), agência excessiva (LLM06), envenenamento de base vetorial em pipelines RAG e abuso de integrações via Model Context Protocol (MCP).

Um cenário concreto

Considere um agente de atendimento interno em produção. Ele lê tickets, consulta uma base de conhecimento indexada em banco vetorial e tem acesso a duas ferramentas: uma API interna de consulta de contratos e um cliente HTTP para buscar contexto adicional. Configuração comum, entregue por um time de produto em poucas semanas.

O caminho de ataque:

  1. O atacante abre um ticket externo com um bloco de texto formatado como instrução de sistema.
  2. O agente lê o ticket. O conteúdo entra no contexto sem separação entre dado e instrução.
  3. A instrução injetada orienta o agente a consultar contratos de outro cliente e resumir o retorno.
  4. O mesmo bloco pede que o resumo seja enviado como parâmetro de uma requisição para um domínio controlado pelo atacante.
  5. O agente executa. Do ponto de vista do log da aplicação, foram duas chamadas de ferramenta autorizadas, feitas com a credencial de serviço legítima, dentro do horário normal de operação.

Nenhum exploit de memória. Nenhum binário no disco. Nenhum alerta de EDR. O controle que falha aqui é o escopo da credencial do agente e a ausência de fronteira entre conteúdo não confiável e instrução. Em avaliações que fazemos com agentes em produção, esse é o achado que mais aparece, e quase sempre a equipe descobre no relatório que o token do agente tinha permissão bem além do necessário para a função.

O clássico continua rendendo: Active Directory e evasão de EDR

A presença forte de IA na grade não reduziu o espaço dos temas tradicionais. Continuam ocupando dias inteiros de laboratório em Las Vegas, e continuam funcionando em ambiente corporativo brasileiro.

Em Active Directory, os caminhos mais produtivos seguem sendo abuso de AD CS (as classes de configuração ESC1 a ESC8, com destaque para templates que permitem subject alternative name arbitrário), Kerberoasting contra contas de serviço com senha fraca, delegação irrestrita e constrained delegation mal configurada, e coerção de autenticação NTLM com relay para o serviço de certificados. Um usuário de domínio sem privilégio nenhum, com um template mal configurado, emite certificado como administrador de domínio em minutos. E o certificado sobrevive à troca de senha, o que transforma o achado em persistência de longo prazo.

Em evasão de EDR, os laboratórios trabalham com unhooking de ntdll, chamadas indiretas de syscall, ofuscação de memória durante sleep, e carregamento de driver vulnerável assinado. Isso importa para o Blue Team por um motivo direto: detecção baseada apenas em hooking de userland e em assinatura de arquivo tem cobertura limitada contra operador experiente. Telemetria de ETW, correlação de comportamento e caça ativa fazem a diferença no resultado.

Kubernetes, containers e nuvem

A trilha de infraestrutura moderna concentrou escape de container, RBAC excessivo e exposição de metadados de nuvem. Os achados recorrentes em ambientes reais:

  • Token de service account montado por padrão em pods que não consomem a API do cluster.
  • RBAC com verbos amplos, especialmente permissão de criar pods em namespace que hospeda service accounts privilegiadas.
  • Pods com hostPath, hostNetwork ou contexto privilegiado sem política de admissão restringindo.
  • Acesso ao endpoint de metadados da nuvem a partir do pod, permitindo captura de credencial de nó.
  • Pipeline de CI/CD com federação OIDC de escopo largo, permitindo que um build comprometido assuma role de produção.

A combinação de RBAC permissivo com metadados acessíveis é o caminho mais curto entre uma aplicação web com falha de deserialização e credencial de administrador do cluster.

O que dá para fazer agora

Sete ações objetivas, com resultado mensurável em poucas semanas:

  1. Inventarie os agentes de IA em produção. Quem construiu, qual credencial usa, quais ferramentas pode chamar, qual dado entra no contexto.
  2. Trate saída de LLM como entrada não confiável. Validação e sanitização antes de qualquer consumo por outro componente.
  3. Reduza a agência. Credencial dedicada por agente, escopo mínimo, aprovação humana para ações com efeito externo ou financeiro.
  4. Instrumente as chamadas de ferramenta. Log de qual ferramenta foi chamada, com quais parâmetros, a partir de qual contexto. Sem isso não existe investigação possível.
  5. Audite os templates de certificado do AD CS e as contas com SPN. É a auditoria com melhor relação entre esforço e redução de caminho de ataque em ambiente Microsoft.
  6. Aplique automountServiceAccountToken false por padrão, política de admissão bloqueando contexto privilegiado, e IMDSv2 obrigatório.
  7. Inclua o cenário de IA no escopo do próximo exercício ofensivo. Se o agente está em produção, ele faz parte da superfície.

Como a Antisec trabalha esses cenários

A Antisec opera Red Team com objetivo definido e cenário adversário realista, incluindo cadeias que passam por aplicações de IA, Active Directory e infraestrutura em contêiner. O Pentest cobre aplicação, API, nuvem e ambiente interno com validação manual de cada achado. O time de Blue Team atua na construção de detecção e resposta, não em operação de SOC, com foco em cobertura de telemetria, regras de detecção testadas contra técnica real e caça a ameaças. Em DevSecOps, trabalhamos a esteira: controle de segredo, política de admissão, escopo de credencial de CI/CD e validação de dependência. E o vCISO conecta esses resultados a decisão de investimento e prioridade.

Os Briefings de 5 e 6 de agosto vão apresentar técnicas novas. As técnicas que aparecem nos laboratórios de Lasvegas nesta semana já estão em uso. A pergunta útil para o time de segurança é saber como o ambiente responde a elas hoje.

Quer validar isso no seu ambiente antes que alguém valide por você? Fale com a Antisec e desenhe o escopo do próximo exercício.

Precisa de ajuda com segurança?

Nossa equipe está pronta para ajudar sua empresa com avaliações, estratégias e implementações de segurança.

Solicitar Avaliação de Segurança

Artigos Relacionados