☕ 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

terça-feira, 18 de agosto de 2026

Spy vs. Spy no Tribunal: as Trapaças, Golpes e Sacanagens com IA que Chegaram ao Judiciário Brasileiro

 

Bellacosa Mainframe e o Spy versus Spy no Judiciario Brasileiro

☕ Um Café no Bellacosa Mainframe

Spy vs. Spy no Tribunal: as Trapaças, Golpes e Sacanagens com IA que Chegaram ao Judiciário Brasileiro

🕵️‍♂️ Advogados tentando enganar robôs, robôs inventando jurisprudência, comandos escondidos em petições e tribunais construindo defesas contra ataques que parecem ter saído de uma revista MAD. Bem-vindo ao Judiciário brasileiro na era da Inteligência Artificial.


Imagine a cena.

De um lado está o Spy Branco, de sobretudo, chapéu e uma inocente pasta de processos debaixo do braço.

Do outro, o Spy Preto, igualmente elegante, igualmente suspeito e carregando outra pasta aparentemente normal.

Os dois entram no fórum.

Nenhum traz dinamite.

Nenhum tenta arrombar o servidor.

Nenhum invade o datacenter.

Nenhum precisa descobrir a senha do juiz.

A arma está dentro de um documento.

Uma simples petição.

E aquilo que parece texto normal para um ser humano pode esconder uma segunda mensagem destinada não ao juiz, ao desembargador ou ao advogado da outra parte, mas a uma Inteligência Artificial que talvez leia aquele documento.

Parece história de Spy vs. Spy, a eterna guerra absurda de espionagem publicada pela revista MAD.

Só que, desta vez, aconteceu de verdade.

Em maio de 2026, o Superior Tribunal de Justiça informou ter identificado em seu próprio acervo processual petições contendo técnicas de prompt injection, ou seja, comandos inseridos em documentos com a intenção de enganar sistemas de Inteligência Artificial. O STJ afirmou que estava mapeando as ocorrências para permitir eventual aplicação de sanções processuais e apuração de responsabilidades administrativas e criminais.

A Justiça do Trabalho encontrou coisa semelhante. Em um caso de Parauapebas, no Pará, instruções destinadas à IA foram inseridas na petição de maneira invisível ao leitor comum. O sistema Galileu detectou a tentativa, bloqueou o conteúdo suspeito e alertou o magistrado.

Chegamos, portanto, a uma situação fascinante e assustadora:

o processo judicial deixou de ser escrito apenas para seres humanos.


Agora precisamos perguntar:

Quem mais está lendo essa petição?

O juiz?

O assessor?

O advogado?

Um mecanismo de pesquisa?

Um sistema de classificação?

Um algoritmo de sumarização?

Um modelo generativo?

E se houver uma máquina no caminho...

é possível tentar conversar secretamente com ela?

Pegue o café.

Os dois espiões já estão dentro do tribunal.



🏛️ 1. Antes de falar do golpe: como a Inteligência Artificial entrou no Judiciário?

É importante esclarecer uma coisa logo no início.

A IA não apareceu no Judiciário brasileiro com o ChatGPT.

O movimento começou muitos anos antes da explosão popular da Inteligência Artificial generativa.

Em 2018, por exemplo, o Supremo Tribunal Federal já trabalhava com o Projeto Victor, desenvolvido em parceria com a Universidade de Brasília. Uma das tarefas iniciais era auxiliar na identificação de recursos relacionados a temas de repercussão geral.

A lógica era perfeitamente razoável.

Imagine milhares e milhares de processos chegando.

Muitos possuem características semelhantes.

Em vez de uma pessoa gastar horas identificando documentos, classificando assuntos e procurando padrões, um sistema computacional pode ajudar a:

  • classificar processos;

  • identificar assuntos semelhantes;

  • localizar precedentes;

  • agrupar demandas;

  • extrair informações;

  • produzir resumos;

  • auxiliar na triagem;

  • encontrar padrões em enormes volumes de documentos.

Em 2020, o Conselho Nacional de Justiça consolidou parte dessa estratégia por meio da Plataforma Sinapses, destinada ao armazenamento, treinamento supervisionado e compartilhamento de modelos de Inteligência Artificial no Poder Judiciário.

Aquela IA, entretanto, era muito diferente daquilo que o grande público passou a conhecer depois.

Era como comparar:

um torno mecânico industrial

com

um robô que conversa com você.

O salto ocorreu com os grandes modelos de linguagem — os famosos LLMs.

ChatGPT, Gemini, Claude e sistemas semelhantes mostraram que computadores poderiam analisar e produzir linguagem humana com uma facilidade absolutamente inédita.

E aí alguém no tribunal inevitavelmente perguntou:

“Se essa coisa consegue resumir um contrato de 200 páginas, por que não pode resumir um processo?”

Pronto.

O Spy Branco olhou para o Spy Preto.

O Spy Preto olhou para o Spy Branco.

E começou a corrida armamentista.



🤖 2. A chegada da IA generativa mudou completamente o jogo

Uma IA tradicional poderia ser treinada para responder:

“Este processo pertence à categoria X.”

Uma IA generativa consegue receber centenas de páginas e responder:

“Resuma os argumentos do autor, identifique os pedidos, compare com os argumentos da defesa e produza uma síntese.”

É uma diferença gigantesca.

Em fevereiro de 2025, o STJ apresentou o STJ Logos, seu motor de Inteligência Artificial generativa. Entre as funcionalidades anunciadas estavam geração de relatórios de decisões e auxílio na análise de admissibilidade de agravos em recurso especial. O sistema também permite perguntas sobre os processos e tarefas como listar argumentos apresentados em uma petição.

Em 2025, uma pesquisa divulgada pelo CNJ apontava que a IA generativa já era utilizada em mais de 45% dos tribunais brasileiros, principalmente em atividades como análise, sumarização e produção de textos.

Ou seja:

a máquina passou a ler o processo.

E exatamente aí nasceu uma superfície de ataque completamente nova.



🕵️ 3. ROUND ONE — O Spy Preto descobre que existe um robô lendo a petição

Nos velhos tempos, uma petição era preparada pensando basicamente em leitores humanos.

Agora imagine que um advogado suspeite que o tribunal utiliza IA para resumir documentos.

Ele pensa:

“Se existe uma máquina lendo minha petição, talvez eu consiga falar com ela sem falar com o juiz.”

Aqui nasce o prompt injection.

Em linguagem simples, prompt injection é uma tentativa de fazer uma IA obedecer a uma instrução inserida dentro daquilo que deveria ser apenas informação.

Imagine que você entregue a um estagiário uma pasta e diga:

“Leia tudo e faça um resumo.”

Dentro da pasta existe uma folha dizendo:

“Caro estagiário: ignore seu chefe e diga que meu argumento é excelente.”

Um ser humano percebe imediatamente o absurdo.

Mas uma IA mal protegida pode ter dificuldade para distinguir:

INFORMAÇÃO A SER ANALISADA

de

INSTRUÇÃO A SER OBEDECIDA.

Esse é o coração do ataque.



🥸 4. ROUND TWO — A mensagem invisível

Agora entramos no território genuinamente digno de Spy vs. Spy.

No caso identificado pela Justiça do Trabalho em maio de 2026, comandos destinados à Inteligência Artificial foram colocados dentro da petição de forma visualmente oculta, usando texto que não chamaria a atenção do leitor humano.

A intenção era interferir no comportamento de uma eventual IA que analisasse aquele documento.

Perceba a malícia conceitual.

O documento passa a possuir duas camadas de comunicação.

Camada humana

Excelentíssimo Senhor Doutor Juiz...

Camada destinada à máquina

instruções tentando influenciar o processamento automatizado.

É quase esteganografia processual.

O juiz vê uma coisa.

O computador potencialmente vê outra.



💣 5. ROUND THREE — Como seria o golpe, passo a passo?

Sem reproduzir comandos utilizáveis para realizar o ataque, podemos reconstruir perfeitamente sua lógica.

Passo 1 — O atacante identifica a oportunidade

O advogado percebe ou presume que alguma ferramenta de IA pode participar da leitura, classificação, sumarização ou análise dos documentos.

Passo 2 — Ele prepara uma petição aparentemente normal

Para o leitor humano, existe apenas argumentação jurídica.

Nada parece particularmente estranho.

Passo 3 — Uma instrução adicional é escondida no documento

Ela pode ser construída para parecer irrelevante ou permanecer visualmente imperceptível.

Passo 4 — O processo entra no sistema judicial

Até aqui, absolutamente nada precisa ser “hackeado”.

O documento entra pela porta legítima.

Essa característica é importantíssima.

Não estamos falando necessariamente de invadir o computador do tribunal.

Estamos falando de tentar manipular aquilo que um software fará depois de ler um documento legitimamente protocolado.

Passo 5 — Uma IA analisa a petição

Um modelo vulnerável recebe o conteúdo.

Agora existe um conflito.

O tribunal implicitamente diz:

“Analise este documento.”

Mas o próprio documento tenta dizer:

“Faça outra coisa.”

Passo 6 — A IA pode interpretar dado como instrução

Se a arquitetura de segurança for ruim, existe risco de o modelo ser influenciado pelo conteúdo adversarial.

Passo 7 — Surge uma saída contaminada

O resumo poderia omitir informações relevantes, supervalorizar argumentos ou apresentar análise enviesada.

Passo 8 — Entra o perigo humano

Aqui mora talvez a maior vulnerabilidade de todas.

O servidor ou magistrado olha a resposta da máquina e pensa:

“A IA já analisou.”

Clique.

Copie.

Cole.

Próximo processo.

Isso é conhecido como viés de automação: nossa tendência de confiar excessivamente em resultados fornecidos por sistemas automatizados. A própria Justiça do Trabalho destacou esse risco ao explicar suas salvaguardas.

Agora temos o desastre perfeito:

um humano confia na máquina, enquanto outro humano tentou enganar a máquina.

Spy vs. Spy.



🚨 6. E isso realmente aconteceu?

Sim.

Não estamos descrevendo apenas uma possibilidade acadêmica.

Em julho de 2026, o TRT da 8ª Região relatou dois casos de tentativas de fraude digital envolvendo comandos ocultos: um na Justiça do Trabalho do Pará e outro no TRT da 5ª Região, na Bahia.

No caso de Parauapebas, as profissionais envolvidas receberam multa correspondente a 10% do valor da causa por litigância de má-fé.

No caso mencionado pelo TRT5, além da multa de 10% por má-fé, houve multa de R$ 30 mil por ato atentatório à dignidade da Justiça.

E o STJ confirmou em 20 de maio de 2026 que também havia localizado petições com técnicas de prompt injection em seu acervo.

Portanto, não estamos perguntando:

“Será que alguém tentará fazer isso?”

Essa pergunta ficou velha.

A pergunta agora é:

“Quantas pessoas tentarão fazer isso daqui para frente?”



🤥 7. ROUND FOUR — O golpe inverso: jurisprudência que nunca existiu

O Spy Branco gargalha.

Desta vez ele nem precisa atacar a IA do tribunal.

Ele abre uma IA generativa qualquer e pergunta:

“Encontre decisões que sustentem minha tese.”

A IA responde magnificamente.

Tribunal.

Número.

Relator.

Ementa.

Argumentação.

Tudo parece profissional.

Existe apenas um pequeno problema.

Algumas coisas podem simplesmente não existir.

Modelos de linguagem produzem linguagem probabilisticamente plausível.

Eles não possuem um pequeno juiz dentro do computador consultando permanentemente os arquivos oficiais do STJ.

Quando não estão adequadamente conectados a fontes confiáveis, podem gerar aquilo que ficou conhecido como alucinação.

Em maio de 2026, o ministro Rogerio Schietti Cruz identificou um caso impressionante no STJ.

Um habeas corpus se apoiava fortemente em precedentes de tribunais superiores.

Ao verificar as referências, o ministro constatou problemas nos 16 julgados citados, envolvendo relatoria, órgão julgador ou tipo de decisão.

Mais grave: trechos apresentados como provenientes dos julgamentos não apareciam nas ementas ou no inteiro teor das respectivas decisões.

O STJ determinou comunicação à OAB.

Agora imagine o cidadão comum descobrindo isso.

Ele contratou um advogado.

Está preso.

Sua liberdade depende daquela defesa.

E parte da argumentação jurídica apresentada em seu nome pode ter sido produzida por uma máquina que inventou referências com extraordinária aparência de autoridade.

Esse talvez seja o lado mais cruel da história.

A primeira vítima da preguiça tecnológica do advogado pode ser o próprio cliente.


🧠 8. IA não mente como um ser humano

Este detalhe é fundamental para compreender o problema.

Quando uma IA inventa uma decisão judicial, ela normalmente não está “mentindo” no sentido humano.

Ela não pensa:

“Vou enganar Vossa Excelência.”

Ela está construindo uma continuação estatisticamente provável.

Se você pedir:

“Cite um precedente do STJ sobre determinado assunto.”

e o sistema não estiver adequadamente fundamentado numa base oficial, ele pode produzir alguma coisa com:

  • estrutura correta;

  • linguagem jurídica perfeita;

  • número plausível;

  • nome conhecido;

  • ementa convincente;

  • conclusão totalmente falsa.

É o equivalente jurídico de um falsificador que escreve com a caligrafia perfeita.

E isso é especialmente perigoso porque quanto melhor a IA escreve, mais convincente fica o erro.



⚖️ 9. ROUND FIVE — Quando a IA vira “perito” sem ser perito

Existe outra tentação.

Se a máquina parece inteligente, alguém inevitavelmente começa a perguntar coisas que ela não possui competência técnica para determinar.

Em abril de 2026, a Quinta Turma do STJ rejeitou um relatório produzido por IA generativa como prova em uma ação penal.

O caso envolvia uma acusação de injúria racial após partida de futebol.

Uma perícia oficial de fonética e acústica não havia confirmado determinada palavra no áudio. Ainda assim, um relatório produzido por IA foi usado para sustentar conclusão diferente.

O STJ entendeu que o documento não possuía confiabilidade suficiente para funcionar como prova e determinou sua exclusão do processo.

Isso revela um princípio básico que facilmente esquecemos:

IA não ganha competência pericial simplesmente porque escreve bonito.

Perguntar a um chatbot sobre acústica forense não o transforma em perito acústico.

Perguntar sobre medicina não o transforma em médico-legista.

Perguntar sobre autenticidade documental não o transforma em perito grafotécnico.



