Identity has become a primary security boundary for most organizations, reducing the ability to solely trust other boundaries once associated with corporate networks. Users authenticate to cloud services using enterprise identities that provide access to collaboration platforms, business applications and sensitive data. With the adoption of software-as-a-service (SaaS) on the rise, people are shifting to platforms for communication and collaboration.
Threat actors have adapted to this shift. In addition to typical email-based phishing, attackers increasingly misuse trusted collaboration platforms to conduct identity phishing, impersonation, credential theft, malware delivery and social engineering. Over the last 12 months, our endpoint alerts of malicious activity associated with collaboration tools have more than quadrupled, as Figure 1 shows. This activity could involve compromised accounts, external federated organizations, guest accounts or trusted third-party relationships. In each case, the attackers seek to exploit the trust that people place in enterprise communication platforms.

This changes the role that collaboration platforms play within enterprise security. They are not just productivity applications, they have become part of the enterprise attack surface. Unit 42 researchers found that 99% of the alerts generated related to chat phishing operations, indicating that attackers often gain access to these environments through targeted phishing operations. After a successful compromise, attackers can then communicate using the identity and privileges of the compromised user. This allows malicious activity to appear as normal collaboration activity.
Security controls typically remain focused on email and authentication events, often providing limited visibility into activity occurring within authenticated collaboration sessions.
We examine how threat actors leverage trusted communication channels and review identity abuse techniques. We also provide practical recommendations for detecting and defending against identity-focused attacks targeting enterprise collaboration platforms.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
Enterprise collaboration platforms have become integral to business operations. Employees use these platforms to exchange messages, share files, coordinate projects and communicate with colleagues, customers and business partners. Organizations typically connect collaboration platform access to their identity provider, and people rely on these platforms for trusted, authenticated communication.
Unlike email, collaboration platforms enable real-time conversations and support features such as external federation, guest access, shared workspaces and third-party integrations. These capabilities improve productivity but also create opportunities for misuse. Attackers can exploit compromised accounts, trusted business relationships or authorized external access to interact with victims through legitimate communication channels. Figure 2 shows common pathways for attackers to compromise identities in enterprise and cloud environments.

When a collaboration account is compromised, attackers inherit the identity context of that user, including their permissions, relationships and ongoing conversations. Requests that might appear suspicious in an email can appear routine when delivered through an authenticated collaboration platform. This reduces a target’s suspicion and increases the effectiveness of identity phishing, impersonation, credential theft and social engineering.
As organizations adopt more SaaS collaboration platforms, they should treat these environments as part of the identity attack surface. Protecting them requires both strong authentication, and visibility into how trusted identities and communication channels are used after authentication.
Recent campaigns demonstrate that attackers use collaboration platforms in multiple stages of identity-focused attacks, from initial access to post-compromise operations. Table 1 summarizes these intrusion stages.
| Intrusion Technique | Campaign Misuse Pattern |
| Initial access: Phishing (T1566) | Identity phishing through external collaboration channels |
| Stealth: Impersonation (T1684.001) | Impersonation through legitimate platform notifications, hosted content and direct messages |
| Persistence: Modify Authentication Process (T1556) | MFA removal and privileged credential exfiltration through a native Slack webhook integration |
Table 1. Collaboration platform misuse by MITRE ATT&CK intrusion technique.
One of the most common techniques is identity phishing through enterprise collaboration platforms. In our Insights article, "When 'Hi, This Is IT' Comes Through Microsoft Teams", we discussed how APT29 used compromised Teams accounts to send links to credential-harvesting pages. We reported that attackers misuse external federation in Teams to initiate conversations with victims while impersonating IT support or other trusted personnel. These campaigns often begin with a request to chat, followed by instructions to visit a phishing site, approve a multifactor authentication (MFA) request, install remote access software or provide credentials.
Okta Threat Intelligence has also documented the technique of identity phishing through attacker-controlled Slack workspaces. The threat actor behind this activity impersonated administrators and employees from targeted organizations and sent phishing links through direct messages, channel mentions and legitimate notifications. The links redirected victims to adversary-in-the-middle phishing proxies designed to capture corporate credentials and MFA tokens.
Security teams might not detect the initial collaboration message directly. They could instead see the actions that follow. An example of this is shown in a process tree from a malicious chat scenario in Figure 3.

