Golpes abusam de `Uniswap V3 Multicall` e `Safe` para mascarar aprovações de carteira

Fraudadores usam contratos legítimos e funções de agregação para induzir vítimas a autorizar permissões de token e permitir transferências controladas pelo operador.

Componente	Uniswap V3 Multicall2, função aggregate, contratos GnosisSafeProxy, execTransaction, Safe MultiSend e aprovações de token em carteiras de criptomoedas.
Vetor	A vítima é induzida a assinar transações de aumento de permissão, como increase allowance, contra contratos que aparentam ser legítimos por pertencerem a protocolos conhecidos.
Impacto	Após a aprovação, o operador consegue acionar chamadas como transferFrom por meio de contratos agregadores e redirecionar tokens da carteira da vítima para uma carteira sob seu controle.
Prioridade	Revisar permissões de token, validar contrato, função e destinatário antes da assinatura, monitorar eventos de aprovação e revogar allowances suspeitas.
Artefatos	O fluxo usa endereço legítimo do contrato Uniswap V3 Multicall2 e contratos proxy da estrutura Safe; os hashes de transação aparecem como evidência de cadeia, sem necessidade de interação direta.
Mitigação	Exigir verificação contextual da transação, restringir aprovações amplas, preferir interações iniciadas em interfaces oficiais e auditar histórico de permissões em carteiras expostas.

Resumo técnico

Uma técnica de fraude contra carteiras de criptomoedas passou a explorar a reputação operacional de protocolos legítimos para tornar transações maliciosas menos óbvias para o usuário. O abuso descrito envolve contratos associados ao Uniswap V3, especialmente o contrato Multicall2, e componentes da estrutura Safe, anteriormente conhecida como Gnosis Safe. O ponto central não é uma vulnerabilidade confirmada nesses projetos, mas o uso indevido de funções legítimas que permitem agrupar chamadas, delegar execução ou operar sobre permissões previamente concedidas. Quando a vítima vê um endereço reconhecido, como um contrato rotulado como parte do Uniswap, pode interpretar a solicitação como uma operação normal de troca de tokens ou de gestão de carteira, mesmo quando os parâmetros internos direcionam ativos para um fluxo controlado por fraudadores.

O golpe depende de uma etapa crítica: a autorização dada pela própria carteira da vítima. Em vez de exigir exploração direta do contrato do protocolo, o operador tenta obter uma assinatura para aumentar a permissão de movimentação de um token. Essa permissão, usualmente associada ao modelo ERC-20 de allowance, permite que um contrato ou endereço execute movimentações em nome do titular até o limite aprovado. Depois que a aprovação é registrada, o operador usa uma chamada agregada para acionar transferFrom contra o token escolhido. O resultado prático é que a movimentação aparece dentro de uma sequência tecnicamente válida, mas a intenção da transação foi distorcida por engenharia social, abuso de interface e confiança em nomes conhecidos do ecossistema.

Fluxo técnico

No caso associado ao Uniswap V3 Multicall2, a função relevante é aggregate. Essa função aceita uma lista de chamadas, cada uma com destino e dados de chamada próprios, e executa múltiplas operações dentro de uma única transação. A característica é útil para reduzir fricção operacional, combinar ações e preservar coesão transacional em aplicações descentralizadas. O risco surge porque a função permite que usuários forneçam alvos e dados arbitrários para cada chamada. Assim, a presença de um contrato legítimo no início da interação não garante que todos os destinos internos e parâmetros representem uma operação segura para a carteira que está assinando.

O fluxo observado começa quando a vítima é levada a aprovar um aumento de allowance para um contrato que parece confiável. Pouco depois, a autorização recém-criada permite que uma chamada agregada execute transferFrom contra um token específico. A função transferFrom exige autorização prévia para que um terceiro movimente fundos de uma carteira; por isso, a assinatura de aumento de permissão é a condição técnica que torna o desvio possível. A chamada agregada oculta a intenção em uma estrutura mais complexa, na qual a interface da carteira ou o usuário podem destacar o contrato conhecido, mas não interpretar de forma clara o alvo final, o token afetado, o destinatário e o limite de gasto.

