"Microsoft Clairty" Não É o Microsoft Clarity: A Desofuscar um Script de Fraude em Anúncios com Typosquatting

Resumo: typosquat msclairty com eliminação do rtkclickid-store e cookie stuffing de afiliado pub=twsc

• Os feeds falharam: Toda a gente corre threat feeds e listas de bloqueio, mas o msclairty.com tinha zero deteções no VirusTotal em mais de 90 motores, nenhuma cobertura no urlscan ou no Safe Browsing, e devolvia 403 a cada ferramenta de IA e IP de datacenter que perguntava, portanto, o feed que se paga é exatamente a ferramenta que o atacante já contornou.
• A cside apanhou-o: A cside sinalizou o msclairty.com de forma autónoma, apenas com base no comportamento em tempo de execução, ao observar uma extensão exclusiva do Chrome a eliminar _ga, _gid e rtkclickid-store ao nível do caminho e do domínio raiz, a largar um iframe de 1x1 para o discounthero.org com pub=twsc, a sequestrar o window.fetch para bloquear o nivtrck.com, e a rodar IDs de campanha diariamente entre cinco variantes de payload type=.
• Demasiado recente para feeds: O certificado SSL foi emitido a 20 de fevereiro de 2026 e o tráfego ao vivo surgiu dez dias depois, a 2 de março. Os feeds de reputação não conseguem apanhar um domínio tão recente, pelo que a verdadeira questão é se a receita de afiliação compensa o preço de não observar o que os scripts fazem dentro do navegador.

Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.

Uma extensão de navegador está a injetar JavaScript ofuscado a partir de msclairty[.]com, um domínio com typosquatting que se faz passar pelo Microsoft Clarity. O script elimina cookies do Google Analytics, insere cookies de afiliados com o valor pub=twsc, injeta iframes ocultos para discounthero[.]org e sequestra a Fetch API. Surpreendentemente, nenhuma ferramenta de segurança sinaliza este domínio. Esta é a primeira documentação pública do msclairty[.]com.

O que é o msclairty[.]com?

msclairty[.]com é um domínio com typosquatting concebido para se fazer passar pelo Microsoft Clarity (msclarity[.]com / clarity[.]ms), a popular ferramenta de analítica e mapas de calor da Microsoft. Pense desta forma: as letras "i" e "r" em "clarity" são trocadas para "clairty", tornando-o subtil o suficiente para passar despercebido numa olhadela rápida a um registo de rede ou a uma tag de script, sem levantar suspeitas.

O domínio não serve analítica. Em vez disso, entrega um payload JavaScript ofuscado que realiza cookie stuffing de afiliados, eliminação de cookies de rastreio e sequestro da Fetch API dentro do navegador do visitante.

Como foi descoberto este script?

Nas últimas 48 horas, começámos a observar pedidos de rede para msclairty[.]com em vários sites não relacionados, na nossa telemetria. O primeiro pedido que registámos foi a 2 de março de 2026, às 21:17 UTC, com o tráfego a aumentar de forma acentuada durante a manhã de 3 de março. O tráfego não vem de uma tag de script comprometida no código-fonte da página. Em vez disso, é injetado por uma extensão de navegador. Ainda não identificámos a extensão específica responsável, mas o padrão de injeção é consistente em todos os sites afetados: o mesmo payload ofuscado, o mesmo domínio, o mesmo comportamento, independentemente do inventário de scripts do próprio site.

O denominador comum é o navegador do utilizador final, não o código-fonte do site.

Observámos o script a afetar sites em vários setores não relacionados, incluindo transportes (como plataformas de reserva de voos), plataformas SaaS (como ferramentas de gestão de projetos), portais de gestão desportiva e portais de pagamento governamentais. Os visitantes afetados abrangem várias versões do Chrome (132, 138 e 145) e têm origem em endereços IP dos EUA, tanto na costa Leste como na costa Oeste. Todos os sites afetados carregam o mesmo identificador de campanha do event.js e recebem o mesmo hash de payload, o que confirma tratar-se de uma única campanha coordenada, executada através de uma única extensão de navegador.

