O que fazer quando o teu site foi pirateado (guia de primeiros socorros)

A chamada chegou às 9:30 da manhã: “O meu site redireciona para uma página que descarrega malware”. O nosso cliente tinha sabido porque um dos seus próprios clientes se tinha queixado. Segundo os logs, o site estava assim há pelo menos 18 horas. Ninguém tinha reparado.

É o cenário típico: descobres o ataque tarde, quando já fez estragos. O que fizeres nas primeiras horas determina a gravidade final do incidente. Este é o protocolo que seguimos, por ordem de prioridade (e aqui tens um caso completo do princípio ao fim).

Fase 1: contenção imediata (primeiros 30 minutos)

O objetivo é evitar mais danos. Não penses ainda em reparar; pensa em estancar a hemorragia.

1. Põe o site em modo de manutenção ou desliga-o.

Se tens acesso ao painel de administração do WordPress ou ao painel do alojamento, ativa o modo de manutenção; se não, pede ao teu fornecedor de alojamento que suspenda temporariamente a conta. Assim proteges as visitas e impedes que o atacante continue a usar o teu servidor.

Outra opção é apontar o DNS para uma página estática de manutenção noutro servidor, deixando isolado o servidor comprometido.

2. Guarda uma cópia do site comprometido.

Antes de apagar ou restaurar o que quer que seja, descarrega os ficheiros, a base de dados e os logs, e guarda-os à parte. São a prova do que aconteceu: vais precisar deles para encontrar o ponto de entrada e para justificar o que fizeste. Muitos fornecedores de alojamento apagam os logs ao fim de poucos dias.

3. Muda todas as palavras-passe.

Administrador do WordPress, alojamento, FTP, base de dados e email associado ao domínio. Parte do princípio de que estão todas comprometidas. Fá-lo a partir de um computador que saibas que está limpo e usa palavras-passe aleatórias de 20 caracteres ou mais, geradas com um gestor. Se a tua equipa falha neste ponto, revê o mínimo sobre palavras-passe, 2FA e gestores.

4. Termina as sessões ativas.

No WordPress, termina as sessões a partir do perfil de cada utilizador e gera de novo as chaves de segurança (salts) do wp-config.php, o que obriga toda a gente a voltar a iniciar sessão. Assim expulsas qualquer atacante que ainda esteja lá dentro.

5. Avisa as pessoas-chave.

A direção, o encarregado de proteção de dados ou o responsável jurídico (se houver dados pessoais em jogo) e, se for o caso, os clientes-chave expostos. Comunicar cedo, mesmo de forma incompleta, é melhor do que o silêncio.

Fase 2: avaliação dos danos (primeiras 4 horas)

Com o site isolado, é altura de perceber o que aconteceu e até onde vai o problema.

Analisa os logs de acesso.

Procura pedidos suspeitos: POST para ficheiros que não deviam receber envios, acessos ao wp-admin a partir de IP estranhos, pedidos com padrões de injeção SQL ou XSS. Procura especialmente:

• Ficheiros PHP carregados na pasta de uploads.
• Pedidos a ficheiros que antes não existiam (portas traseiras com nomes aleatórios).
• Acessos bem-sucedidos ao wp-admin a partir de locais onde a tua equipa não pode estar.

Identifica o vetor de entrada.

Por onde entraram? As vias mais habituais são:

• Um plugin ou tema desatualizado com uma vulnerabilidade conhecida.
• Uma palavra-passe fraca, ou reutilizada e divulgada numa fuga de outro serviço.
• Credenciais de FTP comprometidas.
• Injeção SQL num formulário vulnerável.
• Um ataque à cadeia de fornecimento: um plugin legítimo comprometido na origem.

Identificar o vetor é crítico, porque determina o que é preciso corrigir para evitar uma reinfeção, e diz-te desde quando estás comprometido, algo fundamental para escolher que cópia restaurar.

Avalia que dados ficaram expostos.

Acederam à base de dados de clientes? Exportaram-na? Instalaram alguma coisa para capturar o que se escreve nos formulários? Modificaram ficheiros do núcleo? As respostas determinam se tens obrigações de notificação nos termos do RGPD e o que deves comunicar aos afetados. Revê também os serviços ligados (CRM, email, gateway de pagamento) e onde ficam realmente guardados os dados dos teus clientes.

Fase 3: limpeza e recuperação (do dia 1 ao 3)

Não tentes “limpar” o site comprometido e continuar a usá-lo. Os atacantes costumam deixar várias portas traseiras e é muito difícil garantir que as encontraste todas.

A regra de ouro: reconstruir, não limpar.

1. Parte de uma cópia limpa.

Restaura uma cópia anterior à intrusão (não à deteção: o atacante pode estar lá dentro há semanas) e corrige a vulnerabilidade antes de a publicar. Se não tens nenhuma cópia limpa, o problema é maior, mas é possível reconstruir à mão:

• Instalação limpa do WordPress (ou do CMS que usares).
• Plugins acabados de descarregar dos repositórios oficiais, nunca copiados do servidor comprometido.
• O mesmo para os temas.
• Base de dados revista tabela a tabela antes de a importar.

2. Audita a base de dados.

No WordPress, procura:

• Utilizadores com função de administrador que não reconheces.
• Registos da tabela wp_options com nomes suspeitos ou valores codificados em base64.
• Rascunhos ou artigos privados que contêm código (scripts, iframes).
• Tabelas adicionais que não pertencem ao núcleo nem a plugins conhecidos.

3. Verifica os ficheiros.

Compara os ficheiros do núcleo com os originais de wordpress.org: qualquer diferença é suspeita. Com o WP-CLI, o comando “wp core verify-checksums” faz isto em segundos, e plugins de segurança como o Wordfence ou o Sucuri também o fazem de forma automática.

4. Mantém o site offline até verificares tudo.

Não o voltes a abrir ao público até teres a certeza de que está limpo. Um site que volta a cair logo depois de ser publicado é pior do que mais umas horas offline.

Fase 4: fechar a porta (do dia 3 ao 7)

O site está limpo. Agora é preciso evitar que volte a acontecer.

1. Atualiza tudo.

Núcleo, plugins e temas. Elimina os plugins de que não precisas: cada plugin é uma possível superfície de ataque.

2. Reforça o acesso.

• Verificação em 2 passos obrigatória para todos os administradores.
• Limite de tentativas de início de sessão (com plugins como o Limit Login Attempts Reloaded).
• Mudar o URL de acesso ao wp-admin: é segurança por obscuridade, mas reduz o ruído dos bots.
• Restringir o acesso ao painel a IP concretos se a tua equipa for pequena e trabalhar a partir de locais fixos.

3. Firewall e monitorização.

Instala uma WAF (firewall de aplicações web) como Cloudflare, Sucuri ou Wordfence. E ativa alertas que te avisem se os ficheiros do núcleo mudarem.

4. Cópias de segurança automáticas e fora do servidor.

Programa cópias diárias fora do servidor (Google Drive, Dropbox, Amazon S3) e experimenta restaurá-las de vez em quando: uma cópia corrompida é tão inútil como não ter nenhuma.

5. Analisa e documenta.

Redige um relatório do incidente: o que aconteceu, como entraram, como foi detetado, quanto tempo se demorou a responder e que lições tiraste. Serve para prevenir futuros incidentes e faz parte do que o RGPD te obriga a documentar.

Implicações legais e de notificação

Se o incidente afetar dados pessoais de clientes ou visitantes:

RGPD. A violação deve ser notificada à autoridade de controlo (em Espanha, a Agencia Española de Protección de Datos, AEPD; em Portugal, a CNPD) sem demora injustificada e, sempre que possível, no prazo máximo de 72 horas depois de teres tido conhecimento dela (se for notificada mais tarde, é preciso justificar o atraso), salvo se for improvável que resulte num risco para as pessoas afetadas. Se o risco for elevado, também tens de a comunicar a essas pessoas. E mesmo que concluas que não é preciso notificar, tens de deixar registada a violação e o motivo dessa decisão.

Clientes empresariais. Se o teu site é B2B, avisa os clientes que possam ter ficado expostos: a transparência atempada protege mais a relação do que escondê-lo.

Aconselhamento e ajuda. Em incidentes importantes, procura aconselhamento jurídico especializado. Em Espanha, o INCIBE oferece ainda ajuda gratuita em cibersegurança através do 017, e se houver extorsão ou roubo de dados, pondera apresentar queixa.

Perguntas frequentes

Como sei se o meu site foi pirateado?

Sinais habituais: redirecionamentos para sites estranhos, conteúdo que não criaste, lentidão extrema, ficheiros desconhecidos, avisos do Google Safe Browsing ou alertas do teu fornecedor de alojamento. Para o detetar a tempo, consulta o relatório de problemas de segurança da Search Console e passa um analisador de malware.

Devo pagar se me pedirem um resgate?

Em geral, não. Não há garantia de que recebas a chave para recuperar os teus dados, e pagar pode marcar-te como alvo de futuros ataques. Restaura a partir de uma cópia de segurança. Se não a tens, essa é a lição para a próxima vez.

Quanto tempo demora a recuperar de um ataque?

Com uma cópia limpa, de umas horas a um dia. Sem cópia, de dias a semanas a reconstruir à mão, mais o tempo de confirmar que está tudo limpo. A prevenção sai muitíssimo mais barata.

O meu fornecedor de alojamento é responsável?

Normalmente não, a não ser que a vulnerabilidade estivesse na infraestrutura dele. A maioria dos ataques é responsabilidade do proprietário do site (plugins desatualizados, palavras-passe fracas). Revê o teu contrato e, se fores assinar um, inclui estas cláusulas técnicas.

Conclusão

Um ataque informático é stressante, mas não tem de ser catastrófico. A diferença entre um incidente menor e um desastre é a preparação: cópias de segurança que funcionam, um plano de resposta e rapidez de reação.

O momento de pensar em segurança é antes do ataque. Mas se já estás no meio de um, este protocolo ajuda-te a agir com método e não em pânico.

Se o teu site foi comprometido e precisas de ajuda urgente para o recuperar, na Baqueiro podemos ajudar-te. Mas atenção: depois de recuperado, vamos dedicar tempo a evitar que volte a acontecer. Um ataque pode ser azar; que se repita costuma ser falta de prevenção. Escreve-nos e vemos isso o quanto antes.