Na verdade, o título correto deste texto seria “O Estranho Caso do Sumiço de Ameaças”. Vejamos.

Em meados de agosto de 2026 recebi inúmeras mensagens de email da empresa de hospedagem HostGator reportando a presença de malware no meu servidor que hospeda 6 domínios e alguns projetos web independentes.

Inicialmente não dei muita atenção porque as instalações do WordPress — inclusive esta aqui — têm atualizações automáticas de segurança, então não imaginei que pudessem estar vulneráveis e já comprometida.

Dias depois desses emails chegarem recebo uma mensagem do Google Search Console informando que algumas páginas de um dos sites hospedados não poderiam ser indexadas por motivo de uma queixa de direitos autorais de um terceiro.

Pronto, agora o cenário muda. Desconfiei que algum conteúdo pudesse ter sido injetado no site via backdoor. Mas, como?

Entrei nos painéis administrativos de todas as instalações WordPress em busca de pistas. Nada.

Voltei para o console do Google Seach para ver a lista de URL não indexadas. Peguei uma qualquer.

Sim, estava publicada no site, mas oculta no painel administrativo.

Entro no blog do site e pelo widget de categorias vejo “Sem categoria” com 2800 itens. Bingo.

O malware tinha feito a injeção de usuários admin e conteúdo, mas através de um artifício, dentre dezenas de outros, conseguia esconder essas evidências na painel administrativo.

Entrei no servidor e fui olhar o filesystem e o banco de dados. De pronto identifiquei uma série de plugins do WordPress instalados mas não ativados. Eles estavam sendo usados como shell para o armazenamento do kit de malware.

Meu foco nesse momento estava apenas em uma instalação do WordPress. Eu ainda não havia sido apresentado ainda a característica de side-infection do malware que, como o nome diz, se propaga lateralmente entre diferentes instalações do WordPress quando ele as identifica do servidor.

Neste ponto eu já estava conversando com o Grok 4.6 para identificar a vulnerabilidade que permitiu a entrada do malware ou backdoor intencional instalada por ele. Também, em paralelo, trabalhava para desativar o malware da primeira instalação WordPress (WP).

Nossa primeira ação foi tão ingênua quanto excluir o usuário admin_* do banco de dados e os conteúdos falsos. Poucos minutos depois havia um outro usuário com o mesmo prefixo de nome. Os conteúdos não haviam sido criados ainda.

Parece que o malware tem três status principals — minha ingênua suposição de novo — um instalado dormente, outro instalado e esperando e outro ativo publicando conteúdos, posts.

Foi nesse ponto que começamos a perceber a principal característica do malware — que é brilhante, diga-se de passagem — a sua capacidade de auto-reparar, self-healing. Quando entendi o que isso significava, minha curiosidade superou a urgência de reparar a instalação. 🤓 🤣

Eu continuava sem saber o que era side-infection, muito menos isso combinado com o self-healing. É realmente brilhante e muito bem arquitetado. E pelo fato de PHP ser minha primeira linguagem de programação profissional, me via surpreso a cada novo arquivo que descobria da arquitetura do malware.

Mas isso era só o começo. A arquitetura não se limitava a arquivos no filesystem, mas trabalhava conteúdo persistido no banco de dados, no browser do usuário administrador da instalação WP e, segundo este excelente artigo, também no blockchain Ethereum. Muito interessante mesmo.

Por mais que desativássemos os arquivos do filesystem com extensão .php e .zip de uma instalação WP com sufixos tipo .off, aprendi muito com o Grok e sua proposta de enumerar os arquivos com .off### tipo .off001, .off002 e assim por diante para que pudéssemos ter ideia das transformações que o malware executava.

Neste ponto começamos a entender que mesmo tendo todos os arquivos desativados dentro de uma instalação, novos eram criados em uma questão de minutos pelo kit instalado em outras instalações. Tempo depois percebemos que havia payloads do kit instalados no banco de dados em wp-options de cada instalação WP.

O gatilho da auto-regeneração parecia ser — e ainda não tenho certeza sobre isso — o arquivo functions.php dentro o tema ativo da instalação. O kit instalou um arquivo .user.ini que fazia o append de um pedaço de código no final desse arquivo php que provavelmente se encarregava de trazer o malware para seu baseline operacional via elementos encontrados na própria instalação ou em instalações laterais via side-infection. Side-healing? Talvez. Muito inteligente e bem feito.

