DEV Community: Rodrigo Freire

Bloquear o invasor na hora foi o pior conselho que eu segui

Rodrigo Freire — Mon, 29 Jun 2026 13:55:49 +0000

Por Rodrigo Freire — Pesquisa e Desenvolvimento em Deep Tech

Se você trabalha com infraestrutura, provavelmente aprendeu a mesma regra que eu: detectou processo malicioso, derruba na hora. Mata a conexão, encerra o processo, devolve um Access Denied sonoro. Eu segui essa regra por muito tempo achando que era o certo. Era rápido, era limpo, parecia profissional.

Demorei a perceber o óbvio: o bloqueio imediato é o melhor feedback que você pode dar ao atacante.

Quando o adversário é um script genérico ou uma varredura automática, tudo bem — a guilhotina funciona e custa pouco. O problema é o cenário que virou regra: ataques orquestrados por IA e ameaças persistentes. Se você bloqueia uma IA de ataque no instante em que ela pisa em falso, você acabou de ensinar ela. O bloqueio é o sinal de que existe uma barreira ali e que ela precisa ofuscar o próximo movimento. Você entra num jogo onde a defesa tem que acertar sempre e o atacante só precisa acertar uma vez. Esse jogo você perde no longo prazo.

Foi apanhando dessa lógica que eu fui estudar uma abordagem diferente — não inventada por mim, mas emprestada da biologia: em vez de cortar, sufocar.

O custo escondido de dizer "não" rápido demais

O que ninguém te conta quando você aprende a bloquear na hora é tudo que você joga fora junto.

Quando você mata o processo instantaneamente, você perde a chance de ver a ameaça "ligar para casa". Perde o rastro do servidor de comando e controle. Perde a árvore genealógica de processos que te levaria até a origem real do ataque — o paciente zero. Você ganha a satisfação imediata de ter bloqueado, e paga com a cegueira sobre quem realmente entrou e por onde.

A inversão de raciocínio é essa: e se, em vez de alertar o invasor, você deixasse ele continuar achando que venceu — só que dentro de uma simulação?

Sufocar em vez de cortar

A ideia tem dois ganhos táticos que o bloqueio nunca te dá.

O primeiro é envenenar o aprendizado do atacante. Se ele acessa arquivos de configuração e bancos de dados que parecem reais mas são forjados, o pipeline de uma IA atacante converge para uma solução errada. Ela gasta tempo e orçamento processando lixo que parece ouro. Você não barrou o ataque — você fez ele trabalhar contra si mesmo.

O segundo é tempo. Manter o invasor ocupado numa simulação compra os milissegundos preciosos para rastrear toda a linhagem do ataque antes de arrancar a rede pela raiz. Você troca a satisfação imediata do bloqueio pela informação completa sobre a ameaça.

Para que essa simulação seja convincente, ela precisa operar abaixo do nível do usuário, lá onde o sistema operacional não mente. Três camadas tornam isso possível:

A ilusão do sistema de arquivos. Em vez de negar a leitura de credenciais, você injeta espelhos falsos no namespace restrito do invasor. Ele lê o que acha serem segredos — e são armadilhas perfeitas, enquanto a produção real segue intocada.

O silêncio de rede. Cortar a conexão TCP avisa o atacante na hora. Aplicar descarte silencioso de pacotes atrelado ao grupo de processos dele faz a requisição pendurar num timeout infinito. Para ele, a internet só parece instável.

A asfixia de recursos. Aqui está o golpe econômico. Em vez de matar um ataque que roda só em memória, você corta o tempo de processamento que o escalonador do sistema dá àquele grupo. O resultado é uma assimetria perfeita: as máquinas do atacante continuam queimando energia máxima para manter as requisições vivas, enquanto o seu servidor simplesmente esfria. Você reduz a sua conta enquanto derrete o bolso do invasor.

Onde essa abordagem tem limite (porque tem)

Não vou vender isso como bala de prata. Decepção ativa é cara de construir e de manter — exige forjar ambientes falsos convincentes, e um atacante muito experiente pode farejar a simulação. Para a esmagadora maioria das ameaças comuns, o bom e velho bloqueio continua sendo a resposta certa, porque é barato e suficiente. A asfixia faz sentido para a fração de ameaças avançadas onde a informação sobre o atacante vale mais que a velocidade de barrá-lo. Aplicar isso em tudo seria over-engineering puro.

O que eu tirei disso

A lição que ficou comigo vai além de segurança. Na cibersegurança moderna, a guerra é de atrito: vence quem inviabiliza o lado econômico do oponente primeiro. E o reflexo de "dizer não o mais rápido possível" — que parece força — muitas vezes é o que entrega informação de graça ao outro lado.

Parei de pensar em construir muros mais altos e passei a pensar em projetar areia movediça. Não se trata de sobreviver ao ataque. Se trata de fazer o atacante se arrepender amargamente do custo de ter tentado.

