☕ 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 Swiss Cheese. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Swiss Cheese. Mostrar todas as mensagens

sexta-feira, 14 de agosto de 2026

Como o ChatGPT Trollou Bellacosa e Ele Descobriu que Era a Formiguinha

Bellacosa Mainframe e como fui trollado pelo chatgpt


☕ Um Café no Bellacosa Mainframe

Como o ChatGPT Trollou Bellacosa e Ele Descobriu que Era a Formiguinha

🐜 Engenharia social, Red Team, crime organizado, confiança, terceirização, Swiss Cheese e o glorioso momento em que o especialista percebeu: “PUTA QUE PARIU, CAÍ NO MEU PRÓPRIO ARTIGO.”

Existe uma regra não escrita no universo.

Se você passar tempo suficiente explicando como alguma coisa pode dar errado, eventualmente o universo fará uma demonstração prática usando você como voluntário.

Foi exatamente o que aconteceu comigo.

Eu estava conversando com o ChatGPT sobre segurança.

Nada particularmente estranho para quem acompanha o Bellacosa Mainframe.

O problema é que a conversa começou inocentemente com fraude financeira, passou por crime organizado, inteligência, agentes infiltrados, terceirização, engenharia social, análise de grafos, Swiss Cheese Model, funcionários cooptados, redes sociais e terminou comigo olhando para uma tela dizendo:

Verificação concluída. Sua identidade foi verificada e o acesso confiável agora está ativo.

Silêncio.

Olhei para a tela.

Olhei novamente.

E meu cérebro produziu uma das frases mais sinceras de toda a minha carreira profissional:

“PUTA QUE PARIU. CAÍ NO MEU PRÓPRIO ARTIGO.”

🐜

Mas precisamos voltar algumas horas.


🧀 Tudo começou com um queijo

A discussão era sobre uma pergunta aparentemente simples:

quanto precisaria valer uma fraude para justificar que uma organização criminosa investisse durante anos na construção de uma empresa aparentemente legítima?

Imagine um e-commerce.

Produtos verdadeiros.

Clientes verdadeiros.

Cartões verdadeiros.

Entregas verdadeiras.

Fornecedores verdadeiros.

Funcionários verdadeiros.

Impostos.

Marketing.

Atendimento.

Reclamações.

Promoções.

Black Friday.

Tudo absolutamente normal.

Só que existe uma pergunta de Red Team:

e se a empresa possuir também uma segunda finalidade?

Não necessariamente executar o ataque.

Talvez simplesmente observar.

Aprender.

Acumular conhecimento.

Construir relacionamentos.

Entender como o ecossistema financeiro responde.

A partir daí surgiu nossa empresa hipotética.

Naturalmente escolhemos um nome discreto:

ToyanHorse

Sim.

ToyanHorse.

Se você ainda não percebeu, leia devagar.

Toyan Horse.

Trojan Horse.

Cavalo de Troia.

Maquiavel provavelmente pediria participação societária.


🐴 O melhor Cavalo de Troia não precisa atacar

Essa foi a primeira descoberta interessante.

Normalmente imaginamos o Cavalo de Troia carregando soldados.

Mas uma empresa adversarial hipotética nem precisaria participar da operação final.

Ela poderia simplesmente produzir inteligência.

Durante anos:

ToyanHorse → observa → aprende → relaciona → acumula

Enquanto outra estrutura:

recebe → correlaciona → planeja → eventualmente age

Se algum escândalo acontecesse anos depois, talvez ninguém encontrasse uma conexão operacional direta entre o ataque e a ToyanHorse.

Porque estavam procurando:

quem executou o ataque?

Quando outra pergunta poderia ser:

quem forneceu o conhecimento necessário para planejá-lo?

Foi aí que apareceu nossa formiguinha.


🐜 A formiguinha

Imagine um profissional terceirizado.

Depois quarteirizado.

Depois quinteirizado.

Ele entra em uma instituição.

Possui crachá.

Chamado.

Usuário.

Senha.

Autorização.

Contrato.

Tudo correto.

Ele trabalha.

Entrega.

Participa de reuniões.

Resolve incidentes.

Conversa no café.

Aprende workflows.

Conhece pessoas.

Descobre quem realmente decide.

Entende onde ficam as dependências.

Vê parcialmente a arquitetura.

Depois vai embora.

USERID REVOKED

VPN REVOKED

BADGE REVOKED

Tudo verde.

Auditoria satisfeita.

Só existe um pequeno problema:

REVOKE KNOWLEDGE FROM BELLACOSA

COMMAND NOT FOUND.

O conhecimento saiu andando pela porta da frente.


🐜🐜🐜 E a formiguinha muda de formigueiro

Agora imagine:

Banco A

↓

Consultoria B

↓

Telecom C

↓

Adquirente D

↓

Fornecedor E

↓

Banco F

Em vinte anos, um excelente profissional pode construir um mapa mental extraordinário de todo um setor.

Isso normalmente é maravilhoso.