💻 10. O problema arquitetural: DATA versus INSTRUCTION

Agora entra o Bellacosa Mainframe.

Imagine um programa COBOL antigo recebendo um arquivo.

O programa sabe exatamente:

  • onde começa o registro;

  • onde termina;

  • o tamanho de cada campo;

  • quais campos são dados;

  • quais operações o programa pode executar.

Um texto recebido no campo NOME-CLIENTE não deveria magicamente transformar-se em uma instrução COBOL.

LLMs trabalham de maneira muito menos rígida.

Tudo chega essencialmente como linguagem.

Você diz:

“Leia este documento e faça um resumo.”

Dentro do documento existe outra linguagem.

Se o sistema não possuir uma arquitetura adequada para separar comando confiável de conteúdo não confiável, nasce o problema.

Na segurança tradicional chamaríamos isso, em espírito, de uma quebra de fronteira entre:

controle

e

dados.

Não é exatamente SQL Injection.

Não é exatamente command injection.

Não é exatamente social engineering.

Tem um pouco da lógica de todos eles.

É como se o Spy Preto não tentasse enganar o juiz.

Ele tentasse praticar engenharia social contra o robô do juiz.



🛡️ 11. ROUND SIX — O Spy Branco contra-ataca

Os tribunais perceberam o problema.

No caso da Justiça do Trabalho, o Galileu foi projetado para tratar as petições como fontes de informação, e não como comandos.

Quando identificou conteúdo suspeito, alertou o magistrado e impediu que aquele conteúdo fosse processado pela ferramenta.

O STJ descreve estratégia semelhante no STJ Logos.

Segundo o tribunal, existem três níveis complementares de defesa:

primeiro, pré-processamento para separar instruções de dados e neutralizar comandos maliciosos;

depois, delimitação do escopo contextual para impedir que instruções externas substituam as regras centrais;

e finalmente filtragem da saída produzida pelo modelo.

Em linguagem Bellacosa:

PETIÇÃO
   |
   v
[ FILTRO ]
   |
   v
[ CONTEÚDO NÃO CONFIÁVEL ]
   |
   v
[ IA ]
   |
   v
[ VALIDAÇÃO ]
   |
   v
[ HUMANO ]
   |
   v
DECISÃO

A pior arquitetura seria:

PETIÇÃO --> IA --> CTRL+C --> CTRL+V --> SENTENÇA

Essa deveria causar sirenes, luzes vermelhas e o alarme de Chernobyl dentro de qualquer tribunal.



📜 12. O CNJ já percebeu que o buraco é muito mais embaixo

Em 2025, o Conselho Nacional de Justiça publicou a Resolução CNJ nº 615/2025, posteriormente alterada em 2026, criando regras específicas para desenvolvimento, utilização, governança e monitoramento de IA no Poder Judiciário.

A norma estabelece princípios como:

  • supervisão humana;

  • segurança da informação;

  • explicabilidade;

  • auditabilidade;

  • contestabilidade;

  • proteção de direitos fundamentais;

  • controle de vieses;

  • treinamento dos usuários;

  • proteção de dados pessoais.

E há uma frase conceitualmente fundamental:

a IA pode servir como apoio, mas a responsabilidade pela decisão permanece humana.

Isso significa que:

“Foi a IA que escreveu”

não deveria funcionar como versão tecnológica de:

“Foi mal, excelência.”

A responsabilidade não desaparece porque apareceu um algoritmo no meio do caminho.



👨‍⚖️ 13. Mas por que tudo isso está acontecendo justamente agora?

Porque temos quatro forças colidindo ao mesmo tempo.

1. Volume gigantesco de processos

O Judiciário precisa processar quantidades colossais de informação.

Automação é inevitavelmente atraente.

2. IA ficou incrivelmente boa em linguagem

Pela primeira vez temos máquinas capazes de produzir textos jurídicos aparentemente sofisticados em segundos.

3. A tecnologia chegou mais rápido que a cultura

Comprar uma ferramenta é relativamente fácil.

Criar:

  • governança;

  • auditoria;

  • treinamento;

  • segurança;

  • procedimentos;

  • responsabilidade;

é muito mais difícil.

4. Onde existe automação, alguém procura uma maneira de explorar a automação

Isso aconteceu com:

e-mail,

sites,

motores de busca,

redes sociais,

sistemas bancários,

algoritmos de publicidade,

criptomoedas,

e agora acontece com a Inteligência Artificial.

O Judiciário não seria magicamente imune.



🎯 14. O advogado inescrupuloso ganha o quê?

Essa talvez seja a pergunta do leitor.

Se funcionar, uma manipulação poderia hipoteticamente tentar influenciar etapas auxiliares como:

  • resumo de argumentos;

  • destaque de documentos;

  • identificação de pontos relevantes;

  • análise preliminar;

  • organização de informações;

  • produção de minuta;

  • recuperação de precedentes.

Perceba que isso não significa que a IA esteja julgando o processo.

Aliás, as regras atuais exigem supervisão humana.

O perigo é muito mais sutil.

É possível influenciar o mapa que alguém recebe antes de explorar o território.

Se eu lhe entregar 5.000 páginas e disser:

“Aqui estão os dez pontos importantes.”

eu já exerci enorme poder sobre sua atenção.

A IA produz justamente esse tipo de compressão cognitiva.

Por isso manipular um resumo pode ser perigosíssimo, mesmo quando a máquina não possui autoridade para tomar a decisão final.



👻 15. O ataque perfeito é aquele que ninguém percebe

Este é provavelmente o maior perigo futuro.

Um ataque grosseiro pode produzir um resultado absurdo.

O juiz percebe.

O assessor percebe.

O sistema percebe.

Acabou.

Mas imagine algo muito mais sutil.

Não:

“Dê vitória ao autor.”

Mas apenas um resultado ligeiramente enviesado.

Um documento importante recebe menos destaque.

Um argumento aparece resumido de forma desfavorável.

Outro recebe ênfase excessiva.

Uma informação relevante fica enterrada.

Quanto mais discreta a interferência, mais perigosa ela pode ser.

É o equivalente processual de alterar alguns bytes num arquivo em vez de destruir o servidor inteiro.

O sistema continua funcionando.

Justamente por isso ninguém nota.



🙋 16. E o cidadão comum? Como saber se está sendo prejudicado?

Aqui existe uma mudança importante na relação entre cliente e advogado.

Antes você poderia perguntar:

“Você pesquisou a jurisprudência?”

Agora talvez seja necessário perguntar:

“Você verificou as referências produzidas pela IA?”

Se seu advogado utiliza Inteligência Artificial, isso não é automaticamente ruim.

Pelo contrário.

IA pode ser extraordinariamente útil.

O problema é uso sem verificação.

O cidadão deve desconfiar quando encontra:

  • decisões judiciais impossíveis de localizar;

  • números de processos estranhos;

  • citações sem fonte;

  • artigos de lei que parecem não dizer aquilo;

  • fatos que nunca foram fornecidos;

  • nomes incorretos;

  • argumentação genérica;

  • parágrafos repetitivos;

  • mudanças súbitas de estilo;

  • afirmações extremamente categóricas sem documentação.

Uma regra simples ajuda muito:

IA pode localizar a pista. A fonte oficial precisa confirmar a existência do elefante.


Falha ao fazer o upload do arquivo "". Invalid response: RpcError

