O red teaming é uma simulação autorizada de um adversário real executada ao mesmo tempo contra as pessoas, os processos e a tecnologia de uma organização, com um objetivo específico e sem ser detectada. O sucesso é medido pelo que os atacantes alcançam e pelo que os defensores percebem, não por quantas vulnerabilidades o exercício revela.
No relatório State of Attacks 2026 da Fluid Attacks, que cobre os testes de segurança realizados entre 1º de janeiro e 31 de dezembro de 2025, 87 % das vulnerabilidades de severidade crítica foram identificadas por revisão manual e não por ferramentas automatizadas. São essas as falhas que um adversário encadeia em uma rota de ataque, e as que um scanner tem menos probabilidade de encontrar.
Esta página explica a disciplina: o que é o red teaming, como um exercício é executado, os marcos que o estruturam, em que difere do pentesting e o que exigir de um fornecedor. Também deixa clara a posição da Fluid Attacks.
O que é o red teaming?
O red teaming é uma simulação de adversário dirigida a um objetivo. Uma equipe de especialistas ofensivos, autorizada por escrito e em geral desconhecida dos defensores, escolhe um objetivo concreto —privilégios de administrador de domínio, um sistema de pagamentos, um banco de dados de clientes específico— e avança em direção a ele com a mistura de exploração técnica, engenharia social e acesso físico que as regras de engajamento permitirem.
O sigilo é a restrição que define o red teaming, e é o que o separa de qualquer outra avaliação. Se os defensores sabem que o ataque vem, eles se comportam de outra forma e o exercício deixa de medir aquilo para o que existe. Rafael Alvarez, CTO e cofundador da Fluid Attacks, colocou o princípio sem rodeios em um texto sobre atacar sem anunciar:
"It's absurd that, in these attacks, red team members report progress or request permissions from blue team members…" (é absurdo que, nesses ataques, os membros do red team relatem avanços ou peçam permissões aos do blue team).
O escopo é a organização inteira, não um sistema. É por isso que o red teaming alcança funcionários, fornecedores, leitores de crachá e centrais de atendimento, e é por isso que termina em uma narrativa —como um atacante foi de fora até o objetivo— e não em uma lista de achados.
Três coisas que ele não é:
Não é um pentest mais longo: um pentest tenta encontrar o maior número possível de falhas dentro de um limite definido. Um exercício de red teaming para assim que tem uma cadeia que funciona.
Não é uma avaliação de vulnerabilidades: as pontuações de severidade descrevem falhas isoladas. O red teaming descreve o que acontece quando várias são usadas juntas.
Não é breach and attack simulation: o BAS repete técnicas conhecidas de forma automática e contínua. O red teaming depende de pessoas improvisando contra um alvo vivo.
Por que o red teaming é importante?
O red teaming é importante porque testa as duas capacidades que nenhuma varredura avalia: se os defensores detectam uma intrusão enquanto ela acontece, e se a resposta da organização a contém. Todo o resto que uma avaliação mede é pré-condição para essas duas.
A detecção é uma afirmação até que alguém a teste
Uma implantação de EDR, uma regra de correlação no SIEM e um manual de resposta a incidentes são afirmações sobre o que aconteceria durante um ataque. Continuam sendo afirmações até que um adversário se mova pelo ambiente e alguém verifique o que disparou, quem viu e quanto tempo levou para agir.
Essa medição é o produto do red teaming, e é a razão pela qual Alvarez defende deixar os defensores na incerteza. Se eles não conseguem distinguir um atacante simulado de um real, escreve ele, o blue team "will always be in a state of alert and respond according to defined procedures" (estará sempre em estado de alerta e responderá conforme os procedimentos definidos). Uma equipe em alerta permanente é o ponto, não um efeito colateral.
A via de entrada raramente é a que você defendeu
Duas violações explicam isso melhor que qualquer argumento. A invasão à Target em 2013 é a rota de ataque clássica que vai do fornecedor ao núcleo, e o relatório do Comitê de Comércio do Senado dos Estados Unidos de março de 2014 a analisou como uma kill chain, documentando os pontos onde o ataque poderia ter sido detido. Está amplamente documentado que os atacantes entraram com credenciais roubadas de um fornecedor externo antes de chegar aos sistemas de pagamento: uma rota que nenhuma avaliação limitada a um único aplicativo encontraria.
Em 2021, o CEO da Colonial Pipeline declarou ao Comitê de Segurança Interna e Assuntos Governamentais do Senado dos Estados Unidos que os atacantes "exploited a legacy virtual private network (VPN) profile that was not intended to be in use" (exploraram um perfil legado de VPN que não deveria estar em uso) (depoimento escrito, 8 de junho de 2021). O comunicado da CISA sobre o ransomware DarkSide mapeia ao MITRE ATT&CK as técnicas que o grupo usou depois. Nenhum scanner sinaliza um perfil de VPN esquecido, porque ele funciona exatamente como foi projetado. O red teaming parte da pergunta do atacante, não da ferramenta, e trata esse perfil pelo que ele é: uma porta sem vigilância.
As cadeias começam na autenticação fraca
Isso não é anedótico. No relatório State of Attacks 2026 da Fluid Attacks, o tipo de vulnerabilidade que concentrou a maior parcela da exposição total ao risco foi a ausência ou evasão do mecanismo de autenticação, com 19,1 %. A autenticação é ao mesmo tempo o controle mais valioso de derrotar para um adversário e aquele que as organizações mais costumam dar por resolvido, e é por isso que um exercício de red teaming quase sempre vai primeiro atrás dele.
O red teaming e a Fluid Attacks
A Fluid Attacks não oferece red teaming
A Fluid Attacks não vende red teaming nem executa exercícios de red team. Sua oferta são testes contínuos de segurança de aplicações em onze técnicas: SAST, AI SAST, DAST, SCA, CSPM, MAST, secret scanning, container scanning, Secure Code Review, Pentesting as a Service (PTaaS) e Reverse Engineering. Nenhuma das onze é uma simulação de adversário contra defensores que nunca foram avisados.
O tema não é estranho à casa. Os pentesters da Fluid Attacks têm certificações feitas especificamente para esta disciplina —OSEP, CRTP, CRTM, Red Team Operator, Active Directory Red Team Specialist, AWS e Azure Red Team Expert— e as 59 ferramentas que usam estão publicadas abertamente, entre elas BloodHound, CrackMapExec, Rubeus, mimikatz e Covenant. O conhecimento operacional do red teaming está na casa. O exercício não está na lista de preços.
O que a Fluid Attacks faz no lugar disso, e por quê
O argumento a favor dos testes contínuos frente aos exercícios periódicos é um argumento sobre o que vence. Uma avaliação pontual descreve um sistema que deixa de existir no momento em que entra o próximo commit, e a diferença aumenta a cada implantação.
Os números por trás dessa posição são concretos. No benchmark da Fluid Attacks sobre 36 ferramentas AppSec de terceiros, executado contra um alvo de avaliação com 1.201 vulnerabilidades em 105 categorias CWE, um pentester da Fluid Attacks que trabalhou 49 dias encontrou 1.076 delas: 89,6 % de recall com 100 % de precision. O melhor resultado automatizado do mesmo teste, o do próprio scanner da Fluid Attacks, foi de 22,7 % de recall, e a média das outras 34 ferramentas foi de 1,7 %. O mais revelador: 743 vulnerabilidades, 61,9 % do total, foram encontradas apenas pelo pentester, invisíveis para todas as ferramentas da comparação.
Recall e precision por ferramenta; o pentester encontrou 743 vulnerabilidades que nenhuma ferramenta detectou.
O que o red teaming cobre que os testes contínuos não cobrem
Dizer o limite importa mais que o discurso de venda. Os testes contínuos de segurança de aplicações examinam código, infraestrutura, configuração de nuvem e dependências. Eles não ligam para um funcionário fingindo ser o suporte de TI, não entram em um prédio atrás de alguém que segura a porta e não medem quanto tempo um centro de operações de segurança leva para escalar um alerta às 3 h.
Essas são superfícies de ataque reais, e o red teaming é a disciplina construída para testá-las. Uma organização que precisa dessa medição precisa de um exercício de red teaming e deveria contratá-lo. Dizer o contrário seria vender um scanner como substituto de um simulado de incêndio.
Onde os dois se encontram
As vulnerabilidades que o red teaming encadeia são as mesmas que os testes contínuos encontram e fecham primeiro. O banco de dados público de vulnerabilidades da Fluid Attacks cataloga 384 tipos de fraqueza mapeados a 182 requisitos de segurança, 2.021 correções e 66 padrões indexados, entre eles o MITRE ATT&CK, onde 36 mitigações do ATT&CK estão ligadas a requisitos numerados, e o NIST SP 800-115.
A Fluid Attacks mapeia 36 mitigações do MITRE ATT&CK a seus próprios requisitos de segurança numerados.
Três entradas ficam bem no meio de uma rota de ataque típica: escalação de privilégios, ausência ou evasão do mecanismo de autenticação e credenciais administrativas armazenadas em memória cache. Cada uma traz um tempo esperado de remediação: 60 minutos para a primeira. Fechá-las sai melhor do que descobrir em um exercício que eram elos de uma cadeia.
Como escolher um fornecedor de red team
Veja o que convém verificar antes de assinar.
Acreditação baseada em inteligência: a CREST acredita fornecedores sob disciplinas criadas para este trabalho, entre elas Intelligence Led Penetration Testing (STAR) e STAR-FS. Pergunte qual acreditação o fornecedor tem e para qual serviço, e depois confirme você mesmo no CREST Marketplace em vez de acreditar em uma apresentação comercial.
Regras de engajamento por escrito, antes de começar: objetivos, sistemas fora do escopo, técnicas permitidas, contatos de escalação e datas de devolutiva. A regra de Alvarez é o piso correto: "The red team must have complete authorization on paper and by email and all forms of legal protection…" (o red team deve ter autorização completa em papel e por e-mail, e todas as formas de proteção legal).
Um critério de alerta antecipado acordado de antemão: defina quais achados são graves o bastante para parar o exercício e ser contidos de imediato, e quais esperam o relatório. Sem essa linha, um fornecedor ou interrompe o tempo todo ou senta em cima de algo urgente.
Independência, e prova de que você verificou: o TIBER-EU coloca a carga sobre você, ao indicar que a entidade avaliada "should carry out due diligence to make sure its chosen provider meets all the requirements" (deve fazer a devida diligência para garantir que o fornecedor escolhido cumpre todos os requisitos). Verificar o fornecedor é seu trabalho, não o dele.
Evidência sobre a qual você possa agir: acorde os formatos antes de o exercício começar. A Fluid Attacks publica os formatos de evidência que suporta —capturas anotadas, gravações em vídeo do ataque, relatórios executivos em PDF e técnicos em XLSX— e uma lista comparável é justo exigir de qualquer um.
Consentimento e propriedade: o fornecedor deve confirmar a autorização do dono de cada ativo no escopo. No escopo do SLA documentado da Fluid Attacks, a propriedade é um dos quatro critérios que delimitam o que pode ser testado.
Red teaming, pentesting e BAS não são alternativas
Esses três quase sempre são apresentados como uma escada de maturidade, o que confunde: eles respondem a perguntas diferentes e uma organização pode precisar dos três ao mesmo tempo. Duas variáveis os separam com clareza: quem sabe que o ataque está acontecendo e quão amplo é o alvo.
| Breach and attack simulation | Pentesting | Red teaming |
Pergunta respondida | Nossos controles detêm técnicas conhecidas? | O que é explorável neste sistema? | Um adversário consegue chegar ao objetivo sem ser detectado? |
Alvo | Controles de segurança | Um sistema ou aplicativo definidos | A organização inteira, incluindo pessoas e instalações |
Defensores cientes | Sim | Em geral sim | Não, por design |
Executado por | Uma plataforma automatizada | Pentesters | Especialistas ofensivos, muitas vezes com apoio de inteligência de ameaças |
Termina em | Um relatório de cobertura de controles | Uma lista de vulnerabilidades com evidência | Uma narrativa de uma ou mais rotas de ataque |
Cadência | Contínua | Contínua ou periódica | Periódica, de semanas a meses por exercício |
Dos três, o red teaming é o único julgado por passar despercebido, e essa diferença arrasta todo o resto: escopo, duração, custo e quem é avisado. Executar red teaming contra uma empresa que nunca fez revisão segura de código é comprar uma confirmação cara de algo que testes mais baratos teriam encontrado em uma tarde.
Red team, blue team, purple team e white team
Em um exercício maduro aparecem quatro equipes, e confundi-las é a fonte de confusão mais comum quando se fala de red teaming.
Equipe | Papel | Atividades típicas |
🔴 Red team | Ofensiva | Simulação de adversários, sigilo, encadeamento de exploits em rotas de ataque, teste da resposta a incidentes provocando-a |
🔵 Blue team | Defesa | Detecção com SIEM e EDR, análise forense, contenção de ameaças, endurecimento de configurações |
🟣 Purple team | Colaboração | Sessões ao vivo em que técnicas ofensivas são executadas enquanto os defensores ajustam suas regras de detecção em tempo real |
⚪ White team | Controle | Autoriza o exercício, guarda as regras de engajamento, arbitra incidentes, é o único grupo interno que sabe |
Os nomes não são universais no red teaming: o TIBER-EU chama o quarto grupo de control team e acrescenta um quinto do lado do regulador.
O purple teaming é um modo de trabalho e não um departamento permanente, e troca medição por aprendizado. Assim que os atacantes anunciam o que estão fazendo para que os defensores observem, o exercício deixou de ser red teaming: passa a ser excelente para ajustar regras de detecção e inútil para descobrir se essas regras teriam disparado sozinhas.
Como um exercício de red team é executado
Um exercício de red teaming percorre seis fases, e a única que a maioria das organizações planeja bem é a primeira. A tabela mapeia cada fase com o que os defensores deveriam conseguir ver e com o tipo de fraqueza do catálogo da Fluid Attacks que costuma torná-la possível.
Fase | O que os atacantes fazem | O que os defensores deveriam detectar | Fraqueza relacionada |
1. Objetivos e regras | Definem objetivo, escopo, técnicas permitidas e rota de escalação com o white team | Nada: esta fase é invisível de propósito | — |
2. Reconhecimento | Inteligência de fontes abertas sobre funcionários, fornecedores, ativos expostos e tecnologias | Enumeração incomum de ativos públicos | — |
3. Acesso inicial | Phishing e outras formas de engenharia social, reúso de credenciais, serviços expostos, entrada física | Logins anômalos, dispositivos novos, alertas do gateway de e-mail | |
4. Escalação de privilégios | Abuso de papéis mal configurados e credenciais em cache para obter acesso administrativo | Criação de contas privilegiadas, manipulação de tokens | |
5. Movimento lateral | Movimento lateral entre hosts e relações de confiança rumo ao objetivo | Tráfego leste-oeste entre sistemas que normalmente não conversam | |
6. Objetivo e relatório | Alcançam o objetivo, documentam a cadeia, fazem a devolutiva com todas as equipes | Preparação de dados e volumes de exfiltração | — |
As ferramentas que o red teaming usa são conhecidas e em boa parte públicas: o BloodHound mapeia rotas de ataque no Active Directory, o mimikatz colhe credenciais, o CrackMapExec automatiza o movimento entre hosts e frameworks como o Covenant rodam o comando e controle. Os pentesters da Fluid Attacks usam muitas dessas mesmas ferramentas em testes contínuos, e a lista completa está publicada em sua documentação.
Há um ponto sobre a última fase que vale dizer, porque é mal conduzido de forma rotineira. As vulnerabilidades encontradas durante um exercício de red teaming normalmente não são remediadas até o exercício fechar: corrigi-las em pleno andamento corta a cadeia que a equipe vinha construindo e destrói a demonstração do impacto. A exceção é o critério de alerta antecipado acordado na fase um. Todo o resto espera o relatório.
Os marcos sobre os quais um exercício de red team é construído
Três obras de referência carregam quase todo o peso no red teaming, e um fornecedor que não consiga fixar sua posição diante das três está improvisando.
MITRE ATT&CK
O MITRE ATT&CK é uma base de conhecimento curada de táticas e técnicas de adversários extraídas de observações do mundo real. Ele dá aos dois lados de um exercício de red teaming um mesmo vocabulário: os atacantes descrevem o que fizeram com identificadores de técnica, e os defensores conferem sua telemetria contra esses mesmos identificadores. A Fluid Attacks mapeia 36 mitigações do ATT&CK a seus próprios requisitos de segurança em seu banco de dados público.
NIST SP 800-115
O Technical Guide to Information Security Testing and Assessment do NIST, publicado em setembro de 2008, é a referência formal para planejar avaliações técnicas, analisar achados e construir estratégias de remediação. A maioria dos processos de compra ainda aponta para ele quando especifica trabalho ofensivo, red teaming incluído. A Fluid Attacks mapeia suas seções a 25 de seus próprios requisitos.
TIBER-EU, DORA e CREST
O TIBER-EU —Threat Intelligence-based Ethical Red Teaming— foi publicado pelo Banco Central Europeu e pelos bancos centrais nacionais da UE em maio de 2018 como o marco para testes baseados em inteligência sobre entidades financeiras. Ele separa cinco equipes: o blue team, avaliado sem saber; o control team, o pequeno grupo interno que sabe; um fornecedor de inteligência de ameaças; os avaliadores do red team; e o TIBER cyber team, que supervisiona a conformidade do lado da autoridade. A devida diligência sobre os fornecedores cabe à entidade avaliada.
A Digital Operational Resilience Act tornou depois obrigatório o threat-led penetration testing para as entidades financeiras significativas da UE, sob o Artigo 26, e o TIBER-EU foi atualizado em 2024 para se alinhar a ela. É por isso que a demanda por red teaming cresce mais rápido em setores regulados.
Quando uma organização está pronta para o red teaming
Uma organização está pronta para o red teaming quando sua resposta a "o que está quebrado no nosso software?" ficou entediante. Se um programa de testes de segurança fecha falhas de forma contínua e o backlog aberto não tem nada crítico, a pergunta que resta —se alguém perceberia um intruso— vale o que custa responder.
Os dados sugerem que a maioria ainda não chegou lá. No relatório State of Attacks 2026 da Fluid Attacks, 70 % dos sistemas avaliados tinham ao menos uma vulnerabilidade de severidade alta ou crítica, ante 53,3 % em 2024, e a taxa geral de remediação chegou a 62,2 % no fim de 2025. Os sistemas que usaram um CI Gate para bloquear compilações inseguras chegaram a 72 %, contra 58 % dos que não usaram.
Três sinais de preparo são concretos: as vulnerabilidades são remediadas em dias e não em trimestres, existe um processo documentado de resposta a incidentes e ele já foi ensaiado, e alguém é dono da decisão de escalar de madrugada. Sem o terceiro, o red teaming só vai provar que ninguém estava olhando.
Conclusões
O red teaming mede algo que nenhum scanner relata: se uma organização percebe e detém um adversário real. É simulação de adversários sobre pessoas, processos e tecnologia, julgada pelos objetivos alcançados e pelos alertas que ninguém viu, e se paga quando as perguntas mais baratas já têm resposta.
A Fluid Attacks oferece testes contínuos com pentesters e scanners, que fecham as vulnerabilidades que um adversário encadearia e que, em seu próprio benchmark, revelaram 743 falhas que nenhuma ferramenta automatizada de uma comparação de 36 detectou. Os dois são complementos e não concorrentes, e quem vender o segundo como o primeiro está vendendo um detector de fumaça como um simulado de incêndio.
Perguntas frequentes
Qual é a diferença entre red teaming e pentesting?
O escopo e o sigilo. O pentesting examina um sistema definido e tenta encontrar nele todas as falhas exploráveis, em geral com o conhecimento dos defensores. O red teaming mira a organização inteira, persegue um objetivo específico, inclui as pessoas e a segurança física, e é executado sem avisar o blue team.
O blue team deveria saber de um exercício de red team?
Não. Apenas o white team deveria saber. O exercício existe para medir detecção e resposta em condições realistas, e defensores que esperam um ataque escalam mais rápido do que fariam em um dia comum. O TIBER-EU incorpora essa separação no marco, avaliando o blue team sem que ele saiba.
As vulnerabilidades devem ser corrigidas durante um exercício de red team?
Em geral não: elas esperam o relatório final. Remediar no meio do exercício quebra a cadeia de ataque que a equipe está construindo e destrói a evidência do impacto real. A exceção é um critério acordado antes de começar, que defina quais achados são críticos o bastante para disparar um alerta e uma contenção imediatos.
Alguma regulação exige red teaming?
Nos serviços financeiros da UE, na prática sim. A Digital Operational Resilience Act exige threat-led penetration testing para as entidades financeiras significativas, e o TIBER-EU é o marco que as autoridades nacionais usam para executá-lo. Fora desse setor, o red teaming costuma ser uma decisão de risco e não uma obrigação legal.
A Fluid Attacks faz red teaming?
Não. A Fluid Attacks não oferece red teaming nem executa exercícios de red team. Ela fornece testes contínuos de segurança de aplicações combinando IA, scanners e pentesters em onze técnicas. Em seu benchmark contra 36 ferramentas de terceiros, um pentester da Fluid Attacks encontrou 1.076 de 1.201 vulnerabilidades —89,6 % de recall—, incluindo 743 que nenhuma ferramenta automatizada detectou.
Encontre as rotas antes que alguém as percorra
Nossos pentesters e scanners testam seu software de forma contínua, assim as vulnerabilidades que um adversário encadearia são fechadas muito antes de valer a pena um exercício de red teaming. Teste gratuito · Fale conosco.
Comece agora com o PTaaS da Fluid Attacks
