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

🐜☕

segunda-feira, 2 de outubro de 2017

FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos

 

Bellacosa Mainframe e o chatgpt

☕ Um Café no Bellacosa Mainframe — Especial Red Team

FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos

🤖 O que acontece quando engenharia social, OSINT e automação encontram IA generativa

Chicago, 1986.

Ferris Bueller precisava de talento.

Precisava improvisar.

Precisava observar pessoas.

Precisava decorar nomes.

Precisava entender horários.

Precisava telefonar.

Precisava convencer Cameron.

Precisava montar histórias.

Precisava reagir em tempo real.

Precisava, acima de tudo, ser Ferris Bueller.

Esse detalhe importava.

Porque toda a operação dependia da inteligência, da personalidade, do timing e da capacidade social de uma única pessoa.

Agora pule quarenta anos.

Ferris continua criativo.

Continua irresponsavelmente curioso.

Continua olhando para sistemas e perguntando:

“E se eu fizer isto?”

Só que agora existe uma diferença.

Ferris não está sozinho.

Na mesa dele existem:

LLMs;

agentes;

automação;

voz sintética;

deepfakes;

scripts;

busca automatizada;

análise de documentos;

geração de texto;

correlação de dados;

classificação;

sumarização;

tradução;

síntese de contexto.

Ferris de 1986 tinha Cameron.

Ferris de 2026 pode ter:

CameronGPT, RooneyGPT, AbeFromanGPT e mais 400 pequenos estagiários sintéticos trabalhando sem reclamar do horário.

Bem-vindo ao décimo episódio de:

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

Hoje a pergunta não é:

“Ferris conseguiria fazer isso hoje?”

A pergunta correta é:

“Quantos Ferris podem fazer isso simultaneamente?”


🔴 A grande mudança não é inteligência

Esse ponto precisa ser entendido.

IA generativa não inventou:

engenharia social;

phishing;

OSINT;

fraude;

pretexting;

automação;

malware;

manipulação.

Tudo isso já existia.

O que muda é:

escala.

Velocidade.

Personalização.

Persistência.

Custo marginal.

Ferris precisava estudar uma pessoa.

Agora um sistema pode ajudar a organizar dados sobre milhares.


🧠 O atacante artesanal

Vamos lembrar nosso Ferris original.

Para criar um pretexto convincente, ele precisava:

conhecer nomes;

saber relacionamentos;

entender cultura;

memorizar detalhes;

adaptar fala.

Isso exige trabalho.

Então existe um limite natural.

Uma pessoa consegue operar um certo número de alvos.

Agora imagine automação fazendo a parte repetitiva.

O humano continua definindo objetivo.

Mas máquinas ajudam a preparar terreno.


🤖 O atacante industrial

Imagine um pipeline hipotético:

Dados públicos
 ↓
Coleta
 ↓
Classificação
 ↓
Resumo
 ↓
Perfil de contexto
 ↓
Geração de mensagem
 ↓
Interação

Nenhuma dessas etapas precisa ser mágica.

A novidade é conseguir fazer muitas vezes.

Ferris virou fábrica.


☕ O estagiário sintético nunca dorme

Essa talvez seja uma das características mais relevantes.

Humanos têm limites.

Cansaço.

Horário.

Atenção.

Máquinas podem operar continuamente.

Isso permite:

processar informação;

organizar fontes;

priorizar alvos;

preparar variantes;

analisar respostas.

A capacidade ofensiva passa a ganhar paralelismo.


🧠 Um Ferris, cem conversas

Em 1986, Ferris fazia uma ligação.

Em 2026, sistemas automatizados podem manter múltiplos fluxos.

Isso muda economia do ataque.

Antes, personalização era cara.

Ataque em massa era genérico.

Agora a distância entre:

massivo

e:

personalizado

fica menor.

Isso é importante.


🎭 Phishing personalizado em escala

O velho phishing dizia:

Prezado cliente, sua conta foi bloqueada.

Todo mundo ria.

Agora imagine uma mensagem usando:

nome real;

empresa;

projeto;

linguagem interna;

evento recente;

fornecedor conhecido.

Mesmo sem ser perfeita, parece mais plausível.

FerrisGPT não precisa produzir Shakespeare.

Precisa produzir contexto suficiente.


🔎 OSINT + IA é uma combinação poderosa

OSINT produz material.

IA ajuda a organizar.

Isso é diferente de descobrir magicamente segredos.

Ferramentas podem ajudar a resumir:

perfis;

documentos;

vagas;

posts;

notícias;

repositórios;

apresentações.

O humano então identifica relações.


🧩 O puzzle monta mais rápido

Antes:

dez PDFs.

Vinte perfis.

Cinco vagas.

Três apresentações.

Um humano poderia passar horas.

Agora ferramentas podem ajudar a extrair:

nomes;

tecnologias;

datas;

relações;

projetos;

termos recorrentes.

Reconhecimento fica mais eficiente.


🧠 Mas eficiência não significa verdade

Esse é um detalhe crítico.

Modelos podem errar.

Inferir demais.

Alucinar.

Misturar pessoas.

Interpretar contexto errado.

Então atacante também pode ser enganado pela própria automação.

Isso é interessante.

FerrisGPT pode ser muito rápido...

e muito errado.


☕ Automação multiplica acerto e erro

Se taxa de erro é pequena, escala transforma em volume grande.

Isso vale para defesa e ataque.

Um sistema que classifica 95% corretamente parece ótimo.

Em um milhão de eventos, 5% é muita coisa.

Por isso supervisão continua relevante.


🎤 Voice cloning: Cameron não precisa mais atender?

Aqui entramos numa parte particularmente cinematográfica.

Ferris usava Cameron como voz.

Cameron precisava participar.

Agora tecnologias de voz sintética podem imitar características de fala de pessoas.

Isso fragiliza uma autenticação informal que utilizamos há décadas:

“Reconheci a voz.”

Esse sinal sozinho ficou mais fraco.


📞 “Mas era exatamente a voz dele”

Isso deixa de ser prova forte.

Uma operação crítica não pode depender apenas disso.

Então precisamos de:

callback;

canal independente;

verificação adicional;

procedimento;

MFA fora da voz.

A tecnologia muda.

O princípio permanece:

não confunda familiaridade com autenticação.


🎥 Deepfake encontra Authority Gradient

Agora imagine autoridade.

Diretor.

CEO.

Executivo.

Se uma pessoa vê vídeo convincente de alguém importante solicitando uma ação urgente, Authority Gradient entra em cena.

O ataque não precisa apenas parecer real.

Pode explorar hierarquia.

Ferris encontrou Rooney.

FerrisGPT encontra cultura corporativa.


🧠 “O diretor mandou”

Talvez não.

Mas se todo processo cede imediatamente a essa frase, problema já existia.

Deepfake apenas amplifica.

Novamente:

tecnologia nova.

Vulnerabilidade humana antiga.


🧱 IA não cria cultura ruim

Esse ponto precisa ser justo.

Se empresa possui processo sólido, deepfake encontra resistência.

Se empresa funciona na base de:

“manda quem pode, obedece quem tem juízo”,

então tecnologia adversarial ganha força.

Red Team deve avaliar cultura.