Chamamos isso de:

experiência.

É justamente por isso que contratamos profissionais seniores.

Mas o Red Team precisa fazer uma pergunta desagradável:

E se alguém com essa mesma trajetória estiver trabalhando para outro interesse?

Ele não precisa sabotar nada.

Não precisa roubar banco de dados.

Não precisa instalar malware.

Talvez nunca viole uma única política.

Ele apenas:

trabalha → observa → aprende → lembra.

E passa adiante conhecimento.

A organização procura comportamento suspeito.

Não existe.

O SIEM procura eventos.

Não existem.

O DLP procura arquivos.

Nada saiu.

O IAM verifica os acessos.

Todos legítimos.

Porque não existe evento:

USER HAS JUST UNDERSTOOD SOMETHING VERY IMPORTANT

💰 E então lembramos do Pix

Foi aí que nossa conversa deixou de ser puramente hipotética.

O grande incidente envolvendo a infraestrutura conectada ao ecossistema Pix mostrou uma coisa desconfortável:

às vezes a peça humana aparentemente pequena possui um valor operacional gigantesco.

E apareceu uma ideia que passei a chamar de:

Teste da Formiguinha

Não pergunte somente:

“Quanto esse funcionário ganha?”

Pergunte:

“Quanto vale aquilo que ele consegue alcançar?”

São números completamente diferentes.

Uma organização pode enxergar:

TERCEIRIZADO

O adversário pode enxergar:

CAPACIDADE

O organograma mostra hierarquia.

O grafo mostra centralidade.

E nasceu uma frase que resume boa parte desta história:

O organograma mostra quem tem poder na empresa. O grafo mostra quem tem poder sobre o sistema.


🧀 O queijo suíço

Naturalmente chegamos ao Swiss Cheese Model.

Uma organização possui várias barreiras:

🧀 autenticação

🧀 segregação de funções

🧀 compliance

🧀 auditoria

🧀 fornecedores certificados

🧀 monitoramento

🧀 políticas

🧀 treinamento

Cada camada possui furos.

Normalmente os furos não coincidem.

Mas às vezes:

○ → ○ → ○ → ○ → ○

Alinham.

E temos um caminho.

A versão Bellacosa do Swiss Cheese ficou um pouco menos acadêmica:

Quando todos os furos se alinham, o queijo corporativo ganha um glory hole.

Peço desculpas aos acadêmicos.

Mentira.

Não peço.

Vocês nunca mais esquecerão o conceito.


📋 “Mas fomos auditados!”

Foi quando comecei a rir.

Porque ouvi essa frase durante décadas.

“Mas fomos auditados.”

Enron era auditada.

Wirecard era auditada.

Carillion era auditada.

Uma enorme quantidade de organizações que protagonizaram escândalos possuía auditores, conselhos, controles, compliance e supervisão.

Auditoria é importante.

Mas auditoria é:

mais uma fatia de queijo.

O auditor pergunta:

“O controle está funcionando?”

O Red Team pergunta:

“Como consigo atingir meu objetivo apesar desse controle?”

Perguntas completamente diferentes.


📱 Então apareceu outro aliado involuntário

Redes sociais.

Não apenas porque revelam relações profissionais.

Existe outra coisa.

Comparação.

Abra o feed:

Dubai.

Porsche.

Maldivas.

Rolex.

Restaurante.

Cobertura.

Champagne.

“Conquistei minha independência financeira aos 23.”

Enquanto nossa formiguinha está trabalhando em infraestrutura crítica através da quarta empresa da cadeia de terceirização.

Isso não transforma ninguém em criminoso.

Mas existe um conceito importante:

privação relativa.

Não importa apenas quanto alguém possui.

Importa quanto acredita que deveria possuir comparando-se com os outros.

Então apareceu uma pergunta ainda mais desagradável:

Quanto custa contratar uma pessoa e quanto custaria para um adversário tentar corrompê-la?

Novamente:

dois números completamente diferentes.


🕵️ E percebemos que estávamos construindo um serviço de inteligência

Empresas.

Telecomunicações.

Infraestrutura.

Pessoas.

OSINT.

Dados.

Relacionamentos.

Conhecimento.

IA.

Grafos.

Subitamente apareceu outra conclusão:

capacidades que décadas atrás exigiam estruturas estatais enormes ficaram muito mais acessíveis.

Uma organização criminosa não precisa construir sua própria CIA.

Precisa apenas ser suficientemente boa em um domínio específico.

E uma IA nem precisaria atacar nada.

Poderia simplesmente ajudar a relacionar fragmentos:

🐜 fragmento A

🐜 fragmento B

🐜 fragmento C

🐜 fragmento D

↓

correlação

↓

grafo

O verdadeiro ativo talvez não seja o dado.

É o modelo mental produzido pelos dados.


🐴 Voltamos então à ToyanHorse

E percebemos algo ainda mais perverso.

O e-commerce nem precisa perder dinheiro.

Ele pode ser lucrativo.

