I thought I was cryptosmart. I am familiar with multiple crypto protocols, multiple signature algorithms, smart contract caveats and many other crypto related topics. I wrote 2 cryptocurrency wallets and consulted a number of cryptocurrency companies on various topics like smart contracts based services, on-chain operation costs optimization, crypto services provisioning and crypto related security. I thought I was smart and I couldn’t be phished, right? Wrong.
Few days ago I was doing my standard procedure of topping up my cryptocurrency debit card from a non custodial wallet. I’ve done that dozens of times in the past and each time it worked out. I didn’t know that I was monitored and the mouse trap we set up for me for more than a month already. Eventually, I got caught into this trap. It took me a couple of days of conversation with debit card service customer support to realize that something is terribly wrong, then 5 minutes to realize my money was actually stolen and just 15 minutes to figure out how they did it. I should give that attacker credits on the scale and, perhaps, ingenuity of the attack. But this is also what scares me the most as looking at the results and how many people they managed to lure in. I also want to propose a number of means to prevent such attacks in the future and to make crypto a safer place. Because crypto space gives people financial freedom and anyone who is messing with it is my enemy.
Now, I have lost money and want my vengeance and the best way to get it is to spread awareness and suggest ways how to prevent such types of attacks. Any attack is meaningful while it is profitable and I hope my effort will contribute to decreasing its efficiency. In this article I will explain the structure of attack, approximate the setup and resources required to perform it and will give 5 ways that different crypto service providers can introduce to prevent users from luring into such traps ever again.
Anyways, without further ado here is how it was.
From the victim’s point if view
I was on my average routine topping up my debit card provider’s account with my non-custodial wallet, where I keep most of my funds. I made this multiple times and each time this went through without an issue. Though this time, unfortunately, it went different.
I copied the destination address from the history of my wallet, pasted it into the destination input, clicked the “Send” button and confirmed the transaction with my password. Then, I went to my debit’s card provider’s website and started monitoring my account. Nothing has happened within an hour and I thought there were some technical issues on the website.
Two days later, when I was checking my account again, I saw that my balance was still old. I contacted support, asking what was going on. We went into conversation and they requested the address where I sent my money to.
To my surprise they answered with a message that compared my account’s address in their system with the address I provided them and highlighted the part of the address in the middle that was different. This is where i started noticing that something is terribly wrong. I was seeing my money on that strange address I sent them to and was wondering where did strange address came from. Funds were intact until couple of days later they were transferred to some other strange address
https://etherscan.io/tokentxns?a=0xe7cf36d96e17a0c28786e1d6d472dae84632f07e&p=1
This is where I realized the funds were stolen and started my investigation.
How the attack actually works
We will do an investigation on the other successful case that brought the attacker a good 136000 DAI (poor guy who sent that). Here is a link to the transaction
https://etherscan.io/address/0x14baa59608bedb9997cb9ef51f2961628bb2123e#tokentxns
Here how the history of this attack looked like
I could only guess what happened here, but what I think is the following:
A person has sent money multiple times to a repeated account. Seemingly, that person had multiple wallets with different amounts of funds on each. For whatever reason they decided to switch an account and send a large amount of DAI to that repeated destination. Likely, their setup is a Metamask with multiple wallets in it. They switched to the wallet with a large amount of DAI and went to copy the destination address from the history. Perhaps, they went to the Ethrescan (some other Ethreum explorer) to check the history and to copy the destination address from there. Once on the explore page, they checked the last transaction from the history, confirmed the first and the last characters of the destination, copied that address and went to Metamask to make a transaction. They didn’t know they copied a phishing address and they were sending money to the attacker address.
This attack is built on the fact that Ethereum addresses are long and hard for human reading and a big majority of wallets and explorers are trimming addresses in the middle. Attacker assumes that the victim will validate only the beginning and the end of the destination and this will be enough to copy it and paste it into the sending form. Now, all the attacker needs to do is to fake the history of an account. Well, as it turned out it is not an impossible thing to do. The attacker does that within a ~1 minute frame.
Once the wallet gets on the monitoring list and their frequent destination is defined, the attacker starts producing fake history events that appear in the explorer or in a victim’s wallet. Now the trap is set and it is a matter of the habits of a victim to fall into this trap. To get a better understanding of how a phishing address is compared to the original one check are the original address compared against the phishing one
0x8A383E15c720BC0C65AEdB6342a44E60c05E3A1D – Original
0x8A383E1A6758E0e94bC83910FF8C7A55C85e3A1D – Fake
Here is a screenshot highlighting the attack on some other address that I found. It clearly shows that despite the effort, Etherescan still missing some phishing tokens and addresses, despite some of them are there for more than a month.
Let’s now check what are the requirements to perform such an attack.
Scale of the attack and required resources
This is where I should definitely give the attacker credits. They are continuously monitoring Ethereum addresses above ~5k$ worth, analyzing their behavior patterns and mimicking most other destinations. This is not a trivial thing that you could do in a garage. You need scale!
In my particular case the attacker managed to find an address that matches 14 out of 40 hex characters of my destination address. Each hex character can be a number, from 0-9, or any letter from a to f. Total of 16 possible values. Now to estimate the amount of guesses needed to calculate 14 hex characters we need to power 16 by 14, which is 72057594037927936 attempts on average. This is not a super large number in terms of cryptography standards, however this is still a significant one.
Let’s say we have the best modern PC that can make 1 000 000 random guesses in a second, that still will require 72057594037 seconds (or 833999 days!) to find such an address. But keep in mind that the attacker makes this at scale. They generate such addresses for almost all active Ethereum wallets containing significantly low amounts of funds and showing patterns of manual behavior.
One way to speed things up is to use an ASIC (Application-specific integrated circuit). Literally, a microchip that is tailored and optimized to do very specific calculations. You may have heard this term before in association with mining farms and usually this means a large mining facility with engineers around it. Such a setup requires to design such a microchip, manufacture it and to operate and maintain such a facility. I can’t estimate here the costs to design and manufacture such a microchip or operational costs of such a facility, but I can tell for sure this is the work of very educated engineers and this never comes cheap. We speak of hundreds of thousands of dollars.
Another part of the attack, after the attacker manages to find a ”similar” address, they need to continuously feed fake Web3 events into the chain, each time a victim’s address sends a transaction to the authentic destination address. This we can easily calculate, since all the data is on-chain. Let’s see what we will get.
We will estimate the operation cost for the Ethereum network as this is the most expensive network to operate on currently where the attacker operates. Each minute an attacker broadcasts a transaction that creates a couple of Ethereum events. This usually costs between 4$ to 8$ per transaction. A day of operation costs ~8500$ at the current network conditions and price of Ether. A week of operation costs ~60000$. Additionally it requires a deployment of a smart contract for each 4 targeted tokens that I found. This is another ~30$ per contract, which lives for, lets say, around 2 weeks before it will be reported and marked on Etherscan. This brings additional costs of ~60$ per week, which is pretty much negligible compared to other expenses.
To be honest, despite the seemingly naive expectation that users will not be able to distinguish a fake address from the authentic one, many are actually falling victim to this setup. Here is one of the accounts that is accommodating stolen funds. It is clearly seen that the attacker has quite some success there.
Here is an example of such history faking transaction that attacker produces each minute:
And here are at least 3 addresses that were broadcasting transactions with fake history events:
I am not approximating here the cost to write and operate an analytical tool, that would be monitoring ALL Ethereum addresses, analyzing their behavior patterns and figuring out possible destination targets, but I guess you already got the picture. This is a very sophisticated, well established, resourceful and very costly setup, at least. This is not something one can do in their garage or an apartment. We speak of a well equipped and resourceful organisation that is flooding Ethereum with fake history.
How can users get protected
So, what do we know about this attack already? Well:
- Attacker monitors the entire blockchain network for addresses with solid balances that show signs of a manual behavior, irregular transactions to a repeated address (probably manually triggered)
- Attacker assumes user will compare only the beginning and the end of the addresses strings
- Attacker consumes significant computing power to generate a “similar” destination address
- Attacker requires a deployment of fake ERC20 token smart contract
- Attacker requires a task mirroring all token transactions within a frame of a minute
To make this attack ineffective it only requires to decrease profitability to the level where its operating cost prevails. So, all we need is to find something that will drastically increase the cost of scammer’s operation or decrease the chances of success.
Here are 5 ways that I came up with that could help to make this attack profitable.
A wallet application provider can introduce a destination book
Though this does not solve the situation at scale, it might change habits of some users, preventing them from sending money to phishing destinations. Surely, there are threats that this solution imposes, hence this can not be considered as the best option.
A 3rd party service that scouts for phishing ERC20 tokens
One obvious thing could be to create a list of fake tokens that the scammer is using. But this will require a complex monitoring setup of scammers activity and quite some labour of adding these tokens to some sort of a black list. On the other hand how would the end user be aware that there is a new entry in such a back list? A wallet provider should introduce a monitoring routine of such a back list. This will require the whole community to continuously perform significant effort to ban scammers’ smart contracts. This uses a lot of time and money. On the other hand all that scammer will need to do is to create a new token smart contract and switch to it. That will cost him 30$ at today’s network conditions. It will increase attackers’ operation costs by 0.5%. Doesn’t look like a remedy.
Besides that there is such a list and from my humble opinion this is less than efficient. It is, obviously, an Ethrescan. It definitely does “something”, but the question is – whether this is efficient? Let’s see. Here is another screenshot showing that some tokens are not marked as phishing for more than a month despite showing clear signs of being a phishing token.
A 3rd party service that provides “clean” history records
Alright, token blacklist is not the best option, but what else could we do? We know that there should be a “duplicating” transaction within a frame of a couple of minutes to a “similar” address. So, if there is such a transaction then chances are that the wallet is already under surveillance. Honestly, as a cryptocurrency user when I saw these transactions in Ethescan I associated them with some internal operations of my debit card service provider. There are legit schemes of wrapping tokens and I thought that this is exactly that case.
So, can we call every duplicating transaction with a similar, but deviating address as a scamming transaction? Perhaps. But how would users learn it? Such things require active monitoring and analytics. It is not a trivial task. Something like that could be provided by services like Etherscan or Moralis, but not every wallet application relies on their solution and what about users of other blockchains? Again, the user initiates their transactions from a wallet application, chances are that wallet provider just puts the history directly to the user’s application and that is it. What about the operational cost of such a solution and the amount of effort for the scammer to get away from its surveillance?
Well, that will require monitoring the entire blockchain network, take every transaction, see if there is a following log event with a “similar” destination address and token and then mark that token as suspicious. Such setup should be scaled and duplicated across multiple networks. Each wallet developer will be entitled to integrate with such a service to show its users their “clean” history. Meanwhile the scammer can tinker with their operation parameters and perhaps find a way around it.
This setup fits best wallet applications, however it is not the best option either, as this will expose some user private information to such service providers, who will be able to associate the user’s wallet(s) with their IP addresses. Definitely does not contribute to user’s privacy.
A 3rd party service that oracles if a wallet is are under phishing attack
Though this sounds similar to the previous options it is different. As long as the user is warned that his address is monitored by a phishing organisation, they might get more cautious while operating on a chain. This will definitely contribute to decreasing attack success factor, however this still requires a similar setup described above.
This option suits best centralized service providers like my debit card provider. If I would be shown a warning message that warns me that somebody is trying to lure me into the phishing trap, there would be much less chances for me becoming a victim. In my particular case, I assumed there is a “complex setup” that does internal accounting for whatever reasons.
Human friendly visualization of an address or address hash.
So, is there any solution that could be simply implemented across multiple blockchains, will not require a complex setup, will be cheap or free to operate, but more importantly will drastically decrease scammers success rate or will increase operating costs? Well there is such a thing.
There were multiple attempts to visualize the address in the past, but no one has standardized this practice yet. Perhaps it is the time. How could this work? It is simple: we take the hash of the address, instead of the address itself, pass it to some visualization algorithm and present the image to the user. Users will now have 3 reference points to ensure authenticity of the direction: the beginning and the end of the address and its image. It will be drastically harder for the scammer to fake all three things, since even a slight change to the single address character will generate a completely different hash, resulting in a completely different image.
Surely, the attacker could keep finding similar addresses that would produce similar visualizations, but then this is not a simple task as the human eye is quite a sharp and advanced tool. This will likely require them to compare the images case by case to increase the success of the attack. They could rely on available AI solutions, but still, the final human approval will be required to ensure similarity to increase the success rate.
Another good point is this will help users to ensure that they are sending funds to the correct destination. Have you ever gaze at the destination address for a minute or more before clicking the “Send” button? How many times have you done that? Well, it is much easier to compare two images than two 40 character strings, where 1 single character might be different. So, not only such practice will protect users from fake history attacks, but will also decrease the amount of lost funds due to a typo in the address. Has anybody counted how much money is lost yearly due to that?
This practice does not come for free. It will still require wallet developers to introduce changes to their wallets, but such integration could be provided in the form of a simple code library that returns a SVG or PNG file of a given size. And let’s be honest – developers love to code cool things, especially implementing something that is considered as a “best practice”, is super easy to implement and maintain and will show that they care for their users. Literally, a fun thing to do.
Here is an example of how we would visualize an original and fake Ethereum addresses, provided in section “How the attack actually works” with the Avataars lib in our products: WH Cypher, non-custodial multisig wallet, and WhalesHeaven, non-custodial cross chain OTC. You can immediately notice the difference, despite the addresses looks identical at the first glance.
For those who is interested, here is the JavaScript that generates an SVG file:
import crypto from 'crypto'
import Avataaars from './avataaars';
const elements = {
skin: ['tanned', 'yellow', 'pale', 'light', 'brown', 'darkBrown', 'black'],
top: ['dreads01', 'dreads02', 'frizzle', 'shaggyMullet', 'shaggy', 'shortCurly', 'shortFlat', 'shortRound', 'sides', 'shortWaved', 'theCaesarAndSidePart', 'theCaesar', 'bigHair', 'bob', 'bun', 'curly', 'curvy', 'dreads', 'frida', 'froAndBand', 'fro', 'longButNotTooLong', 'miaWallace', 'shavedSides', 'straightAndStrand', 'straight01', 'straight02', 'eyepatch', 'turban', 'hijab', 'hat', 'winterHat01', 'winterHat02', 'winterHat03', 'winterHat04'],
hairColor: ['auburn', 'black', 'blonde', 'blondeGolden', 'brown', 'brownDark', 'pastelPink', 'platinum', 'red', 'silverGray'],
hatColor: ['black', 'blue01', 'blue02', 'blue03', 'gray01', 'gray02', 'heather', 'pastelBlue', 'pastelGreen', 'pastelOrange', 'pastelRed', 'pastelYellow', 'pink', 'red', 'white'],
accessories: ['none', 'kurt', 'prescription01', 'prescription02', 'round', 'sunglasses', 'wayfarers'],
accessoriesColor: ['black', 'blue01', 'blue02', 'blue03', 'gray01', 'gray02', 'heather', 'pastelBlue', 'pastelGreen', 'pastelOrange', 'pastelRed', 'pastelYellow', 'pink', 'red', 'white'],
facialHair: ['none', 'beardLight', 'beardMagestic', 'beardMedium', 'moustaceFancy', 'moustacheMagnum'],
facialHairColor: ['auburn', 'black', 'blonde', 'blondeGolden', 'brown', 'brownDark', 'pastelPink', 'platinum', 'red', 'silverGray'],
clothing: ['shirtCrewNeck', 'blazerAndShirt', 'blazerAndSweater', 'collarAndSweater', 'graphicShirt', 'hoodie', 'overall', 'shirtCrewNeck', 'shirtScoopNeck', 'shirtVNeck'],
clothingGraphic: ['skrullOutline', 'skrull', 'resist', 'pizza', 'hola', 'diamond', 'deer', 'dumbia', 'bear', 'bat'],
clothingColor: ['black', 'blue01', 'blue02', 'blue03', 'gray01', 'gray02', 'heather', 'pastelBlue', 'pastelGreen', 'pastelOrange', 'pastelRed', 'pastelYellow', 'pink', 'red', 'white'],
eyes: ['squint', 'closed', 'cry', 'default', 'eyeRoll', 'happy', 'hearts', 'side', 'surprised', 'wink', 'winkWacky', 'xDizzy'],
eyebrows: ['angryNatural', 'defaultNatural', 'flatNatural', 'frownNatural', 'raisedExcitedNatural', 'sadConcernedNatural', 'unibrowNatural', 'upDownNatural', 'raisedExcited', 'angry', 'default', 'sadConcerned', 'upDown'],
mouth: ['concerned', 'default', 'disbelief', 'eating', 'grimace', 'sad', 'screamOpen', 'serious', 'smile', 'tongue', 'twinkle', 'vomit'],
};
const createConfig = (pubKey) => {
const count = Object.keys(elements).length;
const hexdigest = crypto.createHash('sha512').update(pubKey).digest('hex');
const hasharray = [];
for (let i = 0; i < count; i += 1) {
const blocksize = Math.floor(hexdigest.length / count);
const currentstart = i * blocksize;
const currentend = (i + 1) * blocksize;
hasharray.push(parseInt(hexdigest.substring(currentstart, currentend), 16));
}
if (pubKey) {
let i = 0;
let elOpts;
let elI;
const svgConfig = Object.keys(elements).sort().reduce(
(obj, key) => {
elOpts = elements[key];
elI = hasharray[i] % elOpts.length;
obj[key] = elOpts[elI];
i += 1;
return obj;
},
{},
);
return svgConfig;
}
return null;
};
export const createAvatarSvg = (pubKey) => {
const svgConfig = createConfig(pubKey);
return Avataaars.create(svgConfig);
};
What’s next?
Well, what is needed for such an initiative to go live? A standard (BIP, EIP it similar), and community support originating from blockchain foundations and wallet providers.
So far I spoke to developers of 2 sound wallets and got their confirmation that such initiative is needed. What’s interesting is that they haven’t heard or encountered such an attack in the past.
I’ll be speaking on NFT Tallinn about digital identity and will definitely bring this topic there to hear some though. I would appreciate it if somebody could help out with preparing EIP for this initiative and could connect with Etherscan and Ethereum foundation to hear their thoughts and feedback.
PS. Thanks for making it till the end! I would highly appreciate if you can help us to improve our products: @WhalesHeaven Non-Custodial OTC and WH Cypher Non-Custodial Cross-Chain MultiSig Wallet. I’m happy to invite you, to participate in our paid beta tester survey: https://forms.gle/YwPfySZcaXfoioDc8