Identifying Suspicious External Domains In Teams With Sentinel & Defender XDR

Threat Overview

From a detection-engineering perspective, Teams is an increasingly attractive vector for attackers because the platform produces high-volume, user-driven traffic with low friction and limited pre-authentication controls. This creates a communication surface where malicious engagement attempts blend seamlessly into legitimate collaboration patterns. Unlike email—which benefits from mature filtering, sandboxing, and decades of defensive tuning. Teams interactions often land directly in front of the user with fewer upstream inspection points.

Telemetry adds another layer of complexity. In Microsoft Sentinel and Defender XDR, Teams data is distributed across multiple signals: audit logs, identity events, endpoint observations, and external access records. While these sources provide valuable insight, the signal quality is not always uniform. Some data points arrive with coarse granularity (e.g., high-level audit actions), while others lack deep metadata about the external entity, device posture, or message content. Additionally, communication with external organizations may generate minimal enrichment, making it harder to attribute unfamiliar domains or detect subtle impersonation patterns.

These gaps mean that traditional correlation logic is not enough. Effective detection requires behavioral baselining, cross-signal stitching, and anomaly detection tuned to the nuances of collaboration traffic. Understanding the limitations, and strengths, of Teams telemetry in Sentinel and XDR is key to building robust detections that can flag malicious external engagements before they escalate.

Detection Logic Explained

• Intent
  • Detect external domains that have never interacted with the organization before.
  • Surface high-risk, early-stage Teams outreach attempts while minimizing noise from legitimate collaboration.
• Signal Selection
  • Use OfficeActivity logs from Sentinel because they reliably capture Teams events such as sessions, messages, calls, and meetings.
  • Focus on identity-level operations (e.g., MessageSent, TeamsSessionStarted) that indicate direct external interaction, even without rich content telemetry.
• Allow-List Design
  • Maintain a static whitelist of approved partner or customer domains.
  • Ensures predictable, sanctioned cross-tenant communications are automatically suppressed.
  • Reduces false positives and removes known-good activity from detection scope.
• Baseline Rationale
  • Build a dynamic 14-day baseline of domains previously seen in Teams activity, excluding the detection window.
  • Allows the logic to adapt to natural business interactions without manual updates.
  • Ensures only truly new and unfamiliar external domains are surfaced—those most likely to represent impersonation or social-engineering attempts.

KQL Query Used

This query identifies unfamiliar external domains interacting with the organization through Microsoft Teams. It does this by:

• Creating a whitelist of approved external domains.
• Building a 14-day baseline of domains previously observed in Teams activity.
• Analyzing the last hour of Teams events and extracting the domain from each UserId.
• Flagging any domain that appears in the last hour but is absent from both the whitelist and the baseline.

The logic focuses on Teams operations that represent direct interaction, messages, sessions, calls, and meetings, ensuring the result set contains only meaningful external engagements.

let WhitelistedDomains = dynamic([ 
    "[WhitelistedDomain1]", 

    "[WhitelistedDomain2]"  
]); 

let FamiliarDomains =  
    OfficeActivity 
    | where OfficeWorkload == "MicrosoftTeams" 
    | where Operation in ( "TeamsSessionStarted", "MessageSent", "MessageCreatedHasLink",  
                           "CallParticipantDetail", "MeetingParticipantDetail", "MeetingDetail") 
    | where TimeGenerated between (ago(14d) .. ago(1h)) 
    | extend Domain = tostring(split(UserId, "@", 1).[0]) 
    | where isnotempty(Domain) 
    | distinct Domain; 

OfficeActivity 
| where OfficeWorkload == "MicrosoftTeams" 
| where Operation in ( "TeamsSessionStarted", "MessageSent", "MessageCreatedHasLink",  
                       "CallParticipantDetail", "MeetingParticipantDetail", "MeetingDetail") 
| where TimeGenerated >= ago(1h) 
| extend Domain = tostring(split(UserId, "@", 1).[0]) 
| where isnotempty(Domain) 
| where Domain !in (WhitelistedDomains) 
| where Domain !in (FamiliarDomains) 
| extend OperationDescription = case( 
        Operation == "MessageSent", "A message was sent in Teams", 
        Operation == "TeamsSessionStarted", "A Teams session was initiated", 
        Operation == "MessageCreatedHasLink", "A Teams message containing a link was created", 
        Operation == "CallParticipantDetail", "Call participant details were logged", 
        Operation == "MeetingParticipantDetail", "Meeting participant details were logged", 
        Operation == "MeetingDetail", "Meeting details were recorded", 
        "Unknown Operation" 
    )

