Conteudo invadido: o que acontece de verdade quando o proprio site, e nao um anunciante, e o comprometido

O primeiro sinal raramente vem de alguem oficial. Sao alguns enderecos estranhos no Search Console que ninguem da equipe lembra de ter criado, ou o trafego organico que cai sem causa visivel nos paineis de sempre, ou um anunciante que escreve perguntando por que a pagina do seu anuncio redireciona para algo que nao tem nada a ver com o site. As vezes e um visitante avisando que o navegador se recusou a abrir a pagina. Nada disso parece fraude de anunciante, e nada se parece com o caso do anuncio malicioso que faz um site ser marcado sem que seu proprio codigo tenha culpa alguma.

Este e o outro caso, e e um problema diferente com uma solucao diferente. Aqui, algo foi de fato adicionado aos arquivos ou ao banco de dados do site sem que ninguem da equipe o tivesse colocado ali. Um diretorio dessa categoria nao pode se dar ao luxo de parecer pouco confiavel nem por uma semana: nem para o Google, nem para um processador de pagamentos que ja trata o setor como mais arriscado que a media, nem para uma hospedagem que pode estar a uma reclamacao de distancia de suspender a conta. Saber exatamente o que aconteceu, o que o Google realmente verifica e em que ordem a solucao realmente funciona vale mais aqui do que valeria para o blog de uma pequena empresa qualquer, porque o custo de errar a ordem e maior.

Como um atacante entra de verdade, e raramente e algo dramatico

Nesse nivel, quase ninguem mira especificamente um diretorio de classificados adultos. O padrao comum e um bot varrendo a web aberta em busca de qualquer site rodando um determinado software com uma falha conhecida e nao corrigida, da mesma forma que varre sites de restaurantes ou blogs de escritorios de advocacia. O site e atingido porque, por acaso, roda o mesmo CMS, o mesmo plugin ou a mesma biblioteca desatualizada que um milhao de outros sites, nao porque alguem o observou e decidiu que valia o esforco.

Software desatualizado e um fator real e comum, mas nao e toda a historia, e trata-lo como se fosse deixa metade dos pontos de entrada reais descobertos. O relatorio de sites invadidos da Sucuri, sobre sites limpos em 2023, constatou que 39,1% das instalacoes de CMS comprometidas rodavam software desatualizado no momento da infeccao, uma queda em relacao aos 50,58% do ano anterior. O mesmo relatorio constatou que apenas cerca de 14% desses sites ainda tinham um plugin ou tema vulneravel identificavel quando a Sucuri examinou de perto a remediacao. Em outras palavras, a maioria dos sites que ela limpou nao foi invadida de fato pela falha de software que um operador esperaria ter que corrigir primeiro.

A outra metade do quadro sao as credenciais. O Data Breach Investigations Report 2025 da Verizon, que olha para todos os setores que acompanha e nao apenas para sites, encontrou credenciais roubadas ou adivinhadas ligeiramente a frente de vulnerabilidades de software exploradas como a forma pela qual atacantes conseguem seu primeiro ponto de apoio: 22% das violacoes contra 20%. Nao e um numero construido apenas com sites de classificados, mas bate com o que a Sucuri observa em limpezas especificamente de plataformas CMS. Uma senha administrativa reutilizada de uma conta de email pessoal que vazou num incidente sem relacao anos antes e, na pratica, uma via de entrada tao provavel quanto um plugin desatualizado.

A consequencia pratica e que proteger um site e um trabalho em duas frentes de peso quase igual, nao uma so. Um calendario de atualizacoes fecha metade das brechas de software. Uma disciplina separada sobre quem tem acesso, qual e de fato a senha e se ela e reutilizada em outro lugar fecha a outra metade. Um operador que apenas mantem os plugins atualizados fez metade do trabalho e pode nunca perceber, porque a tela de aviso aparece identica independentemente de qual metade foi pulada.

Como o Google realmente chama isso, e por que e um problema diferente de um anuncio malicioso

