Fraude deepfake em RWA: travar chamadas falsas de emitentes

O que é a fraude RWA com deepfakes?

A fraude RWA com deepfakes é uma fraude de pagamento dirigida a transações que envolvem ativos do mundo real, geralmente abreviados como RWA. Estes ativos podem incluir fundos do mercado monetário tokenizados, títulos de dívida pública, crédito privado, matérias-primas ou outros direitos representados através de sistemas baseados em blockchain. O burlão não precisa necessariamente de piratear o token ou o seu smart contract. Em vez disso, o atacante faz-se passar por uma pessoa de confiança e redireciona o pagamento convencional usado para comprar ou liquidar o ativo.

Um alvo típico é um funcionário de tesouraria, administrador de fundos, family office, corretor ou investidor institucional a preparar uma grande subscrição. A vítima acredita que um representante do emissor, agente de colocação, advogado, agente de transferência ou responsável de escrow forneceu instruções válidas. Em vez disso, o pagamento chega a uma conta controlada por criminosos, por uma mula financeira recrutada ou por uma empresa de fachada com um nome semelhante ao do beneficiário legítimo.

Esta distinção é importante ao discutir produtos associados a BUIDL, ONDO, PAXG ou XAUT. Esses tickers referem-se a estruturas diferentes e não partilham um único processo de subscrição. ONDO também é usado como ticker de token dentro do ecossistema Ondo, enquanto PAXG e XAUT representam produtos de ouro tokenizado. Uma instrução de transferência fraudulenta que mencione qualquer um deles não prova que o protocolo ou emissor subjacente tenha sido comprometido. Os atacantes exploram frequentemente o nome reconhecível em torno de um pagamento bancário que, de resto, é tradicional.

Porque é que o risco financeiro é invulgarmente grave

O risco óbvio é perder a totalidade do capital da subscrição. Grandes transferências podem passar por várias contas de mulas em poucas horas, ser convertidas em crypto ou sair da jurisdição recetora antes de a vítima se aperceber. Um banco pode tentar uma recuperação, mas uma recuperação é um pedido, não uma reversão garantida. A recuperação torna-se menos provável à medida que o dinheiro é dividido, levantado ou transferido para diante.

O caso de Hong Kong de fevereiro de 2024 mostra a escala potencial. A polícia disse que um funcionário de uma empresa multinacional participou numa videoconferência que parecia incluir o diretor financeiro da empresa e outros colegas. Após a chamada, o funcionário terá autorizado 15 transferências num total de cerca de HK$200 milhões, então equivalentes a aproximadamente 25 milhões de dólares, para cinco contas bancárias. A empresa de engenharia Arup confirmou mais tarde que tinha sido a vítima, afirmando ao mesmo tempo que os seus sistemas internos não tinham sido comprometidos.

As deepfakes inserem-se no problema mais amplo de business email compromise, usurpação de identidade e fraude de pagamentos autorizados. Os relatórios públicos de perdas combinam frequentemente vários métodos, pelo que não existe um valor público fiável que isole o montante anual atribuível apenas a vozes e rostos gerados por AI. O que se sabe é que o business email compromise gerou, ao longo do tempo, perdas comunicadas na ordem dos milhares de milhões de dólares. Para uma empresa individual, uma única instrução bem-sucedida pode criar uma exposição imediata de oito ou nove dígitos.

• Perda de capital: o dinheiro da subscrição pode nunca chegar ao emissor, pelo que a vítima não recebe qualquer token ou direito legal.
• Perda operacional: as equipas de trading, tesouraria, jurídica e resposta a incidentes podem passar semanas a rastrear o pagamento e a preservar provas.
• Incerteza jurídica: contratos, condições bancárias, exclusões de seguros e a autoridade dos funcionários determinam quem acaba por suportar a perda.
• Compromisso secundário: documentos enviados durante o falso processo de onboarding podem expor passaportes, assinaturas, registos de beneficiários efetivos e endereços de carteiras.
• Danos reputacionais: uma divulgação tardia pode enfraquecer relações com investidores, bancos, auditores e reguladores.

As perdas históricas também mostram porque uma deepfake não deve ser tratada como uma novidade que apenas engana utilizadores descuidados. A falha decisiva é geralmente processual. Um funcionário pode receber um pedido urgente, ver executivos aparentemente familiares e seguir um fluxo de pagamento que não tem verificação independente. A AI torna a história mais convincente, mas controlos de aprovação fracos tornam a perda possível.

