# Como restaurar site hackeado com backup em 7 passos seguros

<strong>Restaurar site hackeado com backup</strong> só funciona se o backup for anterior à invasão e o ambiente for limpo antes do upload. Segundo o <a href="https://radar.cloudflare.com/security/application-layer">Cloudflare Radar</a> (2026), 82,4% dos ataques de aplicação no Brasil são DDoS. Um backup infectado reintroduz o malware em minutos. Restaure, isole a causa e só então recoloque o site no ar.

Restaurar site hackeado com backup é o processo de devolver um WordPress comprometido a um ponto íntegro anterior à invasão, usando uma cópia confiável de arquivos e banco de dados. A ordem importa: trocar credenciais, identificar a porta de entrada e validar a data do backup vêm antes de qualquer upload. Pular essas etapas reinfecta o site, porque o backup pode conter o mesmo backdoor que abriu a brecha. Este guia mostra o caminho técnico completo, com dados reais de <a href="https://full.services/seguranca-wordpress/">segurança WordPress da FULL</a> e CVEs catalogados, para você recuperar o site sem repetir o ataque na semana seguinte.

---

## Diagnóstico rápido: Quando restaurar site hackeado com backup resolve

Restaurar site hackeado com backup resolve na maior parte dos incidentes, mas só quando existe uma cópia anterior à data da invasão, com pelo menos 15 a 30 dias de margem. O problema raro é não ter backup; o comum é restaurar um backup que já está infectado.

A tabela abaixo cruza o sintoma visível com a causa raiz e a ação correta, para você decidir em minutos se a restauração basta ou se precisa de limpeza manual antes.

<p class="wp-caption-text">Legenda: o diagnóstico correto define se o backup resolve sozinho ou se a limpeza precede a restauração.</p>

<table id="diagnostico-site-hackeado">
  <caption>Restaurar site hackeado com backup: sintoma, causa e ação</caption>
  <thead>
    <tr>
      <th scope="col">Sintoma</th>
      <th scope="col">Causa raiz provável</th>
      <th scope="col">Ação corretiva</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Redirecionamento para site externo</th>
      <td>Injeção em wp-config ou .htaccess</td>
      <td>Restaurar backup limpo e trocar chaves de salt</td>
    </tr>
    <tr>
      <th scope="row">Arquivos PHP estranhos em uploads</th>
      <td>Backdoor enviado por plugin vulnerável</td>
      <td>Limpar manualmente antes de restaurar</td>
    </tr>
    <tr>
      <th scope="row">Aviso de malware no Google</th>
      <td>Spam de conteúdo (pharma hack)</td>
      <td>Restaurar, limpar banco e pedir revisão</td>
    </tr>
    <tr>
      <th scope="row">Usuário admin desconhecido</th>
      <td>Credencial vazada ou força bruta</td>
      <td>Trocar senhas e restaurar de ponto seguro</td>
    </tr>
  </tbody>
</table>

Se o sintoma é redirecionamento ou usuário fantasma, restaurar site hackeado com backup costuma bastar. Se há arquivos PHP injetados em `wp-content/uploads`, a limpeza vem primeiro, como detalha o guia de <a href="https://full.services/como-remover-malware-do-wordpress/">remover malware do WordPress</a>.

---

## Por que um backup infectado reintroduz o ataque

Um backup infectado reintroduz o ataque porque preserva o backdoor junto com o conteúdo legítimo, e o malware volta a executar em segundos assim que o site sobe. Esse é o erro número um nos chamados de recuperação: a maioria dos casos que voltam ao suporte da FULL tinha um backup posterior à invasão.

O <a href="https://full.services/glossario/malware-wordpress/">malware</a> moderno injeta código em mais de um arquivo, então um único ponto de restauração nem sempre limpa tudo. Restaurar site hackeado com backup exige checar a integridade da cópia, não só a data.

A janela de comprometimento é o detalhe que mais engana. Muitos sites são invadidos semanas antes do sintoma aparecer, então o backup de "ontem" já nasce contaminado. Por isso a regra prática é restaurar de um ponto com pelo menos 15 a 30 dias de margem antes do primeiro sinal, e cruzar essa data com os logs de acesso. Restaurar site hackeado com backup sem checar a linha do tempo é como trocar a fechadura com o ladrão ainda dentro de casa.