A segunda variação usa a estrutura do Safe. O operador cria um proxy aparentemente legítimo por meio de componentes do ecossistema Gnosis Safe e convence a vítima a interagir com esse contrato. Depois da aprovação, a execução passa por execTransaction no contrato proxy, que encaminha a chamada para a cópia principal por delegatecall. Esse desenho é parte do funcionamento normal do Safe, pois permite que o proxy mantenha estado próprio enquanto executa lógica compartilhada. No abuso descrito, a cadeia passa ainda por componentes de execução e pelo Safe MultiSend, que agrupa múltiplas transações em uma operação única. A análise do dado enviado ao MultiSend indicou três chamadas transferFrom envolvendo o token Umbrella, todas orientadas a drenar tokens da carteira da vítima.

Superfície afetada

A superfície exposta inclui usuários que assinam transações sem verificar permissões, contratos de destino e dados internos de chamada, especialmente em carteiras que apresentam apenas uma visão resumida da operação. Protocolos como Uniswap e Safe são amplamente usados e processam grande volume de atividade legítima. O Uniswap é descrito como uma das principais aplicações descentralizadas em redes como Ethereum, Polygon, Arbitrum e Optimism, com grande volume de trocas e valor bloqueado. O Safe.global é descrito como uma plataforma de carteira por contrato inteligente, com contas implantadas, transações registradas e ativos administrados em escala significativa. Esse volume aumenta o valor da marca técnica desses contratos para engenharia social, porque endereços reconhecidos tendem a reduzir a suspeita visual em uma aprovação.

Ambientes mais vulneráveis são aqueles em que usuários mantêm saldos relevantes de tokens, aceitam permissões amplas e dependem apenas do rótulo do contrato em exploradores ou carteiras. Também há risco para equipes que operam tesourarias, carteiras compartilhadas, carteiras de trading e contas com histórico frequente de interação com DEXs. A fraude não requer que o protocolo legítimo esteja comprometido; ela exige que a vítima conceda permissão a um fluxo que o operador consegue reaproveitar. Esse detalhe altera a resposta defensiva: o foco deve estar em visibilidade de approvals, interpretação de chamadas compostas e governança de assinatura, e não apenas em bloquear um endereço por reputação.

A presença de contratos legítimos também dificulta filtros simples de bloqueio. Um alerta baseado apenas em nome de protocolo, endereço rotulado ou contrato verificado pode gerar falso negativo, porque a transação passa por componentes que realmente pertencem a sistemas conhecidos. O ponto de decisão deve considerar relação entre aprovador, spender, token, limite, função invocada, proximidade temporal entre approval e movimentação, e se a sequência inclui agregação por aggregate, execTransaction ou MultiSend.

• Carteiras que recebem solicitações de increase allowance sem validação detalhada do spender, token e limite.
• Usuários que confiam em rótulos de exploradores de bloco como substituto para análise dos parâmetros da transação.
• Contas que interagem com DEXs, contratos proxy e funções de agrupamento de chamadas em redes compatíveis com Ethereum.

Hunting e telemetria

A investigação defensiva deve começar pela correlação entre eventos de aprovação e transferências subsequentes. Um padrão relevante é a ocorrência de um evento de approval concedido pela vítima a um contrato reconhecido, seguido em curto intervalo por uma chamada transferFrom iniciada em uma transação agregada. O intervalo temporal é importante porque o abuso descrito depende de autorização recente para elevar o limite de gasto antes da movimentação dos tokens. Em logs on-chain, a busca deve relacionar owner, spender, token, valor autorizado e destinatário final. A simples existência de um approval não confirma fraude, mas approvals com limite incompatível com a operação esperada, seguidos por drenagem de saldo, são sinais fortes.

