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

Uma extensão de navegador está injetando JavaScript ofuscado de msclairty[.]com, um domínio com typosquatting que se passa pelo Microsoft Clarity. O script exclui 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 esse domínio. Esta é a primeira documentação pública de msclairty[.]com.

O que é msclairty[.]com?

msclairty[.]com é um domínio com typosquatting projetado para se passar pelo Microsoft Clarity (msclarity[.]com / clarity[.]ms), a popular ferramenta de analytics e heatmap da Microsoft. Pense assim: as letras "i" e "r" em "clarity" são trocadas para "clairty", tornando-o sutil o suficiente para passar despercebido em um log de rede ou tag de script sem levantar suspeitas.

O domínio não está servindo analytics. Em vez disso, ele entrega um payload JavaScript ofuscado que realiza cookie stuffing de afiliados, exclusão de cookies de rastreamento e sequestro da Fetch API dentro do navegador do visitante.

Como esse script foi descoberto?

Nas últimas 48 horas, começamos a observar requisições de rede para msclairty[.]com em múltiplos sites não relacionados em nossa telemetria. A primeira requisição que registramos foi em 2 de março de 2026 às 21:17 UTC, com o tráfego aumentando rapidamente durante a manhã do dia 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, uma extensão de navegador o injeta. Ainda não identificamos a extensão específica responsável, mas o padrão de injeção é consistente em todos os sites afetados: mesmo payload ofuscado, mesmo domínio, mesmo comportamento, independentemente do inventário de scripts do próprio site.

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

Observamos o script afetando sites em múltiplos setores não relacionados, incluindo transporte (como plataformas de reserva de passagens aéreas), plataformas SaaS (como ferramentas de gerenciamento de projetos), portais de gestão esportiva e portais de pagamento governamentais. Os visitantes afetados abrangem múltiplas versões do Chrome (132, 138 e 145) e se originam de endereços IP dos EUA nas costas Leste e Oeste. Todos os sites afetados carregam o mesmo identificador de campanha event.js e recebem o mesmo hash de payload, confirmando que se trata de uma única campanha coordenada executada por meio de uma extensão de navegador.

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

Todos os usuários afetados compartilham o mesmo fingerprint. Em todas as requisições em nossa telemetria, o perfil do navegador é idêntico: Windows 10 x64, Google Chrome para desktop, sem dispositivos móveis. Nem uma única requisição vem do Firefox, Safari, Edge, Brave, macOS, Linux, Android ou iOS. Esta é uma extensão exclusiva para Chrome. Os client hints sec-ch-ua confirmam o Chrome real (não forks do Chromium que reportam de forma diferente), e sec-ch-ua-mobile: ?0 confirma desktop em todas as requisições. Observamos apenas 5 IPs de visitantes únicos em todos os sites afetados, todos em conexões residenciais dos EUA.

O ataque completo segue um padrão de carregamento em dois estágios, onde o servidor toma decisões de segmentação por requisição sobre qual payload entregar.

