# Como recuperar de ransomware no WordPress em 6 passos

Recuperar de <strong>ransomware no WordPress</strong> exige isolar o site, preservar evidência e restaurar de um backup offline limpo, nunca pagar resgate. Segundo a <a href="https://www.cisa.gov/stopransomware/ransomware-guide" rel="noopener" target="_blank">CISA (2024)</a>, o ransomware busca e apaga backups acessíveis na rede. Só cópia offline e imutável garante a volta. Restauração apressada reinfecta em até 48 horas.

Recuperar de ransomware no WordPress é um procedimento de resposta a incidente, não um clique de plugin. O ataque cifra arquivos e o banco de dados, exibe nota de resgate e tenta destruir backups acessíveis para forçar o pagamento. A ordem das ações importa mais que a velocidade: isolar antes de mexer, preservar evidência antes de limpar e validar o backup antes de subir o site de volta. Quem inverte essa ordem costuma restaurar o próprio payload e voltar à estaca zero. Este guia faz parte da categoria <a href="https://full.services/gestao-de-sites-wordpress/">conteúdos de gestão de sites WordPress da FULL</a> e cobre os 6 passos na sequência correta.

---

## Primeiros passos: Visão geral da recuperação

A recuperação de ransomware no WordPress cabe em 6 passos numa ordem fixa: conter, diagnosticar, restaurar e blindar. Na prática que a gente vê no suporte da FULL, em boa parte dos casos o ataque só cifra arquivos do `wp-content` e o banco segue legível, então você recupera conteúdo sem pagar resgate algum.

<table id="etapas-recuperar-ransomware-wordpress">
  <caption>Recuperar de ransomware no WordPress: passos, objetivo e validação</caption>
  <thead>
    <tr>
      <th scope="col">Passo</th>
      <th scope="col">Objetivo</th>
      <th scope="col">Check de validação</th>
    </tr>
  </thead>
  <tbody>
    <tr><th scope="row">1. Isolar</th><td>Tirar o site do ar e cortar acesso</td><td>Site em manutenção, FTP/SSH só por IP fixo</td></tr>
    <tr><th scope="row">2. Preservar</th><td>Copiar logs e arquivos cifrados</td><td>Snapshot frio guardado fora do servidor</td></tr>
    <tr><th scope="row">3. Diagnosticar</th><td>Achar entrada e payload</td><td>Plugin/CVE de origem identificado</td></tr>
    <tr><th scope="row">4. Restaurar</th><td>Subir backup anterior limpo</td><td>Data do backup antes da cifragem</td></tr>
    <tr><th scope="row">5. Validar</th><td>Garantir que o payload não voltou</td><td>Scan limpo, hashes do core batem</td></tr>
    <tr><th scope="row">6. Blindar</th><td>Fechar a porta e monitorar</td><td>Firewall ativo, senhas e chaves trocadas</td></tr>
  </tbody>
</table>

---

## Por que ransomware no WordPress é diferente de malware comum

Ransomware no WordPress se distingue do malware comum por um detalhe operacional: ele cifra os dados com uma chave de 256 bits que você não tem, em vez de só injetar spam ou redirecionar visitantes. Um arquivo cifrado por AES-256 é matematicamente irreversível sem a chave do atacante, então não adianta limpar editando código como se faz num defacement simples.

Por isso a estratégia muda de "limpar" para "restaurar de antes". Segundo a <a href="https://www.cisa.gov/stopransomware/ransomware-guide" rel="noopener" target="_blank">CISA</a>, variantes modernas procuram ativamente backups montados na rede e os apagam primeiro, o que explica por que tantos sites descobrem, no pior momento, que o único backup vivia na mesma conta de hospedagem já comprometida. Entender essa diferença define o restante da resposta: ela diz se você vai recuperar os dados de um backup limpo ou acabar refém de <a href="https://full.services/glossario/malware-wordpress/">malware</a> que talvez nem entregue a chave de volta depois do pagamento.

---

## Passo a passo: Como recuperar de ransomware no WordPress

A execução da recuperação de ransomware no WordPress acontece em 6 passos encadeados, e nenhum deles pode rodar fora de ordem sem risco de reinfecção. Reserve de 2 a 6 horas para um site médio: os 5 primeiros passos contêm o incidente e restauram, o sexto blinda contra a próxima onda.

### Passo 1: Isole o site e corte os acessos

