AI Quick Answer
Slack workspace invite phishing is a B2B credential-theft attack where a fake email mimics a Slack invite ("You have been invited to join [Company] on Slack") and links to a lookalike Slack login page on an attacker-controlled domain. The user signs in with their corporate SSO email and password, sometimes approves a Slack OAuth consent screen, and the attacker captures the credential plus any granted token. Treat Slack invites with the same scrutiny as Microsoft 365 sign-in prompts: never click the email button, type slack.com directly, accept the invite from within the app, and route any "Slack admin needs help" message through your IT ticket queue.
The play, end to end
Subject line: "You've been invited to join Acme Corp on Slack" or "Sarah Chen invited you to a Slack workspace." The body carries the familiar Slack masthead, a purple "Join Now" button, and a footer reading "If you have any questions, contact Slack at slack.com." Modern kits embed the inviter's actual headshot pulled from a public LinkedIn profile and reference the recipient's real employer in the workspace title.
The click does not open Slack. It opens a credential-harvest page styled like the Slack workspace sign-in screen, with the purple gradient, "Continue with SSO" button, and a workspace URL prompt. The login URL sits on a lookalike domain (slack-team.com, slackworkspaces.app, slack-invite.co), a free cloud bucket (storage.googleapis.com/slack-invite/, web.app, pages.dev, r2.dev), or an HTML smuggling page inside a SharePoint share. The user types their corporate SSO email and password, and on AiTM kits completes the live MFA prompt the attacker is relaying. The session cookie lands in the attacker's tool. Variants that target Slack directly prompt an OAuth consent ("Workspace Joiner wants permission to read your messages and channels"); a single click grants a long-lived token that survives password changes.
Within minutes the attacker is logged into either the user's SSO console or the captured Slack workspace. SSO compromise unlocks Outlook, Salesforce, GitHub, AWS, and every other federated app. Slack compromise unlocks DM history, private channels, integration tokens pasted into #engineering last quarter, and the ability to send convincing DMs from a trusted identity. Lateral phish to ten coworkers and the compromise compounds.
Common invite-email templates in active rotation
1. The "[Company] invited you" boilerplate
"Acme Corp invited you to join their Slack workspace. Click Join Now to accept." The company name is pulled from the recipient's employer or a known business partner. Click-through is high because external workspace invites are a normal weekly occurrence.
2. The "[Inviter Name] mentioned you" variant
"@Sarah Chen mentioned you in a thread in #project-launch. Open Slack to reply." Suggests an existing relationship and a missed message. The inviter is often a real coworker or LinkedIn connection. Skips the workspace-invite framing and lands directly on the lookalike login page.
3. The "your invitation expires soon" urgency template
"Reminder: your invitation to the Acme-Vendors workspace expires in 24 hours." CISA's social-engineering guidance for the workforce lists artificial urgency as the single most reliable manipulation signal.
4. The "new member needs your approval" admin lure
Targets workspace owners and admins. "Sarah Chen requested to join the Acme Corp workspace. Approve or decline." Owner compromise is much higher impact because owners can mint admins, install workspace-wide apps, and export message history.
5. The compromised real invitation from a partner
Most dangerous variant. The attacker compromises a real partner workspace and sends an actual Slack invite from it. DKIM and SPF pass. The link goes to slack.com. The catch is inside the workspace: a pinned message linking to the attacker's lookalike "shared drive", or a DM from a fake admin asking the new member to "verify your SSO".
The "Slack admin needs your help" social-engineering variant
A separate pattern targets users already inside a workspace. The attacker creates a Slack account with a display name reading "Slack Admin", "Workspace Helper", or the name of the company's IT lead, then direct-messages employees: "We're seeing an SSO sync issue with your account. Can you confirm by signing in here?" The link goes to a lookalike SSO page.
This works inside Slack Connect channels too, where external collaborators from other workspaces appear alongside internal teammates. A user named "Acme IT Support" in a shared channel does not need to be from Acme; Slack Connect federates the workspaces, not the identities. Common pretexts: "your account will be locked in 24 hours", "we need to migrate you to a new workspace", "compliance audit, please verify your access". CISA's collaboration-platform guidance for the workforce explicitly calls out cross-workspace impersonation as a recognized pretexting pattern.
Why Slack is a high-value target for attackers
- Slack is real and constantly active. 65M+ daily active users across 200,000+ paid organizations. The invite notification is something users genuinely receive most months.
- Secrets live in DMs. Engineers paste API tokens to debug. Finance shares bank account numbers in private channels. HR shares employee data. Slack's security blog has repeatedly warned about secrets-in-Slack, and IR writeups document attacker dwell time in workspaces specifically to harvest them.
- Lateral movement is trivial once inside. A phish from "Mike in finance" via Slack DM is far more likely to be clicked than the same phish from a cold external email. The Verizon DBIR 2024 noted collaboration-platform compromise as a ransomware lateral-movement accelerator.
- SSO unlocks downstream applications. If the credential captured is the corporate SSO password, every federated app from email to source code to cloud infrastructure becomes accessible.
- OAuth tokens persist beyond password reset. Rotating the user's password does not revoke the OAuth token. Defenders who treat this as a "change the password" incident miss the actual persistence mechanism.
Lookalike domains used in active campaigns
The defining technical signal is the lookalike landing-page domain. Real invites send recipients to workspacename.slack.com. Patterns observed in the wild that are not Slack:
slack-team.com,slack-teams.com,slackteam.appslack-invite.co,slackinvite.org,slack-invites.comslack-workspaces.app,slackworkspace.iosl4ck.com,s1ack.com,slаck.com(Cyrillic а)slack-signin.com,slack-login.app,slack-auth.co- Free-host paths like
storage.googleapis.com/slack-invite/,slack-invite.web.app,slack-workspace.pages.dev,slack-team.r2.dev
The word "slack" is always present but concatenated with a hyphen, extra word, or near-glyph substitution. Real Slack URLs put "slack" as the apex domain, only the workspace name as a subdomain.
How SafeBrowz blocks this threat
SafeBrowz runs a 3-layer detection architecture: Local + APIs + AI.
- Layer 1 - Local detection: 60+ URL patterns plus 550+ brand-specific signatures (Slack included, with Cyrillic and Punycode homograph variants) plus community whitelist and blacklist, all running in the extension before the page renders. Catches slack-team.{tld}, slack-invite.{tld}, slack-workspaces.{tld}, and free-host paths instantly, plus brand-impersonation where a non-Slack domain renders a Slack-styled sign-in form.
- Layer 2 - API checks: aggregates Google Safe Browsing, PhishTank, URLhaus, ScamAdviser, and 30+ scam TLDs for known malicious domains.
- Layer 3 - AI deep scan (Premium): 100+ language content analysis catches novel variants in seconds, including OAuth-consent-page lures where the URL sits on a benign host but the page requests unusual workspace permissions under a Slack-styled banner.
Detection signatures come from threat-intelligence research and brand database analysis, not from user browsing data. Per-user URL history is never stored.
The 8 red flags in a fake Slack invite
- Sender domain is not slack.com. Real invitations come from
no-reply@slack.comwith SPF, DKIM, DMARC all passing on slack.com. Anything fromslack-team.com,slack-invites.co, or a personal Gmail or Outlook account is fake. - Workspace URL is not on slack.com. Real invitations link to
workspacename.slack.com/join/shared_invite/.... Any other domain in the visible URL or underlying href is phishing. - Unexpected workspace from an unfamiliar company. Legitimate cross-company workspaces are preceded by an email, call, or contract. An out-of-the-blue invite from an unknown company is spam at best, phishing at worst.
- Urgency framing. "Your invitation expires in 24 hours." Real Slack invitations remain valid for 30 days by default and Slack does not send aggressive countdown reminders.
- SSO sign-in shown immediately upon clicking. Real flows briefly land you in Slack's sign-up or workspace selector first. A flow that routes straight to a Microsoft 365, Okta, or Google Workspace login page before showing any Slack interface is a credential-harvest funnel.
- URL bar shows a lookalike or cloud-bucket host. The URL bar should read
slack.comorapp.slack.com. Anything else, close the tab. - OAuth consent asking for unusual permissions. A legitimate workspace join never requests "read all your messages and channels" as an OAuth scope. Decline and report.
- Display name and email mismatch. "From" reads "Sarah Chen" but the actual sender is
noreply@slack-invitations.com. Expand the header to reveal the mismatch.
How to verify a real Slack invite in 60 seconds
- Do not click the email button. Open a fresh browser tab.
- Type
slack.comdirectly and sign in. Pending invites appear in your workspace switcher under "Other workspaces" or as an in-app banner. If the invite is not visible inside Slack itself, the email is fake. - Contact the supposed inviter on a separate channel. Phone, text, or Teams message. A 10-second "Did you invite me to a Slack workspace?" defeats almost every variant.
- Forward suspected phishing to
feedback@slack.comand to your IT security inbox.
What to do if you already clicked and signed in
Speed matters. AiTM kits sweep the captured session cookie within seconds, install OAuth persistence within minutes, and begin lateral DMs within the hour. The next 30 minutes decide whether this becomes a footnote or a full incident.
- Notify your Slack workspace admin immediately. They can force-revoke your active sessions from the admin console (Settings and administration, then Manage members, then Sign out of all sessions) and temporarily deactivate the account.
- Rotate your SSO password. If the credential captured was your corporate SSO password, every federated app is exposed. Change it in Okta, Azure AD, Google Workspace, or whichever identity provider you use.
- Enable hardware-key or passkey MFA. Phone-prompt and SMS MFA do not defeat AiTM phishing. Hardware keys (YubiKey, Titan) and passkeys do because the cryptographic challenge is bound to the real domain. See how AiTM session-cookie theft defeats 2FA.
- Revoke OAuth tokens granted by your account. Slack Profile, then Preferences, then Connected accounts. Revoke anything you do not recognize. Workspace owners should also audit the app directory.
- Force sign-out of all Slack sessions. From your profile, choose Sign out of all sessions. Invalidates any stolen cookie.
- Review your Slack DM history for outgoing messages you did not send. Flag unfamiliar outgoing DMs so recipients can be warned.
- Audit your SSO recent sign-in activity. Look for sign-ins from unfamiliar countries, IPs, or devices in the hour after you submitted credentials.
- Notify your IT security team formally. Even if remediated, file a ticket so the team can push IOCs to the email gateway and warn other employees.
Org protection guide for Slack workspace owners and admins
Most controls that defeat Slack invite phishing live in the Slack admin console plus the upstream SSO identity provider.
- Enforce SSO and disable Slack-managed passwords. Narrows the credential-theft surface to the SSO provider, where your hardware-key MFA already lives.
- Require session re-authentication every 14 to 30 days. Limits the persistence window of any stolen session cookie.
- Restrict workspace invitations to admins only. By default any member can invite external users. Tighten this.
- Audit the Slack app directory quarterly. Workspace-installed apps hold OAuth tokens with broad scope. Revoke unused apps and require admin approval for new installs. Slack's security blog at slack.com/blog/security covers app-review guidance.
- Restrict Slack Connect to trusted domains. The "Slack admin needs your help" pretext is significantly harder when the attacker cannot inject themselves into your shared channel.
- Enable enterprise audit logs and forward to your SIEM. Alert on anomalies (sign-in from new country, broad OAuth scope grants, mass DMs in a short window).
- Mandate hardware-key or passkey MFA at the SSO layer. Phone-prompt MFA does not stop AiTM. Hardware keys and passkeys do. Roll them out to executive, finance, engineering, and IT staff first.
- Train the workforce on collaboration-platform phishing. Add Slack-invite, Teams-invite, and Slack Connect impersonation scenarios. CISA's workforce social-engineering guidance covers the threat model.
- Add browser-layer scanning to every employee browser. The gateway often cannot block the email when the sender domain authenticates. SafeBrowz Business blocks the credential-harvest page before any form loads.
Why email authentication alone does not save you
- Lookalike domains authenticate.
slack-team.comsets up valid SPF, DKIM, DMARC. The gateway confirms the domain; it just is not Slack. - Compromised-partner variants pass natively. A real invite from a real compromised partner workspace passes everything because it is genuinely Slack infrastructure. The malice is in what happens after the user joins.
- AiTM defeats phone-prompt and SMS MFA. The attacker proxies the live SSO prompt and captures the session cookie even when MFA was performed correctly. Only hardware-key and passkey MFA defeat this.
- OAuth consent bypasses passwords entirely. Once a malicious app holds a Slack OAuth token, that token is valid regardless of password changes. Remediation without revoking OAuth grants leaves persistence in place.
Where browser-layer defense fits in the stack
The gateway often cannot block the message. Slack-themed lures originate from authenticated lookalike domains, from free email providers, or from compromised Slack workspace accounts (genuinely from Slack). Browser-layer scanning catches the next step. When a Slack-styled sign-in page renders on a non-slack.com domain, a brand-aware scanner identifies the impersonation before any form loads. SafeBrowz is a free Chrome, Firefox, and Edge extension that scans every URL before render against a 550+ brand database (Slack and major SSO providers included). SafeBrowz Business adds CSV-exportable threat reports so IT teams see org-wide Slack-themed impersonation attempts. Install SafeBrowz and pair it with the verification workflow above.
Frequently asked questions
What domain do real Slack workspace invite emails come from?
Real Slack invitations come from no-reply@slack.com with SPF, DKIM, DMARC all passing on slack.com. The visible workspace URL points to workspacename.slack.com/join/shared_invite/.... Anything from slack-team.com, slack-invites.co, slack-workspaces.app, or a personal mailbox is fake.
I clicked the Slack invite link but did not enter my password. Am I safe?
Probably yes, but verify. Close the tab, run an endpoint scan on managed devices, check your SSO recent sign-in activity for the past hour, and enable hardware-key or passkey MFA. Phone-prompt MFA is no longer sufficient against AiTM phishing.
The invite came from a Slack workspace belonging to a real partner. Is it still phishing?
Possibly. The compromised-partner variant uses a real workspace whose admin credentials were phished earlier. The invite passes every technical check because it is genuinely Slack infrastructure. The signal is what appears inside the workspace once you join: pinned messages linking to attacker-controlled sites, fake admin DMs asking you to verify your SSO, or unusual OAuth app installations.
How do I report a Slack workspace invite phishing email?
Forward the full email with headers to feedback@slack.com and to your internal IT security inbox. Slack works with registrars to file takedowns of impersonating infrastructure.
Does enabling MFA stop Slack workspace phishing?
Phone-prompt and SMS MFA do not stop AiTM Slack phishing because the attacker proxies the live MFA prompt and captures the session cookie that authenticates after MFA succeeds. Hardware keys and passkeys do stop it. Roll them out at the SSO layer for executive, finance, engineering, and IT staff first.
What is the worst-case impact if an attacker captures a Slack session for one employee?
Worst case includes DM history exfiltration (containing API tokens, bank account numbers, personal data), lateral phishing to the victim's coworkers from a trusted identity, OAuth token persistence on workspace apps, secrets harvesting from private channels, and use of the foothold as initial access for ransomware. The Verizon DBIR 2024 documented collaboration platforms as a fast-growing initial-access vector.
How do I configure Slack to make workspace invite phishing harder to succeed?
Enforce SSO and disable Slack-managed passwords, require hardware-key or passkey MFA at the SSO layer, restrict invitations to admins only, audit the app directory and OAuth grants quarterly, forward enterprise audit logs to your SIEM, restrict Slack Connect to trusted domains, set session timeouts at 14 to 30 days, and run Slack-invite phishing scenarios in training. Slack's security blog at slack.com/blog/security publishes the latest guidance.
Will cyber insurance cover a Slack-initiated incident?
Often yes, but conditionally. Most BEC riders require documented MFA enforcement on identity providers, segregation of duties on wires, and recent social-engineering training. Carriers increasingly deny claims where the insured cannot evidence those controls. File same-day as discovery.
Related reading
- DocuSign phishing scam: how fake signature requests steal business credentials
- The $2.3M wire transfer email scam that targets only CEOs and CFOs
- How attackers profile you on LinkedIn before sending phishing
- MFA fatigue and push-spam attacks: how attackers wear users down
Bottom line: Slack workspace invite phishing wins because employees are paid to join Slack workspaces. The defense is not "stop clicking" but "verify before signing in." Type slack.com directly, deploy hardware-key or passkey MFA at the SSO layer, audit OAuth grants quarterly, and put SafeBrowz on every employee browser so the credential-harvest page never loads.