Se você gerencia infraestrutura e ainda trata todo incidente como "detectou, bloqueou", vale a pergunta: quanta informação sobre quem está te atacando você está jogando fora junto com o processo que você matou?

Publicado originalmente em: https://rodrigofreire.pages.dev/posts/01-assimetria-reversa/

Seu antivírus confia no steamcommunity.com. Esse foi o ponto cego que 1.980 sites pagaram

Rodrigo Freire — Mon, 29 Jun 2026 13:51:49 +0000

Por Rodrigo Freire — Pesquisa e Desenvolvimento em Deep Tech

Quando li sobre a campanha de malware Steam→WordPress pela primeira vez, minha reação não foi "que técnica avançada". Foi um desconforto mais incômodo: quantas das defesas que eu mesmo confiava teriam deixado isso passar batido?

A resposta foi humilhante. Quase todas.

Em julho de 2025, pesquisadores começaram a rastrear uma campanha que infectou cerca de 1.980 sites WordPress. O que fez ela circular pela imprensa de segurança não foi o volume — foi o canal de comando e controle: comentários de perfil da Steam, com instruções escondidas dentro de caracteres Unicode invisíveis. Vale destrinchar isso, porque a lição vale para qualquer um que ache que "tem antivírus, está protegido".

A genialidade está em não brilhar

Cada etapa dessa campanha foi desenhada para parecer rotina absoluta.

O ponto de entrada é mundano. Não há exploit exótico. Credenciais de admin roubadas, acesso FTP comprometido, um plugin vulnerável. Nada que chame atenção — e é justamente por isso que funciona em escala.

A persistência é discreta. Plantado o pé inicial, instala-se um backdoor PHP que se mantém por cookie e aceita comandos via POST. Mesmo uma limpeza superficial deixa o caminho de volta aberto.

O comando vem de onde ninguém olha. Aqui está a sacada. Em vez de telefonar para um servidor do atacante — que seria pego por reputação de domínio — o site comprometido busca uma página pública de perfil da Steam. O comentário parece arte ASCII inofensiva. Escondidos entre os caracteres visíveis estão seis caracteres Unicode invisíveis, mapeados para bits. Decodificados, reconstroem uma URL.

A entrega se disfarça de biblioteca. A URL aponta para um JavaScript externo com nome de biblioteca legítima, tipo lodash.core.min.js, injetado em todas as páginas do site, atingindo cada visitante.

Por que minhas defesas favoritas falhariam

Foi aqui que o desconforto virou aprendizado. Olha por que cada camada tradicional perde:

Reputação de domínio não serve para nada aqui. O servidor comprometido conversa com steamcommunity.com, um dos domínios mais confiáveis da internet. Nenhuma blocklist vai sinalizar isso. O atacante terceirizou o canal de comando para uma plataforma que ninguém ousa bloquear. Toda a minha confiança em listas de reputação evaporou nesse parágrafo.

Assinatura de arquivo é frágil por design. O payload está cifrado e ofuscado em camadas, com identificadores aleatórios e código-isca. A regra que casa com a string de hoje não casa com a variante de amanhã. Antivírus por assinatura está sempre um passo atrás.

O canal não é tráfego anômalo — é esteganografia. Os caracteres invisíveis não disparam filtro de spam nem moderação. Gente posta arte ASCII com Unicode o tempo todo. O payload viaja escondido dentro do que parece conteúdo normal.

A conclusão que me incomodou: toda defesa que pergunta "esse indicador é conhecidamente ruim?" perde aqui. Porque o indicador foi projetado, do início ao fim, para parecer bom.

O que sobra quando o "ruim conhecido" não funciona

Se você não pode confiar em domínio, nem em assinatura, nem em filtro de conteúdo, o que sobra?

Sobra o comportamento. A pergunta muda de "esse arquivo é malicioso?" para "esse processo está fazendo algo que um site WordPress saudável jamais faria?". Um servidor web que de repente decodifica caracteres Unicode invisíveis de um perfil da Steam e injeta JavaScript externo em todas as páginas não tem assinatura ruim conhecida — mas tem um comportamento absurdo para o que ele deveria ser.

É uma mudança de eixo inteira: parar de catalogar o que é ruim e começar a entender o que é normal, para que o anormal salte aos olhos sozinho. Detecção por comportamento não precisa ter visto o ataque antes. Ela precisa saber como a vida normal se parece.

Onde isso também tem limite

Para ser honesto: detecção comportamental não é mágica. Ela gera falsos positivos quando o "normal" é mal definido, exige aprender a linha de base de cada ambiente, e um atacante paciente pode se mover devagar o suficiente para parecer normal. Não substitui as outras camadas — soma a elas. Quem vende qualquer abordagem de segurança como solução única está vendendo, não ensinando.