Os IDs de campanha rodam diariamente. Por exemplo, a 2 de março, o URL do loader era event.js?id=dHRcSiYkDj4&date=2026-03-02. A 3 de março, surgiu um novo ID de campanha: event.js?id=XGp2NSkTRVs&date=2026-03-03. O parâmetro date= corresponde à data de cada rotação de campanha. Isto significa que a infraestrutura é ativamente mantida e implementa novos identificadores de campanha todos os dias.

Todos os utilizadores afetados partilham o mesmo fingerprint. Em todos os pedidos da nossa telemetria, o perfil do navegador é idêntico: Windows 10 x64, Google Chrome de ambiente de trabalho, sem dispositivos móveis. Nenhum pedido vem do Firefox, Safari, Edge, Brave, macOS, Linux, Android ou iOS. Trata-se de uma extensão exclusiva do Chrome. Os client hints sec-ch-ua confirmam Chrome real (não forks do Chromium que reportam de forma diferente), e sec-ch-ua-mobile: ?0 confirma ambiente de trabalho em todos os pedidos. Observámos apenas 5 IPs de visitantes únicos em todos os sites afetados, todos em ligações residenciais dos EUA.

O ataque completo segue um padrão de carregamento em duas fases, no qual o servidor toma decisões de segmentação por pedido sobre qual o payload a entregar.

Fase 1: Script de carregamento (event.js)

hxxps://msclairty[.]com/event.js?id=dHRcSiYkDj4&date=2026-03-02
hxxps://msclairty[.]com/event.js?id=XGp2NSkTRVs&date=2026-03-03

O loader event.js tem 8.599 bytes. O parâmetro id= é um identificador de campanha que roda diariamente. A 2 de março, o ID de campanha era dHRcSiYkDj4. A 3 de março, mudou para XGp2NSkTRVs. O parâmetro date= corresponde à data de cada rotação. O primeiro loader que capturámos foi modificado pela última vez a 2 de março de 2026, às 09:58:50 GMT.

Desofuscámos o loader e descobrimos que este faz o seguinte:

1. Sequestro da consola. Sobrescreve todos os 7 métodos da consola (log, warn, info, error, exception, table, trace) imediatamente ao carregar, antes de qualquer payload ser executado. Isto significa que qualquer tentativa de depurar ou registar informação é silenciosamente bloqueada.
2. Verificação anti-iframe. Compara window.self com window.top e termina se o loader estiver a correr dentro de um iframe. Isto garante que só executa no contexto de navegação de topo, evitando ambientes de análise ou sandbox que usam iframes.
3. Verificação de cookie de deduplicação. Lê o cookie __tr_luptv através de um auxiliar getCookie(). Se o cookie já existir, o loader termina. Este cookie é definido pelo payload depois de ser acionado e serve dois propósitos: atribuição ao atacante para fraude de comissões e uma proteção "não executar duas vezes" que impede a execução repetida entre carregamentos de página.
4. Pedido de segmentação do lado do servidor. Envia um POST para msclairty[.]com com Content-Type: application/x-www-form-urlencoded, contendo quatro parâmetros: url (o URL da página atual), referrer (document.referrer), unique_id (o ID de campanha do parâmetro id=) e ext: 'twsc' (o identificador de afiliado do atacante, fixo no código). O servidor responde com JSON contendo um campo data (o nome de ficheiro codificado em Base64 para o payload) e um campo type (qual a variante ?type= a carregar).
5. Injeção dinâmica de payload. Constrói o URL da Fase 2 concatenando a resposta do servidor: https://msclairty[.]com/js/ + response.data + .js?type= + response.type, cria um elemento <script>, define o seu src para este URL e anexa-o a document.head. Isto carrega dinamicamente o payload malicioso com base nas instruções do servidor.
6. Hooks de navegação SPA. Faz um monkey-patch a history.pushState e history.replaceState para disparar eventos locationchange personalizados, e escuta o evento popstate. A cada navegação do lado do cliente numa aplicação de página única, o loader volta a executar a função Info() com o novo URL, dando ao servidor mais uma oportunidade de entregar um payload. Um debounce de 500ms (semáforo wait_nw) impede a reexecução rápida em mudanças de rota velozes.