Como uma chamada falsa do emitente se transforma numa transferência fraudulenta

O atacante começa pela recolha de informação. Vídeos públicos de conferências, chamadas de apresentação de resultados, podcasts, webinars, publicações nas redes sociais, documentos regulatórios e perfis de colaboradores revelam vozes, rostos, cargos, relações comerciais e transações futuras. Alguns minutos de áudio limpo podem ser suficientes para certas ferramentas de clonagem imitarem características vocais. Mais material pode ajudar a reproduzir padrões de fala, vocabulário e maneirismos visuais, embora a qualidade varie e ainda possam surgir artefactos.

Segue-se o acesso ou o posicionamento. O criminoso pode comprometer uma conta de email, registar um domínio parecido, comprar um resultado de pesquisa patrocinado, criar um portal de integração falso ou fazer-se passar por intermediário num serviço de mensagens. A vítima pode acreditar que ligou para o emitente porque marcou um número apresentado num email fraudulento ou num site clonado. Na realidade, o atacante controlava o ponto de partida e todas as confirmações posteriores.

Durante a chamada, o áudio gerado por AI pode ser encaminhado através de software de voz sobre protocolo de internet, de um dispositivo de áudio virtual ou de conversão de voz em tempo real. O operador fala normalmente, o software altera a voz e a saída modificada entra numa aplicação telefónica ou de conferência. O vídeo pode usar substituição de rosto, sincronização labial, imagens pré-gravadas ou uma mistura de material sintético e genuíno. Outros supostos participantes podem ser gravações silenciosas, bots ou cúmplices que reforçam o mesmo pedido.

A narrativa do pagamento é concebida para parecer operacionalmente plausível. O falso representante do emitente pode dizer que a conta habitual está em revisão, que um novo prestador de escrow está a tratar do fecho ou que a liquidação tem de ocorrer antes de uma hora-limite. Uma segunda voz clonada pode surgir para representar o advogado ou o responsável pelo escrow. Depois, o atacante envia faturas, documentos de subscrição, cartas bancárias ou aprovações por email correspondentes, fazendo com que vários sinais comprometidos pareçam provas independentes.

Uma cadeia de ataque credível

• Um investidor procura um contacto do emitente ou responde a uma conversa de email comprometida sobre uma subscrição de RWA.
• Um representante com uma voz familiar atende e confirma o montante da transação, a entidade jurídica e a data prevista de fecho.
• Uma reunião por vídeo mostra um executivo ou colega reconhecível, por vezes acompanhado de vários participantes de apoio.
• O interlocutor apresenta novos dados de escrow e explica a alteração com urgência, confidencialidade ou linguagem regulatória.
• A vítima verifica as instruções respondendo à mesma conversa de email ou ligando para um número incluído nos novos documentos.
• Os aprovadores libertam uma transferência de vários milhões, acreditando que ocorreram várias confirmações.
• Mais tarde, o emitente real comunica que nenhum pagamento chegou, altura em que a conta de destino pode já estar vazia.

Os atacantes também podem substituir uma conta bancária por um endereço de carteira cripto. Essa variante sobrepõe-se ao wallet address poisoning e à manipulação da área de transferência. As transferências em blockchain geralmente não têm um processo bancário de chamada de fundos, o que pode tornar a recuperação ainda mais difícil. Quer a liquidação use uma transferência bancária quer uma transferência onchain, os dados de destino alterados devem ser tratados como uma nova instrução de alto risco, não como uma alteração de rotina.

Porque uma videochamada já não é prova de identidade

O vídeo costumava oferecer uma forte garantia psicológica porque reproduzir uma pessoa conhecida em tempo real era caro e difícil. Essa suposição já não é segura. Hardware de consumo e software amplamente disponível podem gerar um rosto, alterar uma voz, disfarçar artefactos e encaminhar o resultado para plataformas de reunião comuns. Uma má ligação pode até ajudar o atacante, porque a compressão, a baixa resolução, os participantes em silêncio e os atrasos de áudio fazem com que as anomalias pareçam normais.

O caso de Hong Kong demonstrou que várias pessoas aparentemente familiares numa só reunião podem ser todas fabricadas. O consenso de grupo não é útil se todos os participantes e o convite vierem pelo mesmo caminho comprometido. Um colaborador que reconhece o rosto do CFO está a observar uma semelhança, não a verificar o controlo da identidade, do dispositivo, da conta corporativa ou da autoridade legal do CFO.

