Web3 phishing: how to protect yourself and your assets

Spam and phishing are two perennial scourges of the internet at every stage of its evolution. Web3 is no exception. Vladimir Menaskop explains how to fend off phishing attacks on your crypto-assets for ForkLog readers: Vladimir Menaskop.

Three pillars: security, diversification, customisation

If that reads like a mere string of words, it is time to reflect: without these three steps, your crypto-world will never be in good order. Let us start with security.

I have covered it here and here, so I will emphasise only the points I did not write about earlier:

1. If you devote time to security only once a year, you are already potentially compromised. It does not matter whether that is your email ending up in a spam database or a password leaked from some site (say, an exchanger).
2. If you use only convenient but closed software, you are already potentially compromised. The OS community tends to work both faster and more collegially—and, crucially, continuously rather than sporadically.
3. If you have not tried working with complex extensions, wallets and other official dapps such as Bitcoin Core or Polkadot JS, you probably have not fully “felt” the process and are, potentially—yes—already compromised.

All three theses may sound like bedtime scare stories, but the following examples suggest otherwise.

Example No. 1. Our arch-enemy is not stairs, but advertising

One late evening I needed to exchange a small sum in ETH. Where would most of us go? So I went to BestChange. But I broke my own rule: “Type the address by hand, not via search”.

I typed it into Google (a fatal mistake, but errors tend to come in chains) and clicked the first link.

Predictably, it was phishing. The “company of good” filtered crypto projects from its search results—but only the honest ones. Phishing sites mimicking the largest aggregator slipped through. And the replica was excellently done: no bugs, no typos, even an SSL certificate. The difference—one letter. A classic, well staged and well drawn.

In the end I found the route I needed and followed a link to a site that, of course, was also fake. What is more, it looked exactly like the one I had used before. Then I made a third unforgivable mistake: I did not log in, because the amount seemed small and it was already late.

That was it. My ether settled permanently in the scammers’ pockets.

How could this have been avoided?

Here are a few simple rules:

1. Memorise and type manually the addresses of sites you use (DEX, wallets, aggregators), and add them to bookmarks: that gives you at least two sources for cross‑checking. Only then use search engines as a third, independent source; preferably not Google, Yandex or Baidu but something without ads or other spam. Several working options can be found here.
2. Wherever you can customise, do so: Gmail wallpapers, partner authorisation on BestChange, a personal account at an exchanger, and much else. Welcome messages and internal account names work especially well: even CEX now do this; in the decentralised world neglecting it is a sin.
3. And, of course, always verify wallet addresses (numbers): exchanges often index them.

Individually these points are weak; together they work. Phishing ads still show up on Facebook, so my example will remain relevant for a long time yet.

Example No. 2. Approvals: the bane of crypto

This case, unlike the previous one, did not happen to me—and quite recently. I will try to reconstruct the chronology.

Initially, a crypto-enthusiast (let us call him E.) had the seed from a Trezor hardware wallet, on which BTC was stored under a passphrase—an excellent setup in itself.

Then came a series of errors. I quote: “I imported this seed into a [mobile wallet]. Apparently to check how import works and to make sure that the presence of bitcoin is not visible in the mobile wallet. That is how it was; I made sure.”

Importing a seed phrase from a hardware wallet into a mobile one is a serious mistake: it defeats the very purpose of keeping keys on the device. I quote further:

“In autumn 2022 I switched from a PC to a Mac and installed MetaMask as a Chrome extension, because it is inconvenient to live without it. [But for a long time I did not] use it. Deciding to use this same seed for BEP-20 token operations, I topped up [the wallet] on 1 December 2022 with a small portion of BNB from someone and, apparently, started to connect somewhere via Wallet Connect (where and why, I do not remember).”

Here the difference is clear: the Wallet Connect library has been attacked more than once, including through phishing, and in fact the funds were no longer offline but online (after importing the seed phrase). That at least doubled the risk compared with standard storage on a Trezor.

We move on in the victim’s account: “In the process of connecting and [testing] I made an approval for the scammer to operate with BUSD (why, I do not remember), and since it was Wallet Connect and the interface there is not great, [plus] lagging, [I] did not understand this or did not attach importance to it. It is important that the approval was made by me in the [mobile wallet] via Wallet Connect. I clarified [this] with [the mobile wallet’s developers], the screenshot shows this exactly. That is, MetaMask has nothing to do with it.”

The key takeaway from this part is that everything in crypto changes constantly. When we do something unthinkingly, it is then hard to reconstruct the full picture and determine the level of security under control. The rest of the story proves it. I quote:

