Another Lazarus Group Attack? Decoding Wazirx Multisig Wallet’s $235M Exploit

• Incident Overview: WazirX’s multisig wallet, managed in part by Liminal’s custody services, was exploited, resulting in a loss of over $235M. Moments before the exploit, they had a total of 451M worth of assets onchain, out of which 235M has been moved to the exploiter wallet. That is approximately 51% of total onchain assets.

• Attack Method: The multisig wallet had 6 signatories: 5 from the WazirX team and 1 from Liminal, responsible for transaction verifications. The attackers compromised 3 WazirX signatories and 1 Liminal signatory using phishing tactics. They directly compromised 2 WazirX signatories and then used a fake Liminal UI to trick the remaining WazirX signatory and the Liminal signatory into signing malicious transactions.

• Execution: By exploiting the multisig setup, the attackers upgraded the wallet to a malicious contract, allowing continuous transfer of funds to their own wallet.

• ZachXBT’s Findings: Blockchain investigator ZachXBT traced the transactions to addresses funded via Tornado Cash. He discovered that the attackers conducted test transactions from a specific multisig wallet, demixed funds from Tornado Cash, and traced Bitcoin deposits linked to the hack.

• WazirX’s Response: WazirX outlined the incident, emphasizing their commitment to transparency and ongoing efforts to recover the stolen funds. They suspect the payload was replaced during the transaction verification process and attributed the fault to Liminal's system.

• Liminal’s Statement: Liminal confirmed that the breach did not occur within their platform but involved a wallet created outside their ecosystem.

• Stolen Assets: Here's what has been stolen as of now:
• 5.43T $SHIB
• 15,298 $ETH
• 20.5M $MATIC
• 640.27B $PEPE
• 5.79M $USDT
• 135M $GALA
• 6.3M $FTM
• 201K $LINK
• 1.5M $FET
• 76.5M $JASMY
• 1.9B $DENT
• 6.7M $CHR
• 4.7M $SAND
• 859M $HOT
• 13.7M $COTI
• 2.8M $1INCH
• 78.6M $CELR
• 25.7M Others

These were minted through the Gnosis Safe Proxy contract and sent to the attacker's wallet

At the time of writing, the attacker’s primary wallet holds $148,899,745.12 with major holding in 43.8k ETH. Rest of the altcoins are sold for ETH.

Another major account holds $66,280,399.07 with 15.296k ETH

1. Deployment of a Phishing Contract

The attackers deployed a phishing smart contract designed to mimic a legitimate Safe Implementation Skeleton. This contract, although seemingly innocuous, contained malicious code aimed at exploiting the multisig wallet. The contract’s sole function was to divert funds from the multisig wallet to the attackers’ address.

It was deployed on July 10th at 07:37:47 UTC, 8 days before the final exploit, indicating that the whole exploit was well-panned from the start.

2. Compromising Multisig Signers

Multisig wallets typically require multiple signatures from authorized team members to approve transactions. The WazirX multisig wallet had 6 signatories: 5 from WazirX and 1 from Liminal. To exploit this, the attackers compromised the necessary private keys using a combination of methods:

• Direct Compromise: Attackers obtained 2 out of the 4 required private keys through direct compromise. This could have been achieved through phishing attacks, where the attackers created a fake Safe App UI to deceive the wallet owners into revealing their private keys. Other methods include malware to capture keystrokes or screen captures, social engineering to gain trust and obtain private keys, credential reuse from other data breaches, or insider threats from collaborators with access to private keys.

• Phishing for Signatures: The attackers tricked the remaining signers into approving transactions they believed to be legitimate. This was possibly executed through a compromised Liminal’s UI, which displayed seemingly legitimate transaction details. In reality, the attackers had swapped the actual contract with their phishing contract, designed to mimic a legitimate Safe Implementation Skeleton. This allowed them to gain the necessary approvals and siphon funds from the wallet.

   

3. Execution of a Fake USDT Transfer

To gather the necessary signatures without raising suspicion, the attackers initiated a fake USDT transfer. The USDT Transfer Attempt was crafted to fail but was designed to collect the required signatures.

The transaction failed, but the attackers obtained the signatures needed for their malicious transaction.

4. Upgrading to a Malicious Multisig Implementation

The multisig wallet was implemented using a proxy pattern. In this pattern, the multisig wallet (proxy) doesn't directly contain the actual business logic or code. Instead, it points to an implementation contract where the actual logic or code resides. The proxy has a storage slot that contains the address of the current implementation contract.

With the collected signatures, the attackers executed a delegate call from the multisig wallet to their malicious contract, altering the slot0 of the multisig proxy to point to the phishing contract address.

Delegate Call Data: 0x804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc6

The first 4 bytes, 0x804e1f0a, correspond to the function selector of the target contract's function that the delegate call is invoking. This is typically derived from the function's signature.

The remaining bytes, 000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc6, represent the parameter(s) passed to the function. In this case, the parameter is an address 0xef279c2ab14960aa319008cbea384b9f8ac35fc6.

So, this delegate call data means the multisig contract is executing a function (identified by the selector 0x804e1f0a) on the phishing contract address 0xef279c2ab14960aa319008cbea384b9f8ac35fc6, with this address as the parameter.

This delegate call changed the multisig wallet’s implementation to the malicious contract, redirecting all subsequent transactions.

5. Modifying the Multisig Contract Storage

