Teams and Slack Phishing vs Email Phishing: Why Chat Attacks Bypass Email Controls

A phishing message that would be quarantined, banner-tagged and link-rewritten in email can arrive in a chat window with none of those protections, from a sender who looks like the help desk. Email security has had decades to build layered controls: sender authentication with SPF, DKIM and DMARC, secure email gateways, sandboxing, URL rewriting and a report button wired into the security operations centre. Chat platforms have different trust models, different enforcement points and different logs, and users trust a chat message more than an email. This guide compares phishing over Microsoft Teams and Slack with email phishing control by control: what each email layer does, what replaces it in chat, the external access settings that decide who can reach your users, how to detect chat phishing, and which user cues actually work. It is written for security architects, collaboration administrators and SOC leads. Platforms are listed alphabetically; order is not a ranking.

Key takeaways

• Email has a perimeter; chat has a policy. Email passes through a mail flow you can inspect before delivery. Chat between organisations is governed mainly by who you allow to connect, so the external access setting is the most important phishing control.
• There is no DMARC for chat. Sender identity in chat comes from the other organisation's tenant or workspace, and an attacker can register one with any display name. Verification means checking the organisation, not the name.
• Link and file protection works differently. In Teams, Microsoft Defender for Office 365 checks links at the time of click without rewriting them; in Slack, inspection is typically added through approved apps and enterprise APIs. Plan each explicitly rather than assuming email controls extend.
• The payoff is usually not the link. Documented chat campaigns end in a remote support session, an MFA code read aloud or a device code entered, so remote tool control and phishing-resistant MFA matter as much as message filtering.
• Reporting and logging must be wired up separately. A report-phish button in email does not cover chat; enable chat reporting and route chat audit data into the SOC.

Why chat phishing is different

Threat model

Email phishing is mostly cold and high volume: one message to many recipients, relying on a fraction clicking. Chat phishing is conversational. The attacker opens a one-to-one chat or call, responds in real time, and steers the target through a task: approve a sign-in, read out a code, start a screen share, install a "fix". ATT&CK models this as T1566 Phishing, specifically T1566.003 Spearphishing via Service for messages through third-party services and T1566.004 Spearphishing Voice for calls. When the sender is a compromised internal account, it becomes T1534 Internal Spearphishing.

Microsoft's October 2025 report on threats targeting Teams describes actors creating or buying tenants with custom domains and branding to impersonate internal help desk and IT support, using email bombing to create a reason for "IT" to get in touch, then requesting remote access that leads to remote monitoring and management (RMM) tools, credential theft and ransomware. The same report lists device code phishing disguised as Teams meeting invitations, malware delivered through chats and channels, and enumeration of tenants, users and external access settings with open source tools. The user-facing side of the help desk pattern is covered in the Email Bombing and Help Desk Impersonation over Teams Guide.

Why users trust chat more

• Context of the workplace: chat lives inside the tool where colleagues talk, so a message looks internal even when it carries an external label.
• Training gap: most awareness programmes have taught email cues (sender address, hover over links) for years and chat cues barely at all.
• Real-time pressure: a live conversation with a confident "support engineer" leaves no time to check, which is the point.
• Help desk precedent: many organisations do use chat for IT support, so an IT message in chat is not inherently strange.

Email controls and their chat equivalents

The table maps each layer of a mature email defence to what does the same job for cross-organisation chat. The right-hand column is where most organisations have gaps.

Email authentication itself is covered in the DMARC, SPF and DKIM Guide. The lesson for chat is that domain spoofing is replaced by look-alike organisations: an attacker does not need to forge your domain when they can register a tenant called "IT Support" and message your users from it.

External access settings by platform

Each platform below is described from its own documentation as of November 2026. These are customer-side settings under the shared responsibility model.

Microsoft Teams