Comece desconectando o site da internet pública: ative o modo de manutenção ou suba um `index.html` estático, e restrinja FTP, SSH e wp-admin ao seu IP fixo. O objetivo é impedir que o ransomware no WordPress continue cifrando arquivos ou se espalhe para outros sites na mesma conta de hospedagem compartilhada, cenário comum em revenda. Pause tarefas cron e desative o login enquanto investiga. Se você gerencia vários sites, isole cada um: uma rotina de <a href="https://full.services/backup-wordpress-automatico/">backup automático no WordPress</a> mal configurada, compartilhando credenciais entre sites, é justamente o caminho que o atacante usa para pular de um site para o vizinho.

### Passo 2: Preserve a evidência antes de limpar qualquer coisa

Antes de apagar ou restaurar nada, faça um snapshot frio: copie a pasta inteira do site e um dump do banco para um disco externo, e baixe os logs de acesso do servidor (Apache, Nginx, FTP). Essa cópia preserva o timestamp da invasão e a versão do payload, o que você vai precisar para achar a porta de entrada no passo 3. Quem pula isso perde a única pista de QUANDO o ataque entrou e acaba restaurando um backup posterior à invasão, já contaminado. Trate o site cifrado como cena de crime: a <a href="https://full.services/analise-forense-site-wordpress-invadido/">análise forense de site WordPress invadido</a> depende dessa evidência intacta.

### Passo 3: Diagnostique a porta de entrada e o payload

Com a evidência salva, identifique COMO o ransomware no WordPress entrou: quase sempre é um plugin desatualizado com <a href="https://full.services/glossario/vulnerabilidade-wordpress/">vulnerabilidade</a> conhecida, uma senha de admin fraca ou um FTP vazado. Cruze os logs de acesso com a data de modificação dos arquivos cifrados para achar a requisição que iniciou tudo. Ferramentas como Wordfence e o scanner do All in One Security comparam os hashes do core com o repositório oficial e listam arquivos alterados. Consulte o CVE do plugin culpado no <a href="https://security.full.services">FULL Scan</a> para confirmar se a falha já tem correção publicada antes de restaurar.

### Passo 4: Restaure de um backup anterior e comprovadamente limpo

Restaure o site a partir do backup mais recente DATADO ANTES da cifragem, nunca o último automático, que pode já conter o payload dormente. Confira a data no nome do arquivo contra o timestamp da invasão que você salvou no passo 2. Plugins como UpdraftPlus restauram arquivos e banco separadamente, o que permite subir só o banco limpo e reinstalar o core e plugins do zero pelo repositório oficial. Se o único backup disponível for posterior ao ataque, extraia apenas o conteúdo do banco (posts, páginas) e descarte os arquivos. Veja como manter cópias seguras no guia de <a href="https://full.services/backup-no-wordpress/">backup no WordPress</a>.

### Passo 5: Valide que o payload não voltou junto

Depois de restaurar, NÃO religue o tráfego ainda: rode um scan completo e confira se os hashes do WordPress core batem com os oficiais via WP-CLI (`wp core verify-checksums`). Procure usuários admin desconhecidos, tarefas cron suspeitas e arquivos PHP recentes em `wp-content/uploads`, onde payloads gostam de hibernar. Esse passo existe porque restaurar não garante limpeza: se a falha do passo 3 não foi fechada, o atacante volta pela mesma porta em horas. Só libere o site quando o scan vier limpo e a senha de todos os admins, mais as chaves de autenticação do `wp-config.php`, tiverem sido trocadas.

### Passo 6: Blinde o site contra a próxima onda

Com o site limpo no ar, feche a porta que foi usada e adicione camadas para a próxima tentativa. Atualize core, plugins e temas para a última versão, remova qualquer plugin nulled ou inativo e ative um <a href="https://full.services/glossario/firewall-wordpress/">firewall</a> de aplicação para barrar exploits automatizados. Configure backups offline com rotação, fora da conta de hospedagem, e ative atualizações automáticas de segurança. A prevenção contínua descrita em <a href="https://full.services/atualizacoes-seguranca-wordpress/">atualizações de segurança no WordPress</a> fecha o ciclo: sem ela, recuperar de ransomware no WordPress vira rotina mensal em vez de incidente isolado.

---

## Erros comuns que reinfectam o site

O erro que mais reinfecta na recuperação de ransomware no WordPress é pular a ordem: restaurar antes de diagnosticar. Sem achar a porta de entrada do passo 3, você sobe o backup limpo por cima de uma falha aberta e o atacante recifra tudo em até 48 horas pela mesma rota.

O segundo erro é confiar no backup da própria hospedagem: como a CISA alerta, o ransomware apaga ou cifra backups acessíveis na mesma rede, então a cópia que vivia ao lado do site some junto. O terceiro é pagar o resgate sem garantia, porque boa parte das vítimas que paga não recebe uma chave funcional, ou recebe uma que só decifra parte dos arquivos e deixa o resto perdido. Trate cada um desses três como bloqueante antes de declarar o site recuperado e religar o tráfego de produção.

