Entendendo as aquisições de subdomínio: Um guia prático para SEOs

O sequestro de subdomínio não é um tópico comum nas discussões sobre SEO, mas pode ter um efeito direto e prejudicial nas classificações. Este artigo compartilha minha própria experiência com o problema, juntamente com o processo que agora sigo para verificar se há subdomínios vulneráveis durante as auditorias técnicas.

Um breve histórico

Pouco tempo depois de passar de uma função geral de SEO para uma posição puramente técnica, recebi uma temida notificação no Search Console:

“Ação manual aplicada – conteúdo hackeado detectado”

O URL sinalizado era uma promoção de feriado esquecida hospedada em christmas.client.co.uk. Meu gerente não tinha ideia do que se tratava, e eu também não. Depois de algumas pesquisas (e um pouco de pesquisa frenética no Google), percebi que se tratava de um subdomínio de uma campanha antiga que estava se deteriorando. Desde então, ele havia sido reaproveitado por outra pessoa para enviar conteúdo com spam.

Felizmente, o cliente era ágil e tecnicamente experiente, e conseguimos remover o problema em poucas horas. Mas o incidente me fez pensar: quantos outros subdomínios negligenciados podem estar à espreita, sem serem notados, prontos para serem assumidos?

O que de fato aconteceu

Uma aquisição de subdomínio ocorre quando o registro DNS aponta para um serviço de terceiros (por exemplo, GitHub Pages, Heroku, AWS etc.) e esse serviço não está mais em uso, mas a entrada DNS ainda existe.

Um invasor pode reivindicar o recurso abandonado nessa plataforma e fornecer instantaneamente seu próprio conteúdo em seu subdomínio.

No meu caso, o antigo microsite “calendário do advento” havia sido muito promovido anos antes. Quando ele foi abandonado, o DNS permaneceu ativo, criando uma oportunidade de exploração. O sequestrador aproveitou a autoridade e os backlinks existentes no subdomínio, usando-o para anunciar um site de cassino.

Isso está longe de ser raro. Incidentes semelhantes afetaram portais governamentais, grandes marcas e até mesmo sites de alta autoridade nos quais os modelos de IA costumam confiar cegamente.

Por que os profissionais de SEO devem se preocupar

Não se espera que você seja um especialista em segurança cibernética. Mas subdomínios comprometidos podem acionar ações manuais, passar autoridade para sites mal-intencionados e desfazer meses ou anos de trabalho de otimização. Muitas vulnerabilidades vêm de projetos antigos que ninguém se lembra de ter configurado.

O Google trata os subdomínios como propriedades separadas em muitos aspectos, mas os links entre eles ainda podem transferir autoridade. Se um subdomínio negligenciado for invadido e seu site principal for vinculado a ele, você estará basicamente confirmando o conteúdo do invasor. É por isso que as verificações periódicas de subdomínio devem fazer parte de sua rotina de auditoria técnica.

Processo de investigação

Descubra os subdomínios existentes

Use ferramentas como ViewDNS ou DNSDumpster. Esteja ciente dos limites de pesquisa; se um cliente tiver dezenas ou centenas de subdomínios, vale a pena sinalizar a possibilidade de ativos legados ou não utilizados.

Identifique as plataformas de hospedagem

Verifique a hospedagem com ferramentas como WhatCMS ou o comando dig do Google. Além disso, evite visitar diretamente um link comprometido.

Avalie a vulnerabilidade

Compare as plataformas de hospedagem com serviços conhecidos propensos a invasões, como AWS (Elastic Beanstalk/S3), GitHub Pages, Heroku, Shopify, Ghost, Microsoft Azure, Agile CRM, WordPress.com e JetBrains. Use o ViewDNS para encontrar subdomínios, o Wappalyzer para traçar o perfil deles e comparar os resultados com listas de vulnerabilidades disponíveis publicamente.

Se você encontrar um subdomínio vulnerável

Se ele estiver vinculado a uma das plataformas de alto risco e não for utilizado (ou estiver planejado para ser encerrado), coordene com quem gerencia o DNS para remover ou reposicionar o registro. Embora os SEOs não sejam diretamente responsáveis pelas configurações do servidor, conscientizar as partes interessadas sobre as implicações de segurança e de SEO geralmente ajuda a priorizar o problema.

Não sou um testador de penetração, apenas um técnico de SEO que já se deparou com esse problema várias vezes para perceber o valor das verificações proativas. Incluir essa etapa nas auditorias pode evitar dores de cabeça mais tarde.

Exemplo do mundo real: EY.com

Um exemplo recente, compartilhado por Michael Curtis no LinkedIn, envolveu um subdomínio da EY hospedado no Microsoft Azure. O recurso do Azure foi excluído, mas a entrada do DNS permaneceu.

Um invasor registrou um novo aplicativo do Azure com o mesmo nome de host usado anteriormente pelo subdomínio da EY. Como o DNS ainda apontava para lá, ele conseguiu fornecer conteúdo explícito sob o domínio confiável da EY.

Isso não é um “hack” no sentido tradicional, mas um uso oportunista de entradas de DNS abandonadas. O invasor não violou os sistemas internos; ele simplesmente reivindicou um nome desprotegido e herdou o tráfego e a confiança que vieram com ele.