Expected Results

When the query returns results, each row represents:

• A new, previously unseen external domain contacting a user through Teams.
• Context on what action occurred (e.g., message sent, meeting interaction).
• A clear indicator that the domain is neither trusted nor historically familiar.

This gives analysts a high-confidence signal of potential impersonation, social engineering outreach, or anomalous external contact.

How the Detection Logic Works

To effectively build a 14-day behavioral baseline, the maximum lookback for capturing normal external Teams activity, the detection window must be at least one hour. This ensures recent activity can be compared against a meaningful historical profile while maintaining near–real-time visibility. The design balances signal coverage with timeliness but can produce expected false positives, such as legitimate first-time partners, newly onboarded vendors, or temporary collaborators.

The logic follows a simple pattern: understand what “normal” external Teams communication looks like, then spotlight anything that falls outside that pattern.

It starts with a trusted set of external domains, organizations that are officially approved for collaboration. These domains are treated as safe and never flagged.

Next, it builds a 14-day behavioral baseline by looking at which external domains have interacted with the organization during the past two weeks. This period is long enough to capture typical collaboration habits but short enough to avoid stale historical data. If an external domain has appeared inside this window, it becomes part of the familiar baseline.

Once that baseline is established, the logic looks only at the most recent hour of Teams activity. It checks chats, meeting invitations, link-sharing, and call activity—anything representing real communication between people.

Every domain seen in this one-hour window is tested against two questions:

1. Is it part of the trusted allow-list?
2. Has it appeared at least once in the past 14 days?

If the answer is no to both, the domain is treated as unfamiliar. That unfamiliarity is what triggers the detection. To make the output more meaningful, the logic translates raw event types into simple descriptions such as whether someone sent a message, started a session, shared a link, or initiated a meeting.

Limitations: The detection cannot inspect message content, so it only identifies unfamiliar domains. Analysts must verify with the user whether the communication is expected before taking action.

The result is a clear signal highlighting brand-new or previously unseen domains suddenly engaging users on Teams—a strong indicator of impersonation, social engineering, or early stages of a BEC-style attack.

MITRE ATT&CK Mapping

This detection aligns with several enterprise intrusion techniques:

• T1566.003 – Phishing: Spearphishing via Service
  Adversaries use third-party services such as Microsoft Teams or other cloud collaboration apps to deliver social-engineering messages and lures.
• T1566.002 – Phishing: Spearphishing Link
  Malicious links are shared in chats or meeting invites to drive users to credential-harvesting pages or malware delivery sites.
• T1078 – Valid Accounts
  Compromised user or partner accounts are abused to initiate “trusted” external conversations and blend into normal collaboration traffic.
• T1656 – Impersonation
  Threat actors masquerade as executives, suppliers, or partners over Teams to build trust and socially engineer victims, often as part of BEC-style fraud.

Prevention

• Apply strict governance over external collaboration in Microsoft Teams.
• Limit external access to approved and verified domains only.
• Enforce Conditional Access rules requiring phishing-resistant MFA for all cloud applications.
• Conduct periodic reviews of external access policies, guest accounts, and federated domains.
• Implement continuous monitoring for anomalous collaboration activity.

Detection

The detection logic presented here provides a structured mechanism to identify external domains that deviate from established communication patterns. Security teams can enhance this baseline with additional correlation and enrichment to improve detection fidelity:

• URL inspection: Analyze links shared through Teams messages to detect malicious or phishing URLs.
• Correlation with sign-in logs: Cross-reference with Azure AD sign-ins to identify suspicious authentication attempts, impossible travel, unusual MFA prompts, or guest account anomalies.
• Integration with Defender XDR alerts: Correlate external domain activity with endpoint signals such as suspicious process creation, unusual software installations, or lateral movement attempts.
• Automated threat-intel enrichment: Flag unrecognized domains against threat intelligence feeds to identify known malicious actors.
• ASIM/Telemetry integration: Leverage structured security telemetry to create richer analytic rules, enabling multi-signal correlation across collaboration, identity, and endpoint data.

Remediation

When unfamiliar domains appear:

1. Validate whether the communication is legitimate.
2. Investigate the associated user behavior (messages, meetings, files).
3. Block the domain temporarily if activity is suspicious.
4. Conduct user outreach and awareness checks.

