This week, the web3 ecosystem witnessed one of the most brutal frontend attacks ever experienced. While most attacks are highly targeted on a specific frontend (i.e. BadgerDAO, Galxe.com, or balancer.fi), this time the exploit broadly impacted upwards of 100 frontends causing each dApp and their users to fall victim. This can be attributed to the nature of the attack: a supply chain attack.

With the attack 48 hours behind us, we’re now able to provide full visibility into the anatomy of the attack. Specifically, let’s go through a timeline, understand supply chain attacks, and dive deep into this specific attack perpetrated by the Angel Drainer Group. We’ll also show how Blockaid’s automatic detection and proactive protection ensured that each and every wallet that had Blockaid integrated was safe as soon as the malicious payload was deployed.

Timeline

Here are the key moments from the start of the attack to the patch/fix deployed:

• 2:37am PST, December 14th - a malicious payload was deployed by an attacker into the @ledgerhq/connect-kit versions 1.1.5, 1.1.6, 1.1.7
• 2:43am PST, December 14th, Blockaid frontend attack alerts were triggered through a dApp scan initiated on hey.xyz. All related transactions were instantly blocked as soon as the payload was deployed, and dApp connections were then blocked after this dApp scan at 2:43 am PT.
• 4:28am PST, December 14th - Blockaid publishes the first tweet in regard of the attack, only after disclosing to Ledger and receiving confirmation from their team.
• 5:18am PST, December 14th - A patched version, 1.1.8 was deployed by Ledger.

What’s a Supply Chain Attack?

Most of the time, when an attacker aims to target a specific application they will attempt to detect vulnerabilities, misconfigurations, or other types of weak spots directly within that specific application.

In contrast to these straight-forward attacks, a supply chain attack is more sophisticated. Instead of finding a vulnerability directly within the targeted application, the attacker will instead navigate through the various dependencies or components included in the application to identify a point of weakness, or vulnerability. For example,

If the attackers can successfully target a dependency of an application, it provides them with a free entry point into the actual application.

Anatomy of the attack

The attacker was able to inject a malicious wallet-draining payload into the @ledgerhq/connect-kit NPM package, affecting versions 1.1.5, 1.1.6, and 1.1.7.

Importantly, although the malicious code was injected into a Ledger package, the attack is not only targeted at Ledger wallet users. Instead, it affects every wallet that ultimately connects to each compromised dApp. The attacker exploited the ‘supply chain,’ the fact that the Ledger connect-kit package is a piece of code used across many applications in the ecosystem.

Once the packages with the malicious payload were deployed to NPM, every dApp using this dependency pulled the new version from NPM and served it to its users. Among the affected dApps were hey.xyz (attributed to the Lens protocol), sushi.com, zapper.xyz, and counltess other dApps using the package.

Blockaid Real-time Protection

Blockaid helps wallets and dApps protect users from scams, phishing, and hacks. Our engine can detect exploits like this in real-time at both the dApp and transaction levels. We process terabytes of data daily just to guard against events like this one.

By monitoring a vast amount of data in real-time, our engine identified malicious transactions originating from previously benign dApps. This immediately triggered a set of real-time scans on these dApps, resulting in them being flagged as malicious at the very onset of the attack - without any human involvement!

The scans triggered alerts for the Blockaid research team, who immediately investigated into the code and quickly comprehended the true scale of the attack. Automatic, real-time detection contributed to making Blockaid the first team to not only detect the attack but understand the implications of it.

Here are some public examples of wallets and applications that had Blockaid real-time protection enabled, ensuring their users were completely protected from the attack from the moment it began.

OpenSea, Metamask, Zerion, Rainbow

Real-time Protection VS. Reactive Manual Protection

It’s worth focusing on the significance of real-time protection in this context. Unlike human-made deny-lists that are difficult to maintain and may not capture events like this until widespread damage is done, real-time detection ensures the highest level of protection—an essential component that every user in the ecosystem should demand.

During the early hours of the attack, there was a lot of uncertainty about what was happening. Reports circulated highlighting certain frontends as compromised, which didn’t properly understand the sheer scale of the impact. Thanks to our real-time protection, we were able to communicate the incident as quickly as possible and convey the seriousness of this event.

For those relying on manual protection or weaker detection engines, they were only able to protect their users several hours into the attack, with the majority of the damage occurring in the initial hours. The way we see it, when it comes to security a minute late is too late.

