Do Z3R0 ao HERO — Quando o T-800 Auditou o Datacenter, Desconfiou de Igor e Descobriu que Red Team Não É Só Uma Caveira no Terminal

 

Bellacosa Mainframe e a auditoria do T800

☕ Um Café no Bellacosa Mainframe

Do Z3R0 ao HERO — Quando o T-800 Auditou o Datacenter, Desconfiou de Igor e Descobriu que Red Team Não É Só Uma Caveira no Terminal

Ou: o programador COBOL queria saber se era Blue ou Red, o Exterminador respondeu que primeiro ele precisava descobrir quem tinha UPDATE na tabela de pagamentos — e Igor, naturalmente, sugeriu colocar a senha no nome do dataset para não esquecê-la.

MODELO T-800 — STATUS: OPERACIONAL
MISSÃO ORIGINAL: localizar Sarah Connor.
MISSÃO ATUALIZADA: localizar o proprietário da conta técnica com privilégio excessivo.
AVISO: “HASTA LA VISTA, SEGREGAÇÃO DE FUNÇÕES INEXISTENTE.”

O universo da segurança da informação adora cores. Há o Red Team, que pensa como um adversário; o Blue Team, que protege, monitora e responde; e o Purple Team, que tenta impedir que os dois passem a reunião inteira discutindo quem ganhou a bandeirinha do CTF.

Mas, antes que alguém instale uma distribuição cheia de ferramentas, abra três terminais pretos e declare-se “hacker ético” no LinkedIn, convém uma pequena verdade digna de uma sala de máquinas: segurança não começa pelo ataque. Começa por compreender o sistema que se pretende proteger ou avaliar.

Para o programador COBOL iniciante, isso é quase uma boa notícia. Você já está entrando por uma porta que muita gente só encontra depois de anos: a porta dos processos críticos, dos dados que realmente importam, dos controles de acesso, dos jobs que não podem falhar e das mudanças que precisam deixar rastro. No mundo em que uma API moderna conversa com uma fila, que conversa com CICS, que conversa com Db2, que conversa com um batch de quarenta anos ainda pagando salário, ninguém pode tratar segurança como detalhe de rodapé.

1. O primeiro diagnóstico do T-800: Pentest, Red Team e Blue Team não são a mesma coisa

Um pentest é uma avaliação autorizada, normalmente com escopo definido, para encontrar e validar vulnerabilidades. Pode ser um portal, uma API, uma rede, um aplicativo móvel ou um ambiente cloud. A pergunta é direta: “que falhas existem aqui, qual o impacto e como corrigir?”

O Red Team vai além: simula, de forma controlada, um adversário tentando atingir um objetivo relevante para o negócio. Não está interessado em colecionar cinquenta alertas coloridos. Está interessado em testar uma hipótese: seria possível alguém alcançar um ativo crítico? Os controles perceberiam? A organização conteria a atividade a tempo?

Já o Blue Team vive no mundo real. Ele administra ou acompanha controles, investiga alertas, endurece configurações, gerencia vulnerabilidades, melhora logs, responde a incidentes e tenta impedir que o mês da empresa acabe em reunião de crise com jurídico, diretoria e café frio.

Time	Pergunta principal	Entrega útil
Pentest	“Que vulnerabilidades existem no escopo?”	Achados priorizados, evidências e recomendações
Red Team	“Um adversário plausível atingiria o objetivo?”	Cadeia de risco simulada e avaliação de controles
Blue Team	“Como prevenimos, detectamos e respondemos?”	Controles, telemetria, investigação e recuperação
Purple Team	“O que aprendemos juntos?”	Correções testadas e detecções melhores

O Red não existe para humilhar o Blue. Se a operação termina com “entramos e vocês não viram”, mas ninguém melhora log, regra, privilégio ou processo, a empresa acabou de pagar por um trailer de filme, não por segurança.

2. O erro que termina em ABEND: ferramenta antes de fundamento

Ferramenta é multiplicador. Multiplica velocidade quando há conhecimento; multiplica confusão quando não há.

Um scanner pode apontar uma versão vulnerável. Isso ainda não responde se o serviço está exposto, se a função vulnerável está ativa, se há rota de rede, se o controle compensatório existe ou se o impacto é relevante. O profissional precisa validar a hipótese sem provocar dano.

É igual ao COBOL. Decorar READ, WRITE e PERFORM não torna ninguém dono do processamento. É preciso entender arquivo, chave, status, commit, lock, dados de entrada, regra de negócio e consequência de uma atualização. Segurança é a mesma conversa, apenas com o T-800 olhando por cima do ombro.

Os fundamentos indispensáveis são:

• Redes: DNS, TCP/IP, HTTP/S, TLS, proxy, VPN, roteamento, portas e segmentação.

• Sistemas operacionais: usuários, grupos, permissões, processos, serviços, logs, atualizações e administração.

• Programação: lógica, variáveis, validação, tratamento de erro, bibliotecas, APIs e leitura de código.

• Dados: modelagem, autenticação no banco, permissões, cópias, backups, trilhas de auditoria e mascaramento.

• Identidade: autenticação não é autorização; saber quem entrou não responde ao que essa pessoa pode fazer.

• Negócio: um ativo crítico não é necessariamente o servidor mais caro; pode ser uma tabela, uma interface, uma conta técnica ou uma etapa invisível do processo.

Curiosidade de sala de máquinas

O mainframe ensinou há décadas uma lição que a nuvem redescobre quase todo ano: controle de acesso é uma política, não uma tela de login. Um ID autenticado pode continuar perigosíssimo se tiver autoridade excessiva, grupos herdados, permissões antigas ou uso compartilhado. RACF não lê pensamentos, mas obriga a fazer a pergunta certa: quem tem acesso a quê, por qual motivo, e com qual registro?

3. A tríade CIA: não é agência secreta, embora Igor tivesse gostado da ideia

Segurança protege, no mínimo, três propriedades:

• Confidencialidade: somente pessoas e processos autorizados veem a informação.

• Integridade: dados e transações não são alterados indevidamente.

• Disponibilidade: serviços e informações permanecem acessíveis quando necessários.

Pense num pagamento. Se alguém vê o dado de outro cliente, há quebra de confidencialidade. Se consegue alterar a conta favorecida, há quebra de integridade. Se o sistema de pagamentos fica indisponível no fechamento, há quebra de disponibilidade.

E o caso real quase sempre mistura tudo. Uma credencial comprometida pode permitir leitura indevida; a mesma conta, com privilégio demais, pode alterar uma regra; a tentativa de conter o problema pode derrubar um serviço. Segurança não é uma caixinha isolada. É o conjunto inteiro do processo sob pressão.

4. Red Team profissional: o atacante autorizado que sabe a hora de parar

O Red Team avalia caminhos, não apenas máquinas. Dependendo do escopo formal, pode testar exposição externa, aplicações, APIs, configurações, identidade, segmentação, processos, fornecedores e aspectos físicos. A palavra que mantém tudo do lado certo é autorização.

Antes de qualquer exercício sério devem existir regras de engajamento: objetivo, período, ativos permitidos, sistemas proibidos, limites de impacto, contatos de emergência, tratamento de evidências, dados que não podem ser acessados e critério de parada.

“Try harder” é excelente para o laboratório. Em produção, a tradução profissional é: pare quando a evidência já prova o risco. Não se demonstra que um backup está vulnerável apagando-o. Não se demonstra que dados pessoais podem ser acessados copiando uma base inteira. Não se demonstra indisponibilidade derrubando a folha de pagamento.

O objetivo é obter evidência mínima, confiável e reproduzível. O T-800 chama isso de eficiência. O jurídico chama de sobrevivência.

5. Blue Team: o turno da madrugada, os logs e a pergunta que ninguém queria receber

Blue Team não é um analista hipnotizado por um painel cheio de alertas. É uma combinação de capacidades: monitoramento, engenharia de detecção, resposta a incidentes, gestão de vulnerabilidades, hardening, segurança de endpoints, cloud, aplicações, identidade, backups e continuidade.

