 |
| Bellacosa Mainframe e o racf |
☕ Um Café no Bellacosa Mainframe — Especial Red Team
Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago
🦖 Como pensar Red Team em ambientes que não foram projetados com o atacante moderno como personagem principal
Imagine Ferris Bueller diante de um terminal 3270.
Tela preta.
Letras verdes.
TSO.
ISPF.
RACF.
JCL.
CICS.
Db2.
MQ.
USS.
z/OS Connect.
Zowe.
APIs.
Ferris olha.
O administrador olha para Ferris.
Ferris olha de volta.
E então vem aquela pergunta inevitável:
“Qual é o caminho mais fácil?”
Essa pergunta é essencial.
Porque quando alguém fala em “atacar mainframe”, muita gente imagina que o atacante precisa quebrar o z/OS frontalmente.
Como se a única possibilidade fosse:
Internet
↓
Hacker
↓
3270
↓
RACF
↓
z/OS
Bonito.
Cinematográfico.
Simples.
E frequentemente errado.
O mainframe moderno vive dentro de um ecossistema enorme.
Aplicações web.
APIs.
Gateways.
Pipelines.
Cloud.
Mensageria.
DevOps.
Identidades federadas.
Service accounts.
Contas técnicas.
Fornecedores.
Automação.
Integrações.
Ferris não olha apenas para a fortaleza.
Olha para as pontes.
E essa é exatamente a mentalidade de Red Team.
Bem-vindo ao décimo primeiro episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
Hoje Ferris chegou ao mainframe.
Mas talvez nunca precise realmente “hackear o mainframe”.
Talvez seja suficiente atacar:
o caminho até ele.
🔴 O mainframe pode ser extraordinariamente seguro
Vamos começar pelo óbvio.
z/OS não é um sistema operacional improvisado ontem à noite.
Décadas de maturidade.
Segurança.
Controle de acesso.
Auditoria.
Isolamento.
Processamento transacional.
Governança.
RACF.
SAF.
ACEE.
APF.
Controle de datasets.
Recursos protegidos.
Perfis.
Autorizações.
Em ambientes bem administrados, a superfície interna pode ser extremamente robusta.
Então Ferris pergunta:
“Preciso mesmo lutar com isso?”
Esse é o ponto.
Atacante eficiente não escolhe a defesa mais forte.
Escolhe o caminho mais barato.
🧠 A fortaleza não importa se existe uma ponte aberta
Imagine um castelo medieval.
Muros.
Torres.
Guardas.
Portão.
Tudo magnífico.
Mas existe:
uma ponte de serviço;
um túnel;
um fornecedor;
uma porta lateral.
Ferris não vai escalar a muralha se o entregador entra pela cozinha.
Em mainframe moderno, a “cozinha” pode ser:
API;
pipeline;
conta técnica;
ferramenta DevOps;
integração;
proxy;
jump server;
gateway.
🔐 RACF: o porteiro que precisa de contexto certo
RACF é uma peça central.
Ele controla:
usuários;
grupos;
datasets;
recursos;
acesso.
E pode ser extremamente poderoso.
Mas RACF trabalha com identidade e autorização.
Ele não lê intenção.
Se uma identidade legítima chega com permissão válida, o sistema pode autorizar.
Então a pergunta do Red Team é:
como consigo chegar com uma identidade legítima?
Essa pergunta muda tudo.
🪪 O problema não é sempre quebrar autenticação
Às vezes é:
roubar credencial;
usar credencial técnica;
explorar conta compartilhada;
abusar de sessão;
enganar operador;
explorar integração.
Ou seja:
o atacante não precisa destruir RACF.
Pode tentar convencer o ecossistema a lhe entregar uma identidade que RACF aceite.
☕ RACF não precisa falhar para o ataque funcionar
Essa frase merece destaque.
Authentication = SUCCESS
Authorization = SUCCESS
Action = ALLOWED
Tudo correto.
Só que a identidade foi comprometida.
Tecnicamente, RACF fez o trabalho certo.
O sistema global falhou antes.
Isso é Red Team.
🧠 SAF: o mecanismo de confiança
SAF permite que componentes consultem mecanismos de segurança.
Uma ideia elegante.
Aplicação pergunta:
“Este usuário pode fazer isto?”
Controle responde.
Mas novamente:
qual usuário?
Como a identidade foi construída?
De onde veio?
Foi propagada?
Foi mapeada?
Foi compartilhada?
A política pode ser perfeita.
A identidade pode estar errada.
🧬 ACEE: o contexto de segurança em memória
ACEE representa contexto de segurança associado ao usuário.
Identidade.
Grupos.
Atributos.
Permissões.
Na prática, isso significa que várias decisões dependem de um contexto de segurança já estabelecido.
Então Red Team pergunta:
“Como esse contexto nasceu?”
Porque se origem foi comprometida, o resto pode continuar funcionando normalmente.
🧨 SPECIAL: quando Ferris ganha passe VIP
Agora chegamos à palavra divertida.
RACF SPECIAL.
Autoridade poderosa.
Muito poderosa.
Uma identidade com SPECIAL pode possuir capacidades administrativas amplas dentro do RACF.
Então imagine Ferris encontrando uma conta dessas.
Não precisa “virar root”.
O mainframe não pensa exatamente assim.
Mas ele ganhou o equivalente a um passe VIP para partes críticas do controle de segurança.
E é aí que governança de privilégio vira essencial.
🔴 SPECIAL não deveria ser souvenir
Perguntas obrigatórias:
quem possui?
por quê?
há quanto tempo?
é necessário permanentemente?
há MFA?
há conta separada?
há auditoria?
há revisão periódica?
Se ninguém sabe responder...
Ferris já está sorrindo.
🧠 Standing Privilege no mainframe
Privilégio permanente é risco permanente.
Se alguém precisa de SPECIAL uma vez por mês, por que carrega isso todos os dias?
Idealmente:
conta normal para trabalho normal;
conta privilegiada para administração;
uso controlado;
registro;
aprovação quando necessário.
A velha Ferrari novamente.
🔐 PAM encontra RACF
PAM pode ajudar a controlar credenciais privilegiadas.
Checkout.
Rotação.
Sessões.
Aprovação.
Auditoria.
Isso reduz risco de credencial “eterna”.
Porque senha administrativa esquecida em script é praticamente um convite.
🧾 Credenciais técnicas: a nova chave embaixo do tapete
Service accounts.
IDs técnicos.
Usuários de aplicações.
São extremamente comuns.
E muito perigosos quando possuem privilégio excessivo.
Especialmente se:
senha não expira;
ninguém sabe dono;
conta é compartilhada;
está em script;
configuração;
arquivo;
pipeline.
Ferris não precisa convencer uma pessoa se encontrar credencial técnica.
🧠 Service account não vai ligar reclamando
Esse é o problema.
Conta humana tem comportamento.
Conta técnica pode rodar 24x7.
Então atividade maliciosa pode parecer “serviço”.
Por isso identidade técnica precisa:
escopo;
owner;
rotatividade;
monitoramento.
🦖 TSO: a porta clássica
TSO/ISPF é uma interface clássica de interação humana.
Se Ferris chega ali com credencial legítima, começa a explorar ambiente.
Datasets.
JCL.
Utilitários.
Comandos.
Mas isso ainda depende de autoridade.
RACF continua impondo limites.
Por isso atacante procura escalada.
📜 JCL: o poder de pedir ao sistema para trabalhar por você
JCL não é “apenas arquivo de lote”.
Ele descreve trabalho.
Programs.
Datasets.
Parâmetros.
Execução.
Se atacante obtém capacidade de submeter jobs com contexto privilegiado, isso pode ser extremamente relevante.
Então o Red Team pergunta:
quem pode submeter?
com qual identidade?
quais procedures?
quais bibliotecas?
quais programas?
🧠 Job autorizado pode fazer coisa indevida
Mais uma vez:
ação permitida tecnicamente.
Contexto malicioso.
Essa série inteira gira em torno disso.
Ferris não destrói o sistema.
Explora o uso legítimo.
🔐 APF: cuidado com quem pode influenciar código privilegiado
APF — Authorized Program Facility — é peça sensível.
Bibliotecas e programas autorizados podem operar com capacidades elevadas.
Isso significa que qualquer caminho que permita alterar conteúdo crítico relacionado a bibliotecas autorizadas merece atenção extrema.
O problema não é só “quem executa”.
É:
quem pode alterar aquilo que será executado com confiança elevada?
🧠 Supply chain dentro do próprio z/OS
Pense:
programa privilegiado é seguro.
Mas biblioteca foi alterada.
Ou processo de build foi comprometido.
Ou pipeline implantou coisa errada.
Você não atacou diretamente o runtime.
Atacou a cadeia de software.
Ferris adora cadeia.
🧬 USS: o mundo Unix dentro do z/OS
Unix System Services amplia capacidades.
Shell.
Filesystem.
Ferramentas.
Processos.
Integrações.
Isso é excelente.
Também significa mais superfície.
Permissões.
Arquivos.
Scripts.
Sockets.
Ferramentas open source.
Quem vem de Linux pode se sentir mais confortável ali.
Ferris talvez goste.
🔴 O atacante moderno provavelmente entende Linux
Essa é uma diferença importante.
Muita gente imagina mainframe como ambiente completamente estranho.
Mas USS aproxima certos conceitos do Unix.
Então atacante que já domina shell pode encontrar pontos familiares.
Mais uma razão para tratar USS com o mesmo rigor.
🧾 Permissões no filesystem também importam
Quem pode alterar script?
Quem pode executar?
Quem é owner?
Group?
ACL?
Se script roda com contexto poderoso, alteração indevida é perigosa.
Mesma lógica de APF.
🧠 CICS: o coração transacional
CICS é outra joia.
Milhões de transações.
Aplicações críticas.
Programas COBOL.
BMS.
Recursos.
Segurança pode controlar transações.
Mas Ferris talvez nem tente acessar CICS diretamente.
Pode entrar por:
API;
web;
middleware;
aplicação.
📡 z/OS Connect: a ponte moderna
Agora chegamos a uma ponte particularmente interessante.
z/OS Connect permite expor e consumir APIs relacionadas a aplicações z/OS.
É transformação moderna.
Integração.
Mas toda ponte cria perguntas de identidade.
Mobile
↓
API Gateway
↓
z/OS Connect
↓
CICS
↓
COBOL
Pergunte:
quem autentica?
quem autoriza?
qual identidade chega ao backend?
há mapeamento?
há conta técnica?
há log ponta a ponta?
Isso é ouro para Red Team.
🔐 Identity Propagation
Se usuário externo autentica no frontend, queremos saber como identidade chega ao mainframe.
Se tudo vira:
APIUSER
temos perda de contexto.
Backend vê aplicação, não humano.
Isso pode dificultar auditoria.
🧠 Conta técnica compartilhada apaga autoria
Depois do incidente:
— Quem fez a transação?
— APIUSER.
Obrigado.
Quem era o usuário original?
Se cadeia não preserva isso, investigação fica difícil.
🧾 End-to-end traceability
Idealmente, uma ação deveria poder ser rastreada:
usuário;
sessão;
gateway;
API;
z/OS Connect;
CICS;
Db2.
Essa linha do tempo é valiosa.
💾 Db2: a verdade continua morando em algum lugar
No final, muitos sistemas chegam ao dado.
Db2.
Dados críticos.
Financeiros.
Clientes.
Transações.
Ferris pode não querer acesso administrativo.
Talvez baste executar operação legítima que altera dado valioso.
Isso torna autorização de aplicação crucial.
🧠 SQL permitido pode ser malicioso
Se aplicação permite certa transação, o backend vai executá-la.
O ataque pode estar no contexto anterior.
Por isso proteção de dados não pode depender apenas do banco.
📬 MQ: confiança em mensagens
MQ é outro clássico.
Mensagens.
Filas.
Integrações.
Sistemas confiam em mensagens recebidas.
Então Red Team pergunta:
quem pode publicar?
quem pode consumir?
que identidade?
qual origem?
há autenticação?
há autorização?
há validação de conteúdo?
🧨 Mensagem legítima, intenção maliciosa
Se atacante consegue publicar numa fila autorizada, downstream pode processar normalmente.
De novo:
o sistema funciona.
O problema está em quem conseguiu alimentar.
🕸️ Mainframe moderno é grafo, não ilha
Imagine:
Internet
↓
WAF
↓
Web App
↓
IAM
↓
API Gateway
↓
z/OS Connect
↓
CICS
↓
Db2
Agora adicione:
Git
↓
Jenkins
↓
DBB
↓
Deploy
↓
z/OS
E:
Cloud
↓
MQ
↓
z/OS
E:
Zowe
↓
z/OSMF
↓
System Services
Ferris olha para tudo.
Não apenas para o quadrado “MAINFRAME”.
🔴 A superfície está nas integrações
Toda integração precisa responder:
quem chama?
como autentica?
o que pode fazer?
como é auditada?
qual blast radius?
Integração mal desenhada vira atalho.
🧠 Zowe: modernização também cria novos caminhos
Zowe aproxima mainframe de ferramentas modernas.
CLI.
APIs.
Explorers.
Isso é excelente para produtividade.
Mas qualquer interface nova precisa de security design.
Ferris ama conveniência sem governança.
🔐 API é porta com maçaneta bonita
API bem protegida é ótima.
API mal protegida é entrada elegante.
Authorization.
Rate limiting.
Scopes.
Token lifecycle.
Logging.
Tudo importa.
🧠 O token virou a nova senha
JWT.
OAuth.
Tokens.
Se roubados, podem fornecer acesso temporário.
Então:
expiração;
scope;
audience;
revogação;
proteção.
Ferris não precisa conhecer senha se tem token válido.
🧨 Long-lived token é Ferrari com tanque cheio
Quanto mais dura, maior janela.
Prefira tokens curtos.
Renovação controlada.
Menor exposição.
🔐 OAuth não elimina autorização backend
Outra armadilha.
“Tem OAuth.”
Ótimo.
Mas backend precisa continuar aplicar política.
Token autenticado não significa “pode tudo”.
Identity ≠ Authorization.
Abe Froman voltou.
🧠 Zowe CLI em pipeline
Agora imagine automação.
CI/CD usando CLI.
Credenciais.
Tokens.
Deploy.
Ferris olha para pipeline.
Porque quem controla pipeline pode alterar o que chega ao mainframe.
🔴 CI/CD é caminho privilegiado
DevOps moderno aproxima desenvolvimento e produção.
Isso melhora velocidade.
Mas pipeline vira infraestrutura crítica.
Pergunte:
quem altera pipeline?
quem aprova?
quem pode injetar segredo?
quem assina artefato?
quem faz deploy?
🧾 Source control também é segurança operacional
Comprometer repositório pode ser mais fácil que atacar runtime.
Se código malicioso entra “legitimamente” e é implantado por pipeline aprovado, Ferris venceu sem tocar RACF diretamente.
🧠 Supply Chain Attack mainframe edition
Developer
↓
Git
↓
Build
↓
Artifact
↓
Deploy
↓
z/OS
Ataque qualquer etapa.
Ferris procura elo mais fraco.
🔐 Code Signing
Assinatura.
Integridade.
Proveniência.
Ajudam a garantir que artefato não foi alterado.
Mas processo de assinatura também precisa proteção.
Quem controla chave?
Quem aprova?
🧠 Secrets em pipeline
Senha em Jenkins.
Token em variável.
Credential store.
Isso é alvo valioso.
Service account com deploy rights pode ser caminho direto para produção.
🔴 DevOps sem least privilege vira Red Team playground
Pipeline não precisa ter mais acesso do que tarefa exige.
Um job de build não deveria possuir poder administrativo amplo em z/OS.
Separe responsabilidades.
🧠 APIs tornam mainframe mais acessível
Isso é bom.
Mas também significa que atacante pode operar usando ferramentas familiares.
HTTP.
JSON.
OAuth.
Ferris não precisa dominar 3270 para causar efeito no backend.
☕ O atacante moderno pode nunca ver ISPF
Essa frase é importante.
Talvez execute transação crítica via REST.
Backend COBOL.
Db2.
Tudo mainframe.
Atacante só viu:
POST /payments
Isso muda percepção de superfície.
🧠 Modernização não remove mainframe
Ela esconde.
E cria interfaces.
Security precisa considerar cada camada.
🔐 Defense in Depth
WAF.
IAM.
API Gateway.
z/OS Connect.
RACF.
CICS Security.
Db2.
Logs.
Camadas.
Nenhuma perfeita.
Swiss Cheese.
🧀 Ferris quer alinhar os buracos
Exemplo:
token roubado;
scope amplo;
API sem validação adicional;
conta técnica compartilhada;
backend com privilégio excessivo.
Juntos:
exploit.
🧠 O mainframe pode não ter falha nenhuma
Esse é o ponto central.
Ele recebe chamada válida.
Executa transação autorizada.
Grava Db2.
Do ponto de vista local, tudo certo.
O ataque aconteceu na confiança distribuída.
🔴 Threat Modeling precisa incluir upstream
Não pergunte só:
“z/OS está seguro?”
Pergunte:
quem fala com ele?
quem fala com quem fala com ele?
E quem administra tudo isso?
Agora começamos a ver o sistema real.
🕸️ Attack Path
Imagine:
LinkedIn
↓
Developer
↓
Git credential
↓
Pipeline
↓
Service account
↓
z/OS
Outro:
Phishing
↓
VPN
↓
Jump Server
↓
TSO
↓
RACF
Outro:
API token
↓
Gateway
↓
z/OS Connect
↓
CICS
Red Team procura esses caminhos.
🧠 Graph Thinking
Ativos são nós.
Acessos são arestas.
Atacante quer caminho.
Se existe:
User → Group → Role → Service → Mainframe
temos rota.
Mapear relações é valioso.
🔐 Least Privilege reduz arestas
Cada permissão removida elimina caminho potencial.
É por isso que recertificação importa.
Ferris odeia grafo bem podado.
🧾 RACF Groups merecem atenção
Grupo pode conceder acessos amplos.
Usuário entra.
Herda.
Anos depois ninguém lembra.
Privilege creep.
Revise.
🧠 OPERATIONS também merece cuidado
Autoridades poderosas precisam justificativa.
Não importa nome.
Princípio é:
privilégio extraordinário deve ser raro, monitorado e revisado.
🔍 AUDITOR também é sensível
Visibilidade ampla pode revelar informações relevantes.
Controle de auditoria também precisa separação.
Quem audita não deveria necessariamente administrar.
🔐 Separation of Duties no z/OS
Admin.
Auditor.
Operator.
Developer.
Cada papel.
Evite superusuário universal.
Ferris ama concentração.
🧠 Break Glass
Contas emergenciais.
Precisam existir.
Mas:
uso raro;
alerta;
justificativa;
rotação;
revisão.
Não podem virar conta diária.
🧾 SMF: memória operacional
SMF registra enorme quantidade de informação.
Eventos.
Uso.
Segurança.
Performance.
Operação.
Para Blue Team, isso é ouro.
Mas exige:
coleta;
correlação;
retenção;
análise.
🔵 Mainframe não precisa ser ponto cego do SOC
Integre telemetria.
RACF events.
SMF.
CICS.
Db2.
Network.
API.
Se SOC vê apenas Windows e cloud, Ferris ganha uma zona escura.
🧠 Visibility Gap
Um incidente pode atravessar:
cloud → API → z/OS.
Se logs estão separados, ninguém enxerga história completa.
Correlacionar é essencial.
☕ “No mainframe está tudo normal”
Talvez.
Mas upstream não.
Uma sessão pode parecer normal localmente porque credencial é válida.
Contexto externo revela fraude.
🧠 Identity context precisa viajar
IP.
Device.
User.
Session.
Risk.
Quanto contexto chega?
Quanto se perde?
Esse detalhe pode ajudar detecção.
🔴 Technical account apaga contexto
Outra vez.
Se todas as transações chegam como conta técnica, comportamento humano desaparece.
Mantenha correlação externa.
🔐 MFA no caminho inteiro
MFA em login inicial ajuda.
Mas se sessão depois gera token longo e reutilizável, risco continua.
Security lifecycle completo.
🧠 Session Hijacking
Não precisa roubar senha.
Roubar sessão pode bastar.
Então proteção de cookies, tokens e endpoints importa.
Mesmo quando backend é mainframe.
🔴 Ferris ataca endpoints mais modernos
Por quê?
Porque ferramentas são conhecidas.
Stacks comuns.
Documentação pública.
Isso não significa mainframe inseguro.
Significa ecossistema amplo.
🧠 API Security é Mainframe Security agora
Se API termina em CICS ou Db2, ataque à API é ataque ao negócio mainframe.
Essa fronteira mental precisa desaparecer.
☕ O mainframe não termina na LPAR
Essa frase merece destaque.
Hoje mainframe termina onde o processo de negócio termina.
Cloud.
Mobile.
API.
Partner.
Tudo conectado.
🧨 Third Party Access
Fornecedores.
Consultores.
Suporte.
Acessos remotos.
Pergunte:
como autenticam?
por quanto tempo?
qual privilégio?
há monitoramento?
conta individual?
Third party pode ser Cameron.
🧠 Vendor account antiga
Projeto acabou.
Conta ficou.
Clássico.
Red Team agradece.
Offboarding precisa funcionar.
🔐 Identity Lifecycle
Joiner.
Mover.
Leaver.
Quando pessoa muda de função, acessos mudam?
Quando sai, revoga?
Isso afeta mainframe também.
🧠 Orphan Accounts
Conta sem dono é perigo.
Especialmente privilegiada.
Inventário ajuda.
☕ “Essa conta é de quem?”
Se resposta:
“acho que é do sistema antigo”,
hora de investigar.
🔴 USS + SSH
Dependendo do ambiente, SSH pode ser interface.
Chaves.
Users.
Config.
Se chave privada vaza, atacante pode tentar acesso.
Então SSH key management importa.
🔐 Key Rotation
Chaves antigas.
Sem passphrase.
Compartilhadas.
Problema.
Gerencie ciclo.
🧠 APF + writable library = pesadelo
De forma conceitual, qualquer combinação de confiança elevada com capacidade indevida de alteração merece atenção máxima.
O Red Team procura justamente relações assim.
Não precisa publicar passo a passo.
Precisa mostrar risco.
🧩 Privilege Path
User comum.
Permissão em dataset.
Dataset influencia job.
Job roda privilegiado.
Agora temos caminho.
Ferris ama indireção.
🔴 Indirect Privilege é tão importante quanto direto
Você pode não ter SPECIAL.
Mas consegue influenciar algo que roda com autoridade.
Isso é caminho de escalada.
🧠 Control Flow matters
Quem controla código?
Config?
JCL?
Proc?
Libraries?
Tudo pode alterar comportamento.
☕ Não proteja só usuário final
Proteja também:
artefatos;
configuração;
scripts;
pipelines;
bibliotecas;
jobs.
Porque execução confia neles.
🔐 Change Control
Mudanças críticas precisam revisão.
Especialmente em componentes privilegiados.
Quatro olhos.
Auditoria.
Versionamento.
Ferris odeia peer review.
🧠 Code Review não é só qualidade
Também é segurança.
Mudança maliciosa ou acidental pode ser detectada.
🧾 Immutable logs
Se admin consegue apagar evidência, investigação sofre.
Envie cópia para sistema externo.
Proteja.
🔵 SOC + Mainframe
Idealmente, eventos críticos do mainframe chegam ao SOC com contexto.
SPECIAL usado?
Alerta.
Mudança incomum?
Alerta.
Acesso a dataset sensível?
Contexto.
🧠 Behavior Analytics no mainframe
Usuário normalmente acessa 3 datasets.
Hoje acessou 300.
Talvez legítimo.
Talvez não.
Contexto ajuda.
🔴 Baseline é útil
Não como verdade absoluta.
Mas para detectar desvio.
Ferris tenta parecer normal.
Blue Team procura padrão.
🧠 Mas cuidado com Automation Bias
Se score diz normal, não significa seguro.
Lembramos do Rooney.
Ferramenta ajuda.
Não substitui julgamento.
☕ Ferris entra pelo caminho menos glamouroso
Talvez:
senha esquecida em script.
Conta antiga.
Token.
Fornecedor.
API.
Nada cinematográfico.
Ataques reais frequentemente são assim.
🔐 Hygiene ainda vence
MFA.
PAM.
Least privilege.
Recertificação.
Logging.
Patch.
Segmentation.
DevSecOps.
Controle de secrets.
O básico continua forte.
🧠 Red Team Mainframe precisa conhecer negócio
Esse é o diferencial.
Não basta saber z/OS.
Precisa entender:
fluxo financeiro;
transações;
identidade;
integrações;
processos.
Porque objetivo não é “entrar no TSO”.
É impactar negócio.
🎯 Crown Jewels
Quais datasets?
Quais transações?
Quais APIs?
Quais jobs?
Quais contas?
Proteja com prioridade.
🧠 O atacante busca efeito, não terminal bonito
Ele quer:
dados;
dinheiro;
controle;
disrupção;
persistência.
3270 é apenas um meio.
🔴 Ferris não precisa ver READY
Essa frase também merece moldura.
Se consegue objetivo via API, acabou.
Red Team moderno precisa pensar além da estética do mainframe.
🦖 z/OS Connect, MQ, Zowe: modernização com responsabilidade
Essas tecnologias não são “problema”.
São capacidade.
Integração.
Produtividade.
O risco aparece quando são implantadas sem threat model.
Ferris não odeia modernização.
Ele ama modernização mal governada.
🧠 Security by Design
Cada integração deveria nascer com:
identity;
authorization;
logging;
rate limit;
secret management;
segregation.
Não depois.
☕ Threat Model antes do Go Live
Pergunte:
quem chamará?
com qual credencial?
o que pode fazer?
o que acontece se comprometer?
como revoga?
como detecta?
Isso é muito mais barato antes.
🔐 Zero Trust aplicado ao ecossistema
Não confiar implicitamente.
Verificar.
Limitar.
Monitorar.
Mesmo tráfego interno.
Mesmo fornecedor.
Mesmo serviço.
🧠 East-West matters
Ataque pode entrar por cloud e mover internamente.
Segmentação limita blast radius.
🔴 Network segmentation ainda vale
Mainframe não deve estar acessível de qualquer lugar.
Limite caminho.
Jump hosts.
Gateways.
Firewalls.
Rules.
🧠 Mas network não substitui identity
IP permitido não prova usuário legítimo.
Camadas.
☕ Ferris quer uma exceção
Toda empresa tem.
“Temporário.”
“Legado.”
“Só até migração.”
Ferris caça essas palavras.
🧾 Temporary access precisa expirar
Automático.
Não por memória humana.
Porque temporário é uma das coisas mais permanentes de TI.
🧠 Exception Management
Registre.
Owner.
Data final.
Risco.
Compensating controls.
Sem isso, exceção vira arquitetura.
🔴 Red Team deveria atacar exceções
Porque são caminhos menos testados.
Mais humanos.
Mais frágeis.
🧠 Mainframe security é ecosystem security
Essa é talvez a maior mensagem.
Você não protege z/OS isoladamente.
Protege:
identidade;
rede;
API;
pipeline;
endpoint;
fornecedor;
cloud;
dados;
processo.
☕ O atacante talvez nunca saiba que existe mainframe
Isso é quase poético.
Ele explora API.
Executa transação.
Recebe resposta.
Nem sabe que atrás existe CICS + COBOL + Db2.
Mas o impacto está lá.
🧠 Legacy é invisível ao atacante moderno
E isso não torna seguro.
Torna backend.
A segurança precisa abranger frontend e backend.
🔐 Authorization end-to-end
Não confie só no gateway.
Backend também valida quando possível.
Evite “front-end said yes, so everything is allowed”.
Ferris explora implicit trust.
🧠 Confused Deputy
Um componente autorizado pode ser induzido a fazer algo em nome do atacante.
Esse conceito encaixa perfeitamente.
Aplicação tem acesso.
Atacante manipula aplicação.
Backend recebe pedido legítimo de componente legítimo.
Problema.
☕ Cameron virou middleware de novo
Ferris → Cameron → escola.
Agora:
Ferris → API → middleware → mainframe.
Mesma história.
🧨 Service-to-Service Trust
Mutual TLS.
Tokens.
Scopes.
Audience.
Tudo precisa ser correto.
Porque serviço legítimo pode ser comprometido.
🧠 Machine Identity é nova fronteira
Há mais identidades de máquina que humanas em muitos ambientes.
Bots.
Pipelines.
APIs.
Agentes.
Cada uma precisa governança.
🔐 Secrets sprawl
Quanto mais integrações, mais secrets.
Gerenciamento centralizado ajuda.
Ferris procura aquele .properties antigo.
☕ Não coloque senha no JCL
Parece conselho de avô.
Continua válido.
Secrets não pertencem a texto aberto.
🧠 Dataset protection
Datasets podem conter:
source;
config;
credentials;
dados.
Classifique.
Controle.
Monitore.
🔴 Sensitive Dataset Access
Quem lê?
Quem atualiza?
Quem altera ACL?
Audite.
🧠 Db2 Privileges
Privilégios de banco também precisam least privilege.
Não dê SYSADM para resolver SELECT.
Ferrari com canhão.
🔐 CICS Transaction Security
Transações críticas devem exigir autorização adequada.
Não apenas acesso à região.
Granularidade importa.
🧠 MQ Object Security
Filas também são recursos.
Quem PUT?
Quem GET?
Quem ALTER?
Controle.
☕ Cada subsistema tem sua Ferrari
RACF.
CICS.
Db2.
MQ.
Cada um possui privilégios poderosos.
Não concentre tudo na mesma identidade.
🔴 Separation of Duties de verdade
RACF admin não precisa ser Db2 SYSADM automaticamente.
Db2 DBA não precisa controlar pipeline.
Segmente poder.
🧠 Blast Radius
Se uma conta cair, quanto perde?
Essa é pergunta simples e brutal.
Ferris quer conta com blast radius máximo.
🔐 Tiering de privilégio
Contas de alto risco mais protegidas.
MFA forte.
PAM.
Workstation dedicada quando necessário.
Monitoramento.
🧠 Privileged Workstation
Separar ambiente administrativo reduz exposição.
Não administre sistema crítico da mesma máquina usada para e-mail e navegação.
Ferris adora anexos.
☕ O maior bug pode estar no laptop do admin
Mainframe impecável.
Laptop comprometido.
Credencial roubada.
Fim.
Endpoint security também é mainframe security.
🔵 EDR não termina no Windows
Contexto do endpoint importa.
Se admin acessa z/OS de host comprometido, risco atravessa fronteira.
Correlacione.
🧠 Phishing continua relevante
FerrisGPT não precisa atacar z/OS.
Ataca quem administra z/OS.
A velha engenharia social continua viva.
🔴 Quem sabe mais sobre RACF?
Provavelmente profissionais específicos.
OSINT pode identificá-los.
Isso conecta artigo 4 ao 11.
A série fecha círculo.
☕ LinkedIn → Admin → TSO
Não é ataque técnico direto.
É attack path humano.
🧠 Red Team não é pentest de porta
Essa é a diferença.
Pentest pode olhar vulnerabilidades.
Red Team busca objetivo e caminho.
Mainframe exige essa visão.
🔴 Objective-Based Testing
Exemplo:
“Conseguir alterar dado crítico sem detecção.”
Agora escolha caminho.
API.
CICS.
Credencial.
Pipeline.
Não importa.
Objetivo guia.
🧠 Detection matters
Se ataque foi possível, foi detectado?
Quanto tempo?
Qual alerta?
Quem reagiu?
Red Team mede defesa.
🔵 Purple Team
Depois:
Red mostra caminho.
Blue cria detecção.
Engineering corrige.
IAM reduz privilégio.
Isso é valor.
☕ “Conseguimos entrar” é menos útil que “aprendemos por quê”
O objetivo final é aprendizado.
Ferris não precisa provar que é gênio.
Precisa revelar suposição fraca.
🧠 A pergunta Bellacosa número 1
“Qual é o caminho mais curto entre uma credencial externa comprometida e um recurso crítico no z/OS?”
Mapeie.
🔴 Pergunta número 2
“Quais contas técnicas possuem privilégio que ninguém revisa há anos?”
🧠 Pergunta número 3
“Onde identidade humana vira conta compartilhada?”
🔐 Pergunta número 4
“Quem consegue alterar algo que roda com privilégio maior?”
📜 Pergunta número 5
“Conseguimos reconstruir uma ação da internet até o Db2?”
Se não, observabilidade fragmentada.
🧨 Pergunta número 6
“Qual integração mais nova conversa com nosso sistema mais antigo?”
Essa é maravilhosa.
Porque risco frequentemente nasce na junção de eras.
🧠 Pergunta número 7
“Se uma service account for roubada, quem percebe?”
🔴 Pergunta número 8
“Nosso SOC enxerga o mainframe ou ele ainda é planeta separado?”
☕ Pergunta número 9
“Quem possui SPECIAL e realmente precisa dele hoje?”
Essa pode render café longo.
🧠 Pergunta número 10
“Estamos protegendo o z/OS ou apenas o terminal 3270?”
Essa é a essência.
🎬 Ferris entra em Chicago pela porta de serviço
O ataque moderno ao mainframe talvez nunca pareça “ataque de mainframe”.
Pode parecer:
phishing;
token roubado;
pipeline comprometido;
API abuse;
service account;
fornecedor;
endpoint.
No final, o efeito chega ao z/OS.
Essa é a mudança.
☕ Epílogo: o caminho até a Ferrari
Ferris olha para o mainframe.
Gigante.
Robusto.
RACF.
SAF.
ACEE.
APF.
CICS.
Db2.
MQ.
Uma fortaleza.
Ele poderia tentar aprender cada detalhe e procurar uma fraqueza frontal.
Talvez consiga.
Talvez não.
Mas Ferris não é romântico.
Ele é pragmático.
Então olha ao redor.
Vê:
API.
Pipeline.
Conta técnica.
Fornecedor.
Token.
Laptop.
Usuário privilegiado.
Integração.
E pensa:
“Por que eu atacaria o mainframe se posso atacar aquilo em que o mainframe confia?”
Essa é a pergunta central.
Porque segurança moderna não termina na LPAR.
Ela atravessa:
pessoas;
cloud;
DevOps;
IAM;
APIs;
mensageria;
agentes;
endpoints.
O mainframe pode ser extraordinariamente seguro.
E ainda assim estar ligado a cinquenta sistemas menos seguros.
A cadeia inteira define o risco.
Ferris não precisa quebrar RACF.
Talvez precise apenas conseguir uma identidade que RACF aceite.
Não precisa atacar CICS.
Talvez consiga uma API legítima.
Não precisa tocar Db2.
Talvez uma aplicação autorizada faça isso por ele.
Não precisa conseguir SPECIAL.
Talvez consiga influenciar quem já possui.
E é por isso que Red Team em mainframe não pode ser tratado como nostalgia técnica.
É segurança de ecossistema.
Ataque de caminho.
Confiança distribuída.
Privilégio.
Identidade.
Observabilidade.
E integração.
Então, da próxima vez que alguém disser:
“Nosso mainframe é seguro.”
A resposta correta não é discordar.
Talvez seja mesmo.
A resposta correta é perguntar:
“E o caminho até ele?”
Porque talvez Ferris nunca precise ver um prompt READY.
Talvez nunca abra ISPF.
Talvez nunca aprenda JCL.
Pode simplesmente atravessar uma API, usar uma conta técnica, seguir uma cadeia de confiança...
e deixar o z/OS fazer exatamente aquilo para o qual foi projetado.
Com eficiência.
Confiabilidade.
E absoluta obediência.
☕ SAVE FERRIS.
No próximo e último artigo:
“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora
Porque depois de Ferris atravessar pessoas, dados, Ferrari, IA e mainframe...
resta responder a pergunta mais importante:
o que a organização aprendeu antes que o próximo Ferris apareça?
☕ Um Café no Bellacosa Mainframe — Especial Red Team
SAVE FERRIS — Ferris Bueller’s Red Team
Uma série de 12 artigos sobre Red Team, segurança ofensiva, engenharia social, OSINT, integridade de dados, MFA, PAM, rollback, Blue Team, inteligência artificial, RACF e z/OS, usando Ferris Bueller para explorar uma pergunta fundamental: o sistema está realmente seguro ou apenas acredita que está?
- Red Team
- OSINT
- Engenharia Social
- Blue Team
- MFA
- PAM
- IA Generativa
- RACF
- z/OS
- Mainframe
Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team
Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.
Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade
Integridade de dados, alteração de registros, privilégio, auditoria e a perigosa diferença entre aquilo que aconteceu e aquilo que o banco de dados afirma ter acontecido.
Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu
Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.
“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir
Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.
Cameron, Atenda o Telefone — Social Engineering as a Service
Ferris → Cameron → telefone → escola → funcionário → sistema. Nenhuma peça precisa falhar sozinha quando a cadeia inteira possui uma combinação explorável de confiança.
O Diretor Rooney Está Procurando Malware no Lugar Errado
Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.
A Ferrari do Cameron Não Tinha MFA
Privilégio, acesso físico, MFA, PAM, least privilege e o risco de proteger um ativo crítico apenas com medo, confiança e a esperança de que ninguém ousará tocá-lo.
Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
Rollback, restore, journaling, logs, Db2, VSAM e recuperação: voltar o estado de um sistema não significa apagar as consequências daquilo que aconteceu.
Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente
Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.
FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos
IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.
Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago
RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.
“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora
Red Team não termina em “conseguimos entrar”. Ataque deve gerar descoberta, evidência, correção, detecção e aprendizado para deixar a organização mais resiliente.
🎬 Página principal da temporada
Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron reúne os doze episódios e conecta Red Team, engenharia social, IA, Blue Team e segurança de mainframe.
☕ Acessar o especial completo SAVE FERRISSobre a série SAVE FERRIS — Red Team
A série SAVE FERRIS, publicada no Bellacosa Mainframe, utiliza situações inspiradas em Ferris Bueller para explicar conceitos de Red Team, cybersecurity, segurança ofensiva, engenharia social, OSINT, Blue Team, Purple Team, Zero Trust, MFA, PAM, inteligência artificial, RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.
O fio condutor é simples: um atacante não precisa necessariamente quebrar a tecnologia. Ele pode explorar relações de confiança, processos, identidades, privilégios, integrações e suposições existentes entre pessoas e sistemas.
A temporada acompanha o ciclo completo: reconhecimento → engenharia social → acesso → privilégio → impacto → detecção → correção → aprendizado.
Para Red Teams e Blue Teams, o objetivo final não é provar quem é mais inteligente, mas encontrar caminhos invisíveis antes que um adversário real os descubra.
Sem comentários:
Enviar um comentário