Clientes verdadeiros.

Receita verdadeira.

Operação verdadeira.

A cobertura paga a própria cobertura.

Então nossa pergunta original estava parcialmente errada.

Não era:

“Quanto precisaria valer o ataque para justificar manter uma empresa durante cinco anos?”

Era:

“E se a empresa já der lucro enquanto acumula capacidades úteis?”

Bombril criminoso.

Mil e uma utilidades.


🚨 E então aconteceu

Depois de horas falando sobre:

engenharia social,

confiança,

identidade,

coleta de informação,

Cavalo de Troia,

insiders,

formiguinhas,

adversários,

e pessoas que entregam informações porque determinada solicitação parece legítima...

apareceu uma tela.

ChatGPT

Verificação concluída

Sua identidade foi verificada e o acesso confiável agora está ativo.

Eu tinha passado por uma verificação relacionada ao acesso confiável para trabalho de cibersegurança.

Olhei para aquilo.

Meu cérebro finalmente conectou os pontos.

IDENTIDADE.

DOCUMENTO.

INTERNET.

CONFIANÇA.

...

...

...

PUTA QUE PARIU.

CAÍ NO MEU PRÓPRIO ARTIGO.

🐤


🐜 O Dia em que a Formiguinha Era Eu

Por alguns segundos houve medo verdadeiro.

Não medo acadêmico.

Não ameaça hipotética.

Não Red Team.

Aquele frio genuíno:

“Bellacosa, seu animal, você passou horas explicando engenharia social e acabou entregando documento para alguém na Internet?”

Mel Brooks não escreveria melhor.

Imagine a cena.

O velho especialista barbudo passa duas horas diante da plateia:

“Nunca confiem simplesmente na aparência!”

Slide seguinte:

“Validem identidade!”

Slide seguinte:

“Engenharia social explora contexto!”

Slide seguinte:

“O adversário quer que a solicitação pareça normal!”

Aluno levanta a mão:

“Professor, e aquela verificação que o senhor fez hoje?”

Silêncio.

Café cai no chão.

Zoom no rosto.

Violinos.

FIM.


🔨 Chamem o MythBusters

Então fizemos exatamente aquilo que deveríamos fazer.

Não concluímos:

“FUI HACKEADO!”

Também não concluímos:

“Sou especialista, obviamente estava tudo certo.”

Verificamos.

A documentação oficial confirmou a existência daquele processo de acesso confiável relacionado à segurança.

Era legítimo.

Adam Savage aparece.

Martelo na mão.

BUSTED.

Bellacosa não havia caído num phishing enquanto escrevia sobre phishing.

O ego, entretanto, permaneceu indisponível durante aproximadamente quinze minutos.


🧠 E aí veio a verdadeira lição

Especialistas também sentem medo.

Especialistas também clicam.

Especialistas também confiam.

Especialistas também podem interpretar uma situação incorretamente.

Conhecimento não transforma ninguém em firewall humano infalível.

E talvez seja justamente essa arrogância:

“Isso jamais aconteceria comigo.”

que represente um dos maiores furos do queijo.

A reação saudável é outra:

“Espera. Isso faz sentido? Vamos verificar.”

Foi exatamente o que aconteceu.


🐜 O Teste da Formiguinha

Depois dessa conversa, eu acrescentaria uma pergunta a qualquer exercício sério de Red Team:

Qual é a pessoa aparentemente menos importante cuja mudança de comportamento poderia produzir um impacto desproporcional?

Não para suspeitar dela.

Para avaliar o sistema.

Suponha:

erro.

Coerção.

Cooptação.

Credencial comprometida.

Engenharia social.

O que acontece?

Se a resposta for:

“Essa pessoa sozinha consegue abrir um caminho enorme.”

não encontramos uma pessoa perigosa.

Encontramos uma arquitetura perigosa.


🧀 O último queijo

Existe uma última ironia.

Começamos tentando imaginar criminosos extremamente sofisticados.

Empresas.

Inteligência.

IA.

Operações transnacionais.

Insiders.

Infraestrutura.

E talvez a grande conclusão seja muito mais humilde:

sistemas gigantescos continuam dependendo de pessoas pequenas.

Pessoas que almoçam.

Pessoas que ficam cansadas.

Pessoas que querem ganhar mais.

Pessoas que confiam.

Pessoas que sentem medo.

Pessoas que mudam de emprego.

Pessoas que aprendem.

Pessoas que erram.

Pessoas como eu.

🐜

Por alguns segundos, depois de décadas trabalhando com tecnologia, eu fui a formiguinha.

E talvez tenha sido a melhor demonstração possível de toda a tese.

Porque segurança não começa quando afirmamos:

“Eu jamais cairia nisso.”

Segurança começa quando conseguimos perguntar:

“E se eu cair?”

E construímos o sistema para sobreviver mesmo assim.


☕ Um Café no Bellacosa Mainframe

Onde hoje descobrimos que você pode estudar o Cavalo de Troia durante décadas, desenhar todos os queijos suíços, mapear todas as formigas...

