Site Hackeado: Como Acontece e Como Proteger o Seu

Imagine seu site fora do ar numa segunda-feira de manhã, substituído por uma página de apostas em chinês. Ninguém digitou aquele conteúdo. Um script fez isso sozinho, durante a madrugada, sem que ninguém percebesse a tempo.

Como um site é invadido, na prática: quase nunca existe alguém mirando em você

A maioria dos ataques a sites não mira uma pessoa ou uma empresa específica. Bots varrem milhões de endereços por dia, testando falhas conhecidas em lote. Assim que uma vulnerabilidade pública, uma CVE, é divulgada em um plugin popular, esses bots passam a testar todo site que ainda roda aquela versão. O alvo é a falha, não o dono do site.

Faz sentido perguntar por que alguém invadiria um site pequeno, sem cartão de crédito armazenado e sem dado sensível de cliente. A resposta é simples: o objetivo raramente é você. O invasor quer o servidor. Um site comprometido vira ferramenta para outra coisa: hospedar páginas de spam que aparecem no Google sob o nome do seu domínio, enviar phishing usando a reputação do seu e-mail corporativo, minerar criptomoeda com o processamento do servidor ou simplesmente somar mais um nó a uma rede de sites infectados usada em outros ataques.

Os métodos mais usados para invadir um site são conhecidos e se repetem:

• Força bruta: milhares de tentativas automáticas de login em /wp-admin ou /wp-login.php até acertar usuário e senha.
• Plugins e temas desatualizados: a porta de entrada mais comum em WordPress, porque cada plugin é código de terceiros raramente revisado depois da instalação.
• Upload de arquivos maliciosos: formulários de contato ou galerias mal configuradas que aceitam um arquivo disfarçado de imagem, mas com código malicioso dentro.
• Injeção SQL: campos de busca ou parâmetros de URL que não filtram o que o usuário digita, abrindo caminho direto para o banco de dados.
• Senha reaproveitada: a mesma senha usada em outro serviço vazado aparece em listas públicas e é testada automaticamente no painel administrativo do site.

Quais sinais indicam que o site já foi comprometido

Nem sempre a invasão é óbvia no primeiro dia. Às vezes o Google percebe antes do próprio dono do site, e o primeiro aviso chega por e-mail em vez de aparecer visualmente na tela.

• Queda repentina de tráfego orgânico, sem motivo aparente: geralmente porque o Google já rebaixou o site nos resultados de busca.
• Alerta no Google Search Console mencionando conteúdo enganoso ou site comprometido.
• Buscas pelo nome do site retornando páginas de cassino, réplicas de produtos ou farmácia, geralmente em outro idioma, mesmo que o conteúdo visível pareça normal para você.
• Arquivos novos e desconhecidos dentro da pasta de uploads, muitas vezes com extensão .php, onde só deveria haver imagens.
• Hospedagem suspendendo a conta por abuso de envio de e-mail, sinal de que o servidor está disparando spam sem o seu conhecimento.
• Usuários administradores no painel que você não criou, um dos sinais mais graves porque indica acesso persistente.

O que fazer nas primeiras horas depois de descobrir a invasão

O primeiro impulso é entrar em pânico. Resista. Siga uma ordem, porque apagar arquivos às pressas sem entender a origem do problema costuma resultar em reinfecção poucos dias depois.

• Colocar o site em modo de manutenção ou tirar do ar temporariamente, para impedir que o problema continue se espalhando enquanto você investiga.
• Trocar todas as senhas: hospedagem, FTP ou SSH, banco de dados e todos os usuários administradores do CMS. Trocar só a senha do admin do WordPress não resolve, porque o invasor pode ter acesso por outra porta.
• Restaurar um backup anterior à data estimada da infecção, comparando a data de modificação dos arquivos suspeitos com a data do backup.
• Rodar uma varredura de malware completa no servidor inteiro, não só no banco de dados ou nos arquivos do WordPress.
• Revisar a lista de plugins instalados e remover qualquer um que você não reconheça ou que esteja sem atualização há mais de um ano.
• Pedir reanálise no Google Search Console depois da limpeza, para acelerar a remoção do aviso de site comprometido nos resultados de busca.

