USDT Bridge Sent Funds to USDT Contract

[Roodvan]

Hi everyone,

We encountered a very unusual situation in our service and would appreciate any thoughts, similar experiences, or technical insights.

We were swapping USDT between two networks (ERC-20 → BEP-20) using PancakeSwap’s cross-chain swap functionality in manual mode. In simple terms, funds were sent from one MetaMask wallet to another MetaMask wallet. This was a routine operation that had been performed many times before without issues.

Unexpectedly, the swap got stuck. The destination wallet we specified never received the funds.

After investigating the transaction in the blockchain explorers, we discovered that the funds had ultimately been sent to the following BEP-20 address:

0xdAC17F958D2ee523a2206206994597C13D831ec7

What makes this particularly strange is that this address is the well-known USDT (ERC-20) contract address on Ethereum.

We considered two primary possibilities:

A technical issue on the PancakeSwap side or on the side of their bridge provider, Across Protocol.
Human error, where an employee somehow copied and pasted this address as the recipient address, despite having no apparent reason or incentive to do so.

Clipboard malware, address-replacement malware, and similar attack vectors were ruled out. In such cases, funds would normally be redirected to an attacker’s wallet, not to a publicly known token contract address.

We reviewed all communications with PancakeSwap and Across support teams. Following their internal investigations, both stated that they found nothing suspicious on their side and suggested that this address had been specified as the recipient in the order itself.

As part of our internal investigation, the employee involved was also subjected to a polygraph examination and showed no signs of deception throughout the entire scope of questioning.

We are trying to understand what could realistically explain this situation.

We can provide all relevant transaction hashes, logs, and technical details to anyone willing to help analyze the case.

(Scammers, please don’t waste your time.)

If someone can provide useful technical guidance or help identify a path that ultimately leads to the recovery of the funds, we are willing to offer a financial reward based on a percentage of any recovered amount.

Any ideas or similar cases would be greatly appreciated.

txid : https://etherscan.io/tx/0x7ddd37dae2c5ad1ec97646606ec91fe12130b09525ac815d2ff05c219e9d4500

[asriloni]

It seems it's related to the poisoning attack. BSC scan has already tagged it. So it's obviously you're not the only one who is facing this problem. It's almost impossible to solve this because the only wallet owner who can access that fund.

So the better try to ask this to the tether support. As far as i know tether is the only one who has access to that fund since it's the same addy used as USDT ETH contract.

[rat03gopoh]

Clipboard malware, address-replacement malware, and similar attack vectors were ruled out. In such cases, funds would normally be redirected to an attacker’s wallet, not to a publicly known token contract address.

Why not try again with another small amount to test if the device is still working properly? Attackers also need to test their scripts.

As part of our internal investigation, the employee involved was also subjected to a polygraph examination and showed no signs of deception throughout the entire scope of questioning.

Did you or whoever executed this exchange enable an option like "receive to another address"?
If this becomes a routine, sometimes users start to become less careful when selecting wallet addresses.

[Roodvan]

So the better try to ask this to the tether support. As far as i know tether is the only one who has access to that fund since it's the same addy used as USDT ETH contract.

We’ve already contacted them, but since they didn’t issue the token on the BSC network, they can’t help; they advised us to contact Binance.
Binance states that they don’t control the recipient’s address and referred us to BSCscan, which, in turn, is only responsible for the blockchain explorer.

[Roodvan]

Why not try again with another small amount to test if the device is still working properly? Attackers also need to test their scripts.

We used PancakeSwap a few more times after that incident, and everything went smoothly.

Did you or whoever executed this exchange enable an option like "receive to another address"?
If this becomes a routine, sometimes users start to become less careful when selecting wallet addresses.

We used expert mode, which allows you to specify a different address when receiving tokens.

[rat03gopoh]

We used expert mode, which allows you to specify a different address when receiving tokens.

I took a quick look at pancake swap's "expert mode", one of its features eliminates the standard double-check popup, right? So what can users do to determine recipient addresses, (1)only allow whitelisted addresses, or (2)you can still enter addresses manually?
If the answer is 2, doesn't the risk of wrongly addressing the recipient increase drastically in this mode?