Um tipo diferente de aviso do Chrome ja foi tratado aqui: aquele em que uma rede de anuncios contratada veicula uma criatividade enganosa ou maliciosa pelos proprios espacos publicitarios do site, e o Google marca o site por um conteudo que nunca tocou. Este nao e esse caso. Aqui, algo foi adicionado as paginas ou ao banco de dados do site sem o conhecimento do operador, que e exatamente o que as politicas antispam do Google definem como conteudo invadido: conteudo colocado em um site sem a permissao do proprietario, por causa de uma fragilidade na propria seguranca do site.

A documentacao do Google distingue tres padroes especificos. Injecao de codigo e codigo malicioso, geralmente JavaScript, inserido diretamente em paginas ou iframes ja existentes. Injecao de paginas sao paginas novas adicionadas ao site que antes nao existiam, construidas para manipular o posicionamento em buscadores ou conduzir uma tentativa de phishing, enquanto as paginas que um visitante ja conhecia muitas vezes nao mostram nenhum sinal visivel de que algo esta errado. Injecao de conteudo e ainda mais sutil: texto ou links ocultos adicionados a paginas existentes por meio de truques de CSS ou HTML, visiveis para o rastreador de um buscador mas nao para uma pessoa olhando a mesma pagina no navegador.

Injecao de paginas costuma ser o padrao que os operadores descobrem por ultimo, e vale entender por que um atacante se da ao trabalho de fazer isso em vez de simplesmente construir um site descartavel proprio. Um dominio que ja tem historico, backlinks existentes e uma posicao consolidada nos resultados de busca lava conteudo de spam para dentro do ranking muito mais rapido do que faria um dominio novo em folha, entao os atacantes preferem emprestar a reputacao de um site existente a construir a sua do zero. E um mecanismo diferente do ataque externo baseado em links tratado em outro lugar: la, o ataque aponta links de outros sites para o alvo de fora; aqui, as paginas de spam sao construidas para viver no proprio dominio do alvo, dentro da sua propria estrutura de arquivos.

Uma vez que esse conteudo existe no site, as consequencias se acumulam. O relatorio de Problemas de seguranca do Search Console marca a propriedade diretamente, algumas paginas podem ser suprimidas dos resultados ou substituidas por um aviso na listagem, e o Safe Browsing do Chrome pode comecar a mostrar aos visitantes a mesma tela vermelha interstitial ja descrita para o caso da rede de anuncios, desta vez acionada porque o site realmente hospeda conteudo malicioso ou enganoso, nao por uma criatividade defeituosa que passa por ele.

Conseguir tirar o aviso: a ordem que realmente funciona

A orientacao do proprio Google e especifica quanto a ordem, e a maior parte do tempo perdido na pratica vem de fazer esses passos fora de sequencia. O primeiro trabalho e encontrar e remover cada instancia do conteudo injetado, nao apenas a pagina de amostra que o Search Console citou como exemplo do problema. Aquele endereco e uma amostra, nao um inventario, e uma limpeza que para depois de corrigi-lo costuma deixar a maior parte da injecao real intacta.

O segundo trabalho e descobrir como o atacante entrou e fechar exatamente essa brecha, seja um plugin desatualizado, uma credencial vazada ou uma permissao mal configurada, porque apagar as paginas de spam sem corrigir o ponto de entrada apenas zera o relogio ate que o mesmo atacante, ou a mesma varredura automatizada, volte pela mesma porta. A documentacao do Google e explicita de que a correcao precisa cobrir o site inteiro, nao so a pagina inicial ou a pagina que um visitante denunciou, e uma parte relacionada do mesmo guia recomenda trocar toda senha ligada a uma conta com acesso administrativo: o login do CMS, o painel de controle da hospedagem, FTP ou SFTP, e o banco de dados, precisamente porque o ponto de entrada costuma ser um desses e nao a pagina onde o sintoma apareceu.