Chegamos a mapear 90% do kit. Com a ajuda do artigo acima que achei no X.com conseguimos pelo menos ficar alertas para um risco de reinfecção via o browser do usuário admin de qualquer uma das instalações WP afetadas e/ou, incrivelmente, do blockchain Ethereum que, segundo o artigo, carregava uma versão do payload do kit de forma universal na Internet. Brihante.

Como servidor roda Apache, alteramos o .htaccess de cada instalação para rejeitar todas as requisições. O servidor retornaria um 403 padrão da HostGator. Todos os sites “saíram do ar”.

Assim desativamos todos os elementos do kit, limpamos todos os bancos de dados, alteramos senhas, segredos e salts. (há mais detalhes sobre essa parte no artigo técnico)

Depois disso, nos restava esperar algumas horas antes de remover a regra do .htaccess e avaliar se o malware faria o self-healing novamente.

Neste ponto ainda não tínhamos certeza sobre a vulnerabilidade e/ou backdoors. Removi instalações desatualizadas, bancos de dados sem uso, plug-ins antigos e não usados, etc. Tudo que não fosse estritamente necessário. Isso sem contar a revisão nas contas FTP e crons do HostGator.

Tudo parecia estar OK.

Nesse downtime, aproveitei para conversar com meus sócios e clientes sobre a situação. Uma possibilidade era mover instalações supostamente limpas para VPS dedicados, evitando pelo menos a reinfecção lateral e tendo acesso mais controlado a logs para identificar as portas de entrada.

Porém, não chegamos a tomar essa decisão de mudança de infra. Resolvemos testar o serviço de cybersegurança freneticamente sugerido pela HostGator toda vez que me logava ao painel administrativo do host.

Cliquei no banner e contratei o serviço. 20 reais por mês para todas as instalações WP. Custo bastante baixo se comparado ao investimento de tempo e dor de cabeça gerada no enfrentamento do malware.

E foi neste ponto que surgiu a coisa do “O Curioso Caso” deste malware que me inspirou a redigir este relato.

No ato de contratar o serviço de cybersegurança e “limpeza” de vírus e malware percebi algo estranho no bonito gráfico de barras usado pela HostGator para ilustrar o problema para o cliente/prospect.

Detalhes da linha do tempo:

• foi avisado sobre presença de malware na última semana de agosto. As barras vão até o início de agosto se você paginar o gráfico para trás no tempo.
• na virada do dia 27 de agosto para 28 de agosto há uma abrupta redução de arquivos comprometidos na minha conta de hospedagem, mas neste ponto eu nem havia começado a trabalhar no assunto
• na virada do dia 1 de setembro para 2 de setembro tomei ciência da gravidade do assunto depois de ler com mais atenção o email do Google Search sobre infringimento de direitos autorais (o gatilho)
• o serviço de cybersegurança foi contratado no dia 3 de setembro antes mesmo de removermos a regra de acesso nos .htaccess das instalações WP

A partir do dia 3 de setembro não conseguimos mais identificar qualquer traço do kit de malware em nenhuma das instalações WP. Até os arquivos desativados com sufixo .off### foram removidos, assim como o .zip do payload. Vida normal daqui por diante.

Infelizmente não sei se o problema foi sanado através do trabalho que fizemos desativando o kit malware da melhor forma que podíamos imaginar seu funcionamento, ou se foi o glorioso serviço da HostGator que supostamente muito capaz. Erro meu, na verdade.

Ficaremos sem resposta, mas com muitas suposições sobre o comportamento da HostGator ao longo do mês de agosto:

1. Lançamento de serviço de cybersegurança
2. Avisos massivos e frequentes sobre presença de malware na conta do cliente
3. Flutuações na quantidade de arquivos com malware na conta do cliente sem que ele tenha contratado o novo serviço de cybersegurança ou tomado qualquer medida reparativa.

Número 3 deixa a questão no ar se o HostGator decidiu usar o serviço de cybersegurança à revelia dos clientes como medida emergencial de contenção do malware cuja característica de infecção lateral pode ter “transbordado” para outros clientes, outras contas, da empresa em uma proliferação em massa.

Se há outros motivos que possam explicar essa redução de arquivos comprometidos antes da contratação de qualquer serviço, eu não sei… que coisa estranha… o estranho caso do SC 4.0.3.

Disclaimers:

• eu gosto da HostGator e continuo sendo um cliente no momento que escrevo isso
• minha intenção não é levantar suspeitas sobre o serviço da empresa, mas apenas relatar minhas reflexões e sentimentos ao longo desse processo
• não tenho ligação com o grupo do SC 4.0.3. apesar dos elogios. Os caras “são brabo”!