 |
| Bellacosa Mainframe e a social engineering as a service |
☕ Um Café no Bellacosa Mainframe — Especial Red Team
Cameron, Atenda o Telefone — Social Engineering as a Service
📞 Quando o atacante não trabalha sozinho e transforma pessoas legítimas em componentes involuntários do exploit
Chicago.
Um telefone toca.
Do outro lado, alguém acredita estar falando com uma pessoa legítima.
No meio da história, Cameron está desempenhando um papel que, isoladamente, parece completamente banal.
Ele atende.
Fala.
Confirma.
Interage.
Nada de malware.
Nada de exploit remoto.
Nada de buffer overflow.
Nada de zero-day.
Mas Ferris não precisa disso.
Ele precisa apenas que Cameron funcione como parte da cadeia.
E então temos algo belíssimo:
Ferris
↓
Cameron
↓
Telefone
↓
Escola
↓
Funcionário
↓
Sistema
Observe com carinho.
Nenhum desses elementos isoladamente precisa estar “quebrado”.
O telefone funciona.
Cameron fala.
A escola atende.
O funcionário segue um procedimento.
O sistema registra informação.
Tudo aparentemente correto.
E ainda assim...
o resultado é errado.
É aqui que Red Team fica realmente interessante.
Porque segurança não falha apenas quando existe uma vulnerabilidade em uma peça.
Ela também falha quando componentes legítimos se combinam de uma forma que ninguém previu.
Bem-vindo ao quinto episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
Hoje vamos falar de cadeia de confiança, engenharia social, dependências humanas e uma ideia que deveria incomodar qualquer arquiteto:
o sistema inteiro pode ser vulnerável mesmo quando cada componente parece seguro.
📞 Cameron não é o ataque
Esse detalhe é fundamental.
Cameron não precisa entender toda a operação.
Ele não precisa conhecer a arquitetura.
Não precisa saber o objetivo final.
Não precisa possuir acesso especial.
Ele só precisa cumprir sua pequena função.
Essa é uma característica poderosa de muitas cadeias de ataque.
Cada pessoa vê apenas um fragmento.
Cada sistema vê apenas uma transação.
Cada controle valida apenas sua parte.
Ninguém enxerga o todo.
Ferris enxerga.
🧠 O atacante pensa em composição
Defensores frequentemente analisam sistemas por componentes.
Servidor seguro?
Sim.
Banco seguro?
Sim.
Rede segura?
Sim.
Usuário autenticado?
Sim.
Processo aprovado?
Sim.
Então parece que está tudo bem.
O Red Team pergunta outra coisa:
“O que acontece quando conectamos tudo?”
Essa pergunta muda o jogo.
🧀 Bem-vindo ao Swiss Cheese Model
O modelo do queijo suíço é maravilhoso porque explica exatamente isso.
Imagine várias fatias de queijo.
Cada fatia representa uma camada de defesa.
Cada uma possui buracos.
Nenhuma é perfeita.
Mas normalmente os buracos não se alinham.
Então o incidente é bloqueado.
Agora imagine:
Camada 1: Pessoa
○
Camada 2: Processo
○
Camada 3: Telefone
○
Camada 4: Sistema
○
Se os buracos se alinham...
o ataque atravessa.
Não porque tudo falhou.
Mas porque pequenas imperfeições coincidiram.
☕ É exatamente o que Ferris faz
Ferris não precisa encontrar:
“a vulnerabilidade.”
Ele encontra:
vulnerabilidades pequenas o suficiente para parecer irrelevantes.
Cameron confia nele.
A escola espera determinados tipos de ligação.
O funcionário acredita no contexto.
O telefone não autentica intenção.
O sistema aceita o resultado daquela interação.
Separadamente, tudo parece aceitável.
Junto?
Exploit.
🔴 O grande erro: procurar uma única causa
Depois de um incidente, organizações adoram perguntar:
“Quem errou?”
É confortável.
Encontre uma pessoa.
Encontre uma falha.
Encontre um software.
Corrija.
Fim.
Só que sistemas complexos raramente falham assim.
Normalmente temos:
uma condição;
mais outra;
mais uma exceção;
mais uma dependência;
mais um contexto.
Quando tudo se alinha, temos incidente.
Ferris seria um excelente professor de causalidade sistêmica.
🧩 O exploit distribuído
Vamos imaginar a cadeia:
Ferris
↓
Cameron
↓
Telefone
↓
Funcionário
↓
Registro
Quem é culpado?
Ferris é o agente adversarial.
Mas cada componente seguinte apenas faz algo esperado.
Cameron fala.
O telefone transmite.
O funcionário interpreta.
O sistema registra.
Nenhum precisa estar comprometido tecnicamente.
Isso é um exploit distribuído pela confiança.
📞 Pessoas podem virar middleware
Essa metáfora é boa demais.
Em arquitetura, middleware conecta sistemas.
Em engenharia social, pessoas frequentemente fazem exatamente isso.
Elas recebem informação de um lado.
Interpretam.
Transformam.
Repassam.
Executam.
Pessoa como middleware.
E middleware humano possui características interessantes:
contexto;
empatia;
pressão;
memória;
autoridade;
cansaço;
urgência.
É poderoso.
E vulnerável.
🤖 Ferris cria um workflow humano
Pense como automação:
INPUT
↓
Cameron recebe instrução
↓
PROCESS
↓
Cameron adapta a fala
↓
OUTPUT
↓
Escola recebe mensagem
Ferris terceirizou uma etapa.
Isso é quase:
Social Engineering as a Service.
Claro que estamos brincando com a expressão.
Mas a lógica é real.
O atacante pode usar outras pessoas para realizar partes da operação.
🧠 O intermediário nem sempre sabe que participa
Esse ponto é importante.
Muitas operações maliciosas dependem de terceiros que acreditam estar fazendo algo legítimo.
Um funcionário encaminha arquivo.
Um fornecedor confirma dado.
Um atendente reseta senha.
Um colega aprova acesso.
Um usuário clica numa solicitação.
Cada um acredita estar resolvendo um problema normal.
A cadeia adversarial existe apenas na visão de quem coordena.
🎯 Orquestração é mais importante que ferramenta
Ferris não é perigoso porque possui um telefone.
Todo mundo possui telefone.
Ele é perigoso porque sabe quando usar Cameron, quando usar o telefone, quem deve receber a ligação e qual narrativa precisa existir.
Essa é a diferença entre ter ferramentas e conduzir uma operação.
☕ Red Team é coreografia
Um bom Red Team trabalha com sequências.
Reconhecimento.
Pretexto.
Contato.
Resposta.
Acesso.
Movimento.
Objetivo.
A palavra-chave é encadeamento.
Recon
↓
Contexto
↓
Pretexto
↓
Interação
↓
Confiança
↓
Ação
O ataque nasce da ordem.
🧱 Controle local versus segurança global
Essa distinção é essencial.
Um componente pode estar localmente seguro e o sistema globalmente inseguro.
Exemplo:
Help Desk valida três informações antes de resetar senha.
Ótimo.
Mas essas três informações estão publicamente disponíveis.
O Help Desk seguiu o processo.
O processo é que estava errado.
O componente passou.
O sistema falhou.
🧠 O funcionário fez exatamente o que foi treinado para fazer
Esse é um dos casos mais injustos em segurança.
Depois do incidente:
— O funcionário caiu no golpe.
Talvez.
Mas pergunte:
o procedimento permitia verificar adequadamente?
a pessoa tinha tempo?
o contexto era de urgência?
o atacante conhecia informações internas?
o treinamento cobria aquele cenário?
Se todas as condições empurram a pessoa para a decisão errada, talvez o problema seja arquitetura.
🔴 Erro humano é frequentemente erro de design
Essa frase vale ouro.
“Erro humano” às vezes é usado como descarte de responsabilidade.
Mas humanos fazem parte do sistema.
Se você depende deles, precisa projetar para comportamento humano real.
Não para comportamento idealizado.
Pessoas ficam cansadas.
Têm pressa.
Querem ajudar.
Confiam em colegas.
Respondem a autoridade.
Isso não é bug.
É humanidade.
🧀 Swiss Cheese em ambiente corporativo
Vamos construir uma cadeia hipotética:
LinkedIn
↓
Nome do gerente
↓
Telefone corporativo
↓
Help Desk
↓
Reset de senha
↓
Conta legítima
↓
Aplicação
Cada camada possui controle.
Mas pequenas falhas se alinham.
LinkedIn entrega contexto.
Telefone não prova identidade.
Help Desk usa validação fraca.
Conta não exige segundo fator robusto.
Aplicação confia na conta.
Resultado?
A cadeia inteira funciona para o atacante.
🕸️ Dependências escondidas
Sistemas modernos são teias.
Aplicação depende de IAM.
IAM depende de diretório.
Diretório depende de processos de RH.
RH depende de dados de pessoas.
Service Desk depende de procedimentos.
Procedimentos dependem de cultura.
Cultura depende de liderança.
Ferris não vê só “um computador”.
Ele vê a teia.
🦖 Mainframe também vive numa teia
Esse ponto é importante.
Você pode ter RACF impecável.
Perfis maravilhosos.
Auditoria excelente.
Mas como o usuário consegue identidade?
Como o acesso é solicitado?
Quem aprova?
Qual sistema provisiona?
Existe integração com IAM corporativo?
Existe conta técnica?
Existe acesso de emergência?
Ferris provavelmente atacaria antes do RACF.
🔐 Não tente quebrar a porta se alguém pode abrir
Essa é a lógica adversarial.
Se uma porta possui fechadura excelente, o atacante pode tentar:
enganar quem tem a chave;
convencer alguém a abrir;
obter credencial;
abusar de processo de recuperação.
O controle físico pode continuar perfeito.
O acesso acontece mesmo assim.
📞 O telefone é um protocolo de confiança
Pense nisso.
Durante décadas, o telefone funcionou como um canal semi-autenticado socialmente.
Você reconhece voz.
Reconhece número.
Reconhece contexto.
Mas tecnicamente, essas garantias podem ser fracas.
Ferris explora exatamente a diferença entre canal e confiança.
🤖 Em 2026, a cadeia fica mais perigosa
Agora temos:
voice cloning;
deepfake;
mensagens automatizadas;
LLMs;
agentes;
OSINT em escala.
Isso não muda a essência.
Apenas adiciona ferramentas.
A cadeia moderna pode parecer:
OSINT
↓
IA gera pretexto
↓
Voz sintética
↓
Funcionário
↓
MFA aprovado
↓
Conta legítima
Novamente:
cada componente isoladamente pode parecer normal.
🧠 O problema é correlação
Se cada sistema vê só seu pedaço, ninguém percebe a história.
Telefone vê ligação.
IAM vê login.
MFA vê aprovação.
Aplicação vê usuário autorizado.
Banco vê transação.
Cada sistema diz:
normal.
Mas quando correlacionamos:
Ligação suspeita
+
Reset de senha
+
Novo dispositivo
+
Acesso fora do padrão
+
Transação crítica
a história aparece.
🔵 Blue Team precisa pensar em narrativas
SIEM existe exatamente para ajudar nisso.
Não apenas coletar eventos.
Mas correlacionar.
Porque uma operação adversarial é uma história.
Logs são frases.
Incidente é o parágrafo.
O analista precisa ler o conjunto.
☕ “Todos os eventos eram permitidos”
Outra frase maravilhosa.
Sim.
Isso pode acontecer.
Um ataque pode ser composto quase inteiramente por ações permitidas.
Login permitido.
Reset permitido.
Acesso permitido.
Consulta permitida.
Transferência permitida.
O problema é o contexto.
🧠 Allowed não significa legitimate
Essa distinção merece destaque.
ALLOWED ≠ LEGITIMATE
Autorização técnica não prova legitimidade operacional.
Um usuário pode possuir permissão.
Mas a ação ainda pode ser fraudulenta.
Ferris ama essa diferença.
🪪 Contas legítimas são ouro
Atacantes gostam de contas válidas porque elas reduzem ruído.
Em vez de quebrar controles:
usam controles.
Em vez de forçar entrada:
entram pela porta.
Em vez de parecer malware:
parecem funcionário.
Cameron é parte dessa lógica.
🧨 Cadeias de ataque amam sistemas intermediários
Pense em integrações.
Um sistema confia em outro.
Outro confia em outro.
A relação vira:
A trusts B
B trusts C
C trusts D
Então a pergunta adversarial é:
se eu controlar D, até onde a confiança sobe?
Isso vale para pessoas também.
🕸️ Transitive Trust
Confiança transitiva é maravilhosa até deixar de ser.
Você confia em Cameron.
Cameron confia em Ferris.
Então, indiretamente, parte da confiança pode chegar a Ferris.
Ou:
Sistema A confia em B.
B confia em C.
C é comprometido.
Agora temos caminho.
🔐 Trust Boundary
Toda arquitetura deveria perguntar:
onde termina confiança?
onde ela é revalidada?
onde identidade muda?
onde contexto é perdido?
Essas fronteiras são críticas.
🦖 z/OS Connect como exemplo
Imagine:
Mobile App
↓
API Gateway
↓
z/OS Connect
↓
CICS
↓
COBOL
Quem autenticou o usuário?
Onde a identidade foi validada?
Que identidade chegou ao CICS?
Existe propagação?
Existe mapeamento?
Existe conta técnica?
Onde está a trilha?
Cada transição é uma trust boundary.
🧾 Se todo mundo vira APIUSER, temos Cameron demais
Se diversas pessoas chegam ao backend como uma única identidade técnica, auditoria perde granularidade.
User A
User B
User C
↓
APIUSER
Agora o backend sabe que a aplicação falou.
Mas talvez não saiba quem iniciou.
Essa perda de contexto pode complicar detecção.
🕵️ Quem realmente fez isso?
Depois do incidente:
— Foi APIUSER.
Excelente.
Quem era o humano?
Silêncio.
É o equivalente corporativo de perguntar:
— Quem telefonou?
— O telefone.
Obrigado.
🧠 Context propagation importa
Sistemas distribuídos precisam preservar contexto.
Identidade.
Origem.
Sessão.
Ação.
Isso permite reconstruir cadeia.
Sem contexto, cada componente parece inocente.
🔴 O atacante também usa fornecedores
Terceiros são particularmente interessantes.
Eles já possuem relações legítimas.
Conhecem nomes.
Processos.
Ambientes.
Possuem acessos.
Um fornecedor comprometido pode virar Cameron involuntário.
🧩 Supply Chain é Swiss Cheese em escala industrial
Fornecedor A depende de fornecedor B.
Ferramenta depende de biblioteca.
Pipeline depende de repositório.
Produto depende de pacote.
A cadeia inteira cria superfície.
O ataque não precisa atingir você diretamente.
Pode atingir alguém em quem você confia.
☕ Ferris não precisa entrar na escola se Cameron já fala com ela
Essa frase resume o artigo.
O atacante não precisa possuir relação direta com o alvo.
Pode usar intermediários.
Pessoas.
Sistemas.
Parceiros.
Serviços.
Integrações.
A cadeia é o exploit.
🧠 Segurança precisa olhar para pathways
Não apenas ativos.
Pergunte:
como alguém chega até o ativo?
Quais caminhos existem?
Quem pode abrir portas?
Quais sistemas possuem trust?
Quais processos concedem acesso?
Isso vira attack path analysis.
🗺️ Mapa de ataque
Imagine:
Internet
↓
Help Desk
↓
IAM
↓
VPN
↓
Application
↓
Mainframe
Agora coloque controles em cada etapa.
Depois pergunte:
quais dependem de decisão humana?
quais usam mesma identidade?
quais possuem exceção?
A análise fica muito mais rica.
🧠 Ferris é um orquestrador
Ele entende qual peça usar.
Cameron é ator.
Telefone é canal.
Escola é alvo intermediário.
Funcionário é processador.
Sistema é registrador.
Ferris é o controlador.
Quase uma arquitetura de microserviços sociais.
🤣 Social Engineering Microservices
Pense nisso:
Ferris Service
↓
Cameron Service
↓
Telephone API
↓
School Service
↓
Administrative Backend
Observability?
Nenhuma.
Authentication?
Social.
Authorization?
Confiança.
Logging?
Talvez papel.
Chaos Engineering?
Ferris.
🔴 Red Team testa a cadeia inteira
Isso é crucial.
Um teste superficial pode verificar apenas:
phishing.
Um Red Team mais maduro testa:
como phishing se conecta a identidade;
como identidade conecta a VPN;
como VPN conecta a aplicação;
como aplicação conecta a dados;
como detecção responde.
O valor está na cadeia.
🧪 Purple Team aprende com a cadeia
Depois, Blue e Red podem trabalhar juntos.
Onde poderíamos detectar?
No telefone?
No reset?
No novo dispositivo?
No login?
Na mudança de comportamento?
Na ação final?
Idealmente em várias camadas.
Defense in Depth.
🧀 Queijo suíço ao contrário
O atacante quer alinhar buracos.
O defensor quer desalinhá-los.
É isso.
Se uma camada falhar, outra segura.
Social Engineering
↓
MFA bloqueia
ou
MFA falha
↓
Behavior Detection alerta
ou
Detection falha
↓
Approval bloqueia
Não precisamos de perfeição.
Precisamos de independência.
🧱 Camadas dependentes são perigosas
Se três controles dependem da mesma informação, talvez você tenha apenas um controle disfarçado de três.
Exemplo:
Help Desk pergunta nome, CPF e data de nascimento.
Se todos são públicos, temos:
Controle 1
Controle 2
Controle 3
na apresentação.
Na prática:
OSINT
Uma única falha compromete todos.
🧠 Diversidade de controles importa
Autenticação forte.
Canal independente.
Segregação.
Detecção.
Limites.
Auditoria.
Quanto menos correlacionadas as falhas, melhor.
☕ A pergunta Bellacosa
Eu colocaria na War Room:
“Se este controle falhar, qual é o próximo?”
E depois:
“Ele depende da mesma coisa que o primeiro?”
Se depender, cuidado.
🚨 Um incidente perfeito pode parecer uma sequência de dias normais
Isso é o mais assustador.
Nada explode.
Nenhum servidor cai.
Ninguém vê caveira.
Apenas:
uma ligação;
um reset;
um login;
uma alteração;
uma transação.
Tudo legítimo isoladamente.
A fraude vive no encadeamento.
🎬 Cameron provavelmente não se vê como infraestrutura
Mas é.
No plano de Ferris, ele é componente.
Isso é uma lição importante para segurança.
Pessoas fazem parte da arquitetura mesmo quando o diagrama não mostra.
Se o processo depende delas, elas são parte do sistema.
🧠 Diagramas deveriam mostrar humanos
Muitos diagramas possuem:
User
↓
App
Eu adoraria ver:
Human
↓
Help Desk
↓
Manager
↓
IAM
↓
App
Porque é assim que identidade realmente vive.
🔐 Security Architecture é também Human Architecture
Treinamento.
Processo.
Cultura.
Escalada.
Verificação.
Tudo isso é controle.
E precisa ser tratado com o mesmo cuidado que firewall.
🤖 IA transforma Cameron em escala
Agora imagine milhares de interações coordenadas automaticamente.
Mensagens personalizadas.
Respostas adaptativas.
Agentes conversando.
A grande mudança não é que engenharia social nasceu.
É que ganhou escala.
Ferris artesanal virou Ferris industrial.
🛡️ Defesa também pode escalar
A boa notícia é que defesa também evolui.
Análise comportamental.
Correlation.
Risk-based authentication.
Detecção contextual.
Automação.
IA para triagem.
Mas cuidado.
Se automatizamos demais, podemos cair em Automation Bias.
Outra fatia de queijo.
🧠 O humano continua importante
Ferris vence porque entende contexto.
Defensores também precisam entender contexto.
Um alerta sozinho pode parecer irrelevante.
Um analista experiente conecta pontos.
Essa combinação de máquina + humano continua poderosa.
🔵 Rooney precisava de um SIEM melhor
Imagine Rooney vendo:
Phone Call
↓
Administrative Change
↓
Ferris Absent
Talvez percebesse.
Mas cada evento isolado não conta a história.
Rooney tinha intuição.
Faltava correlação.
☕ A grande lição
Segurança não é propriedade de componentes.
É propriedade do sistema.
Você pode comprar:
o melhor firewall;
o melhor IAM;
o melhor EDR;
o melhor mainframe;
o melhor treinamento.
Mas se a combinação criar um caminho inesperado...
Ferris entra.
🎯 Pense em caminhos, não em caixas
Arquitetura normalmente desenha caixas.
Red Team procura setas.
Caixas representam ativos.
Setas representam movimento.
E atacante vive nas setas.
Pessoa → Processo
Processo → Identidade
Identidade → Sistema
Sistema → Dado
Cada seta merece pergunta.
🧠 Quem pode influenciar quem?
Essa é a pergunta de ouro.
Quem influencia Help Desk?
Quem influencia gestor?
Quem influencia IAM?
Quem influencia pipeline?
Quem influencia API?
Quem influencia mainframe?
Mapear influência é mapear ataque.
📞 Cameron atende o telefone
E esse pequeno gesto aparentemente inocente conecta tudo.
Ferris.
Narrativa.
Canal.
Autoridade.
Escola.
Registro.
A cadeia funciona.
Nenhuma peça precisa ser “hackeada”.
Só precisa ser usada.
☕ Epílogo: o exploit está entre as peças
Esse talvez seja o ponto mais importante de toda a série até agora.
Ferris não pensa em vulnerabilidades isoladas.
Pensa em sistema.
Ele percebe que:
Cameron conhece determinada informação.
O telefone permite determinada interação.
A escola espera determinado comportamento.
O funcionário possui determinado poder.
O sistema confia no funcionário.
Então:
Ferris
+
Cameron
+
Telefone
+
Escola
+
Funcionário
+
Sistema
=
Resultado
Essa soma é o exploit.
Red Team precisa aprender a enxergar exatamente isso.
Porque o incidente que sua organização mais teme talvez não dependa de um zero-day maravilhoso.
Talvez dependa de seis coisas perfeitamente normais acontecendo na ordem errada.
E quando alguém perguntar depois:
— Qual controle falhou?
A resposta talvez seja desconfortável:
todos funcionaram.
O problema estava na combinação.
Esse é o Swiss Cheese Model.
Essa é a cadeia.
Esse é o mundo real.
E esse é Ferris Bueller transformando Cameron numa API humana antes mesmo de alguém inventar REST.
☕ SAVE FERRIS.
No próximo artigo:
O Diretor Rooney Está Procurando Malware no Lugar Errado
Porque enquanto o Blue Team procura um atacante sofisticado...
Ferris talvez esteja entrando pela recepção.
Sem comentários:
Enviar um comentário