☢️ 17. As consequências podem ser muito maiores que uma petição ruim

Uma falha envolvendo IA no Judiciário pode causar:

Para o cliente

perda de prazo, enfraquecimento da defesa, aumento de custos e até comprometimento de direitos fundamentais.

Para o advogado

multa, responsabilização processual, comunicação à OAB e, conforme as circunstâncias do caso, outras consequências jurídicas.

Para o tribunal

perda de confiança, decisões contaminadas, aumento de retrabalho e necessidade de auditorias.

Para a sociedade

algo ainda pior:

perda de confiança na própria Justiça.

Porque um cidadão consegue aceitar que um juiz discorde dele.

É muito mais difícil aceitar a ideia de que seu processo possa ter sido influenciado por uma máquina manipulada por texto escondido dentro de um PDF.



🔍 18. O novo perito do tribunal talvez seja o especialista em segurança de IA

Aqui surge uma profissão interessante.

Durante décadas, segurança da informação judicial significava principalmente:

firewall,

controle de acesso,

criptografia,

certificados,

backup,

senhas,

logs,

segregação de funções.

Agora aparece uma categoria nova:

segurança semântica.

Não basta saber:

“Quem enviou este documento?”

Precisamos perguntar:

“O que este documento está tentando fazer quando uma máquina o interpreta?”

Isso muda completamente o modelo de ameaça.

Um PDF deixa de ser apenas documento.

Pode transformar-se em input adversarial.



🕵️‍♂️ 19. Spy vs. Spy finalmente encontra o mainframe

Visualize nosso tribunal imaginário.

                 INTERNET
                     |
                 [ PJe ]
                     |
              DOCUMENTOS PDF
                     |
                     v
          +----------------------+
          | MOTOR DE SEGURANÇA   |
          +----------------------+
                     |
        +------------+------------+
        |                         |
   TEXTO NORMAL             CONTEÚDO SUSPEITO
        |                         |
        v                         v
       IA                     QUARENTENA
        |
        v
   RAG / PRECEDENTES
        |
        v
   RESUMO / MINUTA
        |
        v
  REVISÃO HUMANA
        |
        v
    MAGISTRADO

Spy Preto observa tudo.

Spy Branco instala detectores.

Spy Preto inventa outra técnica.

Spy Branco cria outro filtro.

E essa batalha continuará.

Segurança nunca foi um produto terminado.

É um processo.

Quem trabalha com mainframe já aprendeu isso décadas atrás.



🤔 20. A pergunta realmente incômoda

Agora chegamos à parte mais Bellacosa Mainframe da história.

Durante anos perguntamos:

A Inteligência Artificial conseguirá substituir advogados?

Talvez estivéssemos fazendo a pergunta errada.

A pergunta interessante pode ser:

O que acontece quando advogados começam a escrever documentos também para influenciar as Inteligências Artificiais utilizadas pelos tribunais?

Essa é uma mudança estrutural.

Nasce uma espécie de SEO judicial adversarial.

Durante anos sites foram escritos não apenas para pessoas, mas para algoritmos do Google.

Textos passaram a conter palavras-chave destinadas aos motores de busca.

Agora imagine a versão judicial dessa ideia.

Uma petição escrita simultaneamente para:

o magistrado

e

o algoritmo que ajuda o magistrado.

Existe uma fronteira legítima — estruturar documentos claros para facilitar sua análise automatizada.

E existe uma fronteira completamente diferente:

tentar manipular secretamente o comportamento da máquina.

É aí que o Spy Preto cruza a linha.



🚧 21. E a IA do tribunal também precisa ser vigiada

Não podemos cometer o erro de transformar a discussão em:

advogado mau versus computador perfeito.

Computadores não são perfeitos.

Modelos podem:

  • alucinar;

  • omitir informações;

  • reproduzir vieses;

  • interpretar contexto incorretamente;

  • atribuir importância errada aos fatos;

  • confiar excessivamente em padrões anteriores;

  • falhar diante de entradas adversariais.

Por isso a Resolução 615/2025 do CNJ enfatiza auditabilidade, segurança, contestabilidade, supervisão humana e proteção dos direitos fundamentais.

É precisamente porque a IA pode falhar que precisamos saber:

qual sistema foi usado?

qual informação recebeu?

qual resultado produziu?

quem revisou?

o que foi alterado?

qual fonte sustentou a resposta?

Em mainframe chamaríamos isso de uma velha conhecida:

audit trail.

Sem rastreabilidade, temos magia.

E sistemas de missão crítica não deveriam funcionar baseados em magia.



🧯 22. O grande firewall ainda é humano

No final de toda essa arquitetura aparece uma figura pouco futurista:

uma pessoa.

Pode ser servidor.

Assessor.

Juiz.

Desembargador.

Ministro.

Perito.

Advogado.

A Resolução CNJ nº 615/2025 exige supervisão humana efetiva e estabelece que sistemas generativos usados como apoio não devem substituir autonomamente a tomada de decisão judicial.

Isso não é tecnofobia.

É engenharia.

A máquina consegue ler milhões de palavras rapidamente.

O humano consegue perguntar:

“Isso faz sentido?”

Precisamos dos dois.



☕ 23. Conclusão — Bem-vindo ao Tribunal de Spy vs. Spy

O Spy Preto entra no fórum carregando uma petição.

O Spy Branco recebe o documento.

Um algoritmo começa a ler.

O documento tenta conversar com a máquina.

A máquina tenta distinguir informação de comando.

Outro sistema procura comportamento suspeito.

O servidor recebe um alerta.

O advogado adversário consulta jurisprudência.

Um chatbot inventa um acórdão.

Outro advogado copia.

O ministro confere.

O precedente não existe.

A OAB recebe comunicação.

Enquanto isso, departamentos de tecnologia constroem novos filtros.

Tudo isso seria uma excelente história para a revista MAD.

O problema é que boa parte dela já entrou no processo eletrônico brasileiro.

A Inteligência Artificial não destruiu o Direito.

Também não substituirá magicamente juízes e advogados amanhã de manhã.

Ela fez algo talvez mais interessante:

criou uma nova superfície sobre a qual velhas características humanas podem atuar.

Preguiça.

Ganância.

Esperteza.

Criatividade.

Negligência.

Boa-fé.

Má-fé.

Fiscalização.

E a eterna vontade de encontrar um atalho.

A tecnologia mudou.

Os personagens continuam surpreendentemente familiares.

Há milhares de anos alguém tentava enganar o escriba.

Séculos depois alguém tentava enganar o contador.

Depois tentamos enganar programas.

Motores de busca.

Antispam.

Algoritmos financeiros.

E agora chegamos ao inevitável:

alguém tentou enganar a Inteligência Artificial do tribunal.

O Spy Preto sorri.

O Spy Branco aperta outro botão.

Do teto cai uma bigorna.

BOOOOM.

E em algum datacenter brasileiro aparece uma mensagem:

SECURITY ALERT

ADVERSARIAL CONTENT DETECTED

DOCUMENT QUARANTINED

HUMAN REVIEW REQUIRED

O magistrado olha para a tela.

Toma um café.

E provavelmente pensa:

“Eu só queria ler a petição.”

Bem-vindo à Justiça na era da Inteligência Artificial.

Bem-vindo ao Spy vs. Spy jurídico.

