Bellacosa Mainframe e a operacao ich408i red versus blue team

☕ Um Café no Bellacosa Mainframe

Operação ICH408I: Red Team versus Blue Team no z/OS

🕵️ Tintim, Milu e o estranho caso do usuário que não deveria estar autorizado

Objetivo: aprender a organizar um exercício completo de Red Team × Blue Team em ambiente IBM Z, passando por reconhecimento, identidade, RACF, datasets, USS, CICS, Db2, APIs, rede, persistência simulada, detecção, resposta, recuperação e relatório final.

Era 02:17.

O mainframe estava tranquilo.

Ou, pelo menos, apresentava aquela espécie particular de tranquilidade que só existe em computadores capazes de processar bilhões de transações enquanto metade da empresa acredita que eles estão desligados porque ninguém vê uma tela azul piscando.

No SOC, uma mensagem apareceu:

ICH408I USER(RED001 ) GROUP(REDTEAM )
  ...
  INSUFFICIENT ACCESS AUTHORITY

Tintim olhou para a tela.

Milu olhou para Tintim.

Tintim olhou novamente para a tela.

— Milu... alguém tentou acessar alguma coisa que não deveria.

Do corredor veio uma voz:

— MIL BILHÕES DE BILHÕES DE BARNACLES!

Era o Capitão Haddock.

— Invadiram o mainframe!

Tintim permaneceu calmo.

— Ainda não sabemos.

Professor Girassol apareceu segurando uma pasta.

— Excelente! Então meu teste começou.

Silêncio.

Haddock lentamente virou a cabeça.

— SEU TESTE?!

Bem-vindo ao maravilhoso mundo do:

🔴 RED TEAM × 🔵 BLUE TEAM

E à primeira regra desta história:

Um bom Red Team não começa atacando. Começa escrevendo as regras que impedem o teste de virar um incidente verdadeiro.

🗺️ 1. Antes da guerra: desenhe o mapa

Imagine o ambiente:

                    INTERNET
                       |
                  [ FIREWALL ]
                       |
                     [DMZ]
                       |
               +-------+-------+
               |               |
           z/OS Connect       MQ
               |               |
        +------+---------------+------+
        |                             |
      CICS                           IMS
        |                             |
        +-------------+---------------+
                      |
                     Db2

                IBM Z / z/OS
                      |
       +--------------+--------------+
       |              |              |
      RACF           USS            JES
       |              |              |
   IDENTIDADE      UNIX          BATCH/JCL

Mas isso ainda é incompleto.

Existem consoles, APIs, automação, FTP/SFTP, TN3270, middleware, ferramentas de administração, pipelines DevOps, contas técnicas, certificados, chaves, datasets, bibliotecas autorizadas, logs e integrações com sistemas externos.

O mainframe moderno não é uma ilha.

Ele é uma cidade.

E Red Team significa perguntar:

Por onde alguém tentaria entrar nessa cidade?

⚠️ CHECKPOINT ZERO — autorização

Antes de qualquer atividade:

Regra Bellacosa nº 1

Produção não é CTF.

Você não ganha pontos derrubando o CICS.

Você ganha uma reunião extraordinária com pessoas que conhecem palavras muito desagradáveis.

🎭 2. Os personagens

🔴 Red Team — Tintim

Curioso.

Metódico.

Faz perguntas inconvenientes.

O objetivo não é causar destruição.

É provar caminhos plausíveis de comprometimento.

Tintim pergunta:

“Se eu tivesse uma identidade válida, até onde conseguiria chegar?”

🔵 Blue Team — Capitão Haddock

Defende o ambiente.

Monitora eventos.

Investiga anomalias.

Correlaciona logs.

Tenta responder:

QUEM?
O QUÊ?
QUANDO?
ONDE?
COMO?
POR QUÊ?

E eventualmente:

QUEM FOI O INFELIZ?

🟣 Purple Team — Professor Girassol

Ele sabe o que Tintim tentou.

