Fake IT Support on Teams Tricks Users Into Remote Access

How the attack worked

This campaign uses Microsoft Teams external collaboration features rather than traditional email phishing. The attacker contacts an employee posing as internal IT or helpdesk staff, using lures such as a security update, spam filter update, or a warning about account deactivation. Once trust is established, the victim is coaxed into granting an interactive remote session, either by approving a "request control" prompt during a Teams screen share or by opening Quick Assist and reading back a connection code.

In some cases, the operation adds a phone call to reinforce the pretext. This voice phishing layer increases trust and can also keep malicious instructions or links out of chat logs, making the interaction harder to review after the fact.

Once remote control is granted, the attacker moves quickly. PowerShell is used within the session to download a malicious MSI package from attacker-controlled cloud storage and install it silently, with installer UI suppressed so the victim sees no visible prompts. The installer is disguised with benign, update-themed names like "devfix" or "Hotfix" to reinforce the support pretext. From there, the attacker performs host and Active Directory reconnaissance and pivots laterally using WinRM toward high-value systems such as domain controllers and certificate authorities.

Why it succeeded

The attack succeeds because it uses a legitimate enterprise workflow, an internal-looking Teams message asking for routine support, instead of an obviously suspicious email. The urgency baked into the pretext (account deactivation, required updates) pushes users to bypass normal caution. Because the victim voluntarily grants access through a legitimate remote support tool, the initial access itself does not look like a compromise; it looks like a support session.

What to watch for

• Unexpected messages from external Teams contacts offering IT support
• Urgent language about account deactivation or mandatory security updates
• Requests to approve remote control or read back a Quick Assist code
• A remote-assist session that quickly opens PowerShell or cmd.exe
• Software installs that show no visible installer window or prompts
• Phone calls that discourage written instructions or bypass normal ticketing

How to build resistance

Employees should treat unsolicited IT support contact on Teams as suspicious and verify it through the organization's normal internal helpdesk channel before engaging. No remote control request should be approved unless the employee personally initiated the support ticket and confirmed the technician's identity. Security teams can reinforce this by training staff to recognize the urgency-driven pretext, watching for the process pattern of a remote-assist session followed immediately by command-line tools, and encouraging users to pause and verify rather than act quickly under pressure.

How do attackers impersonate IT support on Microsoft Teams?

They abuse Teams external collaboration to contact employees, posing as helpdesk staff with lures like account verification or urgent security updates, then coach victims into approving a remote control request or Quick Assist session.

What happens after the attacker gains remote access?

The attacker uses PowerShell within the session to silently install a malicious MSI disguised as an update, then performs Active Directory reconnaissance and moves laterally via WinRM toward high-value systems like domain controllers.

What are the red flags of this attack?

Warning signs include messages from external Teams tenants, urgency about account deactivation, requests to grant interactive remote control instead of using normal IT ticketing, and installers that run with no visible prompts.

How can employees protect themselves from this tactic?

Verify any unexpected IT support contact through your normal internal helpdesk channel and never approve remote control requests unless you personally initiated the support ticket.