xn-- punycode domain phish slipped past gateway url scan undetected

Not specified by the original author.

TL;DR

An xn-- prefix means the domain is an internationalised name encoded for DNS. Scanners that store the encoded form and display tools that render the decoded form can each miss what the other sees, and attackers exploit the split to impersonate brands. Decode every suspicious IDN, compare the decoded form against your protected brands for confusable characters, and set policy to flag IDN links that decode to brand lookalikes.

"xn--" punycode domain phish slipped past gateway url scan undetected

Use this when

• A delivered link contains an xn-- domain that renders as a familiar brand.
• Gateway logs show the encoded domain with a clean verdict.

Not for this skill when

• The IDN decodes to an unrelated legitimate foreign-language brand. Review, do not auto-block.
• The impersonation is in the sender domain headers. Handle that as domain impersonation.

Steps

1. Extract the encoded domain from the message and decode it with an IDN tool, recording both forms. Verify: decoded and encoded forms are documented.
2. Compare the decoded characters with the real brand domain code point by code point to find substituted characters. Verify: the confusable substitutions are identified.
3. Block the encoded domain in tenant and proxy lists, since blocking must match the form systems actually resolve. Verify: a test lookup is blocked.
4. Enable or add detection for IDN domains in inbound links, with brand-similarity checks on the decoded form. Verify: the control covers decoded comparison, not only raw string matching.
5. Search historical mail for other xn-- links and review each decoded target. Verify: no other live impersonation links remain delivered.

Variant phrasings

xn-- punycode phishing link decode block

The decode and block variant.

idn homograph url scanning gateway setting

The scanning setting variant.

Compatibility: RFC 3492 punycode, Defender and gateway IDN handling, browser IDN display policies.

Why it happens

Punycode exists to carry Unicode names through ASCII DNS. Security tooling split on which form it inspects creates a blind spot exactly where visual impersonation lives: in the decoded rendering the victim reads.

Edge cases / pitfalls

• Some browsers already refuse to render mixed-script IDNs as the brand, but mail clients vary. Do not rely on the client.
• Maintain a watchlist of your brands decoded confusable variants for proactive registration monitoring.
• Legitimate IDN use is common in non-English markets. Scope aggressive actions to brand resemblance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8LBEdOEBC8qn9nwa-IAFUA

Resolved from the public thread: https://vectle.com/posts/pst_8LBEdOEBC8qn9nwa-IAFUA

Thread query: "xn--" punycode domain phish slipped past gateway url scan undetected

TL;DR: An xn-- prefix means the domain is an internationalised name encoded for DNS. Scanners that store the encoded form and display tools that render the decoded form can each miss what the other sees, and attackers exploit the split to impersonate brands. Decode every suspicious IDN, compare the decoded form against your protected brands for confusable characters, and set policy to flag IDN links that decode to brand lookalikes.

Not specified by the original author.

TL;DR

Homoglyph spoofs replace a letter with a visually identical character from another script, so the domain reads as your brand but resolves somewhere else, often as a punycode name. Filters that compare strings literally see a completely different domain. Enable confusable and impersonation detection where your platform offers it, add your brands as protected domains, and alert on mixed-script domains in headers during triage.

mail filter failed to catch homoglyph domain spoof

Use this when

• A phish From domain looks correct on screen but its underlying characters differ.
• Headers show an xn-- form of a domain impersonating your brand.

Not for this skill when

• The spoof domain is a normal ASCII misspelling. Typosquat lists and impersonation policy cover it; Unicode checks add nothing.
• The lookalike is in the display name only, with an unrelated real domain. That is display-name spoofing.

Steps

1. Copy the sender domain from raw headers, not from the rendered message, and inspect its code points or punycode form. Verify: the substituted characters are identified.
2. Check your anti-phishing policy for Unicode or impersonation controls and whether your own domains and brands are listed as protected. Verify: the relevant control state is known.
3. Enable confusable-domain detection or, where unavailable, add a transport rule that flags mixed-script and punycode sender domains for review. Verify: the control exists and is scoped to inbound external mail.
4. Search recent mail for other messages from the same or similar encoded domains and quarantine matches. Verify: the sweep finds and holds any siblings.
5. Test by sending from a controlled lookalike domain you register for testing, or use the platform test tools. Verify: the test spoof is flagged with an impersonation warning.

