Lookalike domains and brand-new sites: the phishing infrastructure blocklists miss on day one

Many phishing sites run on freshly registered domains or on lookalikes of a real brand, and they often go live before any blocklist knows about them. The fix isn't a better blocklist. MSPs close the gap by treating brand-new and uncategorized domains as untrusted by default, stopping business credentials from being typed into unapproved sites, and giving end users a visible sign that a sign-in page is the real one.

How do attackers use new and lookalike domains?

Domains are cheap, fast to register, and disposable, which makes them ideal for phishing. Attackers lean on a few patterns:

• Brand-new domains. A domain registered this morning hosts a fake Microsoft 365 sign-in page this afternoon, and it's abandoned by the weekend.
• Typosquats. A missing letter, a swapped letter, or an extra word, such as a vendor's name with "-billing" or "-secure" added.
• Lookalike characters. Letters from other alphabets that look identical to Latin ones, so a domain reads correctly in an email or a link but points somewhere else.
• New top-level domains. The real brand name on an unfamiliar ending, which end users don't think to question.
• Trusted hosting. A phishing page on a legitimate file-sharing, form, or site-builder service, where the domain itself has a good reputation.

Small businesses are exposed to the typosquat version too. An attacker who registers a lookalike of a client's own domain, or of a supplier's, can send invoices and sign-in requests that pass a quick glance.

Why do blocklists miss them?

Blocklists only know about a site once someone has reported it, a crawler has found it, or a sensor has seen it attack someone else. A new phishing domain has none of that history. The first hours of a campaign are when it's most effective and least known.

Attackers design for that window. They register fresh domains for each campaign, rotate them quickly, and sometimes show the phishing page only to visitors who arrive from the email link, so a scanner checking the site sees nothing wrong.

That's why reputation-based blocking, on its own, always starts a step behind. It still blocks the bulk of known threats, and it should stay on. The gap is the newest domains, and closing it takes rules that don't depend on reputation at all.

What can end users check, and why isn't it enough?

End users can catch a lot with a few habits, and they're worth teaching:

• Read the domain, right to left. The name just before the ending, such as .com or .co.uk, shows who registered the domain. Everything to its left can be anything the attacker wants.
• Be suspicious of sign-in prompts from links. A request to sign in again right after clicking a link in an email or document deserves a second look.
• Go direct for money and passwords. Type the bank's or vendor's address, or use a saved bookmark, rather than following the link.
• Question urgency. "Your account will be suspended" and "invoice overdue" are pressure tactics, not signs of a real problem.

The trouble is that these checks depend on a person getting it right every time, on every device, at the end of a long day. Lookalike characters can fool a careful reader, and a fake sign-in page can be pixel-perfect. Training lowers the odds. Technical controls have to catch what training misses.

What should MSPs put in place?

MSPs need controls that work without knowing a site is bad, layered on top of the usual threat blocking.

1. Treat new and uncategorized domains as untrusted. Warn on them by default, and block them for clients that handle money, sensitive, and regulated data. The legitimate sites end users need for work are rarely brand new, so the friction is usually small.
2. Keep reputation-based blocking on everywhere. Block malicious, phishing, and command-and-control categories at both the DNS and browser layers, on the office network and, with a roaming agent on the endpoint, on any network the end user may be on.
3. Stop business credentials from going where they shouldn't. Block end users from typing their work email and password into sites that aren't approved business apps. A fake sign-in page then gets nothing, even if it looks perfect.
4. Warn on first-time logins. Entering credentials on a site the end user has never logged in to before, especially one with lookalike characters in the domain, is worth a pause.
5. Give end users a trust mark. Visible watermarks on real sign-in pages for key apps, such as Microsoft 365, train end users to notice when it's missing.
6. Move to phishing-resistant MFA. Passkeys and security keys won't work on a fake domain, which takes away the prize even when everything else fails. For more, see why MFA alone doesn't stop session hijacking.
7. Investigate safely. When an end user reports a suspicious site, inspect it in an isolated browser session, where no harm can occur, rather than on a technician's own device.

The first and third controls do the most work for small clients. Together, they mean a phishing site has to get past two separate checks before it can collect anything useful.

How does Atakama help?

Atakama’s content filtering rule includes “new and uncategorized” domains that can be set to warn or block, alongside the malicious domains, which covers phishing and fraud, malware distribution, command-and-control, and other threat categories. Content filtering applies in the browser on managed devices wherever they connect, and Atakama’s DNS extends category blocking across endpoints and office networks.

For credentials, SaaS login controls block business credentials from being entered on sites that aren't approved business apps, including phishing pages. Credentials risk warnings can alert end users before they sign in to a site they haven't used before, and flag a possible malicious website when the domain contains foreign characters. Atakama’s watermarking rule adds a trust mark to the real sign-in pages the MSP chooses, such as Microsoft 365. When an end user reports a suspicious site, MSP admins can open it in remote browser isolation, a read-only cloud session, and screenshot it for the client. For MSPs, those protections roll out from a global policy across clients and adjust per client where needed.

FAQ

What is a newly registered domain?

A domain registered recently, typically within a week or so. Attackers register fresh domains for phishing campaigns because they have no history on blocklists yet.

Should MSPs block newly registered domains?

Warn on them by default, and block them for clients with higher risk, such as those handling payments and other sensitive data. The legitimate sites end users need are rarely brand new, so the friction is usually low.

What is typosquatting?

Registering a domain that looks like a real one, with a missing, swapped, or extra letter, or a familiar brand name on an unfamiliar ending. Typosquats are used for phishing pages and fake invoices.

What are lookalike characters in domains?

Letters from other alphabets that look the same as Latin letters, used to build a domain that reads like a real brand but belongs to someone else. They're also called homograph attacks.

Why don't blocklists catch new phishing sites?

Blocklists depend on a site having been seen and reported. New domains have no history, and attackers rotate them quickly, so the first hours of a campaign often go undetected.

What stops fake sign-in pages most reliably?

Stopping business credentials from being entered on unapproved sites, paired with phishing-resistant MFA. Together, they mean a convincing fake page still gets nothing usable.

Keep reading

For related threats, see why MFA alone doesn't stop session hijacking, how ClickFix and fake AI installers work, why browser-saved passwords are a client risk, and our page on phishing protection.