Meu site foi invadido: o que fazer nas primeiras horas

Por Rogério Leite, Consultor de Marketing Digital · 11 de setembro de 2026

Os três avisos que chegam, e o que cada um está dizendo

Três avisos diferentes chegam com a mesma aparência de urgência: o rótulo do Google na busca, a tela de bloqueio do navegador e o e-mail da hospedagem informando suspensão. Eles não vêm da mesma fonte e não pedem a mesma reação. Antes de mexer no site, identifique qual deles você está olhando.

Existe ainda o caso em que ninguém avisou e quem reclamou foi um cliente: quem chega pela busca cai em outro site, e você, logado no painel, vê tudo normal. Isso é entrega condicional: o desvio depende de quem pediu a página e de onde veio. Confirme clicando no resultado do Google, de outro aparelho, e não digitando o endereço na barra.

• Rótulo na busca. Dois são os que interessam aqui, entre os que a Ajuda do Search Console reúne em por que meu site está marcado como perigoso: Este site pode ter sido invadido, que aponta conteúdo colocado no site sem sua permissão, e Este site pode danificar seu computador, que aponta malware.
• Tela do navegador. O acesso é interrompido antes de a página abrir. Quem vê isso é o visitante, e ele desiste ali mesmo.
• Suspensão da hospedagem. Quem detectou foi o provedor, pela varredura dele, e não o Google. Peça por escrito a lista de arquivos apontados e a data em que a varredura acusou.

Antes de apagar qualquer arquivo, congele a cena

O primeiro impulso é abrir o gerenciador de arquivos e apagar o que parece estranho. Esse impulso destrói o registro de como aquilo chegou lá, e é esse registro que diz qual porta fechar. Limpeza feita antes do diagnóstico fecha o sintoma e deixa aberta a porta pela qual ele entrou.

A documentação do Google sobre colocar o site em quarentena descreve como tirá-lo do ar, e os exemplos que ela dá são parar o servidor ou apontar o DNS para uma página estática que responde com o código HTTP 503. Ela pede que você avise a hospedagem de que vai alternar entre online e offline, e registra ser improvável que isso afete a classificação futura.

Guarde, antes de qualquer alteração, uma cópia integral do estado comprometido, arquivos e banco de dados juntos. Ela não serve para restaurar, serve para ler. Peça também à hospedagem os registros de acesso do período, que têm retenção limitada e podem sumir sozinhos enquanto você decide o que fazer.

Troque as credenciais e veja quem ganhou acesso junto

Trocar a senha do painel do site e parar por aí deixa o trabalho pela metade. Quando a entrada foi por credencial, o mesmo par de usuário e senha pode abrir mais de uma porta, e o acesso que ficou de fora da troca continua servindo depois que você limpou. A troca só vale se alcançar todas as contas ligadas ao site, de uma vez.

A mesma documentação de quarentena manda trocar a senha de todas as contas ligadas ao site, citando FTP, banco de dados, administrador do sistema e contas do gerenciador de conteúdo. Manda também conferir a lista de usuários e ver se o invasor criou alguma. Se criou, anote os nomes antes de excluir, porque essa lista é pista: mostra por qual caminho a criação foi possível.

• Painel da hospedagem, FTP e SFTP, banco de dados, administrador do site e caixas de e-mail no domínio.
• Painel do registrador do domínio, que é quem controla para onde o endereço aponta.
• Chaves e tokens de integração: gateway de pagamento, disparo de e-mail, API de sistema de terceiro.
• Sessões ativas. Senha nova não derruba quem já está logado se o sistema não encerrar as sessões abertas.
• E-mail cadastrado nas contas legítimas, que pode ter sido trocado para desviar a recuperação de senha.
• Segundo fator onde existir, começando pelas contas que recuperam todas as outras.

A data do comprometimento decide qual cópia serve

O reflexo seguinte é restaurar o backup de ontem. Por que a cópia mais recente pode não servir já está publicado em manutenção de sites, e é decisão anterior ao incidente. O passo que pertence às primeiras horas é um só: não restaure nada antes de saber em que data o comprometimento começou, porque é a data que decide qual cópia serve.

Datar é trabalho de leitura, e não de palpite. Os registros de acesso que você pediu à hospedagem, a data de modificação dos arquivos que não deviam ter mudado e a data em que o Google detectou o problema pela primeira vez, que o painel dele mostra, delimitam a janela. Só depois disso a escolha da cópia deixa de ser aposta.

Restaurar também não fecha nada sozinho. Se a entrada foi um componente desatualizado, a cópia antiga devolve esse componente ao ar na mesma versão vulnerável, e o caminho segue aberto para quem já sabe usá-lo. Restauração é o passo que repõe o conteúdo, não o passo que encerra o incidente.

Achar o que entrou é diferente de achar por onde entraram

