How Phishing Simulations Work in Slack and Teams

The trust problem inside collaboration platforms is real and measurable. When an email arrives from an unknown sender, most employees apply at least some skepticism. When a Teams DM arrives from "IT Support" or a Slack message appears from what looks like Slackbot, that skepticism largely disappears. Employees treat these messages as internal communications by default, and attackers exploit that assumption deliberately.

Inside these platforms, attackers rely on a few well-documented vectors. Malicious links wrapped in urgent requests are designed to push employees to act before they think. Impersonated bots or IT accounts carry the visual credibility of an internal tool. And legitimate platform features get turned against users: Microsoft Teams External Access, for example, is enabled by default across all Microsoft 365 tenants, which means external senders can contact your employees directly without any prior approval. Attackers use compromised .onmicrosoft.com domains to send messages that appear inside your organization's workspace. Teams does display an "(External)" tag on these messages, but research consistently shows employees ignore it when the sender claims to be an IT function or a known vendor.

A security program that tests only email leaves employees with a dangerous blind spot. They build the muscle memory to question a suspicious email, but they never develop the habit of scrutinizing a Teams chat or Slack DM that asks them to verify credentials urgently. That unaddressed gap is where real breaches happen.

Understanding how phishing simulations work in Slack and Microsoft Teams starts with understanding what real attackers actually send, because a simulation that does not faithfully replicate those patterns produces behavioral data that does not reflect real-world risk.

Crafting Realistic Teams Lures

A well-designed Teams phishing simulation mirrors the exact patterns real attackers use. The simulated message comes from a sender identity that looks like your IT team or a known vendor, carries an urgency trigger such as "Your account access expires in 2 hours," and contains a credential-harvest link pointing to a realistic-looking login page. The most effective simulations replicate the external-sender pattern: the message appears with the subtle "(External)" badge, training employees to recognize and act on that visual cue rather than ignore it. This is the foundation of any credible in-app phishing simulation for Teams. Real-world examples of attacker lures, such as fake IT helpdesk messages impersonating internal support, illustrate how convincing these messages can be; security teams should study these patterns when designing tests.

Crafting Realistic Slack Lures

Slack simulations require a different approach, and it is worth understanding why. True bot-injection via legacy webhooks is a documented attack vector: attackers who obtain a valid legacy Slack incoming webhook can send messages directly to employee DMs while spoofing the Slackbot identity. Legitimate simulation vendors do not replicate this capability directly. Instead, well-designed Slack security simulations focus on training employees to recognize lure patterns, suspicious link formats, and urgent-request language that arrive through their normal workflow. A realistic Slack phishing test might look like a fake shared-document notification from a "manager," a spoofed IT bot requesting MFA re-enrollment, or an urgent message about a pending wire transfer.

Across both platforms, two psychological mechanics drive every successful lure: artificial urgency and authority impersonation. Role-adaptive platforms like HookPhish go further by customizing the lure to match each employee's job function. A finance team member receives a fake invoice approval request; an IT admin receives a credential-harvest alert about a software vulnerability. The specificity is what makes the training stick.

The seconds immediately after a click represent the most valuable teachable moment in any phishing simulation. The employee is primed, they just realized they may have made a mistake. Redirecting them to a generic "you failed this test" page wastes that window entirely. The right response is an immediate, targeted micro-lesson that explains exactly which red flag they missed, shows them the specific cue in the message, and wraps up in under two minutes.

HookPhish is built around this principle. When an employee clicks a simulated lure inside Slack or Teams, the platform intercepts that click and delivers a role-specific training module inside the same channel where the lure appeared. The context stays intact, attention is high, and the lesson is directly tied to the mistake that just happened. A finance employee who clicked a fake invoice approval sees a debrief on wire-transfer fraud patterns. An IT admin who clicked a Microsoft Teams phishing payload link sees a breakdown of how attackers spoof admin portals. This is the difference between a simulation that generates data and one that changes behavior.

Good simulation design also accounts for employees who do not click. Non-clickers should receive confirmation through the same channel that they correctly identified the lure. This positive reinforcement matters. Building safe habits requires rewarding the behavior you want to see, not just catching the behavior you want to eliminate. Employees who pass consistently become the informal security advocates who help shift team culture over time.

No simulation should go live without executive sponsorship, HR alignment, and a clearly documented ethics charter. HR needs to be looped in before day one so they can manage employee inquiries and frame the exercise as skill-building rather than surveillance. Your ethics charter should explicitly state that simulation outcomes will not feed into performance reviews, disciplinary records, or manager-level reports on individual employees. In regulated environments, a Legitimate Interest Assessment is required under GDPR if employee interaction data will be processed. U.S. organizations operating under HIPAA, the FTC Safeguards Rule, or PCI DSS should also document the simulation's educational purpose and maintain records of participation rates and follow-up training as evidence of reasonable security measures.