Uma defesa madura distingue quatro coisas:

1. Evento: algo aconteceu; um login, uma alteração, uma conexão.

2. Alerta: uma regra considerou o evento suspeito.

3. Incidente: a investigação confirmou atividade indevida ou dano.

4. Crise: o impacto ultrapassou a capacidade normal de resposta e exige coordenação executiva, legal ou operacional.

Confundir tudo gera dois desastres clássicos: pânico por qualquer alerta ou silêncio até a manchete chegar. Logs são fundamentais porque sem eles a organização fica discutindo memória e impressão. Com registros adequados, ela reconstrói fatos.

Para quem trabalha em z/OS, isso tem sabor familiar. SMF, RACF, logs de CICS, Db2 e auditorias não são burocracia arqueológica: são peças da história que você precisará contar quando algo parecer estranho.

6. Purple Team: quando o treinamento deixa de ser guerra civil

Purple Team é colaboração deliberada. O Red apresenta uma simulação autorizada ou um comportamento relevante; o Blue observa a telemetria, avalia se houve alerta, investiga e propõe melhoria. Depois ocorre reteste.

Exemplo: um exercício mostra que uma alteração sensível em uma conta técnica não gerou alerta útil. A correção pode envolver revisão de privilégio, registro adicional, regra de correlação, aprovação de mudança e um playbook para investigação. O reteste comprova se a defesa agora enxerga o comportamento.

Não importa qual ferramenta foi usada. Importa se a empresa consegue detectar o comportamento. É por isso que o MITRE ATT&CK é tão útil: ele fornece uma linguagem para falar de objetivos e técnicas adversárias sem reduzir a discussão a uma marca de ferramenta ou a um comando da moda.

7. O mapa de carreira: do Z3R0 ao profissional confiável

Não existe atalho, mas há sequência melhor que sair colecionando cursos.

Passo 1 — Aprenda o caminho dos dados

Entenda uma transação de ponta a ponta. Um navegador chama uma API; a API autentica o usuário, consulta uma base ou um serviço corporativo, grava um log e devolve uma resposta. Pergunte em cada etapa: onde há identidade? Onde há autorização? Onde há dado sensível? O que é registrado? Quem administra?

Passo 2 — Construa um laboratório isolado

Use apenas ambientes feitos para estudo ou sistemas próprios. Não precisa de um datacenter da Skynet. Uma máquina virtual, uma aplicação de treinamento, um serviço de logs e controles simples já permitem exercitar observação, documentação, correção e reteste.

Monte sempre os dois lados: uma aplicação ou serviço intencionalmente frágil e a visibilidade defensiva correspondente. A grande lição não é “como entrar”; é “que evidência isso deixou e como eu deveria ter percebido?”

Passo 3 — Aprenda aplicações e APIs

Aplicações modernas concentram falhas que scanners podem não compreender: autorização inadequada, regra de negócio frágil, exposição excessiva de dados, integração confusa e validação só no navegador.

Exemplo seguro: se uma pessoa autenticada consegue acessar uma fatura que não lhe pertence trocando apenas um identificador, o defeito é de autorização. O sistema confirmou “quem é você?”, mas esqueceu de confirmar “você pode ver isto?”. O remédio não é apenas esconder o campo na tela; é validar a permissão no servidor, registrar tentativas e revisar o modelo de acesso.

Passo 4 — Estude identidade, cloud e DevSecOps

Hoje o perímetro é móvel. Usuários acessam SaaS, APIs usam tokens, pipelines implantam infraestrutura e contas de serviço conversam com múltiplos sistemas. Um segredo exposto, uma permissão IAM excessiva ou uma conta técnica sem dono podem ser mais graves que uma porta aberta.

O bom profissional pergunta: qual identidade executa isso? Qual privilégio ela possui? O que aconteceria se fosse usada indevidamente? Onde está o log? Há rotação de segredo? Existe menor privilégio?

Passo 5 — Escolha uma profundidade, mantenha a largura

Você pode especializar-se em segurança ofensiva, SOC, resposta a incidentes, AppSec, GRC, cloud ou mainframe. O formato ideal é o “T”: profundidade em uma área, entendimento amplo das demais.

Um programador COBOL pode construir uma especialidade particularmente rara: segurança de aplicações e integrações híbridas. Quando a frente moderna conversa com CICS, Db2, MQ, IMS, batch e arquivos críticos, entender os dois lados é uma vantagem enorme. A porta de entrada pode ser uma API; o cofre pode estar no backend legado.

8. CVE não é automaticamente risco — e scanner não é oráculo

Uma CVE é identificação pública de uma vulnerabilidade. Ela pode ser importante, mas não substitui análise. Para priorizar, considere exposição, pré-requisitos, valor do ativo, controles existentes e impacto.

Uma falha moderada em um portal público que expõe dados pessoais pode ser mais urgente que uma falha crítica em ambiente isolado, sem rota de rede e sem uso da função vulnerável. Risco é a combinação de probabilidade e impacto, não um número piscando em vermelho.

O relatório útil traduz isso. Em vez de “corrigir vulnerabilidade”, ele diz que ativo foi afetado, por que importa, como o controle falhou, qual equipe pode corrigir, que medida temporária reduz risco e como retestar.

9. O artefato mais subestimado: o relatório

Um relatório ruim é uma coleção de prints com caveira. Um relatório bom é uma ponte entre segurança e mudança real.

Ele deve explicar o cenário, evidência, impacto plausível, controles esperados, lacuna observada, recomendação prática e prioridade. Deve falar para executivos sem esconder a parte técnica e falar para técnicos sem transformar a conclusão em poesia corporativa.

Por exemplo: “Revisar a autorização de alterações de favorecido, separar criação de aprovação, limitar privilégios da conta técnica, registrar mudanças críticas e retestar o fluxo.” Isso dá à empresa um caminho. “Melhorar a segurança” só dá vontade de pedir mais café.

Epílogo — O T-800 fecha o ISPF

Ao final da auditoria, Igor pergunta se Red Team significa usar vermelho no terminal. O T-800 olha para a tela, identifica uma conta compartilhada, três permissões herdadas e um backup nunca restaurado em teste. Depois responde, com a ternura de uma prensa hidráulica:

“A COR É IRRELEVANTE. A AUSÊNCIA DE EVIDÊNCIA, NÃO.”

Ser Blue, Red ou Purple não é escolher uma fantasia. É escolher uma responsabilidade. O Red testa se a defesa resiste; o Blue constrói e opera essa defesa; o Purple garante que o aprendizado não morra no relatório. E o profissional que começa em COBOL traz algo precioso para todos eles: a noção de que sistemas importam porque processos e pessoas dependem deles.

Estude fundamentos. Pratique somente em ambientes autorizados. Aprenda a ler código, logs, permissões e fluxos de negócio. Respeite escopo. Documente bem. E desconfie de toda conta técnica cujo responsável seja descrito como “sempre foi assim”.

Porque, como o T-800 aprendeu naquele turno no datacenter, o futuro não é uma guerra entre máquinas e humanos. É uma planilha de acessos sem dono, uma API sem autorização e Igor dizendo: “Doutor, eu deixei a senha em comentários para facilitar a manutenção.”

 

☕ 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 Team

Portanto, 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
ataca

O 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 MAIS

Isso é 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
   ↓
Database

Lindo.

O atacante talvez faça:

Funcionário
   ↓
LinkedIn
   ↓
Phishing
   ↓
Credential
   ↓
VPN
   ↓
Internal Network

Seu 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 assets

Uma 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.0

Características conhecidas:

confia em autoridade
tem pressa
tem curiosidade
quer ajudar
tem medo
comete erros
reutiliza senhas
clica em coisas

Engenharia 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 enorme

O 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 C

Ele precisa chegar ao palácio de César.

No mundo digital isso pode significar:

user
 ↓
power user
 ↓
administrator
 ↓
