Campanha de airdrop falso de NFT usa logs manipulados para simular remetentes confiáveis

Operação distribuiu NFTs falsos para mais de 200 mil carteiras, imitando mais de 100 projetos populares e levando usuários a sites de phishing para autorização indevida de carteiras.

Componente	Campanha de airdrop falso de NFT envolvendo contratos inteligentes, logs de eventos em Solidity, exploradores de blockchain e sites de claim fraudulentos.
Vetor	NFTs não solicitados são enviados a detentores de tokens de projetos conhecidos; o NFT contém link para um site que induz a conexão da carteira e a assinatura de transação.
Impacto	Usuários que conectam a carteira e autorizam a transação no site fraudulento podem conceder ao operador acesso aos fundos da carteira.
Prioridade	Tratar airdrops inesperados como suspeitos, validar origem por canais oficiais, analisar contratos não verificados e evitar assinatura de transações iniciadas por links embutidos em NFTs.
Escala	A infraestrutura observada distribuiu airdrops para mais de 200 mil pessoas e imitou mais de 100 projetos populares.
Artefatos	Foram observados uso do evento TransferSingle, parâmetro _airdrop, armazenamento em STORAGE[0x03], proxy em 0x129174bcca997e51E4c2849C99f1DDb3A9bA387F e implementação delegada em 0x5A954283c8600a96274bb5a1E3CfDE2e0Dc32Ea0.

Resumo técnico

Uma campanha de fraude com NFTs está explorando a confiança de usuários em projetos conhecidos de criptoativos por meio de airdrops falsos, remetentes aparentes manipulados e páginas de claim usadas para phishing de carteiras. A operação não depende de acesso aos e-mails dos detentores de tokens. Em vez disso, mira carteiras associadas a projetos populares e envia NFTs que aparentam estar ligados ao ecossistema que o usuário já possui ou acompanha. O efeito psicológico é relevante: quando uma carteira que detém um token recebe um NFT com nome e aparência relacionados ao mesmo projeto, a transação parece menos aleatória e ganha uma camada artificial de legitimidade.

A infraestrutura descrita atingiu mais de 200 mil destinatários e imitou mais de 100 projetos populares. O fluxo combina três componentes técnicos: criação de NFTs falsos, uso de eventos de contrato para exibir um remetente enganoso em exploradores de blockchain e redirecionamento para sites específicos de claim. A etapa final é a mais crítica para o usuário: ao visitar o site indicado no NFT, a vítima é induzida a conectar a carteira e assinar uma transação apresentada como necessária para receber recompensa ou benefício. O material analisado indica que essa autorização pode conceder ao operador acesso aos fundos da carteira.

A fraude também expõe um limite importante de leitura operacional em blockchain. Exploradores como o Etherscan exibem informações derivadas de logs emitidos por contratos, e esses logs podem ser construídos de forma a criar uma impressão falsa sobre a origem de um ativo. O registro permanece na blockchain, mas a forma como ele é interpretado na interface pode levar usuários e automações simples a inferirem que o NFT veio de uma entidade legítima. Isso torna insuficiente confiar apenas no campo visual de remetente quando há contrato não verificado, proxy, evento emitido sob controle do operador e link externo associado ao ativo.

Fluxo técnico

O fluxo começa com a seleção de carteiras que possuem tokens ou ativos ligados a projetos de alta visibilidade. Se uma carteira aparece como detentora de um token de determinado projeto, o operador envia um NFT que se apresenta como airdrop relacionado ao mesmo ecossistema. Em exemplos descritos no material recebido, a técnica foi usada para produzir a aparência de airdrops associados a marcas ou projetos conhecidos, incluindo referências ao universo de Bored Ape Yacht Club e Immutable X. O operador não precisa identificar pessoalmente o usuário; basta alcançar a carteira por meio da própria infraestrutura pública de blockchain.

A manipulação mais relevante ocorre na apresentação da origem do NFT. Em um caso envolvendo um falso NFT de IMX, a distribuição aparentava ter sido emitida por IMMUTABLE X Deployer, endereço reconhecido como deployer original do token IMX. A análise dos logs indicou que o campo de origem foi simulado por meio de eventos emitidos pelo contrato. Em Solidity, emit registra eventos que podem ser consumidos por exploradores e ferramentas de análise. Quando um contrato malicioso emite um evento com valores escolhidos pelo operador, a interface que interpreta esse log pode mostrar uma narrativa enganosa sobre quem enviou ou originou o ativo.