O que eu levei para casa

Essa campanha me curou de uma preguiça intelectual: a de achar que segurança é manter listas atualizadas do que é ruim. As listas têm valor, mas elas só pegam o que já é conhecido. O ataque que importa é o que foi desenhado especificamente para parecer bom — e contra esse, a única pergunta que ainda funciona é sobre comportamento, não sobre identidade.

Se você cuida de um WordPress, de um servidor, de qualquer coisa exposta: vale o exercício honesto que eu fiz. Pega as suas defesas atuais, uma por uma, e pergunta se elas pegariam um ataque que conversa com um domínio confiável, muda de assinatura todo dia, e se esconde dentro de conteúdo que parece normal. Se a resposta te deixar desconfortável, ótimo. Foi assim que eu comecei a estudar isso a sério.

Publicado originalmente em: https://rodrigofreire.pages.dev/posts/02-anatomia-c2/

Como você mede o gasto de IA (em dólares) por mês? O número que importa está escondido no kernel

Rodrigo Freire — Mon, 29 Jun 2026 13:47:24 +0000

Por Rodrigo Freire — Pesquisa e Desenvolvimento em Deep Tech

Faz um teste mental rápido. Se alguém perguntar quanto a sua empresa gasta de nuvem com IA por mês, você acha o número numa planilha. Agora a pergunta que quase ninguém consegue responder: quanto custa, em watts e em centavos, cada token que o seu modelo gera?

Eu fui atrás dessa segunda pergunta achando que seria simples. Não era. E o caminho me ensinou mais sobre observabilidade do que qualquer tutorial — inclusive me fez errar feio antes de acertar.

A conta que parece trivial e não é

O problema cabe numa linha:

custo_por_token = (W_cpu + W_dram + W_gpu) × tempo / tokens_gerados

O detalhe cruel é que cada termo dessa conta vive numa camada diferente do sistema, exposto por uma interface diferente, com granularidade diferente. E nenhuma ferramenta de prateleira junta tudo num número só, atribuído ao processo certo, no instante certo.

E isso importa cada vez mais por um motivo concreto: o gargalo real da expansão de datacenters de IA hoje não é dinheiro para comprar GPU. É megawatt disponível na rede. Quando a restrição vira energia, saber onde cada watt está indo deixa de ser curiosidade e vira sobrevivência do negócio. Mas você não otimiza o que não enxerga.

Por que as ferramentas que você já usa não chegam lá

Quando comecei, achei que Prometheus ou algum exporter resolveria. Aqui está por que não resolve:

A energia da CPU mora num canto. Consumo de CPU e DRAM é exposto pela interface RAPL, lida via sistema de arquivos. Útil, mas cobre só uma fatia.

A energia da GPU mora em outro canto totalmente separado. Numa inferência de LLM, 80% a 90% dos watts estão na GPU — e a GPU não fala RAPL. Ela fala NVML, uma biblioteca à parte, com API própria. Quem mede só RAPL mede a ponta do iceberg e ignora o bloco inteiro embaixo d'água.

Os tokens moram dentro do engine. vLLM, llama.cpp, Ollama — cada um expõe o número de um jeito.

E a correlação não mora em lugar nenhum. Esse é o nó. As ferramentas tradicionais medem energia agregada do host: "este servidor gastou tantos watts". Nenhuma responde "o processo de PID 214, rodando o modelo X, gastou tantos watts de CPU mais tantos de GPU enquanto gerava estes tokens nesta janela de 200 milissegundos". A atribuição que liga energia a processo a output simplesmente não existe pronta.

A virada de chave foi essa: toda ferramenta que pergunta "quanto este host gastou?" está errando a pergunta. A certa é "quanto este token custou?" — e respondê-la exige descer até onde o kernel decide quem roda quando.

O erro de 80% que me ensinou a lição

Aqui vai a parte que dói confessar, mas que é o coração do aprendizado.

Para contar tokens, minha primeira versão lia o log de saída do engine e tinha uma lógica de deduplicação para não contar o mesmo evento duas vezes. A chave de identidade dessa dedup era o valor numérico: se "gerou 50 tokens" aparecesse duas vezes em menos de meio segundo, a segunda era descartada como repetição.

Funcionou nos meus testes simples. Aí veio a carga concorrente real. Quando vinte requisições idênticas geram 50 tokens cada, quase no mesmo milissegundo, a dedup confundiu requisições legítimas e diferentes com repetições do mesmo evento. Descartou dezoito delas. O número que deveria ser mil tokens virou duzentos. Subcontagem de 80%.

A causa raiz não era a dedup. Era a minha teimosia de reconstruir, a partir de texto de log não-estruturado, um número que o engine já entregava pronto e estruturado no endpoint de métricas dele. A correção não foi melhorar o parser — foi jogá-lo fora como fonte primária e ler o contador canônico que a inferência já reporta.