Trends & Impact

The increasing use of Microsoft Teams for BEC-style attacks demonstrates a broader shift in threat actor tradecraft. By moving away from email, adversaries bypass established security layers and exploit collaboration tools users inherently trust.

Unfamiliar or newly observed external domains therefore represent a significant risk, especially in organizations with extensive partner ecosystems or third-party communication workflows.

Impacted Technologies

• Microsoft Teams: The primary collaboration platform where anomalous external communications are observed, including chats, meetings, calls, and link sharing.
• Microsoft Sentinel: Collects OfficeActivity logs, enabling detection engineering to aggregate, baseline, and correlate Teams events over time.
• Microsoft Defender XDR: Provides endpoint and identity telemetry that can enrich Teams activity with device posture, user context, and risk indicators.

A real-world scenario illustrates how unfamiliar external domains in Teams can escalate into full compromise when combined with social engineering. An employee received a sudden Microsoft Teams call from someone claiming to be part of the company’s IT helpdesk.

Because the interaction happened inside Teams, the user assumed the call was internal and legitimate. The impersonator then guided the user through a series of instructions, eventually requesting remote access “just to fix the issue quickly.” The attacker directed the user to install AnyDesk, presenting it as an official troubleshooting tool.

Once the user installed and launched AnyDesk, the adversary gained remote control of the workstation. They immediately deployed a malicious payload, modified browser sessions, and harvested cached credentials. With remote access in place, the attacker attempted lateral movement and accessed cloud applications without triggering MFA prompts by using active session tokens. Activity quickly expanded to email rules manipulation and unauthorized file access.

The root cause was simple: the Teams call originated from an unfamiliar external domain impersonating IT staff. The environment had no prior communication with that domain in the 14-day baseline, and the domain was not part of any trusted collaboration set. Detecting that anomaly early would have surfaced the impersonation before the attacker convinced the user to install remote-access software.

This case highlights how attackers exploit trust in collaboration tools. A simple Teams call can bypass skepticism that users might apply to email, making frontline detection of new external domains an essential defense against malware delivery, remote-access abuse, and account compromise.

Unfamiliar external Teams communications can signal social engineering attempts, outbound reconnaissance, or credential-harvesting campaigns. By implementing structured detection logic, organizations gain continuous visibility into external interactions, improving signal-to-noise and highlighting high-risk activity without relying solely on user vigilance. Early detection enables security teams to proactively investigate and respond, reducing the likelihood of data exposure, unauthorized access, or business disruption. Maintaining telemetry-driven coverage across collaboration platforms is now a critical component of a modern, proactive security strategy.

Wizard Cyber delivers advanced detection engineering across Microsoft 365 environments, combining robust monitoring with expert analytics to uncover anomalous activity and potential threats. Our services focus on strengthening collaboration security and accelerating threat detection across identity, endpoints, and cloud workloads.

Key detection engineering capabilities include:

• Custom analytics and continuous monitoring using Microsoft Sentinel to detect anomalies and correlate suspicious activity.
• Managed Detection and Response (MDR) leveraging Defender XDR telemetry to surface endpoint and identity signals linked to potential attacks.
• Behavioral baselining and anomaly detection for Teams communications, enabling identification of unfamiliar external interactions and social engineering attempts.
• Proactive threat hunting and CTEM integration, identifying high-risk configurations or emerging threats before they are exploited.
• Incident detection and response support, including rapid investigation and containment of collaboration-based threats.

This approach ensures organizations gain high-confidence detection signals, reduce false positives, and move beyond reliance on user awareness alone.

• Microsoft Docs – Manage external meetings and chat with trusted organizations in Microsoft Teams
• Microsoft Docs – Secure external access to Microsoft Teams, SharePoint, and OneDrive
• Microsoft Support – Prevent spam or phishing attempts from external chats in Microsoft Teams
• Microsoft Support – Protect yourself from phishing (email and Teams)
• Microsoft Security Blog – Disrupting threats targeting Microsoft Teams
• Push Security – Phishing Microsoft Teams for initial access
• Eye Security – Microsoft Teams Chat: the rising phishing threat and how to stop it
• MITRE ATT&CK – Technique T1566 – Phishing and sub-techniques T1566.002 (Spearphishing Link) and T1566.003 (Spearphishing via Service)
• MITRE ATT&CK – Technique T1078 – Valid Accounts
• MITRE ATT&CK – Technique T1656 – Impersonation