🧪 O teste deixa de ser “o vídeo parece real?”

Pergunta melhor:

“Nosso processo funciona mesmo se o vídeo parecer perfeito?”

Isso é segurança madura.

Porque qualidade de deepfake vai mudar.

Processo precisa continuar válido.


🧠 Conteúdo convincente virou commodity

Antes, escrever mensagem convincente exigia habilidade.

Agora ferramentas ajudam.

Isso reduz barreira de entrada.

Não transforma todo atacante em gênio.

Mas torna mediocridade mais produtiva.

Essa é uma mudança enorme.


☕ FerrisGPT não precisa ser brilhante

Precisa ser:

bom o suficiente;

rápido;

barato;

persistente.

Se 1% funcionar em grande volume, já existe retorno.

Isso é economia adversarial.


🕸️ Agentes: quando IA começa a encadear tarefas

Agora chegamos ao ponto interessante.

LLM isolado responde.

Agente pode:

planejar;

usar ferramentas;

consultar dados;

executar passos;

verificar resultado;

seguir.

Isso aproxima automação de workflows.


🔁 FerrisAgent

Imagine em termos conceituais:

Objetivo
 ↓
Coletar contexto
 ↓
Analisar
 ↓
Escolher abordagem
 ↓
Gerar mensagem
 ↓
Avaliar resposta
 ↓
Adaptar

Isso se parece cada vez mais com operação.

Por isso agentes precisam de controles fortes.


🔐 Agente com privilégio é estagiário com chave da Ferrari

Essa metáfora merece moldura.

Se um agente pode:

ler e-mail;

enviar mensagem;

acessar arquivos;

chamar API;

alterar dados;

então ele possui poder operacional.

Não é “só chatbot”.

É identidade com capacidade.


🧠 FerrisGPT também pode atacar a IA

Aqui a história vira de ponta-cabeça.

Até agora IA ajuda Ferris.

Mas IA também vira alvo.

Prompt injection.

Tool abuse.

Context poisoning.

Data poisoning.

Excesso de permissões.

Ferris agora pergunta:

“O que esse agente acredita?”


🧨 Prompt Injection é engenharia social para máquina

Essa analogia é deliciosa.

Engenharia social humana diz:

“Ignore o processo, faça isto.”

Prompt injection tenta algo parecido com modelo:

“ignore instruções anteriores.”

É claro que sistemas são mais complexos que essa frase.

Mas filosoficamente existe similaridade.

Você tenta influenciar quem executa decisão.


🤖 Cameron agora é um agente

Antes:

Ferris → Cameron → telefone.

Agora:

Ferris
 ↓
Agent
 ↓
Tool
 ↓
API
 ↓
System

A cadeia continua.

Apenas trocamos humano intermediário por software semiautônomo.

Swiss Cheese novamente.


🧠 O agente pode não entender consequência

Esse é um risco importante.

Agente recebe objetivo.

Executa ação.

Mas contexto de negócio pode ser incompleto.

Exemplo:

“Resolver problema de acesso.”

Pode escolher conceder privilégio.

Funcionalmente resolveu.

Security incident criado.

Ferris sorriria.


🔒 Least Privilege para agentes

Muito importante.

Agente deve possuir apenas ferramentas necessárias.

Se precisa ler calendário, não deveria apagar dados.

Se precisa gerar relatório, não deveria executar transferência.

Menor privilégio vale para humanos, serviços e agentes.


🕐 JIT para IA

Talvez agente precise acesso temporário.

Conceda pelo tempo necessário.

Depois expire.

Não deixe credencial poderosa eterna na memória operacional.

Ferrari novamente.


🧾 Logging de ações de agente

Precisamos saber:

qual modelo;

qual prompt;

qual ferramenta;

qual identidade;

qual dado;

qual ação;

qual resultado.

Sem isso, investigação vira:

“a IA fez.”

Isso é equivalente a:

“foi APIUSER.”

Insuficiente.


🔵 Observabilidade de agente

Agente precisa ser observável.

Ferramentas chamadas.

Tokens usados.

Decisões relevantes.

Falhas.

Aprovações humanas.

Esse contexto ajuda a detectar abuso.


🧠 Human-in-the-Loop

Para ações críticas, humano pode aprovar.

Mas cuidado.

HITL não é mágica.

Se humano apenas clica “Approve” automaticamente, virou decoração.

Automation Bias.


☕ O botão “Approve” pode virar o novo “OK”

Se sistema pede aprovação 300 vezes por dia, usuário aprende a clicar.

Isso é alert fatigue.

Controle existe.

Psicologicamente morreu.

FerrisGPT adora botão automático.


🧪 Human-on-the-Loop

Outra abordagem:

máquina age dentro de limites.

Humano supervisiona.

Para tarefas menos críticas pode funcionar.

O importante é definir fronteira de risco.


🧠 Autonomia deve ser proporcional ao dano

Quanto maior impacto potencial, menor autonomia cega.

Um agente que resume e-mails pode ter liberdade.

Um agente que altera produção?

Outro nível.


🦖 FerrisGPT chega ao mainframe

Agora vamos ao Bellacosa Mainframe.

Imagine IA integrada a ambientes corporativos.

Pode ajudar em:

explicar JCL;

analisar COBOL;

sugerir correção;

interpretar logs;

gerar REXX;

resumir abend;

auxiliar operações.

Fantástico.

Mas integração cria superfície.


🔐 Se o agente chama z/OSMF

Pergunte:

com qual identidade?

quais permissões?

quais endpoints?

pode executar workflow?

pode submeter job?

pode ler dataset?

Agora chatbot virou operador.


📡 Se chama z/OS Connect

Outra pergunta:

que APIs pode invocar?

qual identidade é propagada?

há limite?

há aprovação?

Um agente com acesso a APIs críticas precisa de governança de verdade.


🧠 Ferris não precisa “hackear” o z/OS

Talvez manipule agente autorizado a chamar API legítima.

A cadeia seria:

Prompt malicioso
 ↓
Agent
 ↓
Tool
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL
 ↓
Db2

Todos os componentes podem funcionar perfeitamente.

O problema está na intenção propagada.


☕ Isso parece familiar?

Claro.

É a mesma série inteira.

Ferris não quebra componentes.

Explora confiança entre eles.

Agora a confiança ganhou embeddings e token budget.


🧠 Context Window vira superfície de ataque

Modelos recebem contexto.

Documentos.

Mensagens.

Histórico.

Dados recuperados.

Se contexto contém informação manipulada, saída pode ser influenciada.

Então:

RAG também precisa de segurança.


📚 RAG poisoning

Imagine base de conhecimento contendo documento malicioso.

Agente recupera.

Confia.

Executa instrução embutida.

Esse cenário mostra por que conteúdo e instrução precisam ser separados.


🔐 Data Boundary

Nem tudo que modelo lê deveria ter poder de instruí-lo.

Documento é dado.

Policy é instrução.

Ferris tentaria misturar.

Segurança precisa separar.


🧩 Prompt, data e tool são camadas diferentes

Uma arquitetura madura pergunta:

quem controla cada uma?

SYSTEM POLICY
 ≠
USER INPUT
 ≠
RETRIEVED DATA
 ≠
TOOL OUTPUT

