1 · Generate lookalike domains

Enter a domain you own (e.g. yourdomain.com). Substitutes Latin letters with visually identical Cyrillic/Greek glyphs and shows the real xn-- punycode form you'd have to register at a registrar.

2 · Analyze a string

Paste any email or domain — see the true codepoint of every character, non-ASCII flags, Unicode block, and which Latin letter it's impersonating.

The attack chain this lab reproduces (Voorivex: 0-click punycode ATO)

The bug is an inconsistency: the database folds the puny character, SMTP doesn't, and the app emails the string as typed.

1Prerequisite: the attacker controls a mailbox on a puny/lookalike domain — e.g. xn--gmil-1sa.com (renders as gmăil.com). No account on the target is needed.
2Submit: in the forgot-password form the attacker types the victim's email with one puny char: victim@gmăil.com. SMTP would deliver this to the attacker — that's the whole point.
3DB folds: the lookup WHERE email = 'victim@gmăil.com' runs under an accent-insensitive collation (MySQL default *_ai_ci): gmăil == gmail → it matches the victim's real row → token issued against the victim.
4SMTP doesn't fold: the app emails the reset link to the string as typed — victim@gmăil.com — which DNS resolves to the attacker's mail server. Victim's token, attacker's inbox.
50-click ATO: attacker opens the link and resets the victim's password. The victim did nothing.

Why WordPress is immune even with the same risky collation: it queries the DB with user input but emails the address pulled from the DB row. Both halves matter. This lab has toggles for each half: FOLD_COLLATION (DB folds / exact) and EMAIL_FROM (UserInput ⚠ / EmailFromDB ✓). Same inconsistency also bites OAuth flows when an identity provider returns a puny email the app trusts (the writeup: GitLab does — Google doesn't).