A lição vale muito além desse caso: quando você se pega fazendo engenharia reversa de um dado que a fonte já entrega estruturado, você está otimizando o caminho errado. E o barato foi descobrir isso num teste de mesa de cinco dólares, não num cluster de produção depois de prometer precisão a alguém.

A arquitetura que finalmente fecha a conta

A peça que ninguém tem é a ponte temporal entre processo e energia. Ela se constrói com eBPF.

Um programa eBPF no tracepoint de escalonamento do kernel enxerga, com precisão de microssegundo, exatamente quando um worker de inferência entra e sai da CPU. Esse é o relógio que faltava. Com ele dá para correlacionar a janela de execução de um PID com a leitura de energia daquele intervalo — somando RAPL (CPU e DRAM) à leitura de NVML (GPU) do mesmo processo, e dividindo pelos tokens que aquele processo gerou na janela, lidos da fonte estruturada.

São três fontes que vivem em camadas diferentes, costuradas por uma correlação temporal que só existe quando você desce até o escalonador.

Onde isso tem limite

Sendo honesto: num host que serve vários modelos ao mesmo tempo, dividir a energia com exatidão entre eles é difícil — a aproximação por tempo de CPU funciona para um workload e vira estimativa para vários. RAPL é coisa de Intel; AMD e ARM têm mecanismos próprios e desiguais. E medir não é otimizar — saber o custo é o primeiro passo, não o último. Quem promete precisão absoluta em qualquer cenário está vendendo, não medindo.

O que eu levei disso

A indústria aprendeu a medir gasto de nuvem em dólares por mês. O próximo nível de maturidade é medir eficiência por unidade de trabalho útil: watts por token, joules por requisição, centavos por mil tokens, atribuídos ao processo e ao modelo certos.

Esse número não sai de planilha nem de dashboard de host. Ele sai de costurar três fontes que vivem em camadas separadas, lá embaixo, onde o kernel agenda os processos. É trabalho invisível, de fundação. Mas é na fundação que se decide quem vai conseguir escalar IA quando a conta deixar de ser dinheiro e passar a ser, de vez, energia.

Se você roda inferência em produção, fica a pergunta que me tirou o sono: você sabe quanto custa o seu último mil tokens? Se a resposta for "uns dólares de GPU por mês, mais ou menos", você está medindo a coisa certa pela lente errada.

Publicado originalmente em: https://rodrigofreire.pages.dev/posts/03-custo-por-token/

Custo por Token: a fatura de energia invisível que ninguém mede na IA

Rodrigo Freire — Mon, 29 Jun 2026 12:27:42 +0000

Por Rodrigo Freire — Pesquisa e Desenvolvimento em Deep Tech

Todo time de FinOps sabe responder quanto a empresa paga de nuvem por mês. Quase nenhum sabe responder a pergunta que realmente importa: quanto custa, em watts e em centavos, cada token que o seu modelo gera?

Esse vão — entre "pagamos X mil dólares de GPU por mês" e "o modelo Y custa Z centavos por mil tokens para rodar" — é onde mora um dos maiores desperdícios invisíveis da computação atual. E não é um problema de planilha. É um problema de instrumentação que vive lá embaixo, no nível do kernel.

Neste artigo eu decomponho por que esse número é tão difícil de obter, por que as ferramentas de observabilidade tradicionais não chegam até ele, e qual é a arquitetura que torna possível atribuir energia a um token específico. Vou ser franco também sobre onde a abordagem tem limites — inclusive a minha.

A pergunta que parece simples e não é

A equação que define o problema cabe em uma linha:

custo_por_token = (W_cpu + W_dram + W_gpu) × tempo_inferência / tokens_gerados

Parece trivial. Não é. Cada termo dessa conta vive numa camada diferente do sistema, exposto por uma interface diferente, com uma granularidade diferente — e nenhuma ferramenta junta tudo num número só, atribuído ao processo certo, no instante certo.

O gargalo real da expansão de datacenters de IA hoje não é capital para comprar GPU. É megawatt disponível na rede elétrica. Quando a restrição física é energia, saber exatamente onde cada watt está sendo gasto deixa de ser curiosidade de engenheiro e vira decisão de negócio. Uma redução de 5% a 10% no consumo agregado de um cluster de inferência representa milhões de dólares por ano em eletricidade e refrigeração. Mas você não otimiza o que não mede — e ninguém está medindo no nível certo.

Por que a observabilidade tradicional não chega lá

Pare e observe o que torna esse número escorregadio.

A energia da CPU mora num lugar. O consumo de CPU e DRAM é exposto pela interface RAPL (Running Average Power Limit) da Intel, lida via /sys/class/powercap. É um contador acumulado em microjoules, com subdomínios separados para o pacote do processador e para a memória. Útil — mas cobre só uma fatia do consumo.