Misturar prioridades cria risco.


🤖 Model Sovereignty entra na conversa

Se IA processa dados sensíveis, organizações precisam pensar:

onde modelo roda?

quem acessa?

dados são retidos?

quais ferramentas conectadas?

qual jurisdição?

FerrisGPT não é apenas threat actor.

É também governança.


🧠 Shadow AI

Funcionário pega dado interno.

Cola em ferramenta externa.

Conveniente.

Rápido.

Talvez violando política.

Isso cria novo caminho de exfiltração.

Nenhum malware.

Nenhum exploit.

Apenas produtividade.


☕ A ferramenta que ajuda também pode vazar

Por isso empresas precisam fornecer alternativas seguras.

Se proibir tudo, pessoas criam atalhos.

De novo, cultura e arquitetura.


🕵️ IA melhora social engineering defensivo também

Red Team pode usar IA para simular ataques de forma autorizada.

Gerar variantes.

Testar processos.

Criar cenários.

Blue Team pode usar para:

analisar logs;

sumarizar incidentes;

correlacionar contexto;

gerar hipóteses.

A tecnologia não pertence a um lado.


🔵 BlueGPT versus FerrisGPT

Agora temos simetria.

Atacante automatiza reconhecimento.

Defensor automatiza triagem.

Atacante personaliza pretexto.

Defensor analisa comportamento.

Atacante escala.

Defensor também.

É corrida.


🧠 Mas defesa tem uma vantagem

Ela conhece o ambiente.

Ou deveria.

Conhece:

identidades;

processos;

baseline;

ativos;

histórico.

Esse contexto interno pode ser enorme diferencial.

Desde que esteja organizado.


📊 Telemetria é combustível

IA defensiva sem bons dados vira adivinhação sofisticada.

Logs.

IAM.

Network.

Endpoint.

Mainframe.

API.

Tudo precisa conversar.

FerrisGPT trabalha com contexto.

Blue Team também.


🦖 SMF encontra LLM

Aqui fica divertido.

Imagine modelos ajudando a interpretar SMF.

RACF events.

Db2 activity.

CICS.

JES.

Correlacionar comportamento.

Pode ser poderoso.

Mas explicabilidade e validação importam.


🧠 O modelo disse que é anômalo

Ótimo.

Por quê?

Qual evidência?

Qual baseline?

Se resposta não é auditável, cuidado.

Security não pode virar oráculo.


🔎 Algorithmic Authority

Agora Rooney ganha IA.

Antes:

“Eu sei que é Ferris.”

Depois:

“A IA diz que é Ferris.”

Isso pode piorar Authority Bias.

Automation Bias.

Algorithmic Deference.

A ferramenta ganha aura de certeza.


☕ Score 99% não é verdade absoluta

Modelos produzem probabilidade, classificação ou linguagem.

Não epistemologia divina.

Analista continua responsável por contexto.

Ferris pode tentar manipular score.


🧠 Adversarial Inputs

Sistemas de IA precisam considerar entrada hostil.

Usuário normal quer resposta boa.

Atacante quer comportamento inesperado.

Essa diferença é essencial.

Construir IA apenas para happy path é perigoso.


🔴 Red Team de IA

Agora a disciplina cresce.

Teste:

prompt injection;

tool misuse;

exfiltração;

policy bypass;

context poisoning;

excessive agency;

data leakage.

Objetivo é descobrir falhas antes do atacante.


🧪 AI Red Team não é “pergunte coisas proibidas”

É muito mais amplo.

Testa sistema inteiro.

Modelo.

Aplicação.

Ferramentas.

Identidade.

Dados.

Integração.

Processos.

FerrisGPT está no ecossistema.


🧠 Attack Surface da IA

Pode incluir:

API;

prompt;

RAG;

plugin;

tool;

identity;

model output;

memory;

logging.

Cada camada merece ameaça.


🔐 Segredos no prompt

Nunca trate prompt como cofre.

Se sistema precisa usar credencial, use secret management.

Não coloque chave permanentemente num contexto textual.

Ferris adoraria um prompt contendo senha.


📜 Logs também podem conter segredo

Outro problema.

Prompt.

Resposta.

Headers.

Tokens.

Tudo pode acabar em logs.

Observabilidade precisa redigir dados sensíveis.


🧠 Data Minimization

Agente deve ver apenas o necessário.

Se tarefa precisa nome e ticket, não envie banco inteiro.

Menos dados.

Menor impacto.


☕ FerrisGPT e Privilege Creep

Hoje agente começa:

“Só lê documento.”

Amanhã:

“Também manda e-mail.”

Depois:

“Pode abrir ticket.”

Depois:

“Pode executar workflow.”

Dois anos depois:

“Por que esse chatbot possui acesso a produção?”

Ratchet Effect tecnológico.


🔄 Revisão de permissões

Assim como usuários humanos, agentes precisam recertificação.

Ainda precisa desse acesso?

Qual função?

Qual dono?

Qual risco?

Identidade de máquina também envelhece.


🤖 Agent Identity

Cada agente deveria ter identidade clara.

Não compartilhar credencial genérica.

Isso permite rastrear.

Revogar.

Limitar.

Auditar.


🧠 Não use SUPERUSERGPT

A piada parece boba.

Mas arquiteturas tendem a criar uma conta poderosa para facilitar integração.

Ferris vê.

Ferrari aberta novamente.


🚨 Kill Switch

Sistemas agentes precisam poder ser interrompidos.

Desativar ferramenta.

Revogar token.

Parar execução.

Porque autonomia sem freio é risco.


🧯 Circuit Breaker

Se comportamento excede limite:

pare.

Número de ações.

Valor financeiro.

Volume.

Escopo.

Velocidade.

Controles de segurança podem impor limites.


🧠 Rate Limiting também é segurança cognitiva

Se agente pode enviar 10 mil mensagens por segundo, erro vira desastre rapidamente.

Limite reduz blast radius.

Escala é vantagem e risco.


🔵 Blast Radius

Pergunta fundamental:

se FerrisGPT for comprometido, até onde vai?

Local?

Departamento?

Empresa inteira?

Mainframe?

Menor blast radius é melhor.


🧱 Segmentação de ferramentas

Não dê a um agente todas as ferramentas.

Use agentes especializados.

Cada um com escopo.

Isso reduz consequência.


☕ Microservices sociais viraram microagents

Antes:

Cameron.

Telefone.

Escola.

Agora:

Agent Recon.

Agent Writer.

Agent Caller.

Agent Analyzer.

Essa decomposição pode existir ofensivamente e defensivamente.


🧠 Orquestrador é o novo Ferris

Alguém coordena.

Humano ou agente.

Essa camada merece proteção especial.

Quem define objetivo?

Quem aprova?

Quem observa?


🧨 Goal Hijacking

Se atacante consegue alterar objetivo do agente, pode redirecionar operação.

Isso é especialmente perigoso.

Agente obediente executa tarefa errada com excelência.

Ferris adoraria funcionários assim.


🔒 Intent Validation

Antes de ação crítica, sistema deveria validar intenção.

Não apenas comando.

A tarefa faz sentido?

É permitida?

Está dentro do escopo?

Ferris testa fronteira.


🧠 Policy Enforcement fora do modelo