A WPP divulgou uma tentativa de fraude separada em 2024 que envolvia a personificação do chief executive Mark Read. Segundo o aviso da empresa, os atacantes criaram uma conta falsa de WhatsApp, usaram uma voz clonada e recorreram a imagens públicas numa reunião de Microsoft Teams. Tentaram solicitar dinheiro e dados pessoais enquanto propunham uma nova estrutura de negócio. A tentativa falhou, mas mostrou como meios públicos e ferramentas comuns de colaboração podem ser combinados para personificar um executivo.

Os indícios visuais ainda podem contribuir para uma investigação, mas não devem autorizar um pagamento. Piscar de olhos pouco natural, iluminação incompatível, erros de sincronização labial, formulações invulgares ou recusa em mover a câmara podem levantar suspeitas. A ausência desses sinais prova pouco, porque as ferramentas de geração melhoram, a compressão das conferências oculta defeitos e um atacante competente pode misturar imagens autênticas com segmentos sintéticos. O software de deteção também produz falsos positivos e falsos negativos, pelo que deve ser uma camada e não o controlo final.

Sinais que justificam suspender um pagamento

• A conta do beneficiário, o banco, o país, o agente de escrow ou o endereço de carteira mudaram depois da integração.
• O interlocutor introduz urgência ligada a uma janela de fecho, evento de mercado, auditoria ou prazo de conformidade.
• O suposto executivo desencoraja o contacto com o jurídico, compliance, o banco ou outro colaborador conhecido.
• O convite para a reunião, o número de telefone ou o portal de documentos foi fornecido na mesma mensagem que a alteração de pagamento.
• Os participantes evitam perguntas específicas sobre a transação ou explicam inconsistências como assuntos internos confidenciais.
• O nome do beneficiário não corresponde exatamente à entidade jurídica indicada nos documentos de subscrição assinados.

Verificação fora do canal versus confirmação no próprio canal

Verificação no próprio canal significa verificar um pedido através do mesmo canal ou percurso de confiança que o entregou. Responder ao email que forneceu novos dados bancários é uma verificação no próprio canal. Ligar para o número de telefone impresso na instrução anexa também é no próprio canal, porque o atacante pode controlar ambos. Passar de email para vídeo não é verdadeiramente independente quando o convite por email leva a uma reunião controlada pelo atacante.

Verificação fora do canal começa a partir de informações de contacto estabelecidas separadamente antes do pedido contestado. Exemplos incluem ligar para a central telefónica principal conhecida de um emitente a partir de um registo de fornecedor aprovado, contactar um gestor de relação já guardado no sistema de tesouraria ou abrir o portal do emitente a partir de um marcador guardado em vez de uma ligação numa mensagem. O objetivo não é apenas usar outra aplicação. É sair da cadeia potencialmente comprometida e reconstruir o contacto a partir de uma fonte fiável.

A independência também se aplica a pessoas e dados. Se um colaborador recebe instruções e pede a um colega que aprove o mesmo PDF, duas pessoas reviram um artefacto controlado pelo atacante. Uma verificação mais forte atribui a um segundo colaborador a tarefa de recuperar as instruções de liquidação permanentes a partir de um sistema protegido, contactar o emitente de forma independente e comparar cada campo relevante. Nenhum aprovador deve confiar no identificador de chamada, uma vez que os números apresentados podem ser falsificados.

• Verificação fraca: responder ao remetente a perguntar se a nova conta está correta.
• Verificação fraca: ligar para o número indicado na instrução de transferência alterada.
• Verificação fraca: pedir ao mesmo participante da videochamada que mostre identificação à câmara.
• Verificação mais forte: ligar para um número do emitente previamente registado e pedir transferência através da central telefónica principal.
• Verificação mais forte: confirmar a alteração separadamente com o banco de escrow, o advogado ou o administrador usando dados obtidos de forma independente.
• Verificação mais forte: comparar a instrução com documentos assinados e exigir uma alteração controlada quando qualquer campo diferir.

Nenhum canal é perfeito. Um contacto guardado pode estar desatualizado, uma conta de colaborador pode estar comprometida e uma central telefónica pode cometer um erro. A verificação fora do canal reduz falhas correlacionadas ao obrigar um atacante a comprometer mais do que um sistema ou relação independente. Transações de valor elevado devem combiná-la com dupla aprovação, acesso com privilégio mínimo, limites de pagamento e controlos de alteração documentados.