É o servidor que decide o ataque, não o script. O loader envia o URL da página e o referrer, e o servidor responde tanto com o nome de ficheiro do payload codificado como com o valor ?type=. Isto significa que sites diferentes, páginas diferentes ou referrers diferentes podem receber variantes de payload diferentes. Por exemplo, uma página de produto pode receber type=1 (cookie stuffing silencioso), enquanto uma página de checkout pode receber type=5 (redireccionamento forçado). A lógica de segmentação é inteiramente do lado do servidor e invisível à análise do lado do cliente.

Fase 2: Payload ofuscado

hxxps://msclairty[.]com/js/[Base64-encoded-blob].js?type=[1-5]

O payload tem 10.007 bytes. O nome de ficheiro semelhante a Base64 é gerado do lado do servidor com base no URL da página e no referrer enviados pelo loader. O parâmetro ?type=, também escolhido pelo servidor, seleciona qual das cinco variantes de ataque é executada. A função dentro de cada payload tem um nome que corresponde à sua variante (type1(), type2(), type8(), type9(), type11()).

Que ferramentas de segurança sinalizam o msclairty[.]com?

Nenhuma. Verificámos todas as principais plataformas de inteligência de ameaças e ferramentas de segurança disponíveis. À data de publicação, nem uma única sinaliza o msclairty[.]com como malicioso:

• VirusTotal: 0 em mais de 90 motores de deteção
• urlscan.io: sem resultados de scan, sem submissões da comunidade
• Google Safe Browsing: não sinalizado
• SecurityTrails: sem histórico de DNS, sem enriquecimento de WHOIS
• ANY.RUN: sem submissões de sandbox para este domínio
• Hybrid Analysis / Falcon Sandbox: sem resultados
• PhishTank: não listado
• OpenPhish: não listado
• MalwareBazaar: sem amostras
• ThreatFox (abuse.ch): sem entradas de IOC
• Cloudflare Radar: sem dados

Trata-se de cobertura zero em todas as principais plataformas, e este artigo é a primeira documentação pública deste domínio a ser usado para fins maliciosos.

Como é que a cside detetou este script

A cside detetou este script de forma autónoma através de análise comportamental em tempo de execução. Nenhum feed de ameaças sinalizou o domínio. Nenhum scanner devolveu o payload. Nenhuma assinatura correspondeu. A deteção baseou-se inteiramente naquilo que o script fazia dentro do navegador: eliminar cookies de rastreio, injetar um iframe oculto, sequestrar a Fetch API e suprimir a consola.

Os scripts de extensões de navegador estão fora do seu controlo enquanto proprietário de um site. Não pode impedir que uma extensão injete código nas suas páginas. Mas ajuda saber que o abuso está a acontecer. Por exemplo, o script elimina o cookie de atribuição legítimo do RedTrack (rtkclickid-store) e substitui-o pelo próprio token de afiliado do atacante, pub=twsc, através da cadeia de redireccionamento de discounthero[.]org. Se usa o RedTrack para rastreio de conversões de afiliados ou depende de uma atribuição de tráfego precisa, este tipo de fraude rouba ativamente comissões dos seus afiliados legítimos, e nunca o veria sem visibilidade do lado do cliente.

Para o padrão de redireccionamento mais amplo, veja o nosso guia sobre sequestro de afiliados e sequestro de tráfego, que explica como os scripts injetados reescrevem links e encaminham cliques através de destinos de afiliados controlados por atacantes.

Use a cside para perceber como a sua aplicação se comporta no navegador. Detete sinais de fraude por parte de visitantes, agentes de IA e dependências do lado do cliente.

