☕ Um Café no Bellacosa Mainframe — Especial Red Team
O Diretor Rooney Está Procurando Malware no Lugar Errado
🕵️ Por que organizações caçam invasores sofisticados enquanto o atacante entra pela recepção
Existe uma cena imaginária que provavelmente acontece todos os dias em algum datacenter do planeta.
De um lado temos o SOC.
Três monitores por analista.
Dashboard piscando.
Mapa-múndi com pontinhos vermelhos.
Threat Intelligence.
EDR.
XDR.
SIEM.
SOAR.
UEBA.
NDR.
IDS.
IPS.
WAF.
Zero Trust.
Machine Learning.
Artificial Intelligence.
Uma tela mostra 14.827 eventos por segundo.
Outra mostra tentativas de conexão provenientes de países que metade da equipe precisaria procurar no Google Maps.
Na terceira existe um gráfico tão sofisticado que ninguém sabe exatamente o que significa, mas todos concordam que ficaria maravilhoso num PowerPoint para o board.
A organização gastou alguns milhões construindo sua Estrela da Morte particular.
Enquanto isso, na recepção:
— Bom dia, aqui é o Carlos da infraestrutura. Estamos com uma emergência no sistema do diretor. Você poderia confirmar uma informação para mim?
— Claro.
GAME OVER.
Nenhum zero-day.
Nenhum kernel exploit.
Nenhum ransomware polimórfico desenvolvido numa garagem subterrânea da Transnístria.
Nenhum adolescente de capuz digitando:
ACCESS GRANTEDapós quinze segundos de teclado aleatório.
Apenas uma pessoa.
Falando com outra pessoa.
E uma organização que gastou milhões protegendo computadores, mas esqueceu que seres humanos também fazem parte da arquitetura.
Bem-vindo ao sexto episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
E desta vez o diretor Rooney está procurando malware.
Só existe um pequeno problema.
Ferris não trouxe malware.
🎬 Rooney procura uma conspiração
Uma das coisas mais engraçadas em Curtindo a Vida Adoidado é a diferença entre a complexidade imaginada por Rooney e a simplicidade das soluções de Ferris.
Rooney pensa como defensor obcecado.
Ferris deve estar fazendo alguma coisa extraordinariamente sofisticada.
Existe um plano.
Existe uma conspiração.
Existe uma operação gigantesca.
Deve haver alguma prova definitiva escondida em algum lugar.
Rooney procura o equivalente cinematográfico de um APT.
Ferris trabalha com algo muito mais poderoso:
expectativas humanas.
Ele conhece as pessoas.
Conhece o funcionamento da escola.
Conhece os horários.
Conhece as relações.
Conhece as regras.
E, principalmente, sabe quando as próprias pessoas podem ajudá-lo a contornar essas regras.
Essa é uma das lições fundamentais do Red Team:
O atacante não é obrigado a utilizar a vulnerabilidade que você gastou mais dinheiro tentando impedir.
Ele utilizará a mais barata.
💰 Bem-vindo ao orçamento de cybersecurity
Imagine nossa fictícia Ferris Bueller Corporation.
O board aprovou uma transformação completa de segurança.
O PowerPoint ficou magnífico.
Temos:
Firewall de próxima geração: US$ 500.000
SIEM corporativo: US$ 1.000.000
EDR/XDR: US$ 800.000
Zero Trust Program: US$ 2.000.000
Threat Intelligence: US$ 350.000
PAM: US$ 600.000
Consultoria: US$ 750.000Total:
uma quantidade de dinheiro suficiente para Cameron comprar outra Ferrari e ainda esconder a primeira do pai.
Então chega uma ligação.
— Bom dia, aqui é o Roberto, da equipe do diretor.
— Bom dia.
— Tivemos um problema com o acesso dele. Preciso resolver isso antes da reunião das nove.
— Claro.
E pronto.
Toda aquela arquitetura tecnológica acabou de encontrar uma interface que não estava no diagrama:
MARIA — RECEPÇÃO
Maria não é vulnerabilidade.
Maria é parte de um processo vulnerável.
Essa distinção é importantíssima.
🧠 Não culpe o usuário
Existe uma tradição horrorosa em segurança:
“O elo mais fraco é o usuário.”
Conveniente.
Porque absolve todo mundo que desenhou o processo.
Se uma única ligação telefônica permite alterar algo crítico, talvez o problema não seja a pessoa que atendeu.
Talvez o problema seja existir um procedimento no qual uma pessoa possa fazer aquilo apenas porque alguém parece convincente.
Isso é arquitetura.
Não burrice.
☕ Maria está executando o procedimento
Talvez ela tenha aprendido:
“Ajude executivos rapidamente.”
“Não atrase diretoria.”
“Resolva problemas.”
“Cliente não pode esperar.”
“Produção é prioridade.”
Então aparece alguém explorando exatamente esses valores.
Urgência.
Autoridade.
Prestatividade.
Medo.
Ferris não está atacando Maria.
Está atacando:
a cultura que ensinou Maria a tomar determinada decisão.
Agora começamos a falar de Red Team de verdade.
🎭 Engenharia social é exploração de contexto
Muita gente reduz engenharia social a:
“enganar pessoas”.
É pouco.
Engenharia social eficaz explora contexto.
O atacante tenta entender:
quem é você;
o que espera;
quem respeita;
do que tem medo;
que linguagem utiliza;
quais procedimentos conhece;
quais exceções considera normais.
Depois constrói uma história que cabe naquele mundo.
É por isso que o artigo de Abe Froman importava.
Identidade inventada não precisa ser perfeita.
Precisa ser plausível.
🌭 Abe Froman voltou
Ferris não precisa apresentar um certificado internacional dizendo:
Abe Froman — Sausage King of Chicago — ISO 27001 Certified.
Ele precisa fazer o restaurante acreditar durante alguns minutos que aquela identidade é plausível.
No ambiente corporativo acontece igual.
— Sou do suporte.
— Sou do fornecedor.
— Trabalho com o diretor.
— Estou substituindo o João.
— O pessoal da infraestrutura pediu.
Cada frase tenta emprestar confiança de outra entidade.
🔗 A cadeia de confiança
Veja:
Atacante
↓
“Sou do suporte”
↓
Funcionário conhece o suporte
↓
Suporte normalmente pede informações
↓
Pedido parece plausível
↓
Funcionário cooperaNenhuma etapa parece absurda.
Esse é o perigo.
🕵️ Rooney continua olhando para o firewall
Enquanto isso:
SOC detectou 800 port scans.
Firewall bloqueou 14 países.
EDR isolou um executável suspeito.
SIEM correlacionou 300 eventos.
Excelente.
Tudo isso tem valor.
Mas o atacante não passou por ali.
Ele ligou.
🧠 Security Controls possuem campo de visão
Todo controle enxerga determinadas coisas.
Firewall vê rede.
EDR vê endpoint.
SIEM vê eventos enviados.
RACF vê acessos e recursos sob seu controle.
Câmera vê ambiente físico.
Nenhum deles, isoladamente, compreende toda a história.
O atacante procura justamente o espaço entre os controles.
🧀 O queijo suíço aparece novamente
Camada 1:
Firewall.
Camada 2:
MFA.
Camada 3:
Help Desk.
Camada 4:
procedimento de reset.
Camada 5:
usuário.
Talvez Ferris não consiga atravessar as duas primeiras.
Então ataca a terceira.
Se o Help Desk puder alterar autenticação, ele encontrou uma ponte.
🔐 MFA pode ser excelente e ainda perder
Imagine uma conta protegida por MFA.
Ótimo.
Atacante não possui segundo fator.
Então telefona:
— Troquei de celular.
Processo legítimo.
A empresa precisa resolver situações assim.
Mas agora temos um problema interessante:
qual é o processo de recuperação do MFA?
Porque recuperação faz parte da autenticação.
Se recuperar MFA é mais fácil que passar pelo MFA...
adivinhe qual caminho Ferris escolherá.
☕ A porta da frente tem biometria. A janela tem trinco de plástico.
Essa é a metáfora.
Segurança precisa olhar o sistema inteiro.
🧠 Help Desk é infraestrutura de segurança
Isso precisa entrar na cabeça das organizações.
Help Desk não é apenas suporte.
Ele pode:
resetar senha;
desbloquear conta;
alterar dispositivo;
redefinir MFA;
orientar usuário;
criar ticket;
escalar privilégio.
Isso significa que Help Desk participa do modelo de identidade.
Logo:
Help Desk é parte da superfície de ataque.
🔴 Red Team deve testar processo
Com autorização e regras claras, exercícios podem verificar:
funcionários validam identidade?
Help Desk segue procedimento?
urgência muda decisão?
autoridade muda decisão?
exceções são registradas?
ações críticas exigem segunda validação?
O resultado não deve ser:
“HAHA! Pegamos o João!”
Isso seria infantil.
A pergunta é:
por que o processo permitiu que João fosse convencido?
👔 Authority Gradient
Imagine:
— Aqui é o diretor financeiro.
A voz parece irritada.
— Estou entrando numa reunião. Preciso disso agora.
A pessoa sabe que deveria verificar.
Mas pensa:
“Vou pedir identificação ao diretor financeiro?”
Esse é Authority Gradient.
Hierarquia interfere na decisão.
Ferris adoraria.
⏱️ Urgência é um exploit psicológico
“Agora.”
“Imediatamente.”
“Antes da reunião.”
“Produção parada.”
“Cliente esperando.”
Urgência reduz reflexão.
Por isso phishing adora relógio imaginário.
🧠 Medo também funciona
— Se isso não for resolvido, teremos problema sério.
Agora funcionário não está apenas ajudando.
Está evitando punição.
Ferris encontrou outra variável.
❤️ Prestatividade também pode ser explorada
Ironicamente, bons funcionários podem ser alvos excelentes.
Querem resolver.
Querem ajudar.
Querem evitar burocracia.
Isso é qualidade profissional.
O processo precisa permitir que continuem prestativos sem transformar gentileza em bypass de segurança.
☕ O problema não é confiança
Organizações precisam de confiança.
Sem confiança ninguém trabalha.
O problema é:
confiança sem verificação em ações de alto impacto.
🔐 Trust but verify?
Melhor ainda:
confie proporcionalmente ao risco.
Pedido banal?
Processo simples.
Alteração crítica?
Verificação forte.
📞 Callback
Uma defesa clássica contra certos pretextos:
não confiar apenas na chamada recebida.
Retornar usando número oficial conhecido.
O atacante controla o canal inicial.
Você muda o canal.
Isso quebra parte da narrativa.
🧠 Out-of-band verification
Mesma lógica.
Pedido chegou por e-mail?
Confirme em outro canal.
Chegou por telefone?
Confirme por mecanismo corporativo.
Quanto maior impacto, mais importante.
🔐 Four Eyes Principle
Algumas ações deveriam exigir segunda pessoa.
Especialmente:
mudança de conta privilegiada;
reset administrativo;
alteração financeira;
exceção crítica.
Ferris pode convencer uma pessoa.
Duas independentes aumentam custo.
🧀 Nosso objetivo é desalinhamento
Lembra do Swiss Cheese?
Atacante quer alinhar buracos.
Defensor quer impedir alinhamento.
Se engenharia social passa pelo funcionário, outra camada deveria bloquear.
🖥️ EDR não detecta conversa
Essa frase parece piada.
Mas é importante.
EDR pode ser espetacular.
Só não foi projetado para detectar:
— Claro, senhor. Vou alterar.
Não é defeito do EDR.
É expectativa errada sobre controle.
📊 SIEM também não é vidente
SIEM recebe eventos.
Se processo legítimo gera evento legítimo, talvez não exista alerta óbvio.
Exemplo:
Help Desk autorizado reseta senha.
Evento:
PASSWORD RESET SUCCESSFULTecnicamente correto.
Contextualmente suspeito.
É aí que contexto importa.
🧠 Contextual Detection
Talvez possamos correlacionar:
reset incomum;
usuário privilegiado;
novo dispositivo;
login de local diferente;
ação sensível logo depois.
Agora a história começa a aparecer.
🔵 Blue Team precisa pensar como Ferris
Não basta procurar malware.
Pergunte:
o que alguém faria usando apenas funções legítimas?
Essa pergunta é poderosa.
🔴 Living off the Land — versão humana
Em sistemas, atacante pode usar ferramentas legítimas já existentes.
Na engenharia social acontece algo parecido.
Ele usa:
telefone;
Help Desk;
processo;
autoridade;
workflow.
Tudo legítimo.
Intenção ilegítima.
☕ Living off the Organization
Talvez devêssemos chamar assim.
O atacante não traz ferramenta.
Usa a organização contra ela mesma.
Ferris fez isso o filme inteiro.
🧠 Segurança baseada apenas em IOC sofre
Se atacante não instala malware, talvez não haja hash.
Não há domínio malicioso.
Não há payload.
Não há CVE.
Só comportamento.
Por isso detection precisa evoluir além de indicadores técnicos.
🕵️ Behavioral Detection
Quem fez?
Quando?
Normalmente faz?
Depois de qual evento?
Qual sequência?
Essa abordagem ajuda.
🔗 Sequência importa
Isoladamente:
reset de senha = normal.
Novo MFA = normal.
Login = normal.
Download = normal.
Juntos:
Reset
↓
Novo dispositivo
↓
Login incomum
↓
Acesso sensível
↓
DownloadAgora temos história.
🧠 Ferris trabalha com histórias
Isso é fascinante.
Atacante cria narrativa para humano.
Blue Team precisa reconstruir narrativa nos logs.
Um conta história para entrar.
Outro conta história para descobrir como entrou.
☕ SOC é arqueologia em tempo real
Você encontra fragmentos.
Evento.
Login.
Ticket.
Telefone.
API.
E tenta reconstruir civilização.
Ou, neste caso, Ferris.
🔴 Ticket também é log de segurança
Essa é subestimada.
Help Desk possui informação contextual maravilhosa.
“Usuário informou que perdeu celular.”
“Solicitação urgente.”
“Executivo pediu alteração.”
Esses dados podem ajudar investigação.
🧠 Integre mundos
SOC.
IAM.
Help Desk.
Fraud.
Physical Security.
Mainframe.
Cloud.
Quanto mais contexto, melhor.
🦖 E no mainframe?
Agora voltamos ao nosso habitat.
Imagine conta RACF muito bem protegida.
Senha.
MFA externo.
PAM.
Tudo bonito.
Mas operador autorizado pode solicitar desbloqueio por telefone.
Então Red Team pergunta:
como funciona a recuperação?
Não apenas:
“RACF está configurado corretamente?”
🔐 RACF não conhece a conversa telefônica
Ele recebe:
ALTUSER USER123 RESUMEou operação administrativa equivalente realizada por alguém autorizado.
Do ponto de vista do controle:
administrador autorizado executou ação autorizada.
O problema ocorreu antes.
🧠 Mainframe Security não termina no RACF
Essa é outra lição da temporada.
Inclui:
IAM;
Help Desk;
PAM;
MFA;
procedimentos;
operadores;
workstations;
processos de recuperação.
Ferris ataca caminho.
☕ SPECIAL protegido por processo fraco continua sendo problema
Você pode guardar autoridade poderosa.
Mas quem consegue solicitar seu uso?
Quem aprova?
Como valida?
Processo é parte do privilégio.
🔴 PAM não resolve cultura sozinho
PAM pode exigir checkout.
Mas se aprovação vira:
“Diretor pediu, libera”,
temos automação da confiança.
Ferris agradece.
🧠 Zero Trust também pode virar PowerPoint
Zero Trust não significa comprar produto chamado Zero Trust.
É princípio.
Verificar explicitamente.
Menor privilégio.
Assumir comprometimento.
Se telefonema urgente contorna tudo, arquitetura não é Zero Trust.
É:
Zero Trust, Except When Someone Sounds Important.
☕ ZT-EWSI
Zero Trust Except When Someone Is Important.
Novo framework Bellacosa.
Certificação em breve.
Chimpanzés preparando o exame.
🐒 Os chimpanzés entram no SOC
Um milhão deles.
Todos certificados.
Um olha firewall.
Outro SIEM.
Outro EDR.
Outro threat feed.
Polindexter pergunta:
— Quem está olhando o telefone?
Silêncio.
Um chimpanzé levanta a mão.
— Achei que era responsabilidade do RH.
Pronto.
Ferris passou.
🧠 Ownership ambiguity
Essa é vulnerabilidade real.
Quem é responsável pela segurança do processo?
Security?
Help Desk?
IAM?
RH?
Business?
Quando resposta é “todo mundo”...
às vezes significa:
ninguém.
🔴 Red Team encontra fronteiras organizacionais
Tecnologia A pertence a equipe A.
Processo B pertence a equipe B.
Integração C ninguém sabe.
Atacante adora essas fronteiras.
Porque controles tendem a enfraquecer entre departamentos.
🧩 O exploit pode ser burocrático
Essa frase é deliciosa.
Talvez não exista buffer overflow.
Existe:
“Fulano sempre aprova isso.”
“Quando diretor pede, pulamos etapa.”
“Fornecedor usa conta compartilhada.”
Isso também é superfície.
☕ CVE-PEOPLE?
Não.
Evite transformar pessoas em vulnerabilidades numeradas.
O problema geralmente está no sistema sociotécnico.
Essa palavra é importante:
sociotécnico.
Pessoas + tecnologia + processos + cultura.
É isso que Red Team testa.
🧠 Security Awareness não basta
Treinamento ajuda.
Mas colocar toda responsabilidade no funcionário é injusto e ineficiente.
Você pode ensinar:
“não confie em telefonema.”
Ótimo.
Mas precisa fornecer procedimento alternativo.
Como verificar?
Quem chamar?
O que fazer sob pressão?
🔐 Processo seguro precisa ser executável
Se procedimento exige vinte minutos e operação exige resposta em dois, pessoas criarão atalhos.
Security precisa caber no negócio.
Caso contrário surge Shadow Process.
🧠 Fricção excessiva cria bypass
Esse é paradoxo.
Controle muito difícil pode gerar comportamento inseguro.
Senhas impossíveis → anotadas.
Processo lento → contornado.
A segurança precisa equilibrar.
☕ Ferris vive de atalhos
Se caminho oficial é impossível, alguém inventará outro.
E depois esse caminho vira cultura.
🔴 Teste as exceções
Pergunte:
o que acontece se CEO perder celular?
Se admin esquecer senha?
Se fornecedor precisar acesso domingo?
Se produção cair às 3h?
É nesses momentos que controles são flexibilizados.
Ferris espera emergência.
🚨 Incident Mode pode reduzir segurança
Sob pressão, equipes:
compartilham credenciais;
pulam aprovação;
abrem firewall;
usam conta genérica.
Às vezes necessário.
Mas precisa governança e reversão posterior.
🧠 Temporary é perigoso
“Vamos liberar só hoje.”
Três anos depois...
Ferris encontra.
☕ Exceção sem expiração é arquitetura
Anote essa.
🔴 O telefone é uma API humana
Essa metáfora merece um café inteiro.
Entrada:
voz.
Payload:
história.
Authentication:
reconhecimento contextual.
Authorization:
confiança.
Response:
ação.
Ferris envia request.
Funcionário processa.
📞 HTTP/1.1 HUMAN
POST /helpdesk/reset
Authorization: "Sou do diretor"
Urgency: CRITICAL
Context: "Reunião em cinco minutos"
Response:
200 OK💀
GAME OVER.
🧠 Falta schema validation
A organização aceitou campos sem verificar.
Quem é você?
Como sabemos?
Qual ticket?
Qual aprovação?
Qual callback?
Human API precisa validation.
🔐 Strong Authentication para processos humanos
Não precisa transformar tudo em paranoia.
Pode usar:
ticket autenticado;
portal corporativo;
callback;
MFA;
approval workflow;
código temporário;
dupla confirmação.
Depende do risco.
☕ O objetivo é tirar decisão impossível do funcionário
Não peça que Maria reconheça deepfake perfeito.
Crie processo no qual deepfake não seja suficiente.
Isso é arquitetura madura.
🤖 E agora temos FerrisGPT
Como vimos no artigo 10, IA generativa piora esse cenário.
Voice cloning.
Personalização.
OSINT automatizado.
Mensagens melhores.
Escala.
Então treinamento baseado em:
“veja se a mensagem está mal escrita”
está envelhecendo rapidamente.
🧠 Conteúdo pode parecer perfeito
Logo precisamos verificar origem e processo.
Não estética.
🔴 “Parecia profissional” não significa nada
FerrisGPT escreve melhor que muito departamento corporativo.
Talvez até use vírgula corretamente.
O atacante evoluiu.
☕ Mas fundamentos continuam
Mesmo com IA:
callback.
MFA.
Least privilege.
Segregation.
Logging.
Process.
Ferris ganhou tecnologia.
Nós também.
🔵 Blue Team precisa caçar comportamento legítimo usado de forma ilegítima
Esse é o desafio.
Não apenas malware.
Abuso de identidade.
Abuso de processo.
Abuso de privilégio.
🧠 Identity Threat Detection
Credencial legítima pode ser arma.
Então monitore comportamento de identidade.
Mudanças.
Elevação.
Anomalias.
Sequências.
🔐 Privileged actions merecem contexto
Quem pediu?
Quem aprovou?
Por quê?
Qual ticket?
Isso ajuda investigação.
☕ Audit trail humana
Não apenas:
ADMIN01 RESET USER23Mas:
Ticket: INC12345
Requester: USER23
Approver: MANAGER7
Reason: Device replacementMuito melhor.
🔴 Rooney quer encontrar o malware
Mas talvez não exista malware.
Essa é a armadilha.
Se sua definição de incidente exige código malicioso, você não verá abuso de credencial legítima.
🧠 Credential Abuse é ataque
Session abuse.
Token abuse.
Process abuse.
Tudo pode acontecer sem malware.
☕ “Nenhum vírus foi encontrado.”
Excelente.
E o dinheiro?
Foi embora.
🔴 Segurança precisa proteger objetivo de negócio
Não apenas computador.
Se atacante consegue executar ação fraudulenta usando funções legítimas, security falhou mesmo que endpoint esteja limpo.
🧠 Ferris não quer dominar o Windows
Quer faltar à aula.
Objetivo.
Esse é pensamento adversarial.
🎯 Red Team começa pelo objetivo
“Conseguir alterar informação crítica.”
“Conseguir aprovar transação.”
“Conseguir acesso privilegiado.”
Depois procura caminho.
Talvez técnico.
Talvez humano.
Talvez ambos.
☕ O caminho mais barato vence
Atacantes reais possuem economia.
Tempo.
Risco.
Esforço.
Se telefonema funciona, não vão gastar zero-day de US$ 500 mil.
🧠 Defender's Dilemma encontra Attacker Economics
Defensor protege tudo.
Atacante precisa encontrar um caminho.
Por isso reduzir attack paths importa.
🔴 Não construa uma muralha com recepção sem procedimento
Essa é a imagem do artigo.
Fortaleza tecnológica.
Porta humana.
🧠 Segurança física também entra
Tailgating.
Crachás.
Visitantes.
Entregas.
Tudo depende de processo humano.
Novamente:
não culpe recepcionista.
Desenhe controle.
☕ “Estou com o técnico.”
Uma das frases mais poderosas da história da humanidade.
Provavelmente abriu mais portas do que muito exploit.
🔐 Visitor Management
Identificação.
Sponsor.
Registro.
Badge.
Escort.
Expiração.
Simples.
Processo.
🧠 Uniforme é pretexto visual
Colete.
Crachá.
Caixa.
Prancheta.
Pessoas interpretam sinais.
Ferris entende teatro.
🔴 Red Team também é teatro
Com autorização.
Pretexto.
Personagem.
Contexto.
Mas objetivo é testar processo.
Não constranger indivíduo.
🧠 Ethical Red Teaming
Se alguém falha, proteja pessoa.
Corrija sistema.
Treine.
Aprenda.
Expor funcionário publicamente destrói cultura.
Depois ninguém coopera com Security.
☕ Segurança baseada em humilhação gera silêncio
E silêncio é ótimo para atacante.
🔵 Crie cultura de reporte
Funcionário desconfiou?
Que possa perguntar.
Sem medo.
Recebeu ligação estranha?
Reporte.
Clicou?
Reporte rápido.
Quanto antes, menor impacto.
🧠 Punir todo erro incentiva ocultação
Se pessoa acha que será demitida por clicar, talvez esconda.
Agora atacante ganha dwell time.
🔴 Psychological Safety também é controle
Curioso, não?
Cultura influencia segurança.
☕ O botão “Report Phishing” vale ouro
Mas telefone?
Chat?
WhatsApp corporativo?
Crie canais equivalentes.
Ataques são multicanal.
🧠 Vishing merece atenção
Voice phishing.
Especialmente com voice cloning.
Treinamento precisa acompanhar.
🔐 Processo vence voz perfeita
Essa frase conecta FerrisGPT ao artigo.
Não tente vencer deepfake pela intuição.
Construa processo que sobreviva a ele.
☕ Rooney finalmente encontra alguma coisa
Depois de horas procurando malware...
ele encontra:
nada.
Nenhum trojan.
Nenhum exploit.
Nenhum C2.
Porque Ferris entrou utilizando:
confiança;
procedimento;
identidade;
autoridade.
O sistema foi usado exatamente como projetado.
Esse é o pior tipo de incidente para quem só procura tecnologia quebrada.
🧠 A tecnologia não falhou
O design de confiança falhou.
Essa distinção é brutal.
🔴 Red Team revela isso
Ele mostra:
“Se alguém fizer esta história, seu processo responde assim.”
Agora organização sabe.
Pode corrigir.
🧠 Essa é descoberta valiosa
Muito mais do que:
“Porta 443 está aberta.”
Talvez 443 devesse estar aberta.
A pergunta é:
o que alguém consegue fazer através dela?
☕ Mesma coisa com humanos
Funcionário precisa atender telefone.
A pergunta é:
o que alguém consegue convencê-lo a fazer?
🔐 Minimize autoridade humana improvisada
Para ações críticas, use workflow.
Não decisão ad hoc.
Isso protege funcionário.
🧠 Guardrails
Sistema deve impedir determinadas ações sem validação.
Mesmo se funcionário quiser ajudar.
Controle técnico apoiando controle humano.
🔴 Segurança sociotécnica
Agora chegamos ao coração.
A defesa moderna precisa juntar:
PESSOAS
+
PROCESSOS
+
TECNOLOGIA
+
CULTURA
=
SEGURANÇARemova uma parte e aparecem buracos.
☕ O orçamento também precisa refletir isso
Não adianta gastar 99% em tecnologia e 1% em processo.
Ferris seguirá orçamento inverso:
atacará onde você menos investiu.
🧠 Risk-Based Investment
Invista de acordo com attack paths reais.
Não apenas tendências de mercado.
🔴 Ferris não lê Gartner antes de atacar
Ele olha o ambiente.
Isso é Red Team.
☕ A pergunta Bellacosa número 1
“Qual ação crítica um funcionário consegue executar apenas porque alguém pediu convincentemente?”
Excelente exercício.
🧠 Pergunta número 2
“Qual processo de recuperação é mais fraco que o controle que ele recupera?”
MFA.
Senha.
Conta.
Token.
🔴 Pergunta número 3
“Que autoridade consegue criar exceção?”
Diretor?
Help Desk?
Admin?
Fornecedor?
🧠 Pergunta número 4
“Como verificamos alguém que diz ser executivo?”
🔐 Pergunta número 5
“Uma ligação pode alterar privilégio?”
Se sim, examine processo.
🧠 Pergunta número 6
“Nosso SOC consegue correlacionar evento técnico com evento humano?”
Ticket.
Reset.
Login.
Ação.
🔴 Pergunta número 7
“Estamos treinando pessoas ou apenas culpando pessoas?”
Essa dói.
🧠 Pergunta número 8
“Qual é nossa recepção digital?”
Help Desk?
Portal?
Chat?
API?
☕ Pergunta número 9
“Qual controle de US$ 2 milhões pode ser contornado por uma conversa de dois minutos?”
Talvez ninguém goste da resposta.
Ótimo.
Red Team começou.
🐒 O chimpanzé apresenta o orçamento
Nosso chimpanzé do SOC chega à reunião do board.
Slide 1:
Firewall: US$ 500.000
SIEM: US$ 1.000.000
EDR: US$ 800.000
Zero Trust: US$ 2.000.000CFO satisfeito.
Slide 2:
Funcionário recebendo ligação:
— Sim senhor, posso alterar isso.Silêncio.
Slide 3:
💀 GAME OVER.
O chimpanzé fecha o PowerPoint.
Pede banana.
Foi promovido a CISO.
🎬 Epílogo — Rooney estava procurando o invasor errado
Talvez Rooney nunca tenha entendido Ferris.
Porque procurava sofisticação onde havia compreensão humana.
Esperava conspiração.
Encontrou improviso.
Esperava tecnologia.
Encontrou contexto.
Esperava ataque frontal.
Encontrou caminho lateral.
E organizações modernas ainda cometem exatamente esse erro.
Compram ferramentas para enfrentar o adversário que imaginam.
APT.
Zero-day.
Malware sofisticado.
Exploit desconhecido.
Tudo isso existe.
Tudo merece defesa.
Mas existe também outro atacante.
Aquele que olha para a organização e pergunta:
— Quem atende o telefone?
— Quem reseta senha?
— Quem confia no diretor?
— Quem pode abrir exceção?
— Quem consegue alterar um cadastro?
— Quem possui uma conta esquecida?
— Qual procedimento todo mundo pula quando está com pressa?
Esse atacante talvez não precise derrotar seu firewall.
Seu SIEM.
Seu EDR.
Seu Zero Trust.
Ele só precisa encontrar uma pessoa autorizada a fazer alguma coisa...
e uma razão suficientemente convincente para que ela faça.
Por isso Red Team não deve perguntar apenas:
“Como quebramos a tecnologia?”
Deve perguntar:
“Como fazemos a organização quebrar suas próprias regras acreditando que está apenas trabalhando normalmente?”
Essa pergunta é muito mais desconfortável.
E muito mais útil.
Porque talvez o firewall esteja perfeito.
Talvez o SIEM esteja perfeito.
Talvez o EDR esteja perfeito.
Talvez RACF esteja perfeito.
E mesmo assim:
Telefone toca.
— Bom dia. Aqui é o diretor.
— Claro, senhor. Posso alterar isso.
CLICK.Rooney continua procurando malware.
Ferris já está no centro de Chicago.
☕ SAVE FERRIS.
Porque às vezes o exploit mais perigoso não executa código.
Executa confiança.
☕ Um Café no Bellacosa Mainframe — Especial Red Team
SAVE FERRIS — Ferris Bueller’s Red Team
Uma série de 12 artigos sobre Red Team, segurança ofensiva, engenharia social, OSINT, integridade de dados, MFA, PAM, rollback, Blue Team, inteligência artificial, RACF e z/OS, usando Ferris Bueller para explorar uma pergunta fundamental: o sistema está realmente seguro ou apenas acredita que está?
- Red Team
- OSINT
- Engenharia Social
- Blue Team
- MFA
- PAM
- IA Generativa
- RACF
- z/OS
- Mainframe
Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team
Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.
Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade
Integridade de dados, alteração de registros, privilégio, auditoria e a perigosa diferença entre aquilo que aconteceu e aquilo que o banco de dados afirma ter acontecido.
Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu
Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.
“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir
Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.
Cameron, Atenda o Telefone — Social Engineering as a Service
Ferris → Cameron → telefone → escola → funcionário → sistema. Nenhuma peça precisa falhar sozinha quando a cadeia inteira possui uma combinação explorável de confiança.
O Diretor Rooney Está Procurando Malware no Lugar Errado
Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.
A Ferrari do Cameron Não Tinha MFA
Privilégio, acesso físico, MFA, PAM, least privilege e o risco de proteger um ativo crítico apenas com medo, confiança e a esperança de que ninguém ousará tocá-lo.
Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
Rollback, restore, journaling, logs, Db2, VSAM e recuperação: voltar o estado de um sistema não significa apagar as consequências daquilo que aconteceu.
Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente
Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.
FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos
IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.
Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago
RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.
“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora
Red Team não termina em “conseguimos entrar”. Ataque deve gerar descoberta, evidência, correção, detecção e aprendizado para deixar a organização mais resiliente.
🎬 Página principal da temporada
Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron reúne os doze episódios e conecta Red Team, engenharia social, IA, Blue Team e segurança de mainframe.
☕ Acessar o especial completo SAVE FERRISSobre a série SAVE FERRIS — Red Team
A série SAVE FERRIS, publicada no Bellacosa Mainframe, utiliza situações inspiradas em Ferris Bueller para explicar conceitos de Red Team, cybersecurity, segurança ofensiva, engenharia social, OSINT, Blue Team, Purple Team, Zero Trust, MFA, PAM, inteligência artificial, RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.
O fio condutor é simples: um atacante não precisa necessariamente quebrar a tecnologia. Ele pode explorar relações de confiança, processos, identidades, privilégios, integrações e suposições existentes entre pessoas e sistemas.
A temporada acompanha o ciclo completo: reconhecimento → engenharia social → acesso → privilégio → impacto → detecção → correção → aprendizado.
Para Red Teams e Blue Teams, o objetivo final não é provar quem é mais inteligente, mas encontrar caminhos invisíveis antes que um adversário real os descubra.
Sem comentários:
Enviar um comentário