☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta hacking. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta hacking. Mostrar todas as mensagens

sábado, 1 de maio de 2021

💀🔥 “Seu RACF está seguro… ou você só acha?”

 

Bellacosa Mainframe alerta sobre riscos no racf mal configurado

💀🔥 “Seu RACF está seguro… ou você só acha?”

🧠 Checklist de Auditoria RACF nível banco (com segredos que ninguém te conta)

“RACF não falha…
quem falha é quem confia demais nele.”


🧠 📜 Contexto histórico (o começo de tudo)

O RACF nasceu nos anos 70 junto com o z/OS (antes MVS).

👉 Naquela época:

  • segurança era controle de acesso
  • hoje é sobrevivência digital

💡 Curiosidade:

RACF foi um dos primeiros sistemas do mundo a implementar controle centralizado de identidade — antes do conceito de IAM moderno.


💀🔥 O CHECKLIST QUE SEPARA AMADOR DE BANCO


🧨 1. *PUBLIC — o vilão silencioso

👉 Procure:

// quem tem acesso aberto?
RLIST DATASET * AUTHUSER(*)

💥 Red flag:

  • datasets críticos com:
ID(*PUBLIC) ACCESS(READ ou UPDATE)

🔥 Insight Bellacosa:

80% das falhas começam aqui.


🧠 2. Usuários com SPECIAL / OPERATIONS

👉 Liste:

SEARCH CLASS(USER) MASK(*) SPECIAL

💥 Risco:

  • acesso total ao RACF

🎯 Dica senior:

  • separar:
    • ADMIN ≠ AUDITOR

⚙️ 3. Grupos com autoridade excessiva

👉 Verifique:

LISTGRP * OMVS

💥 Problema:

  • grupo herdando privilégio indevido

🔥 Easter egg:

Um grupo mal configurado é pior que um usuário root.


🧬 4. Programas APF e AC=1

👉 Verifique APF:

D PROG,APF

💥 Risco:

  • execução em modo supervisor

🎯 Ataque clássico:

  • inserir loadlib malicioso

🔐 5. Password Policy (o calcanhar de aquiles)

👉 Cheque:

SETROPTS LIST

💥 Problemas comuns:

  • senha simples
  • sem expiração
  • sem history

🔥 Curiosidade:

Já vi banco com senha “123456” em ambiente produtivo.


🌐 6. FACILITY class (o “backdoor oficial”)

👉 Verifique:

RLIST FACILITY *

💥 Risco:

  • permissões ocultas

🎯 Exemplo crítico:

  • BPX.* (Unix System Services)

🧑‍💻 7. USS (Unix no mainframe = Linux feelings)

👉 Verifique:

LISTUSER USER OMVS

💥 Risco:

  • UID 0 (root)

🔥 Insight:

USS é o ponto favorito de pivot de atacante moderno.


🧾 8. Logging / SMF (sem isso você está cego)

👉 Cheque:

  • SMF 80 (RACF)
  • SMF 30 (jobs)

💥 Problema:

  • logs incompletos

🎯 Dica:

  • integrar com SIEM

🧠 9. Started Tasks (STC) — privilégio invisível

👉 Verifique:

RLIST STARTED *

💥 Risco:

  • tarefas com privilégios elevados

🔥 Easter egg:

STC mal protegido = root invisível rodando 24x7


🔗 10. Integrações externas (o novo campo de batalha)

👉 Verifique:

  • CICS
  • z/OS Connect

💥 Risco:

  • acesso indireto ao core

🎯 Realidade:

O ataque não entra pelo mainframe… entra pela API.


💀🔥 CHECKLIST RÁPIDO (modo auditor)

✔️ Nenhum dataset crítico com *PUBLIC
✔️ SPECIAL restrito e auditado
✔️ APF controlado
✔️ Senha forte e rotacionada
✔️ SMF ativo e monitorado
✔️ USS sem UID 0 indevido
✔️ FACILITY revisada
✔️ STC mapeado
✔️ Integrações seguras


🧠💣 Fluxo real de ataque (pra abrir a mente)

  1. credencial fraca
  2. acesso TSO/FTP
  3. enumeração RACF
  4. exploração (APF / FACILITY / USS)
  5. persistência
  6. exfiltração

🧬 Easter Eggs que só senior percebe

💡 RACF não protege dataset não catalogado direito
💡 APF + AC=1 = execução nível kernel
💡 FACILITY é mais perigosa que DATASET
💡 USS é o “Linux escondido” do mainframe


🏦 Realidade nível banco

👉 Banco não confia em RACF…
👉 Banco audita RACF o tempo todo


🔥 Frase final estilo Bellacosa

“Se você não auditou seu RACF hoje…
alguém pode estar usando ele melhor que você.”

 

quinta-feira, 1 de abril de 2021

🧠 💥 Coletânea de ataques hacker em ambiente IBM Mainframe

 

Bellacosa Mainframe apresenta alguns casos de ataques hackers em mainframe

🧠 💥 Coletânea de ataques hacker em ambiente IBM Mainframe

🧪 1. 1965 — O primeiro “hack” da história (IBM 7094 – CTSS)

👉 Sistema: IBM 7094 (CTSS – Compatible Time Sharing System)

O que aconteceu:

  • Um bug no editor criou um arquivo temporário com nome fixo
  • Dois usuários simultâneos causaram:
    • exposição do arquivo de senhas (!)

Impacto:

  • Senhas ficaram visíveis para qualquer usuário

📌 IMPORTANTE:
👉 Isso é considerado o primeiro vazamento de credenciais da história

✔️ Lição:

  • Controle de concorrência e isolamento são fundamentais


🧠 2. 1967 — Primeira invasão de rede (IBM APL Network)

👉 Ambiente: rede experimental IBM APL

O que aconteceu:

  • Estudantes exploraram workspaces compartilhados
  • Conseguiram navegar além do escopo permitido

Impacto:

  • Primeira invasão “não autorizada” documentada em rede

✔️ Lição:

  • Segurança lógica > segurança física


💣 3. 2007 — Primeiro hack documentado em z/OS moderno

👉 Caso citado em estudos de segurança mainframe

Possível alvo:

  • Banco europeu (ex: Nordea Bank)

O que aconteceu:

  • Uso de vulnerabilidades em ambiente z/OS
  • exploração via acesso indireto (provavelmente aplicações)

✔️ Lição:

  • Mainframe moderno também é atacável


🏦 4. 2012 — Caso Nordea Bank / Governo Sueco (O MAIS CLÁSSICO)

👉 Ambiente: IBM z/OS

O que aconteceu:

  • Hackers usaram:
    • z/OS emulado
    • exploração de vulnerabilidades (0-day)
  • Conseguiram:
    • escalar privilégios (SPECIAL)
    • modificar APF
    • acessar dados sensíveis
    • transferir dinheiro (~$850k)

Impacto:

  • Um dos raros casos confirmados de invasão real em mainframe

✔️ Técnica usada:

  • privilege escalation
  • persistência (APF)
  • exfiltração de datasets

✔️ Lição:

  • RACF mal configurado = porta aberta


