How to Defend Against Microsoft Teams Social Engineering and IT Impersonation

Security operations centers (SOCs) and IT departments are facing a refined social engineering vector that bypasses traditional email defenses. Recent guidance from Rapid7’s Managed Detection and Response (MDR) team highlights a significant increase in campaigns where threat actors impersonate internal IT departments via Microsoft Teams.

Unlike email phishing, which relies on deceptive links or attachments, this campaign exploits the inherent trust users place in internal collaboration tools. Attackers leverage the chat interface to persuade users to launch Microsoft Quick Assist, granting the attacker remote access. This access facilitates the deployment of malicious software, data exfiltration, and lateral movement across the network.

Introduction: The Trust Gap in Collaboration Tools

For defenders, the rise of Teams-based social engineering represents a critical blind spot. Organizations heavily invest in Secure Email Gateways (SEGs) to filter spam and phishing, yet Microsoft Teams often remains an open channel. By default, Teams may allow external users to message internal staff. In many configurations, this is the functional equivalent of operating an email server without a gateway filter.

While an interface tag indicates "External," users in high-pressure situations—such as a fake IT support request for "password resets" or "MFA fixes"—often overlook these indicators. This breach of trust allows attackers to pivot directly from a chat message to a full remote control session using legitimate administrative tools.

Technical Analysis

The Threat Vector Threat actors initiate contact with target users through Teams chats, posing as IT support or help desk personnel. The conversation follows a typical social engineering script: creating urgency, citing account issues, or requesting verification.

The Mechanism The primary objective is to trick the user into opening Quick Assist (a built-in Windows tool) or a similar remote support application. Once the user enters a code provided by the attacker or accepts a connection, the threat actor gains legitimate remote control over the endpoint.

Affected Systems & Severity

• Platform: Microsoft Teams (Windows, Mac, Web)
• Exploited Utility: Microsoft Quick Assist (quickassist.exe)
• Severity: High. Successful compromise leads to Remote Access Trojans (RATs), ransomware deployment, or credential theft.

The Vulnerability The core issue is a configuration and awareness gap. Microsoft Teams allows federation and external communication by default in many tenants. Furthermore, there are no native "link scanning" capabilities for URLs sent within Teams chats, nor are there default blocks on outbound remote control tools initiated by users.

Defensive Monitoring

To detect these activities, security teams must correlate Teams communication logs with process execution events on endpoints. Below are KQL queries for Microsoft Sentinel/Defender and PowerShell scripts to aid in investigation.

KQL Query: Detect External Teams Communication

Use this query in Microsoft Sentinel or Microsoft 365 Defender to identify incoming Teams messages from external domains that contain keywords associated with technical support.

let SupportKeywords = dynamic(["password", "mfa", "verify", "support", "it desk", "account", "quick assist", "urgent"]);
OfficeActivity
| where OfficeWorkload == "MicrosoftTeams"
| where Operation in ("TeamsSessionStarted", "MessageCreated")
| extend Initiator = UserId, Target = UserId // Modify based on specific schema version for Target
| project TimeGenerated, Operation, UserId, ClientIP, ExternalUser = OfficeObjectId
| where isnotempty(ExternalUser) or UserId contains "#EXT#"
| join kind=inner (
    OfficeActivity
    | where OfficeWorkload == "MicrosoftTeams"
    | where Operation == "MessageCreated"
    | parse MessageText with * "content: " Content
) on TimeGenerated
| where Content has_any (SupportKeywords)
| summarize count() by TimeGenerated, UserId, ExternalUser, Content
| order by TimeGenerated desc

KQL Query: Detect Quick Assist Execution Post-Teams Activity

This query looks for the execution of quickassist.exe shortly after a Teams activity, which may indicate a social engineering attempt in progress.

DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName == "QuickAssist.exe"
| project DeviceName, AccountName, Timestamp, InitiatingProcessFileName, InitiatingProcessCommandLine
| join kind=inner (
    OfficeActivity
    | where OfficeWorkload == "MicrosoftTeams"
    | where Operation == "TeamsSessionStarted"
    | project TeamsTime = TimeGenerated, UserId
) on $left.AccountName == $right.UserId
| where Timestamp between (TeamsTime - 5min) .. (TeamsTime + 10min)
| project Timestamp, DeviceName, AccountName, TeamsTime

Remediation

Protecting your organization requires a combination of technical configuration controls and user awareness. Implement the following steps immediately:

1. Restrict External Communication in Teams

Reduce the attack surface by limiting who can communicate with your internal users.

• Action: Navigate to the Teams Admin Center > Users > External access.
• Configuration:
  • Disable "Let Teams users communicate with Skype users" if not required.
  • Set External access to "Allow only specific external domains" and explicitly allowlist trusted partners. Block all other domains by default.

2. Disable or Restrict Quick Assist

If Quick Assist is not a business requirement, remove it to eliminate the primary vector for remote control.

PowerShell Script to Remove Quick Assist Capability:

# Check if Quick Assist is installed
Get-WindowsCapability -Online -Name App.Support.QuickAssist*

# Remove Quick Assist
Get-WindowsCapability -Online -Name App.Support.QuickAssist* | Remove-WindowsCapability -Online


*Note: This can be deployed via Group Policy (GPO) or Intune as a remediation script across the fleet.*

3. Configure Conditional Access (CA) Policies

• Action: Implement Conditional Access policies that require compliant devices or trusted locations for access to Microsoft 365 administration tools and Teams.
• Context: This prevents attackers using compromised credentials from easily accessing Teams from unknown IP addresses or devices.

4. User Education and Verification Processes

• Training: Immediately brief users on this specific campaign. Emphasize checking the "External" tag on any Teams chat.
• Process: Establish a policy that IT Support will never ask users to initiate a remote support session via an unsolicited Teams chat. All support requests must go through a designated ticketing portal or a known internal phone number.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub