Detecting Microsoft Teams Phishing: Hunting the Fake IT Helpdesk Threat

By Alon Klayman and Tomer Kachlon, Team AXON

INTRODUCTION

Phishing is no longer just an email problem. Microsoft Teams, the collaboration tool trusted by millions, is rapidly becoming a new entry point for attackers. Adversaries are abusing Teams’ default external collaboration features to impersonate IT staff, launch vishing calls, share malicious files, and even bypass Microsoft’s built-in warnings.

In this blog, we break down how attackers are exploiting Teams for initial access, the forensic artifacts left behind in Microsoft 365 audit logs, and the detection logic SOC teams can use to uncover these threats. Whether you’re a threat hunter or security leader, understanding Teams phishing is no longer optional – it’s essential.

WHY TEAMS PHISHING IS GROWING

Microsoft Teams usage for initial access is not just a theoretical vector;  it has been observed in the wild as part of various attacks and campaigns, with a significant spike noted over the past year.

In November 2024, Team AXON published VEILDrive  an unconventional campaign targeting a U.S. critical infrastructure company. The operation featured untypical tactics, techniques, and procedures, with one standout method being the abuse of Microsoft Teams for initial access.

Following the VEILDrive discovery, our team observed a growing pattern of threat actors using Microsoft Teams as an initial access vector. 

One of the follow-up patterns observed by our team was the usage of Fake IT/Help Desk communication from external sources via Microsoft Teams. This pattern was sometimes seen as a follow-up to spam flooding initiated by the threat actor to make it appear that the targeted user is facing a technical issue that requires assistance from the IT department.

Given the growing frequency of these attacks, our team conducted a focused research effort into how Microsoft Teams is being abused. Our goal was to understand the mechanics of these attacks, why Teams is emerging as a preferred vector for criminal groups, and how defenders can detect and mitigate these threats before damage occurs.

ATTACK TECHNIQUES IN MICROSOFT TEAMS

External Communication Capabilities are the primary threat to initial access in Microsoft Teams. The fact that this capability is enabled by default in Microsoft 365 Teams tenants makes it particularly attractive for attackers.

Image 1 - Default configuration - External organizations' communication capabilities - Teams’ admin portal

Based on in-the-wild examples we've spotted so far, threat actors first use a previously compromised Teams user account or create an Entra ID tenant. In many cases, we observed the usage of .onmicrosoft.com domains that are the fallback domains provided by Microsoft for Microsoft 365 business or school accounts, for companies that don’t configure their own custom domain.

One of the questions we asked ourselves when digging deeper was, why would threat actors create their own tenants and purchase M365 licenses? Can’t they use trial licenses or even personal Microsoft accounts? 

Based on our simulations, the main insights were that using free Microsoft accounts (outlook[.]com), with a free Teams account, or using a trial Teams licence are not equivalent, both in terms of logging, and in terms of potential functionality and attack surface:

• Free personal Microsoft accounts (Outlook[.]com):  In terms of functionality, there is an option to send external messages. However, the voice chat functionality with organizational tenants is disabled by default. It’s important to note that activities performed by users of this type are even less thoroughly logged, providing attackers or red teamers with an added advantage.
• Trial license: Here, the functionality is very limited, and there is no option to use this account to send external messages or create a voice chat targeting an organizational user account with the default settings (“People in my organization can communicate with account in trial Teams tenant”). 

Image 2: Default Settings: People in my organization can communicate with accounts in trial Teams tenant

ONE-ON-ONE CHAT PHISHING

Offensive POV

Threat actors and red teamers can easily initiate one-on-one chats and send messages to individual or multiple users. Microsoft Teams, as a collaboration platform, simplifies the identification of external users through email address searches within the application (GUI or web). This allows for clear confirmation of user existence and the ability to receive messages from external tenants.

Image 3: Searching for external users in Microsoft Teams

If the email address can’t be found, it means that it either doesn’t exist or that the target organization blocks this type of external communication.

Image 4: Finding a non-existent user in Microsoft Teams

Another important aspect to be aware of is the usage of additional security measures implemented by Microsoft that notify the end user in the case of a potential impersonation in an incoming message from an external identity.