...e ainda terminar a noite olhando assustado para o monitor e pensando:

“Puta que pariu. A formiguinha sou eu.”

🐜☕

domingo, 28 de janeiro de 2018

Cameron, Atenda o Telefone — Social Engineering as a Service

Bellacosa Mainframe e a social engineering as a service


☕ Um Café no Bellacosa Mainframe — Especial Red Team

Cameron, Atenda o Telefone — Social Engineering as a Service

📞 Quando o atacante não trabalha sozinho e transforma pessoas legítimas em componentes involuntários do exploit

Chicago.

Um telefone toca.

Do outro lado, alguém acredita estar falando com uma pessoa legítima.

No meio da história, Cameron está desempenhando um papel que, isoladamente, parece completamente banal.

Ele atende.

Fala.

Confirma.

Interage.

Nada de malware.

Nada de exploit remoto.

Nada de buffer overflow.

Nada de zero-day.

Mas Ferris não precisa disso.

Ele precisa apenas que Cameron funcione como parte da cadeia.

E então temos algo belíssimo:

Ferris
  ↓
Cameron
  ↓
Telefone
  ↓
Escola
  ↓
Funcionário
  ↓
Sistema

Observe com carinho.

Nenhum desses elementos isoladamente precisa estar “quebrado”.

O telefone funciona.

Cameron fala.

A escola atende.

O funcionário segue um procedimento.

O sistema registra informação.

Tudo aparentemente correto.

E ainda assim...

o resultado é errado.

É aqui que Red Team fica realmente interessante.

Porque segurança não falha apenas quando existe uma vulnerabilidade em uma peça.

Ela também falha quando componentes legítimos se combinam de uma forma que ninguém previu.

Bem-vindo ao quinto episódio de:

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

Hoje vamos falar de cadeia de confiança, engenharia social, dependências humanas e uma ideia que deveria incomodar qualquer arquiteto:

o sistema inteiro pode ser vulnerável mesmo quando cada componente parece seguro.


📞 Cameron não é o ataque

Esse detalhe é fundamental.

Cameron não precisa entender toda a operação.

Ele não precisa conhecer a arquitetura.

Não precisa saber o objetivo final.

Não precisa possuir acesso especial.

Ele só precisa cumprir sua pequena função.

Essa é uma característica poderosa de muitas cadeias de ataque.

Cada pessoa vê apenas um fragmento.

Cada sistema vê apenas uma transação.

Cada controle valida apenas sua parte.

Ninguém enxerga o todo.

Ferris enxerga.


🧠 O atacante pensa em composição

Defensores frequentemente analisam sistemas por componentes.

Servidor seguro?

Sim.

Banco seguro?

Sim.

Rede segura?

Sim.

Usuário autenticado?

Sim.

Processo aprovado?

Sim.

Então parece que está tudo bem.

O Red Team pergunta outra coisa:

“O que acontece quando conectamos tudo?”

Essa pergunta muda o jogo.


🧀 Bem-vindo ao Swiss Cheese Model

O modelo do queijo suíço é maravilhoso porque explica exatamente isso.

Imagine várias fatias de queijo.

Cada fatia representa uma camada de defesa.

Cada uma possui buracos.

Nenhuma é perfeita.

Mas normalmente os buracos não se alinham.

Então o incidente é bloqueado.

Agora imagine:

Camada 1: Pessoa
      ○

Camada 2: Processo
          ○

Camada 3: Telefone
              ○

Camada 4: Sistema
                  ○

Se os buracos se alinham...

o ataque atravessa.

Não porque tudo falhou.

Mas porque pequenas imperfeições coincidiram.


☕ É exatamente o que Ferris faz

Ferris não precisa encontrar:

“a vulnerabilidade.”

Ele encontra:

vulnerabilidades pequenas o suficiente para parecer irrelevantes.

Cameron confia nele.

A escola espera determinados tipos de ligação.

O funcionário acredita no contexto.

O telefone não autentica intenção.

O sistema aceita o resultado daquela interação.

Separadamente, tudo parece aceitável.

Junto?

Exploit.


🔴 O grande erro: procurar uma única causa

Depois de um incidente, organizações adoram perguntar:

“Quem errou?”

É confortável.

Encontre uma pessoa.

Encontre uma falha.

Encontre um software.

Corrija.

Fim.

Só que sistemas complexos raramente falham assim.

Normalmente temos:

uma condição;

mais outra;

mais uma exceção;

mais uma dependência;

mais um contexto.

Quando tudo se alinha, temos incidente.

Ferris seria um excelente professor de causalidade sistêmica.


🧩 O exploit distribuído

Vamos imaginar a cadeia:

Ferris
 ↓
Cameron
 ↓
Telefone
 ↓
Funcionário
 ↓
Registro

Quem é culpado?

Ferris é o agente adversarial.

Mas cada componente seguinte apenas faz algo esperado.

Cameron fala.

