O meu site foi hackeado: o que fazer, passo a passo

Descobrir que o site foi hackeado é desagradável, mas na maioria dos casos é recuperável. O que mais conta é agir por ordem e com calma: primeiro conter o problema, depois limpar, e só no fim reforçar a segurança para não se repetir.

Como perceber que o site foi hackeado

Os sinais mais comuns são:

• O Google mostra o aviso "Este site pode ter sido pirateado" ou "Site enganoso" nos resultados, ou o browser bloqueia o acesso.
• O site redireciona os visitantes para páginas estranhas, sobretudo a partir do telemóvel ou de resultados do Google.
• Aparecem páginas, links ou texto que não criou (medicamentos, apostas, produtos de marcas falsas).
• O alojamento suspendeu o site ou avisou de envio de spam.
• Há utilizadores administradores que não reconhece, ou não consegue entrar com a sua password.
• O site ficou subitamente muito lento, ou o servidor está sempre com o processador no máximo.

Nem todos os ataques se veem

Muitos ataques modernos são discretos de propósito, para durarem meses sem ninguém dar por eles:

• Ataques que escrevem diretamente na base de dados. Em vez de alterarem ficheiros, o atacante injeta código ou conteúdo nos artigos, nas páginas ou nas opções do site. A verificação de ficheiros pode dar tudo limpo, e nenhum ficheiro aparece como infetado, mas o site continua comprometido. Restaurar só os ficheiros não resolve.
• Hacks que não desconfiguram o site. O site continua com o aspeto normal para si e para os visitantes. O que muda é a informação que os motores de busca veem: títulos, descrições e texto que aparecem nos resultados do Google, para desviar o tráfego do seu site para outros endereços (SEO spam, muitas vezes de medicamentos, apostas ou produtos falsificados).
• Conteúdo diferente consoante quem vê. O site mostra uma coisa a si e outra ao Googlebot ou aos visitantes que chegam pelo Google (cloaking). Só quem clica no resultado do Google é redirecionado.

Se o tráfego do site caiu sem razão, se aparecem no Google títulos ou descrições que não escreveu, ou se há páginas estranhas indexadas, suspeite de um ataque destes mesmo que o site "pareça normal".

1. Não entre em pânico e não apague nada

Apagar tudo à pressa destrói as provas de como o atacante entrou, e sem isso é fácil ser reinfetado no dia seguinte. Antes de mexer, faça uma cópia do estado atual (ficheiros e base de dados) e guarde-a à parte. Mesmo infetada, ajuda a perceber o que aconteceu.

2. Limite os danos

• Ponha o site em manutenção ou bloqueie o acesso público, para não infetar visitantes nem piorar a reputação junto do Google.
• Avise o seu fornecedor de alojamento. Pode ajudar a identificar a origem e a verificar se outros sites na mesma conta foram afetados.
• Se o site guarda dados pessoais (loja, área de clientes, registos), veja o ponto sobre RGPD mais abaixo.

3. Mude todas as passwords

Faça-o a partir de um computador que sabe estar limpo. Altere:

• Utilizadores do painel de administração do site (WordPress ou outro).
• Acesso ao painel do alojamento.
• Utilizadores de SFTP/FTP e de SSH.
• Password da base de dados (e atualize-a no ficheiro de configuração do site).
• Contas de email associadas ao domínio.

Se o site é WordPress, invalide também as chaves de sessão em wp-config.php (as constantes AUTH_KEY, SECURE_AUTH_KEY, etc.), o que termina todas as sessões abertas, incluindo a do atacante.

4. Descubra o que foi alterado

Antes de limpar, perceba a extensão do problema. Em WordPress, o WP-CLI ajuda muito. Este comando compara os ficheiros do WordPress com os originais e mostra o que foi modificado ou acrescentado:

wp core verify-checksums

Depois verifique, manualmente:

• Diretorias estranhas. Reveja as pastas na raiz do site e dentro de wp-content, wp-content/uploads e wp-includes. Pastas com nomes aleatórios, ou que não fazem parte do WordPress, são muito suspeitas.
• O ficheiro .htaccess. Confirme que só tem as regras que conhece. É onde os redirecionamentos maliciosos são frequentes.
• Os ficheiros index.php. Comece pelo da raiz do site: o original é muito curto. Verifique também os que existem dentro de wp-content. Código longo, ilegível ou com eval e base64_decode é sinal de infeção.
• Utilizadores administradores criados sem o seu conhecimento. Com o WP-CLI: wp user list --role=administrator. Apague os que não reconhece.
• Ficheiros PHP em pastas onde não devia haver, como wp-content/uploads.
• Plugins e temas que não instalou, ou que estão desatualizados há muito tempo (normalmente é por aí que entram).

Verifique a base de dados

Como alguns ataques só escrevem na base de dados e não deixam ficheiros infetados, uma verificação limpa dos ficheiros não chega. Com o WP-CLI pode procurar código suspeito em todas as tabelas:

wp db search "<script" --all-tables
wp db search "<iframe" --all-tables
wp db search "eval(" --all-tables

Confirme também as opções básicas do site e os utilizadores:

wp option get siteurl
wp option get home
wp user list --role=administrator

Reveja artigos e páginas com texto ou links que não escreveu (procure também texto escondido no fim do conteúdo), os widgets, as opções do tema e as listas de plugins ativos. Alguns resultados são legítimos (por exemplo, scripts de analítica que instalou), por isso avalie cada um.

Veja o que o Google vê

• Pesquise site:o-seu-dominio.pt no Google e veja se há páginas, títulos ou descrições que não reconhece.
• No Google Search Console, veja os relatórios de segurança, de páginas indexadas e de desempenho (quedas ou picos estranhos de tráfego e pesquisas que não fazem sentido para o seu negócio).
• Veja o site como o Googlebot e como quem vem do Google. Com o curl pode simular ambos e comparar com o que vê normalmente:

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://o-seu-dominio.pt/ | head -50
curl -s -e "https://www.google.com/" https://o-seu-dominio.pt/ | head -50

Se o resultado for diferente do que vê no browser, o site tem cloaking. Faça o teste com a cache desativada, para não receber sempre a mesma página.

Descubra quando foi a infeção

Veja as datas de alteração dos ficheiros comprometidos. Em SSH, por exemplo, lista os ficheiros PHP alterados nos últimos 30 dias, do mais recente para o mais antigo:

find . -name "*.php" -mtime -30 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort -r

A data do ficheiro comprometido mais antigo indica, aproximadamente, o dia em que o atacante entrou. Anote-a: vai precisar dela para escolher a cópia de segurança. Tenha em conta que um atacante pode alterar as datas dos ficheiros, por isso use isto como pista e não como certeza.

Procure outros ataques

Corra uma ferramenta de análise de malware sobre todo o site, para encontrar mais do que aquilo que já viu. Num servidor com Linux pode usar o Maldet ou o ClamAV. Em WordPress, um plugin de segurança com análise de ficheiros também ajuda. Nenhuma ferramenta encontra tudo: o resultado limpo não garante que o site está limpo.

5. Reponha o site a partir de uma cópia que saiba que está boa

Esta é, de longe, a melhor solução. Limpar manualmente é difícil de garantir, porque o atacante costuma deixar várias portas dos fundos (backdoors) escondidas em sítios que não vai ver.

