Fraudes de phishing RWA: como ativos tokenizados falsos esvaziam carteiras

O que é phishing de RWA e porque é diferente de um scam genérico de airdrop?

O phishing de RWA é uma categoria de scam cripto que se faz passar por produtos de ativos do mundo real tokenizados, coisas como fundos do mercado monetário, obrigações do Tesouro dos EUA de curta duração ou crédito privado, para enganar os detentores e levá-los a assinar transações maliciosas. A categoria existe porque os produtos subjacentes têm um sinal de confiança incorporado que scams mais antigos tinham de fabricar do zero: uma marca institucional.

Quando uma carteira mostra um token com o ticker BUIDL ou OUSG, é mais provável que o detentor assuma que veio do emissor real. Os scammers exploram essa suposição. Implementam um novo contrato ERC-20, dão-lhe o mesmo símbolo de ticker, por vezes até o mesmo nome, e fazem airdrop de cópias sem valor para endereços ativos. A cópia fica na carteira ao lado do token real, indistinguível num olhar distraído.

É isto que torna o phishing de RWA um primo mais sofisticado do address-poisoning. O address-poisoning depende de a vítima enviar para o endereço errado. O phishing de RWA depende de a vítima assinar a aprovação errada. O atacante não precisa de o convencer de que o protocolo é real, porque o logótipo e o ticker fazem esse trabalho de graça.

Os produtos que estão a ser imitados, obrigações do Tesouro tokenizadas e crédito privado, também estão entre os segmentos de crescimento mais rápido das finanças on-chain. Esse crescimento atrai utilizadores de retalho que nunca lidaram antes com crédito on-chain e que podem não perceber que o ticker no Etherscan é apenas uma cadeia de texto introduzida por quem implementou o contrato. A fasquia para um scam com aparência credível caiu para quase zero.

Quais são os riscos reais antes de tocar num RWA tokenizado?

A resposta honesta é que os riscos começam antes de alguma vez interagir com um emissor real, porque só o problema da imitação pode esvaziar uma carteira. Os riscos técnicos dos produtos reais, como bugs de smart contracts, falhas de oráculos ou falência do emissor, são secundários face ao risco de engenharia social para a maioria dos utilizadores de retalho.

O phishing de aprovação é o modo de falha dominante. Quando interage com um protocolo DeFi, normalmente concede a um smart contract permissão para mover um token específico da sua carteira. A interface predefinida permite muitas vezes definir essa autorização como ilimitada, o que é conveniente, mas catastrófico se o contrato for malicioso. Uma única assinatura pode dar a um atacante a capacidade de drenar todas as cópias desse token que detém, agora ou mais tarde.

Os tokens wrapper são particularmente perigosos. A maioria dos produtos RWA não é transferível diretamente para uma carteira normal. Ficam dentro de um wrapper, um contrato intermédio que emite um recibo negociável. Os scammers implementam os seus próprios wrappers e rotulam-nos com o ticker real. Aprovar o wrapper errado significa que o atacante pode retirar o wrapper da sua carteira a qualquer momento, e pode só reparar quando o saldo tiver desaparecido.

A imitação torna-se mais difícil de detetar à medida que a marca fica maior. Um scam que copia OUSG pode registar ondo-ousg-claim.com, comprar anúncios no Google para o termo de pesquisa e lançar um clone perfeito da landing page real da Ondo. O portal KYC falso pedirá uma assinatura da carteira sob o pretexto de verificação de acreditação, e o payload assinado será uma aprovação ilimitada de tokens. Não há recurso depois de essa assinatura estar on-chain.

O contexto histórico importa. O padrão não é novo. O hack da Badger DAO em 2022 drenou cerca de 120 milhões de dólares ao enganar utilizadores para aprovarem um contrato malicioso através de um front-end comprometido. O comprometimento do Ledger Connect Kit em 2023 atingiu dezenas de dApps legítimas de uma só vez. Em cada caso, o utilizador assinou algo que parecia rotineiro, e a perda foi total. O phishing de RWA é o mesmo manual de jogo com outro disfarce.

O risco de contraparte no produto real continua a existir. Se comprar com sucesso o BUIDL ou OUSG real através do canal real, continua a assumir o risco de o fundo subjacente pausar resgates, de o banco do emissor falir ou de um custodiante não conseguir entregar obrigações do Tesouro a pedido. Estes riscos de cauda são reais e ficam por cima do risco de imitação, não no seu lugar.

Como funciona realmente o phishing de RWA, passo a passo?

A mecânica é consistente entre campanhas, e é isso que a torna ensinável. Depois de veres uma, consegues identificar todas as fases na seguinte.

Fase 1: Registo do domínio. O atacante regista um domínio que se assemelha visualmente a um emissor real. Os padrões comuns incluem hífenes (ondo-finance-claim.com), TLDs com código de país (ondo.fi ou ondo-app.io), ou letras substituídas (0ndo.com com um zero). O site carrega uma cópia quase perfeita da página inicial do emissor, extraída de materiais públicos de marketing.