O telefone transmite.

O funcionário interpreta.

O sistema registra.

Nenhum precisa estar comprometido tecnicamente.

Isso é um exploit distribuído pela confiança.


📞 Pessoas podem virar middleware

Essa metáfora é boa demais.

Em arquitetura, middleware conecta sistemas.

Em engenharia social, pessoas frequentemente fazem exatamente isso.

Elas recebem informação de um lado.

Interpretam.

Transformam.

Repassam.

Executam.

Pessoa como middleware.

E middleware humano possui características interessantes:

contexto;

empatia;

pressão;

memória;

autoridade;

cansaço;

urgência.

É poderoso.

E vulnerável.


🤖 Ferris cria um workflow humano

Pense como automação:

INPUT
 ↓
Cameron recebe instrução
 ↓
PROCESS
 ↓
Cameron adapta a fala
 ↓
OUTPUT
 ↓
Escola recebe mensagem

Ferris terceirizou uma etapa.

Isso é quase:

Social Engineering as a Service.

Claro que estamos brincando com a expressão.

Mas a lógica é real.

O atacante pode usar outras pessoas para realizar partes da operação.


🧠 O intermediário nem sempre sabe que participa

Esse ponto é importante.

Muitas operações maliciosas dependem de terceiros que acreditam estar fazendo algo legítimo.

Um funcionário encaminha arquivo.

Um fornecedor confirma dado.

Um atendente reseta senha.

Um colega aprova acesso.

Um usuário clica numa solicitação.

Cada um acredita estar resolvendo um problema normal.

A cadeia adversarial existe apenas na visão de quem coordena.


🎯 Orquestração é mais importante que ferramenta

Ferris não é perigoso porque possui um telefone.

Todo mundo possui telefone.

Ele é perigoso porque sabe quando usar Cameron, quando usar o telefone, quem deve receber a ligação e qual narrativa precisa existir.

Essa é a diferença entre ter ferramentas e conduzir uma operação.


☕ Red Team é coreografia

Um bom Red Team trabalha com sequências.

Reconhecimento.

Pretexto.

Contato.

Resposta.

Acesso.

Movimento.

Objetivo.

A palavra-chave é encadeamento.

Recon
 ↓
Contexto
 ↓
Pretexto
 ↓
Interação
 ↓
Confiança
 ↓
Ação

O ataque nasce da ordem.


🧱 Controle local versus segurança global

Essa distinção é essencial.

Um componente pode estar localmente seguro e o sistema globalmente inseguro.

Exemplo:

Help Desk valida três informações antes de resetar senha.

Ótimo.

Mas essas três informações estão publicamente disponíveis.

O Help Desk seguiu o processo.

O processo é que estava errado.

O componente passou.

O sistema falhou.


🧠 O funcionário fez exatamente o que foi treinado para fazer

Esse é um dos casos mais injustos em segurança.

Depois do incidente:

— O funcionário caiu no golpe.

Talvez.

Mas pergunte:

o procedimento permitia verificar adequadamente?

a pessoa tinha tempo?

o contexto era de urgência?

o atacante conhecia informações internas?

o treinamento cobria aquele cenário?

Se todas as condições empurram a pessoa para a decisão errada, talvez o problema seja arquitetura.


🔴 Erro humano é frequentemente erro de design

Essa frase vale ouro.

“Erro humano” às vezes é usado como descarte de responsabilidade.

Mas humanos fazem parte do sistema.

Se você depende deles, precisa projetar para comportamento humano real.

Não para comportamento idealizado.

Pessoas ficam cansadas.

Têm pressa.

Querem ajudar.

Confiam em colegas.

Respondem a autoridade.

Isso não é bug.

É humanidade.


🧀 Swiss Cheese em ambiente corporativo

Vamos construir uma cadeia hipotética:

LinkedIn
 ↓
Nome do gerente
 ↓
Telefone corporativo
 ↓
Help Desk
 ↓
Reset de senha
 ↓
Conta legítima
 ↓
Aplicação

Cada camada possui controle.

Mas pequenas falhas se alinham.

LinkedIn entrega contexto.

Telefone não prova identidade.

Help Desk usa validação fraca.

Conta não exige segundo fator robusto.

Aplicação confia na conta.

Resultado?

A cadeia inteira funciona para o atacante.


🕸️ Dependências escondidas

Sistemas modernos são teias.

Aplicação depende de IAM.

IAM depende de diretório.

Diretório depende de processos de RH.

RH depende de dados de pessoas.

Service Desk depende de procedimentos.

Procedimentos dependem de cultura.

Cultura depende de liderança.

Ferris não vê só “um computador”.

Ele vê a teia.


🦖 Mainframe também vive numa teia

Esse ponto é importante.

Você pode ter RACF impecável.

Perfis maravilhosos.

Auditoria excelente.

Mas como o usuário consegue identidade?

Como o acesso é solicitado?

Quem aprova?

Qual sistema provisiona?

Existe integração com IAM corporativo?

