Defending Against Microsoft Teams Social Engineering: Blocking IT Impersonation Attacks

Introduction

Security Operations Centers (SOCs) are observing a significant shift in how threat actors conduct social engineering attacks. While email phishing remains a persistent threat, attackers are increasingly moving to real-time communication platforms like Microsoft Teams.

The Rapid7 MDR team has highlighted a surge in campaigns where threat actors impersonate internal IT departments. By convincing users to launch legitimate tools like Quick Assist, attackers gain remote access to the endpoint. This attack vector is particularly dangerous because it bypasses traditional email gateway filters and exploits the high level of trust employees place in internal collaboration tools.

Technical Analysis

The core of this threat lies in the default configuration of Microsoft Teams regarding external access. By default, many organizations allow users to communicate with any external Teams user. This creates an "open door" for attackers, effectively making Teams as risky as an email server without a spam filter.

The Attack Flow:

1. Initial Contact: An external threat actor messages an internal user via Teams, often posing as IT support or a helpdesk technician.
2. The Hook: The attacker claims the user's account is compromised, their password needs resetting, or their device requires maintenance.
3. Payload Delivery: The attacker persuades the user to launch "Quick Assist" (a built-in Windows tool) or install remote management software.
4. Compromise: Once the user grants access via Quick Assist, the threat actor gains control of the endpoint, allowing them to deploy malware, exfiltrate data, or move laterally across the network.

Affected Systems:

• Platform: Microsoft 365 (Teams tenant)
• Endpoints: Windows 10/11 devices (Quick Assist)
• Severity: High. This method bypasses many perimeter defenses and relies heavily on user interaction.

Vulnerability Root Cause: The vulnerability is not a software bug in the traditional sense, but a configuration weakness. Allowing unverified external tenants to message internal users provides a vector for social engineering that lacks the scrutiny applied to inbound emails.

Defensive Monitoring

Defenders must implement strict monitoring to detect when external communication leads to suspicious process execution. Below are detection mechanisms using Microsoft Sentinel (KQL) and PowerShell to audit your current Teams configuration.

Detecting Quick Assist Execution

The following KQL query can be used in Microsoft Sentinel or Microsoft Defender to detect the execution of Quick Assist. While this tool is legitimate, it is rarely used by average employees without prior context. Correlating this with Teams logs (if available) is ideal, but monitoring process creation is the first line of defense.

DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName =~ "quickassist.exe" or ProcessVersionInfoOriginalFileName =~ "QuickAssist.exe"
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, FolderPath
| order by Timestamp desc

Auditing Teams External Access Policies

Use this PowerShell script to check your organization's current federation and external access settings. This helps identify if your environment is open to external communication by default.

# Connect to Microsoft Teams PowerShell module
# Connect-MicrosoftTeams

# Get the current Federation Configuration
$FederationConfig = Get-CsTenantFederationConfiguration

Write-Host "--- Current Teams Federation Settings ---" -ForegroundColor Cyan
Write-Host "AllowFederatedUsers:" $FederationConfig.AllowFederatedUsers
Write-Host "AllowPublicUsers:" $FederationConfig.AllowPublicUsers
Write-Host "RestrictTeamsConsumerToTeamsConsumer:" $FederationConfig.RestrictTeamsConsumerToTeamsConsumer

# Check External Access Policies
$Policies = Get-CsExternalAccessPolicy

Write-Host "\n--- External Access Policies ---" -ForegroundColor Cyan
foreach ($Policy in $Policies) {
    Write-Host "Policy Identity:" $Policy.Identity
    Write-Host "EnableFederationAccess:" $Policy.EnableFederationAccess
    Write-Host "EnablePublicCloudAccess:" $Policy.EnablePublicCloudAccess
    Write-Host "EnableOutsideAccess:" $Policy.EnableOutsideAccess
    Write-Host "-------------------------------------"
}

Remediation

To protect your organization from these campaigns, Security Arsenal recommends a defense-in-depth approach focusing on configuration hardening and user awareness.

1. Restrict External Teams Access

The most effective remediation is to limit who can communicate with your internal users.

• Allow List Only: Configure your Microsoft Teams External Access policy to only allow communication with specific, trusted domains. Block all other external domains by default.
• Disable External Chat (If Possible): For organizations with low external collaboration requirements, consider blocking external Teams messages entirely.

PowerShell Command to Restrict Access:

# Example: Set the Global policy to block federation (Use with caution)
Set-CsExternalAccessPolicy -Identity Global -EnableFederationAccess $false

2. Configure "External" Tags Visibility

Ensure that the "External" label is clearly visible in the Teams UI. This visual cue is often subtle; ensure users are trained to look for it before engaging in technical support conversations.

3. User Awareness and Training

Update your security awareness training to include specific modules on "Vishing" (Voice Phishing) and chat-based support scams.

• Verification Protocol: Establish a policy where IT support will never ask users to install remote access software via an unsolicited Teams chat.
• Out-of-Band Verification: Instruct users to verify the identity of the caller by calling the official IT support number listed on your internal portal, not the number provided by the "technician" in the chat.

4. Restrict Quick Assist via Group Policy

If Quick Assist is not a business-critical tool for your environment, consider disabling it for standard users via Group Policy Objects (GPO) or Intune.

Intune Configuration (URI): To disable Quick Assist using a Windows 10/11 Settings Catalog profile in Intune, you can target the following path or use a Win32 app to remove it.

PowerShell Removal Command (for specific images/user profiles):

# Quick Assist is an appx package. To remove it for the current system (requires admin):
Get-AppxPackage -AllUsers *QuickAssist* | Remove-AppxPackage

Related Resources

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