“[Later in the mobile wallet] Wallet Connect did not work, and I needed to make an SBT, so I moved to MetaMask and [started] doing operations in the BSC network from it, connecting to a dapps site… Everything was ok, and since the BUSD BEP-20 token was not involved here, there was nothing for the scammer, who had access, to steal; the approval was waiting for its hour.”

Exactly. An approval granted to a compromised address or smart contract can hang around almost indefinitely. So the first thing to do when reconstructing activity on an account (wallet) is to check approvals. Where and how? I will set it out below.

We continue with the story: “Last week information appeared that Binance would delist the original BUSD from Paxos by 15 December [2023], and on that occasion I decided to get rid of all centralised stablecoins. I swapped a large amount of USDT TRC-20 for bitcoin (successfully, it went up), BUSD BEP-20 remained on another wallet ($2640—the entire amount). Then a colleague in [the city] needed [fiat currency] to a [bank] card, so I [faffed with] MetaMask and left the matter for later, deciding that, perhaps, I would exchange part of the BUSD BEP-20 for roubles at an [exchanger] and send it to the person. In general, in my mind BUSD I decided to spend on current business, since one must fundamentally get rid of CEX stablecoins. The motive is ‘BUSD to go in full…’”

Thus the funds lay in the wallet for some time, and the account was not actively used. And here is how it ended:

“Today at night before going to sleep I think, should I swap in the [mobile wallet] BUSD for bitcoin so as not to shuttle it back and forth (I should have swapped). I refuse, I decide to transfer BUSD BEP-20 in full ($2640) to the seed in MetaMask to test [the exchanger]… and in general to get rid of it by spending. I perform the operation in the [mobile wallet] from one seed, make sure that to the second seed (which is in [the mobile wallet] and MetaMask) the tokens arrived in full, and fall asleep. And in the morning I see notifications in the mail from BscScan that the tokens were debited to a rogue address immediately after arrival by this transaction… I wrote to you, and you found out that an approval a year old was lying in wait for its hour. It got it.”

A sad story with a miserable outcome. But let us try to extract something positive.

1. A cold wallet and a hot one cannot live under a single MetaMask setup. Nor does it make sense to integrate a hardware wallet via a seed (except in emergency recovery). Integration between Trezor and MetaMask, however, is fine.

2. If you have not used a wallet for a long time, check approvals. Where? Via the links below (broadly, you can handle approvals via scanners or via specialised services; here is a consolidated list):

• Ethereum — etherscan.io/tokenapprovalchecker;
• Polygon — polygonscan.com/tokenapprovalchecker;
• BSC — bscscan.com/tokenapprovalchecker;
• Optimism — optimistic.etherscan.io/tokenapprovalchecker;
• Arbitrum — arbiscan.io/tokenapprovalchecker;
• approvals.xyz;
• cointool.app/approve;
• approved.zone;
• revoke.cash.

3. And, of course, do not rely only on yourself, but on a security system that is structured and verifiable (importantly: by anyone, not just once and by you). There are countless counter‑examples: here is one of the latest, and here is another one. Everyone gets hacked: if you have not yet been targeted by vector attacks, that is only because you are like the Uncatchable Joe—not yet on the list.

My zero rule of security therefore reads: “Any system can be hacked.” The questions are always price and time. If it is too long or too expensive, they will not bother (destructive attacks aside, which are another matter).

Example No. 3. Diversification works, but it requires habit

Suppose you are hunting bounties, airdrops and the like. What do you actually do? Test new services and systems. A little at first, then more, then several at once—until you become adept at working with all sorts of start-ups, from niche to sectoral.

But at that moment your base wallet becomes literally stuffed with approvals for contracts and permissions for services, and your browser—with bookmarks and other trappings of deep digital immersion.

At that point attacks will inevitably come:

1. Through fake accounts on X. Even if you withstand the “spot the ten differences” game, nobody is insured against an official account being hacked and phishing links being sent from it. That seems to happen even with the SEC or Vitalik Buterin.
2. Through email. The spam will be copious and well targeted, both via special services and standard mailing tools, and via subscriptions. Hence I keep a public Gmail address for everything, and private addresses for important services—especially since in Web3 there has long been no shortage of the necessary tools.
3. Through Telegram, Discord and other messengers. Living with this is hard. If you are active in the crypto community, you will have noticed spam races through groups lightning‑fast and in parallel.

I list all this so you draw one conclusion: anyone can be hacked. The antidote is diversification.

Say you received a retrodrop to a wallet, having first done all the above (checked approvals and so on). What next? Transfer everything to another wallet that either does not interact with the internet at all, or does so very rarely. That way you leave on a hot wallet only what you are prepared to lose—and no more.