Estágio 1: Script loader (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 rotaciona diariamente. Em 2 de março, o ID de campanha era dHRcSiYkDj4. Em 3 de março, mudou para XGp2NSkTRVs. O parâmetro date= corresponde à data de cada rotação. O primeiro loader que capturamos foi modificado pela última vez em 2 de março de 2026 às 09:58:50 GMT.

Desofuscamos o loader e descobrimos que ele faz o seguinte:

1. Sequestro do console. Ele sobrescreve todos os 7 métodos do console (log, warn, info, error, exception, table, trace) imediatamente ao carregar, antes de qualquer payload ser executado. Isso significa que qualquer tentativa de depurar ou registrar informações é silenciosamente bloqueada.
2. Verificação anti-iframe. Ele compara window.self com window.top e encerra se o loader estiver sendo executado dentro de um iframe. Isso garante que ele só seja executado no contexto de navegação de nível superior, evitando ambientes de análise ou sandbox que usam iframes.
3. Verificação de cookie de deduplicação. Ele lê o cookie __tr_luptv usando um helper getCookie(). Se o cookie já existir, o loader encerra. Esse cookie é definido pelo payload após ser acionado e serve a dois propósitos: atribuição do atacante para fraude de comissão e uma proteção "não execute duas vezes" que impede a execução repetida entre carregamentos de página.
4. Requisição de segmentação no lado do servidor. Ele envia um POST para msclairty[.]com com Content-Type: application/x-www-form-urlencoded contendo quatro parâmetros: url (a 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, hardcoded). O servidor responde com JSON contendo um campo data (o nome do arquivo codificado em Base64 para o payload) e um campo type (qual variante ?type= carregar).
5. Injeção dinâmica de payload. Ele constrói a URL do Estágio 2 concatenando a resposta do servidor: https://msclairty[.]com/js/ + response.data + .js?type= + response.type, cria um elemento ` O loader envia a URL da página e o referrer, e o servidor responde com o nome do arquivo de payload codificado e o valor ?type=. Isso significa que sites diferentes, páginas diferentes ou referrers diferentes podem receber variantes de payload distintas. Por exemplo, uma página de produto pode receber type=1 (cookie stuffing silencioso) enquanto uma página de checkout pode receber type=5 (redirecionamento forçado). A lógica de segmentação é inteiramente no lado do servidor e invisível para análise no lado do cliente.

   Estágio 2: Payload ofuscado

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

   O payload tem 10.007 bytes. O nome de arquivo semelhante a Base64 é gerado no lado do servidor com base na 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 será executada. A função dentro de cada payload é nomeada para corresponder à sua variante (type1(), type2(), type8(), type9(), type11()).

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

   Nenhuma delas. Verificamos todas as principais plataformas de inteligência de ameaças e ferramentas de segurança disponíveis. Até a data de publicação, nenhuma sinaliza msclairty[.]com como malicioso:

   • VirusTotal: 0 de 90+ detecções de engines
   • 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

   Cobertura zero em todas as principais plataformas. Em termos simples, este post é a primeira documentação pública deste domínio sendo usado para fins maliciosos.

   Como a cside detectou esse script

   A cside detectou esse script de forma autônoma por meio de análise comportamental em tempo de execução. Nenhum feed de ameaças sinalizou o domínio. Nenhum scanner retornou o payload. Nenhuma assinatura correspondeu. A detecção foi baseada inteiramente no que o script fez dentro do navegador: excluindo cookies de rastreamento, injetando um iframe oculto, sequestrando a Fetch API e suprimindo o console.

   Scripts de extensões de navegador estão além do seu controle como proprietário de um site. Você não pode impedir que uma extensão injete código em suas páginas. Mas é importante saber que o abuso está ocorrendo. Por exemplo, o script exclui o cookie de atribuição legítimo do RedTrack (rtkclickid-store) e o substitui pelo token de afiliado do próprio atacante pub=twsc por meio da cadeia de redirecionamento de discounthero[.]org. Se você usa o RedTrack para rastreamento de conversão de afiliados ou depende de atribuição precisa de tráfego, esse tipo de fraude rouba ativamente comissões dos seus afiliados legítimos e você nunca veria isso sem visibilidade no lado do cliente.

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

   A cside compartilhou essa inteligência com a Microsoft para que ela possa buscar a remoção de msclairty[.]com por typosquatting malicioso da marca Clarity. Também entramos em contato com o RedTrack, pois o cookie de atribuição rtkclickid-store deles está sendo explicitamente visado para exclusão neste ataque e o token de afiliado pub=twsc está sendo usado para substituir a atribuição legítima de cliques do RedTrack por reivindicações fraudulentas de comissão.

   Comece gratuitamente ou agende uma demonstração para falar com nossa equipe.

   Por que ferramentas de IA e scanners recebem um 403 de msclairty[.]com?

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

   Apesar de estar no Cloudflare, o servidor bloqueia ativamente a análise automatizada. Quando ferramentas com IA como ChatGPT, Claude e Perplexity tentam buscar conteúdo do domínio, o servidor retorna uma resposta 403 Forbidden. O mesmo acontece com scanners de segurança automatizados e qualquer requisição originada de faixas de IP de datacenter.

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

   Esse comportamento anti-pesquisa também explica por que o VirusTotal, urlscan.io e outras plataformas de scanning retornam resultados limpos ou nenhum resultado. Eles nunca recebem o payload real.

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

   Todas as requisições em nossa telemetria compartilham um fingerprint de navegador idêntico: Windows 10 x64, Google Chrome para desktop, sec-ch-ua-mobile: ?0. Não há uma única requisição do Firefox, Safari, Edge, Brave ou qualquer navegador móvel. Nenhum macOS, Linux, Android ou iOS.

   Isso é significativo. Se a extensão estivesse disponível no ecossistema Chromium mais amplo, esperaríamos ver user-agents do Edge ou Brave na mistura, já que ambos suportam extensões da Chrome Web Store. O fato de que todas as requisições reportam "Google Chrome" nos client hints sec-ch-ua e nas strings padrão de user-agent do Chrome sugere que esta é uma extensão exclusiva para Chrome ou que até agora só foi instalada por usuários do Chrome.

   Três versões do Chrome aparecem nos dados: 132, 138 e 145. O Chrome 132 foi lançado em janeiro de 2025 e está desatualizado. O Chrome 138 e 145 são mais recentes. A distribuição entre versões descarta um exploit específico de versão e é consistente com uma extensão instalada voluntariamente que persiste entre atualizações do Chrome.

   Outros padrões de cabeçalho notáveis:

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

   Todas as requisições POST usam content-type: application/json com valores variados de content-length que vão de 604 a 10.246 bytes. Esses são os beacons do event.js enviando dados de volta para msclairty[.]com. Os tamanhos variados de payload sugerem que o script está exfiltrando diferentes quantidades de dados de página ou sessão dependendo do contexto de navegação.

   O cabeçalho dnt: 1 (Do Not Track) está presente em requisições de usuários do Chrome 145 e Chrome 138, mas ausente no Chrome 132. Esta é uma preferência do usuário, não um comportamento da extensão, mas confirma que são usuários reais com navegadores configurados individualmente.

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

   O certificado SSL para msclairty[.]com foi emitido em 20 de fevereiro de 2026 às 20:14:54 UTC. Isso é apenas 10 dias antes de observarmos pela primeira vez tráfego ao vivo deste domínio em 2 de março. Este é um domínio recém-registrado, criado especificamente para esta campanha.

   Os detalhes de registro WHOIS estão ocultos por um serviço de privacidade. Não existem registros históricos de DNS para este domínio no SecurityTrails ou em bancos de dados de DNS passivo.

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

   Após a desofuscação, o script realiza seis ações distintas. Nenhuma delas tem qualquer relação com analytics ou heatmaps.

   Passo 1: Detecção do DevTools

   O script verifica se as ferramentas de desenvolvedor do navegador estão abertas antes de executar qualquer coisa. Ele compara window.outerWidth - window.innerWidth e window.outerHeight - window.innerHeight contra um limite de 120 pixels. Também verifica Firebug e window.chrome.isInitialized.

   Se qualquer verificação indicar que alguém está inspecionando a página, o script encerra imediatamente. Ele só é executado para usuários reais, nunca para desenvolvedores ou pesquisadores de segurança.

   Passo 2: Sequestro do console

   O script sobrescreve sete métodos nativos do console: log, warn, info, error, exception, table e trace. Todos os sete são substituídos por funções no-op vazias. Isso impede que quaisquer avisos ou saídas de depuração apareçam se alguém abrir o DevTools depois que o script tiver carregado.

   Uma chamada separada de console.clear() é disparada em um timer de 3 segundos para limpar qualquer coisa que possa ter sido registrada antes que a sobrescrita entrasse em vigor.

   Passo 3: Exclusão de cookies de rastreamento

   O script exclui os seguintes cookies tanto no nível de caminho quanto no nível de domínio raiz:

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

   Este é o comportamento mais importante a entender. Ao excluir o cookie rtkclickid-store do RedTrack, o script apaga a atribuição legítima de clique de afiliado para aquele visitante. Ao também excluir os cookies do Google Analytics, ele remove qualquer evidência de como o usuário chegou ao site. A fonte de tráfego real do visitante desaparece completamente. Isso abre caminho para que o token de afiliado do próprio 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 a 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.

   Veja o que cada parâmetro de URL significa:

   • t=direct: marcador de tipo de tráfego
   • s=287: identificador de campanha
   • d=[target]: o site sendo defraudado (o valor muda por 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 redirecionamento por meio de discounthero[.]org que insere um cookie de afiliado no navegador do usuário. Se o usuário posteriormente visitar o site-alvo e fizer uma compra, o atacante por trás de pub=twsc ganha uma comissão que nunca gerou. A exclusão de cookies no passo 3 garante que não exista nenhuma atribuição concorrente.

   Após 20 segundos, o iframe é removido do DOM. Nenhum rastro visual permanece na página.

   Passo 5: Sequestro da Fetch API

   Dentro do iframe injetado, o script faz monkey-patch em window.fetch. Qualquer requisição fetch contendo nivtrck[.]com (codificado como bml2dHJjay5jb20= em Base64) é silenciosamente bloqueada com uma Promise rejeitada.

   Isso impede que um serviço de rastreamento concorrente registre a fonte de tráfego real. O atacante não quer apenas crédito pela visita; ele bloqueia ativamente outros rastreadores de capturar qualquer dado de atribuição que conflite com seu cookie fraudulento.

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

   Uma tag `` é injetada no `` da página, suprimindo cabeçalhos referrer em todas as navegações de saída. Isso oculta a fraude do analytics downstream no site-alvo.

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

   __tr_luptv = [timestamp atual menos 300000 milissegundos]

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

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

   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 decodificadora que traduz índices de array para strings legíveis em tempo de execução
   • Objetos proxy que envolvem chamadas de função e referências de string por trás de nomes de propriedades aleatorizados
   • Um loop de embaralhamento IIFE que rotaciona o array até que um checksum corresponda, garantindo que o decodificador produza valores corretos

   O código ofuscado parece ruído aleatório. Nenhuma ferramenta de análise estática, scanner de assinaturas ou detecção baseada em regex identificará comportamento malicioso a partir do código-fonte bruto. Você precisa executar o decodificador para ver o que o script faz.

   O que é discounthero[.]org?

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

   • Hospedado na infraestrutura da AWS no IP 3.68.5.1 (AS16509, AMAZON-02), geolocalizado na Alemanha
   • Classificado como distribuidor de adware pelo 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 ao lado de domínios conhecidos de fraude em anúncios
   • Relatado por usuários em múltiplos fóruns de navegadores como fonte de redirecionamentos de malvertising, incluindo incidentes nos fóruns da comunidade Daz3D
   • Usa o endpoint de redirecionamento red_u_plain.php com parâmetros por campanha (s=, d=, pub=, t=)
   • A cadeia de redirecionamento flui por gracylifestyle[.]com (Cloudflare) para d33old9jdtt77h.cloudfront.net (Amazon CloudFront)

   O que é nivtrck[.]com?

   nivtrck[.]com é o domínio de rastreamento que o script bloqueia ativamente por meio do sequestro da Fetch API. Este domínio tem zero documentação pública em todas as plataformas de inteligência de ameaças, relatórios de sandbox e bancos de dados de histórico WHOIS. Pode ser um serviço de rastreamento legítimo cuja atribuição o atacante quer suprimir, ou pode pertencer a uma operação de fraude concorrente.

   Indicadores de comprometimento (IOCs) para msclairty[.]com

   Tipo	Valor	Finalidade
   Domínio	msclairty[.]com	Entrega de script, typosquat do Microsoft Clarity
   URL	msclairty[.]com/event.js	Script loader do Estágio 1
   URL	msclairty[.]com/js/[encoded].js?type=1	Payload ofuscado do Estágio 2
   SHA256	7ad3dcdcc83eba9298b800a9cbbc00720c35859880bf00ba7bab8883f750f0ff	Hash do event.js (loader), 8.599 bytes
   SHA256	27e6d46c37d2cb8ef3cf21b70ce03b5090eae988f4e3923cd0902a7bde8c4e94	Hash do payload (.js?type=1), 10.007 bytes
   ID de campanha	id=dHRcSiYkDj4	Campanha de 2 de março de 2026 (rotaciona diariamente)
   ID de campanha	id=XGp2NSkTRVs	Campanha de 3 de março de 2026 (rotaciona diariamente)
   Domínio	discounthero[.]org	Endpoint de redirecionamento de fraude de afiliados
   Endereço IP	3.68.5.1	Hospedagem de discounthero[.]org (AWS, Alemanha)
   ASN	AS16509 (AMAZON-02)	Infraestrutura de discounthero[.]org
   Domínio	nivtrck[.]com	Rastreador concorrente bloqueado pelo script
   Nome do cookie	__tr_luptv	Cookie de atribuição do atacante E flag de deduplicação do loader
   Valor do cookie	Date.now() - 300000	Timestamp retroativo, 5 minutos no passado
   ID de afiliado	pub=twsc	Conta de publisher do atacante para fraude de comissão
   Parâmetro POST do loader	ext: 'twsc'	Identificador de afiliado hardcoded na requisição de segmentação do loader
   Parâmetro POST do loader	url, referrer, unique_id	URL da página, referrer e ID de campanha enviados ao servidor
   Content-Type	application/x-www-form-urlencoded	Formato da requisição POST de segmentação do loader
   ID de campanha	s=287	Identificador de campanha na URL de redirecionamento
   Variante de payload	?type=1 (função type1)	Cookie stuffing silencioso de afiliados via iframe oculto
   Variante de payload	?type=2 (função type2)	Cookie stuffing + injeção de conteúdo via template {{link2}}
   Variante de payload	?type=3 (função type8)	Sequestro de clique: adiciona redirecionamento de afiliado a links de saída
   Variante de payload	?type=4 (função type9)	Sequestro de clique: redireciona o usuário primeiro para discounthero
   Variante de payload	?type=5 (função type11)	Redirecionamento automático: navega a página forçadamente após 400ms
   Caminho de URL	/us/s/red_u_plain.php	Handler de redirecionamento de discounthero[.]org
   Certificado SSL emitido	20 de fevereiro de 2026, 20:14:54 UTC	Domínio criado 10 dias antes do primeiro tráfego observado
   Loader modificado	2 de março de 2026, 09:58:50 GMT	Timestamp de última modificação do event.js
   Primeira observação	2 de março de 2026, 21:17:09 UTC	Tráfego mais antigo na telemetria da cside
   ETag	W/"2717-Eekqo9gobf+ksAb6+kvO6VgzCto"	ETag do payload (inalterado em todas as requisições)
   ETag	W/"2197-19cadfc7987"	ETag do event.js (inalterado em todas as requisições)
   Infraestrutura	Cloudflare + Express (Node.js)	Stack do servidor de msclairty[.]com
   Vetor de injeção	Extensão de navegador (não identificada)	Mecanismo de entrega do script

   Por que esse ataque contorna as ferramentas de segurança tradicionais?

   Esse 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 embutido no código-fonte do site. Isso significa que cabeçalhos de Content Security Policy não vão bloqueá-lo. Auditorias de tags não vão encontrá-lo. Verificações de Subresource Integrity não se aplicam. Ferramentas de segurança no lado do servidor não têm visibilidade sobre o que uma extensão de navegador injeta na página em tempo de execução.

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

   O script também evade a pesquisa manual. Ele detecta o DevTools aberto e encerra. Ele sobrescreve todos os métodos do console. Ele remove o iframe do DOM após 20 segundos. Ele limpa o console após 3 segundos.

   O loader adiciona outra camada: ele faz hook em history.pushState, history.replaceState e popstate para re-disparar a cada navegação no lado do cliente em single-page applications. Cada mudança de rota envia a nova URL ao servidor para nova segmentação. E como o servidor decide qual variante de payload entregar com base na URL da página e no referrer, a análise estática de um único payload capturado não pode revelar o alcance completo dos ataques que a infraestrutura é capaz de realizar.

   Como detectar ataques de cookie stuffing de afiliados como este?

   A detecção baseada em blocklist não funciona contra esse tipo de ataque. O domínio é novo demais 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 detecção confiável é a análise comportamental em tempo de execução: monitorar o que os scripts fazem dentro do navegador em vez de analisar seu código-fonte ou verificar seu domínio contra uma blocklist. Exclusão de cookies, injeção de iframe oculto, sequestro da Fetch API e supressão do console são todos comportamentos observáveis que são claramente maliciosos independentemente da aparência do código-fonte ou de onde o script foi carregado.

   É para isso que o monitoramento de segurança no lado do cliente em tempo real foi criado.

   O que significa o parâmetro ?type=?

   A URL aceita um parâmetro de consulta ?type= que seleciona qual payload de ataque o servidor retorna. Confirmamos cinco variantes. Cada uma escala em agressividade. Todas as cinco compartilham o mesmo núcleo de evasão: detecção do DevTools (encerra se aberto, limite de 150px), sequestro do console (7 métodos sobrescritos), exclusão de cookies (_ga, _gid, rtkclickid-store no nível de caminho e domínio raiz), cookie de atribuição do atacante (__tr_luptv = Date.now() - 300000), supressão de 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. Essa discrepância revela a escala real 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 redirecionamento de afiliados, insere o cookie do atacante e se autodestrói após 20 segundos. A Fetch API é sequestrada para bloquear requisições para nivtrck[.]com. O visitante não vê nada.

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

   Faz tudo que o type=1 faz. Depois busca uma segunda URL de uma variável de template no lado do servidor {{link2}}, cria um segundo iframe oculto de 0x0, escreve o HTML buscado nele usando contentWindow.document.write() e falsifica a URL do iframe com history.replaceState. O segundo iframe se autodestrói após 15 segundos. O placeholder {{link2}} é preenchido no lado do servidor por alvo e pode entregar overlays de phishing, injeção de anúncios ou manipulação de página.

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

   Sem iframe. Instala um listener de evento de clique em document.body. Quando um visitante clica em qualquer tag `` com um href começando com "http", o script chama preventDefault() e então redireciona o navegador para a URL original com o redirecionamento de afiliado de discounthero[.]org adicionado como parâmetro de consulta. O usuário ainda chega ao destino pretendido, mas a navegação passa pela cadeia de redirecionamento do atacante no caminho.

   ?type=4 (função type9()) - Sequestro de clique (redirecionamento direto)

   Mesma interceptação de clique que o type=3, mas a direção do redirecionamento é invertida. Em vez de adicionar a URL de afiliado ao destino original, ele envia o usuário diretamente para discounthero[.]org com a URL original codificada como parâmetro usando encodeURIComponent(). O usuário navega visivelmente pela infraestrutura do atacante primeiro, depois é encaminhado ao destino pretendido após o cookie de afiliado ser inserido.

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

   A variante mais agressiva. Sem iframe. Sem interceptação de clique. Após um atraso de 400 milissegundos, o script redireciona forçadamente a página inteira usando window.location.search. O usuário é automaticamente navegado para fora da página que estava visualizando para a cadeia de afiliados de discounthero[.]org. Nenhuma interação necessária. O atraso de 400ms é apenas longo o suficiente para que a exclusão de cookies e o cookie __tr_luptv sejam definidos antes que o redirecionamento seja disparado.

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