O que aconteceu?
A Cybersecurity and Infrastructure Security Agency — CISA realizou duas avaliações de Red Team utilizando técnicas semelhantes contra duas organizações de infraestrutura crítica.
A primeira, chamada no relatório de Organização A, pertence ao setor de Serviços Governamentais e Instalações.
A segunda, identificada como Organização B, atua no setor de Água e Sistemas de Tratamento de Esgoto. (The Hacker News)
O objetivo do Red Team era simular o comportamento de um atacante real para avaliar se as organizações conseguiriam:
- detectar a intrusão;
- investigar os alertas;
- impedir movimentação lateral;
- proteger sistemas críticos;
- responder adequadamente ao incidente.
Em ambos os ambientes, a equipe conseguiu chegar ao comprometimento completo do domínio e acessar sistemas corporativos sensíveis e recursos em nuvem. (The Hacker News)
A diferença estava na resposta.
Organização A não detectou o ataque
Na Organização A, o Red Team inicialmente encontrou uma aplicação web configurada com credenciais padrão em contas internas.
Esse acesso permitiu que a equipe enviasse mensagens de phishing utilizando um endereço pertencente à própria organização, aumentando significativamente a credibilidade do ataque. (The Hacker News)
O phishing resultou no comprometimento de quatro estações de trabalho.
A partir desse ponto, a equipe conseguiu avançar pela infraestrutura.
Active Directory foi comprometido
O Red Team explorou uma combinação perigosa de configurações no Active Directory.
Uma delas era o valor padrão do:
MachineAccountQuota
Por padrão, esse recurso pode permitir que usuários comuns criem contas de computador dentro do domínio.
O ambiente também possuía uma configuração insegura no:
Active Directory Certificate Services — AD CS
especificamente um modelo de certificado vulnerável ao cenário conhecido como:
ESC1 (The Hacker News)
O que significa ESC1?
Em uma configuração vulnerável desse tipo, um usuário com poucas permissões pode solicitar um certificado se passando por outra identidade.
Dependendo da configuração do domínio, isso pode resultar em:
usuário comum → certificado privilegiado → autenticação como administrador → comprometimento do domínio
Esse tipo de problema demonstra por que o AD CS precisa ser tratado como componente crítico da infraestrutura de identidade.
Credenciais estavam armazenadas em texto claro
Depois de expandir o acesso, a equipe encontrou diferentes credenciais disponíveis em sistemas internos.
Segundo a CISA, entre elas estavam:
- credenciais de contas de serviço;
- credenciais de banco de dados;
- configurações descriptografadas;
- chaves de acesso da Amazon Web Services. (The Hacker News)
Um dos principais problemas encontrados foi o uso de chaves estáticas da AWS configuradas para nunca expirar.
Essas credenciais permitiram que o Red Team avançasse também para recursos em nuvem. (The Hacker News)
Segredos estáticos aumentam o impacto
Uma chave que não expira pode permanecer útil para um invasor durante longos períodos caso seja roubada.
Isso é diferente de tokens temporários, que possuem validade limitada.
Por esse motivo, ambientes cloud devem priorizar:
- credenciais temporárias;
- roles;
- identidade federada;
- rotação automática de segredos.
Red Team conseguiu monitorar a própria equipe de segurança
Um dos pontos mais preocupantes do exercício aconteceu depois que os operadores chegaram ao ambiente Microsoft Entra ID.
A equipe conseguiu roubar um Primary Refresh Token — PRT e abusar de aplicações com permissões excessivas dentro do Entra ID. (The Hacker News)
Com isso, o Red Team conseguiu acessar inclusive mensagens da própria equipe de segurança.
Por que isso é grave?
Na prática, o atacante conseguia verificar se o SOC estava discutindo ou investigando a invasão.
Isso cria uma enorme vantagem operacional.
O invasor pode descobrir:
- quais alertas foram gerados;
- se foi detectado;
- quais sistemas estão sendo investigados;
- quais ações defensivas estão sendo planejadas.
Esse tipo de acesso transforma a infraestrutura de segurança em uma fonte de inteligência para o próprio atacante.
Mesmo assim, a Organização A não percebeu o comprometimento
A CISA informou que a Organização A não detectou a atividade do Red Team durante o exercício. (The Hacker News)
Isso aconteceu mesmo com diversas ferramentas de monitoramento e múltiplos Security Operations Centers.
O problema não era ausência completa de alertas.
Na realidade, havia alertas demais.
Excesso de falsos positivos escondeu atividade real
O ambiente produzia milhares de alertas relacionados a atividades normais da empresa.
Muitos deles eram classificados com severidade maior do que os alertas associados ao Red Team. (The Hacker News)
Como resultado, sinais reais da intrusão ficaram perdidos no volume de eventos.
Esse problema é conhecido como:
alert fatigue
ou fadiga de alertas.
Quando praticamente tudo gera alerta, os eventos realmente importantes deixam de se destacar.
SOCs não compartilhavam a mesma visão
A Organização A também possuía múltiplos SOCs e diferentes ferramentas de endpoint.
Porém, essas equipes não tinham visibilidade compartilhada adequada sobre os mesmos eventos. (The Hacker News)
Além disso:
- procedimentos de escalonamento eram insuficientes;
- analistas possuíam autoridade limitada;
- faltava contexto sobre determinados ativos.
Em um caso, um alerta legítimo relacionado à atividade do Red Team em um servidor SCCM foi descartado como falso positivo porque a equipe não conseguiu identificar corretamente o responsável pelo sistema. (The Hacker News)
Organização B respondeu em minutos
A Organização B recebeu uma avaliação com técnicas semelhantes.
Porém, o resultado foi bastante diferente.
O SOC detectou os payloads de phishing enquanto eles eram executados e isolou as estações comprometidas em períodos entre:
2 e 20 minutos. (The Hacker News)
O isolamento interrompeu a comunicação de Command and Control — C2 antes que o Red Team pudesse utilizar aquele acesso para avançar normalmente pela infraestrutura.
CISA precisou simular o comprometimento
Como o acesso inicial havia sido contido, a CISA mudou o exercício para um modelo conhecido como:
assume breach
Nesse modelo, os avaliadores partem do princípio de que um atacante já conseguiu entrar na rede.
A CISA então utilizou agentes autorizados da própria organização para executar um payload do Red Team em uma máquina não privilegiada, permitindo que o restante da avaliação continuasse. (The Hacker News)
Organização B também possuía falhas graves
A resposta rápida não significa que o ambiente fosse tecnicamente perfeito.
Depois de iniciar o cenário assume breach, o Red Team encontrou diversos problemas.
Entre eles estavam novamente credenciais armazenadas em texto claro.
Uma configuração do SCCM continha credenciais de uma conta de serviço do domínio que possuía direitos sobre um controlador de domínio. (The Hacker News)
A partir dessa conta, a equipe conseguiu executar um:
DCSync
O que é DCSync?
O DCSync abusa de permissões de replicação do Active Directory.
Um atacante com os privilégios necessários pode solicitar ao controlador de domínio informações que normalmente seriam enviadas apenas entre Domain Controllers.
Isso pode permitir acesso a hashes de senhas altamente sensíveis.
No exercício, o Red Team conseguiu recuperar o segredo da conta:
krbtgt (The Hacker News)
Essa conta é fundamental para o funcionamento do Kerberos dentro do Active Directory.
Seu comprometimento representa uma situação extremamente grave para a segurança do domínio.
Red Team chegou até a zona de OT
A equipe também conseguiu alcançar um bastion host localizado na DMZ de tecnologia operacional — OT da Organização B. (The Hacker News)
Porém, havia uma diferença importante.
O sistema não tinha acesso de saída para a internet.
Isso impediu que o Red Team estabelecesse comunicação com sua infraestrutura C2. (The Hacker News)
Como resultado, a equipe não avançou para dentro dos sistemas OT propriamente ditos.
Segmentação fez diferença
Esse resultado demonstra a importância de controles simples de arquitetura.
Mesmo que um atacante consiga alcançar um sistema intermediário:
ausência de acesso externo + segmentação + controle de rede
podem impedir que aquela máquina seja utilizada como ponto de controle.
As duas empresas foram comprometidas, mas o impacto operacional foi diferente
Tecnicamente, as duas organizações apresentavam falhas significativas.
A diferença estava na capacidade de:
- identificar;
- interpretar;
- responder;
- conter rapidamente.
A própria CISA resumiu a principal conclusão:
“Ferramentas de detecção são tão eficazes quanto as pessoas, processos e procedimentos que as apoiam.” (The Hacker News)
Essa comparação é especialmente importante porque as avaliações foram realizadas utilizando técnicas semelhantes.
Principais falhas identificadas
Na Organização A
A CISA destacou problemas como:
- Machine Account Quota mantido no valor padrão;
- templates vulneráveis no AD CS;
- credenciais armazenadas em texto claro;
- chaves AWS estáticas sem expiração;
- aplicações Entra ID com permissões excessivas;
- falta de integração entre SOCs;
- excesso de falsos positivos;
- procedimentos inadequados de escalonamento. (The Hacker News)
Na Organização B
Apesar da resposta inicial muito melhor, foram identificados problemas como:
- credenciais em arquivos de configuração;
- permissões excessivas em contas de serviço;
- possibilidade de DCSync;
- caminhos de acesso até infraestrutura próxima ao ambiente OT. (The Hacker News)
Como reduzir esse tipo de risco?
A CISA recomenda que organizações fortaleçam tanto controles técnicos quanto processos de operação do SOC. (CISA)
Revisar Active Directory
Empresas devem verificar:
- valor de MachineAccountQuota;
- permissões de criação de computadores;
- configurações do AD CS;
- templates vulneráveis a ESC1;
- contas com privilégios de replicação;
- grupos administrativos.
Eliminar credenciais em texto claro
Segredos não deveriam permanecer armazenados diretamente em:
- scripts;
- arquivos .config;
- documentos;
- tarefas automatizadas;
- repositórios;
- configurações SCCM.
Credenciais devem ser movidas para mecanismos seguros de gerenciamento de segredos.
Reduzir chaves cloud permanentes
Chaves AWS configuradas para nunca expirar devem ser evitadas sempre que possível.
Prefira:
- IAM Roles;
- credenciais temporárias;
- rotação automática;
- políticas de menor privilégio.
Revisar permissões no Entra ID
Aplicações com capacidade de ler e-mails ou dados de todos os usuários devem receber atenção especial.
Uma aplicação excessivamente privilegiada pode oferecer ao atacante um caminho diferente das contas administrativas tradicionais.
Análise Técnica CyberX
O caso prova que comprar mais ferramentas não resolve sozinho
A Organização A não estava sem ferramentas de segurança.
Ela possuía múltiplos SOCs e tecnologias de endpoint.
Mesmo assim, nenhuma etapa relevante do ataque foi identificada corretamente.
O principal problema foi operacional.
Quando existem milhares de falsos positivos, cada novo alerta perde importância.
Isso demonstra uma regra fundamental para SOC:
visibilidade sem capacidade de priorização não significa segurança.
MTTD e MTTR podem ser mais importantes que prevenção perfeita
A Organização B também foi tecnicamente comprometida durante o exercício.
No entanto, seu SOC respondeu à primeira etapa em poucos minutos.
Isso mostra que prevenção perfeita é um objetivo difícil.
Uma estratégia madura assume que algum controle eventualmente vai falhar.
A pergunta então passa a ser:
quanto tempo o atacante consegue permanecer ativo antes de ser detectado e contido?
Dois indicadores importantes são:
- MTTD — Mean Time to Detect
- MTTR — Mean Time to Respond
No caso da Organização B, a contenção em poucos minutos impediu que o fluxo normal da intrusão avançasse.
AD CS continua sendo uma superfície crítica
A utilização de um template ESC1 reforça um problema recorrente.
Muitas empresas protegem:
- Domain Controllers;
- contas Domain Admin;
- GPOs.
Mas tratam o AD CS como um serviço secundário.
Isso é um erro.
Em determinados cenários, uma autoridade certificadora mal configurada pode permitir que um usuário comum obtenha um certificado válido para se autenticar como uma conta privilegiada.
O AD CS deve ser tratado como parte do Tier 0 da infraestrutura de identidade.
Segredos em arquivos continuam sendo um problema básico e crítico
Nas duas organizações, credenciais armazenadas em arquivos tiveram papel importante.
Esse é um problema aparentemente simples, mas que continua abrindo caminhos para ataques sofisticados.
Um atacante que consegue acessar um servidor não precisa necessariamente explorar outra vulnerabilidade se encontrar:
username=service_admin
password=SenhaDaEmpresa
dentro de uma configuração.
O gerenciamento de segredos precisa fazer parte de qualquer estratégia moderna de segurança.
O acesso ao e-mail do SOC é particularmente perigoso
O comprometimento de aplicações no Entra ID permitiu que o Red Team verificasse mensagens da equipe de segurança.
Do ponto de vista ofensivo, isso oferece algo próximo de um feedback em tempo real sobre a investigação.
Se um atacante souber que foi detectado, pode:
- trocar infraestrutura;
- remover persistência;
- acelerar exfiltração;
- apagar artefatos;
- mudar de técnica.
Permissões administrativas em SaaS e aplicações corporativas precisam, portanto, ser incluídas em avaliações de privilégio, e não apenas contas humanas.
Segmentação de OT continua sendo essencial
O caso da Organização B também demonstra uma vitória defensiva importante.
O Red Team chegou até um bastion host na DMZ de OT, mas não conseguiu estabelecer C2 externo.
Isso mostra que segmentação real precisa envolver não apenas firewall entre redes.
Também deve considerar:
- tráfego de saída;
- DNS;
- proxies;
- protocolos permitidos;
- caminhos de administração.
Uma DMZ que permite qualquer saída para a internet pode perder grande parte do seu valor defensivo.
Recomendação CyberX
A CyberX recomenda que organizações utilizem este relatório como um checklist prático para avaliação dos seus SOCs.
Não basta perguntar:
“Temos EDR?”
As perguntas relevantes são:
- nossos analistas conseguem enxergar todos os endpoints?
- ferramentas diferentes compartilham contexto?
- alertas críticos realmente chegam ao topo da fila?
- o analista sabe quem é responsável pelo ativo?
- existe autoridade para isolar uma máquina imediatamente?
- o SOC consegue detectar DCSync?
- alterações no AD CS são monitoradas?
- segredos estão expostos em arquivos?
- aplicações Entra ID possuem permissões excessivas?
- workloads críticos possuem acesso de saída desnecessário?
Se essas respostas não forem conhecidas, existe uma lacuna operacional que precisa ser tratada.
Conclusão
As duas avaliações da CISA mostram como organizações com níveis tecnológicos semelhantes podem ter resultados completamente diferentes durante uma intrusão.
As duas foram comprometidas em nível de domínio.
Porém, enquanto a Organização A não conseguiu identificar o ataque, a Organização B detectou e isolou as primeiras máquinas afetadas em apenas alguns minutos. (The Hacker News)
O principal ensinamento da CISA não é que uma determinada ferramenta de segurança falhou.
É que tecnologia sem processos, contexto, integração e autoridade operacional pode produzir milhares de alertas sem impedir um atacante de assumir o domínio.
Para empresas, a mensagem é simples:
um SOC eficiente não é aquele que gera mais alertas, mas aquele que consegue identificar rapidamente quais alertas realmente importam e agir antes que o invasor avance.
Referências
Esta notícia foi elaborada a partir da matéria publicada pelo The Hacker News em 26 de agosto de 2026 e validada com o alerta oficial AA26-237A — “A Tale of Two SOCs: Insights From Two Red Team Assessments”, publicado pela CISA em 25 de agosto de 2026. (The Hacker News)