Microsoft Threat Intelligence is tracking a human-operated intrusion pattern that starts with a familiar business workflow: a user receives an external Microsoft Teams message or call from someone pretending to be IT support, then is coached into starting a remote-assistance session. From there, the attacker uses legitimate administrative tools to turn a helpdesk pretext into enterprise access.

The important lesson is not “Teams is broken.” The risk is that collaboration platforms, remote support utilities, Windows Installer, scripting hosts, Node.js, and WinRM can all be abused together when an attacker convinces a user to approve the first step.

Original source: Microsoft Security Blog — Impersonating IT support: how threat actors turn a remote session into enterprise-wide access.

What Microsoft reported

The campaign begins with external Teams contact where the attacker poses as helpdesk or IT personnel. The lure can be framed as an account verification, security update, spam-filter update, or urgent support issue. In some cases, voice interaction is used to keep instructions out of written chat logs and increase pressure on the user.

Once trust is established, the user is guided into granting remote control through a legitimate remote support workflow. That interactive access gives the operator a live keyboard on an internal endpoint with the victim’s trusted session and network position.

Microsoft describes the next stage as a quiet software installation. During the remote session, the actor runs PowerShell to download a malicious MSI package from cloud storage and installs it with a silent Windows Installer switch. The installer stages a script loader and encrypted payload in the user profile, then uses a portable Node.js runtime to execute an obfuscated JavaScript implant.

That choice matters. A signed, legitimate runtime can make malicious activity look less obvious than a standalone unknown executable. The implant then polls over HTTPS for tasking, performs host and domain reconnaissance, captures screenshots, executes additional payloads through trusted Windows binaries, and supports lateral movement attempts over WinRM toward internal servers, domain controllers, and certificate authorities.

Why this matters for SMBs and government contractors

This is the exact kind of intrusion chain that can hurt smaller organizations because every step can look like normal business:

  • An external chat message looks like routine collaboration.
  • A remote support session looks like helpdesk work.
  • PowerShell, msiexec, cmd.exe, WScript, Node.js, and rundll32 are legitimate tools.
  • WinRM traffic may be allowed for administration.
  • Cloud storage downloads may blend into expected network use.

For government contractors, this is also a CMMC-relevant problem. If a user workstation can be converted into a staging point for domain discovery, credential-backed lateral movement, screenshot capture, or access to project data, the issue is bigger than phishing awareness. It becomes an access-control, monitoring, incident-response, and privileged-administration problem.

The defensive pattern: treat remote support as privileged access

Remote assistance should not be treated as casual desktop convenience. It is a path to interactive control and often deserves the same governance as privileged administration.

Organizations should define who is allowed to initiate support, what tools are approved, how identity is verified, and what actions are never acceptable during a support session. A real helpdesk should not need a user to run arbitrary PowerShell commands, install unknown MSI files, paste scripts into terminals, or approve unexplained elevation prompts.

Controls that would raise the cost of this attack

1. Restrict external collaboration by default

Review Microsoft Teams external access and guest collaboration settings. If the business does not need broad external tenant messaging, narrow it. If external collaboration is required, train users to treat first-contact support requests from outside the organization as suspicious until verified through a known channel.

2. Create a helpdesk verification rule

Give users a simple rule: if someone claims to be IT support and asks for remote access, the user must verify through an internal ticket, known phone number, or approved support portal. This needs to be operationally easy or users will bypass it under pressure.

3. Control remote support tools

Inventory approved remote management and monitoring tools. Block or alert on unexpected remote-assistance binaries, newly installed RMM agents, or support sessions launched from unusual user groups. If Quick Assist or similar tools are not needed, disable or restrict them through policy.

4. Watch the post-support process tree

The signal is often the sequence, not a single binary. A remote support process spawning PowerShell, cmd.exe, msiexec, WScript, or rundll32 should be reviewed. A silent MSI install from a user-writable path or cloud storage URL deserves immediate attention.

5. Lock down user-writable execution

Attackers favor LocalAppData because it is writable without administrator rights. Use application control, attack surface reduction rules, and EDR detections for script loaders, portable runtimes, and nonstandard extensions executed from user profile directories.

6. Monitor Node.js as a potential living-off-trusted-runtime path

Node.js is common in developer environments, but it is not normal on every finance, HR, or front-office workstation. Watch for newly dropped or renamed Node.js runtimes, Node launched from LocalAppData, Node executing content through standard input, and Node child processes invoking Windows discovery commands.

7. Constrain WinRM

WinRM should be limited to approved administrative hosts and accounts. Workstations should not be able to broadly initiate WinRM connections to domain controllers, certificate authorities, file servers, or application servers. Segmentation and host firewall rules can turn lateral movement into a noisy failure instead of a domain-wide path.

8. Centralize logs before the incident

This attack chain can involve Teams events, endpoint process telemetry, MSI installation logs, PowerShell activity, remote support session evidence, DNS/HTTPS egress, and WinRM connections. If those logs are scattered or short-lived, responders will lose the timeline right when it matters most.

Hunting ideas

  • External Teams contact followed by Quick Assist or another remote-support session.
  • Remote-support process spawning PowerShell, cmd.exe, msiexec, WScript, rundll32, or Node.js.
  • Silent MSI installs from Downloads, Temp, LocalAppData, or cloud-storage URLs.
  • New Run keys or Startup-folder entries with update-themed names launching scripts or portable runtimes.
  • Node.js executing from user-writable paths on non-developer endpoints.
  • Endpoint reconnaissance bursts: domain user enumeration, server discovery, installed AV checks, virtualization checks, and screenshot capture.
  • WinRM traffic from ordinary user workstations to servers, domain controllers, or certificate authorities.

Bulwark Black assessment

This campaign is a good example of where “phishing defense” is too narrow a label. The attacker is not only trying to steal a password. They are trying to borrow the user, borrow the helpdesk workflow, borrow trusted Windows tooling, and then borrow internal administration paths.

The right response is layered: reduce external contact paths, make support verification easy, restrict remote tools, detect suspicious process chains, limit user-writable execution, and constrain administrative protocols like WinRM. If those controls are in place, a convincing social-engineering call can still happen — but it is much less likely to become domain compromise.

For SMBs and contractors, the practical starting point is simple: write down the approved remote support process, block everything else you can, and hunt for remote support sessions that immediately turn into scripting, installers, or lateral movement.