There are two types of messages we identified as part of our research:

1. The “classic” external communication warning: Shown every time the specific external sender communicates with the specific target user.

Image 5: Microsoft Teams external communication warning pop-up

2. Potential phishing warning message: This warning banner is displayed only in specific cases, differing from the standard version. It appears that Microsoft likely employs particular logical tests to identify messages with a higher probability of being phishing attempts.

Image 6: Potential phishing warning message shown in Microsoft Teams

Defensive POV

In the case of written One-On-One Chat, which is one of the main attack methods used by threat actors, the logs created in M365 Audit Logs are:

• ChatCreated: indication of a new “OneOnOne” chat created between the attacker and the victim. This log includes:
  • Chat Thread Id: a unique identifier of the chat
  • Sender Display Name: for example, “Phillip Alexander” or “Help Desk” 
• Sender Email/UPN: for example Helpdesk@randomdomain[.]onmicrosoft[.]com
• Chat members: includes two members in the case of One-On-One chat, the sender and the potential receiver
  • Organization IDs of both the attacker and the targeted user
• MessageSent: An indication of any message sent by a member in the relevant chat. 
  • It complements the ChatCreated log entry with a crucial artifact—the sender’s IP address. 
  • Even though it doesn’t include the message content itself, it may provide valuable information, such as embedded links within the message. Those links can also suggest that a file was attached, due to the way attached files are being sent in M365 (more on this in the Malware Delivery section below)

In addition to the main log types mentioned above, there are complementary log types that are created in specific scenarios:

1. UserAccepted: indicates that the receiver actually clicked on the “Accept” button in the external sender pop-up. It can be very useful to distinguish between targeted users and those who actually communicated with the threat actor.
   • Note: We witnessed different cases in which there was an inconsistency of “UserAccepted” events, i.e., cases in which we expected those log entries to be created, but they weren’t - don’t worry, we also tackle some alternative ways to identify users that actively communicated with the attacker later in this blog.
2. TeamsImpersonationDetected:  This log entry was generated during one of our simulations and classified as a brand impersonation event. It is unclear whether this classification resulted from the similarity of the attacker and victim tenants' names or from other suspicious indicators. Regardless, this is an event type that analysts should be aware of and monitor closely.
   

VOICE CALL PHISHING (VISHING) 

Offensive POV

Threat actors have adapted their tactics over time, moving beyond message-based phishing to incorporate voice chat phishing (vishing). This shift may be attributed to Microsoft's enhanced security measures, which make it more challenging to deceive victims with malicious textual messages, as previously discussed in the One-On-One Chat section.

When using voice-based phishing, an external sender can, by default, call an organizational user without first sending a message - it does create a new chat though.

It can be, and actually seems to be the case in the wild, a very attractive option for threat actors, mainly because no warning pop-up appears on the victim's side.

Image 7: Fake IT Helpdesk calling victim within Microsoft Teams

Defensive POV

Surprisingly, M365 audit logs, which include a relatively in-depth logging of Microsoft Teams activities, didn’t include any indication of an incoming Teams voice chat. The only log entries created were ChatCreated and MessageSent, the exact two event types that we observed being created when an external text-based message is sent. According to our research, there is no definitive way to distinguish between them.

This gap becomes even more important when taking the next part (Screen Sharing) into consideration.

SCREEN SHARING & REMOTE CONTROL

Offensive POV

Attackers commonly exploit Microsoft Teams for initial access, often alongside Remote Monitoring and Management (RMM) tools like QuickAssist, AnyDesk, and DWAgent. This led us to investigate whether attackers could instead utilize Microsoft Teams' integrated screen sharing and remote control features. While we found this to be only partially feasible, it remains a notable concern, and future discoveries may reveal further potential vulnerabilities.

• Screen Sharing: This functionality actually works as expected, which means that a threat actor who already won the trust of the victim can easily ask them to share their screen as part of the attack, without any significant restrictions. 
• Remote Control: This functionality, on the other hand, is more challenging from the attacker’s perspective due to security controls that are enabled by default. Those security controls prevent both the “Give Control” and “Request Control” options.
  • Notes:
  • The security configuration that seems to allow this option is disabled by default.
  • If your organizational policy permits the “give or request control” functionality by external participants, this can be a significant extension to this attack surface.