🏴‍☠️ 5. 2012 — Hacker do Pirate Bay (caso judicial)

👉 Hacker: cofundador do Pirate Bay

O que aconteceu:

  • Invasão de mainframe
  • Roubo de dados governamentais

Impacto:

  • considerado o maior caso de hacking de mainframe na Dinamarca

✔️ Lição:

  • ameaça real não é só técnica — é também judicial/legal


🧾 6. Casos indiretos (2014–2015) — Dados de mainframe expostos

👉 Empresas:

  • Home Depot
  • Anthem
  • Experian

O que aconteceu:

  • Ataque NÃO começou no mainframe
  • MAS:
    • dados críticos estavam no mainframe
    • foram exfiltrados via sistemas distribuídos

Impacto:

  • milhões de registros vazados

✔️ Insight poderoso:
👉 O mainframe NÃO foi invadido diretamente
👉 mas foi comprometido indiretamente

✔️ Lição:

  • o risco está na integração (APIs, middlewares)


⚠️ 7. Casos IBM i (AS/400) — “Nunca foi hackeado” (mito quebrado)

👉 Realidade:

  • já houve invasões documentadas

Problema comum:

  • permissões abertas (*PUBLIC *ALL)
  • falta de auditoria

✔️ Lição:

  • segurança default ≠ segurança real


🧨 8. Engenharia social e insider (o ataque mais comum)

👉 Segundo especialistas:

  • A maioria dos ataques não é “hack remoto hollywoodiano”
  • São:
    • insiders
    • credenciais roubadas
    • acesso legítimo abusado

✔️ Lição:

  • RACF + auditoria > firewall


📊 9. Estatística brutal (realidade do mercado)

👉 Apenas 0.1% dos mainframes reportaram breach direto

✔️ Tradução Bellacosa:

  • extremamente seguro
  • MAS quando falha → impacto é gigante


🧠 🔥 Padrões REAIS dos ataques em Mainframe

🧩 Vetores mais comuns

  • má configuração de RACF / ACF2 / Top Secret
  • credenciais roubadas
  • aplicações CICS vulneráveis
  • integração com sistemas distribuídos
  • insiders

⚙️ Técnicas usadas

  • privilege escalation (SPECIAL / OPERATIONS)
  • manipulação de APF
  • execução de REXX malicioso
  • leitura de datasets (PII)
  • exfiltração via FTP / TCP/IP stack

💀 MITO vs REALIDADE

MitoRealidade
Mainframe não é hackeávelÉ, mas difícil
Só ataque externoMaioria é interna
RACF resolve tudoDepende da configuração
Isolado = seguroIntegração quebra isso

🧠 Conclusão estilo Bellacosa

👉 O mainframe NÃO é invulnerável
👉 Ele é mal compreendido

💡 A verdade:

“Mainframe não cai por brute force…
cai por negligência.”


PS: Nunca se esqueça que o inimigo pode estar dentro do castelo. E os demonios riem quando fazemos planos infaliveis. 

segunda-feira, 1 de março de 2021

💀🔥 Top 10 vulnerabilidades reais em z/OS (com exemplos práticos)

 

Bellacosa Mainframe apresenta as 10 vulnerabilidades mais comuns em Mainframe

💀🔥 Top 10 vulnerabilidades reais em z/OS (com exemplos práticos)

“O perigo no mainframe não é o sistema…
é quem configura.”


🧨 1. RACF mal configurado (*PUBLIC liberado)

Cenário clássico:

// Dataset crítico liberado
PERMIT DATASET.PROD.FINANCE CLASS(DATASET) ID(*PUBLIC) ACCESS(READ)

💥 Resultado:

  • qualquer usuário pode ler dados financeiros

✔️ Ataque:

  • exfiltração via TSO, FTP ou batch

🔥 Correção:

  • remover *PUBLIC
  • usar grupos restritos

🧠 2. Usuário com SPECIAL indevido

Erro comum:

  • dar SPECIAL “temporário” e esquecer

💥 Resultado:

  • usuário vira “quase root”

✔️ Ataque:

  • altera RACF
  • cria backdoors

🔥 Exemplo:

ALTUSER HACKER SPECIAL

⚙️ 3. APF Library Injection

👉 Se atacante conseguir inserir lib na APF:

💥 Resultado:

  • código roda em modo supervisor

✔️ Ataque:

  • escalar privilégio total

🔥 Exemplo:

  • adicionar dataset na APF via:
SETPROG APF,ADD,DSNAME=HACK.LOADLIB,VOLUME=SYS001

🧬 4. Programas com AC=1 (Authorized)

👉 Programas autorizados são perigosíssimos

💥 Cenário:

  • programa mal protegido

✔️ Ataque:

  • executa código privilegiado

🔥 Exemplo:

  • load module vulnerável em:
SYS1.LINKLIB

🧾 5. JCL Injection

👉 Entrada controlada por usuário dentro de JOB

💥 Exemplo:

