The Anatomy of a Spear Phishing Attack With OSINT Tips and an Almost Disappointing Ending

On 2021 September 5, I bought a new domain, zh4ck.eth. This domain is interesting because I used magic Internet money (a.k.a cryptocurrency) to pay for it, and, though the Brave browser can resolve the domain and show its contents, it cannot be resolved in most traditional browsers. If you are interested in the details of how this works, go to the Technical Details section at the end of the article.

Ethereum Name Service Domains

The number one reason why I bought the domain is because I love to play around with new technology. This type of domain is called the Ethereum Name Service (ENS) and it has some interesting properties. For me, the exciting part is that it cannot be blocked in the traditional sense (there are exceptions, but let’s not dive into that now). The other exciting part is that it cannot be stolen in traditional ways, such as social engineering where someone calls your name service provider, resets your password, and takes over the account.

But, and there is always a BUT, this domain is a Non Fungible Token (NFT). This means that you can still lose the domain in the same way you could lose an NFT. Forgotten wallet passwords or seed phrases / private keys, NFT phishing, and many other threats are lurking in the shadows of the ENS world.

Phishing E-mail Targeting the ENS Domain

In October, I got a spear phishing e-mail targeting my ENS domain, and it was pretty good. I did not fall for it, but I wouldn’t blame anyone who would. Here are the details.

First of all, the e-mail did not end up in my spam folder. Looking at the e-mail headers, this is expected. If you want to know more about spam filtering, I highly recommend this DEF CON presentation from byt3bl33d3r.

Clearly, the sender’s domain is a clear sign that this is a phishing e-mail. Otherwise, it is a perfect phishing e-mail. People trust e-mails where the context suggests an existing relationship with the sender. And the sender knew that I owned the domain. But how?

OSINT for Finding My Personal E-mail Address

I am not sure what they used, but there are multiple OSINT ways to figure this out. One way is to check my profile on https://app.ens.domains/zh4ck.eth and visit the connected GitHub page. From there, you could pick a random repository, and run:

git clone --no-checkout --bare --filter=blob:none <git-repo-URL> && cd <git-repo-dir> && git log

If you picked the right repository, you could see my private and work e-mail addresses. This has been a known issue for a long time and has been fixed for years. But you do have to fix your old repositories retroactively, and I was too lazy to do that.

Another way to find my personal e-mail was to Google my GitHub username on linktre.ee, find my LinkedIn profile and download the LinkedIn data breach details from 2014. Of course, there are other ways to find my LinkedIn profile page.

A third way to get my personal e-mail is to find my Twitter username from the ENS profile (shockingly, they are the same), download the Twitter data breach from 2023, and search for my personal e-mail.

Actually, once you have my personal e-mail address, you can see all the breaches where my e-mail was leaked at https://haveibeenpwned.com/.

Analyzing the Spear Phishing E-mail and Link Redirects

Now that you (and everyone else reading this) have my personal e-mail, let’s move on to more interesting stuff and analyze the content of the spear phishing e-mail.

The URL in the e-mail points to Sendgrid – this is expected for e-mails sent via Sendgrid. Sendgrid redirects me to bing.com. The attacker probably does this because Bing has a good web reputation score. What is bad here is that Bing allows an open-redirect, which allows the attacker to forward the user to another site. This is considered a security issue and can win you a bug bounty in quite a few places.

Bing redirects me to hxxp://archivodigital.org/venezuela-centro-de-computacion-afoco-2003. Interestingly, the main domain, archivodigital.org, redirects to the legitimate ENS URL, https://app.ens.domains. But the long URL redirects to the personalized hxxps://extend-ens.domains/?servicetype=renewal&id=1857469 URL. This long URL redirect from archivodigital.org changes from time to time. Previously it redirected to domains-ens.app.

This is a powerful technique from the attackers, as taking down the malicious website would not affect the campaign, since the original URL could always redirect to a new, working phishing domain.

The Phishing Website

Here are some screenshots of the phishing website.

As you can see, the site looks good, uses similar CSS to the original, and even uses domain names that are very similar to the original one. If you had used only a single browser to do all of your web3 activities, you might suspect something wasn’t right, since you would have already connected your wallet to the legitimate app.ens.domains domain, and here the site would be asking you to connect it again.

But I suspect many users are like me and use many different browsers and wallets, or might have even migrated to a new computer recently. So this will not prevent everyone from falling for this scam.

