☕ 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 telemetryO 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 HACKEmbora 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
ISPFPara 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 → recursoA 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:
USERAE 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ívelNenhuma 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 X13:43:
USERA acessa recurso Y13:45:
USERA executa função ZSeparadamente, 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
↓
Db2Ou:
aplicação
↓
MQ
↓
queue
↓
consumer
↓
transaçãoOu:
USS
↓
processo
↓
dataset
↓
jobE 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
RECOVERO 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
LOGE 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.CRITICALEle 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 2Se 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.USEREsse 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_OKE 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:
DELETEExiste 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:
USERAnormalmente:
08:00 login
08:10 aplicação financeira
12:00 almoço
17:30 logoutSubitamente:
02:37 login
02:38 enumeração
02:42 dezenas de recursos
02:49 execução incomum
02:52 novo acesso privilegiadoTalvez 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á:
Executive Summary
Scope
Rules of Engagement
Architecture
Methodology
Timeline
Attack Paths
Findings
Detection Results
Response Results
Evidence
Risk Classification
Recommendations
Remediation Plan
Retest Plan
E principalmente:
evidência.
Nada de:
"Achamos que talvez pudesse acontecer."
Queremos:
timestamp
user
resource
event
system
evidence
impact
controlPorque 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 recuperarEsse é 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=0000E 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 DENIEDO 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 ERRORO 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