A cside partilhou esta informação com a Microsoft para que possam avançar com a remoção do msclairty[.]com por typosquatting malicioso da marca Clarity. Também contactámos o RedTrack, uma vez que o seu cookie de atribuição rtkclickid-store está a ser explicitamente visado para eliminação neste ataque, e o token de afiliado pub=twsc está a ser usado para substituir a atribuição legítima de cliques do RedTrack por reivindicações fraudulentas de comissão.

Comece gratuitamente ou marque uma demonstração para falar com a nossa equipa.

Por que razão as ferramentas de IA e os scanners recebem um 403 do msclairty[.]com?

O servidor por trás do msclairty[.]com corre num backend Express (Node.js), com Cloudflare à frente. Os cabeçalhos de resposta incluem x-powered-by: Express, cf-cache-status e access-control-allow-origin: *. O payload é colocado em cache pela Cloudflare com um max-age de 14400 segundos (4 horas).

Apesar de estar na Cloudflare, o servidor bloqueia ativamente a análise automatizada. Quando ferramentas com IA como o ChatGPT, o Claude e o Perplexity tentam obter conteúdo do domínio, o servidor devolve uma resposta 403 Forbidden. O mesmo acontece com scanners de segurança automatizados e com qualquer pedido proveniente de gamas de IP de datacenter.

Trata-se de uma filtragem deliberada, baseada em gamas de endereços IP, strings de user-agent ou outro tipo de fingerprinting de pedidos. O servidor só entrega o payload JavaScript malicioso quando o pedido parece vir de um navegador real, com o referrer, o user-agent e os cabeçalhos corretos. IPs de datacenter, user-agents de bots conhecidos e assinaturas de pedidos de ferramentas de IA são todos bloqueados.

Este comportamento anti-investigação também explica por que razão o VirusTotal, o urlscan.io e outras plataformas de scanning devolvem resultados limpos ou nenhum resultado. Nunca recebem o payload real.

O que revelam os cabeçalhos dos pedidos sobre a extensão msclairty[.]com?

Todos os pedidos na nossa telemetria partilham um fingerprint de navegador idêntico: Windows 10 x64, Google Chrome de ambiente de trabalho, sec-ch-ua-mobile: ?0. Não há um único pedido do Firefox, Safari, Edge, Brave ou de qualquer navegador móvel. Nenhum macOS, Linux, Android ou iOS.

Isto é significativo. Se a extensão estivesse disponível no ecossistema Chromium mais alargado, esperaríamos ver user-agents do Edge ou do Brave na mistura, já que ambos suportam extensões da Chrome Web Store. O facto de todos os pedidos reportarem "Google Chrome" nos client hints sec-ch-ua e nas strings padrão de user-agent do Chrome sugere que se trata de uma extensão exclusiva do Chrome, ou que, até agora, só foi instalada por utilizadores do Chrome.

Aparecem três versões do Chrome nos dados: 132, 138 e 145. O Chrome 132 foi lançado em janeiro de 2025 e já está desatualizado. O Chrome 138 e o 145 são mais recentes. A distribuição por várias versões afasta a hipótese de um exploit específico de uma versão e é consistente com uma extensão instalada voluntariamente que persiste através das atualizações do Chrome.

Outros padrões de cabeçalho a assinalar:

O cabeçalho sec-fetch-storage-access surge com os valores active e none nos carregamentos iniciais do script (sec-fetch-dest: script). Isto indica que a extensão interage com a Storage Access API, que rege o acesso a cookies entre sites. Isto é consistente com uma extensão que precisa de armazenamento entre sites para operar o seu mecanismo de cookie stuffing.

Todos os pedidos POST usam content-type: application/json, com valores de content-length variáveis, entre 604 e 10.246 bytes. Estes são os beacons do event.js a enviar dados de volta para o msclairty[.]com. Os tamanhos de payload variáveis sugerem que o script está a exfiltrar diferentes quantidades de dados da página ou da sessão, consoante o contexto de navegação.