No caso de Uniswap V3 Multicall2, a telemetria deve observar transações direcionadas ao contrato Multicall2 em que a função aggregate encapsula chamadas para contratos de token. O interesse está no conteúdo lógico da chamada interna, não apenas no contrato externo. Para Safe, o hunting deve acompanhar proxies recém-criados ou pouco usuais, chamadas execTransaction acionadas após permissões concedidas por vítimas, e uso de MultiSend contendo múltiplas operações de transferência. Quando a carteira pertence a uma organização, esses eventos devem ser cruzados com histórico de assinadores, janela de aprovação, interface usada e mudanças recentes em permissões.

Em endpoint e navegador, sinais complementares podem incluir acesso a páginas de phishing, links recebidos por e-mail ou redes sociais e sessões em que a carteira foi conectada a sites não verificados. Como o golpe depende de assinatura do usuário, a telemetria fora da cadeia ajuda a explicar a origem da solicitação. A defesa deve registrar contexto de conexão da carteira, domínio de origem defangado quando houver evidência, horários, extensão usada e capturas de tela internas quando disponíveis. Não é necessário publicar payloads ou links ativos para investigar o incidente; os elementos úteis são sequência de assinatura, contrato chamado, allowance criada e destino final dos tokens.

• Evento de approval seguido rapidamente por transferFrom contra o mesmo token e owner.
• Chamadas aggregate contendo destinos internos diferentes do contrato externo apresentado ao usuário.
• Uso de execTransaction e Safe MultiSend para agrupar múltiplas transferências após aumento de allowance.
• Allowances elevadas ou incompatíveis com a transação que o usuário acreditava estar autorizando.

Mitigação

A resposta deve priorizar revisão e revogação de permissões. Usuários e equipes responsáveis por carteiras precisam identificar allowances ativas para tokens relevantes e remover autorizações desnecessárias ou excessivas, especialmente quando o spender está ligado a uma interação não reconhecida. Para carteiras institucionais, a política de assinatura deve exigir validação do contrato, da função, do token, do limite e do destinatário antes de qualquer aprovação. A presença de um endereço legítimo ou rotulado não deve ser suficiente para autorizar uma transação quando os dados internos indicam chamada composta ou delegada.

A mitigação operacional exige reduzir permissões amplas. Quando a aplicação permitir, aprovações devem ficar limitadas ao valor necessário para a operação esperada. Transações que envolvem increase allowance, aggregate, execTransaction, delegatecall ou MultiSend devem receber tratamento de maior risco quando o usuário não iniciou a ação diretamente em uma interface oficial conhecida. A validação manual deve observar se a carteira está interagindo com o domínio correto, se a função corresponde à intenção do usuário e se o contrato de token afetado é o esperado. Links de e-mail e redes sociais devem ser tratados como origem de risco para solicitações de assinatura.

Em organizações, a contenção inclui congelar novas assinaturas da carteira afetada, preservar hashes e logs de transação para análise, mapear todas as permissões criadas na janela do incidente e verificar se houve outras transferências relacionadas ao mesmo spender. Depois da revogação, a equipe deve revisar procedimentos de aprovação, configurar alertas para allowances incomuns e educar operadores sobre a diferença entre contrato externo exibido e chamadas internas encapsuladas. A prevenção mais consistente vem da combinação de carteira com decodificação detalhada, revisão por múltiplos aprovadores para ativos críticos e monitoramento contínuo de eventos on-chain que ligam approval a transferência em sequência.

• Revogar allowances desconhecidas, excessivas ou criadas imediatamente antes de transferências suspeitas.
• Validar contrato, função, token, limite e destinatário antes de assinar qualquer aprovação.
• Configurar alertas para increase allowance seguido por transferFrom em curto intervalo.
• Preferir interações iniciadas em interfaces oficiais e evitar solicitações recebidas por links externos.
• Revisar carteiras compartilhadas com governança de múltiplos aprovadores e decodificação completa da transação.