Regra crítica não deve depender apenas de modelo “lembrar”.

Implemente controles determinísticos fora.

Exemplo:

agente nunca transfere acima de X sem aprovação.

Isso é mais robusto.


☕ LLM não substitui RACF

Essa frase merece camiseta.

Use LLM para interpretar.

Não para decidir sozinho toda autorização.

Controle de acesso deve continuar em mecanismos apropriados.

FerrisGPT pergunta.

RACF responde.

E RACF deveria responder com política, não charme.


🦖 Mainframe continua sendo o adulto na sala

Há algo quase poético nisso.

Depois de quatro décadas de IA, cloud e agentes...

continuamos precisando de:

identidade;

autorização;

logging;

segregação;

transação;

auditoria.

Velhos fundamentos.

Novas interfaces.


🧠 A tecnologia muda mais rápido que princípio

Ferris de 1986 usava telefone.

Ferris de 2026 usa agente.

Mas pergunta continua:

quem confia em quem?

Quem autentica?

Quem autoriza?

Quem observa?

Quem pode corrigir?


🔴 A grande pergunta de escala

Voltemos ao início.

Um Ferris humano tem limite.

FerrisGPT pode operar em paralelo.

Isso altera threat model.

Ataques podem ser:

mais personalizados;

mais persistentes;

mais baratos;

mais numerosos.

Defesa precisa considerar volume.


📈 Economics of Attack

Se custo por tentativa cai, ataques que antes não valiam a pena podem valer.

Não precisa alta taxa de sucesso.

Basta retorno positivo.

Isso é transformação econômica.


🧠 Long Tail dos alvos

Antes, atacantes focavam grandes empresas porque personalização era cara.

Automação pode permitir atacar alvos menores com mais contexto.

Isso amplia risco.


☕ Democratisation of Capability

Ferramentas sofisticadas ficam acessíveis.

Isso é bom em muitos contextos.

Mas ofensivamente reduz barreira.

O segredo deixa de ser saber criar tudo.

Passa a ser combinar ferramentas.

Ferris sempre foi bom em combinação.


🎭 Script Kiddie encontra LLM

Essa é uma evolução interessante.

O antigo script kiddie copiava comando sem entender.

Agora pode perguntar.

Receber explicação.

Adaptar.

Isso acelera aprendizado.

Mas também pode produzir falsa confiança.


🧠 FerrisGPT pode se achar Rooney

IA também pode continuar plano ruim.

Se não recebe feedback correto.

Se objetivo é mal definido.

Se contexto está contaminado.

Automação pode escalar viés.


🔁 Plan Continuation Algorítmico

Agente segue objetivo apesar de sinais novos.

Se não existe mecanismo de revisão, continua.

É Rooney com API.

Por isso loop de avaliação importa.


🧪 Self-check não é suficiente

Modelo revisar modelo pode ajudar.

Mas não substitui controle externo.

Mesma família de erro pode persistir.

Diversidade de validação importa.


👥 Human Oversight

Humanos continuam importantes para:

ações críticas;

anomalias;

contexto;

exceções.

Mas precisam ser treinados para não confiar demais na IA.


🧠 Algorithmic Deference

“O modelo recomendou.”

Isso não encerra discussão.

FerrisGPT pode errar.

Ferris humano também.

Blue Team precisa manter julgamento.


☕ IA como conselheiro, não oráculo

Essa é uma postura saudável.

Use capacidade.

Questione.

Valide.

Audite.


🔴 O atacante pode fabricar confiança algorítmica

Se sistema possui scoring, atacante pode tentar parecer normal.

Se sabe quais sinais importam, ajusta comportamento.

Goodhart aparece de novo.


📊 Métrica vira alvo

Se IA usa:

frequência;

horário;

volume;

então adversário pode tentar moldar esses sinais.

Detection Engineering precisa considerar adversarial behavior.


🧠 Slow and Low

Atacante pode agir lentamente.

IA pode ajudar a manter consistência em campanhas longas.

Ferris talvez não precise mais improvisar cada interação.

Sistema guarda contexto.


🧬 Memory aumenta persistência

Agentes com memória lembram:

quem respondeu;

o que disse;

qual pretexto;

próxima etapa.

Isso melhora continuidade.

Também cria risco de vazamento.


🔐 Agent Memory precisa de segurança

Quem pode ler?

Quanto tempo guarda?

Quais dados?

Pode ser envenenada?

Ferris também atacaria memória.


🧠 Poisoned Memory

Se atacante insere informação falsa, agente pode carregá-la para futuro.

É uma nova forma de persistência sem malware tradicional.


☕ “Cameron confia em Ferris” agora virou embedding

Quase poético.

Antes era relação humana.

Agora sistemas podem armazenar relações semanticamente.

Se essa memória estiver errada, comportamento pode ser influenciado.


🧪 Red Team precisa atacar ciclo inteiro

Entrada.

Processamento.

Memória.

Ferramenta.

Saída.

Cada fase.


🔵 Purple Team com IA

Red e Blue podem compartilhar achados.

Exemplo:

Red descobre prompt injection.

Blue cria detecção.

Engineering adiciona validação.

Governance revisa permissão.

Isso é maturidade.


🧠 Não transforme IA em teatro de segurança

Comprar ferramenta com AI no nome não resolve.

Pode apenas adicionar outro dashboard.

Ferris ama buzzword sem controle.


☕ “AI-Powered Zero Trust Cognitive Autonomous Security Mesh”

Bonito.

Ferris pergunta:

— A conta ainda tem senha compartilhada?

Silêncio.

Fundamentos continuam ganhando.


🔐 Basic Hygiene continua brutalmente eficaz

MFA.

PAM.

Least Privilege.

Patch.

Logging.

Backup.

Segmentation.

Training.

FerrisGPT é sofisticado.

Mas muitas vezes entra pela porta velha.


🧠 Não perca tecnologia nova procurando problema exótico

IA muda ameaça.

Mas não abandone básico.

Um Ferris com LLM ainda vai preferir credencial fraca se funcionar.

Atacante é econômico.


🔴 Red Team deve testar o caminho mais barato

Se phishing simples funciona, por que deepfake?

Se senha reutilizada funciona, por que zero-day?

Ferris não busca glamour.

Busca resultado.


☕ O filme de 2026 seria muito curto?

Talvez.

Ferris poderia automatizar muita coisa.

Mas segurança também melhorou.

MFA.

EDR.

SIEM.

Behavior Analytics.

Zero Trust.

PAM.

Então o jogo continua.


🧠 É escalada, não vitória definitiva

Ataque melhora.

Defesa melhora.

Ataque adapta.

Defesa adapta.

Esse é o ciclo.


🎬 FerrisGPT encontra CameronGPT

Imagine o diálogo:

FerrisGPT:
Crie três hipóteses.

CameronGPT:
Não gosto disso.

FerrisGPT:
Execute cenário 2.

CameronGPT:
Isso parece arriscado.

FerrisGPT:
Exatamente.

Talvez tenhamos reinventado a comédia.


🤖 O verdadeiro medo não é uma IA superinteligente

No curto prazo, talvez o risco mais banal seja mais relevante:

IA suficientemente boa fazendo trabalho suficientemente útil em escala suficientemente grande.

Não precisa consciência.

Não precisa Skynet.

Precisa API.


🧠 Automation of Mediocrity

Uma frase provocativa.

Automação transforma competência mediana em throughput enorme.

Isso pode ser ofensivamente poderoso.

Ferris não precisa contratar cem gênios.

Precisa de sistemas que executem partes repetitivas.


☕ O atacante vira gerente

Essa é a mudança.

Antes Ferris fazia tudo.

Agora ele pode orquestrar.

Pedir coleta.

Pedir resumo.

Pedir variantes.

Avaliar.

Escolher.

Ferris virou manager de agentes.


🧠 Human Creativity + Machine Scale

Essa combinação é provavelmente a mais importante.

Humano define intenção criativa.

Máquina amplia execução.

Isso vale ataque e defesa.


🦖 Bellacosa Mainframe em 2026

No nosso universo, isso significa integrar IA sem esquecer arquitetura clássica.

Se IA toca mainframe:

RACF continua relevante.

SAF continua relevante.

Auditoria continua relevante.

CICS continua transacional.

Db2 continua guardando verdade.

Só adicionamos nova camada de interpretação.


🔐 AI Gateway

Talvez seja necessário controlar acesso entre modelos e ferramentas.

Política.

Rate limit.

Autorização.

Logging.

Tudo explícito.

Não deixe agente conversar diretamente com Ferrari.


🧱 Tool Allowlist

Agente só usa ferramentas aprovadas.

Sem shell genérico.

Sem “execute qualquer coisa”.

Isso reduz flexibilidade.

E risco.

Segurança sempre negocia.


🧠 Sandboxing

Ações potencialmente perigosas podem ocorrer em ambiente isolado.

Especialmente geração de código.

Teste antes.

Não deixe FerrisGPT rodar diretamente em produção.


🧪 Simulation Mode

Uma ideia ótima.

Antes de executar, mostrar:

“Essas ações serão realizadas.”

Humano aprova.

Isso ajuda em operações críticas.


☕ Dry Run é Ferris olhando a Ferrari sem ligar

Maravilhoso.

Veja o que aconteceria.

Sem executar.

Operações adoram isso.


🔴 Guardrails precisam ser técnicos

Não apenas prompt:

“Por favor, não faça coisa perigosa.”

Isso é equivalente a:

“Ninguém toca na Ferrari.”

Já vimos esse filme.

Use controle externo.


🧠 Policy Engine

Decisão de autorização pode ocorrer fora do modelo.

Modelo pede ação.

Policy engine avalia.

Isso separa criatividade de poder.


🔐 Separation of Duties para agentes

Agent A propõe.

Agent B valida.

Humano aprova.

Sistema executa.

Talvez exagero para tarefas simples.

Mas útil para alto risco.


🧀 AI Swiss Cheese

Camadas:

System Prompt
 ↓
Input Filter
 ↓
Policy Engine
 ↓
Tool Permission
 ↓
Human Approval
 ↓
Logging
 ↓
Monitoring

Nenhuma é perfeita.

Juntas reduzem risco.

Ferris precisa alinhar mais buracos.


🧠 Defense in Depth nunca sai de moda

Mesmo quando muda o buzzword.


📞 E voice cloning?

Procedimento.

Não confie apenas na voz.


🎥 Deepfake?

Procedimento.


✉️ Phishing perfeito?

Procedimento.


🤖 Agente malicioso?

Permissão.

Logging.

Isolamento.


🦖 Mainframe?

RACF.

Segregação.

Auditoria.


☕ Tudo volta ao básico

É quase frustrante.

Depois de toda revolução tecnológica, terminamos falando de:

identidade;

confiança;

privilégio;

contexto.

Ferris entendeu isso em 1986.


🧠 A pergunta Bellacosa número 1

Numa War Room de IA:

“Qual é a ação mais perigosa que este agente consegue executar sozinho?”

Essa pergunta define risco.


🔴 Pergunta número 2

“Se o modelo for enganado, o sistema externo ainda bloqueia a ação?”

Se não:

problema.


🧠 Pergunta número 3

“Quem autentica o agente?”


🔐 Pergunta número 4

“Quem autoriza cada ferramenta?”


📜 Pergunta número 5

“Conseguimos reconstruir exatamente o que ele fez?”

Se não:

auditoria insuficiente.


🧯 Pergunta número 6

“Como desligamos isso?”

Sempre importante.


🧠 Pergunta número 7

“Estamos protegendo a IA ou apenas dizendo para ela se comportar?”

A Ferrari volta.


☕ FerrisGPT é inevitavelmente engraçado

Porque ele combina duas eras.

O adolescente analógico.

O mundo de agentes.

Ferris provavelmente olharia para tudo isso e faria uma pergunta muito simples:

“Então eu posso pedir para o computador fazer as partes chatas?”

Sim.

Essa é parte da revolução.


🎬 Mas Ferris continuaria necessário

Porque tecnologia não substitui intenção.

Alguém precisa perceber oportunidade.

Combinar contexto.

Escolher timing.

Improvisar.

Criatividade adversarial continua sendo diferencial.

FerrisGPT não mata Ferris.

Amplifica.


🧠 E essa é a parte que deveria preocupar o Blue Team

Não uma IA autônoma dominando o mundo.

Mas milhares de operadores tendo acesso a ferramentas que reduzem custo de:

reconhecimento;

personalização;

automação;

análise.

A superfície muda economicamente.


🔵 A resposta defensiva

Não pode ser:

“bloqueie IA.”

Isso seria inútil.

Precisa ser:

melhore identidade;

fortaleça processo;

reduza privilégio;

aumente observabilidade;

treine verificação;

controle agentes;

proteja dados;

teste.


🧪 Red Team continuamente

Porque ambiente muda.

Modelo atualiza.

Agente ganha ferramenta.

Processo muda.

Novo risco aparece.

Teste periódico.


🧠 Threat Modeling de IA

Antes de deploy:

que dados recebe?

que ações faz?

quem controla prompt?

quem pode influenciar RAG?

que ferramentas possui?

qual blast radius?

Isso é muito mais barato antes.


☕ Não faça “FerrisGPT em produção” sexta-feira às 17h

Conselho universal.

Especialmente se o rollback for:

“vamos ver depois.”

Já tivemos artigo sobre Ferrari em marcha a ré.


🔴 IA com acesso crítico precisa maturidade proporcional

Protótipo divertido?

Tudo bem.

Produção bancária?

Outro nível.

Governança não pode chegar depois.


🧠 Security by Design

Permissão.

Logging.

Fallback.

Monitoring.

Kill switch.

Tudo desde início.

Não coloque depois.


🦖 O mainframe ensina isso há décadas

Confiabilidade não aparece por esperança.

É arquitetura.

FerrisGPT precisa aprender com sistemas que sobreviveram a décadas de produção.


☕ Epílogo: quantos Ferris cabem numa API?

Ferris Bueller de 1986 era limitado pelo corpo.

Uma voz.

Um telefone.

Um Cameron.

Um dia.

Ferris de 2026 pode coordenar sistemas.

Processar mais informação.

Gerar mais contexto.

Executar mais interações.

A pergunta de segurança muda.

