Microsoft Teams Phishing: External Access Risks and Defender Protection Gaps

What KnowBe4 reports​

KnowBe4 says weekly Teams phishing detections rose from five in the week of June 22 to a peak of 301 in the week of September 28. That is a count from its own Email & Collaboration product. The post gives no denominator, customer coverage or methodology.

Treat the figure as evidence of a trend in one vendor's telemetry. It is not an industry-wide incidence rate for Teams phishing.

The post's central argument is behavioral. Users have spent years learning to distrust unexpected email. A chat notification from a familiar app, with a name and a link, doesn't trigger the same caution. The post also notes that the sender can often choose the display name users see, and that a link can show one address and open another. Messages can be edited after sending, so what a user sees later may differ from the original.

How the attack unfolds​

KnowBe4 describes a six-step chain:

1. The attacker picks a plausible identity, such as IT support, a vendor or a colleague.
2. The message gets in through whatever external access the tenant permits. That could be open federation, personal accounts able to start chats, or trial-only tenants an admin has allowed.
3. The user clicks, replies or starts a session. Attackers may also call the user in Teams to talk them through the steps.
4. The user lands on a fake page or receives a payload.
5. The user hands over credentials, grants access or pays.
6. The attacker uses the compromised account to send the next lure.

The three lures​

• Fake IT support. The aim is a remote session the user opens themselves. KnowBe4 notes that remote administration tools are legitimate software, so standard defenses often miss them. Access could expose saved passwords, session cookies and documents. It could also give the attacker a foothold for lateral movement, further RMM tools or ransomware.
• Urgent invoice. A deadline and a personal greeting push the target to act before checking. The goals include payment to an attacker-controlled account, credential theft and malware.
• Ransom note in chat. The message arrives with no email gateway in its path. It may follow a real compromise or be a bluff. KnowBe4's advice is to report it to the security team and not reply.

What Microsoft's own protections do, and don't do​

The post says Defender for Office 365 adds Safe Links and zero-hour auto purge (ZAP) "where it is licensed." Microsoft's documentation shows the layers differ in important ways.

• Baseline URL warnings. All Teams licenses in Microsoft 365 include near real-time URL protection. Known malicious URLs are delivered with a warning. Messages found to contain malicious URLs up to 48 hours after delivery also receive a warning. This covers internal and external chats and channels. It is a warning, not a click-time block.
• Safe Links. This provides time-of-click URL protection and requires Defender for Office 365. Microsoft contrasts it with the base feature: it blocks URLs at the time of click based on your Defender portal settings and requires Defender licenses.
• ZAP for Teams. This needs Defender for Office 365 Plan 1 or Plan 2. Microsoft says ZAP is available for internal messages in Teams chats identified as malware or high confidence phishing, and external messages aren't currently supported. In standard channels the same limit applies, while shared channels support both internal and external messages. It is also unavailable in GCC, GCC High and DoD.

That last point matters for this threat. The attacks KnowBe4 describes are mostly external contact: federated tenants, personal accounts and impersonated outsiders. ZAP is unlikely to clean those up from a chat. Don't assume a licensed Defender tenant will retroactively purge an external lure.

Microsoft also moved the licensing goalposts. Reporting at the time said it would enable ZAP in Teams for all organizations with Defender for Office 365 Plan 1 starting January 6, 2026. Older guidance that limits ZAP for Teams to Plan 2 is out of date. Quarantined Teams messages are admin-only by default, so users won't see a notification when something is removed.

Microsoft also lists the following as available to users and responders:

• User reporting of Teams messages, calls, meetings and meeting participants.
• A Teams message entity panel for SecOps review.
• With Plan 2, the ability to remove users from chats and to hunt across Teams messages and calls.

Narrowing the external-access door​

KnowBe4 says external access is open to all domains by default. Microsoft's cmdlet reference is more careful. AllowFederatedUsers defaults to True and users are "potentially" allowed to communicate with other domains. Your effective exposure depends on the allowed and blocked domain settings and on per-user external access policies. Check what your tenant actually does rather than assuming.

Settings worth reviewing in the Teams PowerShell module:

• AllowFederatedUsers. This is the tenant-wide master switch. Microsoft says that if it is False, users can't communicate with other domains regardless of the allowed or blocked lists.
• AllowedDomains and BlockedDomains. Each supports up to 4,000 domains. The blocked list only takes effect when the allowed setting is "allow all known domains." If you use a specific allow list, only those domains can communicate with your users. Prefer allow lists, since blocklists only stop known bad actors.
• ExternalAccessWithTrialTenants. Microsoft documents Blocked as the default. When Blocked, users from trial-only tenants can't reach yours through chats, Teams calls and meetings. They are also removed from existing chats. You can safelist specific trial tenants with AllowedTrialTenantDomains and keep the main setting Blocked.
• AllowTeamsConsumer and AllowTeamsConsumerInbound. Both default to True. Microsoft's example shows that enabling the first and disabling the second lets your users initiate contact with unmanaged Teams accounts. It stops those accounts from discovering or starting conversations with your people.
• AllowPublicUsers. Microsoft notes that Skype consumer interoperability with Teams is no longer supported and the parameter can no longer be used, starting May 5, 2025. KnowBe4's suggestion to evaluate this setting is therefore dated.

A caveat on subdomains​

KnowBe4 recommends Set-CsTenantFederationConfiguration -BlockAllSubdomains $True so that blocking a main domain also blocks its subdomains. Microsoft's reference shows an example using it alongside BlockedDomains. But the parameter is labeled as applicable to Skype for Business Online. Microsoft's example says it blocks subdomains such as subdomain.contoso.com but not a different domain like subcontoso.com. Test it in your environment before relying on it.

Blocking a single sender​

KnowBe4 describes a per-sender block in the Teams admin center. Go to Users > External access and turn on the option to block specific users from communicating with people in your organization. Select "Block a user," enter the email address or MRI, and apply. It says the list holds up to 200 users and can also be managed with Set-CsTeamsExternalAccessConfiguration. This is KnowBe4's description, so confirm the current interface in your tenant.

Microsoft also documents a delegation setting, SecurityTeamAllowBlockListDelegation. It lets your security operations team edit the blocked domains and users lists from the Defender portal. The default is Disabled.

User guidance that holds up​

The post's user advice is sound and short:

• Treat chat like email, including meeting chats.
• Check the "External" label before acting on anything claiming to be from support or leadership.
• Read an external message request before accepting it, and decline it if it's unexpected.
• Hover over links and read the real destination.
• Never start a remote session someone sends you. Route support through the help desk.
• Confirm payment changes by phone with a known contact.
• Report ransom notes and don't reply.
• Don't share passwords in chat.

If someone has already acted, KnowBe4's triage steps are to reset the password, revoke active sessions, look for remote-access tools they installed, and review any payment made. Fold those into your formal incident-response process rather than treating them as the whole playbook.

Bottom line​

This is a vendor blog, and it ends with a pitch for KnowBe4's products, including an unverified internal claim that 97% of users stop at a coaching prompt. The underlying point still holds. Teams is a phishing channel, and many organizations haven't extended their controls to it.

The most useful takeaway is the gap between policy and protection. Federation settings decide who can reach your users. Baseline warnings only warn. Safe Links needs Defender licensing and policy coverage. ZAP won't remove external messages from standard chats. An audit that checks each layer separately will tell you more than a blanket assumption that Defender has it covered.