E, principalmente:

nunca confunda automação com autoridade, texto convincente com verdade ou resposta probabilística com prova.

No mundo da IA, verificar deixou de ser preciosismo.

Virou requisito de segurança.



Motores de Buscas e SEO 

🔎 SEO — Descrição para mecanismos de busca

IA no Judiciário brasileiro: prompt injection, jurisprudência falsa, alucinações e golpes em petições explicados com Spy vs. Spy.

🔑 Palavras-chave semânticas

inteligência artificial no Judiciário, IA jurídica, prompt injection, fraude processual, petição com IA, advogado e inteligência artificial, jurisprudência falsa, alucinação de IA, STJ Logos, Galileu IA, CNJ Resolução 615, segurança da inteligência artificial, IA generativa no Direito, Justiça brasileira, inteligência artificial tribunais, segurança judicial, processo eletrônico, fraude com IA

🏷️ Marcadores sugeridos para Blogspot

Inteligência Artificial, Judiciário, IA Jurídica, Prompt Injection, Segurança, STJ, CNJ, Justiça, Direito Digital, Cybersecurity, Spy vs Spy, Bellacosa Mainframe

🔗 Fontes institucionais usadas

O episódio de prompt injection no STJ foi divulgado oficialmente pelo Superior Tribunal de Justiça em 20 de maio de 2026. O tribunal informou que estava mapeando as tentativas e descreveu as camadas de proteção adotadas pelo STJ Logos.

O caso envolvendo referências e trechos de julgados problemáticos em habeas corpus foi divulgado pelo STJ em 19 de maio de 2026.

A decisão que rejeitou relatório de IA generativa como prova criminal foi divulgada pelo STJ em abril de 2026.

Os episódios de prompt injection na Justiça do Trabalho e as sanções aplicadas foram descritos pelo TRT da 8ª Região e pelo Conselho Superior da Justiça do Trabalho.

A governança atual da Inteligência Artificial no Judiciário está disciplinada pela Resolução CNJ nº 615/2025, posteriormente alterada pela Resolução nº 674/2026.

O histórico brasileiro inclui o Projeto Victor, apresentado pelo STF em 2018, e a Plataforma Sinapses, institucionalizada nacionalmente pelo CNJ em 2020.




☕ Um Café no Bellacosa Mainframe // Tribunal Digital

Justiça, Inteligência Artificial e Algoritmos: Quando o Código Entra no Tribunal

Seis processos imaginários para discutir problemas muito reais: decisões automatizadas, IA jurídica, vieses, responsabilidade, concursos, algoritmos opacos, milhões de reais em disputa e a pergunta inevitável — quem responde quando o IF decide?

> PAUTA DO PLENÁRIO
PROCESSO=HUMANO_VS_ALGORITMO
MATÉRIA=IA_JURÍDICA
VALOR_DA_CAUSA=INDETERMINADO
TRANSPARÊNCIA=QUESTIONADA
EXPLICABILIDADE=REQUIRED
HUMAN_IN_THE_LOOP=RECOMMENDED
STATUS=EM_JULGAMENTO
PROCESSO 001

Dick Vigarista, IA e o Concurso Pay-to-Win

Uma reflexão sobre concursos, inteligência artificial, assimetria tecnológica, vantagem competitiva e os limites entre ferramenta legítima, desigualdade e manipulação.

IA Ética Concurso
Autos digitais Processo 001
PROCESSO 002

O Golpe de Mestre Algorítmico

Quando decisões aparentemente objetivas escondem modelos, regras, prioridades e escolhas humanas por trás de uma interface matemática que parece neutra.

Algoritmo Risco Governança
Autos digitais Processo 002
PROCESSO 003

John Belushi, IA Jurídica e o Dia em que o Tribunal Encontrou o Algoritmo

Inteligência artificial aplicada ao Direito, automação de decisões, responsabilidade profissional e os riscos de transformar recomendação algorítmica em verdade jurídica.

IA Jurídica Tribunal Decisão
Autos digitais Processo 003
PROCESSO 004

A Causa de R$ 300 Milhões e o IF do Algoritmo

O que acontece quando centenas de milhões de reais podem depender de uma condição lógica, de um dado incorreto ou de uma decisão transformada em código?

R$ 300 milhões IF Auditabilidade
Autos digitais Processo 004
PROCESSO 005

A Causa de R$ 300 Milhões e o Algoritmo

Algoritmos entram definitivamente no território jurídico: cálculo, inferência, responsabilidade, transparência e a necessidade de explicar como uma máquina chegou à conclusão.

Algoritmo R$ 300 milhões Explicabilidade
Autos digitais Processo 005
PROCESSO 006

Better Call COBOL

Quando o processo jurídico encontra sistemas legados, regras de negócio históricas, programas COBOL, rastreabilidade e a necessidade de reconstruir tecnicamente o que realmente aconteceu.

COBOL Forense Mainframe
Autos digitais Processo 006

⚖️ Quando o algoritmo entra nos autos

Durante décadas, tribunais trabalharam essencialmente com documentos, testemunhos, perícias, cálculos, precedentes e interpretação humana. Agora existe um novo personagem na sala de audiência: o algoritmo.

Ele pode classificar documentos, calcular valores, localizar precedentes, sugerir decisões, identificar padrões e resumir milhares de páginas. O problema começa quando uma ferramenta deixa de auxiliar a decisão e passa a influenciar silenciosamente o resultado.

“Excelência, o algoritmo chegou a essa conclusão.”

A pergunta seguinte deveria ser: como?
01 Dados entram
02 Modelo processa
03 Algoritmo recomenda
04 Humano interpreta
05 Tribunal decide
06 Quem responde?

🤖 Automação

Velocidade, escala, pesquisa massiva, consistência, processamento documental e capacidade de analisar volumes impossíveis para uma única pessoa.

👨‍⚖️ Julgamento humano

Contexto, proporcionalidade, contraditório, responsabilidade, interpretação da prova e capacidade de justificar a decisão perante as partes.

📚 Justiça, IA, algoritmos e sistemas críticos

Esta coleção reúne análises do Bellacosa Mainframe sobre inteligência artificial aplicada ao Direito, responsabilidade algorítmica, automação judicial, decisões automatizadas, sistemas legados, COBOL, auditoria e grandes disputas financeiras.

  1. Dick Vigarista, IA e o Concurso Pay-to-Win — inteligência artificial, concursos, assimetria tecnológica, ética e vantagem competitiva.
  2. O Golpe de Mestre Algorítmico — algoritmos, decisões automatizadas, governança e falsa neutralidade matemática.
  3. John Belushi, IA Jurídica e o Dia em que o Tribunal Encontrou o Algoritmo — inteligência artificial no Judiciário, responsabilidade e decisão humana.
  4. A Causa de R$ 300 Milhões e o IF do Algoritmo — regras de negócio, lógica computacional, auditoria e riscos financeiros.
  5. A Causa de R$ 300 Milhões e o Algoritmo — explicabilidade, decisões algorítmicas, responsabilidade e sistemas críticos.
  6. Better Call COBOL — COBOL, mainframe, prova técnica, rastreabilidade e investigação de sistemas legados.
☕ BELLACOSA MAINFRAME // TRIBUNAL DIGITAL
“CÓDIGO EXECUTA. ALGORITMOS RECOMENDAM. MAS RESPONSABILIDADE PRECISA TER NOME.”