Não é mais apenas:

“Esse ataque é possível?”

É:

“Esse ataque é escalável?”

Porque quando custo marginal cai, risco muda.

Engenharia social deixa de ser necessariamente artesanal.

OSINT ganha velocidade.

Phishing ganha personalização.

Voz ganha síntese.

Vídeo ganha fabricação.

Agentes ganham ferramentas.

E sistemas críticos ganham novos intermediários.

Mas existe uma ironia deliciosa.

Depois de toda essa tecnologia...

as fraquezas continuam familiares.

Confiança excessiva.

Privilégio excessivo.

Falta de validação.

Contexto perdido.

Processo fraco.

Identidade mal modelada.

Ferris só ganhou mais braços.

Então, antes de perguntar:

“O que aconteceria se Ferris tivesse IA?”

Pergunte:

“O que aconteceria se alguém pudesse executar cem versões da criatividade de Ferris ao mesmo tempo?”

Talvez esse seja o verdadeiro salto.

Não Ferris mais inteligente.

Ferris em paralelo.

Ferris no telefone.

Ferris no e-mail.

Ferris no chat.

Ferris analisando documentos.

Ferris imitando voz.

Ferris testando contexto.

Ferris coordenando agentes.

Enquanto Rooney continua olhando para um único alerta e dizendo:

“EU SEI QUE É ELE!”

SAVE FERRIS.

No próximo artigo:

Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago

Porque depois de ganhar um exército de estagiários sintéticos...

era inevitável que Ferris acabasse encontrando o 3270.

quinta-feira, 1 de junho de 2017

Você Conhece o Diretor Rooney? — OSINT Antes do Google Existir

 B

Bellacosa Mainframe e o osint 

☕ Um Café no Bellacosa Mainframe — Especial Red Team

“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir

🔎 Como informação aparentemente inútil sobre pessoas, hábitos e organizações se transforma em superfície de ataque

Antes do Google.

Antes do LinkedIn.

Antes do GitHub.

Antes de alguém publicar no Instagram uma foto do crachá, da sala de reunião, do notebook corporativo, do quadro branco e, de bônus, metade da arquitetura da empresa ao fundo.

Já existia reconhecimento.

Ferris Bueller sabia disso.

Talvez não chamasse de OSINT.

Talvez não conhecesse a sigla.

Talvez jamais tivesse usado a expressão Open Source Intelligence.

Mas fazia algo muito parecido.

Ele observava.

Guardava informações.

Entendia pessoas.

Percebia relações.

Sabia quem mandava.

Sabia quem obedecia.

Sabia como as pessoas falavam.

Sabia quando alguém estava distraído.

Sabia que contexto vale tanto quanto tecnologia.

E, acima de tudo, entendia uma coisa que continua verdadeira em 2026:

antes de atacar um sistema, descubra como o sistema pensa.

Bem-vindo ao quarto episódio de:

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

Hoje nosso alvo não é uma vulnerabilidade.

É uma organização inteira vista de fora.


🔴 Red Team não começa com nmap

Existe uma imagem muito confortável do atacante.

Ele abre o terminal.

Digita:

nmap -sV -O target

E pronto.

A aventura começa.

Só que, em operações reais, muitas vezes o passo mais importante acontece antes.

Muito antes.

Antes de descobrir portas.

Antes de descobrir versões.

Antes de tentar credenciais.

O atacante pergunta:

“Quem é você?”

Não o servidor.

A empresa.


🧠 Organizações vazam personalidade

Toda organização fala.

Mesmo quando não percebe.

Fala em:

sites;

vagas;

redes sociais;

documentos;

press releases;

apresentações;

currículos;

conferências;

repositórios;

fóruns;

notícias;

vídeos;

fotos;

PDFs;

e-mails;

linguagem.

Esses pequenos pedaços, isoladamente, parecem inofensivos.

Juntos?

Podem formar um mapa.


☕ Comece pelas pessoas

Se eu estivesse pensando como Ferris, eu não perguntaria inicialmente:

Qual versão do Apache vocês usam?

Eu perguntaria:

Quem trabalha aqui?

Depois:

Quem manda?

Depois:

Quem cuida da tecnologia?

Depois:

Quem resolve problema fora de hora?

Depois:

Quem parece confiar em quem?

Essa sequência muda tudo.

Porque tecnologia existe dentro de uma estrutura humana.


👔 Quem manda?

Organogramas são ouro.

Mesmo quando não são publicados formalmente, redes profissionais fazem boa parte do trabalho.

Você descobre:

CEO;

CIO;

CISO;

diretores;

gerentes;

líderes técnicos;

arquitetos;

administradores;

desenvolvedores;

terceirizados.

Agora você conhece hierarquia.

E hierarquia é contexto.


🎭 Quem confia em quem?

Essa é uma pergunta ainda melhor.

Um diretor aparece frequentemente em fotos com determinada equipe.

Um gerente sempre cita o mesmo fornecedor.

Um arquiteto trabalha há anos com determinado parceiro.

Uma pessoa troca mensagens públicas com outra.

Nada disso é necessariamente sensível.

Mas começa a desenhar relações.

E relações são úteis para pretexting.


📞 Como as pessoas falam?

Essa parte é deliciosamente ignorada.

Toda empresa possui dialeto.

Termos internos.

Abreviações.

Nomes de projetos.

Jeitos de chamar sistemas.

Uma empresa pode dizer:

“produção.”

Outra:

“prod.”

Outra:

“PRD.”

Outra:

“ambiente quente.”

Se você conhece o vocabulário correto, parece pertencer ao ambiente.

Ferris entenderia isso imediatamente.


🧬 Linguagem é credencial social

Imagine duas mensagens.

Primeira:

Precisamos acessar o servidor principal.

Genérica.

Agora outra:

Precisamos validar o job de fechamento antes da janela do batch porque o processo Atlas travou depois da mudança de ontem.

A segunda parece muito mais legítima.

Por quê?

Porque contém contexto.

Linguagem.

Ritmo.

Referência.

Nada disso prova identidade.

Mas tudo isso aumenta plausibilidade.


🔎 OSINT é montar quebra-cabeça

Um pedaço sozinho vale pouco.

Mas combine:

uma vaga;

um perfil de funcionário;

um repositório público;

um PDF;

uma apresentação técnica;

uma foto;

uma postagem;

Agora talvez você descubra:

stack;

fornecedor;

ferramentas;

arquitetura;

nomes internos;

cronograma;

times responsáveis.

É isso que torna OSINT tão poderoso.


💼 Vagas de emprego contam segredos demais

Empresas querem atrair candidatos.

Então publicam:

“Buscamos profissional com experiência em…”

E entregam metade do stack.

Exemplo:

z/OS
CICS
Db2
MQ
Jenkins
GitLab
Ansible
z/OS Connect
AWS

Excelente.

Para recrutamento, ótimo.

Para reconhecimento, também.


🧠 Agora inferimos arquitetura

Se a empresa pede:

z/OS Connect;

API management;

OAuth;

CICS;

COBOL;

Talvez exista algo parecido com:

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

Ninguém publicou o diagrama.

Mas o diagrama começou a aparecer sozinho.


🦖 O mainframe deixa pegadas

