 |
| Bellacosa Mainframe e a engenharia social |
☕ Um Café no Bellacosa Mainframe — Especial Red Team
Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu
🌭 Pretexting, autoridade inventada, confiança contextual e como uma identidade falsa funciona porque todos esperam que ela exista
Chicago.
Restaurante sofisticado.
Recepção impecável.
Pessoas bem vestidas.
Uma reserva.
Um nome.
E um adolescente com confiança suficiente para atravessar um controle social inteiro sem precisar apresentar praticamente nada além de convicção.
— Abe Froman.
Quem?
— Abe Froman.
O Rei da Salsicha de Chicago.
É uma das melhores piadas de Curtindo a Vida Adoidado.
E, ao mesmo tempo, uma aula quase perfeita de engenharia social.
Porque Ferris não prova matematicamente que é Abe Froman.
Não apresenta certificado digital.
Não faz reconhecimento facial.
Não mostra token.
Não passa por biometria.
Não apresenta uma cadeia criptográfica assinada por uma autoridade certificadora da indústria de embutidos de Illinois.
Ele faz algo muito mais simples.
Ele ocupa um espaço social onde Abe Froman deveria existir.
E durante alguns minutos...
isso basta.
Bem-vindo ao terceiro episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
Hoje vamos falar de uma distinção que deveria estar tatuada na parede de qualquer War Room:
Identity ≠ Authentication ≠ Authorization
E, talvez mais importante:
parecer legítimo não é o mesmo que ser legítimo.
🌭 Quem diabos é Abe Froman?
A força da cena está justamente no absurdo.
Ferris encontra um nome.
Uma reserva.
Uma posição social implícita.
E decide ocupar aquela identidade.
Observe o que acontece.
O nome existe.
A reserva existe.
O restaurante espera alguém com aquele nome.
Portanto, a chegada de uma pessoa alegando ser aquela identidade parece plausível.
Essa é a essência do pretexting.
Você não inventa qualquer história.
Você cria uma história que encaixa no ambiente.
🎭 Pretexting não é simplesmente mentir
Essa distinção é importante.
Mentira pode ser qualquer afirmação falsa.
Pretexting é mais sofisticado.
É construir um contexto.
Uma narrativa.
Um papel.
Um motivo.
Uma expectativa.
Ferris não diz simplesmente:
— Quero essa mesa.
Ele implicitamente diz:
— Sou a pessoa que vocês já esperavam.
Isso muda completamente a dinâmica.
🧠 O cérebro ama histórias coerentes
Pessoas não processam cada interação como um sistema criptográfico.
Nós utilizamos heurísticas.
Contexto.
Padrões.
Expectativas.
Se alguém entra numa sala usando crachá, segurando notebook e reclamando do Wi-Fi, nossa cabeça rapidamente conclui:
funcionário.
Se alguém liga dizendo:
— Sou da equipe de infraestrutura, estamos fechando um incidente crítico...
A frase ativa um contexto.
Se a pessoa conhece nomes internos, horários, sistemas e jargão, a história fica ainda mais convincente.
Ferris entende isso intuitivamente.
🔴 Engenharia social ataca modelos mentais
Tecnologia implementa regras.
Pessoas interpretam situações.
Essa diferença cria superfície de ataque.
Um firewall pode perguntar:
SOURCE IP?
DESTINATION?
PORT?
PROTOCOL?
Uma pessoa pergunta coisas muito mais nebulosas:
— Essa história faz sentido?
— Essa pessoa parece saber do que está falando?
— Parece urgente?
— Parece importante?
— Eu deveria ajudar?
Ferris trabalha nessa camada.
🪪 Identity: quem você afirma ser?
Vamos começar pela primeira palavra.
Identity.
Identidade é uma afirmação.
Você diz:
“Eu sou Vagner.”
Ou:
“Eu sou o administrador.”
Ou:
“Eu sou Abe Froman.”
Isso é apenas a declaração.
Nada foi provado ainda.
Em sistemas, seria algo como:
USER = ABE_FROMAN
Muito bonito.
Mas absolutamente insuficiente.
🔐 Authentication: prove
Authentication responde:
“Você realmente é quem afirma ser?”
Senha.
Token.
Biometria.
Smartcard.
Certificado.
MFA.
Passkey.
Algum mecanismo precisa transformar uma alegação de identidade numa identidade aceita.
Então:
Identity:
"I am Abe Froman"
Authentication:
"Prove it."
Ferris tenta atravessar exatamente esse intervalo.
Ele apresenta identidade suficiente para que ninguém exija autenticação forte.
🚪 Authorization: mesmo sendo você, pode fazer isso?
Aqui está a terceira camada.
Você pode ser realmente quem diz ser.
Pode autenticar corretamente.
E ainda assim não deveria necessariamente poder executar qualquer coisa.
Isso é authorization.
Identity
↓
Authentication
↓
Authorization
↓
Action
Essas quatro coisas são diferentes.
E sistemas ruins misturam tudo.
☕ “Mas ele é diretor”
Excelente.
Isso prova o quê?
Talvez identidade social.
Não autorização técnica.
— Ele é diretor.
— Então pode acessar produção?
Não necessariamente.
— Ele é vice-presidente.
— Então pode alterar firewall?
Espero que não.
— Ele é CEO.
— Então pode consultar qualquer dado de cliente?
Talvez a resposta correta seja:
não.
Autoridade organizacional não deveria se transformar automaticamente em privilégio técnico.
Ferris adora ambientes onde isso acontece.
🎩 Autoridade inventada
Uma das ferramentas mais antigas da engenharia social é autoridade.
Pessoas são condicionadas a responder a sinais de hierarquia.
Título.
Tom de voz.
Urgência.
Confiança.
Conhecimento interno.
Ferris utiliza quase todos.
Ele não precisa apresentar poder real.
Precisa transmitir sinais de poder suficientes.
Abe Froman não é apenas um nome.
É um personagem com status.
O “Rei da Salsicha de Chicago”.
A própria ideia sugere alguém importante dentro daquele universo.
🏢 Agora transforme o restaurante numa empresa
Imagine uma ligação:
— Bom dia, aqui é Marcos, da equipe do diretor financeiro. Estamos fechando o trimestre e precisamos liberar uma alteração imediatamente.
Nada necessariamente comprova identidade.
Mas a história contém:
cargo;
contexto;
urgência;
processo conhecido.
Agora acrescente:
— O Paulo está numa reunião com o conselho e pediu para eu resolver isso antes das 15h.
Paulo realmente existe.
Está realmente numa reunião.
A pessoa do outro lado sabe disso.
A narrativa começa a ganhar textura.
🔎 E de onde veio toda essa informação?
OSINT.
LinkedIn.
Redes sociais.
Calendário público.
Site da empresa.
Apresentações.
Documentos.
Vagas.
Postagens.
Uma história falsa pode ser construída com fatos verdadeiros.
Isso é uma combinação poderosa.
🧩 Verdade + mentira = história plausível
Um bom pretexto raramente precisa ser 100% inventado.
Na verdade, quanto mais verdade houver ao redor da mentira central, melhor.
Imagine:
Empresa real
+
Funcionário real
+
Projeto real
+
Prazo real
+
Nome real
+
Urgência plausível
+
Identidade falsa
A história inteira parece legítima.
O único elemento falso pode ser justamente quem está falando.
Ferris faria isso magnificamente.
🧠 Contexto reduz questionamento
Pense em duas abordagens.
Primeira:
— Me dê acesso ao sistema.
Provavelmente recebe:
— Quem é você?
Agora:
— Sou da equipe de suporte do projeto Atlas. A Patrícia abriu o ticket 8231 porque o serviço que integra o faturamento com o mainframe parou depois da mudança desta manhã. Preciso validar a conta técnica antes da janela fechar.
Subitamente temos uma narrativa.
Mesmo sem qualquer prova real, parece haver estrutura.
É aí que procedimentos precisam derrotar intuição.
🧯 Procedimento existe para dias convincentes
Esse ponto é fundamental.
Controles não são criados apenas para bloquear histórias ruins.
São criados para bloquear histórias excelentes.
Qualquer pessoa consegue desconfiar de:
— Oi, sou hacker, me passa sua senha?
Parabéns ao treinamento de segurança.
O problema é:
— Sou Felipe da IBM, estou com a equipe da migração do z/OS Connect e preciso confirmar a conta técnica que vocês configuraram ontem.
Agora a pessoa hesita.
Talvez realmente exista Felipe.
Talvez realmente exista projeto.
Talvez realmente tenha ocorrido mudança ontem.
É nesse momento que processo importa.
🔐 Nunca autentique alguém pela qualidade da história
Essa frase deveria entrar em treinamento corporativo.
Uma história boa não é autenticação.
Conhecer nome interno não é autenticação.
Conhecer projeto não é autenticação.
Saber seu gerente não é autenticação.
Falar jargão não é autenticação.
Estar irritado não é autenticação.
Parecer importante não é autenticação.
E usar um crachá bonito também não.
🪪 Crachá: o cosplay corporativo da confiança
Crachás são interessantes.
Servem para identificação visual.
Mas pessoas frequentemente confundem:
possui crachá
com:
possui autorização.
Ferris provavelmente adoraria um ambiente onde basta parecer funcionário.
Porque elementos visuais criam confiança contextual.
Uniformes fazem isso.
Coletes.
Pranchetas.
Notebook.
Fones.
Pasta.
Tudo isso conta histórias.
🚪 Tailgating: Abe Froman entrou atrás de alguém
Outro exemplo clássico.
Uma porta controlada por crachá.
Pessoa legítima passa.
Outra vem atrás carregando caixas.
— Segura pra mim?
O funcionário segura.
Tecnicamente, o sistema de controle de acesso funcionou perfeitamente.
Ele autenticou uma pessoa.
O problema é que duas entraram.
A falha não está no leitor.
Está no modelo social ao redor dele.
☕ O sistema perguntou uma coisa, o humano respondeu outra
O sistema pergunta:
“Este crachá está autorizado?”
O humano entende:
“Esta pessoa parece pertencer aqui?”
São perguntas diferentes.
Engenharia social vive nessas diferenças.
🔴 Ferris procura permissões sociais
Nem toda autorização está no RACF.
Existem permissões invisíveis.
Quem pode interromper uma reunião?
Quem pode pedir exceção?
Quem pode entrar pela porta lateral?
Quem pode solicitar urgência?
Quem pode dizer:
— Depois regularizamos.
Essas permissões sociais são valiosas.
Porque muitas vezes não estão documentadas.
📞 Help Desk: onde identidade encontra misericórdia
Help Desk é um alvo clássico justamente porque existe para ajudar pessoas que perderam acesso.
Isso cria um paradoxo.
Usuário legítimo:
— Esqueci minha senha.
Atacante:
— Esqueci minha senha.
Do ponto de vista verbal, são idênticos.
Então o sistema precisa de processo.
Validação.
MFA.
Callback.
Verificação independente.
Porque simpatia não autentica.
🧠 “Mas ele sabia meu CPF”
Informação pessoal virou péssimo autenticador.
Datas.
Documentos.
Endereços.
Nomes.
Parentes.
Empregadores.
Muitos desses dados já circularam por vazamentos.
Outros estão publicamente disponíveis.
O atacante conhecer uma informação não significa que é a pessoa.
Esse é outro erro clássico:
confundir knowledge com identity.
🔐 Algo que você sabe
Historicamente, autenticação foi dividida em fatores.
Algo que você sabe.
Algo que você tem.
Algo que você é.
Senha.
Token.
Biometria.
Combinar fatores aumenta resistência.
Mas mesmo MFA pode ser atacado socialmente.
O atacante pode tentar convencer o usuário a aprovar uma solicitação.
Então volta Ferris.
Tecnologia e comportamento precisam trabalhar juntos.
📲 “Aprove a notificação que acabou de chegar”
Imagine:
— Sou do suporte. Estamos corrigindo sua conta. Você vai receber uma notificação. Pode aprovar?
E a notificação chega.
Agora o usuário pensa:
Claro, ele disse que chegaria.
Isso é engenharia social usando o próprio mecanismo de segurança como parte da história.
O controle funciona.
A narrativa captura o usuário.
🤹 O truque não é quebrar o controle
Essa é uma ideia recorrente nesta série.
Ferris não precisa destruir controles.
Ele tenta fazer os próprios controles trabalharem para ele.
Isso é muito mais elegante.
Se uma pessoa legítima aprovar.
Se uma conta legítima autenticar.
Se um fluxo legítimo executar.
O atacante parece menos atacante.
🏦 Autoridade financeira
Empresas sofrem particularmente com golpes baseados em autoridade executiva.
Pedidos urgentes.
Transferências.
Mudanças de conta.
Faturas.
A lógica é sempre parecida.
A pessoa não obedece porque é idiota.
Obedece porque a organização a treinou para responder a hierarquia e urgência.
O atacante utiliza a cultura contra a própria cultura.
🧬 Cultura organizacional também é superfície de ataque
Esse ponto merece destaque.
Se uma empresa possui cultura onde:
“não questione diretor”,
então autoridade vira vetor.
Se possui cultura onde:
“resolver rápido é mais importante que processo”,
urgência vira vetor.
Se possui cultura onde:
“cliente VIP sempre ganha exceção”,
status vira vetor.
Red Team pode revelar isso.
🧪 Engenharia social autorizada não é pegadinha
Esse é outro ponto importante.
Um bom exercício não deve existir apenas para humilhar funcionário.
“HAHA! VOCÊ CLICOU!”
Isso ensina medo.
Não segurança.
O objetivo é descobrir:
processo funcionou?
controle existia?
a pessoa tinha canal para verificar?
o procedimento era realista?
havia pressão operacional?
O erro individual frequentemente é sintoma de desenho ruim.
🔴 Não culpe o humano por seguir o sistema humano
Se um funcionário precisa escolher entre:
seguir processo e tomar bronca;
ou quebrar processo e resolver problema;
adivinhe o que vai acontecer ao longo do tempo.
Segurança precisa encaixar na operação.
Caso contrário, nasce Shadow IT.
Exceção.
Atalho.
E Ferris começa a circular.
🦖 Abe Froman chega ao mainframe
Agora vamos transportar nosso Rei da Salsicha para um ambiente mainframe.
Imagine alguém ligando:
— Sou da equipe de aplicação. Estamos com erro de acesso no batch noturno. Preciso validar a permissão de uma conta técnica.
Parece plausível.
Talvez a pessoa conheça:
nome da aplicação;
job;
dataset;
Lpar;
horário;
time responsável.
Isso impressiona.
Mas nada disso deveria substituir autenticação e procedimento.
🔐 RACF não deveria acreditar em storytelling
RACF é maravilhoso justamente porque trabalha com regras.
Identidade.
Perfis.
Grupos.
Recursos.
Permissões.
Ele não fica emocionalmente impressionado com:
— Mas o diretor pediu!
Se arquitetura e processo estiverem corretos, autoridade informal não deveria atravessar o controle técnico.
O problema aparece quando humanos concedem a exceção.
🧨 SPECIAL: o Rei da Salsicha quer poder demais
Imagine alguém com RACF SPECIAL.
A discussão muda completamente.
Contas privilegiadas são especialmente valiosas.
Por isso PAM, segregação, logs, MFA e revisão são fundamentais.
Abe Froman não deveria conseguir chegar até:
ALTUSER ...
PERMIT ...
CONNECT ...
apenas porque parece convincente.
📡 z/OS Connect e identidade distribuída
Sistemas modernos complicam ainda mais a questão.
Uma identidade pode atravessar camadas.
Mobile
↓
Identity Provider
↓
API Gateway
↓
z/OS Connect
↓
CICS
↓
COBOL
Cada componente pode possuir visão diferente da identidade.
Quem autenticou?
Quem autorizou?
Qual identidade chegou ao backend?
Foi propagada?
Foi mapeada?
Virou conta técnica?
Esse tipo de pergunta é ouro para Red Team.
🧠 Identidade perdida no caminho
Imagine:
Usuário A autentica no frontend.
Backend chama mainframe com conta compartilhada.
Para o mainframe, todas as pessoas parecem:
APIUSER
Agora surge uma pergunta maravilhosa:
Quem realmente executou a transação?
A aplicação talvez saiba.
O mainframe talvez não.
Auditoria pode ficar fragmentada.
É aí que arquitetura de identidade importa.
🧾 Non-repudiation: depois ninguém lembra quem foi
Uma operação crítica deveria poder ser atribuída.
Quem fez?
Com qual identidade?
De qual origem?
Em qual contexto?
Se tudo termina numa conta técnica compartilhada, a história fica nebulosa.
Ferris agradece novamente.
🤖 Abe Froman ganha voz sintética
Agora entramos em 2026.
Uma das grandes mudanças é que sinais sociais podem ser reproduzidos em escala crescente.
Texto.
Voz.
Imagem.
Vídeo.
Isso significa que:
“eu reconheci a voz”
se torna um fator menos confiável isoladamente.
A defesa precisa depender menos de familiaridade.
Mais de canais autenticados.
Processos.
Verificação independente.
📞 “Mas parecia exatamente meu chefe”
Esse é o problema.
Por décadas, voz funcionou informalmente como autenticação.
Você reconhece alguém.
Confia.
Hoje essa confiança precisa ser revista.
Não significa que toda ligação é falsa.
Significa que operações sensíveis precisam de mecanismos além da percepção.
🧠 Deepfake não cria a vulnerabilidade
Ele amplifica uma vulnerabilidade que já existia:
confiamos em sinais sociais.
Ferris faria Abe Froman com presença física.
Hoje alguém pode construir pretexto digitalmente.
O princípio não mudou.
A escala mudou.
🎯 Red Team deveria testar identidade, não apenas senha
Uma operação madura pode perguntar:
Se alguém alegar ser executivo, o que acontece?
Se alguém conhecer informações internas, ganha confiança?
Se fornecedor ligar fora do fluxo, existe validação?
Se uma conta for comprometida, há detecção contextual?
Se alguém usar voz convincente, processo resiste?
Essas perguntas testam a arquitetura real de identidade.
🧩 Identity ≠ Authentication ≠ Authorization
Voltemos ao coração deste artigo.
IDENTITY
"Eu sou Abe Froman"
≠
AUTHENTICATION
"Prove que é Abe Froman"
≠
AUTHORIZATION
"O verdadeiro Abe Froman pode fazer isso?"
Três perguntas.
Três controles.
Três falhas possíveis.
Misture qualquer duas e Ferris entra.
☕ E ainda existe uma quarta pergunta
Mesmo que você seja quem diz.
Mesmo que esteja autenticado.
Mesmo que possua permissão.
Precisamos perguntar:
essa ação faz sentido agora?
Isso é contexto.
Um usuário pode possuir autorização para transferir dinheiro.
Mas transferência de valor enorme às 03h17 de um país inesperado talvez mereça atenção.
Então:
Identity
↓
Authentication
↓
Authorization
↓
Context
↓
Action
Segurança moderna precisa cada vez mais dessa camada.
🚨 Zero Trust: Abe Froman não ganha mesa automaticamente
Zero Trust é frequentemente resumido de maneira pobre como:
“não confie em ninguém.”
Não é exatamente isso.
É mais próximo de:
não transforme confiança implícita em autorização permanente.
Verifique.
Contextualize.
Limite.
Monitore.
Ou, no restaurante:
— Senhor Froman?
— Sim.
— Excelente. Precisamos confirmar sua reserva por outro canal.
Ferris:
— Droga.
Fim do episódio.
🧠 A pergunta Bellacosa
Numa War Room eu colocaria esta pergunta:
“Que frases fazem nossos funcionários pararem de questionar?”
“Sou diretor.”
“É urgente.”
“É auditoria.”
“É produção.”
“É da segurança.”
“É cliente VIP.”
“É ordem do presidente.”
“É incidente.”
“É do fornecedor.”
A resposta revela muito sobre a cultura de confiança.
🌭 O poder de parecer esperado
Abe Froman funciona porque o restaurante já espera Abe Froman.
Esse detalhe é genial.
O pretexto mais forte frequentemente entra por uma expectativa existente.
Manutenção agendada.
Auditoria.
Fornecedor esperado.
Novo funcionário.
Entregador.
Consultor.
Equipe de limpeza.
Migração.
Suporte.
O atacante procura uma história que o ambiente esteja preparado para aceitar.
🧱 Segurança começa quando plausibilidade deixa de ser suficiente
O sistema maduro diz:
“Isso parece plausível.”
Mas continua:
“Vamos verificar.”
Essa pequena diferença impede muita coisa.
Não precisamos tratar todo mundo como criminoso.
Precisamos separar cortesia de controle.
Você pode ser educado.
Prestativo.
Rápido.
E ainda verificar identidade.
🎬 Ferris venceu porque entendeu a cena
Ele não era Abe Froman.
Mas entendeu que o restaurante não possuía uma maneira forte de diferenciar:
a pessoa esperada
de:
alguém que sabia o nome esperado.
Esse é um problema clássico de autenticação.
E continua atual.
☕ Epílogo: longa vida ao Rei da Salsicha
Ferris Bueller entrou no restaurante com uma identidade emprestada.
E nos deixou uma bela lição de segurança.
Identidade é uma afirmação.
Autenticação é prova.
Autorização é permissão.
Contexto é validação contínua.
Nenhuma dessas coisas deveria ser substituída por:
“Ele parecia saber o que estava falando.”
Porque o atacante competente faz exatamente isso.
Ele aprende.
Observa.
Pesquisa.
Constrói pretexto.
Adota linguagem.
Explora expectativas.
E então aparece na porta.
Talvez de terno.
Talvez com crachá.
Talvez por telefone.
Talvez através de uma conta comprometida.
Talvez por API.
Talvez usando uma voz sintética.
Mas sempre trazendo a mesma pergunta:
“Vocês vão verificar quem eu sou ou apenas acreditar que eu deveria estar aqui?”
No restaurante de Chicago, por alguns minutos, a resposta foi confiança.
E Ferris ganhou a mesa.
No seu ambiente corporativo, essa mesma confusão pode significar:
acesso;
credencial;
privilégio;
transação;
dados;
produção.
Então da próxima vez que alguém aparecer dizendo ser muito importante, carregando uma história perfeitamente plausível, lembre-se:
Abe Froman também parecia legítimo.
☕ SAVE FERRIS.
No próximo artigo:
Você Conhece o Diretor Rooney? — OSINT Antes do Google Existir
Porque antes de alguém inventar uma boa mentira...
precisa descobrir verdades suficientes para torná-la convincente.
