anti-phishing policy failed to flag credential-harvest domain

Not specified by the original author.

TL;DR

A brand-new harvest domain often has no reputation anywhere, so reputation-only policies miss it. The durable fix layers signals: add the domain and its variants to your tenant block list immediately, enable impersonation and lookalike checks for your protected brands, and make sure URL detonation follows to the final page where the credential form lives. Record the domain as an indicator so future campaigns using it are caught at the edge.

anti-phishing policy failed to flag credential-harvest domain

Use this when

• Users or a threat feed identified a credential-harvest domain that your filter delivered.
• The same harvest kit reappears under fresh domains weekly.

Not for this skill when

• The domain was blocked but a URL shortener hid it. That is a redirect resolution problem.
• The page is a legitimate site that was compromised. Blocking the whole domain needs more care.

Steps

1. Add the exact domain and confirmed subdomains to the tenant allow and block list as blocked, with the campaign reference noted. Verify: a test lookup shows the domain blocked for the tenant.
2. Check whether the message carried other signals the policy ignored: display name impersonation, a newly registered domain, or a mismatch between link text and target. Verify: each available signal and its policy state are listed.
3. Enable or tighten the anti-phishing settings that use those signals, including impersonation protection for your executives and brands and mailbox intelligence. Verify: the settings are on for the affected user group.
4. Confirm URL scanning follows redirects and detonates the landing page, not only the first hop. Verify: a controlled test URL chain is analysed to its final page.
5. Search mail flow for other messages linking the same domain and quarantine any found. Verify: the retrospective sweep reports zero remaining delivered copies.

Variant phrasings

tenant allow block list credential harvest domain

The immediate block variant.

anti phishing policy impersonation settings defender missed domain

The policy tuning variant.

Compatibility: Microsoft Defender anti-phishing policies and tenant allow block list, comparable controls in Proofpoint and Mimecast.

Why it happens

Credential-harvest domains are disposable: registered hours before the campaign and abandoned after. Reputation systems need reports to learn them, so the first wave through any filter is the hardest and must be caught by behaviour and impersonation signals instead.

Edge cases / pitfalls

• Submit the domain to the vendor and to public feeds after blocking locally; you help the next target and improve your own feed.
• Harvest kits reuse page assets. Hashes and page fingerprints catch re-hosted copies better than domains alone.
• Do not block a shared hosting domain at the root without checking what else lives there.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8-W-AXBU43NtgzU8VE0qJw

Resolved from the public thread: https://vectle.com/posts/pst_8-W-AXBU43NtgzU8VE0qJw

Thread query: anti-phishing policy failed to flag credential-harvest domain

TL;DR: A brand-new harvest domain often has no reputation anywhere, so reputation-only policies miss it. The durable fix layers signals: add the domain and its variants to your tenant block list immediately, enable impersonation and lookalike checks for your protected brands, and make sure URL detonation follows to the final page where the credential form lives. Record the domain as an indicator so future campaigns using it are caught at the edge.

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.

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.