Fase 2: Implementação do contrato. O atacante implementa um novo contrato ERC-20 em Ethereum ou numa rede Layer 2. O contrato tem o mesmo nome e ticker que o token real. Não existe um registo on-chain que impeça isto. Depois, o atacante faz um airdrop do token falso para milhares de endereços que já detêm o produto real, para que o token fraudulento apareça ao lado do genuíno.

Fase 3: Canais de distribuição. O site e o contrato falsos são promovidos através de anúncios pagos em motores de pesquisa, canais Discord ou Telegram pirateados, contas X comprometidas e spam em respostas a anúncios reais do emissor. KOLs e agregadores ocasionalmente indexam o contrato falso, o que faz com que apareça em scanners de carteiras como se fosse legítimo.

Fase 4: A armadilha. As vítimas são encaminhadas para um portal falso de "claim" ou "redeem". A página explica que o utilizador tem de concluir KYC ou acreditação antes de poder receber distribuições, rendimento ou bónus de airdrop. A assinatura da carteira pedida no fim do fluxo de KYC não está realmente a verificar a identidade. É uma aprovação, muitas vezes ilimitada, frequentemente para um token wrapper não transferível controlado pelo atacante.

Fase 5: Drenagem. Depois de a aprovação ser assinada, o atacante chama a função transferFrom do wrapper e retira o wrapper da carteira. Dependendo do desenho, o RWA real subjacente pode ir com ele, ou o wrapper pode simplesmente não ter valor, mas normalmente o detentor só repara depois de o saldo desaparecer.

Porque é que os portais de KYC e acreditação fazem parte do truque?

A maioria dos produtos RWA legítimos está limitada a investidores acreditados ou qualificados ao abrigo das regras sobre valores mobiliários. Isso cria um ponto de fricção de que os burlões gostam: o utilizador espera que lhe peçam documentos antes de poder transacionar. O burlão simplesmente coloca a carga de phishing dentro daquilo que parece ser uma etapa de conformidade.

O portal falso normalmente pede um email, uma selfie e uma assinatura da carteira para "verificar a acreditação on-chain". A assinatura é a aprovação maliciosa. A selfie e o email são dados extra que o burlão pode vender ou usar em burlas posteriores. As vítimas relatam muitas vezes que sentiram que algo estava errado, mas assinaram na mesma porque a etapa parecia normal.

É também por isso que a usurpação de identidade parece mais convincente para o retalho do que para as instituições. Um prime broker sabe que BUIDL é distribuído apenas através da Securitize e nunca através de uma página pública de claim. Um utilizador de retalho que viu um logótipo da BlackRock num anúncio do YouTube não tem um contexto comparável. O enquadramento de KYC faz com que a assinatura da carteira pareça um ponto de controlo regulatório em vez de financeiro.

A defesa é estrutural. Emissores reais como Securitize, Ondo e Maple publicam os seus endereços de contrato canónicos nos seus próprios domínios principais. As etapas de conformidade acontecem dentro da aplicação real do emissor, não numa página a que chegaste a partir de uma DM, de um anúncio ou de uma resposta. Se um site te pede que a tua carteira assine alguma coisa durante o KYC, isso é por si só um sinal de alerta, independentemente de quão polido pareça o resto da página.

O que fazem realmente os portais falsos de "claim" e "redeem" a uma carteira?

A maioria pede uma aprovação ERC-20, o mesmo primitivo usado por Uniswap e Aave para permitir que smart contracts movam tokens em teu nome. A diferença está no spender. Um DEX legítimo pede-te que aproves o router da Uniswap, um endereço conhecido com auditorias públicas e histórico. Um site de phishing pede-te que aproves um endereço controlado pelo atacante, muitas vezes recém-implementado, frequentemente sem auditoria e muitas vezes sem código-fonte verificado no Etherscan.

A pior variante é a aprovação para um token wrapper não transferível. O atacante implementa um contrato wrapper que cunha e queima um token de recibo que representa uma participação no RWA subjacente. O emissor real faz algo semelhante, mas com um contrato verificado. O wrapper falso permite ao atacante mover o recibo para fora da tua carteira quando quiser. Mesmo que revogues a aprovação mais tarde, os tokens já desapareceram.

Alguns sites vão mais longe e pedem uma chamada setApprovalForAll, que concede permissão geral sobre tokens ERC-721 ou ERC-1155 ao nível da carteira. Este é o mesmo primitivo usado por marketplaces NFT, e é também aquilo que os drainers encadeiam para esvaziar uma carteira inteira numa só transação. Assim que um setApprovalForAll é assinado para um operador malicioso, tudo nesse endereço de contrato fica vulnerável.

