Back to all stories
Incident Analysis
Wintermute Hack
Wintermute Hack


Wintermute has been hacked for ~$162.5m which appears to be due to a compromised (or brute forced) private key and not a smart contract vulnerability. At least ~$273,949,000 has been lost to private key compromises this year, making this one of the largest attack vectors this year. The exploiter used a privileged function with the private key leak to specify that the swap contract was the attacker controlled contract. However, Wintermute have announced that that over the counter trading and centralized exchange funds have not been affected.

Event Summary

The algorithmic market maker, Wintermute was hacked for $162.5m which is likely due to private key compromise, at time of writing possibly linked to the way Profanity generates vanity addresses, resulting in the leak of a private key. The leak is possibly due to a vulnerability disclosed by 1inch on 15th September. By utilizing the stolen private key, the hacker was able to redirect funds.

Private key compromises and hacks can result in devastating losses for protocols. This year we have seen notable examples of private key compromises including the attack today:

private key compromises in 2022

  1. Wintermute: $162m
  2. Harmony Protocol: $97M
  3. Slope exploit: $8m
  4. ZbExchange: $4.8m
  5. Gera Coin: $1.4m
  6. Marvin Inu: $350k
  7. Bill Murray’s personal wallet: $177k
  8. Citizen Finance: $94k
  9. Pirate X Pirate: $81K
  10. Impermax Finance: $47k

We can also include the $3.3m that was taken as a result of the Profanity wallet exploit which was reported on 15 September. This amounts to a total of at least $~$273m lost this year. This means that the hack on Wintermute is the largest exploit this year resulting from a leaked private key.

Profanity Brute Force Exploit

A ‘brute force’ is a method of breaking a password or encoded string of characters by trying every single combination until you find the one that matches. If you had 1,000 keys and 1 lock, you simply try every key until you find the one that fits.

Profanity is a vanity address generator for Ethereum that is used to generate millions of Ethereum wallet addresses per second. Vanity addresses are generated cryptographically by assigning a specific prefix or suffix to a program that then generates potentially millions of addresses until it finds one matching the specified conditions.

However, in January 2022 an issue was raised on GitHub with the way private keys were being generated. Profanity uses a random 32-bit seed number to generate a 256-bit private key. It has since been prove that by using 1,000 powerful graphics processing unit (GPU), all 7-symbol vanity addresses could be brute forced within a period of 50 days.

On 15 September 2022, 1Inch posted a Medium article on the Profanity vulnerability and detailed how they were able to generate private keys for users with a vanity addresses.

1 Inch Medium Article

Two days after the Medium article, Twitter user @ZachXBT posted analysis showing that Ethereum wallet 0x6AE had managed to gain $3.3 million worth of crypto by utilizing the exploit.

At the time of writing it appears Wintermute were brute forced which would be possible if they used Profanity or a similiar vulnerable way to generate wallet address 0x0000000fE6A514a32aBDCDfcc076C85243De899b.

Supply-Chain Issues

Supply chain attacks, have been on the rise in the Web3 space. As we’ve seen this year, the increasing amount of Web2 security issues impacting Web3 has grown, but Web3-native supply chain attacks exist as well as evidenced by the Wintermute hack today. Supply chain attacks are a common problem in the Web2 world (e.g. the SolarWinds attack), so much so that they have been called by some security companies the biggest cyber threats emerging in the coming years. They’ve even got their own Wikipedia-page. Supply chain attacks also got attention from the White House just a few days ago Enhancing the Security of the Software Supply Chain to Deliver a Secure Government Experience - The White House. As more independent and open-source tools are built for Web3, and use of both traditional and emerging Web3 libraries becomes the norm in building and supporting decentralized applications, contracts, and infrastructure, more companies will become victims of supply chain attacks unless proper 3rd party supply chain security testing becomes the norm.

If Web2 and traditional cybersecurity providers struggle to keep on top of these, we can expect a similar pattern in the Web3 world unless we are proactive early, and incorporate testing and checks for ALL parts of the project and SDLC. Organizations like the OpenSSF have large-scale projects looking to “improve the security posture of open source software (OSS) through direct engagement of software security experts and automated security testing” OpenSSF Announces The Alpha-Omega Project to Improve Software Supply Chain Security for 10,000 OSS Projects - Open Source Security Foundation that are supported by the current US administration. The Solana wallets hack earlier this year really hit home how third party software not properly tuned for Web3 security parameters can lead to large mishaps and this recent Wintermute incident can show how using an open source third party tool when setting up a project (if they used Profanity vanity address creator to generate addresses and private keys) can have major downstream effects. The Web3 world either needs to join forces with alliances like the OpenSSF or create their own. For decentralized applications, producing a software bill of materials (SBOM) that users can readily access and evaluate or including an SBOM in an audit will greatly assist in transparency and ability for users and security professionals to more accurately assess risk.

Attack Flow

Firstly, EOA 0x6AE09 creates a malicious contract on 20 September and transfers 2 ETH to 0x0000000fE6A514a32aBDCDfcc076C85243De899b in the below transaction:


This EOA is the address with the compromised key and has a history of interacting with 0x00000000AE347930bD1E7B0F35588b92280f9e75, which is the Wintermute exploited contract. We can see that all previous interactions between the compromised EOA and the Wintermute contract call the function “0x178979ae”. Below are a few examples:


We can therefore ascertain that this is a normal function, and highly likely a privileged one. However, after EOA 0x6AE09 transfers 2 ETH to 0x0000000fe6, we see further transactions with the 0x178979ae function:

4202f62c-27df-497a-8ec9-f733466471c9 (1)

However, if we take a look at each transaction we can see that the funds are redirected to the malicious contract created by 0x6AE09.


This function was completed 109 times. Once the attack was completed, 0x6AE09 receives the funds from the malicious contract in a series of transactions. Below are a few examples:


At the time of writing, the stolen assets are sitting in EOA 0x6AE09.


We had already seen a wallet generated by Profanity being exploited resulting in the losses of $3.3m on 15 September 2022. An attack on this scale shows how large organizations in Web3 need to take many steps in securing their assets. If Profanity as the root cause; since the Profanity exploit is now well known, anyone using a generated vanity wallet EOA from Profanity should take steps to move assets to a secure wallet to prevent similar exploits.

There are three ways to prevent attacks on private keys including: never importing keys from one wallet to another, using a hardware wallet, and using a software wallet that offers advanced security features. By taking these steps, individuals and institutions can mitigate attempts from malicious actors to compromise private keys. Web3 projects need to be extra vigilant around all aspects of their project’s supply chain, and development and setup environment.

Assets Lost

Below we can see the breakdown of funds.

wintermute exploit assets stolen-2 720

Screen Shot 2022-09-20 at 12.30.29 PM Screen Shot 2022-09-20 at 12.31.54 PM Screen Shot 2022-09-20 at 12.33.25 PM Screen Shot 2022-09-20 at 12.34.30 PM Screen Shot 2022-09-20 at 12.35.35 PM Screen Shot 2022-09-20 at 12.36.29 PM Screen Shot 2022-09-20 at 12.38.14 PM