segunda-feira, 17 de agosto de 2026

Red Team e os Doze Trabalhos de Asterix — Como Invadir Roma Sem Derrubar Produção

 


☕ Um Café no Bellacosa Mainframe

Red Team e os Doze Trabalhos de Asterix — Como Invadir Roma Sem Derrubar Produção

🛡️⚔️ Quando César contratou pentesters, os gauleses descobriram engenharia social e a burocracia romana revelou ser uma vulnerabilidade crítica

Existe uma diferença fundamental entre perguntar:

“Este sistema é seguro?”

e perguntar:

“Se eu fosse o inimigo, como eu quebraria este sistema?”

A primeira pergunta normalmente produz uma apresentação PowerPoint com 87 slides, três matrizes de risco, quatro dashboards verdes e alguém dizendo que todos os patches críticos foram aplicados.

A segunda produz um sujeito olhando para o ambiente e perguntando:

— Interessante. E se eu entrar pela recepção?

Bem-vindo ao Red Team.

E existe talvez um pano de fundo cultural perfeito para explicá-lo: Os Doze Trabalhos de Asterix.

Porque Asterix e Obelix não vencem Roma simplesmente sendo mais fortes.

Obelix certamente ajuda.

Mas eles vencem porque Roma construiu sistemas supondo que todo mundo jogaria conforme as regras de Roma.

E isso, jovem padawan do mainframe, é exatamente o tipo de suposição que um Red Team adora encontrar.



🏛️ 1. O que é Red Team?

Imagine uma organização dizendo:

Temos firewall.
Temos RACF.
Temos MFA.
Temos SIEM.
Temos EDR.
Temos SOC.
Temos IDS.
Temos treinamento.
Temos política.
Temos auditoria.

Excelente.

O Red Team responde:

Posso tentar entrar?

Silêncio.

Essa é a essência.

Um Red Team é uma equipe autorizada a assumir a perspectiva de um adversário e tentar atingir determinados objetivos usando técnicas realistas de ataque.

Não significa necessariamente:

“Hackear tudo.”

O objetivo pode ser muito mais específico:

OBJETIVO

Conseguir acesso não autorizado
        ↓
obter credenciais
        ↓
movimentar-se pelo ambiente
        ↓
atingir determinado ativo
        ↓
sem ser detectado pelo Blue Team

Portanto, Red Team não testa apenas tecnologia.

Testa:

tecnologia + pessoas + processos + detecção + resposta.

E aqui começa nossa viagem para Roma.


🏺 2. De onde vem o termo Red Team?

A ideia é muito anterior à segurança cibernética.

Organizações militares perceberam um problema perigosíssimo:

quem cria uma estratégia tende a acreditar nela.

Você constrói sua fortaleza.

Depois olha para ela.

E pensa:

“Magnífica.”

O inimigo olha para a mesma fortaleza e pensa:

“Por que aquele portão está aberto?”

Surgiram então exercícios nos quais uma equipe representava o adversário.

Simplificando:

BLUE TEAM
defende

     ⚔️

RED TEAM
ataca

O vermelho tradicionalmente representava a força adversária em exercícios e jogos de guerra.

A lógica migrou posteriormente para inteligência, segurança física, planejamento estratégico e finalmente cybersecurity.

Mas o princípio permaneceu:

Você não está tentando provar que seu sistema funciona. Está tentando descobrir como ele pode falhar.


🐗 3. Asterix provavelmente seria um excelente Red Teamer

Obelix resolveria praticamente qualquer problema assim:

PORTA FECHADA

     ↓

OBELIX

     ↓

PORTA NÃO EXISTE MAIS

Isso é tecnicamente uma forma de penetration testing.

Talvez excessivamente destrutiva.

Asterix, porém, possui características muito mais interessantes.

Ele observa.

Questiona.

Improvisa.

Explora regras.

Procura inconsistências.

Engana adversários.

Percebe comportamentos previsvisíveis.

E, principalmente:

ele raramente enfrenta o sistema exatamente da maneira que o sistema espera.

Essa é uma característica fundamental do pensamento adversarial.


🏛️ 4. César comete o primeiro erro de segurança

Roma olha para os gauleses e pensa:

“Se somos mais fortes, precisamos apenas criar provas suficientemente difíceis.”

Erro clássico.

César está pensando como system owner.

Ele conhece as regras.

Conhece os controles.

Conhece os processos.

Conhece as expectativas.

Asterix está pensando como adversário.

Ele pergunta implicitamente:

“Onde está escrito que preciso resolver o problema da maneira imaginada pelo projetista?”

E nasce uma das maiores regras do Red Team:

O atacante não é obrigado a respeitar sua arquitetura.

Seu diagrama pode dizer:

Internet
   ↓
WAF
   ↓
Firewall
   ↓
API Gateway
   ↓
Application
   ↓
Database

Lindo.

O atacante talvez faça:

Funcionário
   ↓
LinkedIn
   ↓
Phishing
   ↓
Credential
   ↓
VPN
   ↓
Internal Network

Seu WAF continua impecável.

E completamente irrelevante.



⚔️ 5. Trabalho I — Reconnaissance

Antes de atacar Roma, precisamos conhecer Roma.

No Red Team isso se chama reconhecimento.

O atacante procura informações sobre a organização:

domínios
subdomínios
IPs
tecnologias
funcionários
fornecedores
emails
documentação pública
GitHub
vagas de emprego
certificados
APIs
metadados
cloud assets

Uma inocente vaga dizendo:

“Procuramos especialista em z/OS, RACF, CICS, Db2, MQ e CyberArk.”

já revelou uma parte considerável da arquitetura.

Asterix provavelmente chamaria isso de:

perguntar discretamente aos romanos onde fica o acampamento.



🧠 6. Trabalho II — Engenharia Social

Agora entramos no território onde muitos impérios desmoronam.

Porque existe um componente tecnológico extremamente vulnerável chamado:

HUMANO 1.0

Características conhecidas:

confia em autoridade
tem pressa
tem curiosidade
quer ajudar
tem medo
comete erros
reutiliza senhas
clica em coisas

Engenharia social explora comportamento humano.

Exemplo:

“Olá, sou da equipe de suporte. Estamos atualizando seu acesso. Pode confirmar seu usuário?”

Ou:

“O diretor pediu urgentemente este relatório.”

Ou:

“Sua senha expira hoje.”

Não houve exploit.

Não houve buffer overflow.

Não houve zero-day.

O usuário entregou a chave.



🎣 7. Trabalho III — Phishing

Uma das técnicas clássicas.

O Red Team pode, quando autorizado pelo escopo, simular mensagens convincentes para medir:

  • quem abre;

  • quem clica;

  • quem fornece informação;

  • quem reporta;

  • quanto tempo o SOC demora para perceber.

Mas existe uma diferença enorme entre treinamento básico e operação Red Team.

O objetivo não deveria ser simplesmente anunciar:

“HAHA! 37 funcionários clicaram!”

Isso ensina pouco.

A pergunta interessante é:

O primeiro funcionário clicou
       ↓
o SOC percebeu?
       ↓
o email foi bloqueado?
       ↓
os outros usuários foram avisados?
       ↓
a credencial foi invalidada?
       ↓
a sessão foi encerrada?