In this case, the threat actor sent a RAR file to a victim in a Teams chat. The victim accepted the file transfer and downloaded the file to their Downloads folder. The victim then opened an Explorer window and double-clicked [REDACTED].rar, launching WinRAR.exe to open the archive. WinRAR extracted the malicious lpk.dll, which the victim’s endpoint security agent detected. The extracted lpk.dll is a known, older malicious DLL that masquerades as a legitimate Windows language pack DLL. Attackers use the file for DLL sideloading attacks. This recent event demonstrates that attackers continue to use older malware families in attacks delivered through collaboration platforms.
Unlike commonly-seen email phishing, some collaboration platforms support interactive communication. This enables attackers to respond to targets and adjust their social engineering tactics in real time. If successful, the attacker obtains a valid enterprise identity. The attacker can then access enterprise and cloud services with the privileges and identity context of the compromised user.
Attackers use impersonation to exploit trust in collaboration platforms and gain access to enterprise identities, posing as known individuals, trusted organizations or support personnel.
Each of these campaigns used impersonation through trusted collaboration workflows. The attackers relied on recognized identities, legitimate services and familiar business processes to obtain credentials or persuade victims to take actions that enabled identity compromise.
In a more novel approach, attackers have misused trusted collaboration services to maintain their access after identity compromise. In a December 2025 intrusion investigated by CERT Polska, a threat actor modified compromised firewall-VPN appliances at a manufacturing company in Poland. The threat actor used the appliances’ built-in scripting mechanism to create weekly scheduled tasks. One script retrieved the password of a privileged identity, and another script modified security settings and disabled two-factor authentication for a privileged account. A third script used the appliances’ native Slack notification capability to send the results to a Slack channel under the threat actor’s control. This activity combined identity persistence and credential exfiltration with a legitimate SaaS integration. It also avoided the need for a separate exfiltration tool. The case demonstrates how attackers can misuse built-in appliance features and trusted collaboration services during post-compromise operations.
The firewall event in Figure 4 shows an example of a Slack webhook request, a similar communication method to the one described in the CERT Polska report. The request used HTTP POST to hooks.slack[.]com with a curl user agent. The example event below is not malicious.

