Site invadido: o que fazer nas primeiras horas
Um site invadido deve ser tratado nesta ordem: isolar o site para estancar os danos, alterar imediatamente todas as senhas de administração, restaurar um backup limpo anterior ao incidente, identificar e corrigir a falha explorada e, em seguida, avaliar se dados pessoais foram comprometidos para cumprir a obrigação de notificação do RGPD, se necessário. Seguir essa ordem evita restaurar o site apenas para vê-lo ser invadido novamente de imediato.
O verdadeiro problema: o pânico faz perder tempo precioso
Descobrir que o site foi invadido costuma provocar uma reação de pânico que leva a agir de forma desordenada: excluir arquivos aleatoriamente, alterar o conteúdo exibido sem entender a causa ou, no extremo oposto, não fazer nada por medo de piorar a situação. Ambos os extremos são contraproducentes. A boa notícia é que a grande maioria das invasões de sites (sobretudo em CMS como o WordPress) segue padrões conhecidos e se resolve com um procedimento metódico, sem exigir uma expertise técnica muito avançada.
A urgência real não é consertar tudo em uma hora, e sim estancar a propagação dos danos: impedir que o conteúdo malicioso continue a ser exibido, evitar que o invasor mantenha o acesso e evitar que o Google indexe páginas fraudulentas que prejudicariam de forma duradoura o posicionamento do site nas buscas.
A checklist a seguir, em ordem
- Colocar o site fora do ar ou em modo de manutenção imediatamente, para interromper a exposição do conteúdo malicioso a visitantes e aos robôs do Google.
- Alterar todas as senhas de administração: CMS, hospedagem, banco de dados, FTP e domínio, caso o acesso a esse nível esteja em dúvida. Uma senha comprometida reutilizada em outros lugares deve ser trocada em todos eles.
- Revogar acessos suspeitos: contas de administrador criadas sem sua aprovação, chaves de API ou tokens desconhecidos, aplicativos de terceiros conectados que não sejam reconhecidos.
- Identificar a extensão dos danos: páginas modificadas, arquivos adicionados, redirecionamento injetado, banco de dados alterado. Uma comparação com o último backup limpo ajuda a delimitar com precisão o que mudou.
- Restaurar um backup anterior ao incidente, verificando que ele esteja de fato limpo (um backup feito após a invasão inicial já pode conter a falha ou o código malicioso).
- Identificar e corrigir a causa: plugin desatualizado, senha fraca, falha conhecida não corrigida. Sem essa etapa, o risco de repetição permanece alto.
- Atualizar todo o site (CMS, temas, plugins) antes de colocá-lo definitivamente de volta no ar.
- Avaliar o impacto sobre os dados pessoais e acionar, se necessário, o procedimento de notificação do RGPD.
- Monitorar o site nos dias seguintes para confirmar que o invasor não manteve nenhum acesso residual.
A obrigação de notificação do RGPD em caso de vazamento de dados
Se a invasão expôs dados pessoais de seus usuários ou clientes (e-mails, endereços, senhas, informações de pagamento), o RGPD impõe um procedimento preciso, não uma opção:
- Notificação à autoridade competente em até 72 horas após a descoberta da violação, salvo se o risco para os titulares dos dados for considerado insignificante.
- Informação aos titulares dos dados caso a violação represente um risco elevado para seus direitos e liberdades (por exemplo, senhas ou dados bancários expostos).
- Documentação do incidente, mesmo sem notificação obrigatória: natureza da violação, dados envolvidos, medidas adotadas. Essa documentação pode ser solicitada em caso de fiscalização posterior.
Uma invasão que afete apenas a aparência do site (defacement, redirecionamento) sem acesso a dados não gera essa obrigação, mas a extensão real dos danos deve ser analisada antes de descartá-la rápido demais.
Identificar a causa para evitar que se repita
As causas mais frequentes de invasão em um site profissional continuam sendo falhas conhecidas e evitáveis: plugin ou tema desatualizado, senha fraca ou reutilizada, ausência de autenticação em dois fatores na administração, ou hospedagem compartilhada comprometida por meio de outro site no mesmo servidor. Uma auditoria rápida desses pontos após o incidente costuma bastar para identificar a porta de entrada sem exigir expertise técnica avançada.
O que atrasa desnecessariamente a volta ao ar
- Restaurar um backup sem verificar se ele é anterior à invasão, o que reintroduz a falha.
- Colocar o site de volta no ar antes de ter alterado todas as senhas, deixando um acesso aberto para o invasor.
- Ignorar os logs do servidor, que costumam conter pistas precisas sobre o método de invasão.
- Não avisar o provedor de hospedagem, que pode dispor de informações úteis (outros sites afetados no mesmo servidor, alertas já detectados do lado dele).
O que é preciso lembrar
- O procedimento segue uma ordem precisa: isolar, alterar os acessos, restaurar um backup limpo, corrigir a causa, avaliar o impacto sobre os dados.
- Restaurar um backup sem identificar a causa expõe a uma nova invasão rápida, às vezes pela mesma falha.
- Um vazamento de dados pessoais exige notificação à autoridade competente em até 72 horas e, dependendo do risco, informação aos titulares dos dados.
- A maioria das invasões de sites explora falhas conhecidas (plugin desatualizado, senha fraca), não ataques sofisticados.
- Um backup recente e testado é o fator que mais acelera a volta ao ar após um incidente.
Perguntas frequentes
Devo tirar meu site completamente do ar enquanto resolvo o problema? Frequentemente sim, temporariamente. O modo de manutenção ou a suspensão do site impedem que o conteúdo malicioso continue a ser exibido ou indexado enquanto o incidente é tratado.
É preciso notificar a autoridade de proteção de dados em caso de invasão? Somente se dados pessoais tiverem sido comprometidos. O RGPD exige então uma notificação em até 72 horas, além de informar os titulares dos dados caso o risco para eles seja elevado.
Posso restaurar o site sem saber como ele foi invadido? É arriscado: se a falha não for corrigida, o site pode ser invadido novamente em pouco tempo, às vezes pelo mesmo método. Identificar a causa antes de voltar ao ar evita reproduzir o incidente.
Quanto tempo leva para colocar de volta no ar um site invadido? Com um backup limpo e recente e uma causa identificada rapidamente, o site pode voltar ao ar em poucas horas. Sem um backup utilizável, isso pode levar vários dias.
Em resumo
Um site invadido não é uma fatalidade irreversível: um procedimento metódico (isolar, proteger os acessos, restaurar, corrigir a causa) costuma permitir voltar ao ar em algumas horas a poucos dias. A melhor preparação continua sendo feita antes, com backups regulares e testados que tornam essa checklist muito mais rápida de executar. O plano site por assinatura VeryAppi inclui o monitoramento e os backups que limitam o impacto de um incidente desse tipo.
Perguntas frequentes
›Devo tirar meu site completamente do ar enquanto resolvo o problema?
Frequentemente sim, temporariamente. Colocar o site em modo de manutenção ou tirá-lo do ar impede que o conteúdo malicioso continue a ser exibido aos visitantes ou indexado pelo Google enquanto trata o incidente. Depois de corrigida a causa e restaurado um backup limpo, o site pode voltar ao ar.
›É preciso notificar a autoridade de proteção de dados em caso de invasão?
Somente se dados pessoais tiverem sido comprometidos (vazamento, acesso não autorizado). Nesse caso, o RGPD exige a notificação à autoridade competente em até 72 horas após a descoberta da violação, além de informar os titulares dos dados caso o risco para eles seja elevado. Uma invasão sem envolvimento de dados pessoais não gera essa obrigação.
›Posso restaurar o site sem saber como ele foi invadido?
Tecnicamente sim, mas é arriscado: se a falha explorada não for corrigida, o site provavelmente será invadido novamente em pouco tempo, às vezes pelo mesmo método. Identificar a causa antes ou durante a restauração evita reproduzir o incidente de forma idêntica.
›Quanto tempo leva para colocar de volta no ar um site invadido?
Depende da gravidade e da disponibilidade de um backup limpo recente. Com um backup confiável e uma causa identificada rapidamente, o site pode voltar ao ar em poucas horas. Sem um backup utilizável, a reconstrução pode levar vários dias.