A energia da GPU mora em outro. Numa inferência de LLM em datacenter, 80% a 90% dos watts estão na GPU, não na CPU. E a GPU não fala RAPL. Ela fala NVML (NVIDIA Management Library), uma biblioteca completamente separada, com sua própria API, suas próprias unidades, seu próprio modelo de processo. Quem mede só RAPL está medindo a ponta do iceberg e ignorando o bloco submerso.

Os tokens moram num terceiro lugar. O número de tokens gerados vive dentro do engine de inferência — vLLM, llama.cpp, Ollama — e cada um o expõe de um jeito. Alguns têm endpoint de métricas estruturado; outros só cospem no log.

E a correlação temporal não mora em lugar nenhum. Aqui está o nó. Ferramentas como Prometheus, DCGM e OpenTelemetry medem energia agregada do host. Elas dizem "este servidor consumiu tantos watts". Nenhuma delas responde "o processo de PID 214, rodando o modelo Llama, consumiu tantos watts de CPU mais tantos de GPU enquanto gerava estes tokens, nesta janela de 200 milissegundos". A atribuição atômica — energia ligada a um processo ligado a um output — simplesmente não existe nas ferramentas de prateleira.

Em resumo: toda ferramenta que pergunta "quanto este host gastou?" erra a pergunta. A pergunta certa é "quanto este token custou?" — e ela exige descer ao nível onde o escalonador do sistema operacional decide quem roda quando.

A arquitetura: correlação no nível do kernel

A peça que ninguém tem é a ponte temporal entre o processo e a energia. E essa ponte se constrói com eBPF.

Um programa eBPF anexado ao tracepoint sched/sched_switch enxerga, com precisão de microssegundo, exatamente quando um worker de inferência entra e sai da CPU. Esse é o relógio que faltava. Com ele, dá para correlacionar a janela de execução de um PID específico com a leitura de energia daquele intervalo — somando a fatia de RAPL (CPU + DRAM) à leitura de NVML (GPU) atribuída àquele mesmo processo.

O fluxo, em camadas:

1. Coleta de CPU e DRAM. O leitor RAPL via powercap entrega watts de pacote e de memória. Um detalhe que morde quem implementa rápido demais: o contador é cíclico e estoura (max_energy_range_uj). Tratar o wraparound sem produzir watts negativos é obrigatório, não opcional.

2. Coleta de GPU. Bindings de NVML leem o consumo por dispositivo e — crucialmente — mapeiam qual PID está rodando em qual GPU via nvmlDeviceGetComputeRunningProcesses. Esse é o elo que liga o processo à placa.

3. A janela temporal via eBPF. O tracepoint de escalonamento define os limites exatos da janela de medição por processo, em vez de uma média grosseira do host inteiro.

4. A contagem de tokens. Aqui está a parte mais frágil de toda a cadeia, e vale honestidade total: contar tokens lendo o log de saída do engine é traiçoeiro. A fonte confiável é o endpoint de métricas nativo do engine — por exemplo, o contador generation_tokens_total do vLLM, que é estruturado, monotônico e livre de ambiguidade. O parsing de log deve ser fallback de último recurso, não a fonte de verdade.

A lição que custou caro (e foi barata)

Sobre o ponto 4, uma confissão técnica que ilustra o método.

A primeira implementação que validei contava tokens fazendo parsing do log de saída, com uma lógica de deduplicação para evitar contar o mesmo evento duas vezes. A heurística usava o valor numérico como chave de identidade: se "gerou 50 tokens" aparecesse duas vezes em menos de meio segundo, a segunda ocorrência era descartada como duplicata.

O problema apareceu sob carga concorrente real. Quando vinte requisições idênticas geram 50 tokens cada, quase no mesmo milissegundo, a deduplicação as confundiu com repetições do mesmo evento — e descartou dezoito delas. Resultado: subcontagem de 80%. O número que deveria ser mil tokens virou duzentos.

A causa raiz não era o dedup. Era a tentativa de reconstruir, a partir de texto não-estruturado, um número que o engine já expunha de forma canônica. A correção não foi melhorar o parser — foi abandoná-lo como fonte primária e ler o contador estruturado do endpoint de métricas, exatamente como a inferência o reporta.

A lição vale além desse caso: quando você se vê fazendo engenharia reversa de um dado que a fonte já entrega estruturado, você está otimizando o caminho errado. O barato aqui foi descobrir isso num teste de mesa de cinco dólares, não num cluster de produção depois de prometer precisão a um cliente.

Onde isso tem limites

Nenhuma arquitetura é mágica, e a honestidade sobre os próprios limites é o que separa pesquisa de marketing.