---

## Recupere e blinde com a plataforma FULL

Montar essa cadeia de resposta sozinho leva horas e exige plugins pagos que, comprados avulsos, passam de R$ 1.500 por ano somados. No plano PRO da FULL, por R$ 849, você ativa de uma vez as camadas que faltam para recuperar e blindar o site contra a próxima onda.

São UpdraftPlus para backup offline, All in One Security para firewall e os 17 plugins do bundle ativados nos seus sites, o que sai por cerca de R$ 85 por site quando você gerencia uma carteira. A gente vê no suporte da FULL que a diferença entre um site que volta em 2 horas e um que fica dias fora é justamente ter backup offline e firewall já ativos ANTES do ataque, não correndo atrás depois. Compare as camadas em <a href="https://full.services/planos">FULL.services/planos</a> e deixe a recuperação virar um procedimento previsível, não um desespero de madrugada.

---

<h2 id="faq">Perguntas frequentes sobre ransomware no WordPress</h2>

<details>
  <summary>É possível recuperar de ransomware no WordPress sem pagar o resgate?</summary>
  <p>Sim, na maioria dos casos você recupera sem pagar, desde que tenha um backup offline anterior à cifragem. Restaure os dados desse backup, reinstale o core e os plugins pelo repositório oficial e feche a falha de entrada. Pagar o resgate não garante a chave de decifragem: a CISA recomenda explicitamente não pagar, porque financia o atacante e não assegura a volta dos arquivos.</p>
</details>

<details>
  <summary>Por que restaurar o backup antes de diagnosticar costuma reinfectar o site?</summary>
  <p>Porque a falha que deixou o ransomware entrar continua aberta. Se você restaura sem identificar a porta de entrada no passo 3, o site limpo sobe sobre um plugin vulnerável ou uma senha vazada, e o atacante recifra tudo em até 48 horas pela mesma rota. Diagnosticar antes de restaurar é o que transforma recuperação em solução definitiva, e não em ciclo de reinfecção semanal.</p>
</details>

<details>
  <summary>Qual a diferença entre ransomware e malware comum no WordPress?</summary>
  <p>Ransomware cifra arquivos e banco com uma chave que você não tem e cobra resgate; malware comum injeta spam, redireciona visitantes ou cria admins ocultos, sem criptografia. A consequência prática é a estratégia: malware comum você limpa editando arquivos, enquanto dados cifrados por AES-256 são irreversíveis sem a chave, exigindo restauração de um backup anterior em vez de limpeza manual.</p>
</details>

<details>
  <summary>Como saber se o backup que vou restaurar está limpo de ransomware?</summary>
  <p>Compare a data do backup com o timestamp da invasão que você salvou ao preservar a evidência no passo 2: use sempre uma cópia DATADA antes da cifragem. Depois de restaurar, rode `wp core verify-checksums` no WP-CLI para confirmar que os hashes do core batem com os oficiais e faça um scan completo procurando PHP recente em uploads. Só libere o tráfego quando o scan vier limpo.</p>
</details>

<details>
  <summary>Com que frequência devo testar o backup para garantir a recuperação?</summary>
  <p>Teste a restauração pelo menos uma vez por mês em um ambiente de staging, não apenas confie que o backup foi gerado. Boa parte das recuperações falha porque o arquivo estava corrompido ou incompleto e ninguém testou antes da emergência. Um backup offline com rotação semanal e um teste de restauração mensal transformam o ransomware no WordPress de catástrofe em transtorno de duas horas.</p>
</details>

---

## Próximos passos para blindar seu WordPress

Recuperar de ransomware no WordPress prova que backup offline e diagnóstico vêm antes da pressa: isolar, preservar, diagnosticar, restaurar, validar e blindar, nessa sequência, é o que separa um site que volta em horas de um que fica dias fora. A FULL opera como única CNA brasileira sob a CISA e monitora mais de 150 mil sites WordPress, e o padrão que se repete é simples: quem tinha backup offline e firewall ativos ANTES do ataque recupera sem pagar nada. Escaneie seu site agora no <a href="https://security.full.services">FULL Scan</a> para descobrir falhas abertas, e para continuar aprendendo consulte o <a href="https://full.services/guias/guia-de-seguranca-para-wordpress">guia de segurança para WordPress</a> da FULL.

<p class="wp-caption-text">Legenda: restaurar de um backup datado antes da invasão é o único caminho que devolve os dados sem pagar resgate.</p>