O cabeçalho dnt: 1 (Do Not Track) está presente em pedidos de utilizadores do Chrome 145 e do Chrome 138, mas ausente no Chrome 132. Trata-se de uma preferência do utilizador, não de um comportamento da extensão, mas confirma que se trata de utilizadores reais, com navegadores configurados individualmente.

Quando foi registado o domínio msclairty[.]com?

O certificado SSL para msclairty[.]com foi emitido a 20 de fevereiro de 2026, às 20:14:54 UTC. Isto é apenas 10 dias antes de termos observado pela primeira vez tráfego ao vivo deste domínio, a 2 de março. Trata-se de um domínio recém-registado, criado propositadamente para esta campanha.

Os detalhes de registo do WHOIS estão ocultos atrás de um serviço de privacidade. Não existem registos históricos de DNS para este domínio no SecurityTrails nem em bases de dados de DNS passivo.

O que faz o script do msclairty[.]com?

Após a desofuscação, o script realiza seis ações distintas. Nenhuma delas tem qualquer relação com analítica ou mapas de calor.

Passo 1: Deteção de DevTools

O script verifica se as ferramentas de programador do navegador estão abertas antes de executar seja o que for. Compara window.outerWidth - window.innerWidth e window.outerHeight - window.innerHeight com um limiar de 120 pixels. Também verifica Firebug e window.chrome.isInitialized.

Se alguma verificação indicar que alguém está a inspecionar a página, o script termina de imediato. Só corre para utilizadores reais, nunca para programadores ou investigadores de segurança.

Passo 2: Sequestro da consola

O script sobrescreve sete métodos nativos da console: log, warn, info, error, exception, table e trace. Todos os sete são substituídos por funções vazias, sem efeito. Isto impede que apareçam avisos ou saída de depuração caso alguém abra as DevTools depois de o script já ter carregado.

Uma chamada separada a console.clear() é disparada num temporizador de 3 segundos, para apagar tudo o que possa ter sido registado antes de a sobreposição fazer efeito.

Passo 3: Eliminação de cookies de rastreio

O script elimina os seguintes cookies, tanto ao nível do caminho como ao nível do domínio raiz:

• _ga (ID de cliente do Google Analytics)
• _gid (ID de sessão do Google Analytics)
• rtkclickid-store (atribuição de cliques de afiliados do RedTrack)

Este é o comportamento mais importante a compreender. Ao eliminar o cookie rtkclickid-store do RedTrack, o script apaga a atribuição legítima de cliques de afiliados para esse visitante. Ao eliminar também os cookies do Google Analytics, remove qualquer prova de como o utilizador chegou ao site. A fonte de tráfego real do visitante desaparece por completo. Isto abre caminho para que o próprio token de afiliado do atacante (pub=twsc) se torne a única fonte de atribuição.

Passo 4: Injeção de iframe oculto e cookie stuffing de afiliados

Um iframe oculto de 1x1 pixel é injetado no corpo da página. O iframe carrega o seguinte URL:

hxxps://discounthero[.]org/us/s/red_u_plain.php?t=direct&s=287&d=[target]&pub=twsc

O iframe usa referrerpolicy="noreferrer" para suprimir o cabeçalho referrer.

Eis o que significa cada parâmetro do URL:

• t=direct: marcador de tipo de tráfego
• s=287: identificador de campanha
• d=[target]: o site a ser defraudado (o valor muda consoante o site vítima)
• pub=twsc: o ID de publisher afiliado do atacante

O valor pub=twsc é a conta de afiliado que recebe a comissão fraudulenta. Este é o núcleo do ataque. O iframe oculto carrega silenciosamente uma cadeia de redireccionamento através do discounthero[.]org que insere um cookie de afiliado no navegador do utilizador. Se o utilizador visitar mais tarde o site-alvo e fizer uma compra, o atacante por trás de pub=twsc ganha uma comissão que nunca gerou. A eliminação de cookies no passo 3 garante que não existe nenhuma atribuição concorrente.