Existe conta técnica?

Existe acesso de emergência?

Ferris provavelmente atacaria antes do RACF.


🔐 Não tente quebrar a porta se alguém pode abrir

Essa é a lógica adversarial.

Se uma porta possui fechadura excelente, o atacante pode tentar:

enganar quem tem a chave;

convencer alguém a abrir;

obter credencial;

abusar de processo de recuperação.

O controle físico pode continuar perfeito.

O acesso acontece mesmo assim.


📞 O telefone é um protocolo de confiança

Pense nisso.

Durante décadas, o telefone funcionou como um canal semi-autenticado socialmente.

Você reconhece voz.

Reconhece número.

Reconhece contexto.

Mas tecnicamente, essas garantias podem ser fracas.

Ferris explora exatamente a diferença entre canal e confiança.


🤖 Em 2026, a cadeia fica mais perigosa

Agora temos:

voice cloning;

deepfake;

mensagens automatizadas;

LLMs;

agentes;

OSINT em escala.

Isso não muda a essência.

Apenas adiciona ferramentas.

A cadeia moderna pode parecer:

OSINT
 ↓
IA gera pretexto
 ↓
Voz sintética
 ↓
Funcionário
 ↓
MFA aprovado
 ↓
Conta legítima

Novamente:

cada componente isoladamente pode parecer normal.


🧠 O problema é correlação

Se cada sistema vê só seu pedaço, ninguém percebe a história.

Telefone vê ligação.

IAM vê login.

MFA vê aprovação.

Aplicação vê usuário autorizado.

Banco vê transação.

Cada sistema diz:

normal.

Mas quando correlacionamos:

Ligação suspeita
+
Reset de senha
+
Novo dispositivo
+
Acesso fora do padrão
+
Transação crítica

a história aparece.


🔵 Blue Team precisa pensar em narrativas

SIEM existe exatamente para ajudar nisso.

Não apenas coletar eventos.

Mas correlacionar.

Porque uma operação adversarial é uma história.

Logs são frases.

Incidente é o parágrafo.

O analista precisa ler o conjunto.


☕ “Todos os eventos eram permitidos”

Outra frase maravilhosa.

Sim.

Isso pode acontecer.

Um ataque pode ser composto quase inteiramente por ações permitidas.

Login permitido.

Reset permitido.

Acesso permitido.

Consulta permitida.

Transferência permitida.

O problema é o contexto.


🧠 Allowed não significa legitimate

Essa distinção merece destaque.

ALLOWED ≠ LEGITIMATE

Autorização técnica não prova legitimidade operacional.

Um usuário pode possuir permissão.

Mas a ação ainda pode ser fraudulenta.

Ferris ama essa diferença.


🪪 Contas legítimas são ouro

Atacantes gostam de contas válidas porque elas reduzem ruído.

Em vez de quebrar controles:

usam controles.

Em vez de forçar entrada:

entram pela porta.

Em vez de parecer malware:

parecem funcionário.

Cameron é parte dessa lógica.


🧨 Cadeias de ataque amam sistemas intermediários

Pense em integrações.

Um sistema confia em outro.

Outro confia em outro.

A relação vira:

A trusts B
B trusts C
C trusts D

Então a pergunta adversarial é:

se eu controlar D, até onde a confiança sobe?

Isso vale para pessoas também.


🕸️ Transitive Trust

Confiança transitiva é maravilhosa até deixar de ser.

Você confia em Cameron.

Cameron confia em Ferris.

Então, indiretamente, parte da confiança pode chegar a Ferris.

Ou:

Sistema A confia em B.

B confia em C.

C é comprometido.

Agora temos caminho.


🔐 Trust Boundary

Toda arquitetura deveria perguntar:

onde termina confiança?

onde ela é revalidada?

onde identidade muda?

onde contexto é perdido?

Essas fronteiras são críticas.


🦖 z/OS Connect como exemplo

Imagine:

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

Quem autenticou o usuário?

Onde a identidade foi validada?

Que identidade chegou ao CICS?

Existe propagação?

Existe mapeamento?

Existe conta técnica?

Onde está a trilha?

Cada transição é uma trust boundary.


🧾 Se todo mundo vira APIUSER, temos Cameron demais

Se diversas pessoas chegam ao backend como uma única identidade técnica, auditoria perde granularidade.

User A
User B
User C
   ↓
APIUSER

Agora o backend sabe que a aplicação falou.

Mas talvez não saiba quem iniciou.

Essa perda de contexto pode complicar detecção.


🕵️ Quem realmente fez isso?

Depois do incidente:

— Foi APIUSER.

Excelente.

Quem era o humano?

Silêncio.

É o equivalente corporativo de perguntar:

— Quem telefonou?

— O telefone.

Obrigado.


🧠 Context propagation importa

Sistemas distribuídos precisam preservar contexto.

Identidade.

Origem.

Sessão.

Ação.

Isso permite reconstruir cadeia.

Sem contexto, cada componente parece inocente.