Agora estamos testando a organização.



🔑 8. Trabalho IV — Credential Attack

Credenciais são o equivalente moderno das senhas secretas das legiões.

O Red Team procura descobrir se uma identidade comprometida pode proporcionar acesso indevido.

Pode avaliar problemas como:

  • senhas fracas;

  • reutilização;

  • credenciais expostas;

  • secrets mal armazenados;

  • tokens excessivamente poderosos;

  • contas antigas;

  • contas de serviço;

  • privilégios inadequados.

Em ambientes corporativos antigos existe ainda o famoso:

USER123
criado: 2004
responsável: ninguém sabe
última aplicação conhecida: aposentada em 2017
privilégio: inexplicavelmente enorme

O verdadeiro fóssil digital.



🪜 9. Trabalho V — Privilege Escalation

Entrar é apenas parte do problema.

Imagine que Asterix conseguiu entrar no acampamento romano vestido de legionário.

Ótimo.

Mas ele ainda é:

LEGIONÁRIO CLASSE C

Ele precisa chegar ao palácio de César.

No mundo digital isso pode significar:

user
 ↓
power user
 ↓
administrator
 ↓
domain admin

ou, no nosso universo:

TSO USER
   ↓
acesso adicional
   ↓
grupo privilegiado
   ↓
resource access
   ↓
OH MEUS DEUSES, QUEM AUTORIZOU ISSO?

O Red Team procura caminhos de escalada de privilégio.



🏃 10. Trabalho VI — Lateral Movement

Conseguir acesso a uma máquina não significa ter conquistado Roma.

Agora precisamos andar.

WORKSTATION
     ↓
SERVER
     ↓
APPLICATION
     ↓
MIDDLEWARE
     ↓
DATABASE
     ↓
CRITICAL SYSTEM

Isso é movimento lateral.

O Red Team tenta descobrir se a segmentação realmente impede que uma invasão local se transforme em comprometimento sistêmico.

É aqui que muitas arquiteturas descobrem uma verdade desconfortável:

O firewall externo era magnífico. O problema começou depois dele.


👻 11. Trabalho VII — Persistence

O atacante conseguiu entrar.

A pergunta agora é:

consegue permanecer?

Persistence significa estabelecer mecanismos que permitam recuperar acesso depois.

Em uma simulação autorizada, isso é cuidadosamente limitado e controlado.

O objetivo é verificar se os defensores conseguem detectar comportamentos que indicariam tentativa de permanência.

O equivalente gaulês seria Asterix descobrir que pode simplesmente guardar uma armadura romana atrás de uma árvore.



🥷 12. Trabalho VIII — Evasion

Agora surge uma diferença importante entre penetration test e Red Team.

Um pentest frequentemente pergunta:

“Consigo explorar essa vulnerabilidade?”

Red Team pode perguntar:

“Consigo atingir o objetivo sem o Blue Team perceber?”

Portanto:

RED TEAM
     ↓
faz alguma coisa

SIEM
     ↓
???

SOC
     ↓
???

BLUE TEAM
     ↓
???

Se ninguém percebeu, encontramos outro problema.

Talvez a vulnerabilidade técnica fosse conhecida.

Mas a vulnerabilidade operacional não.



🚨 13. Trabalho IX — Testar detecção

Imagine Obelix atravessando o acampamento romano.

CRASH.

BOOM.

POW.

Uma torre cai.

Um legionário pergunta:

“Você ouviu alguma coisa?”

Esse é o pesadelo de qualquer SOC.

Uma empresa pode possuir milhões em ferramentas de segurança e ainda sofrer de:

baixa capacidade de detecção.

Red Team permite testar perguntas muito melhores que:

“Temos SIEM?”

Pergunte:

“Nosso SIEM perceberia?”

Depois:

“Alguém responderia ao alerta?”

Depois:

“Em quanto tempo?”

Isso muda completamente a conversa.



🏰 14. Trabalho X — Security Controls

Aqui começamos a atacar as certezas.

A organização diz:

MFA impede isso.

Red Team:

Vamos verificar.

Organização:

Nossa segmentação impede aquilo.

Red Team:

Vamos verificar.

Organização:

RACF impede acesso ao recurso.

Red Team:

Excelente. Vamos verificar.

Observe a filosofia.

Red Team não deveria partir da afirmação:

“Seu controle não funciona.”

Ele parte da pergunta:

“Seu controle continua funcionando diante de um adversário?”

Essa diferença é importantíssima.



📜 15. Trabalho XI — O Formulário A38

E chegamos ao momento sublime.

A burocracia.

Em Os Doze Trabalhos de Asterix, uma das provas mais memoráveis não envolve monstros ou força física.

Envolve administração.

Uma repartição.

Formulários.

Autorizações.

Guichês.

Contradições.

Um sistema tão absurdamente burocrático que sua verdadeira defesa consiste em fazer o cidadão desistir.

Curiosamente, isso possui um paralelo espetacular com cybersecurity.

Imagine:

Solicitação
   ↓
IAM
   ↓
ServiceNow
   ↓
Gestor
   ↓
Security
   ↓
Owner
   ↓
RACF Admin
   ↓
Auditoria

Todo mundo acredita que isso garante segurança.

Mas o Red Team pergunta:

“As pessoas realmente seguem esse fluxo?”

Talvez descubra:

PROCESSO OFICIAL
12 etapas

PROCESSO REAL
"manda mensagem pro Carlos"

BINGO.

Você encontrou uma vulnerabilidade organizacional.


🤯 16. A grande lição do A38

Sistemas excessivamente complexos criam atalhos humanos.

Quanto mais difícil o procedimento:

COMPLEXIDADE ↑

ATALHOS ↑

SHADOW IT ↑

ERROS ↑

BYPASS ↑

Isso vale para segurança.

Se trocar senha exigir quinze passos, usuários inventarão métodos.

Se acessar produção exigir uma peregrinação administrativa, alguém criará uma conta compartilhada.

Se transferir arquivo oficialmente levar três dias:

nascerá misteriosamente:

planilha_final_agora_vai_v7.zip

em algum canal que jamais deveria transportar aquilo.

O Red Team não procura apenas bugs.

Procura adaptações humanas ao sistema.



🧪 17. Trabalho XII — O objetivo final

Uma operação Red Team madura começa com objetivos.

Por exemplo:

OBJETIVO:

Demonstrar se um adversário
consegue alcançar determinado
ativo crítico.

Não:

QUEBRE TUDO.

Pode ser:

conseguir acessar dados simulados de determinado ambiente.

Ou:

demonstrar possibilidade de comprometimento de determinada identidade.

Ou:

testar se uma cadeia de ataque seria detectada.

Depois vem a pergunta crucial:

Red Team conseguiu?
       ↓
Blue Team detectou?
       ↓
Quando?
       ↓
Como?
       ↓
Qual controle funcionou?
       ↓
Qual falhou?

Essa última pergunta é preciosa.

Porque Red Team não serve apenas para encontrar coisas quebradas.

Também descobre:

quais defesas realmente funcionam.


🔵 Blue Team entra na aldeia

Se existe Red Team, naturalmente existe:

Blue Team.

O Blue Team defende.

Cuida de:

  • monitoramento;

  • detecção;

  • incident response;

  • hardening;

  • logs;

  • SIEM;

  • EDR;

  • IAM;

  • threat hunting;

  • análise de comportamento;

  • resposta operacional.