Existe também uma variante mais recente em que a página de "claim" te pede para assinares uma mensagem off-chain usando eth_sign ou personal_sign. O payload assinado é depois usado para construir um permit reutilizável que autoriza o atacante a gastar os teus tokens sem nunca submeter uma aprovação on-chain. O phishing ao estilo permit tem vindo a crescer porque não deixa uma linha de aprovação óbvia para revogar depois.

O padrão em todos estes casos é o mesmo: a página transforma um momento que parece burocracia num momento que é, na verdade, uma autorização financeira. A defesa individual mais forte é tratar qualquer pedido de assinatura da carteira durante uma etapa de "verificação" como o ponto sem retorno, e ler a transação descodificada na tua carteira antes de confirmares.

Como verificas o contrato canónico antes de assinares alguma coisa?

A verificação é uma rotina de cinco passos, e deve ser feita antes de qualquer interação com um produto RWA, especialmente se chegaste através de uma ligação em vez de escreveres o URL manualmente.

1. Começa no domínio oficial do emissor. Escreve a barra de endereço manualmente. Para o BUIDL da BlackRock, é a página promovida pela Securitize no domínio principal da Securitize, não um resultado de pesquisa. Para USDY e OUSG da Ondo, é o site oficial ondo.finance. Guarda o URL real nos favoritos uma vez e nunca mais cliques em anúncios de pesquisa ou respostas em redes sociais.

2. Encontra o endereço de contrato canónico nessa página. Emissores reais publicam os seus endereços de contrato na documentação, muitas vezes com uma ligação para o Etherscan e uma nota clara sobre as redes em que estão implementados. Anota o endereço. Melhor ainda, copia-o uma vez para uma aplicação de notas para poderes comparar com aquilo que a tua carteira te mostra mais tarde.

3. Faz uma verificação cruzada no Etherscan. A página do contrato no Etherscan deve mostrar o nome do emissor como criador verificado do contrato, um número elevado de detentores, histórico real de transferências e uma data de implementação que esteja alinhada com os anúncios de lançamento do emissor. Se o deployer for uma carteira recente sem histórico, não estás a olhar para o produto real.

4. Atenção a dois contratos que partilham um ticker. Esta é a prova reveladora. Se o Etherscan mostrar dois ou mais contratos rotulados com o mesmo ticker, o mais antigo, com código-fonte verificado e o deployer canónico, é o produto real, o mais recente é o imitador. Os tickers não são únicos on-chain. Qualquer pessoa pode chamar BUIDL ao seu contrato.

5. Revoga aprovações antigas de forma proativa. Ferramentas como revoke.cash permitem-te auditar todas as aprovações ativas na tua carteira e revogar as que já não usas. Fazer isto uma vez por trimestre, ou depois de qualquer incidente que tenha tocado num endereço de elevado valor, impede que aprovações antigas se tornem responsabilidades silenciosas.

O que deve fazer se já assinou algo suspeito?

A primeira hora é mais importante do que tudo o que vem depois. Transfira os ativos restantes para uma carteira nova que nunca tenha interagido com o site suspeito. Não tente “limpar” a carteira comprometida revogando aprovações e esperando que resulte; a aprovação pode já ter sido usada, ou outra carga útil assinada pode ainda estar pendente.

Revogue aprovações no revoke.cash a partir de uma sessão limpa do navegador, se tiver tempo. Depois, verifique a carteira num explorador de blocos para ver se algum token já saiu. Se a aprovação foi uma permit ou uma assinatura off-chain, pode não haver um rasto on-chain óbvio até o atacante fazer a drenagem, por isso a rapidez é essencial.

Comunique o site fraudulento ao emissor que está a ser impersonado. A maioria dos emissores legítimos de RWA mantém um contacto de segurança ou uma caixa de correio para abusos. Quanto mais depressa puderem avisar outros utilizadores e conseguir que o domínio seja retirado, menor será o raio de impacto. Não espere recuperar fundos ao fazer a denúncia, mas conte com que a denúncia abrande a próxima vítima.

Se perdeu um montante significativo, documente as assinaturas, os endereços dos contratos e os URLs do site antes que desapareçam. É esta a informação que as empresas de análise forense de blockchain e as autoridades realmente utilizam. Capturas de ecrã tiradas no momento do incidente são muito mais úteis do que capturas de ecrã feitas uma semana depois.

Como acompanhar o phishing de RWA de forma inteligente

O phishing de RWA move-se depressa, e as notícias à sua volta também. Acompanhar manualmente novos domínios fraudulentos, implementações de contratos falsos e drenadores de aprovações é uma batalha perdida para qualquer investidor individual. O Zippfeed destaca manchetes sobre RWA e ativos tokenizados com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa ver que histórias o mercado trata como relevantes e quais são apenas ruído. Combine esse feed com uma lista de verificação de cinco minutos antes de clicar, e o manual de impersonação torna-se muito mais fácil de resistir.