Phishing works when a string a person trusts, a domain, a sender name or a link, is replaced by one that only looks the same, and people cannot reliably tell the difference. MITRE D3FEND names the countermeasure Homoglyph Detection (D3-HD) and defines it as "Comparing strings using a variety of techniques to determine if a deceptive or malicious string is being presented to a user." It sits under the Detect tactic as a child of Identifier Analysis (D3-ID) and analyses two artefacts: Email and URL. This card covers how homoglyph detection works, which ATT&CK techniques D3FEND relates it to, where it is implemented in browsers, mail filters and DNS, and how to prove it catches lookalikes of your own names. It is for detection engineers, email security owners and SOC leads; the wider brand protection picture is in the Typosquatting and Lookalike Domains Guide.
Key takeaways
- Compare against what you protect. Homoglyph detection is only as good as its reference list: your domains, key partners, executives and the services your users log in to.
- Two families of lookalike. Character swaps from other scripts (Cyrillic "а" for Latin "a") and same-script tricks such as goooogle.com, rn for m or a dropped letter need different checks.
- Unicode already defines the hard part. Unicode Technical Standard #39 publishes confusables data and a skeleton() function that reduces lookalike strings to a common form for comparison.
- D3FEND relates it to eight ATT&CK techniques. All are inferred through the Email and URL artefacts, from Spearphishing Link (T1566.002) to Email Bombing (T1667).
- False positives are the main cost. D3FEND's own considerations warn that non-dictionary product names produce many false positives and that processing DNS at scale is expensive.
D3-HD at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-HD (d3f:HomoglyphDetection) |
| Tactic | Detect |
| Parent technique | Identifier Analysis (D3-ID) |
| Digital artefacts | Email and URL (D3FEND relation: analyzes) |
| D3FEND references | Greathorn patent on visually similar character strings; Endgame patent on a Siamese convolutional neural network for homoglyph attacks; Verisign patent on visual international domain name collisions |
| Typical inputs | Sender domains and display names, URLs in messages and chat, DNS queries, newly registered and certificate-logged domains |
| Effort | Low to switch on mail and browser features; medium to run your own lookalike monitoring |
| Main limitation | Catches imitation of names on the reference list only; a convincing but unrelated domain passes |
How it works
D3FEND's description uses goooogle.com versus google.com as its example and places the technique in phishing and typosquatting. Its three patent references show the main methods.
- Character look-alike sets: the Greathorn method compares an input string against sets of visually similar characters and character combinations, including transpositions, additions and deletions, and alerts when similarity crosses a threshold. This is the family that catches rn for m and doubled letters.
- Rendering and image comparison: the Endgame method converts strings to images and uses a trained Siamese neural network to score visual similarity to a list of legitimate strings. The Verisign method decodes a punycode domain to Unicode, renders it, runs optical character recognition and compares the result with existing domains.
- Skeleton comparison: Unicode Technical Standard #39 (UTS #39, Unicode Security Mechanisms) defines two strings as confusable when their skeletons match. skeleton() normalises the string and replaces each character with its prototype from the confusables.txt data file. UTS #39 also separates mixed-script confusables (Latin "paypal" with one Cyrillic letter) from whole-script confusables (Latin "scope" and an all-Cyrillic lookalike).
Internationalised domain names travel in DNS as ASCII. Punycode (RFC 3492, Standards Track) converts a Unicode label into an ASCII label that carries the IDNA ACE prefix xn--. A detector should decode every xn-- label to Unicode before comparison, otherwise a whole-script lookalike looks like random text and is missed.
ATT&CK techniques D3FEND relates to D3-HD
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-HD. Every row below is inferred through a shared digital artefact: D3-HD analyzes Email and URL, so ATT&CK techniques that produce, read or access those artefacts are related to it. D3FEND labels these relations inferred and experimental (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What homoglyph detection catches |
|---|---|---|---|
| T1566.001 | Phishing: Spearphishing Attachment | Produces Email | Lookalike sender domain or display name on the message carrying the attachment |
| T1566.002 | Phishing: Spearphishing Link | Produces Email; produces URL | Lookalike sender and lookalike link host |
| T1566.003 | Phishing: Spearphishing via Service | Produces URL | Lookalike links sent through social media or chat |
| T1204.001 | User Execution: Malicious Link | Accesses URL | Browser or proxy check on the host the user is about to open |
| T1189 | Drive-by Compromise | Produces URL | Lookalike hosts used to lure users to a compromised or fake site |
| T1534 | Internal Spearphishing | Produces Email | Lookalike internal display names; less useful when a real internal account sends the message |
| T1114.001 | Email Collection: Local Email Collection | Reads Email | Little direct value: the relation comes from the shared Email artefact |
| T1667 | Email Bombing | Produces Email | Little direct value; lookalike support domains may follow a bombing wave in callback scams |
D3FEND also relates the same artefacts to the ICS techniques T0865 Spearphishing Attachment and T0817 Drive-by Compromise. Treat the table as a placement guide: the strong fits are the phishing and malicious link rows. Deeper defensive coverage is in MITRE ATT&CK T1566 Phishing and T1204 User Execution.
Where it is implemented
Products are listed alphabetically within each row and named only as examples of a class.
| Implementation class | What it provides | Signal used | Fits when |
|---|---|---|---|
| Browser IDN display policy | Chromium shows punycode instead of Unicode for labels with mixed scripts, whole-script confusables or a skeleton that matches a top domain (its example: googlé.com), and shows a full-page lookalike warning when a host's skeleton matches a recently engaged site or a top-500 domain | URL in the address bar | Always on for users of that browser; no tuning |
| Email impersonation protection | Google Workspace offers "Protect against domain spoofing based on similar domain names" and "Protect against spoofing of employee names" with warning, spam or quarantine actions. Microsoft Defender for Office 365 anti-phishing policies offer user impersonation protection (up to 350 users per policy), domain impersonation protection (up to 50 custom domains plus accepted domains) and an unusual characters safety tip | Sender domain, display name, From address | Mail is hosted on one of these platforms |
| Secure web gateway and DNS filtering | Category and lookalike checks on requested hosts | DNS queries, proxy logs | You need coverage beyond one browser |
| Lookalike domain monitoring | Permutations of your domains checked against new registrations and certificate transparency logs | Domain registrations and certificates | Early warning before a lookalike is used |
| SIEM analytics | Your own skeleton or edit-distance comparison over sender domains and DNS logs | Mail and DNS logs | You want custom reference lists such as suppliers and payroll providers |
Availability: Microsoft documents impersonation protection as part of Defender for Office 365 anti-phishing policies, with no protected users or domains configured by default. Google documents the spoofing and authentication settings under the Gmail advanced phishing and malware protection page in the Admin console.
Implementation steps
- Build the reference list. Your registered domains, key subdomains, suppliers that send invoices, payroll and HR providers, identity provider login hosts, and the executives most often impersonated. Keep it owned and reviewed.
- Turn on platform features first. Enable the mail platform's similar-domain and employee-name protections in warning mode, add protected users and domains, and add the reference list where the platform allows.
- Normalise before comparing. In custom analytics, lowercase, decode
xn--labels, compute the UTS #39 skeleton, then compare both skeleton equality and a small edit distance against the registrable part of each protected domain. - Pilot in warn mode. Run for two to four weeks, review every hit and add genuine partners to trusted lists. Microsoft notes trusted domains do not include subdomains, so add each one.
- Move to enforcement. Quarantine high-confidence lookalikes of your own domains and of top-risk suppliers; keep warnings for lower-confidence matches.
- Register and redirect defensively. For the closest lookalikes of your own brand, consider registering them and redirecting with an HTTP 301 or 302; Chromium's documentation says meta refresh redirects are ignored by its lookalike check. Takedown steps for the rest are in the Brand Impersonation and Lookalike Domain Takedown Playbook.
- Roll back safely. Switch quarantine actions back to warning per policy if a legitimate partner is blocked, and fix the trusted list rather than disabling the protection.
How to verify it works
- Controlled lookalike test: from a domain you own that imitates your primary domain (for example, one registered defensively), send a test message to pilot mailboxes and confirm the warning or quarantine and the alert.
- Display name test: send from an external test account using a protected executive's display name and confirm the employee name or user impersonation protection fires.
- Analytics unit test: feed your custom rule a fixed list of lookalikes (mixed-script, whole-script, doubled letter, rn for m, swapped TLD) and confirm each is flagged and each real domain is not.
- Punycode check: confirm that
xn--labels appear decoded in your detections and logs, not only in raw form.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Test lookalikes caught in the quarterly unit test | 100% | Proves normalisation and comparison work |
| Protected names on the reference list reviewed in the last 6 months | 100% | Detection only covers what is listed |
| False positive rate after pilot | Falling month on month | The cost D3FEND warns about |
| Time from lookalike registration seen to block or takedown request | Tracked per case | Early action before the domain is used |
| User reports of lookalike messages that bypassed filters | Tracked monthly | Shows residual gaps |
Limits, bypasses and failure patterns
- Unrelated but plausible domains: "yourcompany-payments.com" is not a homoglyph of anything. Pair D3-HD with domain age and reputation checks (see D3-IRA Identifier Reputation Analysis).
- Display name only: attackers send from free mail services with a protected name in the display field; domain checks miss this, so employee name protection must be on.
- Raw punycode in logs: detection that compares
xn--strings directly misses whole-script lookalikes. - Over-broad matching: high edit-distance thresholds flag every short or non-dictionary brand, which D3FEND names as the main false positive source, and teams then switch the rule off.
- Compromised real accounts: internal spearphishing from a genuine mailbox has no lookalike to find; account takeover detection is the control there.
- Images and QR codes: a lookalike URL inside an image or QR code needs extraction first. See the QR Code Phishing (Quishing) Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-8 Spam Protection | Filtering of unsolicited and deceptive messages at entry points |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring, SC-7 Boundary Protection | Monitoring and filtering traffic to lookalike hosts |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Monitoring networks and network services; analysing adverse events |
| MITRE ATT&CK | M1021 Restrict Web-Based Content, M1017 User Training | Mitigations the detection supports |
| MITRE D3FEND | D3-ID, D3-HD | Parent and technique |
Related countermeasures
- Identifier Reputation Analysis (D3-IRA): catches lookalikes that are already known bad, and newly registered domains.
- Identifier Activity Analysis (D3-IAA): searches telemetry for every user who already contacted a lookalike once it is found. See D3-IAA Identifier Activity Analysis.
- Multi-factor Authentication (D3-MFA): phishing-resistant methods bound to the real origin defeat credential harvesting on lookalike sites. See D3-MFA Multi-factor Authentication.
Practitioner checklist
- Maintain an owned reference list of protected domains, suppliers and executives.
- Enable similar-domain and employee-name protection on the mail platform.
- Decode punycode and compute UTS #39 skeletons before any custom comparison.
- Pilot in warning mode, then quarantine high-confidence lookalikes of your own domains.
- Add each legitimate partner subdomain to trusted lists explicitly.
- Monitor new registrations and certificate logs for permutations of your domains.
- Run a quarterly unit test with a fixed set of lookalikes and record the result.
- Pair homoglyph detection with reputation and domain age checks.
Standards and references
- MITRE D3FEND: Homoglyph Detection (D3-HD)
- Unicode: UTS #39 Unicode Security Mechanisms
- IETF: RFC 3492 Punycode
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-8)
- Chromium: IDN display policy
- Google Workspace Admin Help: Advanced phishing and malware protection
- Microsoft Learn: Anti-phishing policies in Microsoft 365
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Typosquatting and Lookalike Domains Guide · Domain Portfolio and Lookalike Domain Management Guide · Email Security Guide · Phishing Guide