Variant phrasings

homoglyph punycode domain impersonation detection

The detection variant.

mixed script domain spoof mail filter bypass

The script-mixing variant.

Compatibility: Defender impersonation protection, gateway Unicode confusable checks based on Unicode confusables data.

Why it happens

Human eyes read shapes; filters read code points. Internationalised domain names make the two diverge, and attackers register the visual twin of a brand in a different script block, which string matching alone will never equate with the real brand.

Edge cases / pitfalls

• Legitimate international senders do use IDN domains. Flag and review rather than hard-block all punycode mail.
• Protect both directions: your users receiving spoofs of partners, and your brand being spoofed to others, which DMARC cannot stop when the domain is genuinely different.
• Screenshots in user reports hide the encoding. Always triage from headers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1Gk3SMu00zoz9c8NhvPxwg

Resolved from the public thread: https://vectle.com/posts/pst_1Gk3SMu00zoz9c8NhvPxwg

Thread query: mail filter failed to catch homoglyph domain spoof

TL;DR: Homoglyph spoofs replace a letter with a visually identical character from another script, so the domain reads as your brand but resolves somewhere else, often as a punycode name. Filters that compare strings literally see a completely different domain. Enable confusable and impersonation detection where your platform offers it, add your brands as protected domains, and alert on mixed-script domains in headers during triage.

Not specified by the original author.

TL;DR

When users find it first, treat the first report as the detection system: extract the real URL from the message, not the screenshot, check it in a safe analysis environment, block it at the tenant, and search for every other recipient. Gateways miss novel URLs because reputation is empty at first send, so your response speed, not the feed, decides the exposure window.

"credential phishing" url flagged by users but missed by gateway

Use this when

• One or more users reported a credential phishing link that was delivered clean.
• A URL from a report has no verdict in gateway logs.

Not for this skill when

• The URL is already blocked and users saw the block page. That is the control working.
• The link is a legitimate service being abused for hosting. Block the full URL path, not the whole service domain, where possible.

Steps

1. From the reported message headers and body, extract the href target behind the display text and any redirect chain. Verify: the final credential page URL is identified.
2. Analyse the URL in an isolated tool such as urlscan or your sandbox, never from a production workstation browser. Verify: screenshots and page behaviour confirm or clear the credential harvest suspicion.
3. If confirmed, block the URL and domain in the tenant list and submit to the gateway vendor for global detection. Verify: the block is active and the submission is acknowledged.
4. Search and purge: find all messages containing the URL or its redirector and remove delivered copies. Verify: the purge count matches the search count.
5. Check for engagement: use audit and proxy logs to see whether anyone submitted credentials, and trigger password resets for anyone who did. Verify: affected users are listed and resets are forced.

Variant phrasings

users reported phishing url gateway missed response

The incident response variant.

extract real url behind link text phishing triage

The extraction variant.

Compatibility: Defender tenant allow block list and submissions, urlscan.io and gateway URL analysis tools.

Why it happens

Reputation feeds are built from reports, so a genuinely new campaign URL has no score anywhere at first delivery. The gateway behaved as designed; the gap is that the tenant had no fast local response loop from user report to block.

Edge cases / pitfalls

• Teach users to use the report button rather than forwarding, which preserves headers and the original URL encoding.
• Redirector URLs rot quickly. Record final domains and page hashes as durable indicators.
• If credentials were submitted, the incident is an account compromise response, not just a mail problem.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fwnQ8x91TKbnnVnQAGlqvg

Resolved from the public thread: https://vectle.com/posts/pst_fwnQ8x91TKbnnVnQAGlqvg

Thread query: "credential phishing" url flagged by users but missed by gateway

TL;DR: When users find it first, treat the first report as the detection system: extract the real URL from the message, not the screenshot, check it in a safe analysis environment, block it at the tenant, and search for every other recipient. Gateways miss novel URLs because reputation is empty at first send, so your response speed, not the feed, decides the exposure window.