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.
✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
| Bellacosa Mainframe e o racf |
SPECIAL Virou o Passe para ChicagoImagine 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:
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:
Hoje Ferris chegou ao mainframe.
Mas talvez nunca precise realmente “hackear o mainframe”.
Talvez seja suficiente atacar:
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:
Esse é o ponto.
Atacante eficiente não escolhe a defesa mais forte.
Escolhe o caminho mais barato.
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 é 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 é:
Essa pergunta muda tudo.
À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.
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 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 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:
Porque se origem foi comprometida, o resto pode continuar funcionando normalmente.
SPECIAL: quando Ferris ganha passe VIPAgora 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 souvenirPerguntas 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.
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 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.
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.
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/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 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?
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 — 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”.
É:
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.
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.
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.
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 é 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.
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.
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.
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.
Idealmente, uma ação deveria poder ser rastreada:
usuário;
sessão;
gateway;
API;
z/OS Connect;
CICS;
Db2.
Essa linha do tempo é valiosa.
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.
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 é 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?
Se atacante consegue publicar numa fila autorizada, downstream pode processar normalmente.
De novo:
o sistema funciona.
O problema está em quem conseguiu alimentar.
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”.
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 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 bem protegida é ótima.
API mal protegida é entrada elegante.
Authorization.
Rate limiting.
Scopes.
Token lifecycle.
Logging.
Tudo importa.
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.
Quanto mais dura, maior janela.
Prefira tokens curtos.
Renovação controlada.
Menor exposição.
Outra armadilha.
“Tem OAuth.”
Ótimo.
Mas backend precisa continuar aplicar política.
Token autenticado não significa “pode tudo”.
Identity ≠ Authorization.
Abe Froman voltou.
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.
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?
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.
Developer
↓
Git
↓
Build
↓
Artifact
↓
Deploy
↓
z/OS
Ataque qualquer etapa.
Ferris procura elo mais fraco.
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?
Senha em Jenkins.
Token em variável.
Credential store.
Isso é alvo valioso.
Service account com deploy rights pode ser caminho direto para produção.
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.
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.
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.
Ela esconde.
E cria interfaces.
Security precisa considerar cada camada.
WAF.
IAM.
API Gateway.
z/OS Connect.
RACF.
CICS Security.
Db2.
Logs.
Camadas.
Nenhuma perfeita.
Swiss Cheese.
Exemplo:
token roubado;
scope amplo;
API sem validação adicional;
conta técnica compartilhada;
backend com privilégio excessivo.
Juntos:
exploit.
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.
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.
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.
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.
Cada permissão removida elimina caminho potencial.
É por isso que recertificação importa.
Ferris odeia grafo bem podado.
Grupo pode conceder acessos amplos.
Usuário entra.
Herda.
Anos depois ninguém lembra.
Privilege creep.
Revise.
OPERATIONS também merece cuidadoAutoridades poderosas precisam justificativa.
Não importa nome.
Princípio é:
privilégio extraordinário deve ser raro, monitorado e revisado.
AUDITOR também é sensívelVisibilidade ampla pode revelar informações relevantes.
Controle de auditoria também precisa separação.
Quem audita não deveria necessariamente administrar.
Admin.
Auditor.
Operator.
Developer.
Cada papel.
Evite superusuário universal.
Ferris ama concentração.
Contas emergenciais.
Precisam existir.
Mas:
uso raro;
alerta;
justificativa;
rotação;
revisão.
Não podem virar conta diária.
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.
Integre telemetria.
RACF events.
SMF.
CICS.
Db2.
Network.
API.
Se SOC vê apenas Windows e cloud, Ferris ganha uma zona escura.
Um incidente pode atravessar:
cloud → API → z/OS.
Se logs estão separados, ninguém enxerga história completa.
Correlacionar é essencial.
Talvez.
Mas upstream não.
Uma sessão pode parecer normal localmente porque credencial é válida.
Contexto externo revela fraude.
IP.
Device.
User.
Session.
Risk.
Quanto contexto chega?
Quanto se perde?
Esse detalhe pode ajudar detecção.
Outra vez.
Se todas as transações chegam como conta técnica, comportamento humano desaparece.
Mantenha correlação externa.
MFA em login inicial ajuda.
Mas se sessão depois gera token longo e reutilizável, risco continua.
Security lifecycle completo.
Não precisa roubar senha.
Roubar sessão pode bastar.
Então proteção de cookies, tokens e endpoints importa.
Mesmo quando backend é mainframe.
Por quê?
Porque ferramentas são conhecidas.
Stacks comuns.
Documentação pública.
Isso não significa mainframe inseguro.
Significa ecossistema amplo.
Se API termina em CICS ou Db2, ataque à API é ataque ao negócio mainframe.
Essa fronteira mental precisa desaparecer.
Essa frase merece destaque.
Hoje mainframe termina onde o processo de negócio termina.
Cloud.
Mobile.
API.
Partner.
Tudo conectado.
Fornecedores.
Consultores.
Suporte.
Acessos remotos.
Pergunte:
como autenticam?
por quanto tempo?
qual privilégio?
há monitoramento?
conta individual?
Third party pode ser Cameron.
Projeto acabou.
Conta ficou.
Clássico.
Red Team agradece.
Offboarding precisa funcionar.
Joiner.
Mover.
Leaver.
Quando pessoa muda de função, acessos mudam?
Quando sai, revoga?
Isso afeta mainframe também.
Conta sem dono é perigo.
Especialmente privilegiada.
Inventário ajuda.
Se resposta:
“acho que é do sistema antigo”,
hora de investigar.
Dependendo do ambiente, SSH pode ser interface.
Chaves.
Users.
Config.
Se chave privada vaza, atacante pode tentar acesso.
Então SSH key management importa.
Chaves antigas.
Sem passphrase.
Compartilhadas.
Problema.
Gerencie ciclo.
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.
User comum.
Permissão em dataset.
Dataset influencia job.
Job roda privilegiado.
Agora temos caminho.
Ferris ama indireção.
Você pode não ter SPECIAL.
Mas consegue influenciar algo que roda com autoridade.
Isso é caminho de escalada.
Quem controla código?
Config?
JCL?
Proc?
Libraries?
Tudo pode alterar comportamento.
Proteja também:
artefatos;
configuração;
scripts;
pipelines;
bibliotecas;
jobs.
Porque execução confia neles.
Mudanças críticas precisam revisão.
Especialmente em componentes privilegiados.
Quatro olhos.
Auditoria.
Versionamento.
Ferris odeia peer review.
Também é segurança.
Mudança maliciosa ou acidental pode ser detectada.
Se admin consegue apagar evidência, investigação sofre.
Envie cópia para sistema externo.
Proteja.
Idealmente, eventos críticos do mainframe chegam ao SOC com contexto.
SPECIAL usado?
Alerta.
Mudança incomum?
Alerta.
Acesso a dataset sensível?
Contexto.
Usuário normalmente acessa 3 datasets.
Hoje acessou 300.
Talvez legítimo.
Talvez não.
Contexto ajuda.
Não como verdade absoluta.
Mas para detectar desvio.
Ferris tenta parecer normal.
Blue Team procura padrão.
Se score diz normal, não significa seguro.
Lembramos do Rooney.
Ferramenta ajuda.
Não substitui julgamento.
Talvez:
senha esquecida em script.
Conta antiga.
Token.
Fornecedor.
API.
Nada cinematográfico.
Ataques reais frequentemente são assim.
MFA.
PAM.
Least privilege.
Recertificação.
Logging.
Patch.
Segmentation.
DevSecOps.
Controle de secrets.
O básico continua forte.
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.
Quais datasets?
Quais transações?
Quais APIs?
Quais jobs?
Quais contas?
Proteja com prioridade.
Ele quer:
dados;
dinheiro;
controle;
disrupção;
persistência.
3270 é apenas um meio.
READYEssa frase também merece moldura.
Se consegue objetivo via API, acabou.
Red Team moderno precisa pensar além da estética do mainframe.
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.
Cada integração deveria nascer com:
identity;
authorization;
logging;
rate limit;
secret management;
segregation.
Não depois.
Pergunte:
quem chamará?
com qual credencial?
o que pode fazer?
o que acontece se comprometer?
como revoga?
como detecta?
Isso é muito mais barato antes.
Não confiar implicitamente.
Verificar.
Limitar.
Monitorar.
Mesmo tráfego interno.
Mesmo fornecedor.
Mesmo serviço.
Ataque pode entrar por cloud e mover internamente.
Segmentação limita blast radius.
Mainframe não deve estar acessível de qualquer lugar.
Limite caminho.
Jump hosts.
Gateways.
Firewalls.
Rules.
IP permitido não prova usuário legítimo.
Camadas.
Toda empresa tem.
“Temporário.”
“Legado.”
“Só até migração.”
Ferris caça essas palavras.
Automático.
Não por memória humana.
Porque temporário é uma das coisas mais permanentes de TI.
Registre.
Owner.
Data final.
Risco.
Compensating controls.
Sem isso, exceção vira arquitetura.
Porque são caminhos menos testados.
Mais humanos.
Mais frágeis.
Essa é talvez a maior mensagem.
Você não protege z/OS isoladamente.
Protege:
identidade;
rede;
API;
pipeline;
endpoint;
fornecedor;
cloud;
dados;
processo.
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á.
E isso não torna seguro.
Torna backend.
A segurança precisa abranger frontend e backend.
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.
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.
Ferris → Cameron → escola.
Agora:
Ferris → API → middleware → mainframe.
Mesma história.
Mutual TLS.
Tokens.
Scopes.
Audience.
Tudo precisa ser correto.
Porque serviço legítimo pode ser comprometido.
Há mais identidades de máquina que humanas em muitos ambientes.
Bots.
Pipelines.
APIs.
Agentes.
Cada uma precisa governança.
Quanto mais integrações, mais secrets.
Gerenciamento centralizado ajuda.
Ferris procura aquele .properties antigo.
Parece conselho de avô.
Continua válido.
Secrets não pertencem a texto aberto.
Datasets podem conter:
source;
config;
credentials;
dados.
Classifique.
Controle.
Monitore.
Quem lê?
Quem atualiza?
Quem altera ACL?
Audite.
Privilégios de banco também precisam least privilege.
Não dê SYSADM para resolver SELECT.
Ferrari com canhão.
Transações críticas devem exigir autorização adequada.
Não apenas acesso à região.
Granularidade importa.
Filas também são recursos.
Quem PUT?
Quem GET?
Quem ALTER?
Controle.
RACF.
CICS.
Db2.
MQ.
Cada um possui privilégios poderosos.
Não concentre tudo na mesma identidade.
RACF admin não precisa ser Db2 SYSADM automaticamente.
Db2 DBA não precisa controlar pipeline.
Segmente poder.
Se uma conta cair, quanto perde?
Essa é pergunta simples e brutal.
Ferris quer conta com blast radius máximo.
Contas de alto risco mais protegidas.
MFA forte.
PAM.
Workstation dedicada quando necessário.
Monitoramento.
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.
Mainframe impecável.
Laptop comprometido.
Credencial roubada.
Fim.
Endpoint security também é mainframe security.
Contexto do endpoint importa.
Se admin acessa z/OS de host comprometido, risco atravessa fronteira.
Correlacione.
FerrisGPT não precisa atacar z/OS.
Ataca quem administra z/OS.
A velha engenharia social continua viva.
Provavelmente profissionais específicos.
OSINT pode identificá-los.
Isso conecta artigo 4 ao 11.
A série fecha círculo.
Não é ataque técnico direto.
É attack path humano.
Essa é a diferença.
Pentest pode olhar vulnerabilidades.
Red Team busca objetivo e caminho.
Mainframe exige essa visão.
Exemplo:
“Conseguir alterar dado crítico sem detecção.”
Agora escolha caminho.
API.
CICS.
Credencial.
Pipeline.
Não importa.
Objetivo guia.
Se ataque foi possível, foi detectado?
Quanto tempo?
Qual alerta?
Quem reagiu?
Red Team mede defesa.
Depois:
Red mostra caminho.
Blue cria detecção.
Engineering corrige.
IAM reduz privilégio.
Isso é valor.
O objetivo final é aprendizado.
Ferris não precisa provar que é gênio.
Precisa revelar suposição fraca.
Mapeie.
Se não, observabilidade fragmentada.
Essa é maravilhosa.
Porque risco frequentemente nasce na junção de eras.
SPECIAL e realmente precisa dele hoje?”Essa pode render café longo.
Essa é a essência.
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.
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:
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:
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:
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
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á?
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.
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.
Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.
Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.
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.
Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.
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.
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.
Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.
IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.
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.
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.
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 FERRISA 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.
Gostou deste artigo? 💡💡💡 Conecte-se comigo no LinkedIn e acompanhe conteúdos exclusivos sobre IBM Z, COBOL, Arquitetura, IA, Modernização e Engenharia de Software.
👨💻 Perfil no LinkedIn 📚 Assinar "Aprenda mais no Bellacosa Mainframe" ☕ Acompanhar "Um Café no Bellacosa Mainframe"IBM Champion 2026 • Especialista em IBM Mainframe
Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.