A atribuição multi-modelo é difícil. Num host que serve vários modelos ao mesmo tempo, dividir a energia entre eles com exatidão exige cuidado. A aproximação por tempo de CPU funciona bem para um único workload e vira estimativa quando há vários competindo pela mesma placa.

RAPL é Intel. A interface cobre CPU e DRAM em plataformas Intel; AMD e ARM têm seus próprios mecanismos, com cobertura desigual.

Medir não é otimizar. Saber o custo por token é o primeiro passo, não o último. O passo seguinte — agir sobre esse número — é um território com riscos próprios, sobretudo o de violar SLAs de latência se alguém ceder à tentação de estrangular processos no momento errado. Por isso a observabilidade pura, que só mede e nunca atua, é um produto defensável por si só: ela entrega o dado sem nunca colocar a inferência em risco.

Conclusão

A indústria de IA aprendeu a medir gasto de nuvem em dólares por mês. O próximo nível de maturidade é medir eficiência energética por unidade de trabalho útil — watts por token, joules por requisição, centavos por mil tokens, atribuídos ao processo e ao modelo certos.

Esse número não vem de uma planilha nem de um dashboard de host. Ele vem de juntar três fontes que vivem em camadas diferentes do sistema — RAPL, NVML e eBPF — numa correlação temporal que só existe quando você desce até onde o kernel agenda os processos.

É um trabalho silencioso, invisível, e fica nas fundações. Mas é exatamente nas fundações que se decide quem vai conseguir escalar IA quando a restrição deixar de ser dinheiro e passar a ser, definitivamente, energia.

Publicado originalmente em: https://rodrigofreire.pages.dev/posts/custo-por-token-energia-invisivel-da-ia/

Assimetria Reversa: Por que paramos de bloquear hackers e começamos a asfixiá-los?

Rodrigo Freire — Wed, 24 Jun 2026 15:57:49 +0000

Postado originalmente em: https://rodrigofreire.pages.dev/posts/artigo_imunno_assimetria_reversa/

Na segurança cibernética tradicional, a resposta a uma invasão costuma ser binária: Detectar e Bloquear. Se um processo malicioso tenta acessar um arquivo de configuração sensível ou executar um payload, o sistema de defesa derruba a conexão, encerra o processo e o atacante recebe um sonoro Access Denied.

O problema dessa abordagem? Você acabou de fornecer o melhor feedback possível para o invasor.

Quando lutamos contra scripts genéricos ou varreduras simples, o bloqueio imediato (a "Guilhotina") é eficiente e barato. Porém, o cenário atual envolve IAs Adversariais e Ameaças Persistentes Avançadas (APTs). Se você bloqueia uma IA de ataque imediatamente após ela pisar em falso, ela aprende. O bloqueio é o sinal de que ela encontrou uma barreira e precisa ofuscar seu payload na próxima tentativa. Você entra num jogo infinito de gato e rato onde a defesa precisa acertar sempre, e a IA só precisa acertar uma vez.

Foi para quebrar esse ciclo que, ao desenvolvermos o Imunno System (nosso sistema imunológico adaptativo), adotamos uma filosofia biológica de "Assimetria Reversa". Criamos um labirinto invisível que chamamos de Arquitetura HADES.

O Paradoxo da Guilhotina vs. Cyber-Deception

Para 99% das ameaças comuns, o extermínio imediato do processo malicioso é a regra. É rápido e consome poucos recursos. Mas e os 1% que representam IAs avançadas?

Em vez de alertar a IA de que ela foi detectada, o sistema aciona o modo de Decepção Ativa. O invasor continua digitando comandos, lendo arquivos e achando que está dominando o servidor, enquanto na verdade está isolado numa simulação.

Isso serve a dois propósitos táticos fundamentais:

Envenenamento de IA (Data Poisoning): Ao deixar o invasor acessar arquivos de configuração ou bancos de dados falsos gerados dinamicamente (Honeyfiles), nós poluímos o pipeline de aprendizado da IA atacante. O modelo dela converge para uma solução totalmente errada, desperdiçando o tempo e o orçamento do invasor processando dados inúteis.
Tempo para a Árvore de Causalidade: Rastrear a origem exata de um ataque (o Patient Zero) requer a análise de árvores genealógicas de processos e correlação avançada de dados temporais. Se matamos o processo instantaneamente, perdemos a chance de ver a ameaça "ligar para casa" (C2 - Comando e Controle). A simulação nos compra os milissegundos preciosos para rastrear toda a linhagem do ataque antes de extirpar a rede inteira pela raiz.

A Tríade da Contenção: Kernel, Isolamento e Energia

Para tornar essa simulação impossível de ser detectada pelo atacante, nós operamos muito abaixo do nível do usuário, manipulando diretamente as engrenagens mais profundas do Sistema Operacional. A contenção se divide em três pilares:

1. A Matriz: Ilusão de Sistema de Arquivos

