Quase todas as interações com uma aplicação descentralizada, desde negociar numa exchange descentralizada até fazer staking de um token, exigem conceder a essa aplicação permissão para mover um token específico em nome do proprietário da carteira. Esta permissão chama-se aprovação de token, e é uma parte legítima e necessária do funcionamento da maioria das aplicações de blockchain. O problema não é o facto de as aprovações existirem. O problema é que a maioria das interfaces de carteira as apresenta de forma breve e técnica, e a maioria dos utilizadores confirma-as rapidamente sem compreender exatamente o que estão a autorizar.
Segundo o Relatório de Crime Cripto 2026 da Chainalysis, as burlas onchain renderam pelo menos catorze mil milhões de dólares em 2025, um aumento face aos doze mil milhões do ano anterior, e o phishing baseado em aprovações tem sido um contribuinte persistente para esse número, com mais de mil milhões de dólares em perdas cumulativas reportadas desde 2021 atribuídas especificamente a esta técnica.
O que uma aprovação de token realmente concede
Quando uma aplicação pede uma aprovação, está a solicitar à carteira que autorize um contrato inteligente a transferir até um montante especificado de um token, em nome do proprietário, no momento à escolha do contrato. Muitas aplicações pedem por defeito uma aprovação ilimitada, já que é mais conveniente para a aplicação e evita pedir ao utilizador que volte a aprovar cada transação futura. É precisamente essa conveniência que torna a permissão perigosa se o contrato que a recebe for malicioso ou vier a ser comprometido, porque a própria aprovação não expira e não exige qualquer confirmação adicional para ser exercida.
Uma aprovação não é uma transação única. É uma autorização permanente que se mantém ativa indefinidamente, on chain, até ser manualmente revogada, independentemente de o site que a pediu ser voltado a visitar.
Aprovações ERC-20, Permit, e Permit2 explicados
A função approve padrão
O padrão de token ERC-20 original inclui uma função chamada approve, que o proprietário da carteira chama para autorizar um endereço de contrato específico a gastar até um montante especificado desse token. Isto exige uma transação on chain, ou seja, custa uma taxa de rede e fica registada permanentemente na blockchain no momento em que é confirmada. Por ser uma transação visível e separada, a maioria das interfaces de carteira mostrará pelo menos um aviso genérico de que está a ser pedida uma interação com um contrato, e não uma simples transferência.
Permit e assinaturas off chain
Um padrão mais recente, geralmente conhecido como Permit, permite que o mesmo tipo de aprovação seja concedido através de uma mensagem assinada em vez de uma transação on chain. A própria assinatura não custa qualquer taxa de rede e não precisa de ser transmitida de imediato, já que o contrato recetor pode apresentá-la à blockchain em qualquer momento posterior para ativar a aprovação. Isto é conveniente para aplicações legítimas, já que permite a um utilizador aprovar e concluir uma ação, como uma troca de token, numa única interação em vez de duas transações separadas. É também exatamente isto que torna o phishing baseado em Permit mais difícil de notar, já que um pedido de assinatura muitas vezes tem um aspeto visualmente semelhante ao de assinar uma mensagem inofensiva, e historicamente muitas interfaces de carteira têm mostrado menos detalhe para um pedido de assinatura do que para uma transação completa.
Permit2 e aprovações universais
O Permit2, uma extensão adicional amplamente adotada em exchanges descentralizadas, permite que uma única aprovação concedida a um contrato Permit2 central seja depois reutilizada em muitas aplicações diferentes sem uma aprovação separada para cada uma. Isto reduz o atrito e as taxas para utilizadores legítimos, mas também significa que uma única assinatura Permit2 vítima de phishing pode potencialmente expor um token a qualquer aplicação construída para interagir com o sistema Permit2, alargando o raio de ação prático de uma tentativa de phishing bem-sucedida em comparação com uma aprovação de contrato único ao estilo antigo.
Um cenário realista: uma falsa reclamação de airdrop que concede aprovação ilimitada
- Circula uma mensagem numa comunidade de cripto a afirmar que um projeto de token bem conhecido está a distribuir um airdrop surpresa a detentores de um ativo relacionado, com um link para uma página de reclamação.
- A página de reclamação pede ao visitante que ligue a sua carteira e clique num botão rotulado Reclamar Agora, o que desencadeia uma janela na carteira a pedir aprovação para o token do projeto, descrita apenas como uma interação com um contrato.
- O montante de aprovação pedido é definido para o valor máximo possível permitido pelo padrão do token, em vez de um montante de reclamação específico, embora este detalhe não seja destacado de forma proeminente na vista de confirmação padrão da carteira.
- A vítima confirma, não recebe quaisquer tokens já que nunca existiu um airdrop real, e fecha o separador presumindo que a reclamação simplesmente falhou ou já se esgotara.
- Semanas depois, assim que o preço do token subiu ou a vítima acumulou um saldo maior, o atacante exerce a aprovação permanente e transfere todo o saldo numa única transação que a vítima nunca aprovou diretamente.
O atraso entre a interação de phishing original e a perda eventual é deliberado. Desliga o roubo da sua causa na memória da vítima e torna muito menos provável que a página de phishing específica seja reportada ou associada à perda quando esta finalmente ocorre.
Por que o phishing de aprovações é mais difícil de notar do que uma transferência direta de drenador
Um drenador de carteira direto, abordado em o nosso guia complementar, esvazia tipicamente uma carteira em segundos após a confirmação de uma assinatura, o que pelo menos torna a causa e o efeito imediatamente óbvios para a vítima. O phishing de aprovações está estruturado de forma diferente. A própria transação de aprovação não move nada, pelo que uma vítima que verifica o saldo logo a seguir a confirmar não vê qualquer alteração e conclui razoavelmente que nada aconteceu. A perda real pode ocorrer dias, semanas, ou meses depois, executada pelo atacante no momento à sua escolha, o que significa que a ligação entre a página de phishing original e o roubo eventual frequentemente nunca é feita pela vítima. É também por isto que as auditorias regulares de aprovações importam mais para esta ameaça específica do que para ataques diretos de drenagem, já que existe uma janela real, ainda que de duração incerta, durante a qual revogar a aprovação evita totalmente qualquer perda.
Como o ataque é normalmente executado
Páginas falsas de reclamação e verificação
A configuração mais comum é uma página a imitar uma reclamação de airdrop, um passo de verificação de carteira, ou uma interação de rotina com um protocolo. A vítima liga a sua carteira à espera de uma simples confirmação, e o site pede em vez disso uma aprovação que cobre um token valioso, enquadrada na janela da carteira como uma interação genérica com um contrato, e não como algo alarmante.
Phishing de assinatura Permit e Permit2
Uma variante mais recente e mais difícil de detetar abusa de um padrão de assinatura, frequentemente referido como Permit ou Permit2, que permite conceder uma aprovação através de uma mensagem assinada off chain em vez de uma transação on chain. Como assinar uma mensagem nem sempre desencadeia os mesmos avisos visuais que uma transação, e não custa uma taxa de rede, as vítimas têm mais probabilidade de a assinar sem um escrutínio atento. Um caso amplamente noticiado envolveu um trader que perdeu cerca de um milhão de dólares numa única assinatura Permit2 depois de a confundir com uma confirmação de rotina na interface de uma exchange descentralizada.
Exploração diferida
Como uma aprovação não precisa de ser usada imediatamente, os atacantes frequentemente recolhem um grande número de aprovações em muitas carteiras e exercem-nas mais tarde, em lotes, muitas vezes cronometrados para períodos em que o preço de um token subiu ou em que é menos provável que a vítima esteja a monitorizar ativamente essa carteira. Este atraso explica em parte por que as vítimas por vezes não conseguem associar uma perda à interação de phishing original, já que semanas ou meses podem separar os dois eventos.
Como verificar e revogar aprovações existentes
- Use uma ferramenta de verificação de aprovações de boa reputação que leia o histórico de aprovações on chain da sua carteira e liste todas as permissões ativas, juntamente com qual contrato as detém e que montante cobrem.
- Revogue qualquer aprovação que não reconheça ou de que já não precise, particularmente aprovações ilimitadas associadas a contratos desconhecidos ou raramente usados.
- Preste especial atenção a aprovações do estilo Permit2, já que são visualmente menos óbvias na maioria das interfaces de carteira do que uma transação de aprovação on chain padrão.
- Faça da revogação uma prática de rotina depois de interagir com qualquer aplicação descentralizada nova ou desconhecida, e não apenas algo feito reativamente depois de uma perda ser descoberta.
Além de verificar as aprovações existentes, vale a pena tratar alguns sinais específicos, no momento em que uma nova aprovação é pedida, como um sinal de paragem imediata em vez de algo a rever mais tarde.
- O montante de aprovação pedido é o valor máximo permitido pelo padrão do token, em vez de um número específico associado à ação reclamada.
- A página pede uma aprovação antes de mostrar qualquer benefício, recompensa, ou serviço tangível, em vez de como um segundo passo natural de uma interação que iniciou.
- A janela da carteira descreve o pedido apenas como uma assinatura ou uma interação genérica com um contrato, sem um resumo legível por humanos do que está a ser autorizado.
- O site combina urgência, como um temporizador de contagem decrescente ou uma janela de reclamação limitada, com um pedido de aprovação da carteira em vez de uma transação direta.
Um percurso completo do próprio processo de revogação, incluindo que ferramentas são normalmente usadas e como interpretar o que cada aprovação realmente autoriza, é abordado no nosso guia dedicado sobre revogar aprovações de token. Esse processo é uma das poucas medidas defensivas genuinamente eficazes ao alcance de um detentor de carteira, já que fecha diretamente o acesso permanente em vez de depender apenas de evitar futuras tentativas de phishing.
Quando uma aprovação já foi explorada
Se os fundos já se moveram através de uma aprovação explorada, a própria aprovação deve continuar a ser revogada imediatamente para evitar que qualquer margem restante seja usada de novo, mesmo depois de um roubo inicial. A transação que executou o roubo, juntamente com a transação de aprovação original, deve ser documentada com carimbos de tempo e identificadores, já que essa sequência é muitas vezes o que permite a um investigador estabelecer como ocorreu o comprometimento e se está ligado a um padrão mais amplo de atividade de drenagem, discutido em mais detalhe em o nosso guia sobre ataques de drenagem de carteira.
Perguntas frequentes
A maioria das ferramentas de verificação de aprovações de boa reputação suporta agora ver e revogar aprovações baseadas em Permit2 juntamente com as padrão, embora a interface possa separá-las numa secção distinta. Vale a pena verificar ambas as categorias especificamente, já que as aprovações Permit2 são visualmente menos óbvias em muitas interfaces de carteira.
Não. A revogação apenas impede que uma aprovação existente volte a ser usada no futuro. Não tem qualquer efeito sobre fundos já transferidos, já que as transações de blockchain não podem ser revertidas depois de confirmadas.
A maioria das interfaces de carteira é concebida para uso geral e apresenta as aprovações como uma interação padrão com um contrato, em vez de assinalar o montante ou a duração específicos. As ferramentas especializadas de verificação de aprovações fornecem geralmente um detalhe mais claro do que o ecrã de confirmação padrão de uma carteira.
Pode ser. As aprovações baseadas em assinatura, particularmente os pedidos do estilo Permit2, podem conceder o mesmo acesso de gasto que uma transação de aprovação on chain, mas são muitas vezes apresentadas com um aviso menos visível e sem taxa de rede, o que as torna mais fáceis de ignorar.
Uma prática razoável é rever as aprovações ativas a cada poucas semanas para uma carteira usada ativamente, e imediatamente depois de interagir com qualquer aplicação descentralizada, reclamação de airdrop, ou página de mint nova ou desconhecida.
Fontes e leituras adicionais
- What are token approvals · MetaMask
- 2026 Crypto Crime Report: Scams · Chainalysis
- Uniswap Permit2 Phishing: $1 Million Loss Highlights Risk · Cryptonomist