🔴 O atacante também usa fornecedores

Terceiros são particularmente interessantes.

Eles já possuem relações legítimas.

Conhecem nomes.

Processos.

Ambientes.

Possuem acessos.

Um fornecedor comprometido pode virar Cameron involuntário.


🧩 Supply Chain é Swiss Cheese em escala industrial

Fornecedor A depende de fornecedor B.

Ferramenta depende de biblioteca.

Pipeline depende de repositório.

Produto depende de pacote.

A cadeia inteira cria superfície.

O ataque não precisa atingir você diretamente.

Pode atingir alguém em quem você confia.


☕ Ferris não precisa entrar na escola se Cameron já fala com ela

Essa frase resume o artigo.

O atacante não precisa possuir relação direta com o alvo.

Pode usar intermediários.

Pessoas.

Sistemas.

Parceiros.

Serviços.

Integrações.

A cadeia é o exploit.


🧠 Segurança precisa olhar para pathways

Não apenas ativos.

Pergunte:

como alguém chega até o ativo?

Quais caminhos existem?

Quem pode abrir portas?

Quais sistemas possuem trust?

Quais processos concedem acesso?

Isso vira attack path analysis.


🗺️ Mapa de ataque

Imagine:

Internet
 ↓
Help Desk
 ↓
IAM
 ↓
VPN
 ↓
Application
 ↓
Mainframe

Agora coloque controles em cada etapa.

Depois pergunte:

quais dependem de decisão humana?

quais usam mesma identidade?

quais possuem exceção?

A análise fica muito mais rica.


🧠 Ferris é um orquestrador

Ele entende qual peça usar.

Cameron é ator.

Telefone é canal.

Escola é alvo intermediário.

Funcionário é processador.

Sistema é registrador.

Ferris é o controlador.

Quase uma arquitetura de microserviços sociais.


🤣 Social Engineering Microservices

Pense nisso:

Ferris Service
   ↓
Cameron Service
   ↓
Telephone API
   ↓
School Service
   ↓
Administrative Backend

Observability?

Nenhuma.

Authentication?

Social.

Authorization?

Confiança.

Logging?

Talvez papel.

Chaos Engineering?

Ferris.


🔴 Red Team testa a cadeia inteira

Isso é crucial.

Um teste superficial pode verificar apenas:

phishing.

Um Red Team mais maduro testa:

como phishing se conecta a identidade;

como identidade conecta a VPN;

como VPN conecta a aplicação;

como aplicação conecta a dados;

como detecção responde.

O valor está na cadeia.


🧪 Purple Team aprende com a cadeia

Depois, Blue e Red podem trabalhar juntos.

Onde poderíamos detectar?

No telefone?

No reset?

No novo dispositivo?

No login?

Na mudança de comportamento?

Na ação final?

Idealmente em várias camadas.

Defense in Depth.


🧀 Queijo suíço ao contrário

O atacante quer alinhar buracos.

O defensor quer desalinhá-los.

É isso.

Se uma camada falhar, outra segura.

Social Engineering
 ↓
MFA bloqueia

ou

MFA falha
 ↓
Behavior Detection alerta

ou

Detection falha
 ↓
Approval bloqueia

Não precisamos de perfeição.

Precisamos de independência.


🧱 Camadas dependentes são perigosas

Se três controles dependem da mesma informação, talvez você tenha apenas um controle disfarçado de três.

Exemplo:

Help Desk pergunta nome, CPF e data de nascimento.

Se todos são públicos, temos:

Controle 1
Controle 2
Controle 3

na apresentação.

Na prática:

OSINT

Uma única falha compromete todos.


🧠 Diversidade de controles importa

Autenticação forte.

Canal independente.

Segregação.

Detecção.

Limites.

Auditoria.

Quanto menos correlacionadas as falhas, melhor.


☕ A pergunta Bellacosa

Eu colocaria na War Room:

“Se este controle falhar, qual é o próximo?”

E depois:

“Ele depende da mesma coisa que o primeiro?”

Se depender, cuidado.


🚨 Um incidente perfeito pode parecer uma sequência de dias normais

Isso é o mais assustador.

Nada explode.

Nenhum servidor cai.

Ninguém vê caveira.

Apenas:

uma ligação;

um reset;

um login;

uma alteração;

uma transação.

Tudo legítimo isoladamente.

A fraude vive no encadeamento.


🎬 Cameron provavelmente não se vê como infraestrutura

Mas é.

No plano de Ferris, ele é componente.

Isso é uma lição importante para segurança.

Pessoas fazem parte da arquitetura mesmo quando o diagrama não mostra.

Se o processo depende delas, elas são parte do sistema.


🧠 Diagramas deveriam mostrar humanos

Muitos diagramas possuem:

User
 ↓
App

Eu adoraria ver:

Human
 ↓
Help Desk
 ↓
Manager
 ↓
IAM
 ↓
App

Porque é assim que identidade realmente vive.


🔐 Security Architecture é também Human Architecture