1. Restaure uma cópia anterior à infeção. Use a data que encontrou no passo anterior e escolha um backup anterior a ela. Se tiver dúvidas, recue mais. Restaure também a base de dados: se o ataque escreveu diretamente na base de dados, só os ficheiros limpos não chegam.
2. Ou reinstale de raiz. Instale um WordPress limpo, reinstale os plugins e temas a partir de fontes oficiais e só traga do site antigo o conteúdo (a pasta uploads depois de verificada e, com cuidado, os artigos e as páginas). Se importar a base de dados inteira, reveja-a antes com as pesquisas do passo 4, porque pode trazer o código injetado. Nunca copie ficheiros PHP do site infetado.
3. Só em último caso, limpe manualmente. Reponha os ficheiros base com wp core download --skip-content --force, apague as pastas e ficheiros desconhecidos, e remova utilizadores suspeitos. Só é aceitável se tiver a certeza de ter encontrado tudo.

Logo a seguir a restaurar, atualize tudo (passo seguinte): a vulnerabilidade que foi explorada continua no site restaurado, e o atacante pode voltar a entrar.

Nunca reutilize plugins ou temas "crackeados" ou de origem duvidosa: são uma das causas mais frequentes de infeção.

6. Atualize tudo e mude as passwords outra vez

wp core update
wp plugin update --all
wp theme update --all

Apague os plugins e temas que não usa, mesmo desativados. O que não está instalado não pode ser explorado.

Depois de o site estar limpo, mude de novo as passwords do backoffice (administradores, painel de alojamento, SFTP/SSH e base de dados). As anteriores podem ter sido guardadas pelo atacante enquanto o site esteve infetado.

7. Peça ao Google para reavaliar o site

Se o Google marcou o site como perigoso, depois de limpar peça uma revisão no Google Search Console, na secção "Problemas de segurança". A revisão costuma demorar de algumas horas a alguns dias. Verifique também se apareceram páginas de spam indexadas e peça a sua remoção.

8. Reforce a segurança para não voltar a acontecer

Depois de resolver, estude que medidas pode acrescentar:

• Atualizações regulares do WordPress, dos temas e dos plugins.
• Passwords fortes e únicas, e autenticação de dois fatores para os administradores.
• Menos plugins: cada um é uma possível porta de entrada.
• Backups automáticos guardados fora do servidor, e testados. É isto que lhe permite recuperar depressa da próxima vez.
• Um utilizador por pessoa, com as permissões mínimas necessárias.
• Firewall e monitorização no servidor. Se tem uma VPS, veja o artigo sobre o Netfilter.
• Alojamento com isolamento entre sites, para que um site infetado não contamine os outros.

Vale a pena mudar de plataforma?

Se o site é sobretudo informativo (institucional, portfólio, blog) e o conteúdo muda pouco, talvez o WordPress seja mais do que precisa. Um site em HTML estático não tem base de dados, nem PHP, nem plugins para explorar, e por isso tem uma superfície de ataque muito menor. Foi o caminho que seguimos no nosso site. Leia Site em WordPress ou em HTML? para perceber quando faz sentido. Se precisa de loja ou de funcionalidades dinâmicas, avalie outra plataforma mais segura ou uma solução à medida, em vez de continuar a acumular plugins.

Dados pessoais e RGPD

Na maioria dos sites pequenos (institucionais, portfólios, blogs) não há dados pessoais guardados, e este ponto não se aplica. Mas se o seu site tem loja online, área de clientes, registo de utilizadores ou formulários que guardam informação, deve ter atenção: se houve acesso a dados pessoais, a violação pode ter de ser comunicada à CNPD e, em certos casos, aos titulares dos dados, no prazo de 72 horas após tomar conhecimento. Nesse caso, procure aconselhamento adequado.

Quando pedir ajuda

Se não tem a certeza de ter limpo tudo, se o site é essencial para o negócio, ou se o problema volta a aparecer, é melhor pedir ajuda do que limpar às cegas. Uma limpeza incompleta só adia o problema.

O seu site foi hackeado ou suspeita que sim? Fale connosco — analisamos o caso sem compromisso.

Artigos relacionados

• WP-CLI: comandos essenciais para gerir o WordPress por SSH
• Como instalar o Maldet
• Netfilter — o firewall que protege a maioria dos servidores Linux
• Site em WordPress ou em HTML? A resposta já não é simples