Some lure topics are off-limits entirely. Fake termination notices, health emergency alerts, and messages mimicking family crises cause genuine psychological harm and destroy the trust that makes your security program viable. Define these boundaries in writing before your first simulation goes out, a one-page simulation policy or charter sign-off that documents prohibited scenarios gives you a clear record and sets expectations across HR, legal, and leadership. The goal is building skill, not manufacturing stress.

On the technical side, complete these steps before launch. Allowlist simulation domains in your email gateway and endpoint security tools so simulated links are not blocked before employees ever see them. Confirm that Teams External Access settings permit your simulation sender. Notify your SOC so that legitimate security reports from employees who flag the simulation as suspicious are handled as program feedback rather than triggering a full incident response. For details on how external users and guest access work (and the configuration nuances to watch for), see guidance on Microsoft Teams external users and guest access. These setup steps are easy to overlook and expensive to skip.

Four numbers form the foundation of any meaningful collaboration-platform simulation program. Click rate measures the percentage of employees who clicked the lure. Reporting rate measures the percentage who flagged the message as suspicious before or instead of clicking. Time-to-report tracks how quickly employees identify and surface a lure to your security team. Repeat-offender rate tracks employees who click across multiple simulation rounds despite prior training.

Why Distribution Beats Averages

Distribution matters more than averages, and this is a point most security teams miss. A 12% click rate where the same five employees fail every simulation points to a fundamentally different problem than a 12% rate distributed randomly across the workforce. The first scenario signals that specific individuals need a different training approach or closer manager attention. The second suggests a broadly distributed awareness gap that requires program-wide changes. Reporting averages without examining the underlying distribution leads to decisions that look data-driven but miss the actual problem.

A single simulation produces a data point. A program produces a trend. Plot click rates and reporting rates per team and per role across successive simulation rounds. The metric that proves your program's value to a board or executive leadership is a measurable downward trend in clicks paired with an upward trend in reporting. HookPhish translates these behavioral trends into a unified human risk score per employee and team, giving security leaders a board-ready number that shows exactly how much risk has been reduced since the program started, rather than a raw list of who clicked what.

See our Customer Case Studies & Results for concrete outcomes and real-world examples of behavior change tracked over time.

The first question to ask any vendor claiming Slack and Teams support is whether lures are delivered natively inside those channels or whether "support" means sending follow-up training emails after a simulated email campaign. These are very different things. Native delivery means the simulation message appears inside the collaboration platform itself, using the same interface patterns employees interact with every day. Follow-up email notifications do not train employees to be vigilant inside Slack and Teams; they add another email to ignore.

When evaluating how phishing simulations work across Slack and Teams in a given platform, look for these capabilities. Role-adaptive simulation content should customize the lure to each employee's job function and risk level. Instant in-channel teachable moments should deliver training at the exact moment of the click, not the next morning in a follow-up email. And reporting should tie click behavior to team-level and individual risk scores over time, not just a one-time snapshot. Some platforms offer email simulations with optional Teams notifications bolted on afterward. That is a fundamentally different architecture from a platform designed from the ground up for multi-channel delivery.

If you want a vendor designed specifically for this multi-channel architecture, review our Cybersecurity Solutions for Modern Teams.

HookPhish is built for exactly this problem. Its AI generates role-adaptive lures delivered natively across Slack, Teams, and email. When an employee clicks, the teachable moment appears inside the same channel immediately. The platform tracks behavior across every simulation round and surfaces the results as a unified human risk score that security leaders can present to boards, use as compliance evidence under NIS2 and ISO 27001, and act on to prioritize which teams need additional training. It is one of the few architectures designed from the ground up to close the collaboration-platform gap rather than patch around it.

Phishing has moved into Slack and Teams because that is where employees are most trusting and least vigilant. A security awareness program that ignores these channels is not just incomplete, it actively teaches employees that the most dangerous messages they will ever receive all look like suspicious emails. That lesson is wrong, and attackers know it.

The playbook is straightforward once you understand how phishing simulations work in Slack and Teams. Learn the lure mechanics specific to each platform. Set up simulations with proper legal, HR, and technical groundwork before you launch. Deliver training at the moment of the click, inside the channel where the click happened. Measure behavior change over time using click rates, reporting rates, and repeat-offender patterns, not completion rates and one-time snapshots.

HookPhish runs this entire cycle natively across Slack, Teams, and email, turning every simulated click into a building block for a more resilient workforce. If your current program does not test the channels where your employees spend most of their day, see how HookPhish fills that gap.

For additional reading on practical simulation approaches and examples you can study, see a practical M365 phishing simulation guide and research into real-world Teams phishing techniques such as fake IT helpdesk lures (Microsoft Teams fake IT helpdesk).