A parte que os operadores mais erram e quando pedir ao Google para olhar de novo. Pedir uma revisao antes que a limpeza acima descrita esteja realmente concluida nao acelera nada; o Google diz claramente que pedir uma revisao enquanto o problema ainda existe so prolonga o tempo em que o site fica marcado. Os prazos de revisao variam por categoria: uma revisao de malware simples geralmente leva poucos dias, uma de phishing cerca de um dia, mas uma revisao de conteudo invadido que inclui paginas de spam injetadas pode levar ate varias semanas, porque o Google trata essa categoria como uma que pode exigir uma analise de fato manual em vez de uma reverificacao automatica.

Uma segunda rodada do mesmo aviso depois que uma revisao ja passou geralmente e sinal de que o ponto de entrada nunca foi de fato fechado na primeira vez, so o sintoma. Apagar as paginas de spam visiveis parece encerrar o trabalho, mas se o plugin vulneravel ainda esta la ou a senha vazada ainda funciona, a mesma brecha e reutilizada, as vezes dentro de poucos dias depois de o aviso ser removido.

O que realmente previne isso, com um orcamento que esse negocio consegue sustentar

Nada disso exige contratar uma equipe de seguranca dedicada, e os operadores que pulam o basico geralmente fazem isso porque a lista parece maior do que realmente e. O CMS, seu tema e cada plugin instalado precisam de um calendario fixo de atualizacao, verificado toda semana em vez de "quando houver tempo", e tudo que foi instalado uma vez e nao e mais usado deveria ser removido por completo em vez de deixado adormecido, porque um plugin inativo continua sendo uma porta que nunca foi trancada.

A disciplina de credenciais pesa tanto quanto as atualizacoes, dado o que os numeros da Sucuri e da Verizon citados acima de fato mostram. Isso significa uma senha unica para cada conta que possa tocar o site, gerada e guardada num gerenciador de senhas em vez de memorizada, autenticacao de dois fatores ativada em todo login que a oferecer, e nenhum login compartilhado passado entre equipe ou moderadores, ja que um login compartilhado tambem e um acesso que ninguem consegue rastrear ate uma pessoa especifica quando algo da errado.

Backups importam tanto quanto a prevencao, porque sao o que traz um site de volta ao ar em horas em vez de esperar uma revisao do Google que pode levar semanas. Um backup que vive na mesma conta de hospedagem do site que deveria proteger nao e grande coisa como backup, ja que um atacante com acesso administrativo geralmente consegue alcanca-lo tambem; uma copia guardada em outro lugar, e de fato testada restaurando-a pelo menos uma vez em vez de deixada rodando sem verificacao, e a diferenca entre uma semana ruim e um mes ruim.

A ultima peca e simplesmente descobrir cedo. Os alertas por email do Search Console fazem o relatorio de Problemas de seguranca chegar numa caixa de entrada que alguem realmente le, em vez de o operador descobrir o problema pela reclamacao de um visitante ou por uma sangria lenta de trafego organico dias ou semanas depois. Nenhum desses passos custa mais que tempo, e todos saem mais baratos feitos agora do que depois que a tela de aviso ja consumiu uma semana de trafego enquanto a limpeza e resolvida.

A ordem, se o aviso ja apareceu, e limpar tudo primeiro, fechar a brecha especifica que permitiu aquilo, e so entao pedir ao Google para olhar de novo, nunca o contrario. A ordem, se nada aconteceu ainda, e fazer mesmo assim as mesmas quatro coisas num calendario nesta semana: atualizar o que esta instalado, trocar toda senha com acesso administrativo, ativar autenticacao de dois fatores onde for oferecida, e testar uma restauracao real a partir do backup. De qualquer forma, a solucao nunca teve a ver com a jurisdicao do certificado nem com o tamanho do escritorio de advocacia contratado: tem a ver com quem consegue fazer login, com o quanto o software esta atualizado, e com se alguem perceberia a tempo.