Treat the channel change as part of the attack, not a separate event. Once email noise is used to suppress alerts, impersonation in chat can push victims toward unsafe actions such as remote access or credential reset. Security teams should extend verification, monitoring, and user guidance across all communication channels.
Why channel switching changes the attack, not just the delivery method
When an attacker moves from email to Microsoft Teams or Slack, the core problem is usually social engineering with a different transport layer. The goal is still to create urgency, bypass normal caution, and push the target into a bad action, often before the victim has time to verify who is asking. Security teams should treat the channel shift as continuation of the same intrusion path, not as a separate nuisance.
That matters because many defenders still tune controls around inboxes, phishing filters, and email reporting. Once the conversation moves into chat, the attacker can exploit the perceived informality of collaboration tools, the speed of response, and the assumption that an internal-looking message is automatically safer than email.
Teams should also assume the attacker may be working around detection by moving into a channel where security review is weaker or where users are more likely to act on a request without stopping to validate it. A successful campaign often blends pretext, timing, and platform trust rather than relying on a single compromised account.
How Teams and Slack impersonation turns into unsafe action
The most common failure mode is not the chat message itself, but the next step it triggers. A fake help desk, coworker, manager, or IT support message can steer a user toward a remote access session, a password reset, an MFA approval, or disclosure of a one-time code. That is why verification procedures need to follow the user, not just the mailbox.
Teams and Slack also create opportunities for rapid trust transfer. If the attacker can reference a real project, a plausible ticket, or recent internal activity, the message feels operational rather than suspicious. The result is often an action taken under pressure, with the user believing they are following a legitimate internal process.
Defenders should look for the sequence, not only the message. A chat request that asks for credentials, pushes a reset workflow, or asks the user to open a screen-sharing or remote support session is materially more dangerous than ordinary spam because it can become immediate account compromise or lateral movement.
What changes in detection, verification, and user guidance
Monitoring must extend beyond email to collaboration platforms, especially for messages that imitate support, security, or leadership. Chat telemetry, audit logs, identity events, and user-reported messages should be reviewed together so that suspicious activity is visible across the full conversation path. That is especially important when an attack uses email first to create noise and chat second to achieve the action.
Verification guidance should be platform-agnostic. Users need a rule that any request to change credentials, approve access, install software, or start a remote session must be validated through an out-of-band channel that is pre-agreed and difficult to spoof. If that rule only exists for email, the attacker will simply move to Teams or Slack.
Security teams should also align response playbooks across communications tools. A report from chat should trigger the same triage as a report from email: preserve the conversation, identify the sender, check for impersonation, review sign-in and session activity, and search for similar lures sent to other users. That reduces the chance of treating the chat message as a minor messaging issue when it is actually part of a broader compromise attempt.
Risk and Threat Considerations
Channel hopping is effective because it exploits trust in internal collaboration tools and the human tendency to downgrade scrutiny outside the inbox. If the organisation only hardens email, attackers can still reach users where urgency, familiarity, and informal workflow make unsafe actions more likely.
Failure mechanism: The attacker uses one channel to establish confusion or legitimacy, then uses Teams or Slack to push the victim into granting access, approving authentication, or disclosing secrets before normal verification happens.
Impact: The result can be account takeover, remote access abuse, credential reset abuse, or a wider compromise path that moves from social engineering to identity and session control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Chat impersonation is a phishing delivery path used to trick users into unsafe actions. |
| T1078 — Valid Accounts | If the lure succeeds, the attacker often pivots into existing accounts and sessions. | |
| Recommendation — Map Teams and Slack impersonation to phishing detections and hunt for follow-on credential theft or access abuse. Monitor for valid-account abuse that follows chat-based impersonation and urgent credential-reset requests. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | Channel-spanning impersonation often seeks credential reset or access approval. |
| Recommendation — Extend verification and access workflows to collaboration tools and require out-of-band confirmation for high-risk requests. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | Cross-channel impersonation needs coordinated reporting, triage, and response playbooks. |
| Recommendation — Include Teams and Slack impersonation in incident handling, user reporting, and escalation procedures. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | A user tricked in chat may misuse privileged non-human access or secrets on the attacker’s behalf. |
| Recommendation — Prevent users from disclosing or relaying secrets and access actions through chat-based requests. | ||
| OWASP API Security Top 10 | API2 Broken Authentication — Broken Authentication | Impersonation campaigns frequently aim to steal or bypass authentication material. |
| Recommendation — Treat stolen codes, tokens, and reset flows as authentication failures, not just messaging abuse. | ||
Practitioner Guidance
What to prioritise: Treat chat channels as first-class attack surfaces in your phishing and impersonation program. If you only train users and tune detections for email, you leave the most convenient follow-on channel uncovered.
What to verify: Confirm that help-desk, security, and executive impersonation scenarios are being logged, triaged, and investigated across Teams, Slack, and email with the same escalation criteria. The key question is whether a request that looks internal can still be independently verified before any action is taken.
Decision rule: If a message asks for a credential reset, MFA approval, remote support, or urgent access change, require out-of-band confirmation regardless of channel. If the requester pressures the target to skip that step, treat the request as hostile until proven otherwise.
Practitioner takeaway: The control objective is not to make chat less convenient, it is to make every high-risk request independently verifiable before a user can turn a message into access.
Related resources from NHI Mgmt Group
- How should teams respond when CI or developer secrets are exposed?
- How should teams respond when a secret is found in a support ticket?
- How should teams respond when a service account token is exposed?
- What happens when attackers start in email and then continue the attack in collaboration platforms like Slack or Teams?