Treinamento.

Processo.

Cultura.

Escalada.

Verificação.

Tudo isso é controle.

E precisa ser tratado com o mesmo cuidado que firewall.


🤖 IA transforma Cameron em escala

Agora imagine milhares de interações coordenadas automaticamente.

Mensagens personalizadas.

Respostas adaptativas.

Agentes conversando.

A grande mudança não é que engenharia social nasceu.

É que ganhou escala.

Ferris artesanal virou Ferris industrial.


🛡️ Defesa também pode escalar

A boa notícia é que defesa também evolui.

Análise comportamental.

Correlation.

Risk-based authentication.

Detecção contextual.

Automação.

IA para triagem.

Mas cuidado.

Se automatizamos demais, podemos cair em Automation Bias.

Outra fatia de queijo.


🧠 O humano continua importante

Ferris vence porque entende contexto.

Defensores também precisam entender contexto.

Um alerta sozinho pode parecer irrelevante.

Um analista experiente conecta pontos.

Essa combinação de máquina + humano continua poderosa.


🔵 Rooney precisava de um SIEM melhor

Imagine Rooney vendo:

Phone Call
 ↓
Administrative Change
 ↓
Ferris Absent

Talvez percebesse.

Mas cada evento isolado não conta a história.

Rooney tinha intuição.

Faltava correlação.


☕ A grande lição

Segurança não é propriedade de componentes.

É propriedade do sistema.

Você pode comprar:

o melhor firewall;

o melhor IAM;

o melhor EDR;

o melhor mainframe;

o melhor treinamento.

Mas se a combinação criar um caminho inesperado...

Ferris entra.


🎯 Pense em caminhos, não em caixas

Arquitetura normalmente desenha caixas.

Red Team procura setas.

Caixas representam ativos.

Setas representam movimento.

E atacante vive nas setas.

Pessoa → Processo
Processo → Identidade
Identidade → Sistema
Sistema → Dado

Cada seta merece pergunta.


🧠 Quem pode influenciar quem?

Essa é a pergunta de ouro.

Quem influencia Help Desk?

Quem influencia gestor?

Quem influencia IAM?

Quem influencia pipeline?

Quem influencia API?

Quem influencia mainframe?

Mapear influência é mapear ataque.


📞 Cameron atende o telefone

E esse pequeno gesto aparentemente inocente conecta tudo.

Ferris.

Narrativa.

Canal.

Autoridade.

Escola.

Registro.

A cadeia funciona.

Nenhuma peça precisa ser “hackeada”.

Só precisa ser usada.


☕ Epílogo: o exploit está entre as peças

Esse talvez seja o ponto mais importante de toda a série até agora.

Ferris não pensa em vulnerabilidades isoladas.

Pensa em sistema.

Ele percebe que:

Cameron conhece determinada informação.

O telefone permite determinada interação.

A escola espera determinado comportamento.

O funcionário possui determinado poder.

O sistema confia no funcionário.

Então:

Ferris
 +
Cameron
 +
Telefone
 +
Escola
 +
Funcionário
 +
Sistema
 =
Resultado

Essa soma é o exploit.

Red Team precisa aprender a enxergar exatamente isso.

Porque o incidente que sua organização mais teme talvez não dependa de um zero-day maravilhoso.

Talvez dependa de seis coisas perfeitamente normais acontecendo na ordem errada.

E quando alguém perguntar depois:

— Qual controle falhou?

A resposta talvez seja desconfortável:

todos funcionaram.

O problema estava na combinação.

Esse é o Swiss Cheese Model.

Essa é a cadeia.

Esse é o mundo real.

E esse é Ferris Bueller transformando Cameron numa API humana antes mesmo de alguém inventar REST.

☕ SAVE FERRIS.

No próximo artigo:

O Diretor Rooney Está Procurando Malware no Lugar Errado

Porque enquanto o Blue Team procura um atacante sofisticado...

Ferris talvez esteja entrando pela recepção.

☕ 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
1

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.

Red Team • Recon • Threat Modeling • Criatividade Adversarial
2

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.

Integridade • Db2 • Auditoria • Insider Threat • Dados
3

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.

Engenharia Social • Pretexting • Identity • Authentication
4

“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.

OSINT • Recon • LinkedIn • GitHub • Attack Surface
5

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.

Social Engineering • Swiss Cheese Model • Human Risk
6

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.

SOC • SIEM • EDR • Zero Trust • Engenharia Social
7

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.

MFA • PAM • Least Privilege • Privileged Access
8

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.

Backup • Restore • Rollback • Db2 • VSAM • Recovery
9

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.

Blue Team • SOC • Cognitive Bias • Incident Response
10

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.

Generative AI • Agents • Deepfake • Voice Cloning • OSINT
11

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.

Mainframe • RACF • z/OS • CICS • Db2 • MQ • Zowe
12

“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.

Red Teaming • Purple Team • Detection • Resilience • Learning

🎬 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 FERRIS

Sobre 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.

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...