Malware em WordPress: como usei o ChatGPT para investigar e conter um ataque
Não sou especialista em cibersegurança. Ainda assim, em cerca de 12 horas de trabalho consegui investigar e conter um incidente de malware que afetava mais do que uma instalação WordPress. O mais interessante não foi apenas o ataque: foi perceber até onde uma pessoa consegue chegar quando usa a Inteligência Artificial como biblioteca, mentor e copiloto técnico.
Há uma aplicação da Inteligência Artificial que me parece ainda subestimada: a capacidade de aumentar aquilo que uma única pessoa consegue fazer.
Um sistema como o ChatGPT pode funcionar como uma biblioteca gigantesca. Mas existe uma diferença importante em relação a uma biblioteca tradicional: posso mostrar-lhe exatamente o problema que tenho à minha frente, dar-lhe contexto, acrescentar novos dados e construir uma investigação passo a passo.
Quando esse contexto é suficientemente bom, a IA começa também a funcionar como um mentor. Não porque substitua um especialista, mas porque nos pode ajudar a perceber o que estamos a observar, que hipóteses fazem sentido, o que devemos verificar a seguir e que alterações podem representar um risco.
Foi precisamente isto que me aconteceu.
Em resumo
Numa manhã, um dos meus sites começou a apresentar milhares de caracteres sem sentido antes do conteúdo normal. O que inicialmente parecia um problema de cache acabou por revelar malware com vários mecanismos de recuperação e persistência.
Ao aprofundar a investigação encontrei sinais diferentes em várias instalações: uma conta administrativa que não reconhecia, páginas e URLs relacionadas com casino que nunca tinham sido publicadas por mim e, no IA Hoje, dezenas de endereços anómalos que o Google Search Console tinha chegado a rastrear.
Foram necessárias cerca de 12 horas de investigação e contenção. O ChatGPT não executou o trabalho por mim, mas tornou possível que eu conseguisse fazê-lo.
Como usar este artigo: alguns conceitos técnicos aparecem a azul. Clique no termo para consultar a respetiva explicação. No glossário, “Voltar ao artigo” regressa exatamente ao ponto onde estava. As imagens também podem ser ampliadas.
Como tudo começou
Tudo começou numa manhã em que abri uma página de um dos sites que tenho alojados.
Em vez da página normal, apareceu uma enorme quantidade de caracteres aparentemente aleatórios.
Tentei perceber se o problema se limitava àquela página. Não se limitava.
O mesmo comportamento aparecia noutras áreas do site e também quando tentava chegar ao WordPress.
No ecrã de login, o formulário chegava a aparecer, mas era precedido por todos aqueles caracteres. O próprio WordPress indicava que os cookies tinham sido bloqueados devido a um resultado inesperado.
À primeira vista, o problema parecia estar relacionado com cache, compressão, headers ou alguma configuração do servidor.
E foi por aí que comecei.
O que parecia um problema de cache era malware
Ao verificar os ficheiros relacionados com o funcionamento do WordPress, um dos primeiros elementos que chamou a atenção foi:
Quando esse ficheiro foi temporariamente retirado de funcionamento, o site voltou ao normal.
Durante alguns minutos, podia parecer que o problema estava encontrado.
Mas a análise do ficheiro mostrou algo completamente diferente.
O código estava fortemente ofuscado — escrito de forma deliberadamente difícil de interpretar — e continha lógica para localizar, recuperar e voltar a colocar em funcionamento outros componentes.
Um dos nomes que apareceu repetidamente foi:
O que é que este código está a fazer, onde mais está instalado e de quantas formas consegue voltar?
Porque é que o malware podia voltar a aparecer?
Uma das partes mais importantes da investigação foi perceber que não estava perante um único ficheiro malicioso.
Existiam vários mecanismos de persistência.
Isto significa que eliminar o ficheiro que estava visível não significava necessariamente eliminar o problema.
1. advanced-cache.php
Em algumas instalações, o advanced-cache.php tinha sido transformado numa das peças capazes de recuperar o código malicioso.
2. MU Plugins
Foram encontradas cópias ou referências ao malware dentro dos MU Plugins, em:
wp-content/mu-plugins/
Estes plugins são carregados automaticamente pelo WordPress.
3. Uma segunda cópia como plugin normal
Existia também lógica para manter outra cópia dentro da pasta normal de plugins.
wp-content/plugins/rapid-analyzer-edge/
4. .user.ini e execução automática de código
Outro mecanismo encontrado utilizava o ficheiro
.user.ini.
Em alguns casos, continha uma instrução
auto_prepend_file.
Esta configuração permite ao PHP executar automaticamente outro ficheiro antes do código normal que foi pedido.
5. Código guardado na base de dados
A investigação mostrou também código malicioso — aquilo a que em cibersegurança se chama payload — guardado dentro da base de dados do WordPress.
Isto significa que limpar apenas os ficheiros podia não ser suficiente. Parte do código necessário para os reconstruir podia continuar guardada na base de dados.
6. WP-Cron
Foram ainda encontradas tarefas associadas ao WP-Cron, o sistema de tarefas agendadas do WordPress.
7. Ficheiros ZIP de recuperação
O código procurava também ficheiros ZIP com nomes aparentemente aleatórios em diferentes locais do WordPress.
Estes ficheiros podiam guardar componentes necessários para voltar a criar código PHP.
8. Outros mecanismos
A análise mostrou ainda mecanismos relacionados com memória partilhada do sistema e diferentes formas de recuperar componentes.
A principal lição técnica foi esta: apagar um ficheiro malicioso não é o mesmo que eliminar a infeção. É necessário perceber o que o consegue voltar a criar.
Os sinais que já estavam à vista
Quando comecei a recuar no tempo, apareceram elementos que já existiam antes de eu perceber que estava perante malware.
Numa das instalações afetadas encontrei uma conta com privilégios de administrador que eu não reconhecia.
Essa conta tinha sido criada semanas antes da descoberta do incidente.
Este elemento tornou-se especialmente relevante depois de analisarmos o malware, porque o código que encontrámos tinha também capacidade para criar utilizadores administrativos e atribuir-lhes privilégios elevados.
Se tem um WordPress, faça esta verificação
Vá a Utilizadores → Todos os utilizadores e confirme quem tem perfil de Administrador.
Um utilizador desconhecido não deve ser eliminado automaticamente. Pode ser uma conta antiga, um prestador de serviços ou um utilizador criado durante a instalação. Mas deve perceber quem é, quando surgiu e por que razão tem privilégios administrativos.
Páginas de casino que eu nunca tinha criado
Na mesma instalação existia outro sinal bastante diferente: páginas e URLs relacionadas com casino que nunca tinham sido criadas por mim.
Não faziam parte dos conteúdos normais do projeto e não tinham qualquer relação com a finalidade do site.
Inicialmente, um fenómeno deste tipo pode parecer apenas spam ou um problema de indexação.
Mas, quando comecei a relacioná-lo com a existência de uma conta administrativa não reconhecida, os ficheiros maliciosos e os mecanismos de persistência encontrados mais tarde, tornou-se claro que devia ser analisado como parte do mesmo incidente de segurança.
Um ponto importante: nem sempre um site comprometido deixa de funcionar. Para determinadas utilizações, é mais vantajoso para quem o compromete que o proprietário continue a vê-lo aparentemente normal.
Um domínio legítimo que já tem histórico, tráfego, backlinks e posições nos motores de pesquisa pode ter valor para quem queira tentar promover páginas de casino ou outros conteúdos através de SEO spam.
O Google Search Console também estava a avisar
No IA Hoje, o sinal era diferente.
O Google Search Console mostrava URLs associados ao domínio que eu não reconhecia.
Algumas eram sequências aparentemente aleatórias. Noutras apareciam caminhos completamente estranhos à estrutura editorial do portal.
O mais curioso era que estes endereços não correspondiam a páginas ou artigos que eu tivesse criado no WordPress.
Muitos acabaram posteriormente por devolver 404.
Mesmo assim, o Google tinha-os encontrado e rastreado.
Se o Search Console começar a mostrar páginas, diretórios ou URLs que não reconhece, não olhe apenas para isto como um problema de SEO. Pode também justificar uma verificação de segurança.
Quando percebi que não era apenas um site
Depois de compreender o que estava a acontecer na primeira instalação, comecei a verificar outros WordPress existentes na mesma conta de alojamento.
E apareceram indicadores semelhantes.
Por razões de segurança, não identifico neste artigo os restantes projetos nem a estrutura concreta do alojamento.
O ponto importante é que o incidente não estava limitado ao site onde apareceu o primeiro sintoma.
Existiam sinais da mesma família de malware noutras instalações sob a mesma conta.
Quando diferentes sites funcionam sob o mesmo utilizador do sistema, código PHP executado com essas permissões pode, em determinadas circunstâncias, conseguir escrever noutras pastas pertencentes à mesma conta.
Isto não demonstrava que todo o servidor estivesse comprometido. Demonstrava que a investigação tinha de abranger a conta de alojamento e não apenas um WordPress isolado.
O que os logs mostraram
Depois da análise aos ficheiros, bases de dados e instalações WordPress, comecei a recuar nos logs.
Foi aí que apareceu um padrão particularmente importante.
Acesso ou login no WordPress → entrada no /wp-admin/ → upload de plugin → ativação do plugin.
A mesma sequência aparecia em mais do que uma instalação.
A primeira evidência de elevada confiança que encontrei deste padrão remontava a 5 de julho de 2026.
Existiam, contudo, sinais anteriores. Em junho já existia pelo menos uma conta administrativa que eu não reconhecia e já tinham começado a surgir outros indicadores anómalos.
A data em que descobrimos um ataque não é necessariamente a data em que o ataque começou.
A investigação permitiu perceber bastante sobre a forma como o malware se mantinha ativo. Não permitiu, até ao momento, provar com certeza qual foi o ponto inicial de entrada.
O ficheiro voltou mesmo com um site bloqueado
Durante a investigação, uma das instalações afetadas foi temporariamente bloqueada com uma resposta HTTP 403.
Isto impedia o acesso web normal enquanto a análise decorria.
Mesmo assim, posteriormente, o ficheiro rapid-analyzer-edge.php voltou a ser criado nessa instalação.
O sistema de segurança voltou a detetá-lo e neutralizou o conteúdo.
Este episódio foi particularmente importante porque mostrou que bloquear simplesmente o acesso público ao site não bastava para explicar toda a atividade observada.
A partir daí, a investigação teve de considerar também mecanismos de execução ou escrita ao nível da própria conta de alojamento.
Por onde entrou o atacante?
Esta é uma pergunta a que ainda não consigo responder com certeza.
Os logs mostram acessos autenticados ao WordPress antes do upload e ativação de plugins maliciosos.
Existem várias explicações possíveis:
- uma password comprometida;
- uma sessão de autenticação obtida por terceiros;
- uma vulnerabilidade existente num plugin;
- outro mecanismo que permitisse obter privilégios equivalentes.
Durante a investigação encontrei também um plugin antigo e desatualizado com uma vulnerabilidade de segurança relevante e optei por retirá-lo.
Mas encontrar uma vulnerabilidade possível não demonstra que tenha sido esse o ponto de entrada.
Esta distinção foi importante durante toda a investigação: separar o que conseguíamos demonstrar daquilo que continuava a ser apenas uma hipótese.
Como usei o ChatGPT na investigação
Esta foi, para mim, a parte mais interessante de toda a experiência.
O ChatGPT não tinha acesso ao meu servidor. Eu era o intermediário.
Ia fornecendo aquilo que encontrava: capturas de ecrã, ficheiros PHP, resultados do sistema de segurança, pesquisas no gestor de ficheiros, conteúdos do wp-config.php, configurações .user.ini, tabelas da base de dados, utilizadores, consultas SQL e excertos dos logs.
A investigação começou a seguir um ciclo bastante simples:
Mostrar o resultado real
Em vez de descrever genericamente o problema, fornecia o ficheiro, captura de ecrã, log ou resultado concreto.
Testar a hipótese
Antes de alterar ou eliminar alguma coisa, procurávamos evidência de que aquela hipótese fazia sentido.
Uma alteração de cada vez
Depois de cada ação, voltava a verificar o resultado e acrescentava essa informação ao contexto.
Se o código continha o nome de um ZIP, procurávamos exatamente esse ZIP.
Se referia uma determinada opção da base de dados, começávamos por fazer uma consulta apenas de leitura.
Se aparecia um utilizador estranho, verificávamos primeiro a data de criação, permissões e conteúdos associados.
Se um ficheiro tinha um nome suspeito, não era eliminado apenas por causa do nome.
A IA também se enganou
Houve hipóteses que tiveram de ser corrigidas.
Houve momentos em que foi necessário confirmar novamente um nome, um caminho ou perceber que determinado elemento tinha uma função legítima.
Por isso, esta experiência não demonstra que o ChatGPT consiga resolver automaticamente um incidente de cibersegurança.
Mostra outra coisa: uma pessoa sem especialização naquela área pode ter acesso imediato a uma capacidade de análise e orientação que anteriormente seria bastante mais difícil de obter.
O valor aumentava à medida que o contexto aumentava.
Uma pergunta como “o meu WordPress tem um vírus, como resolvo?” teria produzido uma resposta genérica.
Mostrar o ecrã, o ficheiro, o código, os resultados das pesquisas, a base de dados, os logs e o resultado de cada passo transformou a conversa numa investigação progressivamente mais específica.
O que foi feito para conter o incidente
A resposta não consistiu numa única operação. Foi necessário neutralizar os diferentes pontos que podiam manter ou recuperar o código malicioso.
- isolamento de ficheiros maliciosos;
- neutralização dos
advanced-cache.phpcomprometidos; - remoção das cópias conhecidas do Rapid Analyzer Edge;
- neutralização de configurações
.user.inimaliciosas; - remoção de loaders PHP identificados;
- localização e neutralização de ZIPs utilizados para recuperação;
- neutralização de dados maliciosos encontrados nas bases de dados;
- remoção de tarefas maliciosas do WP-Cron;
- validação dos utilizadores com privilégios administrativos;
- invalidação das passwords antigas dos administradores;
- terminação das sessões WordPress administrativas existentes;
- renovação das chaves e salts de autenticação;
- alteração da password principal do cPanel;
- ativação de autenticação de dois fatores;
- eliminação de contas FTP que já não eram necessárias;
- remoção de plugins antigos ou desnecessários;
- bloqueio, por defeito, da instalação e alteração de plugins e temas através do painel WordPress.
Alguns ficheiros foram mantidos em quarentena para preservar elementos da investigação.
Foram cerca de 12 horas de trabalho efetivo.
Como percebi que a contenção tinha resultado
Depois da limpeza, não quis assumir imediatamente que o problema estava resolvido.
Continuei a acompanhar o Imunify360.
Durante a investigação, determinados componentes tinham sido recriados várias vezes e o sistema voltava a detetá-los em tempo real.
A última deteção maliciosa em tempo real num site ativo ocorreu no dia 10 de agosto de 2026 às 11:24.
Mais tarde apareceram novas entradas no histórico, mas correspondiam a novas análises de ficheiros que já tinham sido colocados em quarentena.
Realtime: o sistema detetou atividade associada à criação ou alteração de um ficheiro naquele momento.
Rescan: o sistema voltou a analisar um ficheiro que já existia.
Atualização de 13 de agosto de 2026, às 10:20
Voltei a consultar o histórico do Imunify360.
Continuava sem existir qualquer nova deteção realtime nos dias 11, 12 ou 13 de agosto.
A última deteção em tempo real mantinha-se em 10 de agosto às 11:24.
A ocorrência posterior mais recente continuava a ser um rescan, realizado no próprio dia 10, sobre um ficheiro que já estava numa pasta de quarentena.
Isto representa quase três dias sem que o malware conhecido volte a aparecer em tempo real nos sites ativos.
Isto não permite garantir a inexistência absoluta de qualquer outro vestígio. Permite dizer que os mecanismos identificados foram neutralizados e que o malware conhecido deixou de se reconstruir durante o período de monitorização.
Porque é que isto interessa a quem tem um website?
É fácil imaginar que um atacante esteja interessado apenas em grandes empresas, instituições financeiras ou organizações com informação particularmente sensível.
Mas um website pode ter valor por uma razão muito mais simples:
já conquistou autoridade.
Tem histórico, páginas indexadas, tráfego, backlinks e posições nos motores de pesquisa.
Um domínio bem posicionado pode ser especialmente interessante para operações de SEO spam, porque permite tentar aproveitar a autoridade que outro site já construiu.
Isto ajuda também a perceber porque é que determinados ataques não destroem o site.
Se o objetivo for manter acesso, criar URLs, introduzir conteúdo de spam, colocar links ou fazer redirecionamentos, pode ser mais útil que o proprietário não perceba que existe um problema.
Se encontrou algo estranho no seu site
Alguns sinais que podem justificar uma investigação:
- um administrador WordPress que não reconhece;
- utilizadores criados sem autorização;
- páginas de casino que nunca publicou;
- páginas de conteúdo adulto associadas ao domínio;
- spam relacionado com medicamentos, criptomoedas ou outros temas;
- URLs desconhecidos no Google Search Console;
- URLs rastreados pelo Google que não existem normalmente no WordPress;
- caracteres ilegíveis antes da página normal;
- erros inesperados de cookies no login;
- código estranho ou ofuscado em
advanced-cache.php; - ficheiros PHP desconhecidos dentro de
mu-plugins; .user.inicom umauto_prepend_fileque não reconhece;- plugins que surgiram sem terem sido instalados por si;
- ZIPs desconhecidos dentro do WordPress;
- malware que reaparece depois de ser eliminado;
- deteções repetidas num sistema de segurança.
Nenhum destes sinais, isoladamente, demonstra necessariamente que está perante o mesmo ataque. Mas são motivos suficientes para investigar.
A parte que mais me surpreendeu
A conclusão mais interessante desta experiência não é sobre malware.
É sobre aquilo que uma pessoa consegue fazer com Inteligência Artificial.
Eu não me tornei especialista em cibersegurança durante aquelas 12 horas.
Mas consegui entrar numa área altamente técnica, compreender gradualmente aquilo que estava à minha frente, formular hipóteses, testá-las e executar uma investigação que dificilmente teria conseguido fazer sozinho.
A IA não fez as 12 horas de trabalho por mim. Mas tornou possível que uma pessoa que não é especialista em cibersegurança conseguisse fazê-las.
A IA como biblioteca e mentor
Os especialistas continuam a ser especialistas.
Uma pessoa com anos de experiência em cibersegurança tem conhecimento, prática, ferramentas e capacidade de análise que não são substituídos por uma conversa com um modelo de IA.
Mas existe agora uma diferença importante.
A distância entre “não tenho competências para fazer isto” e “consigo começar a compreender e investigar isto” tornou-se muito mais pequena.
Dizer simplesmente ao ChatGPT “o meu WordPress tem um vírus, resolve” teria produzido, provavelmente, recomendações genéricas.
Mostrar-lhe o que estava no ecrã, depois o ficheiro, depois o código, depois o resultado de uma pesquisa, depois a base de dados, depois o histórico do scanner e, finalmente, os logs transformou completamente a qualidade da investigação.
É aqui que a contextualização se torna determinante.
A IA deixa de trabalhar sobre um problema abstrato e passa a trabalhar sobre aquilo que estamos efetivamente a observar.
Nesse momento, pode funcionar simultaneamente como biblioteca, intérprete técnico e mentor.
A decisão continua a ser nossa.
Mas passamos a ter muito mais capacidade para perceber qual deve ser a pergunta seguinte.
Glossário
Neste artigo aparecem alguns termos técnicos de WordPress e cibersegurança. Se chegou aqui ao clicar numa palavra, a respetiva definição fica destacada. No final, clique em “Voltar ao artigo” para regressar exatamente ao ponto onde estava.
Malware
Software ou código criado para executar ações maliciosas ou não autorizadas. Pode modificar ficheiros, criar acessos, instalar outros componentes, redirecionar utilizadores ou permitir que terceiros mantenham controlo sobre um sistema.
← Voltar ao artigoadvanced-cache.php
Ficheiro que pode ser utilizado legitimamente por sistemas de cache do WordPress. A sua existência não significa, por si só, que exista malware. Neste incidente, determinadas versões tinham sido alteradas e continham código malicioso.
← Voltar ao artigoRapid Analyzer Edge
Nome apresentado por um dos principais componentes maliciosos encontrados durante a investigação. Surgia através do ficheiro rapid-analyzer-edge.php e fazia parte dos mecanismos utilizados para manter e reconstruir o malware.
Persistência
Conjunto de mecanismos utilizados para manter malware ou acesso não autorizado ativo, ou para permitir que volte a aparecer depois de uma tentativa de limpeza.
← Voltar ao artigoMU Plugin
Abreviatura de Must-Use Plugin. É um tipo de plugin carregado automaticamente pelo WordPress e não funciona exatamente como os plugins normais ativados e desativados no painel.
← Voltar ao artigo.user.ini
Ficheiro que permite definir determinadas configurações do PHP para uma pasta ou website. É legítimo, mas pode ser alterado por malware.
← Voltar ao artigoauto_prepend_file
Configuração do PHP que permite executar automaticamente um determinado ficheiro antes do script que foi pedido.
← Voltar ao artigoPayload
Código que executa efetivamente uma determinada ação dentro do ataque. Pode criar ficheiros, instalar componentes, comunicar com um servidor externo ou ajudar a reconstruir malware anteriormente removido.
← Voltar ao artigoWP-Cron
Sistema de tarefas agendadas do WordPress. É utilizado legitimamente pelo WordPress e por plugins, mas também pode ser aproveitado para executar ações maliciosas.
← Voltar ao artigoSEO spam
Utilização não autorizada de um site legítimo para criar, promover ou tentar posicionar páginas, links ou conteúdos sem relação com o projeto original.
← Voltar ao artigoLogs
Registos automáticos de atividade que podem mostrar pedidos feitos ao servidor, horas, endereços IP, códigos de resposta e outros elementos úteis para reconstruir acontecimentos.
← Voltar ao artigoHTTP 403
Código de resposta que indica que o servidor recusou o acesso ao recurso pedido. Durante a investigação foi utilizado para manter temporariamente uma instalação inacessível através da web.
← Voltar ao artigoLoader
Pequeno ficheiro ou componente cuja função é carregar ou executar outro código.
← Voltar ao artigoSessão WordPress
Mecanismo através do qual o WordPress reconhece que um utilizador já iniciou sessão.
← Voltar ao artigoSalts e chaves de autenticação
Valores secretos usados pelo WordPress para reforçar a segurança dos cookies e das sessões. Renovar estes valores invalida sessões existentes.
← Voltar ao artigoAutenticação de dois fatores
Método de segurança que exige uma segunda prova de identidade além da password. É frequentemente identificado pela sigla 2FA.
← Voltar ao artigoQuarentena
Isolar um ficheiro suspeito num local onde deixe de ser executado, preservando-o para análise.
← Voltar ao artigoImunify360
Plataforma de segurança utilizada em serviços de alojamento para detetar atividade suspeita e ficheiros identificados como maliciosos. Neste incidente foi utilizada para acompanhar deteções e limpezas.
← Voltar ao artigo