Ele sabe o que Haddock deveria detectar.

Sua pergunta é:

“O controle funcionou?”

Isso transforma a brincadeira de polícia e ladrão em engenharia de segurança.

📜 3. Rules of Engagement

Chamaremos de:

ROE — RULES OF ENGAGEMENT

Exemplo:

OPERATION: ICH408I

TARGET:
ZOSLAB

WINDOW:
22:00–04:00

ALLOWED:
Authentication testing
Authorization validation
Dataset access validation
USS privilege validation
API security testing
Logging validation
Network segmentation validation

FORBIDDEN:
Production disruption
Data destruction
Real customer data extraction
IPL
Destructive JCL
Security database modification
Malware deployment
Unbounded load testing

Essa última parte importa muito.

Easter egg

Se alguém sugerir:

“Vamos só testar um IPL.”

Haddock imediatamente joga a pessoa pela janela.

Metaforicamente.

O RH pediu para esclarecer isso.

🕵️ 4. Fase I — Reconnaissance

Tintim começa sem tocar no coração do sistema.

Ele quer entender a superfície exposta.

Perguntas:

Quais serviços existem?
Quais interfaces são acessíveis?
Existem APIs?
Existe TN3270?
Existe FTP?
Existe SSH?
Existe z/OSMF?
Existe z/OS Connect?
Existe MQ?
Existem aplicações web ligadas ao mainframe?

O objetivo não é atacar imediatamente.

É construir:

Attack Surface Map

🔎 5. Reconhecimento interno

Suponha que o exercício forneça uma identidade limitada:

RED001

Agora começa uma pergunta extremamente importante:

O que esse usuário consegue enxergar?

Não:

“O que deveria conseguir enxergar?”

Mas:

“O que realmente consegue?”

Essa diferença sustenta metade da segurança corporativa.

🔐 6. Identidade

Agora chegamos ao RACF — ou ao equivalente utilizado pela organização.

Tintim procura entender:

USER
 |
 +-- GROUP
 |
 +-- RESOURCE
 |
 +-- ACCESS

Os privilégios devem seguir:

NONE
READ
UPDATE
CONTROL
ALTER

conforme o tipo de recurso e política aplicável.

A pergunta fundamental:

RED001 possui somente os privilégios necessários?

🚨 CHECKPOINT 1 — identidade

O Blue Team verifica se consegue detectar:

autenticações incomuns;
falhas repetidas;
acessos fora do padrão;
utilização anormal de contas técnicas;
tentativas contra recursos protegidos;
mudanças relevantes de privilégios;
comportamento incompatível com o perfil do usuário.

Possíveis fontes incluem registros RACF/SAF e SMF conforme a configuração do ambiente.

O objetivo é correlacionar:

USER
+
TIME
+
RESOURCE
+
ACTION
+
RESULT

🐶 Milu encontra uma credencial

Milu aparece carregando um papel.

Nele está escrito:

USER=APPBAT01
PASSWORD=********

Tintim pergunta:

— Onde encontrou isso?

Milu aponta para uma biblioteca de desenvolvimento.

Silêncio.

Essa é uma simulação clássica extremamente útil.

Não coloque uma senha verdadeira.

Plante uma:

Honey Credential

Uma credencial falsa criada especificamente para detectar utilização indevida.

Se alguém tentar utilizá-la:

ALERT

E agora o Blue Team tem uma oportunidade fantástica de provar que sua telemetria funciona.

🗃️ 7. Fase II — datasets

Agora investigamos autorização sobre datasets.

Imagine:

DEV.APP.SOURCE
DEV.APP.JCL
DEV.APP.CNTL
PROD.APP.LOAD
PROD.APP.PARMLIB

Pergunta:

Um usuário de desenvolvimento consegue modificar algo que influencia produção?

Esse é um dos testes mais importantes.

💣 O JCL aparentemente inocente

Tintim encontra:

DEV.APP.JCL

O acesso é permitido.

Até aí, tudo certo.