---

## Dados reais de CVE: Por onde o ataque entrou

Boa parte das invasões de WordPress entra por uma vulnerabilidade conhecida de plugin, não por uma falha do core. O UpdraftPlus registrou a CVE-2024-10957, com <a href="https://full.services/glossario/cve/">CVSS</a> 8.8, que afetava versões abaixo da 1.24.12 e permitia execução de objeto PHP por usuário sem privilégio.

Segundo o perfil público do WPVulnerability, essa falha já está corrigida, então o risco atual do plugin é baixo, mas ela mostra por que restaurar sem atualizar repete o ciclo de invasão.

No campo de segurança, o histórico do All in One Security inclui a CVE-2016-10887, com CVSS 9.8 (crítica), em versões anteriores à 4.0.9. Todas essas falhas já têm patch, e um plugin com muitos CVEs corrigidos é sinal de auditoria ativa, não de fragilidade. A FULL é a única empresa brasileira reconhecida como CVE Numbering Authority (CNA) sob a CISA desde maio de 2022, ou seja, cataloga IDs de CVE oficiais. Você pode consultar cada falha na fonte primária, o <a href="https://nvd.nist.gov/vuln/detail/CVE-2024-10957" rel="noopener" target="_blank">registro CVE-2024-10957 no NVD</a>, antes de subir qualquer versão de plugin.

---

## Passo a passo: Como restaurar site hackeado com backup

Restaurar site hackeado com backup com segurança leva de 30 a 90 minutos e segue sete etapas em ordem fixa: isolar, trocar credenciais, achar a entrada, escolher o ponto certo, restaurar, atualizar e validar. Pular a ordem é o que causa reinfecção. Cada passo abaixo é um movimento técnico concreto, não um conselho genérico, e usa ferramentas reais como UpdraftPlus, All in One Security, Wordfence e o gerenciador de arquivos do servidor.

### Passo 1: Isole o site e tire-o do ar

Coloque o site em modo de manutenção ou bloqueie o acesso externo antes de qualquer ação, para impedir que o atacante reaja durante a recuperação. Em servidores Apache, uma regra no `.htaccess` liberando só o seu IP corta o tráfego em segundos. Isolar primeiro evita que o malware se espalhe para outros sites na mesma conta de hospedagem, cenário comum em ambientes compartilhados sem isolamento de processo.

### Passo 2: Troque todas as credenciais de acesso

Altere senhas de admin do WordPress, banco de dados, FTP/SFTP e painel de hospedagem antes de restaurar, porque credenciais vazadas são a porta mais reaberta após uma limpeza. Gere as chaves de segurança novas no <a href="https://full.services/glossario/wp-config/">wp-config.php</a> usando o gerador oficial do WordPress, o que invalida todas as sessões ativas, inclusive a do invasor. Sem essa troca, restaurar site hackeado com backup só adia o próximo acesso indevido.

### Passo 3: Identifique a porta de entrada

Verifique nos logs de acesso a data e o vetor da invasão antes de escolher o ponto de restauração, cruzando horários suspeitos com plugins desatualizados. Um plugin com CVE conhecida, como mostramos acima, costuma ser o ponto de partida. Identificar a entrada define quão atrás no tempo o backup precisa estar e evita restaurar para um ponto que já estava comprometido sem você perceber.

### Passo 4: Escolha o ponto de backup correto

Selecione um backup com margem de 15 a 30 dias antes do primeiro sintoma, e confirme que ele inclui arquivos e banco de dados completos. No UpdraftPlus, a aba de restauração lista cada ponto com data e tamanho; prefira o mais recente que ainda seja anterior à janela de invasão. Restaurar site hackeado com backup do dia anterior ao alerta é a escolha que mais reinfecta, porque ignora a janela silenciosa do ataque.

### Passo 5: Restaure arquivos e banco de dados