Um atacante invariavelmente buscará credenciais sensíveis no servidor. Em vez de bloquear a leitura, injetamos espelhos falsos do sistema de arquivos diretamente no namespace restrito do invasor. Ele "lê" as credenciais, mas são armadilhas perfeitamente forjadas que parecem reais, garantindo que o servidor de produção continue intacto.

2. O Tarpit de Rede Silencioso

Cortar a conexão TCP alerta o atacante na hora. Nossa abordagem manipula os filtros nativos de rede do Sistema Operacional para aplicar regras de descarte silencioso (Drop) atreladas especificamente ao grupo de processos do invasor. Ele tenta enviar um pacote para extrair os dados "roubados" e a requisição fica pendurada num timeout infinito. Para ele, a internet apenas parece instável.

3. A Joia da Coroa: Asfixia Termodinâmica

Este é o golpe final no modelo econômico do ataque. A inteligência do nosso sistema correlaciona a execução de processos com picos termodinâmicos (consumo elétrico em Watts) dos componentes de hardware.

Quando detectamos um ataque Fileless (que roda apenas em memória para escapar de varreduras) ou uma IA executando força-bruta, nós não matamos o processo. Nós aplicamos uma asfixia radical de recursos de CPU no nível do escalonador do Sistema Operacional.

O resultado? Uma inversão assimétrica econômica perfeita.
As GPUs gigantescas e botnets do atacante continuam consumindo energia máxima para manter as requisições ativas. Do nosso lado, o Kernel simplesmente corta o tempo de processamento destinado àquele ataque. Nós literalmente esfriamos o nosso servidor, reduzindo brutalmente nossa fatura de nuvem, enquanto derretemos o hardware e o bolso do invasor.

Conclusão

Na cibersegurança moderna, a guerra é de atrito (War of Attrition). Vence quem inviabiliza o lado econômico do oponente primeiro.

Ao unir Reconhecimento Comportamental, Árvores de Causalidade e Controle Termodinâmico no nível do Kernel, nós paramos de brincar de construir muros mais altos e começamos a projetar areia movediça. A defesa ativa não se trata apenas de sobreviver ao ataque, mas de garantir que o atacante se arrependa amargamente do custo de tê-lo tentado.

# Anatomia de um C2 invisível: como o malware Steam WordPress engana a detecção tradicional (e como detê-lo por comportamento)

Rodrigo Freire — Sun, 07 Jun 2026 16:52:49 +0000

Por Imunno System

Em julho de 2025, pesquisadores da GoDaddy Security começaram a rastrear uma campanha que, em poucos meses, infectou cerca de 1.980 sites WordPress. O detalhe que fez essa campanha circular pela imprensa de segurança não foi o volume — foi a engenhosidade do canal de Comando e Controle (C2): comentários de perfil da Steam, com instruções escondidas dentro de caracteres Unicode invisíveis.

Este artigo decompõe a cadeia de ataque, explica por que ela escapa das defesas convencionais, e mostra como uma arquitetura de detecção baseada em comportamento — em vez de assinatura — muda o jogo. Vou ser franco também sobre onde cada abordagem tem limites, incluindo a nossa.

A cadeia de ataque, em camadas

O brilho dessa campanha está em não brilhar. Cada etapa foi desenhada para parecer rotina.

1. Comprometimento inicial. Não há um exploit único. A análise aponta para vetores conhecidos e mundanos: credenciais de admin roubadas, acesso FTP/SFTP comprometido, um plugin ou tema vulnerável, ou compromisso de cadeia de suprimentos. Nada exótico — e é justamente por isso que funciona em escala.

2. O backdoor PHP. Plantado o pé inicial, o malware instala um backdoor server-side capaz de modificar arquivos PHP do site. Ele se mantém com autenticação por cookie e aceita comandos via POST. Esse é o ponto de persistência: mesmo uma limpeza superficial deixa o caminho de volta aberto.

3. O C2 esteganográfico. Aqui está a inovação. Em vez de telefonar para um servidor controlado pelo atacante — que seria flagrado por reputação de domínio — o WordPress comprometido busca uma página de perfil público da Steam. O texto do comentário parece arte ASCII inofensiva. Escondidos entre os caracteres visíveis, porém, estão seis caracteres Unicode invisíveis (zero-width non-joiner, zero-width joiner, e variantes de "invisible" operator) mapeados para bits. Decodificados, eles reconstroem uma URL.

4. A injeção. A URL aponta para um JavaScript hospedado externamente, disfarçado de biblioteca legítima — nomes como lodash.core.min.js. Esse script é injetado em todas as páginas públicas do site, atingindo cada visitante. O payload ainda usa AES-256-CTR com derivação de chave PBKDF2 e HMAC, o que dá ao operador controle criptograficamente protegido sobre o conteúdo.

Por que a detecção tradicional falha

