Como verificar se o seu site ou servidor foi invadido: verificações passo a passo para hospedagem compartilhada, WordPress e VPS, e o que fazer primeiro se encontrar algo

Para quem é: pessoas e pequenas empresas que mantêm um site em hospedagem compartilhada, WordPress ou VPS e agora se perguntam "fui invadido?". Este guia mostra como verificar você mesmo o seu site e o seu servidor. Ele se baseia na documentação oficial do WordPress.org, do WP-CLI e do Google Search Central, nas páginas de manual de cada comando, na IPA e no JPCERT/CC do Japão e no GDPR. Técnicas de ataque não são abordadas.

Sinais que devem fazer você suspeitar de uma invasão

Se algum destes se aplicar, passe às verificações por ambiente abaixo. O "FAQ My site was hacked" do WordPress.org também lista sinais claros de invasão, como ser colocado em lista de bloqueio pelos buscadores, a hospedagem desativar o site e comportamentos não autorizados, como a criação de novos usuários.

Verificações por ambiente

Verifique as linhas que correspondem à sua configuração. Se você usa WordPress numa hospedagem compartilhada, as duas primeiras linhas se aplicam.

Hospedagem compartilhada

Mesmo sem SSH, o painel de controle normalmente permite verificar estas três coisas (os nomes variam conforme a hospedagem).

• Abra a pasta pública no gerenciador de arquivos e ordene pela data de modificação. Fique atento a arquivos alterados em dias em que você não mexeu neles, arquivos PHP com nomes sem sentido e arquivos PHP dentro de pastas de imagens, como uploads
• Baixe os logs de acesso e de erro e veja de onde e quando vieram as requisições à área administrativa (no WordPress, /wp-login.php e /wp-admin/), além de requisições a URLs que você não reconhece
• Se você puder ver a contagem ou o histórico de envio de e-mails, procure grandes volumes que você não enviou

Verifique também o .htaccess. O WordPress.org cita o .htaccess como um dos arquivos mais modificados e abusados, seja qual for o tipo de infecção, e observa que index.php, header.php e footer.php são alvos valiosos porque afetam toda requisição de página.

WordPress

No painel, verifique dois lugares.

• Users > All Users (Usuários > Todos os usuários): há alguém com a função Administrator (Administrador) que você não criou?
• Plugins > Installed Plugins (Plugins instalados): há algum plugin que você não instalou? Verifique Appearance > Themes (Aparência > Temas) da mesma forma

Se o WP-CLI (a ferramenta oficial de linha de comando do WordPress) estiver disponível no servidor, você pode comparar os arquivos com a versão oficial automaticamente.

# Check WordPress core files against WordPress.org checksums
wp core verify-checksums
# Also warn about non-WordPress files in the WordPress root directory
wp core verify-checksums --include-root
# Verify plugins distributed on WordPress.org
wp plugin verify-checksums --all
# List administrator accounts with their registration dates
wp user list --role=administrator

Um resultado limpo imprime Success: WordPress installation verifies against checksums. Um arquivo divergente imprime Warning: File doesn't verify against checksum: seguido do nome dele. A verificação de plugins compara com os checksums do WordPress.org, então plugins premium e temas personalizados não podem ser verificados assim. Para esses, baixe de novo a mesma versão do fornecedor e compare.

VPS (Linux)

Num VPS, procure o que um invasor deixa para conseguir voltar: chaves públicas, tarefas agendadas, usuários novos e programas aguardando conexões. Execute tudo isto no seu próprio servidor, como administrador.

# SSH login records (the unit is ssh on Debian/Ubuntu, sshd on RHEL-family)
sudo journalctl -u ssh --since "2026-10-01"
# Recent logins (on Debian 13, use wtmpdb last instead; install the wtmpdb and libpam-wtmpdb packages)
last -a
# Each user's last login (on Debian 13, use lastlog2 instead; install the lastlog2 and libpam-lastlog2 packages)
lastlog
# SSH public keys: the current user's (other users: /home/*/.ssh/authorized_keys) and root's
cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys
# Scheduled jobs (per user and system-wide)
crontab -l
sudo crontab -l -u root
sudo cat /etc/crontab
sudo ls -la /etc/cron.d
# Users, and the group with admin rights (wheel on RHEL-family)
getent passwd
getent group sudo
# Listening TCP ports and the programs behind them
sudo ss -tlnp
# Files in the web root whose contents changed in the last 7 days
sudo find /var/www -type f -mtime -7
# Have package files changed since they were installed?
sudo debsums -s      # Debian/Ubuntu (needs the debsums package)
sudo rpm -Va         # RHEL-family

Como ler os resultados:

• Na saída do journalctl, verifique o IP de origem dos logins bem-sucedidos (Accepted) em busca de endereços que não são seus. Se nada aparecer, o nome da unidade pode ser outro; confira o nome do serviço SSH com systemctl list-units --type=service
• No authorized_keys, procure chaves públicas que você nunca adicionou. Como gerenciar as chaves que podem acessar um servidor é explicado em privilégio mínimo para chaves SSH
• No cron, procure linhas que baixam e executam algo de um URL desconhecido
• Na lista do ss, procure programas em escuta que você não iniciou
• debsums -s mostra só os arquivos com problema; rpm -Va marca os arquivos alterados com códigos como tamanho (S), digest (5) e hora de modificação (T)