Mas o Blue Team precisa investigar a cadeia:

USER
 ↓
JCL
 ↓
SCHEDULER
 ↓
SERVICE ACCOUNT
 ↓
PRODUCTION RESOURCE

Eis uma lição fundamental:

O privilégio real de uma identidade não é apenas aquilo que ela acessa diretamente. Também importa aquilo que executa em nome dela.

🧠 Attack Path

Representamos isso como grafo:

RED001
   |
   v
DEV.JCL
   |
   v
SCHEDULER
   |
   v
BATCHUSR
   |
   v
PROD.DATA

Individualmente, cada permissão pode parecer razoável.

Juntas?

Temos uma história completamente diferente.

🚨 CHECKPOINT 2 — batch

Blue Team procura:

submissões incomuns
jobs fora de horário
bibliotecas inesperadas
mudanças em JCL
identidades inesperadas
alterações de execução
acessos anormais a datasets

E aqui JES entra na investigação.

🐚 8. Fase III — USS

Muita gente pensa:

MAINFRAME = RACF + COBOL + JCL

Até alguém lembrar:

USS

E descobrir um UNIX inteiro vivendo dentro do z/OS.

Tintim entra no Unix System Services autorizado para o exercício.

Agora verificamos:

UID
GID
permissions
ownership
executables
scripts
configuration files
keys
environment variables

🧨 Atenção especial

Contas com privilégios elevados no USS merecem enorme atenção.

Especialmente configurações equivalentes a superuser.

O exercício deve verificar se:

ordinary user
     |
     X
     |
privileged capability

permanece realmente bloqueado.

🚨 CHECKPOINT 3 — USS

Blue Team verifica:

sessões SSH;
autenticação;
alterações de arquivos;
execução inesperada;
modificações de permissões;
utilização de identidades privilegiadas;
comportamento anormal.

🌐 9. Fase IV — APIs

Professor Girassol aparece novamente.

— O mainframe possui APIs.

Haddock:

— Claro que possui.

— E estão ligadas à Internet.

Haddock:

— ...

— Indiretamente.

Haddock:

— BARNACLES!

Bem-vindo ao mundo moderno.

🔌 z/OS Connect

Imagine:

Mobile App
    |
 API Gateway
    |
z/OS Connect
    |
   CICS
    |
   Db2

O Red Team verifica controles como:

authentication
authorization
token validation
scope
rate limiting
input validation
logging
TLS
API exposure

🧩 A pergunta venenosa

Imagine uma API:

GET /account/{id}

A aplicação verifica autenticação.

Ótimo.

Mas verifica se:

USER A

pode acessar:

ACCOUNT B

Autenticação responde:

Quem é você?

Autorização responde:

O que você pode fazer?

Confundir as duas é uma tradição informática quase tão antiga quanto colocar senha em Post-it.

🚨 CHECKPOINT 4 — API

Blue Team deveria conseguir observar:

TOKEN
 ↓
API
 ↓
IDENTITY
 ↓
TRANSACTION
 ↓
BACKEND

O sonho do investigador é acompanhar a mesma operação de ponta a ponta.

🏦 10. Fase V — CICS

Agora Tintim chega ao território onde milhões de transações podem estar acontecendo.

Aqui a regra é:

NÃO SEJA O ELEFANTE NA LOJA DE CRISTAIS.

Nada de testes indiscriminados.

Validamos controles previamente aprovados.

Perguntas:

Quem pode iniciar determinada transação?

Qual identidade chega ao backend?

Quais recursos essa transação acessa?

Existe separação entre desenvolvimento e produção?

As operações sensíveis são auditadas?

🔍 11. Fase VI — Db2

Agora temos:

APPLICATION
    |
   CICS
    |
   Db2

Tintim pergunta:

A aplicação possui mais privilégio no banco do que necessita?

Outra pergunta:

Contas técnicas possuem privilégios históricos que ninguém mais sabe explicar?

Esse fenômeno possui um nome informal:

Arqueologia de privilégios.