Image 8: Content sharing configuration screenshot on Microsoft Teams

No dedicated M365 audit log entries were created when screen sharing. This, of course, prevents us from distinguishing between a classic text-based/voice conversation and one that includes screen sharing.

MALWARE DELIVERY

Offensive POV

It’s not the focus of this short blog post; however, we did want to mention that during our simulations, we validated that sending files via OneOnOne chat communication is possible, even though it is not an option using the GUI. Here’s how:

1. Using a tool like Burp Suite, fetch an HTTP request where we share a file between internal users (user A and user B in the same organization) - copying the relevant parts associated with the file attachment.
2. Intercept a normal One-On-One message between the attacker and the victim user using Burp.
3. Add the relevant file attachment part to this request.

Section 3 of the following blog post can be used as a reference - https://posts.inthecyber.com/leveraging-microsoft-teams-for-initial-access-42beb07f12c4

Note that the “file attachment” is actually uploaded to the sender’s SharePoint, and even though represented as a file logo in the OneOnOne chat, it points to the SharePoint URL.

Food for thought: This file can be modified later by the threat actor by simply modifying the SharePoint file itself.

It means that, even though incoming One-On-One chats shouldn’t include attached files by design, as a defender, it is important to remember that this option is available and not to ignore it. 

Defensive POV

Embedded files (in practice, SharePoint links) can be identified in the relevant “MessageSent” M365 Audit logs entries in the “MessageURLs” field.

MEETINGS AS A POTENTIAL BYPASS

Microsoft has implemented security pop-ups to warn users about potential threats, posing a significant hurdle for attackers. While previous methods to bypass these warnings have been documented, our recent tests indicate that these methods are no longer effective.

During our simulations, we asked ourselves, is there a way to actually send text messages that will be accessible by the victim, without the need to first witness those “external user” pop-ups? We found that some of the security measures enforced on Voice Chats and One-On-One communications are not consistently enforced in the case of Teams’ Meetings.

Teams Meetings vs Voice Calls

In Microsoft Teams, meetings and voice calls serve different purposes and offer distinct features. Meetings are designed for larger, collaborative sessions, potentially involving multiple participants and featuring tools such as screen sharing and recording. Calls are typically one-on-one or small-group interactions, more akin to a phone call, with a focus on quick and direct communication.

For instance, while the GUI facilitates file sharing, this capability isn't a significant concern. As previously demonstrated, this functionality can still be exploited in one-on-one chats, even when using tools like Burp, regardless of the GUI setting.

A crucial point to note is that the warning banner is not consistently enforced during meetings.

• The victim answers the call: 
  The banner will disappear, meaning that if a threat actor created an instant meeting and called the victim from this meeting, an incoming call pop-up will appear on the potential victim’s screen. If they answer, a text-based communication with the victim will be allowed from this point forward, without the warning banner.
• The victim does not answer the call: 
  Attackers can still use a text-based message under the context of a Teams Meeting, by adding the targeted user to the meeting and tagging them to lure them into interaction. It will create a notification in the “mentions” section in Microsoft Teams. When the victim clicks on this notification, they are directed to a text chat that lacks the usual warning banner.
  
  Note: Whilst writing this blog, the tagging method stopped working, and a warning banner was displayed. We speculate this is a result of rapid patching, given our prior notification to Microsoft's teams regarding this vulnerability. Nevertheless, it's important to note that the initial phase of the attack, where the victim answers the call, continues to bypass the warning banner.
  

DETECTION & THREAT HUNTING STRATEGIES

Given the increasing prevalence and evolution of Microsoft Teams phishing as an initial access vector, our team has developed comprehensive detection logic to address this threat. This logic identifies suspicious external communications as threat-hunting signals and incorporates a dedicated enrichment and scoring layer. This ensures that the most significant hits are prioritized and classified as alerts.

Key Detection Logic