Perimeter firewalls provide valuable visibility into webhook-related traffic exiting the organization. Many network and security appliances, including VPN appliances, operate behind a separate perimeter firewall and send outbound webhook requests through the enterprise egress path when configured for external alerting or automation. Security teams should review unexpected Slack webhook traffic, uncommon user agents and webhook activity from systems without an approved Slack integration. This type of activity should also be flagged in Microsoft Teams, which supports similar incoming webhook workflows for posting messages from external services.
These examples of initial access, impersonation and persistence demonstrate how attackers leverage trusted communication channels to support identity-focused attacks. Although the techniques differ, each example leverages legitimate platforms, authenticated identities or authorized communication paths to increase the likelihood of success. The common objective is to misuse the trust, access and identity context associated with enterprise collaboration platforms.
Organizations should protect collaboration platforms with the same level of scrutiny applied to email and identity infrastructure. Because these platforms are integrated with enterprise identities, security controls should focus on both preventing identity compromise and detecting misuse after authentication.
The first priority is reducing unnecessary exposure. Collaboration platform administrators should review external federation, guest access and third-party integrations to ensure they support legitimate business requirements. Where possible, limit external communications to trusted organizations, and implement a process to review guest accounts regularly and remove unnecessary access.
Identity protections should also extend beyond authentication. MFA, conditional access and session risk evaluation help reduce the likelihood of account compromise, but they do not prevent an attacker from misusing a valid session. Security teams should monitor for behavior that could indicate identity compromise, including unusual messaging activity, unexpected file sharing or communications with unfamiliar external tenants.
Identity and security teams should define and communicate verification procedures for security-sensitive requests received through collaboration platforms. Users should not approve MFA prompts, install remote access tools, share credentials, transfer files or modify access based only on a message. Instruct people to verify high-risk requests through an approved secondary channel, such as a known phone number, ticketing system or documented internal process.
User awareness remains an important part of effective verification procedures. People should treat collaboration messages, platform notifications and links to hosted content with the same caution as email. This is especially important when a request involves credentials, MFA approval, software installation, remote access tools or sensitive data.
Security training should make clear that content associated with an enterprise collaboration platform is not automatically trustworthy. An attacker can send a direct message, trigger a legitimate platform notification or use content hosted on an approved service to direct victims to a phishing site.
Security awareness teams should include these scenarios in phishing simulations and security awareness exercises. Many people recognize email phishing indicators but might not apply the same scrutiny to collaboration platforms and related notification workflows.
Security teams should incorporate collaboration platform telemetry into routine monitoring and incident response. Authentication logs, messaging activity, file sharing events and external tenant interactions provide valuable context for detecting identity abuse.
Network and security appliances should also be included in monitoring coverage. Firewalls, VPN appliances, load balancers and managed switches increasingly support automation, notification integrations and scheduled tasks. Attackers can potentially use these capabilities for malicious purposes following a compromise. To protect against such activity, security teams should monitor:
This telemetry should be ingested into a security information and event management (SIEM) system and correlated with identity, endpoint and collaboration platform data. This can improve visibility into malicious activity that might otherwise appear to originate from legitimate users or approved infrastructure.
Collaboration-based reporting must also be easy for users. Security teams should provide a clear process for reporting suspicious communications, notifications, hosted content and links associated with collaboration platforms. Each report should be triaged using identity telemetry, sign-in activity, endpoint alerts, file-sharing events and external tenant information. This helps to determine whether the activity reflects user error, external misuse or identity compromise.
Enterprise collaboration platforms are integrated with enterprise identity and access workflows. As organizations rely on these platforms for communication, attackers are exploiting the trust associated with authenticated users and sanctioned communication channels to conduct identity phishing, impersonation, credential theft and post-compromise operations.
Common security strategies have focused on protecting email and authentication systems. While these controls remain essential, they should be complemented by security measures that address collaboration platforms as part of the enterprise identity attack surface. Authentication alone is no longer sufficient to establish trust. Organizations must also understand how authenticated identities are communicating and recognize when trusted communication channels are being misused.
By extending identity security to include collaboration platforms, defenders can better detect identity abuse, reduce opportunities for compromise and strengthen their ability to respond to identity-focused attacks. As collaboration technologies evolve, organizations should monitor and protect them with the same controls they apply to other critical identity infrastructure.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
The query below is designed to help Palo Alto Networks customers hunt for, investigate and identify potentially suspicious activity using Cortex XDR. Results returned by this query should not be considered inherently malicious and require further analysis to determine their significance.
This XQL query can help to identify where legitimate collaboration platforms — specifically Slack or Teams in this example — are used to execute system shells. The query inspects both the direct process hierarchy and the broader causality chain. It identifies instances where a collaboration tool is either the immediate parent process or an ancestor process that initiated the execution of a shell. Analysts can use this logic to identify:
The query can be modified to search for additional collaboration platforms or system shells.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
dataset = xdr_data | filter _time >= "2026-07-08T00:00:00Z" and _time < "2026-07-09T00:00:00Z" | filter ( // Look for Slack/Teams in the causality chain spawning shells (lowercase(causality_actor_process_image_name) contains "slack" or lowercase(causality_actor_process_image_name) contains "teams" or lowercase(actor_process_image_name) contains "slack" or lowercase(actor_process_image_name) contains "teams") and (lowercase(actor_process_image_name) in ("cmd.exe", "powershell.exe", "bash", "sh", "zsh") or lowercase(action_process_image_name) in ("cmd.exe", "powershell.exe", "bash", "sh", "zsh")) ) | fields _time, actor_process_command_line, action_process_image_command_line, causality_actor_process_command_line, actor_process_image_name, action_process_image_name, causality_actor_process_image_name, actor_process_image_sha256, action_process_image_sha256, causality_actor_process_image_sha256, action_file_path, actor_causality_id, causality_actor_process_causality_id, dst_actor_remote_ip, dst_action_external_hostname, action_remote_ip, action_external_hostname | sort asc _time |