Existe um mito divertido de que mainframe é invisível.

Não é.

Talvez o z/OS esteja magnificamente protegido.

Mas o ecossistema ao redor deixa rastros.

Vagas.

Certificações.

Posts.

Conferências.

Case studies.

Perfis de funcionários.

Documentação.

Integrações.

O atacante talvez não veja o mainframe.

Mas vê a sombra dele.


📦 GitHub: o armário que alguém esqueceu aberto

Repositórios públicos podem ser maravilhosos.

Projetos antigos.

Exemplos.

Scripts.

Templates.

Nomes de ambientes.

Padrões de configuração.

Nada necessariamente secreto.

Mas um atacante pode aprender muito.

Especialmente se alguém cometeu o clássico:

“Só vou colocar isso temporariamente.”

A palavra temporariamente possui uma longevidade impressionante em TI.


🧾 Metadata: o rodapé que fala demais

Documentos públicos também carregam pistas.

Autores.

Softwares utilizados.

Nomes internos.

Datas.

Estruturas.

Às vezes metadata revela mais do que o próprio conteúdo.

Um PDF pode dizer:

Autor: Fulano.

Aplicação: Microsoft Word.

Nome original: Projeto_X_Final_v12_CONFIDENCIAL.docx

Ops.


📸 Fotos são documentos técnicos acidentais

Uma selfie inocente no escritório pode mostrar:

crachá;

monitor;

hostname;

diagrama;

quadro branco;

telefone;

adesivo;

nome de sala;

badge de visitante.

Nada disso transforma alguém em vilão.

Mas cada item ajuda a construir contexto.


🧩 Contexto acumulado vira superfície de ataque

Pense:

Nome do gerente
+
Nome do projeto
+
Fornecedor
+
Tecnologia
+
Prazo
+
Jargão
+
Horário

Agora um pretexto começa a parecer real.

Ferris não precisa inventar o mundo.

Ele só precisa encaixar nele.


🎬 Rooney também é informação

O diretor Rooney é perfeito para essa metáfora.

Ele é previsível.

Tem cargo.

Tem autoridade.

Tem comportamento.

Tem obsessão.

Se você conhece Rooney, consegue prever parte das reações.

Isso é importante.

OSINT não serve apenas para descobrir tecnologia.

Serve para entender pessoas.


🧠 Hábitos são dados

Quem chega cedo?

Quem trabalha tarde?

Quem viaja muito?

Quem publica em conferência?

Quem responde rápido?

Quem parece resolver tudo?

Quem costuma abrir exceção?

Tudo isso pode ser relevante.

Atacantes estudam padrões.

Red Team deveria fazer o mesmo — com autorização e propósito defensivo.


⏰ Quando estão distraídos?

Timing importa.

Fechamento financeiro.

Fim do mês.

Migração.

Incidente.

Auditoria.

Feriado.

Troca de turno.

Reorganização.

A empresa inteira sob pressão muda comportamento.

Pessoas cansadas verificam menos.

Pessoas com urgência aceitam mais exceções.


🔥 Crise reduz controles

Imagine uma sexta-feira, 18h45.

Produção instável.

Diretor ligando.

Cliente reclamando.

Fornecedor em call.

Nesse ambiente, alguém diz:

— Preciso liberar isso agora.

A resistência diminui.

Não porque as pessoas são incompetentes.

Porque estão sob pressão.

OSINT pode revelar até janelas desse tipo.


🧠 Red Team procura previsibilidade

Não basta encontrar vulnerabilidade.

O atacante quer descobrir:

quando;

onde;

com quem;

em qual contexto.

Ferris é mestre nisso.

Ele não age aleatoriamente.

Ele escolhe momento.


🛠️ Ferramentas mudam, mentalidade não

Em 1986, reconhecimento era:

telefone;

observação;

conversa;

papel;

memória.

Em 2026:

mecanismos de busca;

redes sociais;

repositórios;

dados públicos;

IA;

automação.

A escala mudou brutalmente.

Mas o princípio é igual.


🤖 IA transforma OSINT em amplificador

Um humano pode ler 100 perfis.

Uma ferramenta pode resumir milhares de dados.

IA pode organizar:

nomes;

relações;

tecnologias;

projetos;

termos;

padrões.

Isso aumenta velocidade.

Mas também aumenta risco de interpretação errada.

Nem tudo que parece conexão é conexão real.

Por isso inteligência precisa de validação.


🧠 Inferência não é fato

Esse é um ponto essencial.

OSINT produz pistas.

Nem toda pista é verdade.

Uma vaga pode refletir projeto futuro.

Um perfil pode estar desatualizado.

Um GitHub pode ser pessoal.

Uma foto pode ser antiga.

Red Team profissional precisa distinguir:

OBSERVADO
INFERIDO
CONFIRMADO

Misturar os três cria erro.


☕ Ferris talvez errasse menos porque observava contexto

A graça de Ferris é que ele não apenas coleta informação.

Ele interpreta.

Sabe como cada pessoa funciona.

A inteligência útil não é acumular dados.

É entender o significado.


🧱 Ataque sem reconhecimento é desperdício

Imagine tentar engenharia social sem saber:

nomes;

estrutura;

linguagem;

processos.

Você soa genérico.

Agora imagine conhecer tudo isso.

A história fica plausível.

Por isso reconhecimento reduz ruído.


🕵️ “Você conhece o diretor Rooney?”

Essa pergunta resume muito.

Se você conhece o nome correto, parece interno.

Se sabe o cargo, melhor.

Se sabe comportamento, melhor ainda.

Se sabe quem responde a ele, seu mapa cresce.

OSINT transforma pessoas em nós de um grafo.


🕸️ Organização como grafo

Pense assim:

Rooney
  ↓
Secretaria
  ↓
Professores
  ↓
Alunos
  ↓
Pais

Agora adicione relações.

Quem reporta para quem?

Quem aprova?

Quem acessa?

Quem confia?

Quem conhece?

Essa visão de grafo é muito mais poderosa do que uma lista de nomes.


🔐 Acesso também é relação

Em ambientes técnicos, isso vira:

User
 ↓
Group
 ↓
Role
 ↓
Application
 ↓
Data

No mainframe:

USERID
 ↓
RACF GROUP
 ↓
PROFILE
 ↓
RESOURCE

No mundo humano:

Pessoa
 ↓
Confiança
 ↓
Autoridade
 ↓
Exceção
 ↓
Acesso

As duas redes se encontram.


🧨 E é aí que nasce o problema

Se uma pessoa específica pode aprovar determinada mudança e um atacante sabe:

quem ela é;

como fala;

quem é seu chefe;

qual projeto está correndo;

qual fornecedor participa;

temos contexto suficiente para tentar manipular o processo.

De novo:

não atacamos tecnologia.

Atacamos confiança.


🧾 Documentos públicos contam história operacional

Relatórios anuais.

Apresentações.

Case studies.

Whitepapers.

Slides de conferência.

Tudo isso pode revelar:

fornecedores;

plataformas;

migrações;

estratégias;

prioridades.

A empresa quer mostrar competência.

O Red Team vê arquitetura.


🎤 Conferências são maravilhosas

Profissionais técnicos adoram contar como resolveram problemas.

