 |
| Bellacosa Mainframe e a o banco de dados alterado |
☕ Um Café no Bellacosa Mainframe — Especial Red Team
Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade
💾 Ferris, registros escolares, integridade de dados e o perigo de confiar cegamente naquilo que aparece na tela
Chicago.
Uma escola.
Um diretor desconfiado.
Um aluno que já acumulou faltas suficientes para transformar o boletim numa pequena investigação administrativa.
E um computador.
A tela mostra um número.
Nove faltas.
O diretor Rooney conhece Ferris Bueller.
Conhece o histórico.
Conhece o comportamento.
Conhece a capacidade quase sobrenatural daquele adolescente de transformar regras em sugestões.
Ele suspeita.
Desconfia.
Quase consegue sentir que alguma coisa está errada.
Mas então acontece algo maravilhoso.
O número muda.
O computador registra outra realidade.
E, naquele instante, Ferris demonstra uma das vulnerabilidades mais antigas e persistentes da tecnologia:
quando a organização confunde o registro com a realidade.
Bem-vindo ao segundo episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
Hoje não vamos falar apenas de hackers.
Vamos falar de algo muito mais assustador.
Dados confiáveis demais.
🖥️ Se o computador diz, deve ser verdade
Quem trabalha com sistemas corporativos já ouviu alguma variação desta frase milhares de vezes:
— O pagamento foi feito?
— Está no sistema.
— O cliente possui autorização?
— Está no sistema.
— O funcionário está ativo?
— Está no sistema.
— A mercadoria saiu?
— Está no sistema.
— A transferência foi aprovada?
— Está no sistema.
— Esse usuário deveria possuir esse acesso?
— Está no sistema.
Maravilhoso.
Então está resolvido.
Exceto por uma pergunta ligeiramente inconveniente:
quem colocou essa informação no sistema?
E outra:
quem poderia alterá-la?
E uma terceira, ainda pior:
como saberíamos que foi alterada?
É aqui que o café começa a ficar forte.
💾 O dado não é a realidade
Essa distinção parece filosófica.
Mas é brutalmente prática.
Um banco de dados não armazena a realidade.
Armazena uma representação dela.
Se uma pessoa nasceu em determinada data, o sistema não armazena o nascimento.
Armazena algo como:
DATA_NASCIMENTO = 1980-03-14
Se um funcionário recebeu um pagamento, o sistema não armazena o ato econômico em si.
Armazena registros dizendo que aquilo ocorreu.
Se Ferris faltou à aula, o computador não armazena a cadeira vazia.
Armazena:
ABSENCES = 9
A diferença parece pequena.
Não é.
Porque a realidade física pode ser difícil de alterar.
O registro digital, às vezes, não.
🔴 Integridade: a palavra que parece chata até destruir sua empresa
Segurança costuma ser ensinada pela famosa tríade:
Confidencialidade
Integridade
Disponibilidade
A maioria das pessoas se apaixona imediatamente pela confidencialidade.
Senhas.
Criptografia.
Dados secretos.
Espionagem.
Hackers.
Tudo muito cinematográfico.
Disponibilidade também recebe atenção.
Sistema caiu?
Pânico.
Mas integridade frequentemente fica no meio, olhando para os lados, como aquele parente esquecido na fotografia.
Até o dia em que alguém altera alguma coisa.
Então todos descobrem que integridade era provavelmente a parte mais importante.
Porque um sistema disponível com dados errados pode ser pior que um sistema indisponível.
Muito pior.
☕ Imagine um banco perfeitamente disponível
Todos os servidores funcionando.
Nenhum downtime.
Rede perfeita.
Banco de dados online.
Aplicação respondendo em 50 milissegundos.
Usuários felizes.
Tudo verde.
Só existe um pequeno detalhe.
Alguém alterou:
SALDO = 10.000
para:
SALDO = 100.000
A disponibilidade está maravilhosa.
A confidencialidade talvez também.
Mas a integridade morreu.
E agora o sistema está funcionando perfeitamente para produzir resultados errados.
Isso é assustador.
🎬 Rooney sabe que alguma coisa está errada
É isso que torna a cena de Ferris tão interessante.
Rooney possui uma coisa que o computador não possui:
contexto.
Ele conhece Ferris.
Ele sabe que aquele número parece estranho.
A intuição diz:
“Isso não está certo.”
Mas organizações modernas frequentemente treinam pessoas a fazer o oposto.
O sistema virou autoridade.
A tela substitui o julgamento.
O operador pergunta.
O sistema responde.
Fim da conversa.
Esse é um tipo perigoso de automação cognitiva.
🧠 “Mas o sistema não pode estar errado”
Ah.
Pode.
Pode estar errado por defeito.
Pode estar errado por erro humano.
Pode estar errado por integração incorreta.
Pode estar errado por dado desatualizado.
Pode estar errado por fraude.
Pode estar errado porque alguém com privilégio alterou o registro.
Pode estar errado porque o próprio processo de entrada nunca foi confiável.
Pode estar errado porque um sistema anterior mandou informação errada.
Pode estar errado porque ninguém percebeu que o campo significava outra coisa.
E pode estar errado porque apareceu um Ferris Bueller.
🔐 Privilégio excessivo: quem pode alterar a verdade?
Aqui entramos num tema delicioso para Red Team.
Imagine um registro escolar.
Quem deveria poder alterar faltas?
Provavelmente poucos usuários.
Talvez professores.
Secretaria.
Administração.
Talvez algum processo automático.
Agora imagine que 40 pessoas possuem acesso.
Ou 400.
Ou uma conta técnica antiga.
Ou uma credencial compartilhada.
Ou um usuário com privilégio administrativo concedido cinco anos atrás para resolver uma emergência.
Você acaba de criar um pequeno mercado negro da verdade.
🪜 Least Privilege não é decoração de PowerPoint
O princípio de menor privilégio é simples:
cada identidade deve possuir apenas os acessos necessários para executar sua função.
Na prática, porém, organizações acumulam privilégios como minha geração acumulava disquetes.
Ninguém quer apagar nada.
Vai que precisa.
Então acontece:
2019 - acesso temporário
2020 - promoção
2021 - projeto emergencial
2022 - migração
2023 - suporte fornecedor
2024 - incidente
2025 - mudança de área
2026 - ninguém lembra por quê
Resultado:
O usuário que deveria consultar possui alteração.
O operador possui administração.
A conta de serviço possui permissões globais.
A aplicação antiga continua autenticando.
E Ferris agradece.
🧾 “Quem alterou isso?”
Essa é provavelmente uma das perguntas mais importantes de qualquer sistema crítico.
Não basta permitir alteração.
É necessário responder:
quem;
quando;
de onde;
qual valor anterior;
qual valor novo;
por qual processo;
com qual identidade;
sob qual autorização.
Isso é trilha de auditoria.
Sem isso, depois do incidente começa o esporte corporativo favorito:
arqueologia de logs.
📜 Antes e depois
Imagine um bom registro:
TIME: 10:42:11
USER: USER123
OBJECT: STUDENT.FERRIS
FIELD: ABSENCES
OLD_VALUE: 9
NEW_VALUE: 2
SOURCE: ADMIN_CONSOLE
SESSION: 883201
Agora temos alguma coisa.
Podemos perguntar:
USER123 deveria fazer isso?
Estava trabalhando naquele horário?
A sessão era legítima?
Houve aprovação?
Existe outro evento relacionado?
O IP é esperado?
O dispositivo é conhecido?
Perceba como a investigação muda.
Sem log:
— Alguém mudou.
Com log:
— Podemos reconstruir a história.
🕵️ Insider Threat: o inimigo já tem crachá
Outra coisa importante.
Quando falamos de ataque, imaginamos frequentemente alguém de fora.
O hacker misterioso.
O russo numa sala escura.
O adolescente no porão.
O grupo criminoso.
Mas muitos sistemas podem ser abusados por quem já possui acesso.
Isso é insider threat.
E insider não significa necessariamente um funcionário maligno tramando destruir a empresa.
Pode ser:
funcionário fraudando;
administrador curioso;
terceirizado abusando de acesso;
usuário cometendo erro;
conta legítima comprometida por atacante externo.
O sistema vê uma identidade autorizada.
Mas não sabe necessariamente se a intenção é legítima.
🧠 O problema da identidade válida
Isso é particularmente perverso.
Defesas tradicionais procuram comportamento obviamente hostil.
Mas imagine:
LOGIN = SUCCESS
MFA = SUCCESS
USER = AUTHORIZED
ACTION = ALLOWED
Tudo certo.
Só que a pessoa por trás da sessão não deveria estar fazendo aquilo.
Ou talvez nem seja a pessoa.
Do ponto de vista técnico, o sistema está funcionando.
Do ponto de vista de segurança, você tem um incidente.
Ferris provavelmente adoraria essa zona cinzenta.
🏦 Agora troque escola por banco
Vamos aumentar um pouco o tamanho do problema.
Em vez de:
ABSENCES = 9
temos:
CREDIT_LIMIT = 50.000
ou:
ACCOUNT_STATUS = ACTIVE
ou:
TRANSFER_APPROVED = YES
Agora integridade deixa de ser tema escolar.
Vira dinheiro.
Compliance.
Auditoria.
Regulação.
Fraude.
🦖 E no mainframe?
Aqui o assunto fica especialmente interessante.
Mainframes são máquinas construídas em torno de processamento confiável.
Transações.
Registros.
Contabilidade.
Bancos.
Seguradoras.
Governos.
Sistemas onde dados não podem simplesmente “mais ou menos” estar corretos.
Imagine um ambiente:
CICS
↓
COBOL
↓
Db2
O usuário executa uma transação.
O programa altera um registro.
O banco confirma.
Tudo perfeito.
Mas segurança não pergunta apenas:
a transação funcionou?
Pergunta:
quem tinha autoridade para executá-la?
🔐 RACF não lê sua alma
RACF pode controlar quem acessa o quê.
Pode ser extremamente granular.
Pode registrar eventos.
Pode aplicar políticas.
Mas existe uma verdade desconfortável:
um sistema de controle de acesso valida identidade e permissão.
Não intenção.
Se uma conta autorizada é comprometida, o controle pode legitimamente permitir a ação.
Por isso segurança moderna precisa de camadas.
Autenticação.
Autorização.
Monitoramento.
Auditoria.
Detecção comportamental.
Segregação de funções.
Revisão.
🧱 Segregação de funções: não dê a Ferris o lápis e a borracha
Uma das maneiras mais antigas de reduzir fraude é simples:
não permita que uma única pessoa controle todo o processo.
Quem cria não aprova.
Quem solicita não executa.
Quem altera não audita.
Isso é segregation of duties.
Porque se uma pessoa pode:
CREATE
ALTER
APPROVE
DELETE_LOG
então ela basicamente possui a versão corporativa do poder de Ferris sobre suas faltas.
Pode mudar a realidade e apagar as pegadas.
Nada ideal.
🚨 O log também precisa de integridade
Aqui aparece uma pegadinha elegante.
Você criou auditoria.
Excelente.
Mas quem pode alterar o log?
Se o mesmo administrador que modifica dados pode apagar eventos, temos um problema.
É como instalar uma câmera de segurança e deixar o suspeito com a chave da sala onde ficam as gravações.
Logs precisam ser protegidos.
Idealmente enviados para outro ambiente.
Com retenção.
Controles.
Imutabilidade quando possível.
Porque a trilha de auditoria só é útil se também for confiável.
🧼 “Não encontramos evidência”
Outra frase maravilhosa.
Às vezes significa:
não aconteceu.
Às vezes significa:
ninguém procurou direito.
Às vezes:
os logs não existiam.
Às vezes:
os logs foram apagados.
Às vezes:
o evento aconteceu num sistema diferente.
E às vezes:
a investigação estava procurando no lugar errado.
Red Team adora essa questão.
Não basta perguntar:
“O ataque seria bloqueado?”
Pergunte também:
“Seria detectado?”
E depois:
“Conseguiríamos explicar o que aconteceu?”
🧭 Prevenção sem detecção é fé
Imagine duas empresas.
Empresa A possui controles excelentes.
Mas praticamente nenhuma visibilidade.
Empresa B possui controles razoáveis e ótima detecção.
Qual é mais segura?
Depende.
Mas a empresa A talvez nunca saiba quando o controle falhar.
Isso é perigoso.
Nenhum controle é perfeito.
Então Red Team deve testar:
prevenção;
detecção;
resposta.
Ferris pode conseguir alterar o número.
A pergunta seguinte é:
alguém perceberia?
📊 “Está no dashboard”
Em 2026 temos uma nova versão do mesmo problema.
Não apenas:
“Está no sistema.”
Agora temos:
“Está no dashboard.”
O dashboard mostra verde.
Então está tudo bem.
Talvez.
Mas dashboards também são representações.
Eles dependem de:
dados;
regras;
queries;
thresholds;
integrações;
timing.
Se qualquer uma dessas partes estiver errada, você terá uma bela visualização de uma realidade inexistente.
🤖 E agora temos IA dizendo o que é verdade
A coisa ficou ainda mais interessante.
Sistemas modernos podem resumir logs.
Interpretar eventos.
Classificar risco.
Priorizar alertas.
Gerar respostas.
Fantástico.
Mas existe o perigo de transformar:
SYSTEM SAYS
em:
TRUTH
Agora não é apenas um campo no banco.
É uma interpretação automatizada.
E usuários podem confiar demais.
Automation Bias entra pela porta.
🧠 O operador acredita na máquina
Suponha que um analista veja:
RISK SCORE: LOW
Pode relaxar.
Mas como esse score foi calculado?
Quais sinais entraram?
Algum dado estava faltando?
Um atacante conseguiu influenciar a entrada?
O modelo conhece aquele padrão?
A confiança na ferramenta pode ser explorada tanto quanto qualquer outra confiança.
Ferris não precisa enganar apenas pessoas.
Pode enganar as máquinas que ajudam pessoas a decidir.
🧪 Data Poisoning: Ferris aprende estatística
Vamos imaginar uma versão moderna.
Se um sistema aprende padrões históricos, o que acontece se alguém conseguir contaminar esses padrões?
Pouco a pouco, comportamentos anormais podem parecer normais.
Isso é uma forma de data poisoning.
A velha cena de Ferris ganha nova vida.
Ele não precisa apenas alterar:
ABSENCES = 9
Talvez queira alterar o mecanismo que decide o que significa “frequência normal”.
A escala muda.
A filosofia permanece.
🧾 Fonte da verdade não significa fonte infalível
Empresas adoram a expressão:
Single Source of Truth.
É útil.
Evita sistemas discordando.
Centraliza informação.
Mas existe um problema semântico.
Uma fonte única da verdade não é necessariamente verdadeira.
Ela é apenas a fonte que todos concordaram em usar.
Se estiver errada, todos errarão de maneira consistente.
Isso é operacionalmente elegante.
E filosoficamente aterrorizante.
💣 Uma verdade errada propagada perfeitamente
Imagine:
Sistema A registra valor errado.
Sistema B consome.
Sistema C replica.
Data lake armazena.
Dashboard mostra.
IA resume.
Executivo recebe relatório.
Agora temos:
ERRO
↓
INTEGRAÇÃO
↓
PROPAGAÇÃO
↓
ANÁLISE
↓
DECISÃO
A cadeia inteira funcionou perfeitamente.
Parabéns.
Você automatizou o erro.
🎯 Red Team precisa atacar a confiança nos dados
Esse tipo de exercício é extremamente valioso.
Não apenas:
“Consigo acessar o banco?”
Mas:
“Consigo modificar um dado crítico?”
“Isso dispara alerta?”
“Qual sistema percebe?”
“Quanto tempo leva?”
“Quem investiga?”
“Existe reconciliação?”
“Existe validação independente?”
“Existe dupla aprovação?”
“Existe trilha?”
Agora estamos testando integridade de verdade.
🧠 A pergunta Bellacosa
Eu faria uma pergunta particularmente desagradável numa War Room:
“Qual dado, se alterado silenciosamente, poderia causar mais estrago sem derrubar nenhum sistema?”
Pense.
Talvez não seja senha.
Talvez seja:
limite de crédito;
status de cliente;
conta bancária de fornecedor;
parâmetro de juros;
identidade;
regra fiscal;
preço;
saldo;
permissão;
modelo de risco.
Isso é uma superfície de ataque completamente diferente.
🚦 Sistema verde, negócio vermelho
Imagine:
CPU normal.
Disco normal.
Rede normal.
Banco online.
CICS respondendo.
MQ fluindo.
APIs funcionando.
Tudo verde.
Só que alguém alterou uma tabela de parâmetros.
Agora cada transação está ligeiramente errada.
Nada cai.
Nada trava.
Nenhum alerta tradicional dispara.
O sistema virou uma máquina perfeitamente funcional de produzir prejuízo.
Esse tipo de incidente é muito mais interessante que simplesmente derrubar um servidor.
🧩 Ferris não quer destruir a escola
Essa é outra razão pela qual a metáfora funciona.
Ferris não quer incendiar o prédio.
Não quer destruir o computador.
Não quer impedir a escola de funcionar.
Quer apenas fazer o sistema acreditar em outra versão da realidade.
Atacantes financeiros frequentemente preferem exatamente isso.
Silêncio.
Discrição.
Mudanças pequenas.
Persistentes.
Porque interrupção chama atenção.
Fraude silenciosa paga melhor.
🕶️ O atacante perfeito talvez pareça um usuário normal
Essa é uma das conclusões mais importantes.
Se a ação maliciosa parece uma ação autorizada, detecção fica difícil.
Por isso precisamos de contexto.
Quem normalmente faz isso?
Em qual horário?
Com qual frequência?
De qual dispositivo?
Em qual volume?
Depois de qual evento?
Segurança não pode olhar apenas para:
ALLOW
DENY
Precisa olhar para comportamento.
🔵 Rooney versus o computador
Voltemos a Rooney.
Ele possui intuição.
O computador possui registro.
A segurança madura precisa dos dois.
Dados.
Contexto.
Automação.
Experiência humana.
Nenhum deveria dominar cegamente.
Rooney também pode estar errado.
Sua obsessão por Ferris prova isso.
Mas o computador também pode.
A chave é não transformar nenhuma fonte em autoridade absoluta.
☕ “Está no sistema” não significa “é verdade”
Essa frase deveria estar impressa em muitas salas de operação.
Talvez em letras grandes.
Porque sistemas registram aquilo que conseguimos observar.
E aquilo que alguém informou.
E aquilo que integrações enviaram.
E aquilo que processos permitiram.
Eles não possuem acesso mágico à realidade.
Então sempre precisamos perguntar:
Como esse dado nasceu?
Quem pode alterá-lo?
Como validamos?
Como auditamos?
Como detectamos inconsistências?
🔴 Integridade é confiança verificável
No final, integridade significa uma coisa muito simples:
poder confiar que informação não foi alterada de maneira indevida.
Mas “confiar” não pode significar fé.
Precisa existir evidência.
Controles.
Logs.
Reconciliação.
Segregação.
Revisão.
Detecção.
E capacidade de reconstruir eventos.
🎬 Ferris Bueller e o primeiro ataque à verdade digital
Talvez Ferris não tivesse percebido a profundidade filosófica do que estava fazendo.
Provavelmente só queria matar aula.
Mas aquele computador escolar antecipou um problema que cresceria enormemente nas décadas seguintes.
O mundo passou a depender cada vez mais de registros digitais.
Dinheiro virou registro.
Identidade virou registro.
Propriedade virou registro.
Saúde virou registro.
Reputação virou registro.
Autorizações viraram registros.
E quanto mais a sociedade digitaliza, maior fica o valor de alterar silenciosamente aquilo que ela acredita ser verdade.
☕ Epílogo: nove faltas desapareceram
Rooney olha para Ferris.
Ferris olha para o computador.
O computador olha para ninguém.
Ele apenas executa comandos.
Essa talvez seja a parte mais importante.
A máquina não sabe que está mentindo.
Ela não sabe que está dizendo a verdade.
Ela simplesmente armazena estado.
Nós é que atribuímos confiança.
E é exatamente essa confiança que Red Team deve testar.
Porque entre:
REALITY
e:
DATABASE
existe sempre um caminho.
Alguém coleta.
Alguém transmite.
Alguém grava.
Alguém altera.
Alguém consulta.
Alguém interpreta.
Cada etapa pode falhar.
Cada etapa pode ser abusada.
Cada etapa pode virar uma porta.
Então da próxima vez que alguém disser:
“Mas está no sistema.”
Sirva outro café.
Olhe para Ferris.
E faça a pergunta mais importante:
“Quem disse ao sistema que isso era verdade?”
☕ SAVE FERRIS.
No próximo artigo:
Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu
Porque talvez você não precise hackear um banco de dados.
Talvez precise apenas convencer alguém de que você deveria estar sentado naquela mesa.
☕ 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.