Using tools like evm.storage, it was observed that the slot0 of the multisig proxy was changed from the standard Safe Implementation to the new phishing contract. This modification gave the malicious contract control over the multisig’s funds.

6. Draining the Multisig Wallet

Once the multisig wallet was upgraded to the malicious contract, the attackers began to transfer all funds from the multisig wallet to their own wallet. Transactions involving significant amounts, such as 95 million worth of Shiba Inu ($SHIB) tokens, were executed.

From this point forward, every transaction to the Safe Multisig redirected a delegate call to the new malicious implementation address. This allowed the attackers to continuously transfer funds from the multisig wallet.

The attack exploited a flaw in the multisig wallet’s contract upgrade mechanism. The attackers deployed a phishing smart contract that mimicked a legitimate Safe Implementation Skeleton, which is basically a template or base contract for the Gnosis Safe. This tricked the signers into approving it. This contract replaced the genuine implementation with a malicious version that redirected all subsequent transactions to the attackers.

By compromising the multisig signers through phishing tactics and a fake Liminal UI, the attackers gathered the necessary 4 signatures out of 6 to execute the malicious contract upgrade. Specifically, they directly compromised 2 WazirX signers and tricked 1 WazirX signer and the Liminal signer using the fake UI. Once the contract was swapped with their malicious version, the attackers gained control of the wallet, allowing them to transfer all the assets from the Multisig wallet to their own wallet.

1. Funding and Demixing:

• The attacker’s address received 6 x 0.1 ETH from Tornado Cash on July 10th.

• Demixing the Tornado Cash transactions revealed matching deposits made the day before from another address.

   

2. Test Transactions:

• On July 8th, 2023, at 3:03 PM UTC, address 0xc68 was funded with 1 ETH from Tornado Cash. This ETH deposit matched another 1 ETH deposit made nine hours earlier.
• On July 9th, addresses 0xc687 and 0xc891 transferred funds to each other, which effectively broke the privacy benefits provided by Tornado Cash. These addresses conducted test transactions involving $SHIB tokens and interacted with multisig wallets. These preliminary transactions served as a testing phase, which made sure that the exploit would proceed smoothly without raising suspicions.

3. Tracing Funds:

• Further tracing revealed funding from an exchange to the attacker’s addresses, followed by a complex trail involving Bitcoin transactions.
• The Bitcoin deposits were traced back to unknown services, indicating sophisticated methods to obscure the trail.

WazirX emphasized their commitment to transparency and outlined the incident in detail:

1. Incident Overview:
   • A cyber attack on one of their multisig wallets resulted in a loss exceeding $230 million. The wallet was operated with Liminal's digital asset custody and wallet infrastructure.
2. Wallet Configuration and Breach Mechanics:
   • The wallet had six signatories—five from the WazirX team and one from Liminal. A transaction required three WazirX signatories and one Liminal signatory.
3. Nature of the Cyber Attack:
   • The attackers exploited a discrepancy between the data displayed on Liminal's interface and the actual transaction contents. They suspect the payload was replaced during the transaction verification process.
4. Security Measures and Response:
   • Despite robust security features, the attackers breached the system. WazirX is actively working to locate and recover the stolen funds.

Liminal clarified that their platform was not breached:

1. Preliminary Investigations:
   • Liminal stated that the compromised wallet was created outside the Liminal ecosystem.
2. Security Assurance:
   • All WazirX wallets created on the Liminal platform remain secure and protected.
3. Collaboration:
   • Liminal is assisting WazirX in their investigation and recovery efforts.

There are several indicators suggesting the potential involvement of the Lazarus Group in this attack, although conclusive evidence is yet to be found.

Transaction Traces

0.034 BTC from one of the transactions was traced to the Coincheck exchange, which has previously been used by the Lazarus Group to launder stolen funds.

Another 0.0198 BTC transaction was traced to a darknet OTC service, often frequented by organized cybercriminal groups like the Lazarus Group. This provides a strong hint towards their involvement.

Meticulous Planning and Execution

The attackers deployed the phishing contract on July 10th at 07:37:47 UTC, eight days before the final exploit, indicating careful planning and premeditation. This level of sophistication is characteristic of the Lazarus Group.

History of Similar Attacks

The Lazarus Group has a well-documented history of targeting cryptocurrency platforms and has been linked to multiple high-profile crypto heists. The tactics used in this attack, such as phishing for signatures and compromising multiple layers of security, are consistent with their modus operandi.

In light of the recent attack, there are several security measures that organizations can implement to mitigate risks associated with multisig wallets and smart contracts:

Key Management Best Practices

Implement robust key management practices, including the use of hardware wallets and multi-factor authentication (MFA). Key management should ensure that private keys are stored securely and accessed only by authorized personnel.

Comprehensive Security Audits

Conduct regular security audits using advanced tools to identify and address vulnerabilities in the smart contracts and wallet infrastructure. Audits from popular firms like QuillAudits should cover all aspects of the system, including the multisig wallet configurations and the underlying smart contracts.

Transaction Validation Procedures

Establish strict procedures for validating transactions before signing. Signers should be trained to verify transaction details independently, ensuring that the transaction data displayed on the interface matches the intended transaction.

Implementing Self-Custody for Users

Encourage and facilitate self-custody solutions for users. This empowers users to have direct control over their assets, reducing reliance on third-party custody services and enhancing overall security. Self-custody solutions, combined with user education on secure practices, can significantly mitigate the risk of centralized points of failure.