Ao fim de 20 segundos, o iframe é removido do DOM. Não fica qualquer rasto visual na página.

Passo 5: Sequestro da Fetch API

Dentro do iframe injetado, o script faz um monkey-patch a window.fetch. Qualquer pedido fetch que contenha nivtrck[.]com (codificado como bml2dHJjay5jb20= em Base64) é silenciosamente bloqueado com uma Promise rejeitada.

Isto impede que um serviço de rastreio concorrente registe a fonte de tráfego real. O atacante não quer apenas o crédito pela visita; bloqueia ativamente outros rastreadores de captarem quaisquer dados de atribuição que possam entrar em conflito com o seu cookie fraudulento.

Passo 6: Supressão do referrer e cookie de rastreio do atacante

Uma tag <meta name="referrer" content="no-referrer"> é injetada no <head> da página, suprimindo os cabeçalhos referrer em todas as navegações de saída. Isto oculta a fraude da análise a jusante no site-alvo.

O script também define o seu próprio cookie de rastreio:

__tr_luptv = [timestamp atual menos 300000 milissegundos]

O valor do cookie é Date.now() - 300000 (hora atual menos 5 minutos), definido tanto no caminho raiz como no domínio raiz do site. Este timestamp retroativo provavelmente sinaliza à cadeia de redireccionamento do discounthero[.]org que o visitante já foi marcado e não deve ser processado novamente.

Como é ofuscado o script do msclairty[.]com?

O código usa uma pilha de ofuscação padrão, mas eficaz, que derrota a maioria das ferramentas de análise estática:

• Um array de strings rotacionado, contendo aproximadamente 95 entradas codificadas em Base64
• Uma função descodificadora que traduz índices do array em strings legíveis em tempo de execução
• Objetos proxy que envolvem chamadas de função e referências de strings atrás de nomes de propriedades aleatorizados
• Um ciclo de baralhamento IIFE que roda o array até um checksum corresponder, garantindo que o descodificador produz os valores corretos

O código ofuscado parece ruído aleatório. Nenhuma ferramenta de análise estática, scanner de assinaturas ou deteção baseada em expressões regulares identificará comportamento malicioso a partir do código-fonte em bruto. É preciso executar o descodificador para ver o que o script faz.

O que é o discounthero[.]org?

discounthero[.]org é o endpoint de redireccionamento de fraude de afiliados usado neste ataque. Ao contrário do msclairty[.]com, este domínio tem uma presença estabelecida em várias plataformas de inteligência de ameaças:

• Hospedado em infraestrutura da AWS no IP 3.68.5.1 (AS16509, AMAZON-02), geolocalizado na Alemanha
• Classificado como distribuidor de adware pela Gridinsoft
• Sinalizado como malicioso em análises de sandbox do ANY.RUN, com indicadores de phishing Tycoon 2FA
• Apareceu em relatórios de análise do Falcon Sandbox junto de domínios conhecidos de fraude publicitária
• Reportado por utilizadores em vários fóruns de navegadores como fonte de redireccionamentos de malvertising, incluindo incidentes nos fóruns da comunidade Daz3D
• Usa o endpoint de redireccionamento red_u_plain.php, com parâmetros por campanha (s=, d=, pub=, t=)
• A cadeia de redireccionamento passa por gracylifestyle[.]com (Cloudflare) até d33old9jdtt77h.cloudfront.net (Amazon CloudFront)

O que é o nivtrck[.]com?

nivtrck[.]com é o domínio de rastreio que o script bloqueia ativamente através do sequestro da Fetch API. Este domínio não tem qualquer documentação pública em nenhuma plataforma de inteligência de ameaças, relatórios de sandbox ou bases de dados de histórico de WHOIS. Pode ser um serviço de rastreio legítimo cuja atribuição o atacante quer suprimir, ou pode pertencer a uma operação de fraude concorrente.