domain admin

ou, 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 SYSTEM

Isso é 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
   ↓
Auditoria

Todo 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.zip

em 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
🛡️
defende

Mas 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
   ↓
RESPOSTA

Funcionou.

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 CHAMAS

3. 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 investigado

Agora 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 PROCEDURES

Obelix 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-IF

Desenvolvedor 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 ATTACK

Algoritmo:

IF DOOR = LOCKED
    REMOVE DOOR
END-IF

Complexidade 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.PALACE

Mesmo 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

 

Bellacosa Mainframe e diabolik entra no redt eam

☕ Um Café no Bellacosa Mainframe

🕶️ DIABOLIK NO MAINFRAME — Red Team e a Arte de Atacar as Certezas

O melhor Red Team não pergunta apenas como invadir o mainframe. Pergunta quais certezas precisam deixar de ser verdade para que o próprio ambiente abra caminho para o incidente.

Imagine a cena.

São 03:17.

O IBM Z continua funcionando.

As LPARs estão ativas. CICS responde. Db2 está disponível. JES2 continua processando sua fila. RACF permanece de pé. O SIEM está recebendo eventos. Há redundância de rede. Existe um segundo caminho. Os operadores estão na sala.

No dashboard, quase tudo continua verde.

Então alguém pergunta:

— Estamos seguros?

E Diabolik sorri.

Porque essa é a pergunta errada.

A pergunta interessante é:

Quais coisas precisam deixar de funcionar simultaneamente para transformar uma arquitetura aparentemente segura em uma arquitetura vulnerável?

Bem-vindo ao Red Team.

E, principalmente, bem-vindo ao Red Team visto sob a tutela de Diabolik, o criminoso fictício que não ficou famoso simplesmente pela força bruta.

Diabolik observa.

Planeja.

Estuda pessoas.

Entende rotinas.

Explora confiança.

Procura exceções.

E espera.

Esse último verbo é importantíssimo.

Porque um atacante sofisticado não precisa encontrar um sistema permanentemente vulnerável.

Ele pode esperar pelo momento em que o sistema temporariamente se torna vulnerável.

No mainframe isso muda completamente nossa maneira de pensar segurança.

---

🕶️ CAPÍTULO 1 — Diabolik não começa pelo RACF

Imagine que contratamos uma equipe para realizar um exercício autorizado de Red Team em uma grande organização que utiliza IBM Z.

A abordagem superficial começaria perguntando:

Qual versão do z/OS?

Existe RACF?

Existe MFA?

Como está a rede?

Quais aplicações estão expostas?

Existem APIs?

Existe USS?

Existe Zowe?

Tudo isso importa.

Mas Diabolik provavelmente começaria antes.

Ele colocaria sobre a mesa uma folha em branco e escreveria:

ASSET

O que realmente estamos protegendo?

Talvez:

CORE BANKING
CARD AUTHORIZATION
PIX
CUSTOMER DATA
PAYROLL
SECURITIES
INSURANCE
CLEARING
SETTLEMENT

Agora outra pergunta:

THREAT ACTORS

De quem estamos protegendo esses ativos?

Depois:

TRUST

Em quem o funcionamento desses sistemas confia?

Finalmente:

ASSUMPTIONS

Quais condições acreditamos que sempre serão verdadeiras?

É aqui que a investigação começa a ficar interessante.

Porque podemos descobrir que a organização possui milhões investidos em tecnologia, mas toda aquela arquitetura depende de algumas premissas extremamente humanas.

Por exemplo:

O operador seguirá o procedimento.

A conta privilegiada será usada corretamente.

O segundo link estará disponível.

O backup será recuperável.

O certificado será renovado.

O alerta será investigado.

A mudança será registrada.

O fornecedor continuará confiável.

A conta de serviço permanecerá protegida.

Alguém interromperá o processo se algo der errado.

Diabolik circula essa última frase.

"Alguém interromperá."

Será?

---

🎭 CAPÍTULO 2 — Red Team não é apenas invasão

Existe uma caricatura bastante comum de Red Team.

Alguém de moletom preto diante de seis monitores digitando furiosamente:

ACCESS GRANTED

Pronto.

Invadimos.

Mas Red Team maduro é muito mais interessante.

O exercício autorizado tenta colocar determinadas premissas defensivas sob pressão.

Pergunta:

Se um adversário real estivesse estudando nossa organização, quais caminhos poderiam levá-lo aos ativos importantes?

Isso envolve tecnologia, mas também:

• identidade;

• processos;

• segregação de funções;

• configuração;

• monitoramento;

• fornecedores;

• procedimentos;

• comportamento;

• contingência;

• comunicação;

• resposta a incidentes;

• governança.

Nosso estudo anterior chegou exatamente a esse ponto: o Red Team deixa de olhar apenas para o controle isolado e começa a investigar a arquitetura de confiança.

No mainframe isso é extraordinariamente importante.

Porque IBM Z raramente vive sozinho.

Temos algo parecido com:

USER
  ↓
DEVICE
  ↓
NETWORK
  ↓
IDENTITY
  ↓
APPLICATION
  ↓
CICS / IMS
  ↓
COBOL
  ↓
DB2 / VSAM

Mas existem dezenas de arestas laterais:

APIs
MQ
FTP/SFTP
z/OS Connect
USS
Zowe
Schedulers
DevOps
CI/CD
Cloud
Distributed Systems
Service Accounts
Vendors
Automation

Segurança é um grafo.

E cada aresta representa alguma forma de confiança.

---

🕸️ CAPÍTULO 3 — Diabolik desenha o grafo

Pegue um programa COBOL aparentemente inocente:

BILLING01

Talvez ele leia:

CUSTOMER
ACCOUNT
TRANSACTION
PRODUCT

e atualize:

INVOICE

O iniciante poderia pensar:

PROGRAM → DATABASE

Diabolik desenharia:

                    USER
                      │
                      ▼
                   RACF ID
                      │
               ┌──────┴──────┐
               ▼             ▼
             CICS           BATCH
               │             │
               ▼             ▼
            BILLING01      JCL/JES
               │             │
          ┌────┴────┐        │
          ▼         ▼        ▼
        DB2        VSAM    DATASET
          │
          ▼
       CUSTOMER

Depois continuaria:

CI/CD ──────► LOADLIB
                ▲
                │
DEVELOPER ──────┘

SERVICE ACCOUNT ──► AUTOMATION

API ──► z/OS Connect ──► CICS

MQ ──► APPLICATION

Agora temos algo muito mais interessante.

Porque a pergunta deixou de ser:

O Db2 está protegido?

Passou a ser:

Quantos caminhos diferentes podem produzir uma alteração relevante no estado desse negócio?

Esse é pensamento de Red Team.

---

🔐 CAPÍTULO 4 — RACF não protege contra todas as formas de confiança

RACF é extraordinariamente importante.

Mas existe uma armadilha conceitual:

RACF = SEGURANÇA

Não.

RACF é uma parte da arquitetura de segurança.

Imagine:

USER01
READ   DATASET.A

USER01
UPDATE DATASET.B

USER01
EXECUTE TRANSACTION.C

USER01
SUBMIT JOB.D

Cada permissão individualmente pode ter justificativa.

Auditor pergunta:

READ A?
OK.

UPDATE B?
OK.

CICS C?
OK.

JOB D?
OK.

Quatro verdes.

Diabolik pergunta:

READ A
+
UPDATE B
+
TRANSACTION C
+
JOB D
=
?

Essa é uma pergunta completamente diferente.

Não estamos mais analisando permissões isoladas.

Estamos analisando capacidade acumulada.

O usuário talvez não possua uma permissão perigosa.

Pode possuir uma combinação perigosa de permissões legítimas.

Essa diferença é fundamental.

---

🧩 CAPÍTULO 5 — Compartmentalization

Aqui aparece um princípio antigo de segurança e inteligência: compartimentalização.

Compare:

USUÁRIO A
├── desenvolvimento
├── aprovação
├── implantação
├── produção
├── auditoria
└── rollback

com:

DEV      → desenvolvimento
APPROVER → aprovação
OPS      → implantação
SEC      → segurança
AUDIT    → auditoria

Por que dividir?

Porque comprometimento possui blast radius.

Se uma identidade conhece, controla ou executa tudo, comprometer aquela identidade potencialmente compromete tudo.

O mesmo raciocínio vale para pessoas.

Vale para contas técnicas.

Vale para pipelines.

Vale para fornecedores.

Vale para APIs.

Vale para certificados.

Vale até para informações aparentemente banais.

Não precisamos transformar cada funcionário em suspeito.

O objetivo é exatamente o contrário: construir um sistema no qual a confiança em uma única pessoa não seja suficiente para destruir o modelo inteiro.

---

👤 CAPÍTULO 6 — Insider Threat não significa vilão

Quando falamos em insider threat, muita gente imediatamente imagina:

FUNCIONÁRIO TRAIDOR

Esse é apenas um cenário.

Insider risk pode envolver:

malícia
erro
negligência
coerção
engenharia social
credencial comprometida
procedimento inadequado
excesso de privilégio
informação excessiva
automação mal configurada

Imagine um analista autorizado.

Ele não deseja prejudicar ninguém.

Mas possui:

PRODUCTION ACCESS

Recebe uma solicitação aparentemente normal.

Executa determinada atividade.

O problema talvez não seja:

BAD EMPLOYEE

Pode ser:

BAD PROCESS

Um sistema resiliente deve presumir que humanos eventualmente erram.

Por isso temos segregação.

Aprovação.

Logging.

Monitoring.

Least privilege.

Dual control.

Change management.

Não porque todo mundo seja criminoso.

Porque confiança absoluta é um controle de segurança péssimo.

---

🎬 CAPÍTULO 7 — A fotografia virou filme

Aqui chegamos ao nosso Risk Scoring.

A segurança tradicional frequentemente produz fotografias:

USER01 = LOW RISK

Diabolik pergunta:

Quando?

08:00?

11:30?

03:17?

O contexto muda.

Por isso deveríamos pensar:

RISK(t)

Risco como função do tempo.

Imagine:

08:00

USER01
LOCATION = NORMAL
DEVICE   = MANAGED
ACTION   = NORMAL
RISK     = 20

Agora:

03:17

USER01
UNUSUAL CONTEXT
PRIVILEGED ACTION
CHANGE WINDOW
MULTIPLE FAILURES
RISK = ?

O usuário continua sendo USER01.

Mas o contexto deixou de ser o mesmo.

É exatamente por isso que comportamento importa.

Não perguntamos apenas:

WHO ARE YOU?

Perguntamos:

IS WHAT YOU ARE DOING
CONSISTENT WITH
WHAT WE EXPECT?

---

🧮 CAPÍTULO 8 — Risk Score não é sentença

É importante não transformar Risk Scoring em numerologia.

Podemos imaginar pedagogicamente:

BASELINE.................... 20
privileged operation........ +15
unusual context............. +10
change detected............. +10
control degraded............ +15
unexpected dependency....... +10
-------------------------------
RISK........................ 80

Esses números são ilustrativos.

O princípio importa mais que o peso.

Cada evento altera contexto.

Portanto:

EVENT
   ↓
CONTEXT
   ↓
RISK RECALCULATION
   ↓
DECISION

Isso permite decisões graduais:

ALLOW

CHALLENGE

REQUIRE APPROVAL

LIMIT

ESCALATE

STOP

Diabolik detestaria principalmente a última.

---

🚨 CAPÍTULO 9 — CHANGE é um evento de segurança

Mainframe conhece Change Management muito bem.

Mudou:

JCL
COBOL
PARMLIB
PROCLIB
LOADLIB
RACF
DB2
CICS
IMS
MQ
NETWORK
CERTIFICATE

Registramos.

Aprovamos.

Testamos.

Ou deveríamos.

Mas Red Team acrescenta outra pergunta:

O que mais mudou como consequência dessa mudança?

Imagine:

PRIMARY LINK DOWN

Temos backup.

Ótimo.

Então:

BACKUP LINK DEGRADED

Ainda funciona.

Então:

MONITORING DELAY

Ainda funciona.

Então:

SECURITY ALERT

Provavelmente falso positivo.

Então alguém diz:

BYPASS

Separadamente:

LINK FAILURE       = manageable
BACKUP DEGRADED    = manageable
MONITORING DELAY   = manageable
ALERT              = manageable
BYPASS             = manageable

Juntos:

FAILURE
+
DEGRADATION
+
BLINDNESS
+
ALERT
+
BYPASS
=
CRITICAL STATE

Esse é o filme que a fotografia não mostra.

---

🧀 CAPÍTULO 10 — O queijo suíço chegou à LPAR

Existe uma metáfora maravilhosa para isso: o Swiss Cheese Model.

Imagine várias barreiras.

IDENTITY
████████○████

NETWORK
███○█████████

RACF
█████████○███

APPLICATION
█████○███████

MONITORING
██○██████████

Cada camada possui imperfeições.

Normalmente os buracos não se alinham.

Uma camada compensa a outra.

Mas existe uma condição perigosa:

○
○
○
○
○
│
▼
INCIDENT

Diabolik não precisa destruir todas as fatias.

Precisa encontrar o momento em que os buracos se alinham.

Essa é uma maneira extraordinária de ensinar defesa em profundidade.

---

💥 CAPÍTULO 11 — Ataque a redundância

Temos:

LPAR A
LPAR B

Excelente.

Mas:

LPAR A ─┐
        ├── DEPENDENCY X
LPAR B ─┘

Temos realmente redundância?

Talvez tenhamos dois componentes com single point of failure compartilhado.

Isso aparece em inúmeras arquiteturas:

2 SERVERS
1 NETWORK

2 APPLICATIONS
1 DATABASE

2 LINKS
1 PROVIDER

2 ADMINS
1 PRIVILEGED ACCOUNT

2 SYSTEMS
1 CERTIFICATE

Diabolik procura exatamente isso.

Não necessariamente:

WHAT IS MISSING?

Mas:

WHAT DO ALL THESE THINGS
SECRETLY DEPEND ON?

Essa pergunta deveria estar pendurada em toda War Room.

---

🧠 CAPÍTULO 12 — Normalization of Deviance

Agora aparece um inimigo extremamente humano.

Primeiro:

"Hoje vamos fazer uma exceção."

Nada acontece.

Depois:

"Fizemos isso semana passada."

Nada acontece.

Mais tarde:

"Fazemos sempre assim."

Finalmente:

"Nem sei por que existe essa regra."

Parabéns.

A exceção virou processo.

Isso é normalização do desvio.

E existe um erro lógico perigosíssimo associado:

FIZEMOS 100 VEZES
E NADA ACONTECEU

Portanto:

É SEGURO

Não.

A conclusão correta é:

100 EXECUÇÕES
SEM INCIDENTE

Somente isso.

Ausência histórica de desastre não prova ausência de risco.

---

🛑 CAPÍTULO 13 — Quem pode apertar STOP?

Essa talvez seja uma das perguntas mais importantes de toda esta história.

Imagine:

NORMAL OPERATION
       ↓
     CHANGE
       ↓
  RISK INCREASE
       ↓
       ???

Quem pode dizer:

STOP

?

Existe autoridade?

Existe procedimento?

Existe pressão para continuar?

O operador consegue interromper uma operação crítica?

O gerente aceitará?

O negócio pressionará?

Existe escalation path?

Esse componente organizacional pode ser mais importante que determinado produto de cybersecurity.

O fluxo saudável seria:

CHANGE DETECTED
       ↓
     STOP
       ↓
    ASSESS
       ↓
  RECALCULATE
       ↓
   ┌───┴───┐
   ▼       ▼
CONTINUE  ABORT

Não:

CHANGE
 ↓
"VAI ASSIM MESMO"