//STEP1 EXEC PGM=IEFBR14
//SYSIN DD *
DELETE PROD.DATA
/*

✔️ Ataque:

  • execução de comandos não autorizados

🔥 Lição:

  • validar input sempre

🌐 6. FTP mal configurado

👉 FTP aberto é porta escancarada

💥 Problema:

  • acesso sem restrição
  • upload/download liberado

✔️ Ataque:

  • baixar datasets
  • subir payload

🔥 Exemplo:

ftp> get 'PROD.CLIENTES'

🧑‍💻 7. CICS sem segurança adequada

👉 Transações abertas

💥 Cenário:

  • transação sem autenticação

✔️ Ataque:

  • acesso direto a dados sensíveis

🔥 Exemplo:

  • acessar transação:
CEMT I TASK

🔐 8. Falta de logging (SMF desligado ou fraco)

👉 Sem trilha = sem investigação

💥 Resultado:

  • ataque invisível

✔️ Ataque:

  • ações sem rastreabilidade

🔥 Correção:

  • ativar SMF 80 (RACF), 30 (job), 110 (CICS)

🧠 9. Senhas fracas / padrão

👉 O clássico que nunca morre

💥 Exemplo:

  • USER: OPERADOR
  • PASS: OPERADOR

✔️ Ataque:

  • brute force / guessing

🔥 Correção:

  • regras RACF (PASSWORD RULES)

🔗 10. Integração insegura (APIs / z/OS Connect)

👉 O ponto mais moderno… e mais perigoso

💥 Cenário:

  • API exposta sem controle forte

✔️ Ataque:

  • acesso indireto ao mainframe

🔥 Exemplo:

  • chamada REST acessando backend CICS sem validação

🧠🔥 Padrão ouro dos ataques

👉 90% dos casos seguem esse fluxo:

  1. credencial fraca ou vazada
  2. acesso TSO / FTP
  3. enumeração de datasets
  4. exploração (APF / AC=1 / CICS)
  5. persistência
  6. exfiltração

💀 MITO vs REALIDADE (nível hardcore)

MitoRealidade
RACF protege tudo               só se bem configurado
APF é seguroé arma nuclear
Ninguém acessa TSOatacante ama TSO
Mainframe é isoladoAPI abriu a porteira

☢️Maior falha de sempre

Backdoor em online. As vezes para corrigir erros em produção são criados programinhas ocultos com muito poder de atualização. Caso caia em mãos erradas o estrago esta feito. Sem log, sem rastro, oculto entre programas quentes.

De boas inteçoes o inferno esta cheio.

🚀 Conclusão Bellacosa

“Mainframe não é hackeado por força…
é hackeado por permissão.”


 

 

terça-feira, 24 de abril de 2018

🧠 Deep Web & Dark Web: O Subsolo Invisível Onde Seus Dados COBOL Podem Já Estar Sendo Negociados

 

Bellacosa Mainframe mergulhando na Deep Web

🧠 Deep Web & Dark Web: O Subsolo Invisível Onde Seus Dados COBOL Podem Já Estar Sendo Negociados

“Você confia no seu batch. Mas… e se alguém lá fora já estiver confiando demais nos seus dados?”


🌐 A Internet que Você NÃO Vê (e que não aparece no Google)

Vamos direto ao ponto, no estilo raiz:

  • Surface Web → Google, portais, APIs abertas (menos de 5% da internet)
  • Deep Web → tudo que exige autenticação (intranets, sistemas bancários, CICS, DB2, etc.)
  • Dark Web → um subconjunto da Deep Web, acessado por redes anônimas como o Tor Browser

💡 Tradução para o mundo mainframe:
Seu ambiente z/OS, CICS, DB2, RACF está 100% dentro da Deep Web.
E isso não significa segurança — significa apenas não indexado.


🕳️ A Origem: Não foi crime… foi estratégia militar

A história começa com o laboratório naval dos EUA (U.S. Naval Research Laboratory), que criou o conceito de roteamento anônimo.

Objetivo original:

  • Proteger comunicações militares
  • Garantir anonimato em ambientes hostis

Resultado inesperado:

  • A tecnologia virou base para mercados ilegais

🛒 O Mercado Negro Digital: “eBay do Submundo”

Na Dark Web, existem marketplaces que lembram e-commerce:

  • Venda de dados roubados (cartões, credenciais)
  • Acesso a sistemas corporativos
  • Exploits zero-day
  • Serviços de ransomware “as a service”

Um dos casos mais emblemáticos:

  • Silk Road marketplace shutdown

Ali, vendia-se de tudo:

  • Drogas
  • Documentos falsos
  • E sim… acesso a sistemas corporativos comprometidos

💾 O Pesadelo do Analista COBOL Senior

Agora vem o ponto que poucos falam.

🔥 O que está sendo vendido que envolve mainframe?

  • Dumps de bases DB2 (com dados sensíveis)
  • Credenciais RACF comprometidas
  • Acessos VPN de operadores
  • Scripts JCL com lógica de negócio crítica
  • APIs expostas de integração (CICS Web Services / z/OS Connect)

💣 Realidade dura:
Você não precisa invadir um mainframe…
Basta comprar acesso de alguém que já invadiu.


⚠️ Vetores de ataque que chegam até o z/OS

Mesmo sendo robusto, o mainframe não vive isolado:

1. Integração moderna (o calcanhar de Aquiles)

  • REST APIs (z/OS Connect)
  • Web Services CICS
  • MQ, Kafka, integrações cloud

➡️ Se expôs… virou superfície de ataque.


2. Engenharia social (o clássico eterno)

  • Phishing em operadores
  • Roubo de credenciais RACF
  • Acesso indireto via desktop

➡️ O elo fraco não é o sistema… é o humano.


3. Supply chain (o perigo silencioso)

  • Ferramentas externas
  • Scripts automatizados
  • Pipelines DevOps mal protegidos

🧬 Easter Eggs da Dark Web (curiosidades que poucos sabem)

🔍 Existem motores de busca próprios, como o Ahmia
🧠 Muitos fóruns exigem “prova de crime” para entrar
💰 Pagamentos são feitos com Bitcoin e Monero
🕵️ Alguns marketplaces têm suporte ao cliente melhor que muito banco tradicional


🏦 Casos reais que impactam o mundo corporativo

  • Vazamento de dados bancários com origem em sistemas legados
  • Credenciais vendidas com acesso a ambientes produtivos
  • Dumps completos de clientes sendo comercializados

💥 E o mais crítico:
Muitos desses dados vieram de sistemas altamente confiáveis… e legados


🛡️ O que um Analista COBOL Senior PRECISA fazer

Aqui é onde você se diferencia.

✔️ Segurança não é só RACF

  • Revisar acessos com frequência
  • Princípio do menor privilégio

✔️ Blindar integrações

  • Autenticação forte (OAuth, certificados)
  • Monitoramento de APIs

✔️ Auditar logs de verdade

  • SMF, logs CICS, DB2
  • Detectar padrões anômalos

✔️ Pensar como atacante

  • Onde seu sistema está exposto?
  • Qual dado teria valor no mercado negro?

🧠 Reflexão no estilo Bellacosa

O mainframe nunca foi o problema.
O problema é o mundo ao redor dele.

Você pode ter:

  • Código COBOL impecável
  • JCL otimizado
  • Performance absurda

Mas se:

  • Uma credencial vaza
  • Um endpoint é exposto
  • Um operador é enganado

👉 Tudo isso vira produto… na Dark Web.


🚨 Conclusão: O novo papel do profissional de mainframe

O analista COBOL moderno precisa ser:

  • 🔐 Especialista em segurança
  • 🌐 Entendedor de integração
  • 🧠 Estratégico — não apenas técnico

Porque hoje…

Seu sistema não compete só com SLA.
Ele compete com criminosos altamente organizados.


💬 Provocação final

Se alguém hoje tivesse acesso ao seu ambiente…

👉 Quanto isso valeria na Dark Web?

E mais importante:

👉 Você saberia que isso já aconteceu?

sábado, 11 de fevereiro de 2017

Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team

 

Bellacosa Mainframe e o plano de ataque de ferris bueller 

☕ Um Café no Bellacosa Mainframe — Especial Red Team

Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team

🎬 Reconhecimento, criatividade adversarial e o princípio fundamental: não ataque a tecnologia; ataque as suposições de quem construiu o sistema

Chicago.

Década de 1980.

Computadores pessoais ainda tinham aquele ar de objeto mágico comprado por alguém que provavelmente também mantinha uma enciclopédia de 30 volumes na sala.

Não havia cloud.

Não havia SIEM.

Não havia EDR.

Não havia SOC 24x7.

Não havia dashboard piscando vermelho porque alguém da contabilidade tentou entrar no sistema às 03h17.

Não havia Zero Trust.

Também não havia LinkedIn dizendo exatamente onde você trabalha, qual tecnologia utiliza, qual certificação acabou de tirar, quem é seu gerente e qual projeto está colocando em produção na próxima terça-feira.

Mesmo assim, Ferris Bueller já havia entendido uma coisa que muita empresa ainda tenta aprender em 2026:

sistemas não são feitos apenas de computadores.

São feitos de pessoas.

Regras.

Rotinas.

Expectativas.

Horários.

Autoridade.

Confiança.

Telefonemas.

Burocracia.

E pequenas certezas que ninguém costuma questionar.

Ferris não precisava de um exploit de kernel.

Não precisava de malware.

Não precisava descobrir um buffer overflow.

Ele precisava apenas olhar para o mundo ao redor e perguntar:

“O que essas pessoas esperam que aconteça?”

E então fazer alguma coisa ligeiramente diferente.

Senhoras e senhores, bem-vindos ao primeiro episódio de:

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula


🔴 Antes de atacar, Ferris observa

Existe uma tendência quase infantil quando alguém começa a estudar segurança ofensiva.

A pessoa quer ferramentas.

Kali Linux.

Burp Suite.

Metasploit.

Nmap.

Hydra.

John the Ripper.

Wireshark.

E vinte abas abertas contendo comandos copiados de um tutorial.

Nada contra.

Ferramentas são importantes.

Mas Red Team começa antes.

Muito antes.

Começa com observação.

Ferris conhece o ambiente.

Ele conhece os pais.

Conhece a escola.

Conhece o diretor Rooney.

Conhece Cameron.

Conhece Sloane.

Conhece os horários.

Conhece os comportamentos esperados.

Sabe como um adolescente doente deveria parecer.

Sabe como adultos falam ao telefone.

Sabe quais histórias parecem plausíveis.

Sabe quem acredita em autoridade.

Sabe onde existe margem para improvisação.

Isso tem nome.

Reconhecimento.


🔎 Recon não é abrir o Nmap

Quando falamos em reconhecimento em segurança, muita gente imediatamente pensa:

nmap -sV -O target

Excelente.

Você descobriu portas.

Ferris descobriria pessoas.

A diferença não é pequena.

Imagine uma organização.

Você pode saber que ela possui:

443/tcp open
22/tcp open
8443/tcp open

Muito útil.

Mas imagine saber também:

que o administrador principal está de férias;

que a equipe está no meio de uma migração;

que existe uma manutenção emergencial naquela noite;

que o fornecedor externo costuma telefonar para o Service Desk;

que o diretor financeiro está viajando;

que funcionários recebem instruções urgentes pelo WhatsApp;

que um projeto específico utiliza credenciais técnicas compartilhadas.

Agora a superfície de ataque começa a parecer diferente.

Portas são tecnologia.

Contexto é poder.


☕ O primeiro exploit está na cabeça das pessoas

Uma vulnerabilidade tradicional costuma ser descrita assim:

Existe um comportamento inesperado no software que pode ser explorado.

Red Team amplia isso.

Também existe comportamento inesperado em organizações.

Um funcionário acredita que alguém falando com confiança deve saber o que está fazendo.

Um gerente acredita que um e-mail vindo de determinado endereço é confiável.

Um operador acredita que aquilo que aparece na tela corresponde à realidade.

Um administrador acredita que determinada conta nunca será usada indevidamente.

Um desenvolvedor acredita que uma API só será chamada pelo aplicativo oficial.

Essas crenças não aparecem no código.

Mas fazem parte do sistema.

Ferris é especialista nisso.


🧠 A primeira arma é a previsão

Ferris não controla tudo.

Ele prevê.

E previsão é extremamente poderosa.

Se você sabe que uma pessoa provavelmente reagirá de determinada maneira, você pode preparar o próximo movimento.

Pense como um atacante.

Se eu enviar esta solicitação, quem receberá?

Se chegar fora do horário comercial, haverá menos supervisão?

Se eu aparentar urgência, alguém pulará uma etapa?

Se eu mencionar o nome do gerente correto, minha história ficará mais convincente?

Se eu souber o jargão interno, parecerá que pertenço ao ambiente?

Perceba.

Até agora não atacamos nenhum computador.

Mas já estamos construindo um ataque.


🎯 Red Team é pensamento adversarial

Talvez essa seja uma definição melhor que muitas definições acadêmicas.

Red Team é a capacidade de olhar para um sistema e perguntar:

“Como alguém que não compartilha nossas intenções usaria isto?”

O desenvolvedor cria uma função.

O usuário utiliza a função.

O atacante pergunta:

“O que acontece se eu usar essa função para outra coisa?”

O RH cria um processo para redefinição de senha.

O funcionário legítimo usa o processo.

O atacante pergunta:

“Quais informações preciso saber para parecer o funcionário?”

A empresa cria uma API.

O aplicativo usa a API.

O atacante pergunta:

“A API sabe que sou o aplicativo?”

Essa mudança de perspectiva é gigantesca.


🧱 O sistema perfeito imaginário

Toda arquitetura nasce com premissas.

Algumas são técnicas.

Outras sociais.

Imagine este desenho:

USER
  ↓
APPLICATION
  ↓
API
  ↓
DATABASE

Simples.

Seguro.

Bonito.

Arquitetura aprovada.

Ferris olha.

E pergunta:

Quem cria o usuário?

Quem redefine sua senha?

Quem administra a aplicação?

Quem configura a API?

Quem possui acesso ao banco?

Quem aprova mudanças?

Quem lê logs?

Quem pode desabilitar alertas?

Quem possui acesso de emergência?

Quem testa restore?

Quem trabalha no fornecedor?

Subitamente nosso belo desenho fica assim:

USER
 ↓
HELP DESK
 ↓
IDENTITY SYSTEM
 ↓
APPLICATION
 ↓
API
 ↓
SERVICE ACCOUNT
 ↓
DATABASE
 ↓
BACKUP
 ↓
ADMIN
 ↓
VENDOR
 ↓
CLOUD

Agora estamos chegando perto da realidade.


🧀 Ferris descobriu o queijo suíço

Nenhum controle precisa estar completamente quebrado.

Basta que pequenas falhas se alinhem.

Imagine:

O funcionário publica demais no LinkedIn.

A empresa utiliza perguntas previsíveis para recuperação de conta.

O Help Desk trabalha sob pressão.

Existe uma conta antiga com privilégio excessivo.

O SOC não monitora determinado horário.

Separadamente?

Talvez nada aconteça.

Juntos?

OSINT
  ↓
Pretexto
  ↓
Reset de senha
  ↓
Conta legítima
  ↓
Privilégio excessivo
  ↓
Sistema crítico

Nenhuma cena cinematográfica.

Nenhuma tela verde.

Nenhum crânio piscando.

Apenas pequenas permissões fazendo amizade umas com as outras.


📞 Ferris entende interfaces humanas

Nós adoramos pensar em APIs.

Mas pessoas também possuem interfaces.

E muito menos documentação.

Uma pessoa recebe uma solicitação.

Analisa contexto.

Interpreta autoridade.

Avalia urgência.

Decide.

Essa decisão pode virar autorização.

Por isso engenharia social funciona.

Não porque humanos sejam estúpidos.

Mas porque sistemas humanos foram desenhados para colaborar.

Se toda solicitação fosse tratada como ataque, organizações parariam.

Ferris explora exatamente isso.

Ele não encontra uma pessoa burra.

Encontra uma pessoa cumprindo o papel esperado.


🏫 A escola como sistema de informação

Olhe para a escola de Ferris como uma arquitetura corporativa.

Temos:

Alunos
Professores
Secretaria
Direção
Pais
Registros
Telefone
Computadores
Procedimentos
Autoridade

Isto é um sistema.

Ferris não precisa quebrar todas as partes.

Ele precisa compreender como elas interagem.

É exatamente isso que Red Team faz.

Não se trata apenas de:

“Consigo comprometer este servidor?”

A pergunta mais interessante é:

“Consigo atingir um objetivo usando qualquer combinação disponível?”

Essa mudança de linguagem é fundamental.


🎯 Objetivo, não ferramenta

Uma operação Red Team deveria começar com um objetivo.

Por exemplo:

Obter acesso a determinado ambiente.

Não:

Usar phishing.

Phishing é técnica.

Talvez funcione.

Talvez não.

O objetivo permanece.

Então podemos tentar:

credenciais vazadas;

engenharia social;

exposição externa;

misconfiguração;

cadeia de fornecedores;

processos de recuperação;

acesso físico;

tokens;

integrações;

privilégios excessivos.

O atacante real não recebe KPI dizendo:

“Utilizar obrigatoriamente Metasploit em 37% da operação.”

Ele quer chegar ao objetivo.

Ferris também.


🚪 O atacante procura a porta que vocês esqueceram

Empresas costumam proteger aquilo que consideram importante.

Servidor principal?

Protegido.

Banco de dados?

Protegido.

Firewall?

Protegido.

Ferris pergunta:

“O que vocês não perceberam que também é uma porta?”

Uma impressora.

Um fornecedor.

Uma aplicação antiga.

Uma conta esquecida.

Uma VPN temporária.

Um endpoint de teste.

Uma integração criada durante pandemia.

Um funcionário terceirizado.

Um sistema legado.

Uma API mobile.

Um pipeline CI/CD.

Um chatbot.

Agora começamos a entender por que superfície de ataque cresce tão rápido.


🦖 E quando o alvo é mainframe?

Agora entramos no Bellacosa Mainframe propriamente dito.

Quando alguém pensa em atacar mainframe, frequentemente imagina:

HACKER
 ↓
3270
 ↓
TSO
 ↓
RACF
 ↓
z/OS

Talvez.

Mas Ferris provavelmente escolheria outra rota.

Ele perguntaria:

Quem conversa com o mainframe?

Talvez:

Mobile App
   ↓
API Gateway
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
Db2

Ou:

Cloud
 ↓
MQ
 ↓
Mainframe

Ou:

Git
 ↓
Pipeline
 ↓
Build
 ↓
Deploy
 ↓
z/OS

O ambiente principal pode possuir controles extraordinários.

Mas o atacante pode preferir comprometer a confiança ao redor dele.

É mais Ferris.

Menos Hulk.


🔐 Não ataque RACF se alguém já tem permissão

Essa frase merece moldura.

Imagine que Ferris deseja acessar um dataset.

Ele pode tentar quebrar RACF.

Difícil.

Ou encontrar uma conta legítima que já possui acesso.

Muito mais interessante.

Por isso identidade é tão importante.

O atacante não quer necessariamente destruir o controle de segurança.

Muitas vezes quer ser confundido com alguém autorizado.

Quando isso acontece, o sistema funciona perfeitamente.

E esse é o problema.


🤖 Ferris Bueller em 2026 seria assustador

O Ferris de 1986 trabalhava artesanalmente.

Observação manual.

Telefone.

Computador.

Improviso.

Conhecimento social.

O Ferris moderno teria ferramentas capazes de acelerar partes desse processo.

Análise de grandes volumes de informação.

Correlação de dados públicos.

Geração de mensagens.

Automação.

Agentes.

Reconhecimento de padrões.

Isso não elimina a necessidade de criatividade adversarial.

Amplifica.

A pessoa ainda precisa fazer a pergunta certa.

IA pode encontrar cem informações.

Ferris precisa perceber quais três formam uma história convincente.


🧠 O verdadeiro ativo do Red Team

Não é ferramenta.

É imaginação disciplinada.

Veja a combinação aparentemente banal:

Informação pública
+
comportamento previsível
+
processo legítimo
+
credencial válida
+
privilégio acumulado

Pode não existir CVE para isso.

Pode não existir patch.

Pode não existir assinatura no antivírus.

Mas existe risco.

E esse tipo de coisa é exatamente onde Red Team brilha.


🚨 “Mas nosso sistema nunca foi invadido”

Uma frase adorável.

Também perigosíssima.

Não ter evidência de invasão não significa necessariamente que seu sistema é seguro.

Pode significar:

ninguém tentou;

ninguém percebeu;

ninguém registrou;

ninguém correlacionou;

o atacante desistiu;

o atacante passou despercebido.

Ferris poderia passar o dia inteiro fora da escola.

Se ninguém verificasse corretamente, o sistema permaneceria convencido de que tudo estava normal.


👨‍💼 Rooney sofre de um problema clássico

Rooney sabe que Ferris está fazendo alguma coisa.

Mas concentra-se em Ferris como pessoa.

Isso pode virar uma forma de tunnel vision.

Em segurança, acontece algo semelhante.

A equipe possui uma hipótese.

Procura evidências dessa hipótese.

Ignora caminhos alternativos.

Um Red Team serve justamente para bagunçar essas certezas.

Talvez o ataque não venha de onde imaginávamos.

Talvez o controle mais caro não seja relevante.

Talvez o problema esteja naquele processo humilde que ninguém revisa desde 2009.


🧩 O exploit é a combinação

Aqui está o coração deste artigo.

Ferris não é perigoso porque possui uma ferramenta excepcional.

Ele é perigoso porque combina coisas comuns.

Telefone.

Computador.

Conhecimento.

Pessoas.

Rotina.

Autoridade.

Timing.

Individualmente, nenhuma é suficiente.

Juntas, produzem o efeito.

Em segurança chamamos isso de attack chain.

Ou, dependendo do contexto, attack path.

O atacante percorre pequenos passos.

Reconhecimento.

Acesso inicial.

Execução.

Persistência.

Escalada.

Movimento.

Objetivo.

O cinema gosta do clique mágico.

A realidade gosta de encadeamento.


☕ A pergunta Bellacosa

Se eu estivesse numa War Room avaliando segurança de qualquer ambiente, eu faria uma pergunta simples:

“Quais suposições precisam permanecer verdadeiras para este sistema continuar seguro?”

Depois listaria.

Usuários não compartilham senha.

Administradores revisam privilégios.

Logs permanecem íntegros.

Backups funcionam.

Fornecedores não são comprometidos.

APIs validam identidade corretamente.

Credenciais técnicas não vazam.

Funcionários reconhecem tentativas de fraude.

IA não executa instruções maliciosas.

Ótimo.

Agora o Red Team começa a trabalhar.

Uma por uma.


🔴 Segurança é testar certezas

Blue Team constrói controles.

Red Team testa controles.

Mas o melhor trabalho acontece quando testamos também certezas.

Você acredita que ninguém consegue alterar determinado dado?

Teste.

Acredita que o SOC detectará um comportamento?

Teste.

Acredita que MFA bloqueará um atacante?

Teste.

Acredita que um funcionário nunca liberaria determinada informação?

Teste de forma autorizada e segura.

Acredita que o mainframe está isolado?

Mapeie integrações.

Acredita que um agente de IA não pode executar determinada ação?

Valide.

Segurança baseada em esperança é apenas esperança usando crachá corporativo.


🎬 Ferris Bueller, Red Teamer acidental

Ferris não estudou MITRE ATT&CK.

Não possui OSCP.

Não abriu Kali Linux.

Não rodou Cobalt Strike.

Mas demonstra algo anterior a todas essas ferramentas:

pensamento adversarial.

Ele observa regras.

Entende expectativas.

Identifica fragilidades.

Combina recursos.

Prevê reações.

Adapta o plano.

E busca resultado.

Quase quarenta anos depois, essa mentalidade continua no centro de qualquer bom Red Team.

Porque o melhor atacante talvez não seja quem conhece mais comandos.

Pode ser quem olha para um ambiente complexo e percebe:

“Vocês estão protegendo a coisa errada.”


☕ Epílogo: o sistema também mata aula

Talvez seja por isso que Ferris continue tão divertido.

Ele percebe que instituições possuem regras.

Mas também percebe que regras dependem de modelos mentais.

A escola acredita conhecer seus alunos.

Os pais acreditam conhecer o filho.

O diretor acredita conhecer o comportamento de Ferris.

O sistema acredita conhecer o número de faltas.

Ferris testa cada uma dessas certezas.

Isso é Red Team.

Não destruir o sistema.

Não atacar por atacar.

Mas descobrir:

onde termina a realidade e começa a confiança na representação da realidade.

Em mainframe.

Em cloud.

Em redes.

Em IA.

Em pessoas.

Em 1986.

Em 2026.

A tecnologia muda.

A pergunta permanece.

“E se alguém decidir usar isso de um jeito que você nunca imaginou?”

Se sua arquitetura não possui resposta, talvez Ferris já esteja alguns passos à frente.

Enquanto Rooney procura por ele no corredor.

Enquanto Cameron atende o telefone.

Enquanto Sloane espera.

Enquanto o computador da escola continua tranquilamente executando suas rotinas.

E enquanto seu SOC exibe, orgulhosamente:

SECURITY STATUS: GREEN
ACTIVE INCIDENTS: 0

Ferris olha para a câmera.

Sorri.

E desaparece pela porta.

SAVE FERRIS.

No próximo café:

Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

Porque se o sistema diz que Ferris esteve na escola...

quem somos nós para discutir com o computador?

quinta-feira, 12 de janeiro de 2017

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula

Bellacosa Mainframe e o red team

☕ Um Café no Bellacosa Mainframe — Especial Red Team

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula

🎬 Ferris Bueller, engenharia social, computadores, confiança e a estranha arte de descobrir que o sistema acredita mais no banco de dados do que nos próprios olhos

Chicago, 1986.

Não existe ChatGPT.

Não existe LinkedIn.

Não existe Zero Trust.

Não existe SOC com 14 monitores mostrando mapas vermelhos enquanto alguém grita SEV-1.

Não existe MFA perguntando se você realmente é você.

Não existe aquele maravilhoso ritual moderno:

Digite sua senha.

Digite o código enviado ao celular.

Confirme no aplicativo.

Resolva o CAPTCHA.

Selecione todas as imagens contendo semáforos.

Sua sessão expirou.

Em algum lugar dos Estados Unidos, porém, existe algo muito mais perigoso.

Um adolescente inteligente.

Um computador.

Um telefone.

Muito tempo livre.

E uma instituição absolutamente convencida de que seus procedimentos funcionam.

Senhoras e senhores:

Ferris Bueller acaba de entrar no Red Team.


💾 Antes do Kali Linux havia Ferris Bueller

Quando pensamos em Red Team, é fácil imaginar uma sala escura.

Monitores.

Terminal Linux.

$ whoami
root

Um sujeito de capuz olhando para hexadecimal enquanto uma música eletrônica toca ao fundo.

Hollywood fez um belo estrago na nossa imaginação.

O verdadeiro atacante nem sempre começa procurando uma vulnerabilidade tecnológica.

Ele procura uma suposição.

Ferris Bueller é praticamente uma coleção ambulante delas.

A escola supõe que os alunos obedecerão.

Os pais supõem que o filho doente permanecerá na cama.

O restaurante supõe que alguém suficientemente convincente dizendo ser uma pessoa importante provavelmente seja essa pessoa.

O diretor supõe que perseguir Ferris resolverá o problema.

As pessoas supõem que aquilo que aparece no computador corresponde à realidade.

E Ferris?

Ferris pergunta silenciosamente:

“E se não corresponder?”

Bem-vindo ao Red Team.


🖥️ O computador da escola sabe quantas vezes Ferris faltou

Existe uma cena particularmente deliciosa para qualquer pessoa que passou a vida trabalhando com sistemas.

O registro escolar mostra as faltas de Ferris.

E então aquela informação começa a mudar.

A máquina registra uma realidade.

Ferris altera o registro.

A realidade administrativa muda junto.

Não importa que o corpo físico de Ferris tenha faltado.

Não importa que professores tenham visto sua cadeira vazia.

Não importa que alguém tenha contado suas ausências.

Para a burocracia, existe uma fonte oficial da verdade.

E a fonte oficial diz:

menos faltas.

Quarenta anos depois, continuamos cometendo exatamente o mesmo erro.

Só que agora chamamos isso de:

Single Source of Truth.


☕ “Mas está no sistema!”

Quem trabalha há algumas décadas com tecnologia conhece essa frase.

— O pagamento foi feito?

— Está no sistema.

— O cliente tem autorização?

— Está no sistema.

— O funcionário ainda trabalha aqui?

— Está no sistema.

— Esse usuário pode executar essa transação?

— Está no sistema.

— Esse processo realmente aconteceu?

— Está no sistema.

Maravilhoso.

Agora vem a pergunta desagradável do Red Team:

Quem pode alterar o sistema?

Essa pequena pergunta transforma uma tarde tranquila em uma reunião com Segurança, Auditoria, Compliance, Infraestrutura, Desenvolvimento e um gerente olhando para o teto.

Porque dados não são verdade.

Dados são representações da verdade.

E representações podem ser modificadas.


🔴 Red Team não pergunta apenas “é seguro?”

Essa talvez seja uma das diferenças fundamentais.

Uma organização olha para seu ambiente e pergunta:

“Estamos seguros?”

O Red Team pergunta:

“Como eu quebraria isso?”

Mas existe uma pergunta ainda melhor:

“O que vocês precisam acreditar para que isso funcione?”

Porque toda arquitetura possui pressupostos.

O usuário protegerá a senha.

O funcionário reconhecerá uma tentativa de fraude.

O administrador não abusará do privilégio.

O fornecedor protegerá sua integração.

O sistema legado receberá dados confiáveis.

A API será chamada apenas pelos sistemas autorizados.

O operador perceberá uma anomalia.

O backup funcionará.

O log não poderá ser alterado.

A IA reconhecerá uma instrução maliciosa.

Ferris Bueller olha para essa lista e sorri.


📞 Cameron, precisamos de você

Um dos aspectos mais interessantes de Curtindo a Vida Adoidado é que Ferris raramente depende de uma única técnica.

Ele combina recursos.

Computador.

Telefone.

Conhecimento das pessoas.

Improvisação.

Timing.

Cameron.

Sloane.

Expectativas sociais.

Autoridade.

Confusão.

Isso é muito mais próximo de uma operação adversarial real do que a imagem do hacker apertando freneticamente um teclado.

Imagine uma organização com cinco controles.

Firewall
   ↓
MFA
   ↓
EDR
   ↓
SIEM
   ↓
SOC

Parece formidável.

Agora imagine:

Atacante
   ↓
Funcionário
   ↓
Processo legítimo
   ↓
Credencial legítima
   ↓
Sistema legítimo

Houston...

Temos um problema.

O atacante não atravessou o firewall.

O firewall deixou o usuário autorizado entrar.


🌭 Abe Froman, o Rei da Salsicha de Chicago

E então chegamos a uma das minhas partes favoritas.

Ferris precisa de uma identidade.

Surge:

Abe Froman.

O Sausage King of Chicago.

É absurdo.

É maravilhoso.

E funciona porque identidade é uma construção social antes de ser uma construção tecnológica.

Você não precisa necessariamente demonstrar quem é.

Às vezes basta convencer alguém de que deveria ser aquela pessoa.

Esse princípio continua vivo em 2026.

Mudaram apenas as ferramentas.

Hoje temos:

Identity
↓
Authentication
↓
Authorization
↓
Privilege
↓
Action

E segurança moderna tenta impedir que uma coisa seja confundida com a seguinte.

Conhecer meu nome não prova que você sou eu.

Possuir minha senha não deveria necessariamente provar que você sou eu.

Conseguir autenticar-se não deveria significar que pode acessar tudo.

Ter acesso não deveria significar poder alterar qualquer coisa.

E poder alterar alguma coisa não deveria significar fazê-lo sem deixar evidências.

É por isso que Red Team adora identidades.

Porque organizações são construídas sobre confiança.


🔎 OSINT: Ferris conhece o ambiente

Existe outra característica fundamental.

Ferris presta atenção.

Ele conhece pessoas.

Conhece comportamentos.

Conhece horários.

Conhece relações.

Conhece expectativas.

Conhece a linguagem necessária para representar determinado papel.

Em segurança moderna chamamos parte disso de OSINT — Open Source Intelligence.

E existe uma quantidade quase obscena de informação disponível publicamente.

Uma organização publica que está contratando:

“Especialista em Kubernetes, AWS, Terraform, Jenkins e GitLab.”

Interessante.

Outra pessoa escreve:

“Orgulhoso de concluir nossa migração para determinada plataforma!”

Interessante.

Um administrador publica uma captura de tela comemorando uma certificação.

Interessante.

Um desenvolvedor deixa um projeto antigo no GitHub.

Interessante.

Um executivo anuncia uma viagem.

Interessante.

Uma empresa publica seu organograma.

Interessante.

Separadamente, quase nada disso parece perigoso.

Junto?

Ferris começa a montar o quebra-cabeça.


🧀 O queijo suíço de Ferris Bueller

É aqui que Red Team fica realmente fascinante.

Raramente existe uma vulnerabilidade cinematográfica:

APERTE ESTE BOTÃO E O BANCO EXPLODE.

Na vida real encontramos pequenas imperfeições.

Uma informação pública demais.

Uma permissão um pouco excessiva.

Uma conta antiga.

Um processo manual.

Uma senha reutilizada.

Uma API esquecida.

Um funcionário excessivamente prestativo.

Um fornecedor com acesso.

Um endpoint sem monitoramento adequado.

Uma exceção criada três anos atrás durante uma emergência.

Cada uma isoladamente parece tolerável.

Mas alinhe os buracos.

OSINT
  ↓
Engenharia Social
  ↓
Credencial
  ↓
Acesso
  ↓
Escalada
  ↓
Movimento Lateral
  ↓
Sistema Crítico

Parabéns.

Você acaba de transformar pequenas imperfeições em uma cadeia de ataque.

Ferris não precisa encontrar um buraco gigantesco.

Ele precisa encontrar buracos alinhados.


🚗 A Ferrari do Cameron é nosso ambiente de produção

Agora precisamos falar daquela Ferrari.

O pai de Cameron possui uma joia.

Uma máquina preciosa.

Protegida não necessariamente por controles técnicos sofisticados, mas por algo profundamente humano:

ninguém ousaria tocar nela.

Excelente estratégia.

Até aparecer Ferris Bueller.

Em tecnologia também fazemos isso.

— Ninguém mexe nesse dataset.

— Por quê?

— É produção.

— Existe controle impedindo?

— Não.

— Auditoria?

— Mais ou menos.

— Aprovação dupla?

— Não.

— Então por que ninguém mexe?

— Porque todo mundo sabe que não pode.

Ferris lentamente coloca os óculos escuros.

SAVE FERRIS.


🔐 Least Privilege: Cameron não deveria ter acesso à Ferrari

Aqui entra um dos conceitos mais importantes da segurança:

Least Privilege.

Você deve possuir apenas o acesso necessário para executar sua função.

Nada além.

Porque permissões acumulam-se.

Funcionários mudam de departamento.

Projetos terminam.

Contas permanecem.

Autorizações antigas sobrevivem.

Service accounts ganham poderes.

Exceções temporárias tornam-se permanentes.

E quinze anos depois alguém pergunta:

— Por que USER123 possui acesso administrativo?

Silêncio.

Um veterano olha para o horizonte.

— Acho que foi por causa daquela migração de 2011.

Ratchet Effect.

Privilégio entra.

Privilégio raramente sai.


🦖 E no mainframe?

Agora Ferris chegou ao meu território.

Se ele entrar no z/OS, as coisas ficam interessantes.

Porque o mainframe possui mecanismos extraordinariamente maduros de segurança.

RACF.

SAF.

Perfis.

Grupos.

Auditoria.

Segregação.

Controles de datasets.

Recursos protegidos.

Mas existe uma pergunta que sempre deve ser feita:

Como o mundo exterior chega até o mainframe?

Porque hoje não estamos falando apenas de alguém sentado num terminal 3270.

Temos:

Internet
   ↓
Aplicação
   ↓
API Gateway
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
Db2

Ou:

Cloud
 ↓
MQ
 ↓
Mainframe

Ou:

CI/CD
 ↓
Pipeline
 ↓
Credencial técnica
 ↓
Deploy
 ↓
Produção

O z/OS pode estar magnificamente protegido.

Ferris talvez nem tente atacá-lo diretamente.

Ele procura quem já possui autorização para conversar com ele.

Esse é o detalhe que muda tudo.


🤖 FerrisGPT entrou na escola

E chegamos a 2026.

O Ferris original precisava improvisar.

Pesquisar.

Telefonar.

Interpretar personagens.

Preparar histórias.

Coordenar pessoas.

Hoje podemos automatizar partes dessa preparação com IA.

LLMs podem ajudar a analisar grandes volumes de informação, organizar dados públicos, produzir textos convincentes, correlacionar documentos e operar como componentes de sistemas agentes.

Isso aumenta brutalmente a escala possível de certas operações.

O problema deixa de ser apenas:

“Existe alguém inteligente o suficiente para tentar?”

E passa a incluir:

“Quanto dessa inteligência operacional pode ser automatizada?”

Ao mesmo tempo surge uma superfície completamente nova.

Prompt injection.

Data poisoning.

Excesso de autonomia.

Agentes com privilégios demais.

Credenciais disponíveis no contexto.

Ferramentas conectadas.

RAG contaminado.

Confiança excessiva na resposta do modelo.

Ferris olha para um agente com acesso a e-mail, arquivos, APIs e banco de dados.

Ferris sorri.

O Blue Team começa a suar.


🛡️ E aqui precisamos colocar Rooney na história

Todo Ferris precisa de um Rooney.

O diretor sabe que alguma coisa está errada.

Ele suspeita.

Investiga.

Persegue.

Insiste.

E progressivamente torna-se tão obcecado pela própria hipótese que começa a cometer erros.

Isso também é segurança.

Analistas não são máquinas.

SOC não é máquina.

Red Team não é máquina.

Gestores não são máquinas.

Todos carregamos vieses.

Confirmation Bias.

Anchoring Bias.

Plan Continuation Bias.

Sunk Cost Fallacy.

Outcome Bias.

Automation Bias.

Você pode possuir todas as ferramentas corretas e ainda interpretar os sinais incorretamente.

Pior:

pode encontrar evidências que contradizem sua hipótese e decidir que elas apenas demonstram como o atacante é sofisticado.

Rooney acaba de entrar no SOC.


🚨 ALERTA CRÍTICO!

Imagine Rooney trabalhando num SIEM.

03:14:07 LOGIN FAILURE
03:14:11 LOGIN FAILURE
03:14:16 LOGIN SUCCESS
03:17:44 DATABASE QUERY
03:19:02 PRIVILEGE CHANGE

Rooney:

É O FERRIS!

Analista:

— Senhor, o usuário está de férias.

Rooney:

EXATAMENTE O QUE FERRIS QUER QUE VOCÊ PENSE!

Analista:

— O IP pertence à nossa VPN corporativa.

Rooney:

ELE É BOM!

Analista:

— O acesso foi aprovado pelo gerente.

Rooney:

ELE É MUITO BOM!

Nesse momento alguém deveria retirar Rooney da War Room.


🚗 Coloque a Ferrari em marcha a ré

Talvez nenhuma cena seja tão maravilhosa para um veterano de TI quanto a tentativa de desfazer a quilometragem da Ferrari.

A lógica parece perfeita.

O carro rodou para frente.

A quilometragem aumentou.

Então:

vamos rodar para trás.

Quem nunca viu raciocínio semelhante em produção?

— Podemos voltar?

— Temos backup.

— Testado?

Silêncio.

— Temos backup.

— Quando foi o último restore?

Silêncio ainda maior.

Backup não é restore.

Restore não é rollback.

Rollback não elimina necessariamente logs.

Rollback não apaga consequências.

Rollback não desfaz uma mensagem enviada.

Rollback não recupera confiança.

E colocar a Ferrari em marcha a ré certamente não garante que ela permaneça na garagem.

Produção não possui:

CTRL+Z emocional.


🔵 Então para que serve o Red Team?

Aqui está a parte mais importante.

Red Team não deveria existir para alguém aparecer numa reunião dizendo:

“HAHA! ENGANEI VOCÊS!”

Isso é infantil.

O objetivo não é humilhar o Blue Team.

Não é provar que alguém é hacker.

Não é colecionar shells.

Não é imprimir root numa camiseta.

O objetivo é descobrir alguma coisa que a organização não sabia sobre si mesma.

Talvez um controle não funcione.

Talvez funcione tecnicamente, mas possa ser contornado por processo.

Talvez uma detecção não exista.

Talvez o SOC veja o evento, mas não compreenda seu significado.

Talvez existam privilégios excessivos.

Talvez pessoas confiem demais numa determinada informação.

Talvez a arquitetura tenha criado uma cadeia inesperada.

Red Team produz conhecimento adversarial.

Hipótese
   ↓
Reconhecimento
   ↓
Simulação
   ↓
Evidência
   ↓
Detecção
   ↓
Correção
   ↓
Reteste

O ataque é apenas o instrumento.

Aprendizado é o produto.


☕ O Bellacosa Mainframe encontra Ferris Bueller

Talvez seja por isso que, quase quarenta anos depois, aquela cena do computador continue tão divertida.

A tecnologia envelheceu.

A tela envelheceu.

O computador envelheceu.

A interface envelheceu.

Mas a vulnerabilidade fundamental continua assustadoramente moderna:

alguém confiou no sistema sem perguntar suficientemente quem poderia alterar aquilo em que o sistema acreditava.

Essa pergunta atravessa décadas.

Mainframe.

Client/server.

Internet.

Cloud.

Mobile.

APIs.

IA.

Agentes.

Mudamos as interfaces.

Mudamos os protocolos.

Mudamos as linguagens.

Mudamos os nomes.

Mas continuamos construindo máquinas sobre camadas de confiança humana.

E sempre haverá algum Ferris perguntando:

“O que acontece se eu fizer isto?”


🎬 SAVE FERRIS

Esta será nossa viagem.

Nos próximos artigos, Ferris Bueller deixará de ser apenas o adolescente que queria matar aula.

Vamos transformá-lo em nosso Red Teamer acidental.

Vamos desmontar o computador da escola.

Conhecer Abe Froman.

Usar OSINT.

Telefonar para Cameron.

Perseguir Ferris com Rooney.

Proteger a Ferrari.

Tentar fazer rollback.

Entrar no mainframe.

Conversar com RACF.

Encontrar APIs.

Soltar FerrisGPT.

E descobrir que segurança talvez tenha muito menos a ver com construir uma muralha perfeita e muito mais com compreender como alguém inteligente tentaria contorná-la.

Porque existe uma diferença enorme entre:

“O sistema funciona.”

e:

“O sistema continua funcionando quando alguém deliberadamente tenta fazê-lo funcionar de uma maneira que jamais imaginamos.”

Essa segunda pergunta?

Essa é a pergunta do Red Team.

E como Ferris nos ensinou:

A vida passa muito rápido.

Os sistemas também.

E se você não parar de vez em quando para olhar para eles como um atacante...

pode descobrir tarde demais que Ferris já alterou o número de faltas, pegou Cameron, buscou Sloane, virou Abe Froman, saiu dirigindo a Ferrari...

...e o seu SIEM continua dizendo:

STATUS: GREEN
THREATS DETECTED: 0
ALL SYSTEMS OPERATIONAL

Bem-vindo ao Red Team.

SAVE FERRIS.

E, por favor, alguém coloque MFA naquela Ferrari.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

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.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...