Indicadores de compromisso (IOCs) do msclairty[.]com

Por que razão este ataque contorna as ferramentas de segurança tradicionais?

Este ataque contorna as ferramentas de segurança tradicionais por dois motivos: o vetor de injeção e as técnicas de evasão.

O script é injetado por uma extensão de navegador, não está embutido no código-fonte do site. Isto significa que os cabeçalhos de Content Security Policy não o vão bloquear. As auditorias de tags não o vão encontrar. As verificações de Subresource Integrity não se aplicam. As ferramentas de segurança do lado do servidor não têm qualquer visibilidade sobre o que uma extensão de navegador injeta na página em tempo de execução.

Para além disso, o servidor por trás do msclairty[.]com filtra pedidos de forma agressiva. Scanners de segurança, ferramentas de investigação com IA e qualquer pedido vindo de um IP de datacenter ou de um user-agent de bot conhecido recebem uma resposta 403 Forbidden. Mesmo que um scanner conseguisse, de alguma forma, obter o payload real, o código-fonte ofuscado não contém assinaturas reconhecíveis nem padrões maliciosos conhecidos que a análise estática pudesse sinalizar.

O script também evade a investigação manual. Deteta as DevTools abertas e termina. Sobrescreve todos os métodos da consola. Remove o iframe do DOM ao fim de 20 segundos. Limpa a consola ao fim de 3 segundos.

O loader acrescenta ainda outra camada: faz hook a history.pushState, history.replaceState e popstate para voltar a disparar a cada navegação do lado do cliente em aplicações de página única. Cada mudança de rota envia o novo URL ao servidor para uma nova segmentação. E como é o servidor que decide qual a variante de payload a entregar, com base no URL da página e no referrer, a análise estática de um único payload capturado não consegue revelar toda a gama de ataques de que a infraestrutura é capaz.

Como se deteta este tipo de ataque de cookie stuffing de afiliados?

A deteção baseada em listas de bloqueio não funciona contra este tipo de ataque. O domínio é demasiado recente para que qualquer feed de ameaças o tenha indexado. A ofuscação derrota a análise estática. O servidor bloqueia scanners automatizados e ferramentas de IA com respostas 403.

O único método de deteção fiável é a análise comportamental em tempo de execução: monitorizar o que os scripts fazem dentro do navegador, em vez de analisar o seu código-fonte ou verificar o seu domínio numa lista de bloqueio. A eliminação de cookies, a injeção de iframes ocultos, o sequestro da Fetch API e a supressão da consola são todos comportamentos observáveis claramente maliciosos, independentemente do aspeto do código-fonte ou da origem do carregamento do script.

É exatamente para isto que serve a monitorização de segurança do lado do cliente em tempo real.

O que significa o parâmetro ?type=?

O URL aceita um parâmetro de consulta ?type= que seleciona qual o payload de ataque devolvido pelo servidor. Confirmámos cinco variantes. Cada uma escala em agressividade. Todas as cinco partilham o mesmo núcleo de evasão: deteção de DevTools (termina se estiverem abertas, limiar de 150px), sequestro da consola (7 métodos sobrescritos), eliminação de cookies (_ga, _gid, rtkclickid-store, ao nível do caminho e do domínio raiz), cookie de atribuição do atacante (__tr_luptv = Date.now() - 300000), supressão do referrer via meta tag, e o mesmo alvo de afiliado (discounthero[.]org com pub=twsc e s=287).

O valor do parâmetro ?type= (1 a 5) é sequencial, mas os nomes das funções internas não são. Esta discrepância revela a verdadeira escala da infraestrutura.

?type=1 (função type1()) - Cookie stuffing silencioso de afiliados

Injeta um iframe oculto de 1x1 para discounthero[.]org com pub=twsc. O iframe carrega a cadeia de redireccionamento de afiliados, insere o cookie do atacante e autodestrói-se ao fim de 20 segundos. A Fetch API é sequestrada para bloquear pedidos para nivtrck[.]com. O visitante não vê nada.