---

⏳ CAPÍTULO 14 — Temporal Attack Surface

Aqui está um conceito delicioso para nossa investigação.

Superfície de ataque normalmente é apresentada como:

PORTS
APIs
SERVICES
USERS
DEVICES
NETWORKS

Mas existe também uma dimensão temporal.

Imagine:

00:00 ───────────────────────── 23:59
                 │
             03:17
                 │
          ATTACK WINDOW

Talvez durante alguns minutos aconteçam simultaneamente:

CHANGE WINDOW
+
REDUCED STAFF
+
DEGRADED CONTROL
+
PRIVILEGED ACTIVITY
+
MONITORING NOISE

Às 09:00 alguém audita:

RACF.......... OK
NETWORK....... OK
CICS.......... OK
DB2........... OK
MONITORING.... OK

Tudo verde.

Mas isso é uma fotografia das 09:00.

O incidente ocorreu às 03:17.

Precisamos reconstruir:

02:55
03:01
03:07
03:12
03:16
03:17
03:18
03:25

Agora temos um filme.

---

🕵️ CAPÍTULO 15 — Diabolik procura combinações

Uma auditoria convencional pode produzir:

CONTROL A = PASS
CONTROL B = PASS
CONTROL C = PASS
CONTROL D = PASS

Diabolik pergunta:

A + B + C + D = ?

Melhor ainda:

A DEGRADED
+
B BYPASSED
+
C DELAYED
+
D MISINTERPRETED
=
?

Esse é o coração do exercício.

Não testar apenas controles.

Testar interações entre controles.

---

🔬 CAPÍTULO 16 — Como transformar isso em exercício defensivo

Uma organização pode estruturar um exercício autorizado sem sair tentando "hackear tudo".

Primeiro:

1. IDENTIFY ASSETS

Quais serviços não podem parar?

Depois:

2. MAP TRUST

Quem e o que possui acesso?

Depois:

3. MAP DEPENDENCIES

De que cada componente depende?

Depois:

4. IDENTIFY ASSUMPTIONS

O que estamos assumindo que nunca falhará?

Depois:

5. CREATE SAFE SCENARIOS

Por exemplo:

E se o link primário desaparecer?

E se uma conta privilegiada precisar ser bloqueada?

E se o SIEM ficar temporariamente indisponível?

E se o operador principal não estiver presente?

E se uma mudança emergencial acontecer?

E se um fornecedor estiver indisponível?

E se o segundo caminho compartilhar a mesma dependência?

Depois:

6. OBSERVE RESPONSE

Finalmente:

7. IMPROVE CONTROLS

Esse é Red Team gerando engenharia.

Não espetáculo.

---

🖥️ CAPÍTULO 17 — O COBOL também entra na investigação

Nosso programador COBOL iniciante talvez esteja pensando:

— Mas eu apenas programo.

Não existe "apenas programo" em sistemas críticos.

Imagine:

IF AUTHORIZED
    PERFORM UPDATE-ACCOUNT
END-IF.

A pergunta tradicional é:

AUTHORIZED funciona?

Red Team pergunta:

Quem determina AUTHORIZED?

De onde vem esse estado?

Ele pode ficar obsoleto?

Existe contexto?

Existe logging?

Existe override?

Quem aprova?

O que acontece em erro?

FAIL OPEN ou FAIL CLOSED?

Uma pequena condição COBOL pode representar uma enorme decisão de negócio.

Por isso segurança não termina no RACF.

Ela atravessa aplicação, dados e processo.

---

🧪 CAPÍTULO 18 — O teste mais perigoso é o pressuposto

Faça uma reunião.

Pergunte:

O que nunca pode acontecer aqui?

Alguém responderá:

"Os dois links nunca cairão juntos."

Anote.

Outro:

"Ninguém compartilha essa conta."

Anote.

Outro:

"Produção nunca recebe alteração sem aprovação."

Anote.

Outro:

"Se o monitoramento parar, perceberemos."

Anote.

Outro:

"Nosso fornecedor cuida disso."

Circule duas vezes.

Essas frases são excelentes candidatas para exercícios defensivos.

Red Team é, em grande parte, uma máquina de transformar:

EU ACHO

em:

NÓS TESTAMOS

---

🎩 CAPÍTULO 19 — O Easter Egg das 03:17

Nos artigos Bellacosa Mainframe, 03:17 aparece quando alguma coisa resolveu acontecer justamente na hora em que ninguém queria.

Aqui ele ganha significado especial.

Às 03:17 não precisamos imaginar um invasor cinematográfico digitando furiosamente.

Podemos imaginar:

03:17:00 CONTROL A DEGRADED

03:17:03 DEPENDENCY B UNAVAILABLE

03:17:07 AUTOMATION RETRY

03:17:12 OPERATOR OVERRIDE

03:17:18 SECURITY EVENT

03:17:21 ALERT DELAYED

Diabolik não criou necessariamente nenhuma dessas condições.

Ele apenas adoraria descobrir que elas podem coexistir.

E esse é o Easter Egg:

O momento mais perigoso de uma arquitetura talvez não seja quando alguma coisa quebra. É quando várias coisas continuam funcionando mal o suficiente para ninguém decidir parar.

---

🕶️ CAPÍTULO 20 — A verdadeira lição de Diabolik

Diabolik não deveria nos ensinar a ser criminosos.

Como metáfora de Red Team, deveria ensinar-nos a pensar como adversários para construir sistemas melhores.

Ele não pergunta apenas:

COMO QUEBRO O RACF?

Pergunta:

POR QUE PRECISARIA QUEBRÁ-LO?

Não:

COMO DERRUBO A REDUNDÂNCIA?

Mas:

ELA É REALMENTE INDEPENDENTE?

Não:

COMO ENGANAR O OPERADOR?

Mas:

O PROCESSO DEPENDE DEMAIS DE UMA PESSOA?

Não:

COMO DESATIVAR O ALERTA?

Mas:

O QUE ACONTECE QUANDO O ALERTA
APARECE NO PIOR MOMENTO POSSÍVEL?

Essa mudança de mentalidade é enorme.

---

☕ EPÍLOGO — O mainframe que confiava demais

Às 03:17 daquela noite imaginária, nosso mainframe não estava sem segurança.

Esse é justamente o problema.

Ele possuía:

RACF
SIEM
MFA
NETWORK SECURITY
SEGREGATION
CHANGE MANAGEMENT
BACKUP
REDUNDANCY
MONITORING
PROCEDURES

Tudo existia.

Mas segurança não é a soma dos produtos instalados.

Segurança é o comportamento da arquitetura quando o mundo deixa de colaborar com nossas premissas.

É por isso que Red Team importa.

Blue Team pergunta:

Estamos detectando ataques?

Purple Team aproxima ataque e defesa.

Auditoria pergunta:

Os controles estão implementados?

Operações pergunta:

O serviço está disponível?

Risk Management pergunta:

Qual é nossa exposição?

E nosso Diabolik imaginário entra silenciosamente na War Room, olha para aquele enorme painel verde e faz outra pergunta:

"Qual dessas coisas verdes precisa ficar amarela para fazer as outras perderem valor?"

Silêncio.

Essa é a pergunta.

Porque o adversário sofisticado não precisa derrotar todas as nossas defesas.

Não precisa derrubar o IBM Z.

Não precisa destruir RACF.

Não precisa comprometer cada aplicação.

Não precisa vencer cada operador.

Pode precisar apenas encontrar:

FAILURE
+
CHANGE
+
EXCEPTION
+
TRUST
+
PREDICTABILITY
+
TIMING

e esperar que essas condições se encontrem.

Por isso eu resumiria toda a filosofia do Bellacosa Red Team Mainframe numa única equação:

SECURITY ≠ CONTROLS

Segurança real é:

SECURITY =
CONTROLS
+
CONTEXT
+
RESILIENCE
+
OBSERVABILITY
+
SEGREGATION
+
GOVERNANCE
+
ABILITY TO STOP

