Fake Teams Sign-In Domains: Block teams-cloud.live Correctly in Microsoft 365

The practical advice in that report is mostly sound, with one part that needs clarifying. It recommends ~teams-cloud.live with a leading tilde as the Microsoft 365 block entry. That syntax is valid in one part of Microsoft's Tenant Allow/Block List and doesn't work in another. Admins who type it into the wrong list may think they're protected when they aren't.

What is known about teams-cloud.live​

According to Lim's warning as reported:

• Age: The domain was about five days old when he flagged it, so it was registered around October 13. That date is an estimate, not a confirmed registration record.
• What the page does: It copies the Teams sign-in screen and interface. Someone who arrives from a link in a message sees a page that looks like the app they use every day.
• The "update Teams" option: Clicking it downloads a plain text (TXT) file. Nobody has published what's in the file, its hash, or any analysis of it.
• A subdomain named after Amgen: A comment on Lim's report mentions amgen.teams-cloud.live, which uses the name of the pharmaceutical company. Whoever controls a domain can create a subdomain with any name in seconds. The name alone doesn't show that Amgen was targeted successfully or that any Amgen employee visited the page.
• An earlier site: On October 8, Lim flagged teams-online.com, another Teams lookalike that was four days old at the time. He reported zero detections from Microsoft Defender but didn't say which Defender product or settings he used. Treat that figure as a single snapshot. Nobody has shown that the same people run both sites.

What isn't known​

• How many people opened the page.
• Whether anyone entered a password.
• Who runs the domain.
• What the TXT file is for. A text file doesn't run code by itself, but it could contain instructions or addresses for a later step. Calling it malware isn't justified yet.

Nothing here supports talk of an "attack in progress." A copied login page with no victims looks exactly like one with a thousand. Blocking the domain is still worth doing because it takes about a minute and costs nothing.

Section summary: A recently registered Teams lookalike exists and is credible enough to fool a busy user. There's no confirmed theft and no confirmed target, and the downloaded file hasn't been analysed.

How to spot a fake Teams sign-in page​

Real Microsoft sign-in pages sit on Microsoft-owned domains such as microsoftonline.com or microsoft.com. An address that combines "teams" with a .live, .online or other unusual ending belongs to someone else. The problem is that people rarely read the address bar, and a name like "teams-cloud" sounds like it could be an internal company service.

Four warning signs, roughly in order of how quickly you can check them:

• The domain isn't Microsoft's and uses an ending Microsoft doesn't use for Teams.
• How you got there: you followed a link in a message instead of opening the app or your company portal yourself.
• An update prompt asking you to download a file. The Teams app updates itself.
• A company name at the front of the address, such as yourcompany.suspicious-domain.live, which is meant to make the page feel familiar.

Blocking it in Microsoft 365: use the right list​

Microsoft Defender for Office 365's Tenant Allow/Block List has separate tabs for different kinds of entries, and each uses different wildcard rules.

For links inside email: the URLs list​

A phishing page reaches users as a link, so the URLs list is the main control. Microsoft's PowerShell reference shows a tilde example: the command New-TenantAllowBlockListItems -ListType Url -Block -Entries ~contoso.com~ adds a URL block entry for contoso.com and all subdomains (for example, contoso.com,, xyz.abc.contoso.com, and ).

The same page confirms that for URL entries, wildcards ( and ~) are supported in hostnames. Microsoft's syntax notes say subpaths aren't implied for allow* entries: contoso.com does not include contoso.com/a. Block entries are broader. Microsoft's syntax table shows a bare contoso.com block entry also matches its subdomains and their paths, such as contoso.com/a and abc.xyz.contoso.com/a/b/c.

For this case, an entry of ~teams-cloud.live~ covers:

• the base domain
• the Amgen-named subdomain

Microsoft's syntax table shows the tilde form excludes URL paths. A bare teams-cloud.live block entry is broader and also matches subpaths, so use that if you want paths covered too.

Repeat it for ~teams-online.com~. Microsoft also notes that when no expiration is set, the entry expires after 30 days, so decide whether 30 days is long enough.

For mail sent from the domain: Domains & addresses​

