## TL;DR
A cloned login page on a fresh domain defeats reputation because the domain is new and the page copies the real brand perfectly. Catch it on what does not change: the kit reuses page structure, asset hashes and form behaviour, and the domain is not a Microsoft domain. Block the specific host, submit the kit fingerprint to your vendor, and check whether anyone entered credentials, because a pixel-perfect clone fools even careful staff.

```text
fake microsoft login clone bypassed url reputation check and filter failed to block it
```

## Use this when
- Delivered mail links to a sign-in page that looks like Microsoft but sits on an unrelated domain.
- URL reputation shows no verdict or clean for the clone host.

## Not for this skill when
- The page is hosted on a real Microsoft domain. Verify the full URL carefully before treating it as a clone.
- The issue is a lookalike sender domain with no link. That is domain impersonation, not a cloned page.

## Steps
1. Record the full URL and capture the page in an isolated analysis environment, noting form action targets and asset names. Verify: evidence of the clone is captured without visiting from a work machine.
2. Block the host and URL in the tenant list and in the web proxy or DNS filter if you run one. Verify: internal test resolution of the host is blocked.
3. Submit the URL and page indicators to your mail vendor and to Microsoft reporting channels for the impersonation. Verify: submissions are confirmed.
4. Hunt for the campaign: search mail and proxy logs for the host and for sibling hosts in the same message set. Verify: all delivered copies are purged and proxy hits are listed.
5. For any user who visited, check sign-in logs for impossible travel or new MFA methods and force a reset. Verify: potentially compromised accounts are secured.

## Variant phrasings
### fake microsoft 365 login page clone detection
The clone detection variant.
### credential harvest page fingerprint phish kit block
The fingerprint variant.

Compatibility: Defender and gateway URL controls, web proxy and DNS filtering layers, Microsoft phishing reporting.

## Why it happens
Kits copy the victim brand, not the detection surface. The page must still POST credentials to attacker infrastructure from a non-brand domain, and that combination of brand assets plus alien domain is the reliable signal reputation lacks on day one.

## Edge cases / pitfalls
- Attackers increasingly proxy the real login to pass MFA. Check for adversary-in-the-middle indicators in sign-in logs, not just password entry.
- Legitimate regional Microsoft pages use Microsoft domains. Train the check as domain first, appearance second.
- Keep the captured page source; kit reuse across campaigns makes it valuable evidence later.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1unQe-BkKbMrpX13nqAlaQ