E o Risk Scoring completa:

RISK = RISK(t)

O risco de ontem não é necessariamente o risco de agora.

O usuário continua sendo o mesmo.

O programa COBOL continua sendo o mesmo.

A LPAR continua sendo a mesma.

O RACF continua sendo o mesmo.

Mas alguma coisa mudou.

E CHANGE pode transformar uma arquitetura.

Essa talvez seja a maior lição de Diabolik para quem trabalha com IBM Mainframe:

Não procure somente a vulnerabilidade. Procure a combinação de condições que transforma controles individualmente fortes em uma arquitetura coletivamente fraca.

Porque uma fortaleza não precisa perder todas as muralhas para ser penetrável.

Basta existir uma noite em que a ponte esteja abaixada, o guarda esteja olhando para outro lado, a contingência tenha sido improvisada e alguém diga:

"Está funcionando.

Pode continuar."

E, em algum lugar da War Room, o relógio muda silenciosamente para:

03:17

Diabolik sorri.

O Red Team anota.

E o Blue Team, na manhã seguinte, transforma aquela descoberta em uma arquitetura melhor.

 

☕ Um Café no Bellacosa Mainframe

Spy vs. Spy no z/OS: Red Team vs. Blue Team e o ABEND que Quase Comeu o Banco

💣 Dois espiões. Um Sysplex. Um RACF. Quatro milhões de logs. Nenhuma confiança. E um operador que só queria tomar café.

Existe uma antiga regra da computação corporativa que provavelmente deveria estar escrita na entrada de todo datacenter:

Se existe uma maneira absurdamente improvável de alguma coisa dar errado, alguém eventualmente colocará aquilo em produção.

No mundo do mainframe, entretanto, existe uma segunda regra.

Se alguém colocar aquilo em produção, provavelmente haverá um SYSOUT explicando exatamente o que aconteceu.

O problema será encontrar o maldito SYSOUT.

E foi exatamente nesse ponto que começou a guerra.

De um lado estava o Red Team.

Casaco vermelho imaginário, sorriso suspeito, criatividade questionável e uma convicção quase religiosa de que qualquer sistema pode ser quebrado se você fizer perguntas suficientemente inconvenientes.

Do outro estava o Blue Team.

Casaco azul igualmente imaginário, três consoles SDSF abertos, acesso ao SIEM, uma quantidade industrial de café e a certeza de que existe um log para tudo.

Mesmo que esteja num dataset criado em 1997.

Em uma fita.

Guardada por alguém chamado Geraldo.

Que se aposentou em 2011.

Era, portanto, inevitável.

Spy vs. Spy havia chegado ao IBM Z.

---

🕵️ 1. Os dois espiões entram no Sysplex

Imagine um ambiente corporativo clássico:

                    INTERNET
                       |
                   FIREWALL
                       |
                      DMZ
                       |
          +------------+------------+
          |                         |
    z/OS Connect                    MQ
          |                         |
          +------------+------------+
                       |
                IBM Z / z/OS
                       |
        +--------------+--------------+
        |              |              |
       CICS           IMS            APIs
        |              |              |
        +--------------+--------------+
                       |
                      Db2
                       |
              DADOS DA EMPRESA

Para um arquiteto, isto é um diagrama.

Para o Blue Team, é superfície a defender.

Para o Red Team, é um cardápio.

O espião vermelho olha para aquilo e pensa:

"Por onde eu entraria?"

O azul olha para a mesma arquitetura e pensa:

"Por onde ele tentaria entrar?"

Parece a mesma pergunta.

Não é.

Essa pequena diferença contém praticamente toda a filosofia de Red Team e Blue Team.

---

🔴 2. O Spy Vermelho aparece

Nosso Red Spy recebe sua missão.

O alvo não é:

"Hackear o mainframe."

Isso seria uma descrição digna de filme ruim de Hollywood.

A missão real parece mais com:

Avaliar se um atacante que comprometa determinadas credenciais corporativas poderia alcançar funções sensíveis executadas no ambiente z/OS.

Agora temos algo interessante.

Existe escopo.

Existem Rules of Engagement.

Existem sistemas autorizados.

Existem horários.

Existem técnicas proibidas.

Porque Red Team profissional não significa sair detonando coisas.

Significa reproduzir comportamento adversarial de maneira controlada.

O objetivo não é destruir o castelo.

É descobrir se alguém conseguiria entrar nele.

E, idealmente, fazer isso sem derrubar a ponte levadiça, incendiar o fosso e desligar o CICS às 14h37 de uma sexta-feira.

---

🔵 3. O Spy Azul já está desconfiado

O Blue Team recebe outra missão:

Detectar, investigar, conter e compreender atividades potencialmente hostis dentro do ambiente.

Ele abre suas armas.

Não são pistolas.

São coisas muito mais perigosas.

SMF
RACF
SDSF
SIEM
Syslog
NetView
OMEGAMON
zSecure
AT-TLS logs
CICS logs
MQ logs
Db2 traces
USS logs
network telemetry

O Red Spy olha aquilo e pensa:

"Preciso não aparecer."

O Blue Spy pensa:

"Ele já apareceu. Só preciso descobrir onde."

Primeiro quadro da história.

O espião vermelho coloca uma bomba.

O azul encontra a bomba.

O vermelho percebe que o azul encontrou.

O azul percebe que o vermelho percebeu que ele encontrou.

E alguém no meio disso abre um Sev1.

---

🧭 4. ROUND ONE — Reconnaissance

Nenhum atacante competente começa digitando:

TSO HACK

Embora isso facilitasse bastante o trabalho do Blue Team.

O ataque começa com reconhecimento.

O Red Team tenta compreender o ambiente.

Tecnologias.

Interfaces.

Domínios.

Aplicações.

Padrões de nomes.

APIs.

Funcionários.

Documentação pública.

Mensagens de erro.

Endpoints.

Talvez encontre referências como:

CICS
IMS
Db2
MQ
z/OS Connect
RACF
TSO
ISPF

Para alguém sem experiência, isso é sopa de letrinhas.

Para quem conhece mainframe, cada sigla conta uma história.

Se existe MQ, existem canais.

Se existe CICS, existem transações.

Se existe z/OS Connect, provavelmente existem APIs chegando ao ambiente tradicional.

Se existe USS, existe um mundo POSIX vivendo dentro do z/OS.

E se existe RACF...

O Red Spy sorri.

O Blue Spy também.

Por razões completamente diferentes.

---

🔵 Blue Team contra-ataca

O Blue Team pergunta:

Que atividade externa antecedeu isso?

Houve enumeração?

Houve múltiplas requisições incomuns?

Apareceram erros repetidos?

Existem padrões nos logs?

O SIEM começa a enxergar peças.

IP → endpoint
endpoint → aplicação
aplicação → identidade
identidade → recurso

A diferença entre log e telemetria útil começa exatamente aqui.

Log sozinho é evidência.

Correlação transforma evidência em história.

---

💣 5. ROUND TWO — Credential Attack

O Red Spy encontra uma identidade válida.

Não importa para nossa história exatamente como.

Talvez phishing autorizado.

Talvez uma credencial de laboratório.

Talvez um cenário previamente preparado.

O importante é que agora temos:

USERA

E USERA funciona.

O Red Team comemora durante aproximadamente quatro segundos.

Porque uma credencial válida não significa acesso ilimitado.

É aqui que RACF entra no palco carregando uma enorme placa escrita:

ICH408I

Poucas mensagens conseguem destruir a autoestima de um atacante com tanta eficiência.

O Red Spy tenta um recurso.

ACCESS INTENT(READ)

Negado.

Outro.

Negado.

Outro.

Negado.

O Blue Spy começa a observar várias negativas associadas ao mesmo usuário.

Sua sobrancelha azul metafórica sobe.

Um usuário normal pode receber uma negativa.

Duas talvez.

Dezessete acessos negados em recursos completamente diferentes?

Hmm.

---