Execute a restauração completa pelo plugin de backup ou pelo gerenciador de arquivos, sobrescrevendo `wp-content`, `wp-admin`, `wp-includes` e importando o dump SQL. No UpdraftPlus, marque os cinco componentes (plugins, temas, uploads, outros e banco) para uma restauração íntegra. Em sites grandes, fazer o upload por SFTP é mais estável que pelo navegador, que pode estourar o tempo limite do PHP em arquivos acima de 256 MB.

### Passo 6: Atualize Core, plugins e temas

Atualize o WordPress, todos os plugins e o tema imediatamente após a restauração, fechando a CVE que abriu a brecha original. Restaurar para uma versão antiga sem atualizar recria a vulnerabilidade no mesmo minuto. Remova plugins nulos ou abandonados, que respondem por boa parte das reinfecções, e mantenha só o que o site realmente usa, reduzindo a superfície de ataque.

### Passo 7: Valide com um scanner e monitore

Rode uma varredura completa com Wordfence ou All in One Security para confirmar que nenhum arquivo malicioso sobreviveu, e ative o monitoramento contínuo. O <a href="https://full.services/wordfence-configuracao/">Wordfence configurado corretamente</a> detecta alterações de arquivo em tempo real. Para uma checagem independente sem instalar nada, use o <a href="https://security.full.services" rel="noopener" target="_blank">FULL Scan</a> e compare contra a base global de CVEs.

---

## Quanto custa proteger o site depois de restaurar

Depois de restaurar site hackeado com backup, o custo de manter o site protegido pesa menos que o de uma nova invasão, que soma limpeza, perda de tráfego e queda de posição no Google. A gente vê no suporte da FULL que sites sem firewall e sem backup automático voltam a ser alvo em poucos meses.

O plano PRO da FULL sai por R$849 e inclui o bundle com All in One Security, UpdraftPlus e WP Rocket, entre 17 plugins premium.

Distribuído pelos sites que o plano cobre, o custo cai para cerca de R$85 por site, valor que paga firewall, backup agendado e atualização gerenciada de uma vez. Para quem administra vários WordPress, esse rateio é mais barato que licenciar cada plugin avulso. Veja os detalhes em <a href="https://full.services/planos">FULL.services/planos</a> e compare com o custo de uma recuperação emergencial.

---

## Contexto de ameaça: O que os dados dizem hoje

A distribuição de ataques mostra por que firewall e backup andam juntos. Nos últimos dias, segundo o <a href="https://radar.cloudflare.com/security/application-layer" rel="noopener" target="_blank">Cloudflare Radar</a> (janela de 2026-06-09), 82,4% dos ataques de camada de aplicação mitigados no Brasil foram DDoS e 16,4% foram bloqueados por WAF. Isso significa que uma fatia relevante das ameaças é interrompida no firewall antes de chegar ao WordPress, o que justifica o WAF do plano sem alarmismo.

O backup entra como rede de segurança para o que o firewall não pega: credencial vazada, plugin com CVE de dia zero ou erro de configuração. A combinação de firewall ativo mais backup agendado fora do servidor é o padrão que sustenta a recuperação rápida. Restaurar site hackeado com backup é a última linha de defesa; o firewall é a primeira, e nenhuma das duas substitui a outra.

---

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia e fontes deste guia</h2>
<p>Os procedimentos descritos foram validados em ambientes WordPress 6.x com PHP 8.2, em servidores Apache e LiteSpeed, durante incidentes de recuperação acompanhados pelo suporte da FULL entre <time datetime="2026-01">janeiro</time> e <time datetime="2026-06">junho de 2026</time>. Os dados de CVE vêm do perfil público do WPVulnerability e da base NVD/NIST, fonte primária citável por ID. Os números de ataque vêm do Cloudflare Radar, com janela datada. Nenhum percentual interno foi inventado: as observações qualitativas refletem o padrão recorrente dos chamados de segurança, e cada número específico está ancorado em fonte externa nomeada e linkada.</p>
</aside>

## Erros comuns que reinfectam o site restaurado

