☕ Um Café no Bellacosa Mainframe
Red Team e os Doze Trabalhos de Asterix — Como Invadir Roma Sem Derrubar Produção
🛡️⚔️ Quando César contratou pentesters, os gauleses descobriram engenharia social e a burocracia romana revelou ser uma vulnerabilidade crítica
Existe uma diferença fundamental entre perguntar:
“Este sistema é seguro?”
e perguntar:
“Se eu fosse o inimigo, como eu quebraria este sistema?”
A primeira pergunta normalmente produz uma apresentação PowerPoint com 87 slides, três matrizes de risco, quatro dashboards verdes e alguém dizendo que todos os patches críticos foram aplicados.
A segunda produz um sujeito olhando para o ambiente e perguntando:
— Interessante. E se eu entrar pela recepção?
Bem-vindo ao Red Team.
E existe talvez um pano de fundo cultural perfeito para explicá-lo: Os Doze Trabalhos de Asterix.
Porque Asterix e Obelix não vencem Roma simplesmente sendo mais fortes.
Obelix certamente ajuda.
Mas eles vencem porque Roma construiu sistemas supondo que todo mundo jogaria conforme as regras de Roma.
E isso, jovem padawan do mainframe, é exatamente o tipo de suposição que um Red Team adora encontrar.
🏛️ 1. O que é Red Team?
Imagine uma organização dizendo:
Temos firewall.
Temos RACF.
Temos MFA.
Temos SIEM.
Temos EDR.
Temos SOC.
Temos IDS.
Temos treinamento.
Temos política.
Temos auditoria.Excelente.
O Red Team responde:
Posso tentar entrar?Silêncio.
Essa é a essência.
Um Red Team é uma equipe autorizada a assumir a perspectiva de um adversário e tentar atingir determinados objetivos usando técnicas realistas de ataque.
Não significa necessariamente:
“Hackear tudo.”
O objetivo pode ser muito mais específico:
OBJETIVO
Conseguir acesso não autorizado
↓
obter credenciais
↓
movimentar-se pelo ambiente
↓
atingir determinado ativo
↓
sem ser detectado pelo Blue TeamPortanto, Red Team não testa apenas tecnologia.
Testa:
tecnologia + pessoas + processos + detecção + resposta.
E aqui começa nossa viagem para Roma.
🏺 2. De onde vem o termo Red Team?
A ideia é muito anterior à segurança cibernética.
Organizações militares perceberam um problema perigosíssimo:
quem cria uma estratégia tende a acreditar nela.
Você constrói sua fortaleza.
Depois olha para ela.
E pensa:
“Magnífica.”
O inimigo olha para a mesma fortaleza e pensa:
“Por que aquele portão está aberto?”
Surgiram então exercícios nos quais uma equipe representava o adversário.
Simplificando:
BLUE TEAM
defende
⚔️
RED TEAM
atacaO vermelho tradicionalmente representava a força adversária em exercícios e jogos de guerra.
A lógica migrou posteriormente para inteligência, segurança física, planejamento estratégico e finalmente cybersecurity.
Mas o princípio permaneceu:
Você não está tentando provar que seu sistema funciona. Está tentando descobrir como ele pode falhar.
🐗 3. Asterix provavelmente seria um excelente Red Teamer
Obelix resolveria praticamente qualquer problema assim:
PORTA FECHADA
↓
OBELIX
↓
PORTA NÃO EXISTE MAISIsso é tecnicamente uma forma de penetration testing.
Talvez excessivamente destrutiva.
Asterix, porém, possui características muito mais interessantes.
Ele observa.
Questiona.
Improvisa.
Explora regras.
Procura inconsistências.
Engana adversários.
Percebe comportamentos previsvisíveis.
E, principalmente:
ele raramente enfrenta o sistema exatamente da maneira que o sistema espera.
Essa é uma característica fundamental do pensamento adversarial.
🏛️ 4. César comete o primeiro erro de segurança
Roma olha para os gauleses e pensa:
“Se somos mais fortes, precisamos apenas criar provas suficientemente difíceis.”
Erro clássico.
César está pensando como system owner.
Ele conhece as regras.
Conhece os controles.
Conhece os processos.
Conhece as expectativas.
Asterix está pensando como adversário.
Ele pergunta implicitamente:
“Onde está escrito que preciso resolver o problema da maneira imaginada pelo projetista?”
E nasce uma das maiores regras do Red Team:
O atacante não é obrigado a respeitar sua arquitetura.
Seu diagrama pode dizer:
Internet
↓
WAF
↓
Firewall
↓
API Gateway
↓
Application
↓
DatabaseLindo.
O atacante talvez faça:
Funcionário
↓
LinkedIn
↓
Phishing
↓
Credential
↓
VPN
↓
Internal NetworkSeu WAF continua impecável.
E completamente irrelevante.
⚔️ 5. Trabalho I — Reconnaissance
Antes de atacar Roma, precisamos conhecer Roma.
No Red Team isso se chama reconhecimento.
O atacante procura informações sobre a organização:
domínios
subdomínios
IPs
tecnologias
funcionários
fornecedores
emails
documentação pública
GitHub
vagas de emprego
certificados
APIs
metadados
cloud assetsUma inocente vaga dizendo:
“Procuramos especialista em z/OS, RACF, CICS, Db2, MQ e CyberArk.”
já revelou uma parte considerável da arquitetura.
Asterix provavelmente chamaria isso de:
perguntar discretamente aos romanos onde fica o acampamento.
🧠 6. Trabalho II — Engenharia Social
Agora entramos no território onde muitos impérios desmoronam.
Porque existe um componente tecnológico extremamente vulnerável chamado:
HUMANO 1.0Características conhecidas:
confia em autoridade
tem pressa
tem curiosidade
quer ajudar
tem medo
comete erros
reutiliza senhas
clica em coisasEngenharia social explora comportamento humano.
Exemplo:
“Olá, sou da equipe de suporte. Estamos atualizando seu acesso. Pode confirmar seu usuário?”
Ou:
“O diretor pediu urgentemente este relatório.”
Ou:
“Sua senha expira hoje.”
Não houve exploit.
Não houve buffer overflow.
Não houve zero-day.
O usuário entregou a chave.
🎣 7. Trabalho III — Phishing
Uma das técnicas clássicas.
O Red Team pode, quando autorizado pelo escopo, simular mensagens convincentes para medir:
quem abre;
quem clica;
quem fornece informação;
quem reporta;
quanto tempo o SOC demora para perceber.
Mas existe uma diferença enorme entre treinamento básico e operação Red Team.
O objetivo não deveria ser simplesmente anunciar:
“HAHA! 37 funcionários clicaram!”
Isso ensina pouco.
A pergunta interessante é:
O primeiro funcionário clicou
↓
o SOC percebeu?
↓
o email foi bloqueado?
↓
os outros usuários foram avisados?
↓
a credencial foi invalidada?
↓
a sessão foi encerrada?Agora estamos testando a organização.
🔑 8. Trabalho IV — Credential Attack
Credenciais são o equivalente moderno das senhas secretas das legiões.
O Red Team procura descobrir se uma identidade comprometida pode proporcionar acesso indevido.
Pode avaliar problemas como:
senhas fracas;
reutilização;
credenciais expostas;
secrets mal armazenados;
tokens excessivamente poderosos;
contas antigas;
contas de serviço;
privilégios inadequados.
Em ambientes corporativos antigos existe ainda o famoso:
USER123
criado: 2004
responsável: ninguém sabe
última aplicação conhecida: aposentada em 2017
privilégio: inexplicavelmente enormeO verdadeiro fóssil digital.
🪜 9. Trabalho V — Privilege Escalation
Entrar é apenas parte do problema.
Imagine que Asterix conseguiu entrar no acampamento romano vestido de legionário.
Ótimo.
Mas ele ainda é:
LEGIONÁRIO CLASSE CEle precisa chegar ao palácio de César.
No mundo digital isso pode significar:
user
↓
power user
↓
administrator
↓
domain adminou, no nosso universo:
TSO USER
↓
acesso adicional
↓
grupo privilegiado
↓
resource access
↓
OH MEUS DEUSES, QUEM AUTORIZOU ISSO?O Red Team procura caminhos de escalada de privilégio.
🏃 10. Trabalho VI — Lateral Movement
Conseguir acesso a uma máquina não significa ter conquistado Roma.
Agora precisamos andar.
WORKSTATION
↓
SERVER
↓
APPLICATION
↓
MIDDLEWARE
↓
DATABASE
↓
CRITICAL SYSTEMIsso é movimento lateral.
O Red Team tenta descobrir se a segmentação realmente impede que uma invasão local se transforme em comprometimento sistêmico.
É aqui que muitas arquiteturas descobrem uma verdade desconfortável:
O firewall externo era magnífico. O problema começou depois dele.
👻 11. Trabalho VII — Persistence
O atacante conseguiu entrar.
A pergunta agora é:
consegue permanecer?
Persistence significa estabelecer mecanismos que permitam recuperar acesso depois.
Em uma simulação autorizada, isso é cuidadosamente limitado e controlado.
O objetivo é verificar se os defensores conseguem detectar comportamentos que indicariam tentativa de permanência.
O equivalente gaulês seria Asterix descobrir que pode simplesmente guardar uma armadura romana atrás de uma árvore.
🥷 12. Trabalho VIII — Evasion
Agora surge uma diferença importante entre penetration test e Red Team.
Um pentest frequentemente pergunta:
“Consigo explorar essa vulnerabilidade?”
Red Team pode perguntar:
“Consigo atingir o objetivo sem o Blue Team perceber?”
Portanto:
RED TEAM
↓
faz alguma coisa
SIEM
↓
???
SOC
↓
???
BLUE TEAM
↓
???Se ninguém percebeu, encontramos outro problema.
Talvez a vulnerabilidade técnica fosse conhecida.
Mas a vulnerabilidade operacional não.
🚨 13. Trabalho IX — Testar detecção
Imagine Obelix atravessando o acampamento romano.
CRASH.
BOOM.
POW.
Uma torre cai.
Um legionário pergunta:
“Você ouviu alguma coisa?”
Esse é o pesadelo de qualquer SOC.
Uma empresa pode possuir milhões em ferramentas de segurança e ainda sofrer de:
baixa capacidade de detecção.
Red Team permite testar perguntas muito melhores que:
“Temos SIEM?”
Pergunte:
“Nosso SIEM perceberia?”
Depois:
“Alguém responderia ao alerta?”
Depois:
“Em quanto tempo?”
Isso muda completamente a conversa.
🏰 14. Trabalho X — Security Controls
Aqui começamos a atacar as certezas.
A organização diz:
MFA impede isso.Red Team:
Vamos verificar.
Organização:
Nossa segmentação impede aquilo.Red Team:
Vamos verificar.
Organização:
RACF impede acesso ao recurso.Red Team:
Excelente. Vamos verificar.
Observe a filosofia.
Red Team não deveria partir da afirmação:
“Seu controle não funciona.”
Ele parte da pergunta:
“Seu controle continua funcionando diante de um adversário?”
Essa diferença é importantíssima.
📜 15. Trabalho XI — O Formulário A38
E chegamos ao momento sublime.
A burocracia.
Em Os Doze Trabalhos de Asterix, uma das provas mais memoráveis não envolve monstros ou força física.
Envolve administração.
Uma repartição.
Formulários.
Autorizações.
Guichês.
Contradições.
Um sistema tão absurdamente burocrático que sua verdadeira defesa consiste em fazer o cidadão desistir.
Curiosamente, isso possui um paralelo espetacular com cybersecurity.
Imagine:
Solicitação
↓
IAM
↓
ServiceNow
↓
Gestor
↓
Security
↓
Owner
↓
RACF Admin
↓
AuditoriaTodo mundo acredita que isso garante segurança.
Mas o Red Team pergunta:
“As pessoas realmente seguem esse fluxo?”
Talvez descubra:
PROCESSO OFICIAL
12 etapas
PROCESSO REAL
"manda mensagem pro Carlos"BINGO.
Você encontrou uma vulnerabilidade organizacional.
🤯 16. A grande lição do A38
Sistemas excessivamente complexos criam atalhos humanos.
Quanto mais difícil o procedimento:
COMPLEXIDADE ↑
ATALHOS ↑
SHADOW IT ↑
ERROS ↑
BYPASS ↑Isso vale para segurança.
Se trocar senha exigir quinze passos, usuários inventarão métodos.
Se acessar produção exigir uma peregrinação administrativa, alguém criará uma conta compartilhada.
Se transferir arquivo oficialmente levar três dias:
nascerá misteriosamente:
planilha_final_agora_vai_v7.zipem algum canal que jamais deveria transportar aquilo.
O Red Team não procura apenas bugs.
Procura adaptações humanas ao sistema.
🧪 17. Trabalho XII — O objetivo final
Uma operação Red Team madura começa com objetivos.
Por exemplo:
OBJETIVO:
Demonstrar se um adversário
consegue alcançar determinado
ativo crítico.Não:
QUEBRE TUDO.Pode ser:
conseguir acessar dados simulados de determinado ambiente.
Ou:
demonstrar possibilidade de comprometimento de determinada identidade.
Ou:
testar se uma cadeia de ataque seria detectada.
Depois vem a pergunta crucial:
Red Team conseguiu?
↓
Blue Team detectou?
↓
Quando?
↓
Como?
↓
Qual controle funcionou?
↓
Qual falhou?Essa última pergunta é preciosa.
Porque Red Team não serve apenas para encontrar coisas quebradas.
Também descobre:
quais defesas realmente funcionam.
🔵 Blue Team entra na aldeia
Se existe Red Team, naturalmente existe:
Blue Team.
O Blue Team defende.
Cuida de:
monitoramento;
detecção;
incident response;
hardening;
logs;
SIEM;
EDR;
IAM;
threat hunting;
análise de comportamento;
resposta operacional.
Então temos:
RED
⚔️
ataca
BLUE
🛡️
defendeMas existe um terceiro personagem.
🟣 Purple Team
Purple Team não significa necessariamente uma terceira equipe permanente.
É principalmente a cooperação estruturada entre ataque e defesa.
Red descobre:
“Conseguimos executar X sem sermos detectados.”
Blue responde:
“Mostre exatamente o comportamento.”
Criam uma detecção.
Repetem.
Agora:
ATAQUE
↓
ALERTA
↓
SOC
↓
RESPOSTAFuncionou.
Isso é muito mais valioso do que Red Team voltar para casa dizendo:
“Ganhei.”
Segurança não é campeonato de Capture the Flag contra seus próprios colegas.
⚡ As FORÇAS do Red Team
O grande poder está no realismo.
1. Testa o sistema inteiro
Pentest pode encontrar vulnerabilidade.
Red Team encontra caminhos de ataque.
2. Descobre combinações improváveis
Talvez nenhuma falha seja crítica individualmente.
Mas:
informação pública
+
senha reutilizada
+
permissão antiga
+
segmentação ruim
+
monitoramento deficiente
=
ROMA EM CHAMAS3. Testa pessoas
Tecnologia não existe isoladamente.
4. Testa processos
O procedimento oficial pode ser perfeito.
O procedimento real pode envolver Carlos.
Sempre existe um Carlos.
5. Testa defesa
Você finalmente descobre se SOC, SIEM e incident response funcionam juntos.
6. Produz aprendizado realista
Uma coisa é dizer:
“Existe risco de credential compromise.”
Outra é demonstrar:
09:17 acesso obtido
09:31 movimento lateral
10:04 recurso crítico alcançado
14:27 primeiro alerta investigadoAgora o risco ganhou relógio.
☠️ As FRAQUEZAS
Red Team também possui problemas.
1. Pode custar caro
Profissionais especializados, preparação, infraestrutura, coordenação e análise consomem recursos.
2. Pode causar impacto
Uma operação mal planejada pode afetar produção.
Por isso existem:
SCOPE
RULES OF ENGAGEMENT
STOP CONDITIONS
AUTHORIZED TARGETS
CONTACTS
ESCALATION PROCEDURESObelix definitivamente precisa ler as Rules of Engagement.
3. Pode virar teatro
Existe Red Team ruim.
A empresa escolhe exatamente o que pode ser atacado, avisa todo mundo, proíbe praticamente todas as técnicas e depois comemora:
“Nenhum invasor conseguiu entrar.”
Naturalmente.
César retirou todos os romanos antes da invasão.
4. Pode virar competição de ego
Red:
“Vocês não nos detectaram!”
Blue:
“Vocês trapacearam!”
Security Manager:
“Senhores…”
César:
“EU SÓ QUERIA SABER SE ROMA ERA SEGURA.”
🧠 O atributo secreto: pensamento adversarial
Ferramentas podem ser aprendidas.
Mas existe um atributo muito mais interessante:
Adversarial Thinking
É olhar para algo funcionando e perguntar:
“Quais pressupostos precisam continuar verdadeiros para isso funcionar?”
Depois:
“E se um deles deixar de ser verdadeiro?”
Exemplo.
Aplicação:
IF USER-AUTHENTICATED
PERFORM TRANSACTION
END-IFDesenvolvedor pensa:
usuário autenticado pode executar.
Red Teamer pergunta:
autenticado significa autorizado?
Essa pergunta aparentemente pequena já derrubou muitos impérios digitais.
🧙 Easter Egg COBOL
Imagine um programa antigo:
IF USER-TYPE = 'A'
PERFORM ADMIN-FUNCTION.Todo mundo procura vulnerabilidade em ADMIN-FUNCTION.
O Red Teamer pergunta:
Quem controla USER-TYPE?Silêncio.
Alguém abre um copybook criado em 1989.
01 USER-RECORD.
05 USER-ID PIC X(08).
05 USER-TYPE PIC X.Depois encontram um arquivo VSAM.
Depois encontram um job batch.
Depois encontram:
//SYSIN DD *
UPDATE USER TYPE=A
/*E alguém pergunta:
“Quem pode executar esse job?”
O veterano COBOL olha pela janela.
Toma café.
E responde:
“Essa é uma excelente pergunta.”
🎺 Música de encerramento.
🐗 Easter Egg Obelix
Existe ainda uma técnica avançadíssima conhecida informalmente no Bellacosa Mainframe Security Framework como:
OBELIX ATTACKAlgoritmo:
IF DOOR = LOCKED
REMOVE DOOR
END-IFComplexidade computacional:
O(Obelix)Taxa de sucesso:
alarmantemente elevada.
Recomendação:
não implementar em produção.
🏛️ A verdadeira moral dos Doze Trabalhos
César acredita que está testando a força dos gauleses.
Mas os gauleses acabam testando algo muito maior:
as premissas de Roma.
E isso é exatamente o que um bom Red Team faz.
Ele não pergunta apenas:
Existe firewall?Pergunta:
O firewall realmente impede o ataque?Não pergunta:
Existe MFA?Pergunta:
O adversário consegue atingir o objetivo apesar dele?Não pergunta:
Existe SOC?Pergunta:
O SOC percebe?Não pergunta:
Existe procedimento?Pergunta:
As pessoas realmente seguem o procedimento?☕ E finalmente chegamos ao Café no Bellacosa Mainframe
Talvez a maior lição de Red Team seja desconfortavelmente simples:
segurança não é aquilo que deveria acontecer. Segurança é aquilo que acontece quando alguém deliberadamente tenta fazer acontecer outra coisa.
Roma possuía:
legiões.
Estradas.
Administração.
Hierarquia.
Procedimentos.
Fortificações.
Comunicação.
Logística.
Normas.
E provavelmente algum precursor latino do RACF:
ICH408I
ASTERIX
NOT AUTHORIZED TO ACCESS
ROMA.CAESAR.PALACEMesmo assim, aqueles gauleses continuavam aparecendo.
Porque César tinha cometido o erro clássico de muitos arquitetos:
ele projetou as provas pensando em como deveriam ser resolvidas.
Asterix pensava em como poderiam ser contornadas.
E entre essas duas formas de pensar existe todo o universo do Red Team.
🐗 Regra Bellacosa nº 12
BLUE TEAM pergunta:
"Como protegemos o castelo?"
RED TEAM pergunta:
"Por que eu precisaria entrar pelo portão?"
PURPLE TEAM pergunta:
"Ótimo. Como detectamos alguém pensando nisso?"E Obelix?
Obelix já está dentro.
Ninguém sabe como.
O SIEM não registrou nada.
Dois legionários estão pendurados numa árvore.
E o relatório preliminar do incidente contém apenas uma observação:
“Eles são loucos, esses romanos.” ☕⚔️🛡️
Para ir mais longe
https://eljefemidnightlunch.blogspot.com/2026/08/dick-vigarista-ia-e-o-concurso-pay-to.html
https://eljefemidnightlunch.blogspot.com/2026/08/a-causa-de-r-300-milhoes-e-o-algoritmo.html
https://eljefemidnightlunch.blogspot.com/2026/02/hackers-no-cinema-quando-hollywood.html