We employed a UEBA approach, focusing on identifying new Microsoft Teams chats where the domain of the sender is both external and not typically used in communications with organizational Teams users. This emphasis on "ChatCreated" events stems from their prevalence across various chat types, including those used in vishing and text-based phishing attempts by threat actors.

Image 9: Microsoft Teams Phishing Attempt Alert in Hunters Next Gen SIEM

The hits are initially considered threat-hunting signals (a.k.a. leads). On top of those hunting signals, we created robust enrichment and scoring layers to ensure that SOC analysts who use Hunters will be able to prioritize the most important and interesting leads and quickly investigate them to determine if it is indeed true-positive or not.

Contextual Enrichments & Scoring Layer

To provide the analyst with the option to conduct a quick triage and analyze the lead, we created a dedicated drill-down that fetches relevant M365 unified audit log entries based on the relevant entity (sender or receiver) and the relevant chat ID. The following screenshot shows an example of this drill-down, which includes a significant number of TIMailData log entries right before the malicious incoming Teams’ message:

Image 10: Dedicated drill-down that fetches relevant M365 unified audit log entries

This summarized view of events further enhances efficiency, allowing for quick determination of significant event types within associated log entries.

Image 11: Summarized view of events in Hunters NextGen SIEM

Based on the information available in the lead itself and also in the drill-down/enrichment, we created multiple scoring layers to increase the severity or the confidence of the leads based on different characteristics:

Image 12: Microsoft Teams Phishing Attempt Scoring Layers in Hunters Next Gen SIEM

Confidence

The following logic can be applied to enhance the confidence level of a suspicious new chat initiated by an incoming Microsoft Teams message from an external user. This method can effectively narrow down the alerts to those more likely to be true positives.

• Sender used Onmicrosoft[.]com domain: most of the attacks observed by our team included the usage of onmicrosoft[.]com domains - the default suffix used when creating a new Entra ID tenant.
• A significant number of TIMailData events targeting the victim user: TIMailData M365 audit log entries were identified as a handy way to identify a spike of email bombing right before the suspicious incoming chat.
• Sender used a fake IT/Help-Desk pattern in the User ID: impersonation attempt.
• Sender used a fake IT/Help-Desk pattern in the Display Name:  impersonation attempt.
• Sender used a Non-ASCII character in the Display Name: Attackers have been observed using non-ASCII characters, such as emojis like the green checkmark (✅), to make display names appear more legitimate. Additionally, they may use numerous space-like characters to push the "(External)" warning in the Microsoft Teams GUI beyond the screen's viewable area.
• Extra confidence modifiers:
  • Sender domain is a baby domain (the domain was registered shortly before the suspicious message)
  • Sender’s domain/IP was identified in an IOC feed
  • Sender’s IP was a proxy IP

Severity

The following logic can be used to identify suspicious chats with a higher potential for escalating to  a significant incident based on follow-up activities that were logged in M365 audit logs:  

• User Accepted Event: Looking for cases in which a “UserAccepted” log entry was created under the context of the user ID that received the incoming message.
• User Replied in Suspicious Chat: Looking for a case in which the potential victim not only accepted the incoming message, but also replied in the suspicious chat (based on Chat Thread ID).
• Member Added Event: When a “MemberAdded” event occurred, with the suspicious sender as the added member.

Image 13: Microsoft Teams Phishing Attempt Logic Hunters SIEM

THREAT HUNTING GUIDELINES