O contrato observado em 0x129174bcca997e51E4c2849C99f1DDb3A9bA387F atuava como proxy, delegando a implementação para 0x5A954283c8600a96274bb5a1E3CfDE2e0Dc32Ea0. Essa separação dificulta a avaliação direta porque a lógica efetiva não está necessariamente no endereço que o usuário vê durante a interação. O contrato de implementação não estava verificado, exigindo análise por decompilação para inferir comportamento. No código decompilado foram identificados um evento TransferSingle e um parâmetro _airdrop, armazenado em STORAGE[0x03], associado ao endereço real de deployer que seria usado para sustentar a impressão de origem legítima.

Após a entrega do NFT, o artefato inclui um link para um site específico de claim. Essa página é o ponto de conversão da fraude: ela apresenta uma recompensa ou benefício, solicita conexão da carteira e tenta obter uma assinatura de transação. O problema não está apenas em visitar a página, mas em autorizar a operação solicitada. A assinatura dá ao operador a condição necessária para agir contra os fundos da carteira, conforme descrito no contexto. Portanto, a cadeia de ataque depende da combinação de engenharia social, confiança em nomes conhecidos, leitura superficial de logs e uma autorização feita pelo próprio usuário sob falsa premissa.

Superfície afetada

A superfície exposta inclui usuários e carteiras que interagem com NFTs recebidos sem solicitação, especialmente quando o ativo menciona um projeto que a carteira já possui ou com o qual já interagiu. A campanha foi desenhada para atingir detentores de tokens de muitos projetos, não apenas um único ecossistema. Isso amplia o alcance porque a seleção por carteira permite personalizar a isca sem depender de listas de e-mail, credenciais vazadas ou contato direto fora da blockchain. O canal de entrega é o próprio recebimento do NFT, e a pressão de confiança vem da aparente coerência entre o token do usuário e o airdrop recebido.

Ambientes operacionais que monitoram carteiras institucionais, tesourarias cripto, carteiras de jogos web3, coleções de NFT e contas usadas por equipes de investimento devem tratar airdrops inesperados como eventos de risco, não como simples ruído de portfólio. A presença de proxy, contrato de implementação não verificado e evento emitido para simular origem cria um cenário em que a inspeção manual rápida pode falhar. A exposição aumenta quando usuários dependem apenas de campos de interface em exploradores, sem validar contrato, canal oficial do projeto e intenção exata da assinatura solicitada pelo site externo.

A campanha também afeta ferramentas automatizadas que classificam NFTs ou transações com base em logs sem contexto adicional. Se um scanner consome o evento emitido e assume que o campo de origem representa o emissor real, pode registrar falso positivo de legitimidade ou reduzir prioridade de alerta. Esse comportamento é especialmente perigoso em carteiras com grande volume de ativos, nas quais usuários e operações de segurança podem filtrar eventos por nome de projeto, suposto remetente ou aparência do token. A defesa precisa considerar que o log é uma evidência técnica, mas não uma garantia isolada de autenticidade.

• Carteiras que receberam NFTs não solicitados vinculados a projetos conhecidos ou a tokens já presentes no endereço.
• Contratos proxy que delegam lógica a implementação não verificada, dificultando leitura direta da função executada.
• NFTs que embutem link de claim e induzem conexão de carteira fora de canais oficiais do projeto.
• Exploradores e automações que interpretam eventos emit como origem confiável sem validação do contrato emissor.

Hunting e telemetria

A investigação defensiva deve começar pela correlação entre recebimento de NFT inesperado, nome de projeto imitado e presença de link externo no metadado do ativo. Em carteiras monitoradas, eventos de entrada que mencionam airdrop, recompensa ou claim devem ser analisados com atenção quando o contrato emissor não é verificado, quando há proxy na execução ou quando o ativo tenta associar-se a marcas conhecidas sem confirmação por canal oficial. A prioridade não é apenas identificar o NFT falso, mas reconstruir o caminho que levou o usuário ao site de phishing e verificar se houve conexão de carteira ou assinatura posterior.

