Homograph attack
A homograph attack uses characters from different alphabets that look identical on screen, so that a fake domain, sender or filename passes for the real one. It is the delivery vehicle for a phishing campaign rather than a family of malware: what it fools is the eye, not the code.
How it works
A homograph attack exploits something typography cannot fix: two different character strings can look exactly the same on screen. The attacker registers a domain, stands up an email address or names a file using letters the eye reads as the originals, and the victim interacts with a fake resource believing it is the genuine one.
The raw material is Unicode. The Latin alphabet does not own the only letter shaped like an “a”: Cyrillic has its own and Greek has its own, and to a screen they are the same stroke. When internationalised domain names opened URLs to those alphabets, they also opened the door to writing “example.com” with a letter that is not the one it appears to be.
Browsers do not carry those names as they stand: they encode them into a restricted alphabet using Punycode, which is why the same technique is also called a Punycode attack. A domain holding one Cyrillic letter travels as a string beginning with “xn--“. That representation is what gives the trick away, and it is also the one almost nobody looks at.
The rest of the attack is unremarkable: it is phishing. The lookalike domain is only the carrier. The objective is still that somebody types their credentials, authorises a payment or opens an attachment.
Where it shows up, besides the address bar
The case everyone pictures is the domain of a fake website, but a homoglyph works anywhere a person reads a string and makes a decision from it.
In an email sender. A homograph domain in the From field turns an ordinary message into one that appears to come from inside the organisation, and it is the natural route into business email compromise and into spear phishing.
In filenames. The same principle lets an executable read as a document, and the best known variant uses writing-direction control characters to reverse the visible part of the extension.
In usernames, organisation names and package names. Any platform that lets you pick a visible identifier without normalising the characters allows a known account to be impersonated, and there the victim is not even looking at a URL.
A worked example
An attacker wants the mailbox credentials of staff at a company that uses the domain “example.com”.
They register a domain that looks the same, with the Latin “a” replaced by the Cyrillic “a”. The two characters share a stroke and carry different Unicode code points, so to the system they are different domains and to the reader they are the same one.
They send an email that appears to come from the legitimate service, carrying a link to the fake domain. The landing page is a copy of the real sign-in form.
The employee notices no difference, types a username and password, and the attacker walks away with valid credentials. What happens next is no longer a homograph attack: it is access with legitimate credentials, which is precisely the thing that is hard to detect.
Homograph, typosquatting and brand abuse
All three produce a domain that resembles yours and all three are defended differently, so it is worth not calling them the same thing.
| Homograph attack | Typosquatting | Brand abuse in the subdomain | |
|---|---|---|---|
| What it relies on | Characters from another alphabet with the same stroke | A plausible typing mistake | The brand placed where it has no authority |
| What the attacker registers | The same name with one letter from another alphabet | A letter swapped, doubled or dropped | A third-party domain that starts with your brand |
| What the victim sees | The correct domain | An almost correct domain | Their brand at the start of the string |
| What detects it | Comparing the Punycode form | Comparing against the list of variants | Reading the registrable domain, not the prefix |
| What limits it | Normalisation, email authentication and a second factor | Defensive registration and monitoring of new registrations | Training and out-of-band verification |
The practical difference is whether the set of bad domains can be enumerated. Typosquatting has a finite set and a list covers it. Homographs do not: the combinations of alphabets that produce the same shape are too many, which is why the defence here cannot be registering or blocking names one at a time.
Common mistakes
Trusting the padlock. A homograph domain gets its certificate in minutes, and gets it in its own name, which is a valid name. The padlock says the connection is encrypted to the domain in the address bar, not that the domain is yours. It is the most expensive misunderstanding around TLS.
Teaching staff to “look carefully at the URL”. It is advice that cannot be followed, because the attack is built so that looking does not help. What can be taught, and can be followed, is never to authenticate from a link you received.
Assuming the browser always warns. Browsers display the Punycode form when they detect mixed alphabets, but the rule depends on the browser, its version and the top-level domain. That is a defence to verify in the browsers your organisation actually uses, not one to assume.
Treating it as a domain problem and forgetting email. Much of the damage arrives through the sender rather than the address bar, and there the decision is not the browser’s but that of email authentication.
How it is detected and reduced
Watch the name space around yours. Public certificate issuance logs make almost any new domain that starts serving over HTTPS visible, and comparing those issuances against the Punycode form of your brand is a check you automate once and then leave running.
Normalise before comparing, everywhere your software compares strings that a person also reads: domain names, senders, usernames and organisation names. Comparing raw bytes is what lets through two strings the user reads as one.
Authenticate inbound and outbound mail. SPF, DKIM and DMARC will not stop anyone registering a lookalike domain, but they do stop them writing from yours, which is the cheap half of the problem.
Take the password out of the equation where you can. A phishing-resistant second factor means a credential captured on a fake page is not enough to get in, and it is the only defence on this list that does not depend on anybody noticing anything. See multi-factor authentication.
And test the reaction rather than the theory. A phishing simulation using a domain that resembles yours measures what actually happens when one arrives, including how many people report it and how quickly, which is the figure you can act on.
Where this shows up in an audit
On an external penetration test the inventory of lookalike domains is part of reconnaissance: registered variants are enumerated, and we check which resolve, which serve content and which already have a certificate issued. That list is usually the first surprise of the engagement.
On a Red Team exercise the homograph domain is a means and not a finding: it exists to test whether the organisation detects and responds, and what gets reported is how long each step took and who saw it.
And in training it is the example that best dismantles the idea that paying attention is enough, because the attendee looks, sees nothing odd, and listens to the rest from there.
FAQ
Is a homograph attack the same as a Punycode attack? Yes, they are two names for the same thing. The first describes the effect, two strings that read alike, and the second the encoding those domain names travel in.
Will antivirus stop it? No. There is no malicious file to analyse: there is a valid domain, a valid certificate and a page that copies another. What can stop it is email authentication, web filtering and a phishing-resistant second factor.
Is it worth registering the lookalikes of my domain? The four or five most plausible ones, yes, and it is cheap. Registering every possible homoglyph combination never ends, which is why the main defence is detection and authentication rather than registration.
How do I check a suspicious domain without opening it? Convert it to its Punycode form. If the resulting string begins with “xn--“, the name carries characters that are not the ones on display, and no further check is needed.