Permissões concedidas em 1997.

Projeto terminou em 2003.

Funcionário aposentou em 2014.

Permissão continua lá.

Porque:

"Ninguém sabe se pode remover."

👻 12. Persistence — mas simulada

Aqui temos uma regra importantíssima.

Não precisamos instalar malware para testar se detectaríamos persistência.

Podemos criar:

Synthetic Persistence Indicators

Exemplo conceitual:

TEST.PERSISTENCE.REDTEAM

ou outra alteração previamente combinada e completamente reversível.

O Blue Team precisa detectá-la.

Depois:

ROLLBACK

🎯 Truque Purple Team

Crie indicadores exclusivos:

REDTEAM-2026-001
REDTEAM-2026-002
REDTEAM-2026-003

Assim conseguimos correlacionar:

ACTION
 ↕
LOG
 ↕
ALERT
 ↕
SOC CASE

Isso facilita enormemente o relatório.

🥷 13. Evasion

Essa fase precisa ser tratada com extremo cuidado.

O objetivo seguro não é ensinar como desaparecer.

A pergunta defensiva é:

Se uma atividade produzir menos sinais do que esperamos, nossas outras fontes ainda a enxergam?

Exemplo:

CONTROL A
falhou
   |
CONTROL B
detectou
   |
CONTROL C
confirmou

Isso é:

Defense in Depth

📡 14. A sala secreta do Blue Team

Enquanto Tintim trabalha, Haddock possui dashboards.

Possíveis fontes:

SMF
RACF/SAF events
CICS logs
Db2 audit information
USS logs
network telemetry
API gateway logs
z/OSMF logs
SIEM

Tudo converge para:

             SIEM
              |
    +---------+---------+
    |         |         |
   RACF      CICS      USS
    |         |         |
   SMF       Db2       API

⏱️ 15. Métrica maravilhosa: MTTD

Mean Time To Detect

Tintim executa uma ação autorizada às:

02:17:00

O SOC percebe às:

02:24:00

Então:

MTTD = 7 minutos

🚑 MTTR

Depois:

02:24 detection
02:31 investigation
02:38 containment

Podemos medir:

Mean Time To Respond

ou métricas equivalentes definidas pela organização.

Agora Red Team deixou de ser espetáculo.

Virou dado.

🟣 16. Purple Team Matrix

A melhor tabela do exercício:

Técnica simulada	Esperávamos detectar?	Detectamos?	Alerta	Resposta
Login anormal	Sim	Sim	Sim	Sim
Dataset proibido	Sim	Sim	Sim	Sim
Honey credential	Sim	Sim	Sim	Sim
Mudança USS simulada	Sim	Não	Não	—
API irregular	Sim	Sim	Sim	Parcial

A linha mais interessante é:

SIM | NÃO

Porque encontramos um:

Detection Gap

🧪 17. Injects

Uma operação divertida pode incluir eventos roteirizados.

Inject 01

Credencial falsa encontrada.

Inject 02

Acesso negado a dataset sensível.

Inject 03

API apresenta comportamento anormal.

Inject 04

Arquivo controlado aparece no USS.

Inject 05

Job inesperado aparece no ambiente de laboratório.

O Blue Team não necessariamente sabe quando cada um acontecerá.

Mas o controlador sabe.

🧑‍⚖️ 18. Os Dupond & Dupont entram na investigação

— Descobrimos o invasor.

— Exatamente. Descobrimos o invasor.

— Foi RED001.

— Precisamente. Foi RED001.

Tintim:

— RED001 é a conta do Red Team.

Silêncio.

Dupond:

— Então capturamos o Red Team.

Dupont:

— Caso encerrado.

Eis outro ensinamento:

Detectar uma identidade não significa compreender o incidente.

Contexto importa.

📸 19. Evidence Pack

Cada ação do Red Team recebe identificação.

RT-001
RT-002
RT-003
...

Para cada uma:

Timestamp:
System:
Identity:
Action:
Expected Detection:
Observed Detection:
Evidence:
Impact:
Rollback:

Exemplo:

ID: RT-017

TIME:
02:17:34

SYSTEM:
ZOSLAB

IDENTITY:
RED001

ACTION:
Attempted access to controlled resource

EXPECTED:
RACF denial + SIEM alert

OBSERVED:
RACF denial recorded
No SIEM alert generated

RESULT:
PARTIAL FAILURE

Isso vale ouro.

🚦 20. Severity

Não classifique tudo como:

CRITICAL!!!!

Senão nada é crítico.

Uma classificação razoável pode considerar:

LIKELIHOOD
     ×
IMPACT
     =
RISK

Exemplo:

Finding	Probabilidade	Impacto	Risco
Privilégio excessivo	Alta	Alto	Crítico
Logging incompleto	Média	Alto	Alto
Conta antiga	Média	Médio	Médio
Banner informativo	Baixa	Baixo	Baixo

🧠 21. O verdadeiro prêmio: Attack Path

O finding mais poderoso geralmente não é:

“Encontramos permissão errada.”

É:

USER
 ↓
DEV RESOURCE
 ↓
AUTOMATION
 ↓
SERVICE ID
 ↓
PRODUCTION RESOURCE
 ↓
SENSITIVE DATA

Nenhum elo isoladamente parece apocalíptico.

A cadeia é que importa.

🧀 Swiss Cheese Model

Imagine cinco controles:

IDENTITY
   ↓
RACF
   ↓
APPLICATION
   ↓
DATABASE
   ↓
MONITORING

Cada um possui buracos.

O incidente acontece quando os buracos se alinham.

O     O
  O      O
     O
        O
-----------> INCIDENT

O Red Team procura alinhamentos.

O Blue Team fecha buracos.

O Purple Team verifica se eles realmente foram fechados.

🚨 22. STOP CONDITIONS

O exercício deve parar imediatamente caso exista:

instabilidade
degradação inesperada
risco a dados reais
efeito fora do escopo
impacto em clientes
comportamento não previsto
perda de observabilidade

Palavra de emergência:

HADDOCK

Se alguém disser:

HADDOCK

todos param.

Porque nenhuma vulnerabilidade vale um SEV1 real.

🧹 23. Rollback

O Red Team precisa sair sem deixar lembranças.

Checklist:

remover artefatos de teste;
invalidar credenciais temporárias;
remover certificados temporários;
restaurar configurações;
apagar dados sintéticos quando apropriado;
confirmar integridade;
registrar mudanças revertidas;
obter validação operacional.

📋 24. Relatório técnico

Estrutura sugerida:

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

👔 25. Relatório executivo

Não entregue ao diretor:

ICH408I
FACILITY
SURROGAT
APF
USS
SMF 80

e espere aplausos.

Traduza.

Em vez de:

“Encontramos autorização excessiva no recurso X.”

Explique:

“Uma conta de desenvolvimento poderia, através de uma cadeia de permissões e automação, alcançar recursos de produção além das responsabilidades previstas para sua função.”

Agora a diretoria entende.

📊 26. Scorecard

No final:

PREVENTION       82%
DETECTION        71%
INVESTIGATION    88%
CONTAINMENT      79%
RECOVERY         94%

E principalmente:

ATTACK ACTIONS:        30
DETECTED:              24
MISSED:                 6

Então perguntamos:

Por que seis passaram?

Essa pergunta vale mais do que declarar:

“O Red Team venceu.”

🔁 27. Retest

Depois das correções:

RT-017

é repetido.

Antes:

ATTACK → LOG → SILENCE

Depois:

ATTACK
  ↓
LOG
  ↓
SIEM
  ↓
ALERT
  ↓
ANALYST
  ↓
CASE

Agora temos evidência de melhoria.

🏆 28. Quem ganhou?

Tintim pergunta:

— Então o Red Team venceu?

Haddock responde:

— Detectamos quase tudo!

Professor Girassol balança a cabeça.