Um procedimento de chamada de retorno ao emitente que fecha o circuito

Para equipas de tesouraria, o objetivo prático é provar que o emitente genuíno ou o administrador autorizado espera a transação exata que está a ser libertada. Uma chamada de retorno só é eficaz quando a equipa escolhe o caminho de contacto de forma independente. Ligar para um número fornecido pelo requerente, confiar numa chamada recebida ou depender do identificador de chamada apresentado deixa o circuito aberto.

Antes de qualquer pedido de subscrição

• Registe o nome legal do emitente, os contactos autorizados, a central telefónica principal, o administrador, o agente de transferência, o prestador de escrow e os dados bancários aprovados num sistema restrito.
• Obtenha esses dados a partir de acordos assinados, registos regulatórios, um portal autenticado do emitente ou uma relação verificada existente, não a partir de um novo email de pagamento.
• Defina quais as funções que podem pedir uma alteração de pagamento e exija que dois colaboradores aprovem qualquer alteração que envolva beneficiário, banco, número de conta, código SWIFT, número de encaminhamento ou carteira.
• Acorde que o emitente não exigirá segredo nem contornará o processo de chamada de retorno, mesmo perto de um prazo de fecho.

Quando as instruções chegam

• Suspenda o pagamento se qualquer campo de destino diferir do registo permanente. Não edite o registo mestre a partir do documento recebido.
• Peça a um segundo colaborador que recupere o número estabelecido do emitente sem usar ligações, assinaturas, anexos, mensagens de chat ou resultados de pesquisa fornecidos durante a transação.
• Faça uma chamada de saída para a central telefónica principal conhecida do emitente. Peça ao operador que ligue a equipa ao representante previamente autorizado, em vez de pedir um número direto ao interlocutor original.
• Indique a referência interna da transação e peça ao representante que identifique a entidade investidora, o ativo, o montante, a moeda, a data prevista, o nome legal do beneficiário, o banco, os últimos dígitos da conta e o motivo de qualquer alteração.
• Repita todos os campos relevantes da liquidação. Não aceite uma resposta geral como dizer que os dados estão corretos.
• Termine a primeira chamada e contacte de forma independente o prestador de escrow, o administrador ou o advogado usando os dados previamente verificados. Confirme que reconhece a mesma transação e o mesmo beneficiário.
• Exija uma alteração formalmente assinada para instruções modificadas e depois valide as assinaturas ou a aprovação digital através do processo documental estabelecido.
• Aplique um período de reflexão para contas recentemente alteradas quando as operações o permitirem, e peça a ambos os aprovadores que documentem as fontes, a hora, os contactos e os campos verificados.

Isto fecha o circuito porque a transação começa no diretório fiável do investidor, chega ao emitente genuíno através da sua central telefónica estabelecida e regressa com informações específicas da transação que podem ser comparadas com registos controlados. Uma correspondência de voz ou um rosto reconhecível é desnecessário. O procedimento verifica autoridade, destino e detalhes da transação, não a aparência.

Se um pagamento suspeito já tiver sido enviado, contacte imediatamente a equipa de fraude do banco remetente e peça a chamada de fundos ou o congelamento da transferência. Notifique a instituição recetora quando permitido, preserve emails, registos de chamadas, cabeçalhos, documentos, dados de conta e registos de reuniões, e envolva consultores jurídicos, seguradoras e as autoridades. Não continue a interagir com o atacante suspeito a partir de contas corporativas normais, pois isso pode revelar o plano de resposta ou destruir provas.

Acompanhe sinais de segurança de RWA com contexto

Os mercados de RWA e as técnicas de fraude que os rodeiam mudam rapidamente, enquanto os relatórios de incidentes muitas vezes misturam falhas genuínas de protocolos com falsificação de identidade offchain. O Zippfeed organiza manchetes relevantes com classificação de sentimento bullish, neutral ou bearish e uma avaliação de importância, ajudando as equipas de segurança e tesouraria a separar o ruído do mercado de desenvolvimentos que possam justificar uma revisão dos controlos. O sentimento é contexto, não prova, por isso a verificação de pagamentos deve continuar a basear-se em procedimentos estabelecidos de forma independente.