If you also want to block email from the domain, the tilde doesn't apply. Microsoft's documentation for sender entries is clear on this. A block entry for contoso.com blocks only contoso.com; it doesn't block subdomains. Similarly, a wildcard entry for *.contoso.com blocks subdomains, but it doesn't block contoso.com itself. To block the specified domain and its subdomains, you need separate block entries for both values.

So you need two entries:

• teams-cloud.live
• *.teams-cloud.live

In the Defender portal, the path is Email & collaboration > Policies & rules > Threat policies > Tenant Allow/Block Lists, then the Domains & addresses tab. Microsoft's sender documentation adds two points:

• Activation: entries should take effect within five minutes.
• Entry limits: 500 sender block entries without Defender for Office 365, 1,000 with Plan 1, and 10,000 with Plan 2.

Those limits apply to the sender list. They weren't checked here for URL entries.

Section summary: Use ~teams-cloud.live~ on the URLs tab. Use teams-cloud.live plus *.teams-cloud.live on the Domains & addresses tab. Both lists only filter email.

Stopping the browser from opening it​

Blocking the link in email does nothing about a link that arrives through Teams chat, a text message, or a personal inbox. For that, you need protection on the device or the network.

Microsoft Defender for Endpoint's network protection can enforce custom URL and domain indicators. Microsoft's network protection documentation sets some conditions:

• Microsoft Edge: SmartScreen must be enabled.
• Other browsers: network protection must be in block mode. Audit mode only records what would have been blocked.
• Chrome and Firefox: blocking a domain over HTTPS requires QUIC and Encrypted Client Hello to be turned off. Network protection reads the domain name from the TLS handshake and can't do that when those features are on.
• Delay: Microsoft warns of up to two hours, usually less, between adding an indicator and the block taking effect.
• Requirements: Windows 10 or 11 Pro or Enterprise (or supported Server, macOS and Linux versions), with Microsoft Defender Antivirus active and real-time protection on.

If your organisation doesn't use Microsoft's stack, a DNS filter or the company web proxy does the same job. Whichever tool you use, check the web access and DNS logs for visits to either domain. A visit doesn't prove a password was stolen, but it tells you which users to follow up with.

If someone already entered their password​

Opening the page without typing anything is low risk. If a user entered their email address and password, the report recommends this response:

• Reset the password from a clean device.
• Revoke all active sessions.
• Check the account for newly registered sign-in methods.
• Check the mailbox for new forwarding rules.

Steps 3 and 4 matter because a new sign-in method or forwarding rule lets an attacker keep access after the password is changed. If the user reused that password elsewhere, change it there too. Anyone who downloaded the TXT file should leave it unopened and hand it to the security team.

Why passkeys stop this kind of attack​

Text-message codes and approve-on-your-phone prompts can be relayed through a fake page in real time. Passkeys can't. Microsoft's Entra documentation explains that passkeys use origin-bound public-key cryptography, so a passkey works only on the website or app it was created for. A copied page on teams-cloud.live has nothing to request from it.

Rolling out passkeys takes real work: distributing keys, training users, and handling account recovery. It is still the only defence here that doesn't depend on someone reading the address bar.

Analysis: the five-day window​

This is my own analysis from general industry experience, not something the report measured. Registering a domain costs a few dollars, and copying a login page is easy. Reputation feeds often take some time to catch up with brand-new domains. Lim's report that Defender didn't flag teams-online.com fits that pattern, but one data point doesn't prove a trend.

The lasting lesson is to block newly registered domains that include well-known brand names by default, rather than waiting for a feed to catch each one. Whoever is behind these two sites, both point at the same thing: a work account. For now, add four entries:

• URLs tab: ~teams-cloud.live~ and ~teams-online.com~
• Endpoint indicators: teams-cloud.live and teams-online.com

Then check your logs for earlier visits.

Correction (October 19, 2026): An earlier version said Microsoft's URL syntax doesn't imply subpaths, citing contoso.com vs contoso.com/a. That no-subpath rule applies only to allow entries; Microsoft's syntax table shows a bare domain block entry also matches subdomains and their paths. The article also said the ~teams-cloud.live~ entry covers URL paths; per Microsoft's table, the tilde form covers the domain and its subdomains but excludes paths.