The Smart Contract

We have finally reached the part where I was like

I was expecting a smart contract function call to transfer the ENS domain’s NFT to the scammer’s wallet, and maybe pay some extra ETH to the scammers. But instead, I got:

Funnily enough, this page threw off my analysis for a while. I thought I was interacting with the famous 0x0000000000000000000000000000000000000000 wallet address. Which would be impossible, as there is no contract deployed at that address.

It turned out that the scammers were clever enough to generate a smart contract with a lot of leading and trailing zeroes. And now, revisiting the site and enabling experimental alerts from MetaMask, I had a better view of what was going on:

So, the smart contract I was dealing with was 0x0000Bdf9Df069B009F79f075B50e0d86B8880000. But what exactly was going on here? MetaMask did not really know.

Looking at the decompiled code of the smart contract, I was not really sure I understood what was going on either. But I bet I was not about to extend my domain.

Based on the blockchain transactions, I was sure that this smart contract call wanted to steal my ENS domain. A quick website check revealed that the site’s JavaScript was heavily obfuscated, and even had anti-debugging techniques deployed.

Also, a quick Twitter X search revealed that I was not the first to see this smart contract.

This is where I decided to stop investigating. I might revisit the obfuscated JS in the future.

Lessons Learned

1. Stay vigilant. Never rush when it comes to signing smart contract functions. Take your time. Look for red flags.
2. Always check the sender’s validity.
3. Always double-check that you are interacting with a legitimate website.
4. Always check the smart contract calls and understand what exactly you would be approving.
5. Enable experimental warnings in your wallet software.

The Technical Details

If you want to dig into more technical details about ENS, IPNS, and IPFS, keep reading! Otherwise, so long and thanks for all the phish!

ENS – the Ethereum Name System

The purpose of ENS is to provide something similar to DNS in the blockchain world. In practice, ENS is an NFT where the ENS record has a “content hash” entry, which is an IPNS resource. In order to understand IPNS, we first need to understand IPFS.

IPFS – the InterPlanetary File System

IPFS is a peer-to-peer network for storing and sharing data in a distributed file system. Unlike traditional web technologies, IPFS uses content-addressing to uniquely identify each file in a global namespace, connecting all computing devices with the same system of files for efficient, decentralized data storage and retrieval.

Content addressing is a way of finding and accessing data based on its content rather than its location. Imagine if every book in a library was found not by its shelf or row number but by a unique code generated from the text inside the book itself. No matter where the book is in the library, you can find it as long as you know this unique code. This code is akin to a fingerprint; it’s unique to the book’s content. So, in a content-addressed system like IPFS, data is retrieved by what it is, not where it is, making it a robust and efficient way to store and access information.

Now, this is where IPNS makes sense. If we put our URL to the content-address on a blockchain, the address will change once we change the content. But we don’t want to update anything on the blockchain.

IPNS – the InterPlanetary Name System

IPNS is like a permanent address label for changing content on the IPFS network. It provides a stable identifier that always points to the latest version of your content, even when the content itself changes and gets a new IPFS address. Think of it as a fixed phone number that always connects, even if you buy a new phone. In my case, zh4ck.eth resolves to:

ipns://k51qzi5uqu5dlodad1tur2ti64q55m1w8ipohvk0a52ebm4qlntay45hgdxqyb

The browser queries the IPFS network to resolve the IPNS hash to the current IPFS hash through an IPFS gateway or a local IPFS node.

As discussed already, this IPFS hash corresponds to a unique content identifier (CID) on the IPFS network, which is a decentralized storage system. In my case, it’s:

ipfs://Qmd2o3CwKNiXEscxmbvEA9J22tQTmKBWnxmhVT5dRQ92Hm/

Once the IPFS hash (CID) is resolved, the browser retrieves the content associated with that hash from the IPFS network. If you directly enter ipfs://Qmd2o3CwKNiXEscxmbvEA9J22tQTmKBWnxmhVT5dRQ92Hm/ into the IPFS compatible browser, it might redirect you to ipfs://bafybeig2jrcg5g3xhy4gruyolu2k3hfk2ceunsusv7745lnawpxssbecua/.

If this isn’t confusing enough, IPFS supports QmHash (hash starts with Qm, a.k.a CIDv0) and bafyHash (hash starts with bafy, a.k.a CIDv1). These hashes are practically the same thing if you are just getting started in the IPFS world, the same thing for the same URL.