That Help Desk Messaging Your Users on Teams Is Not Yours

A user gets a Teams message from "Microsoft Security Team" offering to fix the spam suddenly flooding their inbox. The display name looks right. The domain looks right at a glance. Twenty minutes later an attacker has a remote session on their laptop.

None of that required a single compromised account in your tenant. It works because Microsoft 365 lets external users open Teams chats with your users by default. This post walks through the kill chain and a four-control runbook to shut it down.

How the fake help desk attack works#

A typical run of this attack looks like this:

1. The attacker sets up a new Microsoft 365 tenant to look like a legitimate, trusted organization.
2. Knowing a user's email address, they sign that user up for dozens of newsletters, flooding the inbox with spam.
3. They reach out in Teams chat impersonating a help desk member offering to fix the spam problem. Default Microsoft 365 settings allow any external user to start that chat.
4. They talk the user into accepting a remote access session via Quick Assist (a remote access tool natively installed on Windows), ScreenConnect, TeamViewer, or similar.
5. With hands on the device, they tamper with protections like antivirus, install malicious payloads, or walk the user through an adversary-in-the-middle flow to compromise the account further.

The spam flood is the clever part. It manufactures the exact problem the fake help desk then offers to solve.

What Microsoft 365 allows out of the box#

With default settings, any user anywhere can search for an external email address in Teams and learn whether that account exists.

Found and available to chat:

Not found:

Users who receive messages from non-whitelisted external participants do get a consent warning before the chat opens. Given the average user's track record with warning screens, expect plenty of them to click straight through.

Microsoft has also added a layer of its own. As of November 2024, Teams shows default warnings when Microsoft suspects a chat is phishing or impersonation:

In this example, the attacker set their display name to "Microsoft Security Team" and used a domain that reads like Microsoft.com but is actually Mircosoft..com. Useful signal, but the user can still bypass the screen themselves, which is not where you want your defense to end.

Four controls that break the kill chain#

Control 1: Whitelist external chat instead of allowing it all#

The strongest move is blocking external users from chatting with your organization unless they are approved and whitelisted.

Microsoft documents both scenarios:

1. Managed organizations: manage external meetings and chat with trusted Microsoft 365 organizations (opens in new tab)
2. Unmanaged organizations: manage chats and meetings with external Teams users not managed by an organization (opens in new tab)

Control 2: Remove the remote access tools you do not use#

Quick Assist is enabled by default on Windows devices and features heavily in this attack, but any remote access tool works: ScreenConnect, TeamViewer, AnyDesk. Make sure only your approved remote access tool is enabled on the device and remove the rest.

Microsoft's guidance for removal: Disable Quick Assist within your organization (opens in new tab).

You can also hunt for the pattern in Defender. This KQL query surfaces external one-on-one Teams chats followed by suspicious RMM activity on the same user:

let interestingUsers = DeviceProcessEvents
| where Timestamp > ago(1h)
| where isnotempty(InitiatingProcessAccountObjectId)
| where FileName has_any ("quickassist.exe", "anydesk.exe", "teamviewer_service.exe") // Multiple RMM tools can be abused here
| project InitiatingProcessAccountUpn;
CloudAppEvents
| where Timestamp > ago(1d)
| where Application == "Microsoft Teams"
| where ActionType == "ChatCreated"
| where isempty(AccountObjectId)
| where RawEventData.ParticipantInfo.HasForeignTenantUsers == true
| where RawEventData.CommunicationType == "OneOnOne"
| where RawEventData.ParticipantInfo.HasGuestUsers == false
| where RawEventData.ParticipantInfo.HasOtherGuestUsers == false
| where AccountId has "@"
| extend TargetUPN = tolower(tostring(RawEventData.Members[1].UPN))
| where TargetUPN in (interestingUsers)
| extend VictimTenant = tostring(RawEventData.OrganizationId)
| extend AttackerTenant = RawEventData.Members[0].OrganizationId
| extend AttackerUPN = RawEventData.Members[0].UPN
| extend AttackerName = RawEventData.Members[0].DisplayName

Control 3: Turn on tamper protection#

Tamper protection in Microsoft Defender for Endpoint and Defender for Business stops security settings, such as virus and threat protection, from being disabled or changed. If the attacker does reach the device through a remote session, this blocks the next move: turning off AV and dropping malware or ransomware.

You can enable it from the Security admin center or Intune. It does require devices to be enrolled in Defender for Business or Defender for Endpoint.

Documentation: Protect security settings with tamper protection (opens in new tab).

Control 4: Teach users what a real help desk never does#

Tech support scams belong in your security awareness training, for your team and your customers' end users. Microsoft maintains a solid primer on what to watch for: Protect yourself from tech support scams (opens in new tab).

Where this runbook ends and defense in depth begins#

These four controls cover the specific kill chain, not everything an attacker can try. Evaluate your security stack for the additional layers that compound them:

• Ensuring users are not local admins on their devices
• Link and attachment protections in Defender for Office 365
• Application whitelisting and elevation control on devices
• Phishing-resistant MFA

Each one makes a different step of the attack more expensive. Stack enough of them and the fake help desk moves on to an easier tenant.