• External access (federation): Microsoft documents that both the organisation setting and user policies are on by default, with all external domains allowed. Options are to allow only specific domains, block specific domains, or block all external domains. Blocking a domain does not block its subdomains unless Set-CsTenantFederationConfiguration -BlockAllSubdomains $True is set.
• Trial-only tenants: controlled by -ExternalAccessWithTrialTenants, documented as Blocked by default (Teams PowerShell module 6.4.0 or later). Keep it blocked.
• Unmanaged Teams accounts: separate settings control whether your users can chat with personal Teams accounts and whether those accounts can start conversations. Turning off the second means your users must initiate all contact.
• Blocked users: up to 200 specific external users can be blocked.
• Microsoft guidance: the October 2025 report recommends restricting external chat and meetings to allowed domains, blocking trial-only tenants and preventing unmanaged users from starting conversations.
• Availability: unmanaged Teams chat and Skype communication are not offered in GCC, GCC High, DoD or private cloud deployments.

See the Microsoft Teams Security Guide and the External Collaboration and Federation Abuse Guide for full configuration.

Slack

• Slack Connect DMs: Slack documents that, by default, members can start direct messages with people from other companies, and can both send and accept DM invitations. Owners (Workspace Owners, or Org Owners and Org Admins on Enterprise) can turn Slack Connect DMs off or restrict who can send and accept invitations.
• Verified organisations: on Pro and Business+ plans, members can accept invitations from any organisation by default and admins can limit acceptance to verified organisations; on Enterprise, members can by default only accept from verified organisations. Slack notes the setting does not stop members sending invitations to unverified organisations.
• Shared channels: only the organisation that owns a Slack Connect channel can invite or remove other organisations and manage posting permissions.
• External indicators: conversations with external organisations show a banner, are grouped in the External Connections section of the sidebar, and external profile photos display the other organisation's icon.
• Apps: Workspace Owners can turn on app approval and keep approved and restricted app lists. Apps added by another organisation in a shared conversation show that organisation's icon.
• Availability: Slack Connect channels require every organisation to be on a paid plan; DMs with external people are available on any plan; verified organisation controls need a paid plan; the Audit Logs API needs an Enterprise plan.

See the Slack Enterprise Security Guide and How to audit Slack apps, bots and tokens.

Choosing a chat exposure model

Small organisations: an allow list of the few partners you chat with is easy to keep and removes most risk. Large organisations: start with guardrails (block trial and unmanaged, verified only), measure which external organisations are actually used for a month, then move to an allow list with a request process. Apply stricter models to IT support and finance staff first, because they are the personas attackers impersonate or target.

Implementation: a phased rollout

1. Inventory: export current external access settings, the list of external organisations your users have chatted with over the last 90 days, and installed third-party apps.
2. Quick wins: block trial-only tenants and stop unmanaged accounts starting conversations (Teams); restrict Slack Connect invitations to verified organisations and limit who can send and accept invitations (Slack). Turn on app approval.
3. Link and file protection: enable Safe Links and Safe Attachments coverage for Teams where licensed; for Slack, decide which approved security or DLP app inspects shared links and files, and confirm its coverage of Slack Connect conversations.
4. Reporting: turn on both Teams reporting settings (the messaging policy in the Teams admin center and the user reported settings in the Defender portal) and route reports to the SOC mailbox; in Slack, publish a single reporting route (for example a workflow or channel owned by security) and teach it.
5. Pilot an allow list with one business unit, using the 90-day partner list. Monitor blocked contact attempts and access requests for two to four weeks.
6. Roll out by risk tier: IT support, finance and executives first, then the rest of the organisation.
7. Rollback: keep the previous configuration exported. If a critical partner is cut off, add that partner to the allow list rather than reopening the whole tenant or workspace.

Removing the payoff

Message controls reduce exposure; they do not stop every lure. The documented chat campaigns succeed at the next step, so close those as well:

• Remote support tools: block or remove remote assistance tools you do not use and allow only the sanctioned RMM. Microsoft's report advises disabling Quick Assist if unused. See the RMM Tool Security Guide and Detecting RustDesk, MeshCentral and Tactical RMM Abuse; ATT&CK tracks this step as T1219 Remote Access Tools.
• Phishing-resistant MFA: codes read aloud and approved pushes are what chat social engineers ask for. FIDO2 and passkeys remove that option. See the Device Code Phishing Guide for the device code variant.
• Help desk process: publish how real IT support contacts users (internal accounts only, never from an external organisation) and how users can verify a request.

Where identity fits