The attack group responsible: Angel Drainer

At Blockaid, our models are based on deep knowledge regarding various attack groups that deploy drainers and their strategies. We have been tracking the Angel Drainer, the group behind this attack, for a very long time.

As early as October, Blockaid had discovered a consistent launching of new, malicious dApps that all lead back to the same onchain drainer infrastructure. You can see that the Angel Drainer group has been increasing the number of dApps it launches daily leading up to the attack:

Within minutes of the Ledger Connect Kit attack, Blockaid researchers were able to identify the attack emanated from the Angel Group based on known onchain addresses, as well as the SDKs and CNC interactions.

Onchain

The attack involved a number of addresses:

1. 0x000067464bdcbec51051ddcce8551e702f130000 - the main draining contract, referred to as main-drainer.
2. 0x658729879fca881d9526480b82ae00efc54b5c2d - an EOA used for collecting profits from the main-drainer and obtaining direct approvals/permits from the attacked users. Referred to as collector-wallet.
3. 0x00003ffA7857408ab714c28B1451914330240000 - an EOA used to execute operations on the main-drainer. It’s also the owner of the main-drainer contract. Referred to as operator-wallet.
4. 0x412f10AAd96fD78da6736387e2C84931Ac20313f - an EOA that holds the ENS angel-drainer.eth. Used to collect fees for the usage of the Angel Drainer infrastructure, referred to as fee-collector-wallet.

To understand how it works, consider the following example transaction. As seen, the operator-wallet address triggered a built-in multicall function inside the main-drainer.

One can observe that exactly 15% of the funds go to the fee-collector-wallet, and the remaining 85% go to the collector-wallet. This revenue-sharing structure repeats itself in this attack, as well as in many other draining activities in the wild.

The attack also introduced a new type of assault that creates dedicated contracts on demand. This type of attack will be covered further in a future blog.

Upon examining the bytecode of the main-drainer, one can see that it actually includes a multicall function accessible only to the contract owner (in our case, the operator-wallet). This is a technique employed by many drainer contracts to maintain a "backdoor" for running arbitrary code within the context of the main draining contract.

Blockaid has an automatic decompilation component capable of detecting these types of behaviors in real-time while analyzing a transaction.

Offchain

The attacker used a set of Command & Control (CNC) servers as the infrastructure for the operation.

As mentioned before, these CNCs were all previously used in other malicious drainers that the attacker deployed outside the scope of this attack. Visualized below, the attacker was using the same contracts to operate his draining infrastructure. The red dots indicate dApps while the blue dots connote onchain wallets and smart contract infrastructure.

This is a common attacker technique: using the same onchain infrastructure to support different drainers. This is why at Blockaid, we believe in deep behavioral analysis rather than the casual maintenance of deny-lists and bloom-filters.

‍

Conclusion

1. Supply Chain Attacks: Supply chain attacks, a well-known attack vector, have been employed across various industries in the past couple of years. Our community is not immune to them, and we must implement relevant web2 security measures to guard against such threats. A huge shoutout to the Ledger team for their responsiveness and the swift release of a patch to mitigate the attack at the NPM level.
2. dApps & Transaction Level Protection: Regardless of whether a user was targeted through a compromised frontend, phishing attack, social engineering, or another attack type, the final step to be scammed is a transaction. If wallets and applications can detect threats at the transaction level, it would protect user funds and would be a significant win for web3.
3. Real-time Protection: The attack underscored the importance of having real-time protection enabled. Wallets and applications that relied on mechanisms detecting and announcing the attack several hours into the event suffered significant losses. The majority of the damage occurred in the first few hours of the attack. Attackers are getting smarter and more sophisticated. Simple deny-lists or bloom-filters are too little, too late.
4. Blockaid: Our commitment to our customers is to be at the forefront of understanding and preventing these types of attacks at the wallet/transaction level and to empower builders with an understanding of the situation. We take pride in being the first team to detect this attack, and the fact that our engine successfully prevented it at both the dApp and transaction levels without human intervention. While all Blockaid-protected users remained unaffected by this attack, we believe that our growth will bring more trust and safety to web3, enabling the industry to realize its true potential.

If you're a wallet/application building on web3 and seeking real-time protection, don't hesitate to reach out. We won’t stop until we make it virtually impossible for attack groups to make millions of dollars draining web3 user wallets.