WITH COMMONLY_USED_DOMAINS AS (
   SELECT LOWER(SPLIT_PART(USER_ID , '@', 2))          AS DOMAIN_COMMONLY_USED,
          MIN(EVENT_TIME)      AS MIN_EVENT_TIME,
          MAX(EVENT_TIME)      AS MAX_EVENT_TIME,
          ARRAY_AGG(DISTINCT OPERATION)    AS OPERATIONS,
          COUNT(*)             AS COUNTER
   FROM RAW.O365_AUDIT_LOGS
   WHERE 1=1
     AND WORKLOAD = 'MicrosoftTeams'
     -- This is the learning period, adjust per your needs
     AND EVENT_TIME BETWEEN CURRENT_TIMESTAMP - interval '60d' AND CURRENT_TIMESTAMP - interval '30d'
     AND USER_ID ILIKE '%@%'
   GROUP BY DOMAIN_COMMONLY_USED
   -- Threshold that determines how many appearances for a domain to be considered common
   HAVING COUNTER > 50
)
SELECT
   MIN(EVENT_TIME)                                                              AS FIRST_SEEN,
   MAX(EVENT_TIME)                                                              AS LAST_SEEN,
   USER_ID                                                                      AS USER_ID,
   LOWER(SPLIT_PART(USER_ID , '@', 2))                                          AS USER_DOMAIN,
   RECORD_SPECIFIC_DETAILS:chat_thread_id                                       AS CHAT_THREAD_ID,
   ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:members[0].DisplayName)           AS MEMBER_DISPLAY_NAME_1,
      ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:members[0].UPN)                   AS MEMBER_UPN_1,
   ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:members[1].DisplayName)           AS MEMBER_DISPLAY_NAME_2,
   ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:members[1].UPN)                   AS MEMBER_UPN_2,
   ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:message_ur_ls)                    AS MESSAGE_URLS,
   ARRAY_AGG(DISTINCT OPERATION)                                                AS OPERATIONS,
   ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:resource_tenant_id)               AS RESOURCE_TENANT_ID,
   ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:communication_type)               AS COMMUNICATION_TYPE,
   ARRAY_AGG(DISTINCT RAW:ClientIP)                                             AS CLIENT_IP,
   ARRAY_AGG(DISTINCT RAW:ParticipantInfo.HasForeignTenantUsers)                AS INCLUDE_EXTERNAL_ENTITY
FROM RAW.O365_AUDIT_LOGS
WHERE 1=1
 AND WORKLOAD = 'MicrosoftTeams'
 AND NOT USER_ID IN ('app@sharepoint')
 AND USER_ID ILIKE '%@%'
 AND OPERATION IN ('ChatCreated')
 AND RECORD_SPECIFIC_DETAILS:participant_info:has_foreign_tenant_users = true
 AND RECORD_SPECIFIC_DETAILS:communication_type = 'OneOnOne'
 -- remove commonly used domains
 AND LOWER(SPLIT_PART(USER_ID , '@', 2)) NOT IN (SELECT DOMAIN_COMMONLY_USED FROM COMMONLY_USED_DOMAINS)
 AND EVENT_TIME > CURRENT_TIMESTAMP - interval '30d'
GROUP BY USER_ID, CHAT_THREAD_ID,USER_DOMAIN
HAVING COUNT(*) < 20

To make it even easier, here is a list of guiding questions to answer when investigating a Threat-Hunting hit:

1. Does the sender’s domain look suspicious?
   • Is the domain newly registered, or has it been seen recently for the first time?
   • Is the sender using a generic Microsoft-hosted domain (e.g., *.onmicrosoft.com)?
2. Does the sender’s user ID contain administrative keywords (e.g., adm_, admin, administrator)?
3. Is the sender domain/IP found in IOC feeds?
4. Is the conversation a One-On-One chat?
5. Does the sender’s display name contain keywords to mimic a fake IT/Help Desk?
6. Does the sender’s User ID contain keywords to mimic a fake IT/Help Desk?
7. Does the sender’s display name include non-ASCII (e.g., emoji) characters?
8. Is there a UserAccepted event from the same internal user shortly after receiving the suspicious message?
9. Has the internal user responded in the same chat thread as the suspicious message?
10. Was the sender accepted into the conversation in the same chat thread?

CONCLUSIONS

Microsoft Teams phishing isn’t a fringe technique anymore — it’s an active, evolving threat that bypasses traditional email defenses and exploits trust in collaboration tools. By monitoring audit logs like ChatCreated and MessageSent, enriching signals with contextual data, and training users to spot IT/help desk impersonations, SOC teams can close this new gap before it’s exploited.

Attackers are already moving into Teams. The question is whether defenders will adapt quickly enough. Start by applying the hunting queries and detection logic we’ve shared here —  and make Teams phishing detection a first-class priority in your SOC.