A Microsoft Teams call is not proof that the caller is IT.

Before an employee shares their screen, grants remote control, or runs a command, they need a reliable answer to a simple question: is this person really our IT support?

Microsoft traces the risk beyond one remote session

In its September 2 report, Microsoft describes attackers impersonating IT support through external Teams accounts. They persuade employees to grant remote control through Teams or Quick Assist, then install malware, examine the internal network, and move toward servers and identity systems, including domain controllers.

This is not a reported Teams vulnerability. Legitimate support tools give an intruder a way in when the employee trusts the person operating them. Microsoft's recommendations include confirming unsolicited support requests through an established internal channel before allowing remote access.

That is the point I would bring into a support-policy review. Telling employees to use approved software is not enough. They also need a practical way to check who is asking them to use it.

Spring Ring borrowed trust from Microsoft Teams

Unit 42's Spring Ring research illustrates the same trust problem. External Teams identities posing as corporate helpdesks approached more than 150 employees across at least 10 organizations between January and April 2026.

Voice calls steered employees toward remote-support tools or tailored malware. One variant attempted to reach a domain controller through an NTLM relay attack. Unit 42 says its protections blocked the two observed intrusion attempts before the attackers achieved their objectives.

Microsoft does not identify its reported activity as Spring Ring. The reports support the same operational lesson; they do not establish that the campaigns are the same.

An external warning is not a verification workflow

Teams warned Spring Ring recipients that the conversation came from outside their organization. The caller still tried to persuade them to continue.

That warning matters. But a caller can offer a plausible explanation: an outsourced helpdesk, a migration team, or a temporary support account.

An onmicrosoft.com address or professional display name does not establish that the person is your IT support or is authorized to control your device.

Training helps employees recognize the risk. A verification workflow gives them something concrete to do about it.

Verify the caller through a trusted company app

The employee should open a known company-controlled destination, not rely on a link, telephone number, or code supplied only by the person claiming to be IT.

This is why we built IT caller verification into Fctr. IT starts a request in Fctr Portal after meeting the organization's verification policy. The employee independently opens Fctr in Teams or Outlook, chooses Check pending requests, and reviews the caller details and reason.

The caller says the phrase. The employee selects the matching choice and submits without reading the choices back to the caller. If none matches, or the employee is not on a support call, they reject the request.

The conventional direction still matters: the helpdesk verifies an employee before recovery or account actions. These attacks show why verification must also work in reverse, so employees can verify IT and support callers.

Verification establishes who is participating. It does not give blanket permission to control an endpoint, install software, reset an account, or change an authenticator. Those actions still require their own policy and authorization.

Verify the caller and constrain what happens next

Organizations should still restrict Microsoft Teams external access where practical, control approved remote-support software, and detect suspicious files, PowerShell, and endpoint activity. Microsoft’s Teams security guidance includes domain restrictions and granular external-access policies that can reduce exposure.

Those controls protect the channel and endpoint. Fctr’s two-way caller verification addresses the human trust decision between them: whether the person asking the employee to act is actually an authorized member of IT or support.

Fctr does not inspect downloads, detect lateral movement, or replace endpoint protection and incident response. It addresses the caller's identity earlier in the interaction—before the employee grants remote access or runs anything.

The takeaway from both reports is simple:

A support request can arrive through Microsoft Teams. Trust begins only after the caller is verified.

Sources

• Microsoft Security Research — Impersonating IT support: how threat actors turn a remote session into enterprise-wide access
• Palo Alto Networks Unit 42 — Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams
• Microsoft Learn — Reduce the attack surface for Microsoft Teams
• Help Net Security — Vishing campaign abuses Microsoft Teams to give attackers a foothold in company networks