Nenhum dos dois venceu.

Porque Red Team contra Blue Team não deveria ser:

RED
 VS
BLUE

Deveria terminar como:

RED
 +
BLUE
 =
PURPLE

O verdadeiro adversário é:

UNKNOWN RISK

🧭 29. Operação completa

Nossa campanha pode ser resumida assim:

                 AUTHORIZATION
                      ↓
                    SCOPE
                      ↓
            RULES OF ENGAGEMENT
                      ↓
               ARCHITECTURE
                      ↓
              RECONNAISSANCE
                      ↓
                 IDENTITY
                      ↓
                   RACF
                      ↓
                 DATASETS
                      ↓
                    JES
                      ↓
                    USS
                      ↓
                   APIs
                      ↓
                  CICS/MQ
                      ↓
                    Db2
                      ↓
          CONTROLLED SIMULATIONS
                      ↓
                 DETECTION
                      ↓
                RESPONSE
                      ↓
                 ROLLBACK
                      ↓
                 EVIDENCE
                      ↓
                  REPORT
                      ↓
               REMEDIATION
                      ↓
                  RETEST

🥚 Easter Eggs do Bellacosa Mainframe

Durante o exercício, espalhe apenas em laboratório artefatos obviamente sintéticos.

Dataset:

REDTEAM.TINTIN.UNICORN

Job:

//HADDOCK JOB ...

Arquivo:

/u/redteam/milu_was_here.txt

Identificador:

GIRASSOL-42

Mensagem:

DONT_PANIC

E a honey credential pode apontar para uma identidade chamada:

ZAPHOD42

Quem acompanha o Café sabe que o número 42 jamais aparece por acidente.

☕ 30. A grande lição

Um Red Team ruim demonstra:

“Olha o que conseguimos fazer.”

Um Red Team bom demonstra:

“Aqui está o caminho pelo qual conseguimos fazer.”

Um Red Team excelente acrescenta:

“Aqui estão os controles que deveriam ter impedido ou detectado cada etapa.”

E um exercício maduro termina dizendo:

“Corrigimos. Agora vamos tentar novamente.”

Porque segurança não é possuir um RACF perfeitamente configurado.

Não é comprar um SIEM.

Não é instalar mais um produto com dashboard vermelho.

Não é produzir 847 páginas de compliance.

Segurança é conseguir responder continuamente:

QUEM pode fazer O QUÊ
       ↓
EM QUAL recurso
       ↓
ATRAVÉS DE QUAL caminho
       ↓
QUEM perceberia
       ↓
EM QUANTO tempo
       ↓
E O QUE FARÍAMOS depois?

Tintim fecha o notebook.

Milu finalmente dorme.

Professor Girassol arquiva o relatório.

Os Dupond & Dupont continuam investigando a própria conta de teste.

Haddock olha para o console.

Nenhum alerta.

Nenhum incidente.

Produção funcionando.

Ele pega o café.

— Finalmente acabou.

Nesse instante aparece:

ICH408I USER(ZAPHOD42) ...

Haddock fica imóvel.

Tintim olha para Girassol.

Girassol olha para Tintim.

Milu levanta uma orelha.

E alguém pergunta:

— Professor... ZAPHOD42 fazia parte do exercício?

Girassol consulta a planilha.

Pausa.

— Curiosamente... não.

          >>> TO BE CONTINUED <<<

☕ Bellacosa Mainframe

Porque MAXCC=0 significa apenas que o computador terminou o que você mandou fazer.

Nunca significou que você deveria ter mandado.

Para ir mais longe

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

https://eljefemidnightlunch.blogspot.com/2026/02/hackers-no-cinema-quando-hollywood.html

https://eljefemidnightlunch.blogspot.com/2024/06/sherlock-holmes-cobol-e-o-misterio-da.html

https://eljefemidnightlunch.blogspot.com/2026/08/a-causa-de-r-300-milhoes-e-o-algoritmo.html

Translate

sábado, 8 de janeiro de 2022