Chat platforms are full of non-human identities: bots, apps, webhooks and API tokens. A malicious or over-permissioned app can post messages that look trustworthy inside internal channels, and a stolen user token turns an internal account into a phishing sender that inherits colleagues' trust. In the Uber Breach 2022, the attacker used compromised employee access to reach Slack and posted in a company-wide channel. Review app scopes and tokens as part of chat phishing defence; see How to find secrets in Slack and Teams messages.

Detection and measurement

What to log and hunt

• Microsoft Teams: Microsoft's October 2025 report recommends verifying audit logging, using Defender for Cloud Apps activity policies and hunting in the MessageEvents, MessagePostDeliveryEvents, MessageUrlInfo, UrlClickEvents and CloudAppEvents tables. User reports raise default alerts such as "Teams message reported by user as a security risk".
• Slack: the Audit Logs API (Enterprise plans) provides read-only audit events, each with an actor, action, entity and context, such as user_login with IP address and user agent, and app events carrying the app's ID, name and scopes. It covers actions, not message content, and does not itself judge whether an action was appropriate, so detections are built in the SIEM.
• Cross-platform hunts: first contact from an external organisation whose display name contains "help desk", "IT", "support" or "security"; external contact followed within an hour by a remote access tool launch or a new MFA method registration; a burst of inbound subscription email (email bombing) followed by an external chat to the same user.

Metrics

• Percentage of users reachable by any external organisation (target: falling to the allow-listed population).
• Number of first-contact external chats per week, and share from organisations not on the partner list.
• Chat phishing reports per month and median time from report to containment.
• Click or engagement rate in chat-based phishing simulations, compared with email simulations.
• Remote access tool launches following external chat contact (target: zero unsanctioned).

User cues that work

Add chat scenarios to the Phishing Simulation Programme Guide cycle, and train IT support and finance staff on the help desk pretext used by groups such as those in the Scattered Spider Threat Actor Profile.

Framework mapping

Common failure patterns

• Assuming the email stack covers chat: the gateway, banner and report button are all email-only; chat arrives through a different path.
• Leaving default external access in place: open federation or open external DMs lets any newly registered organisation contact any user.
• Blocking domains one at a time: attackers register new tenants faster than a block list grows; allow lists scale better.
• Training only email cues: users who know to hover over email links still accept a chat from "IT Support" and share their screen.
• Filtering messages but not the payoff: unrestricted remote support tools and push or code MFA leave the attacker a clear path once the lure lands.
• No chat logs in the SIEM: without audit data, a first-contact help desk lure is invisible until the ransomware alert.

Decision checklist

• Can any external organisation start a chat with any of your users today?
• Are trial tenants, unmanaged accounts and unverified organisations blocked where the platform supports it?
• Is link and file inspection in place for chat, and does it cover external conversations?
• Can users report a chat message to the SOC in two clicks, and does someone triage it?
• Are remote support tools restricted to the sanctioned RMM?
• Do chat audit events reach the SIEM with detections for help desk impersonation?

Practitioner checklist

• Export and review external access and external DM settings on every chat platform in use.
• Block trial-only tenants and stop unmanaged accounts initiating chats in Teams.
• Limit Slack Connect invitations to verified organisations and restrict who can send and accept them.
• Move to a partner allow list, starting with IT support, finance and executive users.
• Enable time-of-click link checking and file scanning for chat where licensed or via approved apps.
• Turn on in-chat reporting and route it to the SOC.
• Restrict remote support tools and move high-risk users to phishing-resistant MFA.
• Add chat lures to phishing simulations and awareness content.

Standards and references

• Microsoft Security Blog: Disrupting threats targeting Microsoft Teams
• Microsoft Learn: Manage external meetings and chat with people and organisations using Microsoft identities
• Microsoft Learn: Safe Links in Microsoft Defender for Office 365
• Microsoft Learn: User reported message settings in Microsoft Teams
• Slack Help Center: Slack Connect guide, work with external organisations
• Slack Help Center: Manage settings and permissions for Slack Connect direct messages
• Slack Help Center: Security recommendations for approving apps
• Slack Developer Docs: Audit Logs API

Related NHI Mgmt Group resources: Phishing Guide, Collaboration Tool Security Guide, External Collaboration and Federation Abuse Guide, Vishing and Help Desk Social Engineering Awareness Guide, Microsoft Defender for Office 365 Configuration Guide.