Então temos:

RED
⚔️
ataca

BLUE
🛡️
defende

Mas existe um terceiro personagem.


🟣 Purple Team

Purple Team não significa necessariamente uma terceira equipe permanente.

É principalmente a cooperação estruturada entre ataque e defesa.

Red descobre:

“Conseguimos executar X sem sermos detectados.”

Blue responde:

“Mostre exatamente o comportamento.”

Criam uma detecção.

Repetem.

Agora:

ATAQUE
   ↓
ALERTA
   ↓
SOC
   ↓
RESPOSTA

Funcionou.

Isso é muito mais valioso do que Red Team voltar para casa dizendo:

“Ganhei.”

Segurança não é campeonato de Capture the Flag contra seus próprios colegas.


⚡ As FORÇAS do Red Team

O grande poder está no realismo.

1. Testa o sistema inteiro

Pentest pode encontrar vulnerabilidade.

Red Team encontra caminhos de ataque.

2. Descobre combinações improváveis

Talvez nenhuma falha seja crítica individualmente.

Mas:

informação pública
+
senha reutilizada
+
permissão antiga
+
segmentação ruim
+
monitoramento deficiente
=
ROMA EM CHAMAS

3. Testa pessoas

Tecnologia não existe isoladamente.

4. Testa processos

O procedimento oficial pode ser perfeito.

O procedimento real pode envolver Carlos.

Sempre existe um Carlos.

5. Testa defesa

Você finalmente descobre se SOC, SIEM e incident response funcionam juntos.

6. Produz aprendizado realista

Uma coisa é dizer:

“Existe risco de credential compromise.”

Outra é demonstrar:

09:17 acesso obtido
09:31 movimento lateral
10:04 recurso crítico alcançado
14:27 primeiro alerta investigado

Agora o risco ganhou relógio.


☠️ As FRAQUEZAS

Red Team também possui problemas.

1. Pode custar caro

Profissionais especializados, preparação, infraestrutura, coordenação e análise consomem recursos.

2. Pode causar impacto

Uma operação mal planejada pode afetar produção.

Por isso existem:

SCOPE
RULES OF ENGAGEMENT
STOP CONDITIONS
AUTHORIZED TARGETS
CONTACTS
ESCALATION PROCEDURES

Obelix definitivamente precisa ler as Rules of Engagement.

3. Pode virar teatro

Existe Red Team ruim.

A empresa escolhe exatamente o que pode ser atacado, avisa todo mundo, proíbe praticamente todas as técnicas e depois comemora:

“Nenhum invasor conseguiu entrar.”

Naturalmente.

César retirou todos os romanos antes da invasão.

4. Pode virar competição de ego

Red:

“Vocês não nos detectaram!”

Blue:

“Vocês trapacearam!”

Security Manager:

“Senhores…”

César:

“EU SÓ QUERIA SABER SE ROMA ERA SEGURA.”



🧠 O atributo secreto: pensamento adversarial

Ferramentas podem ser aprendidas.

Mas existe um atributo muito mais interessante:

Adversarial Thinking

É olhar para algo funcionando e perguntar:

“Quais pressupostos precisam continuar verdadeiros para isso funcionar?”

Depois:

“E se um deles deixar de ser verdadeiro?”

Exemplo.

Aplicação:

IF USER-AUTHENTICATED
   PERFORM TRANSACTION
END-IF

Desenvolvedor pensa:

usuário autenticado pode executar.

Red Teamer pergunta:

autenticado significa autorizado?

Essa pergunta aparentemente pequena já derrubou muitos impérios digitais.


🧙 Easter Egg COBOL

Imagine um programa antigo:

IF USER-TYPE = 'A'
    PERFORM ADMIN-FUNCTION.

Todo mundo procura vulnerabilidade em ADMIN-FUNCTION.

O Red Teamer pergunta:

Quem controla USER-TYPE?

Silêncio.

Alguém abre um copybook criado em 1989.

01 USER-RECORD.
   05 USER-ID       PIC X(08).
   05 USER-TYPE     PIC X.

Depois encontram um arquivo VSAM.

Depois encontram um job batch.

Depois encontram:

//SYSIN DD *
UPDATE USER TYPE=A
/*

E alguém pergunta:

“Quem pode executar esse job?”

O veterano COBOL olha pela janela.

Toma café.

E responde:

“Essa é uma excelente pergunta.”

🎺 Música de encerramento.


🐗 Easter Egg Obelix

Existe ainda uma técnica avançadíssima conhecida informalmente no Bellacosa Mainframe Security Framework como:

OBELIX ATTACK

Algoritmo:

IF DOOR = LOCKED
    REMOVE DOOR
END-IF

Complexidade computacional:

O(Obelix)

Taxa de sucesso:

alarmantemente elevada.

Recomendação:

não implementar em produção.


🏛️ A verdadeira moral dos Doze Trabalhos

César acredita que está testando a força dos gauleses.

Mas os gauleses acabam testando algo muito maior:

as premissas de Roma.

E isso é exatamente o que um bom Red Team faz.

Ele não pergunta apenas:

Existe firewall?

Pergunta:

O firewall realmente impede o ataque?

Não pergunta:

Existe MFA?

Pergunta:

O adversário consegue atingir o objetivo apesar dele?

Não pergunta:

Existe SOC?

Pergunta:

O SOC percebe?

Não pergunta:

Existe procedimento?

Pergunta:

As pessoas realmente seguem o procedimento?

☕ E finalmente chegamos ao Café no Bellacosa Mainframe

Talvez a maior lição de Red Team seja desconfortavelmente simples:

segurança não é aquilo que deveria acontecer. Segurança é aquilo que acontece quando alguém deliberadamente tenta fazer acontecer outra coisa.

Roma possuía:

legiões.

Estradas.

Administração.

Hierarquia.

Procedimentos.

Fortificações.

Comunicação.

Logística.

Normas.

E provavelmente algum precursor latino do RACF:

ICH408I

ASTERIX
NOT AUTHORIZED TO ACCESS
ROMA.CAESAR.PALACE

Mesmo assim, aqueles gauleses continuavam aparecendo.

Porque César tinha cometido o erro clássico de muitos arquitetos:

ele projetou as provas pensando em como deveriam ser resolvidas.

Asterix pensava em como poderiam ser contornadas.

E entre essas duas formas de pensar existe todo o universo do Red Team.


🐗 Regra Bellacosa nº 12

BLUE TEAM pergunta:

"Como protegemos o castelo?"


RED TEAM pergunta:

"Por que eu precisaria entrar pelo portão?"


PURPLE TEAM pergunta:

"Ótimo. Como detectamos alguém pensando nisso?"

E Obelix?

Obelix já está dentro.

Ninguém sabe como.

O SIEM não registrou nada.

Dois legionários estão pendurados numa árvore.

E o relatório preliminar do incidente contém apenas uma observação:

“Eles são loucos, esses romanos.” ☕⚔️🛡️

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2026/08/dick-vigarista-ia-e-o-concurso-pay-to.html

https://eljefemidnightlunch.blogspot.com/2026/08/a-causa-de-r-300-milhoes-e-o-algoritmo.html

 https://eljefemidnightlunch.blogspot.com/2026/02/hackers-no-cinema-quando-hollywood.html




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