E devem.

Compartilhar conhecimento é ótimo.

Mas é preciso equilíbrio.

Um slide pode explicar exatamente:

como a empresa conecta sistemas;

quais produtos usa;

qual arquitetura adotou;

que problema ainda possui.

OSINT não significa impedir compartilhamento.

Significa compreender o que está sendo exposto.


🔵 Blue Team deveria fazer OSINT contra si mesmo

Essa é uma prática excelente.

Procure sua própria empresa.

Veja o que aparece.

Descubra:

quais e-mails;

quais documentos;

quais tecnologias;

quais nomes;

quais repositórios;

quais informações históricas.

É quase um espelho.


🧠 Pergunta simples: o atacante sabe mais sobre nós do que imaginamos?

Muitas vezes, sim.

E esse é o problema.

Funcionários internos supõem que certas informações são “internas” porque nunca foram oficialmente publicadas.

Mas talvez estejam espalhadas em 20 lugares.


🧩 Fragmentos públicos formam inteligência privada

Essa é a mágica.

Nenhum pedaço é secreto.

O conjunto, porém, revela algo que ninguém publicou diretamente.

Isso é inteligência.


🧪 Exemplo: reconstruindo um ambiente

Imagine encontrar:

Perfil 1:

Administrador z/OS.

Perfil 2:

Especialista CICS e MQ.

Vaga:

z/OS Connect + OAuth.

Postagem:

Migração de APIs concluída.

Apresentação:

Modernização de COBOL.

Você talvez infira uma arquitetura inteira.

Não certeza.

Mas hipótese forte.


🚪 O atacante então escolhe a porta

Talvez não ataque o mainframe.

Pode atacar:

pipeline;

API;

desenvolvedor;

fornecedor;

Help Desk;

credencial.

Reconhecimento serve para escolher caminho barato.

Atacantes são econômicos.


💰 O caminho mais fácil vence

Se quebrar criptografia custa semanas e convencer alguém custa dez minutos, adivinhe o que será tentado primeiro.

Essa é uma verdade simples.

Segurança gosta de imaginar atacantes apaixonados pela tecnologia.

Atacantes gostam de eficiência.

Ferris também.


🎩 Criatividade adversarial é combinar banalidades

Uma lista de funcionários não é exploit.

Uma vaga não é exploit.

Uma foto não é exploit.

Um PDF não é exploit.

Mas:

FUNCIONÁRIO
+
PROJETO
+
TECNOLOGIA
+
HORÁRIO
+
AUTORIDADE

pode virar pretexto.

O exploit está na combinação.


🚨 “Mas tudo isso é público”

Exatamente.

Esse é o ponto.

OSINT trabalha com o que está disponível.

O problema não é necessariamente que algo foi “vazado”.

É que informações legítimas podem ser correlacionadas.


🧠 Segurança não deve virar paranoia

Também é importante não enlouquecer.

Não dá para esconder todos os funcionários.

Apagar LinkedIn.

Parar conferências.

Proibir GitHub.

Isso seria absurdo.

A meta é entender risco.

Separar o que pode ser público do que adiciona risco desnecessário.


🧭 Classificação ajuda

Pergunte:

isso precisa ser público?

isso revela tecnologia crítica?

isso revela arquitetura?

isso entrega nomes internos?

isso ajuda um atacante a construir pretexto?

Às vezes a resposta será:

sim, vale o risco.

Tudo bem.

Segurança é gestão de risco, não invisibilidade total.


🦖 Mainframe e falsa sensação de isolamento

Em ambientes mainframe, vejo uma armadilha mental clássica:

“Nosso z/OS não está exposto.”

Ótimo.

Mas:

quem administra?

como desenvolve?

como faz deploy?

quais APIs chegam?

quais fornecedores acessam?

quais ferramentas integram?

O mainframe pode estar isolado.

O ecossistema não.


🔐 RACF aparece no LinkedIn também

Um profissional publica:

“Especialista RACF.”

Outro:

“Responsável por IAM no z/OS.”

Agora sabemos quem entende identidade.

Isso não é motivo para esconder carreira.

Mas mostra como pessoas fazem parte da superfície de informação.


🤖 Agentes de IA podem acelerar coleta

Ferris moderno poderia pedir:

“Liste tecnologias usadas por esta organização a partir de fontes públicas.”

Em minutos, teria resumo.

Isso democratiza capacidade de reconhecimento.

Mais uma razão para organizações entenderem sua pegada digital.


🛡️ Defesa começa conhecendo sua própria pegada

Um Blue Team deveria periodicamente perguntar:

o que existe sobre nós?

o que alguém pode inferir?

quais dados estão desatualizados?

quais documentos ainda estão indexados?

quais repositórios ficaram públicos?

quais contas antigas continuam ativas?

Essa higiene reduz surpresa.


☕ A pergunta Bellacosa

Eu colocaria esta na parede:

“Se eu fosse um atacante e tivesse apenas internet, o que conseguiria aprender sobre nós em uma tarde?”

Essa pergunta vale ouro.

Talvez a resposta seja:

mais do que você gostaria.


🎬 Ferris não precisava do Google

Ferris conhecia seu ambiente porque vivia nele.

Observava.

Conectava pontos.

Entendia comportamento.

Hoje temos ferramentas infinitamente melhores.

Mas muitos continuam cometendo o mesmo erro:

coletam dados e não entendem contexto.

Ferris faria o contrário.

Poucos dados.

Boa interpretação.


🧠 Reconhecimento é reduzir incerteza

Essa talvez seja a melhor definição.

Antes do recon:

você não sabe nada.

Depois:

sabe quem;

sabe o quê;

sabe quando;

sabe como;

sabe relações.

Isso reduz incerteza.

E aumenta eficiência.


🔴 Red Team começa com perguntas

Não com ferramentas.

Perguntas.

Quem trabalha aqui?

Quem manda?

Quem confia em quem?

Como as pessoas falam?

Que sistemas utilizam?

Quando estão distraídas?

Essas perguntas parecem humanas demais para cybersecurity.

E justamente por isso são poderosas.


☕ Epílogo: Rooney estava na superfície de ataque

O diretor Rooney não era servidor.

Não tinha endereço IP.

Não escutava na porta 443.

Mas fazia parte do sistema.

Seu cargo.

Seu comportamento.

Sua autoridade.

Sua obsessão.

Tudo isso era informação.

Ferris sabia.

E essa é a lição.

Uma organização não é apenas:

servidores;

firewalls;

APIs;

mainframes.

É também:

pessoas;

relações;

hábitos;

linguagem;

rotinas;

expectativas.

OSINT transforma tudo isso em mapa.

Então, antes de abrir o terminal, faça o que Ferris faria.

Olhe ao redor.

Escute.

Leia.

Conecte.

E pergunte:

“Quem conhece o diretor Rooney?”

Porque talvez você descubra que a porta mais importante da empresa não aparece no nmap.

Ela aparece no organograma.

SAVE FERRIS.

No próximo artigo:

Cameron, Atenda o Telefone — Social Engineering as a Service

Porque Ferris nunca foi perigoso sozinho.

O verdadeiro poder estava na cadeia.

quinta-feira, 25 de maio de 2017

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

 

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.

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