Encontrar e fechar a porta de entrada é mais importante do que limpar os sintomas visíveis. Um site pode voltar ao ar limpo e ser reinfectado em 48 horas se a vulnerabilidade original, o plugin desatualizado ou a senha fraca, continuar aberta.

Prevenção que realmente reduz o risco de invasão

Prevenção custa muito menos do que recuperação, em tempo e em reputação. A lista abaixo não é teórica: é o que efetivamente fecha as portas mais usadas por bots.

• Atualizar núcleo, tema e plugins assim que uma nova versão sai, não meses depois.
• Ativar autenticação de dois fatores para todo usuário com acesso de administrador.
• Limitar tentativas de login e bloquear o IP depois de poucas falhas seguidas.
• Manter HTTPS ativo em cem por cento do site, incluindo o painel administrativo.
• Fazer backup automático diário, guardado fora do servidor de origem.
• Usar um firewall de aplicação, conhecido como WAF, na camada de hospedagem ou CDN.
• Revisar permissões de arquivo: nenhuma pasta deveria ter permissão 777.
• Reduzir o número de plugins ao mínimo necessário para o site funcionar.

Tema próprio reduz o risco, e o motivo é a superfície de ataque

Cada plugin instalado é código escrito por terceiros que você não auditou linha a linha. Quanto mais plugins, builders e integrações um site acumula, maior a superfície de ataque: mais lugares onde uma falha pode aparecer sem que ninguém perceba.

Um site com WordPress com tema próprio e código sob medida depende de menos dependências externas. Isso reduz diretamente a quantidade de componentes que precisam ser corrigidos toda vez que uma vulnerabilidade nova é divulgada. Não significa que o WordPress seja inseguro por natureza: o núcleo do WordPress tem equipe de segurança dedicada e ciclo de correção rápido. O problema costuma ser o acúmulo de plugins abandonados, temas genéricos cheios de funções que o site nunca usa e builders que injetam scripts de terceiros sem controle nenhum.

WordPress com tema próprio e código enxuto entrega performance máxima e, como consequência direta, menos pontos de falha para monitorar. Menos plugins também significa menos atualizações para acompanhar e menos chance de um deles ser abandonado pelo desenvolvedor original, o que é mais comum do que parece no ecossistema de plugins gratuitos.

Trocar de plataforma não é a solução automática. O que reduz risco é ter menos código de terceiros rodando sem manutenção, seja qual for o CMS por trás do site.

Quanto custa proteger, ou reconstruir, um site depois de um ataque

Não existe um preço único de conserto de site hackeado, porque o trabalho depende do tamanho do dano. Cada caso exige investigação forense antes de qualquer orçamento fechado, por isso esse serviço é sempre avaliado sob consulta. O que dá para afirmar, com segurança, é que reconstruir com poucas dependências desde o início tende a exigir menos horas de manutenção recorrente ao longo dos anos do que remendar, todo ano, um site cheio de plugins acumulados sem critério.

Para quem está construindo ou reconstruindo com essa base em mente, os valores de referência da Codech são:

• Site institucional: a partir de R$ 2.600
• Site sob medida, com código próprio: a partir de R$ 3.400
• SEO contínuo, que inclui monitoramento recorrente: a partir de R$ 350 por mês

Hospedagem e domínio são custos recorrentes de terceiros, cobrados à parte pelo provedor escolhido e variam conforme o plano contratado. Não são preço da Codech.

Se o seu site foi comprometido ou você quer evitar isso antes que aconteça, fale com a Codech pelo WhatsApp: (51) 99437-5953. Mais conteúdos como este estão disponíveis no blog da Codech.