Google Search Console

Se o seu site ainda não está cadastrado no Search Console, adicione-o e verifique a propriedade primeiro.

• No relatório Problemas de segurança, veja se há algum problema listado. Os problemas se dividem em três grandes categorias: conteúdo invadido, malware e software indesejado, e engenharia social, normalmente com URLs de exemplo. Alguns problemas vêm sem URLs de exemplo; o Google diz que isso não significa que nenhuma página foi afetada
• Pesquise no Google site:seudominio e procure páginas que você nunca fez. O Google diz que isso lista as páginas do seu site, inclusive as que um invasor possa ter adicionado
• Coloque as páginas suspeitas na ferramenta de inspeção de URL para ver como o Google as vê

Sobre a terminologia: rastros de um comprometimento que já aconteceu, como os acima, são chamados de IOCs (indicadores de comprometimento). Veja o que é um IOC e, para identificar um ataque pelo comportamento enquanto ele ainda está em andamento, o que é um IOA.

O que fazer primeiro se encontrar algo

Se errar a ordem, você destrói as evidências ou restaura o site com o ponto de entrada do atacante ainda aberto. Siga de cima para baixo.

Se dados pessoais podem ter vazado

Se você trata dados pessoais como empresa e envios de formulários de contato ou cadastros de membros podem ter vazado, verifique as regras de onde você atua.

• UE e Reino Unido (GDPR, Artigo 33): notifique a autoridade de controle sem demora injustificada e, quando possível, em até 72 horas depois de tomar conhecimento de uma violação de dados pessoais, a menos que ela provavelmente não resulte em risco aos direitos e liberdades das pessoas. O Artigo 34 trata de quando você também precisa avisar as pessoas afetadas
• Japão: a Personal Information Protection Commission (PPC) lista quatro categorias que devem ser comunicadas — dados sensíveis, risco de dano financeiro, suspeita de finalidade ilícita e mais de 1.000 pessoas. Um vazamento causado por acesso não autorizado é dado como exemplo da categoria de finalidade ilícita. O relatório preliminar é devido em 3 a 5 dias após a descoberta e o relatório final em 30 dias (60 dias na categoria de finalidade ilícita), e as pessoas afetadas também devem ser avisadas
• Em outros lugares: verifique a autoridade nacional de proteção de dados

Onde pedir ajuda

Fontes (oficiais)

• WordPress.org: FAQ My site was hacked — wordpress.org
• WordPress.org: Administration Screens — wordpress.org
• WP-CLI: wp core verify-checksums — developer.wordpress.org
• WP-CLI: wp plugin verify-checksums — developer.wordpress.org
• WP-CLI: wp user list — developer.wordpress.org
• Google: Security issues report (Ajuda do Search Console) — support.google.com
• Google: How do I know if my site was hacked? (web.dev) — web.dev
• Google: Fix the cloaked keywords and links hack (web.dev) — web.dev
• Blog do Google Search Central: Detect and get rid of unwanted sneaky mobile redirects (outubro de 2015) — developers.google.com
• Ajuda da Pesquisa Google: Report a problem with Google Search (sobre o rótulo "Este site pode ter sido invadido") — support.google.com
• Páginas de manual do Debian: journalctl(1), last(1), lastlog(8), sshd(8), crontab(1), cron(8), ss(8), find(1), debsums(1) — manpages.debian.org
• RPM: rpm(8) (como ler a saída do --verify) — rpm.org
• Notas de lançamento do Debian 13 (trixie): os comandos last, lastb e lastlog foram substituídos — debian.org
• GDPR (Regulamento (UE) 2016/679), Artigos 33 e 34 — eur-lex.europa.eu
• Personal Information Protection Commission, Japão: comunicação obrigatória de vazamentos e aviso às pessoas (em japonês) — ppc.go.jp
• Personal Information Protection Commission, Japão: como responder a vazamentos de dados (em japonês) — ppc.go.jp
• JPCERT/CC: pedido de resposta a incidentes (em japonês) — jpcert.or.jp
• IPA: comunicação de vírus de computador e acesso não autorizado (em japonês) — ipa.go.jp

Leia a seguir

• Para as suas contas pessoais: Como verificar se alguém acessou sua conta
• Quando a própria hospedagem é invadida: Quando o seu provedor de hospedagem é invadido: o que os clientes devem fazer (em inglês; preparação para o que as suas próprias configurações não conseguem evitar)
• Verificar onde ficam os arquivos: Você deixou um arquivo secreto num diretório público? / Mantendo o .env fora da web pública na hospedagem compartilhada
• WordPress: Segurança do WordPress — uma referência de reforço para produção / um ponto de entrada comum: vulnerabilidades de upload de arquivos (em inglês)
• Termos: O que é um IOC? / O que é um IOA? / O que é um backdoor? (em inglês) / O que é malware?
• Recuperação: Fundamentos de backup