# O que fazer quando o teu site foi pirateado (guia de primeiros socorros) Source: https://baqueiro.es/pt/seguridad-y-juridico/site-pirateado-o-que-fazer/ Published: 2026-08-26T07:03:00+00:00 Updated: 2026-08-26T07:03:00+00:00 Author: Baqueiro Desarrollo Web Language: pt-PT Usage: Attribution required: quoting allowed with a visible link back --- **TL;DR** - O primeiro passo é estancar a hemorragia: isolar o site para evitar mais danos e proteger as visitas. - Recuperar exige saber o que aconteceu, reconstruir a partir de uma base limpa e fechar a porta por onde entraram. - Documentar tudo durante o incidente é fundamental, tanto para a recuperação como para as tuas obrigações legais. 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](https://baqueiro.es/pt/cyberseguridad/caso-estudo-pirateado-seguro-12-horas/)). ## 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](https://baqueiro.es/pt/seguridad-y-juridico/palavras-passe-2fa-gestores-seguranca-equipa/). **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](https://baqueiro.es/pt/seguridad-y-juridico/onde-ficam-dados-clientes-fornecedor-web/). ## 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](https://baqueiro.es/pt/seguridad-y-juridico/clausulas-tecnicas-contrato-desenvolvimento/). ## 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](https://baqueiro.es/pt/contacto/).