Início
» Notícia
»
Como proteger sua carteira Web3 contra phishing de drenagem e aprovações maliciosas
Como proteger sua carteira Web3 contra phishing de drenagem e aprovações maliciosas
Uma carteira Web3 pode ser esvaziada sem que o atacante descubra sua frase mnemônica. Essa é a parte desagradável do phishing moderno: um site falso pode simplesmente persuadi-lo a autorizar o atacante a movimentar ativos que sua carteira já controla. A aprovação ou assinatura pode parecer rotineira, especialmente quando a página imita um protocolo familiar, um airdrop, uma emissão de tokens, um portal de suporte ou uma solicitação de token.
Este guia foi verificado com base na documentação oficial da carteira, do protocolo e dos padrões Ethereum em 16 de setembro de 2026. As telas de aviso e os recursos de segurança exatos variam de acordo com a carteira, a rede e o aplicativo; portanto, o objetivo não é memorizar uma única interface, mas sim entender o que uma solicitação pode autorizar antes de aprová-la.
Primeiro, entenda o que um produto que drena a carteira realmente precisa.
Um "drainer" não é uma única função de contrato inteligente. Na prática, campanhas de phishing podem tentar obter vários tipos diferentes de autorização: uma permissão para tokens ERC-20, a aprovação de um operador de NFT, uma licença assinada, uma transação de transferência direta ou — no nível mais grave — a frase secreta de recuperação ou a chave privada do usuário.
O risco depende do que foi autorizado. Uma autorização ERC-20 normalmente se aplica a um contrato de token e gastador específicos, enquanto uma setApprovalForAllautorização ERC-721 pode permitir que um operador gerencie todos os NFTs daquela coleção que o proprietário possui. A especificação ERC-721 do Ethereum define explicitamente setApprovalForAlla habilitação ou desabilitação de um operador para todos os ativos do solicitante naquele contrato NFT. Leia a especificação ERC-721 .
Ação: quando uma carteira digital solicitar que você aprove uma despesa, um operador ou uma assinatura, trate isso como uma decisão de autorização, e não como uma simples etapa de "login".
Comece pelo domínio: um endereço desconhecido ou muito semelhante deve interromper a interação antes que qualquer solicitação de carteira seja aprovada.
Mito 1: “Conectar minha carteira permite que o site saque meus fundos”
Verificado: simplesmente conectar uma carteira e conceder acesso a um aplicativo ao seu endereço público não é o mesmo que conceder uma permissão para movimentação de tokens. A documentação oficial do MetaMask deixa essa distinção explícita: desconectar um aplicativo descentralizado (dapp) remove a conexão, enquanto revogar uma permissão remove a capacidade do contrato inteligente de acessar e movimentar os tokens abrangidos por essa aprovação. Consulte as diretrizes de revogação de aprovações do MetaMask .
O contexto é importante: após a conexão, um site ainda pode apresentar uma solicitação de transação ou assinatura. A etapa perigosa geralmente ocorre após a conexão inicial, portanto, "Eu apenas me conectei" só é seguro se você realmente não assinou ou aprovou nada além disso.
Ação: se você se conectou a um site suspeito, mas rejeitou todas as transações e assinaturas, desconecte-se mesmo assim. Em seguida, verifique a atividade recente e as aprovações da sua carteira, em vez de presumir que a conexão em si movimentou fundos.
Mito 2: “Se eu desconectar o aplicativo descentralizado (dapp), revoguei a aprovação do token.”
Verificado: isso é falso. A aprovação de um token é uma autorização on-chain. Desconectar a sessão do site não apaga automaticamente esse estado na blockchain. A MetaMask observa que a revogação em si é uma transação on-chain e, portanto, normalmente requer gas da rede. A MetaMask explica a diferença aqui .
Isso é importante após um ataque de phishing porque a vítima pode fechar o navegador, desconectar o aplicativo descentralizado (dapp) e acreditar que o perigo passou, enquanto um usuário previamente autorizado ainda mantém a autoridade.
Ação: se você aprovou um gastador em quem não confia mais, use o recurso de gerenciamento de aprovações em sua carteira ou o verificador de aprovações oficial oferecido pelo explorador de rede relevante e envie uma revogação on-chain.
Uma solicitação de gastos ilimitados merece uma análise cuidadosa: verifique o token, o gastador, a rede e o valor solicitado antes de aprovar.
Reduzir o raio de explosão das aprovações ERC-20
As permissões ERC-20 são úteis porque uma exchange descentralizada ou outro contrato pode precisar de permissão para transferir tokens em seu nome. Elas não são inerentemente maliciosas. O problema é o escopo. Se você conceder uma permissão muito grande ou ilimitada e o gastador for malicioso — ou se um contrato confiável se tornar vulnerável posteriormente — o valor em risco pode ser muito maior do que a transação pretendida.
Atualmente, o MetaMask permite que os usuários definam um limite de gastos personalizado para fluxos de aprovação compatíveis. Sua documentação de segurança recomenda verificar o que um aplicativo descentralizado (dapp) está solicitando e limitar o acesso quando apropriado. Consulte as diretrizes do MetaMask sobre limite de gastos .
Ação: quando a carteira oferecer um limite personalizado, aprove apenas o valor necessário para a ação imediata. Se um site exigir acesso ilimitado para uma troca ou saque único, pare e verifique o motivo.
Não ignore as autorizações assinadas só porque não há taxa de combustível.
Verificado: nem toda autorização começa como uma transação de aprovação normal na blockchain. O padrão ERC-2612 introduziu permita permissão ERC-20, que permite que uma permissão seja definida por meio de uma mensagem assinada. O padrão estabelece que uma assinatura válida pode definir a permissão do proprietário para um gastador até um valor e prazo especificados. Leia sobre o ERC-2612 .
Isso significa que "esta assinatura não custa gás" não é prova de que ela seja inofensiva. Uma assinatura pode conter autorização que outra parte posteriormente submete na blockchain. A possibilidade de uma assinatura específica movimentar ativos depende do padrão exato, do contrato, dos campos e da execução subsequente.
Ação: leia os dados estruturados exibidos pela carteira. Preste atenção especial ao gastador, token, valor, prazo, blockchain e domínio do contrato. Rejeite solicitações que você não consiga explicar em linguagem simples.
Uma carteira de hardware pode isolar o material da chave privada, mas não pode tornar segura uma aprovação maliciosa se o usuário a confirmar intencionalmente.
Mito 3: “Uma carteira de hardware me protege automaticamente de golpistas”
Em parte verdade, mas incompleto: carteiras de hardware podem proteger chaves privadas da exposição direta ao navegador ou a malwares comuns, o que é valioso. No entanto, ataques de phishing frequentemente visam a decisão de autorização do usuário. Se o dispositivo exibir uma transação ou aprovação maliciosa e o usuário a confirmar, a barreira de hardware não invalida magicamente a autorização.
A vantagem prática é mais significativa quando o dispositivo permite verificar detalhes importantes da transação em uma tela confiável. A proteção é menor quando a solicitação é opaca ou quando o usuário confirma algo que não entende.
Ação: utilize uma carteira de hardware para ativos de alto valor, mas ainda assim verifique o destino, o contrato, o valor, a rede e a permissão no dispositivo de assinatura. Nunca considere a presença de uma carteira de hardware como permissão para assinar sem autorização.
Fique atento às aprovações dos operadores em NFTs.
Para NFTs, a expressão setApprovalForAllmerece atenção especial. De acordo com o padrão ERC-721, definir um operador como aprovado permite que ele gerencie todos os NFTs daquele contrato que você possui. Isso é mais abrangente do que aprovar um único ID de NFT. O próprio padrão Ethereum distingue a aprovação de um único token da aprovação para todos os NFTs do operador. Consulte as funções de aprovação do ERC-721 .
Isso não significa que toda setApprovalForAllsolicitação seja maliciosa; os mercados de NFTs podem legitimamente precisar de permissões do operador. A questão correta é se o operador e o caso de uso correspondem à sua intenção.
Ação: se você estiver apenas tentando reivindicar um airdrop ou fazer login em um site, uma solicitação inesperada de controle do operador em toda a NFT deve ser tratada como um sinal de alerta importante.
Uma lista de verificação repetível é mais confiável do que a intuição quando uma página de phishing é projetada para criar urgência ou FOMO (medo de ficar de fora).
Verifique o site antes de confirmar a transação.
O phishing do tipo "drainer" (roubo de carteira digital) costuma ter sucesso porque o site falso é muito parecido com o verdadeiro. Um resultado de busca patrocinado, uma resposta em redes sociais, uma mensagem direta, uma conta de suporte falsa ou uma interface copiada podem levar os usuários a um domínio diferente que apresenta solicitações convincentes para saque de carteiras digitais.
Os sistemas de segurança de carteiras podem ajudar, mas não são infalíveis. A API Verify da WalletConnect, por exemplo, pode informar a uma carteira participante se um domínio foi verificado, se há alguma incompatibilidade, se é desconhecido ou se foi sinalizado como malicioso. A WalletConnect alerta explicitamente que essa detecção não é "à prova de balas". Consulte a documentação da API Verify da WalletConnect .
De forma semelhante, o MetaMask descreve seus alertas de segurança como sinais informativos, e não como garantias, e observa que sites legítimos nem sempre exibem um indicador de verificação. Veja Alertas de segurança do MetaMask .
Ação: acesse aplicativos descentralizados (dapps) importantes por meio de um marcador que você criou a partir de uma fonte oficial verificada de forma independente. Não confie no primeiro resultado da busca, em um link encurtado ou em uma URL fornecida em uma mensagem direta não solicitada.
Separar a atividade diária do aplicativo descentralizado (dapp) dos ativos mantidos a longo prazo pode reduzir a exposição dos fundos quando uma carteira envia uma solicitação inválida.
Separe seu "cofre" da sua carteira de "dapps".
Esta é uma técnica de gestão de risco, e não uma regra de protocolo. Uma carteira usada para experimentar novas emissões, reivindicações de tokens, jogos e aplicativos descentralizados (dapps) desconhecidos tem uma superfície de interação maior do que um endereço usado apenas para manter ativos a longo prazo.
A separação não impede ataques de phishing, e a movimentação de ativos entre carteiras cria sua própria carga operacional. Mas pode limitar o valor exposto a uma aprovação equivocada, pois a carteira de interação simplesmente não detém a maior parte dos seus ativos.
Ação: considere manter ativos de longo prazo ou de alto valor em uma carteira que raramente se conecta a aplicativos descentralizados (dapps), enquanto utiliza uma carteira separada com saldo deliberadamente limitado para atividades Web3 de maior risco.
Mito 4: “Um site verificado ou não sinalizado deve ser seguro”
Não verificado: a ausência de um aviso não é prova de segurança. Os bancos de dados de ameaças podem ficar defasados em relação aos domínios de phishing recém-criados, e um aplicativo legítimo ainda pode ter uma interface comprometida ou um contrato vulnerável. O WalletConnect usa um estado explícito de "DESCONHECIDO" para domínios que não pode verificar, e sua documentação afirma que sua camada de verificação não foi projetada para ser infalível.
Ação: trate os avisos de segurança como uma camada de segurança. Verifique separadamente o domínio, o contrato esperado, a permissão solicitada e se a ação faz sentido para o que você está tentando fazer.
Duas verificações distintas são importantes: verificar a origem da solicitação e, em seguida, verificar qual autoridade a solicitação concede.
Audite as aprovações antigas antes que elas se tornem um problema amanhã.
As aprovações podem permanecer ativas mesmo depois de você parar de usar um aplicativo descentralizado (dapp). A MetaMask recomenda verificar periodicamente as aprovações de tokens e revogar as permissões que você não precisa mais. Como a revogação altera o estado na blockchain, geralmente há uma taxa de gás. Consulte o guia oficial de revogação .
A frequência com que você deve auditar depende da frequência com que interage com dApps e do valor que possui na carteira. Não existe um cronograma universalmente correto.
Ação: configure um lembrete recorrente no calendário — por exemplo, mensalmente, se você for um usuário ativo de DeFi — para revisar os gastadores, os tamanhos dos limites, os operadores de NFTs e as permissões antigas de dApps nas blockchains que você realmente usa.
Revisar contratos e permissões é uma prática contínua de higienização da carteira digital, não uma etapa de configuração única.
Se você assinou algo suspeito, identifique qual comprometimento você fez.
Não aplique imediatamente a mesma solução para todos os incidentes. A resposta depende do que aconteceu.
O que aconteceu
O que isso pode significar
Prioridade imediata
Você se conectou apenas a um site.
O site aprendeu seu endereço público e estabeleceu uma sessão, mas isso por si só não é uma permissão simbólica.
Desconecte-se e revise a atividade; não assine solicitações de acompanhamento.
Você aprovou gastos com ERC-20
O usuário indicado poderá transferir a quantia aprovada desse token.
Revogue imediatamente a concessão.
Você aprovou um operador de NFT.
O operador poderá transferir NFTs abrangidos por essa aprovação de coleta.
Revogar a aprovação do operador
Você assinou uma autorização ou outra forma de autorização formal.
A assinatura pode autorizar ações posteriores na blockchain, dependendo do seu conteúdo.
Determine exatamente o que foi assinado e revogue ou transfira os ativos afetados, se possível.
Você expôs sua frase mnemônica/chave privada.
As próprias chaves da carteira estão comprometidas.
Crie uma nova carteira a partir de uma nova frase de recuperação e migre seus ativos.
As diretrizes oficiais da MetaMask para resposta a incidentes afirmam que, quando uma Frase Secreta de Recuperação é comprometida, os usuários devem criar uma nova carteira com uma nova frase de recuperação, transferir os ativos restantes e interromper o uso de contas derivadas da frase comprometida. A MetaMask também alerta que as transações na blockchain são geralmente irreversíveis. Consulte as diretrizes da MetaMask para casos de invasão ou fraude .
Ação: se a frase mnemônica ou a chave privada foram expostas, não considere a revogação das aprovações como suficiente. A própria autoridade de assinatura deve ser considerada comprometida.
Nunca insira uma frase de recuperação para "corrigir" um problema de aprovação.
A Frase Secreta de Recuperação é a credencial principal para contas derivadas dela. A documentação oficial do MetaMask afirma que qualquer pessoa que a obtenha pode controlar a carteira. Um gerenciamento de aprovação legítimo não exige a inserção da frase de recuperação em um site aleatório. Consulte as diretrizes de segurança da frase de recuperação do MetaMask .
Ação: mantenha a frase offline e privada. Se um site, agente de suporte, formulário, bot ou "serviço de recuperação" solicitar essa informação, pare.
Alertas de segurança e controles de conta mais rigorosos adicionam camadas úteis de proteção, mas funcionam melhor em conjunto com uma análise de aprovação cuidadosa e a separação de carteiras.
Uma lista de verificação prática antes da assinatura
Domínio: Este é exatamente o domínio oficial que você pretendia visitar?
Motivo: A permissão solicitada faz sentido para a ação que você iniciou?
Rede: A solicitação está na cadeia esperada?
Contrato ou remetente: O endereço de recebimento ou autorizado é o esperado?
Escopo: É um valor fixo, permissão ilimitada, um NFT por vez ou aprovação do operador para toda a coleção?
Campos de assinatura: Se forem dados digitados, você consegue identificar o token, o gastador, o valor, o prazo e o domínio?
Exposição da carteira: Esta carteira contém mais valor do que você se sente confortável em expor nesta interação?
Sinais de alerta: A carteira está reportando um domínio ou transação maliciosa, incompatível, desconhecida ou suspeita de alguma forma?
Se uma dessas verificações falhar, rejeitar a solicitação geralmente é mais barato do que tentar recuperar os ativos posteriormente.
Como verificar se suas defesas estão funcionando
Você não precisa esperar por um ataque para testar sua configuração. Verifique se os favoritos do seu navegador apontam para os domínios corretos do aplicativo descentralizado (dapp). Abra as ferramentas de gerenciamento de aprovações da sua carteira e confirme se você reconhece os usuários ativos. Verifique se sua carteira de alto valor ainda está isolada de testes rotineiros de dapps. Confirme se sua frase de recuperação não está armazenada em e-mails, notas na nuvem, capturas de tela, registros de bate-papo ou em um campo de gerenciador de senhas de um site. Certifique-se de que os avisos de segurança da carteira estejam ativados, caso sua carteira os ofereça.
Em seguida, teste seu próprio processo de decisão: antes de assinar a próxima solicitação Web3 real, explique em voz alta o que a solicitação autoriza. Se você não conseguir descrever o efeito em uma frase, rejeite-a e investigue primeiro.
Resumindo
A maioria dos ataques de phishing de drenagem obtém sucesso ao transformar uma funcionalidade legítima da Web3 — aprovações, permissões de operador, assinaturas ou transações — em uma arma de engenharia social. A melhor defesa não se resume a uma única extensão, um único dispositivo de hardware ou uma única lista de ameaças. Trata-se de um processo em camadas: verificar o site, compreender a autorização, minimizar seu escopo, separar informações valiosas de interações de risco, revisar permissões antigas e saber diferenciar uma aprovação maliciosa de uma frase de recuperação totalmente comprometida.
As ferramentas de segurança podem reduzir o risco, mas nenhuma pode garantir que uma solicitação maliciosa assinada seja inofensiva. Em sistemas de autocustódia, a confirmação final geralmente representa o limite de segurança. Faça com que essa confirmação seja lenta, específica e deliberada.