IDN Homograph Attacks: Fake Sites You Can't Tell Apart by Eye
Look at the two addresses above. Can you spot the difference?
If you said “they’re the same”, you failed the test. One is the real site, the other is an attacker’s trap… And the scary part is that it is almost impossible to tell them apart with your eyes.
In this post we will look at an attack that fooled a lot of people in its day — even users of the tech giant Apple: the IDN Homograph Attack
First we will build up how it works, then we will set up a homograph trap running in our own isolated lab environment and show, step by step, how a user’s credentials get stolen.
⚠️ Everything in this post was carried out in an isolated virtual lab environment cut off from the internet, for educational purposes only. The spoofed “shopeko” brand is an entirely fictional company. Using these techniques against real people or systems is a crime.
The Internet Really Only Speaks “ASCII”
Have you ever noticed that none of the addresses on the internet actually belong to a particular language?
Think about it: the Japanese, Russian and Arabic alphabets are completely different from ours. Yet wherever we are in the world, we can all use the same sites with the same addresses. A Japanese user types google.com, so does a Russian user, and so do we. So how is that possible?
Because when the domain name system (DNS) was first designed, it only understood a single common “language”: ASCII. That is, the letters a-z, the digits 0-9 and the hyphen (-). Thanks to this shared conversion the internet could work globally; everyone used the same limited character set.
But this common ground came at a price: we could register erenonder.com, but not erenönder.com or 日本.jp. Never mind the billions of people who use Chinese, Arabic or Russian — even our Turkish letters ö, ü, ş, ğ, ç, ı did not fit into this system. People needed to be able to register domain names in their own languages.
What Is IDN?
That need gave birth to IDN (Internationalized Domain Names): the standard that allows Unicode characters — in other words, almost every language in the world — to be used in domain names. Now a Japanese user could register a domain in their own script, a Russian user in Cyrillic letters, and we could use Turkish characters.
Thanks to IDN, the internet truly became global. The address bar was no longer stuck with the Latin alphabet. But this flexibility brought a new danger with it.
Punycode: The Bridge to ASCII
So was it possible to rewrite the entire DNS infrastructure from scratch? It wasn’t. Instead, a clever solution was found: an encoding that converts a domain name containing Unicode characters into an equivalent made up entirely of ASCII behind the scenes. This is called Punycode.
The idea is this: the user sees the nice, readable form of the domain name, while DNS resolves its ASCII-converted form behind the scenes. This conversion always starts with the xn-- prefix.
A few examples:
- münih.de → xn--mnih-kva.de
- 日本.jp → xn--wgv71a.jp
So when you type münih.de into your browser, the browser converts it to xn--mnih-kva.de in the background and asks DNS for that. This is a completely legitimate mechanism that runs millions of times every day. The problem is that it can be abused.
The Real Danger: Visual Twins (Homoglyphs)
Now we come to the dangerous part.
Unicode contains characters that come from different alphabets but look exactly the same on screen. These are called homoglyphs. The best-known examples are some letters of the Cyrillic alphabet:
+ - - - - - - - - + - - - - - - - - - + - - - - - - - - - + | Looks like | Latin (real) | Cyrillic (fake) | + - - - - - - - - + - - - - - - - - - + - - - - - - - - - + | a | U+0061 a | U+0430 а | | e | U+0065 e | U+0435 е | | o | U+006F o | U+043E о | | p | U+0070 p | U+0440 р | | c | U+0063 c | U+0441 с | + - - - - - - - - + - - - - - - - - - + - - - - - - - - - +
The right and left columns of this table look identical on screen. But to a computer they are completely different characters; they have different Unicode values and different bytes.
This is exactly where the attack comes in. Let’s say you want to impersonate apple.com. All you have to do is replace the Latin a in it with its visual twin, the Cyrillic а (U+0430). The eye still sees “apple.com”. But this is now a completely different domain name. When converted to Punycode:
- Real: apple.com
- Fake: аpple.com → xn--pple-43d.com
The two go to completely different servers. The victim thinks “I’m on apple.com”, but they are actually on the attacker’s server.
So Why Can’t Browsers Block This?
They actually do, but only partly — and this is the most interesting part.
Modern browsers have a defence: mixed-script detection. If more than one alphabet is mixed within a domain name label (for example, if the word аpple has one Cyrillic and four Latin letters), the browser gets suspicious and shows the address not in its nice Unicode form but in its raw xn--pple-43d.com form. That way the user can see the odd xn-- prefix and think “something is wrong here”.
But this defence has a gap: if the attacker writes all the letters of the word in a single alphabet, the mixed-script check never kicks in. That is exactly what Xudong Zheng did in 2017. He wrote the address аррӏе.com entirely in Cyrillic characters (xn--80ak6aa92e.com), without mixing in a single Latin letter, and the Chrome, Firefox and Opera browsers of the time showed a flawless apple.com in the address bar.
Keep this detail in mind; in a moment we will look closely at the wall of this defence.
Let’s Run the Attack from Start to Finish
Now that the theory is in place, we can move on to the fun part. In this section we will follow, step by step, how a homograph attack plays out through the victim’s eyes.
Here is our scenario: we are a user of shopeko.com, a fictional e-commerce site. As we will see shortly, clicking a single email will be enough for us to lose our account.
⚠️ All the steps here were staged in an isolated virtual environment cut off from the internet, for educational purposes only. “shopeko” is a fictional brand.
It All Starts with an Email
In our inbox there is an email we believe came from shopeko. The subject is eye-catching: someone tried to sign in to our account from an unrecognised device. It says “Verify your identity for your security”, and there is a button below it.
What do we see when we hover over the button or the link? shopeko.com. Exactly the address we expect. In a panic, we click to protect our account.
This is the sneakiest part of the attack. The link in the email shows us shopeko.com, but that is not where it takes us when we click — it takes us to the homograph address hidden behind it.
Is What We See Really What It Is?
So where exactly does this link take us? The address in the email looks like shopeko.com, but the innocent-looking e in it is not actually Latin; it is the Cyrillic е (U+0435). The eye cannot catch this difference, but to the machine it is a completely different address. When it is converted to Punycode in the background, this is what comes out:
This is the whole secret of the attack. Our eyes see shopeko.com, but the machine sees a completely different address: xn--shopko-6of.com. That single Cyrillic letter has turned into a whole -6of suffix in Punycode. So the moment we click, while we think “I’m going to shopeko.com”, we are actually going to the attacker’s server.
Falling Into the Trap
The page we land on after clicking the link is an exact copy of the real shopeko sign-in screen: the same logo, the same colours, the same “Sign in to your account” form. To the eye, the two pages are identical.
The only difference is in the address bar and, as we will see shortly, even that difference is not always obvious.
In the rush of “my account is in danger”, we enter our username and password without a second thought. The moment we press “Sign In”, two things happen: the credentials we entered reach the attacker, and we are instantly redirected to the real shopeko site.
This redirect is no accident; it is a subtle part of the attack. Landing on the real site, we think “I must have typed my password wrong” and try again, this time we sign in successfully and assume nothing went wrong. But our password has already been stolen.
Behind the Curtain: What Does the Attacker See?
While we are going through all of this, the credentials we entered show up on the attacker’s screen within seconds:
The password we hid as “●●●●●●●●” on the site sits in plain text in the attacker’s hands. On top of that, we are still browsing the real shopeko. No warning, no error message. The most frightening thing about the attack is exactly this: it goes unnoticed.
But Does This Really Happen?
Maybe you are thinking “these are lab scenarios, who would bother in real life?” In fact, this is one of the most widely used techniques in the field.
Real attackers actually buy homograph or look-alike domain names of the brands they target; often they register hundreds of variations in bulk for a single target, and hide who owns them. In the MITRE ATT&CK framework this technique is classified as T1583.001 (Acquire Infrastructure: Domains) and it is a method actively used by well-known threat groups such as APT38 and FIN7.
So what we staged here is not a brain teaser. It is an exact replica of an attack that happens every day all over the world.
So Would the Victim Really Fall for It?
We need to be honest here, because this may be the most instructive part of the post.
When we opened the fake address in the lab, up-to-date browsers (Firefox and Chrome in our test) showed the address not as shopeko.com but in its raw form, xn--shopko-6of.com:
This is actually good news: it means browsers have developed a defence against this attack. If you remember, we mentioned it in the theory section — modern browsers perform mixed-script detection. Because our word shopeko mixes five Latin letters with one Cyrillic letter (е), the browser found it suspicious and exposed the address in its Punycode form.
So a careful user can spot the trap from that odd xn-- prefix in the address bar.
But that does not mean the attack is over. Remember the 2017 Apple example: Xudong Zheng bypassed this defence by picking all the letters of the word from a single alphabet (Cyrillic). So if the attacker targets a brand whose letters all have Cyrillic twins, the victim can still see a flawless shopeko.com in the address bar.
The lesson here is important: browser defences are real and valuable, but they are not perfect.
How Do We Protect Ourselves?
There is no single magic fix against the IDN homograph attack; protection comes from a handful of habits combined.
1. Read the address bar carefully. Take one more look at the address, especially before entering login or payment details. If you see an address starting with xn--, the site deserves a second look.
2. Don’t trust links blindly. Before clicking a link in an email or message, hover over it; the browser or client shows at the bottom where the link really goes. Even if the visible text says shopeko.com, the address it goes to can be something else entirely.
3. Type important sites yourself or use bookmarks. Go to your bank or your e-commerce account by typing the address yourself or from a saved bookmark, not through a link in an email.
4. Don’t be fooled by the padlock (HTTPS). The padlock only tells you the connection is encrypted, not that the site is genuine. Attackers can get certificates for their fake sites too.
5. Keep your browser up to date. Homograph defences arrive with browser updates. An up-to-date browser protects you far better than an old one.
What About the Defending Side?
So far we have looked at the attack and at how to protect ourselves as individual users. But how does a SOC team catch this attack inside an organisation?
That is exactly my favourite part of the job, and the subject of a separate post. Hunting Punycode (xn--) in DNS logs, detection logic that checks whether these domains resemble well-known brands, and where all of this sits in the Pyramid of Pain… I will cover these in the next post, from the defender’s point of view.
Conclusion
IDN homograph is an attack built on a simple idea but surprisingly effective: fooling the eye. A legitimate technology (IDN), developed so that the internet could be multilingual, can turn into a tool of deception in the wrong hands.
The good news is that modern browsers have built serious defences against this attack; the bad news is that those defences have limits, and attackers can still push them. That is why the strongest defence is not blind trust in technology, but an aware eye and a few simple habits.