O Google descreve quatro formas de conteúdo invadido: injeção de código, quando script ou iframe malicioso entra nas páginas existentes; injeção de páginas, quando páginas novas de spam ou de phishing são criadas; injeção de conteúdo, quando texto e link ocultos são costurados no que já estava publicado; e redirecionamento, que é a entrega condicional descrita no começo desta página.

A injeção de conteúdo é a que engana o dono, porque a página continua igual na tela. Rode o mesmo site: que por que meu site não aparece no Google ensina e, desta vez, leia os títulos em vez de contar as páginas. Título em outro idioma, com nome de remédio ou de aposta, é conteúdo que você não publicou.

Encontrar e remover isso resolve o sintoma. A porta é outra pergunta, e as respostas comuns são componente desatualizado, credencial vazada, envio de arquivo sem validação ou conta de um terceiro que também tinha acesso. Certificado não fecha nenhuma dessas portas, e o porquê está em hospedagem de sites.

No painel do Google, o relatório que interessa aqui não é o de ações manuais

São dois relatórios distintos, e a diferença muda o que você faz. Ações manuais tratam de manipulação do índice de busca, e o efeito é de posição. Problemas de segurança trata de risco ao visitante, e o efeito é o rótulo que aparece na busca e a tela de aviso que o navegador mostra antes de abrir o site.

O relatório de Problemas de segurança separa as descobertas em conteúdo invadido, malware e software indesejado e engenharia social, mostra amostras de endereços atingidos e traz a data em que cada problema foi detectado pela primeira vez no site. É por ele que se confirma o que o Google viu, em vez de deduzir pelo que o navegador mostra.

A opção de solicitar revisão está nesse mesmo relatório, e o pedido cobra a descrição do que foi corrigido. A Ajuda do Google avisa que pedir revisão com o problema ainda não corrigido pode alongar a resposta ao pedido seguinte e até fazer o site ser marcado como infrator reincidente, e pede que você não envie outro pedido enquanto houver decisão pendente.

O resto do painel, robots.txt, noindex, sitemap e a própria seção de ações manuais, pertence a outra pergunta, a de por que uma página não aparece, e já está descrito em por que meu site não aparece no Google. Aqui o painel entra só por esta porta.

Se havia dado de cliente no site, a conta não é só técnica

Formulário de contato, área restrita e loja virtual guardam nome, telefone, e-mail e histórico de pedido dentro do banco de dados. Invasão que alcançou o banco é incidente de segurança com dado pessoal, e isso abre uma obrigação que não se resolve no painel do site.

A Lei 13.709/2018, no artigo 48, obriga o controlador a comunicar à Autoridade Nacional de Proteção de Dados e ao titular a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante aos titulares. Se o caso concreto se enquadra, quem responde é o jurídico da empresa, e não a agência.

A Resolução CD/ANPD nº 15/2024, no artigo 6º, regulamenta essa comunicação. O prazo é de três dias úteis, contados do conhecimento pelo controlador de que o incidente afetou dados pessoais, e não da data em que o site caiu. O mesmo artigo conta esse prazo em dobro para agente de tratamento de pequeno porte.

Ao lado técnico cabe entregar a base dessa decisão: o que foi acessado, em que janela e o que foi feito depois. É exatamente por isso que a cópia do estado comprometido e os registros de acesso são guardados lá no começo. Registro guardado durante o incidente vira documento; memória de quem estava na hora, não.

O que muda o cenário do próximo evento

Imunidade não existe como produto, e o que um acompanhamento preventivo muda quando a invasão acontece assim mesmo já está respondido em manutenção de sites. O que cabe dizer aqui é o inverso: nas primeiras horas, você só usa o que já existia. Nada disso se contrata durante o incidente.

Tudo o que este texto pede, datar a janela, saber qual componente entrou e quando, ter uma cópia para onde voltar, depende de registro que alguém guardou antes. Quem chega ao incidente sem esse registro gasta as primeiras horas reconstruindo o passado do próprio site em vez de fechar a porta.

Esse regime é o que a manutenção da Criattus mantém, e vale dizer o que ela não é: não é plantão de emergência, não é perícia forense e não é serviço que promete devolver um site limpo. A contratação faz sentido antes do evento, e não durante.

Quando a operação não pode esperar, a opção que ganha é outra. O suporte da própria hospedagem já está dentro da máquina e, quando o plano inclui varredura no servidor, é a porta mais curta. Empresa especializada em resposta a incidente é a outra opção, e o regime de atendimento dela é a primeira pergunta a fazer.

Dizer isso nos custa trabalho e economiza tempo de quem está no meio do incidente. A conversa útil com a gente, nesse ponto, é sobre regime, acesso e histórico, e não sobre urgência. Se você preferir tratar isso pessoalmente, o endereço, o telefone e o formulário da Criattus estão na página de contato.