Na camada de blockchain, sinais úteis incluem eventos TransferSingle emitidos por contratos que não pertencem ao projeto alegado, discrepância entre endereço apresentado na interface e endereço que efetivamente executa a transação, uso de contrato proxy e armazenamento de valores que referenciam endereços legítimos para induzir confiança. O endereço de proxy 0x129174bcca997e51E4c2849C99f1DDb3A9bA387F e a implementação 0x5A954283c8600a96274bb5a1E3CfDE2e0Dc32Ea0 são artefatos relevantes dentro do material analisado, mas a caça não deve depender apenas deles, pois a mesma técnica pode ser replicada com outros contratos e nomes de projeto.

Na telemetria de endpoint e navegação, a defesa deve procurar acessos a páginas de claim originados a partir de links em NFTs, conexões de carteiras a sites recém-visitados e sequência curta entre visualização de ativo, abertura de URL e solicitação de assinatura. Em ambientes corporativos ou de custódia, eventos de navegador, extensões de carteira e registros de aprovação devem ser correlacionados. O objetivo é identificar autorização indevida antes que a carteira seja drenada, ou ao menos delimitar quais carteiras assinaram transações após interação com a página fraudulenta.

• NFT recebido sem solicitação, com metadado contendo link externo de claim ou recompensa.
• Evento TransferSingle com origem aparente ligada a projeto conhecido, mas emitido por contrato diferente do projeto alegado.
• Contrato de implementação não verificado atrás de proxy usado na distribuição do airdrop.
• Conexão de carteira e assinatura de transação imediatamente após acesso ao site indicado no NFT.
• Divergência entre o remetente exibido por explorador e a lógica real inferida a partir dos logs e do contrato executor.

Mitigação

A resposta deve priorizar prevenção de assinatura indevida. Usuários e operadores de carteiras devem considerar suspeito qualquer airdrop não solicitado, mesmo quando o NFT aparenta vir de um projeto familiar. A validação precisa ocorrer fora do link embutido no ativo: canais oficiais do projeto, documentação pública e comunicação já conhecida devem ser usados para confirmar se existe campanha legítima. Quando a origem depende apenas de um campo exibido por explorador de blockchain, a conclusão deve permanecer condicionada até que contrato, eventos, implementação e metadados sejam avaliados.

Para carteiras com ativos de maior valor, a segregação operacional reduz impacto. Carteiras usadas para receber ou inspecionar NFTs inesperados não devem concentrar fundos relevantes. O uso de carteiras de hardware para armazenar valores significativos adiciona uma camada de controle contra phishing de navegador, desde que o usuário revise cuidadosamente o que está assinando. A mitigação também deve incluir revisão periódica de autorizações concedidas, especialmente após qualquer interação com páginas de claim. Quando houver suspeita de assinatura indevida, a contenção deve focar na carteira afetada, nas aprovações associadas e na transferência defensiva de ativos ainda não movimentados, respeitando processos internos de custódia.

Em organizações que monitoram ativos digitais, políticas de navegação e treinamento precisam refletir a técnica observada: o problema não é apenas phishing por e-mail, mas phishing iniciado por ativo recebido na blockchain. Bloqueios ou alertas para links embutidos em NFTs, análise de contratos não verificados, revisão de proxies e marcação de airdrops inesperados ajudam a reduzir exposição. Ferramentas confiáveis continuam úteis para inspeção, mas devem ser tratadas como apoio analítico, não como prova definitiva quando os dados exibidos derivam de logs que podem ser manipulados pelo próprio contrato.

• Não conectar carteiras a sites de claim acessados por links presentes em NFTs recebidos sem solicitação.
• Validar a existência do airdrop em canais oficiais do projeto antes de qualquer assinatura de transação.
• Inspecionar contrato emissor, proxy, implementação e eventos antes de confiar no remetente exibido por exploradores.
• Separar carteiras de armazenamento de carteiras usadas para interação com aplicações e ativos desconhecidos.
• Revisar autorizações após qualquer interação suspeita e tratar assinaturas recentes como evento de resposta a incidente.
• Configurar monitoramento para airdrops inesperados, contratos não verificados e sequência de acesso a site seguida de assinatura.