Em resumo: se quer mandar remover malware do seu site, apagar alguns ficheiros raramente basta. Preservamos primeiro o que foi encontrado, procuramos webshells, backdoors e tarefas ocultas, reconstruímos a partir de fontes fiáveis e fechamos a porta de entrada. Só então a limpeza é fiável.
Como reconhecer malware num site
O código malicioso em sites só se nota muitas vezes de forma indireta. São típicos os redirecionamentos para páginas alheias, conteúdos de spam visíveis apenas para os motores de pesquisa ou para dispositivos móveis, um aviso do Google nos resultados de pesquisa, queixas de clientes ou um bloqueio do fornecedor de alojamento por envio de spam. No servidor, surgem ficheiros PHP desconhecidos, contas de administrador novas, ficheiros .htaccess alterados ou cronjobs inexplicáveis.
Depois do PHP2Shell, junta-se mais uma preocupação: através da CVE-2026-109618 e da CVE-2026-109619, os atacantes podem executar código sem autenticação. Não existem indicadores de compromisso (IOCs) confirmados e publicados; a deteção assenta na análise de comportamento. Como são tipicamente as webshells e onde se encontram, descreve-o Reconhecer e remover webshells.
Remover malware de um site: porque é mais importante ser rigoroso do que rápido
Os atacantes raramente deixam apenas um ficheiro. O habitual são várias backdoors em locais diferentes: em pastas de uploads, em plugins ou temas, em plugins must-use, na base de dados, em cronjobs ou em contas de utilizador adicionais. Se só se apagar o ficheiro mais vistoso, o código malicioso volta.
Ao mesmo tempo, o estado infetado é um meio de prova. Quem limpa precipitadamente perde a possibilidade de apurar se dados de clientes foram afetados. Por isso, preservamos antes de qualquer alteração. Isso custa pouco tempo e mantém-lhe todos os caminhos abertos, incluindo uma posterior notificação à autoridade de controlo ou à seguradora.
Uma atualização do PHP ou do CMS não remove software malicioso que já esteja no servidor. E um site limpo é infetado de novo enquanto a porta de entrada estiver aberta.
Onde o código malicioso tipicamente se esconde
Os locais seguintes verificamo-los em cada limpeza, porque, na prática, são afetados vezes sem conta:
| Local | Achado típico |
|---|---|
| Pasta de uploads | ficheiros PHP com nomes de aparência inofensiva ou disfarçados de imagem |
| Plugins, temas, módulos | ficheiros adicionais ou ficheiros originais alterados |
| Configuração | linhas introduzidas em .htaccess, .user.ini ou ficheiros de entrada |
| Base de dados | contas de administrador estranhas, scripts em conteúdos ou opções |
| Sistema | cronjobs, chaves SSH adicionais, processos sem finalidade reconhecível |
| Caches e pastas temporárias | cópias de código malicioso que reaparecem depois de apagadas |
O que importa é o conjunto: um achado isolado raramente explica todo o incidente. Só o quadro completo mostra como o atacante procedeu e se levou credenciais.
Como ajuda concretamente a PHP SOS?
- Preservar: criamos uma cópia de ficheiros, base de dados e registos no estado infetado. Fica guardada para uma análise posterior.
- Procurar: comparamos os ficheiros do programa com os originais do fabricante, verificamos nas pastas de uploads a presença de código executável, examinamos a base de dados, os cronjobs, as contas de utilizador e a configuração do servidor. Para ambientes WordPress, procedemos como descrito em Encontrar backdoors no WordPress.
- Limpar: reinstalamos o núcleo, as extensões e os temas a partir de fontes fiáveis, em vez de remendar ficheiros suspeitos um a um. Os conteúdos próprios e os uploads verificamo-los em separado e só aproveitamos o que for inofensivo.
- Fechar a causa: aplicamos patches ao PHP e à aplicação, removemos contas estranhas e substituímos todas as credenciais e chaves que o atacante possa ter visto.
- Controlo posterior: observamos o site depois da limpeza quanto a novas alterações e apoiamo-lo para que um aviso do Google seja reavaliado através do Search Console. Mais informação em Remover o aviso do Google.
Para os administradores, uma primeira consulta inofensiva aos ficheiros PHP alterados recentemente:
# ficheiros PHP no diretório web alterados nos últimos 10 dias
find /var/www -type f -name "*.php" -mtime -10 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort
O resultado é um indício, não uma prova: os atacantes podem alterar as marcas temporais.
O que recebe e o que precisamos
Recebe um relatório com os componentes maliciosos encontrados e o local onde estavam, as medidas de limpeza, a lista das credenciais substituídas e a provável porta de entrada. Separamos claramente o que está comprovado, o que é provável e o que é desconhecido.
Precisamos de si:
- acesso ao servidor ou ao painel de alojamento, ao backend do CMS e à base de dados
- um interlocutor que possa autorizar alterações de palavras-passe e desligamentos
- informações sobre a agência, o programador ou o fornecedor de alojamento e sobre personalizações do sistema
- cópias de segurança existentes, com data, para podermos avaliar que estado poderá estar limpo
- acesso ao Google Search Console, se for apresentado um aviso
O que não prometemos
Não prometemos que todas as backdoors de todos os sistemas sejam encontradas com certeza, se faltarem registos ou a infeção remontar a muito tempo atrás. Em caso de situação pouco clara, recomendamos a reconstrução num servidor novo, para o qual só são transferidos conteúdos verificados. É mais trabalhoso, mas muitas vezes o caminho mais fiável. Também não prevemos quando o Google ou outros serviços removerão um aviso; isso é decidido por esses fornecedores.
Se for necessário esclarecer, com valor probatório em tribunal, o que aconteceu exatamente e que dados foram afetados, recorremos à perícia forense informática com parceiros especializados. Num ataque agudo e ainda em curso, o trabalho começa com a assistência de emergência para sites comprometidos.
Perguntas frequentes
Um plugin de análise de malware chega para limpar o meu site?
Um analisador encontra padrões conhecidos, mas não todas as backdoors. As webshells são muitas vezes ofuscadas, estão em imagens, caches ou na base de dados, ou estão ancoradas num cronjob. Um analisador é uma ferramenta de apoio, não uma limpeza completa.
Posso simplesmente repor uma cópia de segurança antiga?
Só se for seguro que a cópia foi feita antes da intrusão e se a porta de entrada for fechada depois. Caso contrário, o site fica limpo por pouco tempo e é infetado de novo pelo mesmo caminho.
Porque é que o malware volta a aparecer depois de o apagar?
Na maioria das vezes há uma segunda backdoor, um cronjob, uma conta de administrador manipulada ou a vulnerabilidade continua aberta. Só quando todos os mecanismos de persistência forem encontrados e a causa eliminada é que a limpeza se mantém.
Uma atualização do PHP remove o malware existente?
Não. Um patch fecha a vulnerabilidade, mas não remove software malicioso já introduzido. São dois passos de trabalho distintos.