Here are some other important tips:

1. Stay up to date. Read ForkLog and other outlets—say, via an aggregator. It may sound banal, but it lets you spot up to two‑thirds of attacks. How? Someone’s site or protocol is hacked, DNS is spoofed—and you already know and do not visit that resource today. When they restore it—by all means, but not today. The life of phishing sites is mercifully short.

• Xakep.ru—my regular weekend read for some 15 years;
• AuditDB, Dynamic and other specialist resources;
• closed forums such as Exploit.in.

3. Always validate any airdrops and the like via several resources. Recall the Galxe hack—if only to prevent a repeat. The standard set: a) the official site; b) social networks; c) the media.

Again, each item on its own is weak; together they give you an edge. To the above I add three empirical rules (read: laws):

1. If you can wait—wait. But not too long: not so long ago I managed to miss a retrodrop simply because I mixed up the dates.
2. If someone you know has been hacked—from an open community to friends, relatives and other close contacts—be on your guard.
3. If you think you know it all, remember the hack via a reverse approval in BSC and forget, once and for all, any sense that such knowledge is complete or universal.

Your keys—your money

Many believe that everything described above, and similar cases, proves that account abstraction and all manner of revocable (reversible) transactions will solve the problem.

I am convinced of the opposite. If you walk down a dark street at night, even in placid Switzerland, without any self‑defence skills, you risk running into a lone thug who will hit you over the head with “a heavy blunt object” and take your wallet, smartphone and wedding ring.

Digital hygiene must therefore become as necessary as brushing your teeth in the morning or washing your hands before eating. There is no other way, as breaches of every scale attest. One more example.

Example No. 4. KYA, or know what and whom you work with

This happened recently. A person was trading via a CEX and decided to withdraw funds. He copied an address and pasted it into the withdrawal field. He pressed confirm and went to have tea.

On returning he saw the funds had gone elsewhere. A standard clipboard‑substitution trick had fired. It comes in many guises:

• “poisoned” transactions and addresses, which now both wallets and scanners must fight;
• standard keyloggers, trojans and other malware, which abound on the dark net and, worst of all, can be wielded by script kiddies;
• wallet substitution: mobile, desktop or extension—no matter. Download the wrong binary—and that is that. Even downloading from the official site may not help—remember the Atomic Wallet case.

But you can fight this. Simple mechanics:

• update after reading the news, not before;
• if an update is not critical, wait a few days and watch the feed: it will not save you from zero‑day vulnerabilities, but it will from many lesser woes;
• try to study the documentation of the software you use: read the git, get to know the developers (in the OS world this is not so hard), browse forums and, above all, try to become at least an advanced user of the software;
• where possible—and it almost always is—verify hash sums, SSL certificates, PGN, and so on.

Never forget that in technology the weakest link is the human. Fatigue, working without breaks and without a strict financial schedule ultimately lead to losses, not extra profit. Bear it in mind.

Conclusion. The perfect armour against phishing

It does not exist. Why? Because “perfect” here means “individual”. Of course, some points should not be ignored, but otherwise imagination is your best ally.

Here is a checklist of basic self‑defence mechanisms.

1. Limit your working hours. 09:00 to 21:00 on weekdays is plenty to solve 99% of tasks. But personalise even this: for instance, handle assets above a certain amount only at weekends.
2. Customise everything you can: from email and messengers to wallets and DEX accounts. The more details known only to you, the harder it is to trip you up.
3. Do not shun notifications and additional safeguards. Separate cold and hot wallets, set alerts in scanners and special services (HAL.xyz, Cielo). In short, learn to build an IFTTT‑style setup for yourself.
4. Diversify assets into at least three buckets: core investments, working tools, stabilisation fund. And remember that diversification, like decentralisation, is a case of “the more, the merrier”.
5. Stay informed. Read the news before you move a large sum from a compromised service, not after. Remember that video and voice deepfakes already exist, and devise your own verification methods for OTC/P2P trades.
6. Do not forget we operate in an untrusted environment. Gmail spam filters are imperfect; wallets on CEX are not wallets; your ERC‑20 with an approval on any protocol is not really yours. If you are attacked, help others: report phishing to Google, Yandex and specialised resources such as AMLBot and Chainabuse.
7. Do not overlook new wallet features. A recent MetaMask feature, for example, saved me.
8. Raise the level at which you work with services. For example, phishing tokens in Ethereum are plenty, but in nine out of ten cases a scanner flags them promptly and accurately—let alone advanced tools.
9. The main rule of security: any system can be hacked. Work from that premise and the rest of the checklist falls into place.