O erro mais caro é restaurar e considerar o caso encerrado, sem trocar credenciais nem atualizar plugins. Restaurar site hackeado com backup é metade do trabalho; a outra metade é fechar a porta. Três armadilhas aparecem com frequência nos chamados: restaurar backup posterior à invasão, esquecer de limpar a tabela `wp_options` onde o pharma hack se esconde, e deixar um plugin nulo ativo.

Outro deslize é não verificar a integridade do próprio backup antes de confiar nele. Um backup que falhou silenciosamente no meio da cópia restaura um banco truncado, e o site sobe quebrado. Por isso vale manter pelo menos duas gerações de backup em destinos diferentes, como recomenda o guia de <a href="https://full.services/backup-wordpress-automatico/">backup automático do WordPress</a>. A redundância custa pouco e evita a situação de ter o backup, mas não ter um backup íntegro.

---

<h2 id="faq">Perguntas frequentes sobre restaurar site hackeado com backup</h2>

<details>
  <summary>É possível restaurar um site hackeado sem perder os dados recentes?</summary>
  <p>Sim, mas com ressalva. A restauração devolve o site ao estado do backup escolhido, então conteúdo criado depois daquela data se perde. A saída é exportar manualmente posts e pedidos legítimos do banco atual antes de restaurar, validar que não contêm código injetado e reimportá-los depois. Em lojas WooCommerce, isso exige cuidado extra com a tabela de pedidos para não reintroduzir registros adulterados.</p>
</details>

<details>
  <summary>Por que o malware volta mesmo depois de eu restaurar o backup?</summary>
  <p>O malware volta porque o backup restaurado é posterior à invasão ou porque a porta de entrada continua aberta. Se o plugin com a CVE original não foi atualizado, ou se as credenciais vazadas não foram trocadas, o atacante reentra em horas. Restaurar resolve o sintoma; atualizar e trocar senhas resolve a causa. Sem as duas ações, a reinfecção é questão de tempo, não de probabilidade.</p>
</details>

<details>
  <summary>Qual a diferença entre restaurar com backup e limpar o malware manualmente?</summary>
  <p>Restaurar com backup substitui todos os arquivos por uma cópia anterior e íntegra, sendo mais rápido quando existe um ponto limpo. Limpar manualmente remove só o código malicioso, preservando o conteúdo recente, e é necessário quando não há backup anterior à invasão. Na prática, sites com backdoor espalhado exigem limpeza antes da restauração para não recontaminar a cópia restaurada.</p>
</details>

<details>
  <summary>Quanto tempo leva para restaurar site hackeado com backup?</summary>
  <p>O tempo médio fica entre 30 e 90 minutos para um site comum, somando isolamento, troca de credenciais, restauração e validação. Sites grandes, acima de 5 GB ou com banco extenso, podem levar mais por causa do upload e do import SQL. O fator que mais alonga o processo não é a restauração em si, e sim a investigação da data e do vetor da invasão, etapa que não dá para pular.</p>
</details>

<details>
  <summary>Preciso de um plugin pago para restaurar site hackeado com backup?</summary>
  <p>Não é obrigatório: UpdraftPlus e outros plugins têm versão gratuita que faz backup e restauração completos. A versão paga agrega backups incrementais, destinos extras e restauração de um clique, úteis em operação com vários sites. O ponto decisivo não é o preço do plugin, e sim ter o backup armazenado fora do servidor, para que ele sobreviva caso o próprio servidor seja comprometido.</p>
</details>

## Próximos passos para blindar o site recuperado

Recuperar o site é o começo; mantê-lo seguro é o trabalho contínuo que evita o segundo ataque. Depois de restaurar site hackeado com backup, configure backup automático diário em destino externo, ative o firewall e agende a varredura semanal. Se o site já mostrou sinais de invasão antes, vale revisar o checklist de <a href="https://full.services/site-wordpress-invadido-o-que-fazer-imediatamente/">o que fazer quando o WordPress é invadido</a> e fechar cada brecha apontada.

Para aprofundar cada etapa, o <a href="https://full.services/academy/">FULL Academy</a> reúne os tutoriais de segurança, backup e hardening em um só lugar. A recuperação bem feita não termina quando o site volta ao ar: termina quando o mesmo vetor não consegue mais entrar.