🪜 6. ROUND THREE — Privilege Escalation

O Red Team agora quer descobrir uma coisa muito mais interessante:

USERA consegue tornar-se algo maior do que deveria?

Este é um dos pontos centrais de qualquer avaliação séria.

Porque muitas invasões importantes não acontecem devido a uma única vulnerabilidade espetacular.

Elas acontecem por encadeamento.

Um pequeno acesso permite outro.

O segundo permite um terceiro.

O terceiro revela uma configuração.

A configuração abre outra possibilidade.

De repente:

baixo privilégio
      ↓
configuração esquecida
      ↓
permissão excessiva
      ↓
credencial técnica
      ↓
recurso sensível

Nenhuma peça isolada parecia catastrófica.

Juntas formaram uma escada.

O Spy Vermelho sobe.

O Spy Azul começa a juntar eventos.

---

🔵 7. O Blue Team descobre a diferença entre EVENTO e INCIDENTE

Imagine o seguinte:

Às 13:41:

USERA acessa recurso X

13:43:

USERA acessa recurso Y

13:45:

USERA executa função Z

Separadamente, talvez ninguém ligasse.

Mas o Blue Team possui contexto.

USERA pertence à contabilidade.

Contabilidade não executa Z.

Contabilidade nunca acessou Y.

E Z aconteceu dois minutos depois de Y.

Agora não temos três eventos.

Temos uma narrativa.

O analista azul coloca seus óculos imaginários de Sherlock Holmes.

Ou talvez de Capitão Haddock depois de descobrir que alguém mexeu em seu whisky.

---

🚶 8. ROUND FOUR — Lateral Movement

O Spy Vermelho conseguiu entrar em algum lugar.

Mas atacantes raramente querem permanecer onde chegaram.

Eles querem descobrir:

"Onde mais essa identidade funciona?"

Surge então o movimento lateral.

Em ambientes distribuídos isso significa frequentemente servidor → servidor.

No ecossistema mainframe a história pode assumir formas muito diferentes.

API
 ↓
z/OS Connect
 ↓
CICS
 ↓
programa
 ↓
Db2

Ou:

aplicação
 ↓
MQ
 ↓
queue
 ↓
consumer
 ↓
transação

Ou:

USS
 ↓
processo
 ↓
dataset
 ↓
job

E aqui aparece uma lição importante.

O mainframe moderno não é uma máquina isolada em uma caverna.

Ele é parte de um ecossistema.

APIs.

Cloud.

Containers.

Aplicações móveis.

Middleware.

Mensageria.

Linux.

Internet.

Parceiros.

Portanto, defender IBM Z significa entender os caminhos que chegam ao IBM Z.

---

👻 9. ROUND FIVE — Persistence

O Red Spy agora pensa como qualquer vilão de desenho animado competente:

"E se me expulsarem?"

Entrar uma vez é bom.

Conseguir voltar é melhor.

O Red Team testa se existem mecanismos capazes de produzir persistência.

Não necessariamente implantando alguma coisa destrutiva.

O objetivo pode simplesmente ser determinar se controles existentes permitiriam que determinado tipo de persistência fosse possível.

O Blue Team está procurando justamente aquilo.

Novos objetos.

Alterações incomuns.

Mudanças de privilégios.

Execuções fora de padrão.

Jobs inesperados.

Mudanças em datasets sensíveis.

Relacionamentos RACF novos.

Comportamento diferente do baseline.

E então acontece a tradicional cena Spy vs. Spy.

O vermelho abre uma porta.

Atrás dela está o azul.

O azul abre outra.

Atrás dela está o vermelho.

Os dois apontam um para o outro.

Atrás dos dois existe um auditor com uma planilha Excel.

---

🥸 10. ROUND SIX — Evasion

Agora começa uma das partes mais divertidas de qualquer Red Team.

O vermelho sabe que existem sensores.

Então começa a pensar:

"Como minhas ações aparecem para quem está olhando?"

Isso muda completamente o jogo.

O Red Team deixa de avaliar apenas:

"Consigo fazer?"

E começa a testar:

"Consigo fazer sem ser percebido?"

Esse ponto distingue avaliações superficiais de exercícios maduros.

Porque um controle pode impedir uma ação.

Excelente.

Mas talvez não detecte tentativas.

Outro controle pode não impedir completamente algo, porém gerar um alerta instantâneo.

Também excelente.

Segurança não é uma muralha única.

É uma combinação de:

PREVENT
DETECT
RESPOND
RECOVER

O Spy Vermelho procura os espaços entre essas camadas.

O Azul procura exatamente os mesmos espaços.

---

📟 11. Blue Team abre o SDSF

Enquanto isso, em algum lugar do datacenter...

Um operador olha para:

DA
ST
H
LOG

E pergunta:

"Por que diabos existem tantos jobs desse usuário?"

O silêncio toma conta da sala.

O Red Spy sente uma perturbação na Força.

O Blue Spy sorri.

Porque uma característica fascinante do mainframe é que muitas atividades acabam produzindo rastros extremamente ricos.

SMF é praticamente a caixa-preta do ecossistema z/OS.

É possível registrar uma quantidade impressionante de informações sobre:

• execução;

• autenticação;

• datasets;

• jobs;

• subsistemas;

• rede;

• segurança;

• utilização;

• desempenho.

O problema moderno raramente é:

"Não temos logs."

O problema frequentemente é:

"Temos tantos logs que ninguém percebeu que a invasão estava gritando há três horas."

---

💥 12. ROUND SEVEN — O ataque chega perto do prêmio

Finalmente o Red Team encontra um caminho plausível até o objetivo estabelecido no exercício.

Talvez seja acesso a determinado dado.

Talvez execução de determinada função.

Talvez uma transação crítica.

Talvez o comprometimento de uma identidade privilegiada simulada.

O Red Spy chega diante da porta.

Na porta está escrito:

PROD.PAYMENT.CRITICAL

Ele toca a maçaneta.

E então...

ALERTA.

O Blue Team detectou.

Ou não.

É justamente por isso que o exercício existe.

Se detectou, queremos saber:

Quanto tempo demorou?

Qual telemetria disparou?

O alerta tinha contexto suficiente?

O analista entendeu?

Escalou corretamente?

Conseguiu correlacionar?

A contenção funcionou?

E se NÃO detectou...

Parabéns.

Acabamos de encontrar algo extremamente valioso.

Não um motivo para demitir alguém.

Uma oportunidade para melhorar o sistema antes que o Spy Vermelho seja substituído por um atacante real.

---

🟣 13. Entra o personagem secreto: Purple Team

E então ocorre a maior heresia de toda a guerra.

O Red Spy e o Blue Spy param de tentar explodir um ao outro.

Sentam na mesma mesa.

Surge o Purple Team.

Ele pergunta ao Red:

O que você fez?

Depois pergunta ao Blue:

O que você viu?

Red:

Executei A.

Blue:

Não vimos.

Purple:

Excelente. Vamos descobrir por quê.

Red:

Depois fiz B.

Blue:

Isso gerou alerta.

Purple:

Quanto tempo?

Blue:

Quatro minutos.

Red:

Interessante.

Purple:

Podemos reduzir?

De repente Spy vs. Spy vira laboratório.

É aqui que exercícios maduros começam realmente a gerar valor.

---

🧠 14. O verdadeiro objetivo do Red Team

Existe um erro clássico:

"O Red Team venceu porque conseguiu entrar."

Não.

Outro erro:

"O Blue Team venceu porque bloqueou tudo."

Também não.

O exercício não é futebol.

Não existe placar:

RED TEAM   3
BLUE TEAM  2

Se o Red Team encontra uma falha séria antes de um atacante real:

a organização venceu.

Se o Blue Team detecta uma técnica que nunca havia testado:

a organização venceu.

Se ambos descobrem que determinada telemetria não está sendo coletada:

a organização venceu.

A pior situação é aquela em que ninguém testa nada e todos acreditam que tudo funciona.

---

