Microsoft Threat Intelligence uncovered an intrusion campaign that begins with a message or call via Microsoft Teams from an external party impersonating information technology or help desk employees. The attacker attempts to persuade the employee to bypass the external contact warning and grant interactive control of the device through tools such as remote support sessions or Quick Assist, then uses PowerShell to download and silently install a malicious MSI package.
According to Microsoft, the campaign does not exploit a technical vulnerability in Microsoft Teams; rather, it relies on social engineering and persuading the user to bypass existing security measures. Its danger lies in the fact that the entry point appears to be a familiar support procedure, while granting the attacker interactive access backed by the user’s credentials to a device inside the organization.
Attack Chain Uses Trusted Tools
After the MSI package is installed, the campaign places a script loader and an encrypted file containing a JavaScript implant in the LocalAppData folder. If Node.js is not installed on the device, the package downloads a legitimate portable version of the runtime from the official Node.js distribution, then uses it to decrypt and run the implant.
The process is launched through PowerShell, cmd.exe, or WScript, and uses per-user persistence mechanisms, such as a Run registry value or a shortcut in the Startup folder named EdgeUpdate. The implant communicates with command and control through randomized periodic HTTPS requests and receives JavaScript tasks capable of executing commands, inspecting the device, security software, and virtual environment, and periodically capturing screenshots of the desktop.
The samples analyzed by Microsoft also contained disabled logic to query a smart contract on the Ethereum network to obtain an updated address for the command-and-control server. The company explained that the contract does not store or execute the malicious payload, and that the recovered samples used a fixed fallback address.
From the Infected Device to Identity Systems
The activity does not stop at installing the implant. The operators used native commands and ADSI queries to enumerate domain accounts, servers, and users, then executed additional payloads through rundll32.exe. The implant subsequently initiated WinRM connections over TCP port 5985 to a large number of domain-joined systems, including file, database, and application servers, as well as domain controllers and certificate authorities.
This movement represents a practical shift from deceiving a single user to attempting to expand control within the organization. The material does not establish that the campaign actually deployed ransomware or stole data, but it indicates that the reconnaissance and movement toward identity systems are consistent with stages preceding later objectives such as data theft, extortion, or ransomware deployment.
Why Does This Matter?
The campaign demonstrates that trust in a legitimate tool can become more dangerous than an unknown executable. The presence of Microsoft Teams, Node.js, Windows Installer, and WinRM in the chain does not mean these tools are malicious, but it makes relying solely on allowlists of permitted programs insufficient. The most important indicator is an unusual behavioral sequence: an urgent external contact, followed by a remote support session, followed by the execution of PowerShell or cmd.exe, and the installation of an MSI or execution of Node.js from a user-writable path.
Microsoft recommends verifying any external support request through a known internal channel, restricting external collaboration in Teams to trusted domains, enforcing multifactor authentication and conditional access, and monitoring remote support tools. It also suggests enabling attack surface reduction rules and network and web protection, limiting WinRM to authorized management workstations, and generating alerts when it is launched from a user context or a nonadministrative process.
Organizations that find indicators associated with this campaign should treat the affected device as a potential access point to the network and prioritize investigation and rotation of credentials that could have been accessed from it, including domain administrator accounts where appropriate.