Pare e observe o que torna essa campanha resistente:

Reputação de domínio não ajuda. O servidor comprometido conversa com steamcommunity.com — um dos domínios mais confiáveis da internet. Nenhuma blocklist vai sinalizar isso. O atacante terceirizou sua infraestrutura de C2 para uma plataforma que ninguém ousa bloquear.

Assinaturas de arquivo são frágeis. O payload real está cifrado e ofuscado em múltiplas camadas, com identificadores randomizados e código-isca. Uma regra que casa com a string de hoje não casa com a variante de amanhã.

O canal é stego, não tráfego anômalo. Os caracteres Unicode invisíveis não disparam filtros de spam nem moderação — usuários postam arte ASCII com Unicode o tempo todo. O payload viaja escondido dentro do que parece conteúdo normal.

Em resumo: toda defesa que pergunta "esse indicador é conhecidamente ruim?" perde. O indicador foi projetado para parecer bom.

A pergunta certa: causalidade, não assinatura

A mudança de paradigma é parar de perguntar "este artefato é malicioso?" e começar a perguntar "este comportamento deveria estar acontecendo, dado o contexto?".

Aplicado a essa campanha, três comportamentos se destacam — independentemente de como o payload é cifrado:

1. Modificação de arquivo PHP por origem inesperada. O backdoor reescreve arquivos PHP. Um agente que mantém o hash SHA-256 de cada arquivo PHP/JS e detecta a divergência no momento da modificação não se importa com o conteúdo da mudança — ele detecta que houve mudança não autorizada. Em produção, arquivos de core do WordPress não mudam sozinhos.

2. Linhagem de processo web→shell. Se o backdoor executa comandos do sistema, o processo que os roda é filho do php-fpm ou do servidor web. Um motor de causalidade que rastreia a árvore pai→filho identifica o padrão nginx → bash ou php-fpm → sh como o que ele é: execução remota de código quase nunca legítima em um servidor de produção.

3. Conexão outbound para domínio fora do baseline. Aqui está o ponto mais interessante. Um servidor WordPress típico não faz requisições HTTP de saída para steamcommunity.com durante o carregamento de página. Não importa que a Steam seja confiável — o que importa é que este servidor nunca fez isso antes. Detecção por desvio de baseline de comportamento de rede pega exatamente o que a reputação de domínio deixa passar.

É essa a tese do Imunno System: defender servidores web Linux pela causalidade e pelo comportamento, contendo a ameaça via cgroups (limitando o processo suspeito a 1% de CPU em vez de matá-lo e arriscar derrubar o serviço legítimo junto).

Onde até a detecção comportamental tem limites — sendo honesto

Seria desonesto vender comportamento como bala de prata. Vamos aos limites reais:

O C2 esteganográfico em si é difícil de pegar no fio. Detectar os caracteres Unicode invisíveis exige inspeção de conteúdo de arquivo procurando por code points específicos (U+200C, U+200D, U+2061–U+2064 em densidade anômala). É factível — é detecção de conteúdo, não de comportamento — mas é uma capacidade que precisa ser explicitamente construída. Não cai de graça do modelo de causalidade. No nosso roadmap, isso é uma fase planejada, não um recurso que já entregamos.

Detecção de baseline de rede sofre com cold start. Um servidor recém-monitorado não tem baseline. O período de aprendizado é uma janela de cegueira parcial, e atacantes pacientes podem se misturar ao tráfego durante ela.

Modificação de arquivo via caminho legítimo é zona cinzenta. Se o backdoor escreve através de um processo que legitimamente edita arquivos (um plugin de atualização automática, por exemplo), separar o sinal do ruído fica difícil sem contexto adicional.

Nenhuma camada única resolve. O que funciona é a sobreposição: integridade de arquivo + causalidade de processo + baseline de rede + inspeção de conteúdo, onde a falha de uma é coberta pela outra.

O que tirar disso

Essa campanha é um lembrete de que a fronteira da defesa não está em ter a maior blocklist. Está em entender o que é normal para um servidor específico e detectar o desvio — porque o atacante moderno trabalha duro para que cada indicador isolado pareça inofensivo.

Para quem opera servidores WordPress hoje: revise arquivos PHP/JS modificados recentemente, procure por conexões de saída para domínios inesperados (mesmo os "confiáveis"), e desconfie de qualquer processo shell cujo pai seja o servidor web. E se você foi infectado, restaure de um backup limpo conhecido — o backdoor persiste.

O Imunno System é um EDR de borda para servidores web Linux, focado em detecção comportamental contra webshells, comprometimento de arquivos e abuso de processos. Documentação e arquitetura: github.com/rodrigoffreir3/imunno-pitch

Referências técnicas: relatório original da GoDaddy Security sobre a campanha; cobertura do BleepingComputer e Security Affairs (junho de 2026).