🛡️ 15. Mainframe não é invulnerável

Existe outra lenda corporativa particularmente perigosa:

"Mainframe é impossível de hackear."

Não.

IBM Z possui uma arquitetura de segurança extremamente madura.

Mas segurança nunca depende apenas da plataforma.

Existe configuração.

Existem pessoas.

Existem aplicações.

Existem credenciais.

Existem integrações.

Existem APIs.

Existem permissões históricas.

Existem processos.

E existe o componente mais imprevisível já implantado em qualquer infraestrutura:

HUMAN.USER

Esse componente não possui PTF.

---

🧩 16. A diferença brutal do ambiente legado

Agora chegamos ao detalhe que torna Red Team em mainframe particularmente interessante.

Você encontra coisas que existem há décadas.

Datasets criados em eras geológicas diferentes.

Naming conventions fossilizadas.

Aplicações COBOL escritas quando Michael Jackson ainda lançava discos.

REXX que ninguém sabe quem escreveu.

CLIST aparentemente mantido por magia negra.

JCL copiado desde a administração Reagan.

Perfis RACF herdados de reorganizações corporativas que ninguém mais lembra.

Jobs chamados:

TEMP01
TEMP02
TEMP03
TEMP03B
TEMP03B_NEW
TEMP03B_NEW2
TEMP03B_NEW2_OK

E todos estão em produção.

Desde 2004.

Não mexa.

Ninguém sabe o que acontece.

---

☢️ 17. O Spy Vermelho encontra TEMP03B_NEW2_OK

O Red Spy observa o nome.

O Blue Spy observa o Red Spy observando o nome.

Ambos sabem.

Existe alguma coisa ali.

Talvez nada.

Talvez o sistema financeiro inteiro dependa disso.

Ninguém ousa executar:

DELETE

Existe uma velha superstição mainframeira:

Quanto mais ridículo o nome de um dataset, maior a probabilidade de ele ser crítico para o negócio.

Isso nunca foi cientificamente comprovado.

Mas nenhum veterano pretende testar.

---

🔎 18. IOC não basta — comportamento importa

Outra lição do confronto:

Não basta procurar endereços IP ruins.

Não basta procurar hashes.

Não basta procurar assinaturas conhecidas.

Um atacante usando uma identidade válida pode parecer perfeitamente legítimo.

A detecção moderna precisa considerar comportamento.

Imagine:

USERA

normalmente:

08:00 login
08:10 aplicação financeira
12:00 almoço
17:30 logout

Subitamente:

02:37 login
02:38 enumeração
02:42 dezenas de recursos
02:49 execução incomum
02:52 novo acesso privilegiado

Talvez USERA tenha desenvolvido uma súbita paixão por administração de sistemas às três da manhã.

Ou talvez tenhamos um problema.

---

🚨 19. O momento da contenção

O Blue Team decide agir.

Conta suspensa.

Sessão encerrada.

Credencial revogada.

Acesso bloqueado.

Sistema isolado conforme o cenário.

O Spy Vermelho vê a porta fechar.

Sorri.

Porque aquela era exatamente a pergunta do exercício:

O Blue Team conseguiria perceber e interromper o ataque antes do objetivo final?

Resposta:

Sim.

Ou talvez:

Quase.

Ou:

Não.

Todas são respostas úteis.

Desde que sejam transformadas em ação.

---

📜 20. Depois da explosão vem o relatório

Agora aparece o verdadeiro chefe final de qualquer operação.

Não é RACF.

Não é SIEM.

Não é CICS.

Não é Db2.

É o:

RELATÓRIO TÉCNICO

O Red Spy olha assustado.

O Blue Spy começa a suar.

O Purple Team abre o Word.

Todos percebem que talvez fosse mais fácil enfrentar hackers.

O documento terá:

1. Executive Summary

2. Scope

3. Rules of Engagement

4. Architecture

5. Methodology

6. Timeline

7. Attack Paths

8. Findings

9. Detection Results

10. Response Results

11. Evidence

12. Risk Classification

13. Recommendations

14. Remediation Plan

15. Retest Plan

E principalmente:

evidência.

Nada de:

"Achamos que talvez pudesse acontecer."

Queremos:

timestamp
user
resource
event
system
evidence
impact
control

Porque segurança sem evidência vira opinião.

---

🧪 21. O Retest

Meses depois os dois espiões voltam.

O Red Team tenta novamente.

A antiga porta não existe mais.

O Blue Team criou novas regras.

Novos alertas.

Melhor correlação.

Permissões foram corrigidas.

A telemetria foi ampliada.

O Red Spy tenta A.

Bloqueado.

Tenta B.

Detectado.

Tenta C.

O SOC recebe alerta.

Tenta D.

Um analista liga:

"Olá. Nós sabemos o que você está fazendo."

Silêncio.

O Red Spy fecha o terminal.

O Blue Spy toma café.

---

🏆 22. Quem ganhou?

Resposta:

os dois.

Mais precisamente:

ganhou a organização.

Porque o objetivo de segurança não é construir a ilusão de que ataques nunca acontecerão.

O objetivo é tornar o ambiente:

difícil de comprometer
        +
difícil de explorar
        +
difícil de permanecer
        +
fácil de observar
        +
rápido de responder
        +
capaz de recuperar

Esse é o jogo.

---

🧓 23. E o mainframe?

No canto do datacenter está um IBM Z.

Ele acompanhou toda a confusão.

Red Team.

Blue Team.

Purple Team.

SOC.

SIEM.

Threat Intelligence.

MITRE ATT&CK.

Zero Trust.

APIs.

Cloud.

IA.

O mainframe olha para todos.

Ele já viu modas passarem.

Client-server.

SOA.

Web 2.0.

Cloud.

Microservices.

DevOps.

AI.

Alguém pergunta:

"Você está bem?"

O z/OS responde:

IEF404I JOB ENDED
MAXCC=0000

E continua processando quatro bilhões de transações como se nada tivesse acontecido.

---

☕ Epílogo — Spy vs. Spy, edição Mainframe

Na última cena, o Spy Vermelho deixa uma caixa sobre a mesa do Blue Team.

O Blue abre cuidadosamente.

Dentro existe apenas um bilhete:

"Você esqueceu uma regra."

O Blue imediatamente verifica RACF.

Nada.

SIEM.

Nada.

CICS.

Nada.

MQ.

Nada.

Firewall.

Nada.

Ele vira o bilhete.

No verso:

"A máquina pode ser extraordinariamente segura.
O ambiente só será tão seguro quanto aquilo que vocês lembraram de configurar, monitorar e testar."

O Blue Spy sorri.

Coloca outro bilhete dentro da caixa.

Entrega de volta ao Red.

O vermelho abre.

Está escrito:

"Nós vimos você deixar esta caixa."

Silêncio.

Os dois se encaram.

Em algum lugar do Sysplex aparece:

ICH408I
USER(REDSPY )
ACCESS DENIED

O Spy Azul começa a rir.

O vermelho puxa uma enorme bomba preta de desenho animado de dentro do casaco.

No pavio está escrito:

//EXPLODE JOB ...

Antes que possa acendê-la, JES2 responde:

JCL ERROR

O vermelho olha incrédulo.

O azul cai da cadeira.

E assim termina mais um dia no datacenter.

Porque depois de sessenta anos de evolução tecnológica existe uma verdade que continua absolutamente universal:

você pode enfrentar Red Team, Blue Team, ransomware, engenharia social, ataques sofisticados e agentes de ameaça financiados por Estados.

Mas cedo ou tarde...

todo mundo perde uma batalha para um erro de JCL.

☕ Bellacosa Mainframe

Onde Red Team tenta entrar, Blue Team tenta descobrir, Purple Team tenta fazer os dois conversarem — e o velho z/OS registra tudo em algum SMF que ninguém lembrou de colocar no dashboard.

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

https://eljefemidnightlunch.blogspot.com/2026/08/red-team-e-os-doze-trabalhos-de-asterix.html