?type=2 (função type2()) - Cookie stuffing + injeção de conteúdo

Faz tudo o que o type=1 faz. Depois procura um segundo URL a partir de uma variável de template do lado do servidor {{link2}}, cria um segundo iframe oculto de 0x0, escreve o HTML obtido dentro dele com contentWindow.document.write() e falsifica o URL do iframe com history.replaceState. O segundo iframe autodestrói-se ao fim de 15 segundos. O placeholder {{link2}} é preenchido do lado do servidor por alvo e pode entregar sobreposições de phishing, injeção de anúncios ou manipulação da página.

?type=3 (função type8()) - Sequestro de cliques (piggyback)

Sem iframe. Instala um listener de eventos de clique em document.body. Quando um visitante clica em qualquer tag <a> com um href começado por "http", o script chama preventDefault() e, em seguida, redireciona o navegador para o URL original, com o redireccionamento de afiliado do discounthero[.]org anexado como parâmetro de consulta. O utilizador continua a chegar ao destino pretendido, mas a navegação passa pela cadeia de redireccionamento do atacante no percurso.

?type=4 (função type9()) - Sequestro de cliques (redireccionamento direto)

A mesma interceção de cliques que o type=3, mas com a direção do redireccionamento invertida. Em vez de anexar o URL de afiliado ao destino original, envia o utilizador diretamente para discounthero[.]org, com o URL original codificado como parâmetro através de encodeURIComponent(). O utilizador navega visivelmente primeiro pela infraestrutura do atacante e só depois é encaminhado para o destino pretendido, após o cookie de afiliado ter sido inserido.

?type=5 (função type11()) - Redireccionamento automático (sem clique necessário)

A variante mais agressiva. Sem iframe. Sem interceção de cliques. Ao fim de um atraso de 400 milissegundos, o script redireciona forçosamente a página inteira usando window.location.search. O utilizador é automaticamente afastado da página que estava a ver e enviado para a cadeia de afiliados do discounthero[.]org. Não é necessária qualquer interação. O atraso de 400ms é apenas o suficiente para que a eliminação de cookies e a definição do cookie __tr_luptv aconteçam antes de o redireccionamento disparar.

Os nomes das funções não são sequenciais. O parâmetro ?type= vai de 1 a 5, mas as funções chamam-se type1, type2, type8, type9 e type11. Valores acima de 5 devolvem respostas em branco. As lacunas na numeração das funções (type3 a type7, type10) refletem provavelmente variantes retiradas ou descontinuadas de iterações anteriores desta infraestrutura. Cinco tipos de payload ativos, escalando do silencioso ao forçado.

Como funciona o ataque de typosquatting ao Microsoft Clarity

O typosquatting é um padrão de ataque em que um script malicioso é hospedado num URL quase idêntico a um legítimo, trocando letras, transpondo carateres ou omitindo uma vogal. O script Microsoft "Clairty" (falta um "a") é um exemplo clássico.

A cadeia de ataque costuma seguir este percurso:

• Um atacante regista um domínio visualmente semelhante ao de um fornecedor de confiança (microsoft-clairty.[tld] em vez de microsoft-clarity.com).
• O atacante hospeda nesse domínio um payload de fraude publicitária, de recolha de credenciais ou ao estilo Magecart.
• Um programador copia um excerto de tag manager de uma fonte comprometida (ou de um e-mail de phishing) que referencia o domínio com typosquatting em vez do real.
• O script malicioso passa a carregar dentro do contexto do navegador de cada utilizador que visita a página afetada.

A monitorização de scripts em tempo de execução capta isto porque o comportamento e o domínio de alojamento do script carregado diferem do script Microsoft Clarity aprovado. Consulte a nossa solução de segurança do lado do cliente para conhecer a camada de deteção ao nível do navegador que capta este tipo de ataques de domínios semelhantes.