The Attack: From a Teams Chat to Domain Controller Access
An operator impersonating internal IT support contacts an employee through Microsoft Teams from an external tenant. A little social pressure gets the target to approve a remote assistance session—either through Teams screen-share “request control” or by reading back a Quick Assist code. Once the session is live, the operator runs PowerShell to pull a malicious Windows Installer (MSI) package from cloud storage and installs it silently with msiexec. The victim never sees an install prompt.
The MSI stages a portable Node.js runtime pulled from the official distribution alongside an encrypted script. The operator now has a signed interpreter running attacker code without dropping an unsigned binary. The Node.js implant polls a command and control server over randomized HTTPS, captures periodic screenshots, enumerates the host and Active Directory, and uses Windows Remote Management (WinRM) on TCP 5985 to move laterally toward file servers, database servers, and finally the domain controllers and certificate authorities that anchor identity.
Microsoft documented this campaign and mapped the initial access to MITRE ATT&CK technique T1566.003—spearphishing via service. They’re careful to note this isn’t a Teams vulnerability. The platform shows external-tenant labels, Accept and Block prompts, and phishing indicators. The problem is that every control sits in front of a single human decision, and once that decision is made, nothing downstream looks abnormal to signature-based tools. Every binary is signed. WinRM is how your administrators pivot between systems. The operator borrowed trusted tooling, so endpoint detection has little to bite on.
Why Signature-Based Controls Missed It
The recovered implants even carried dormant code to fetch an updated C2 address from an Ethereum smart contract—a resiliency feature the operators left switched off. The reconnaissance showed patience: randomized sleep jitter, quiet reachability probes instead of noisy scanning. Pointing WinRM at domain controllers and certificate authorities is the tell that matters, because that identity backbone is what attackers map before data theft, extortion, or ransomware deployment.
Endpoint tools that hunt for known malware have nothing to detect. The operator used a signed Node.js runtime, pivoted over WinRM the same way administrators do, and ran follow-on code through rundll32 and trusted Windows script hosts. The signal to hunt for is a sequence: a remote-assist process tree immediately followed by PowerShell, or a WinRM connection starting from a user-context process.
How FileSure Defend Would Have Blocked It
FileSure Defend operates at the Windows kernel level, intercepting file operations before they reach the file system. The attack chain depends on writing files to disk—first the MSI payload, then the Node.js runtime and encrypted scripts, and later files written to remote shares during lateral movement. Block those file writes, and the reconnaissance, lateral movement, and domain controller access never happen.
Block the Initial Payload Delivery
The most upstream intervention point is the MSI write during the remote assistance session. A FileSure rule blocks remote access tools from writing executable or installer files to local drives:
- File name filter:
*.msi;*.exe;*.dll;*.ps1;*.bat;*.cmd;*.vbs;*.js - Program name filter:
\quickassist.exe;\msra.exe;\msiexec.exe(when running under remote context) - Operations: Write, Create
- Drive type: Hard drives
- Result: Remote assistance tools cannot write executable payloads, installers, or scripts to local drives. The MSI never lands, so the Node.js implant, reconnaissance, and lateral movement never start.
Block Remote Lateral Movement File Writes
If an implant somehow lands on a workstation, FileSure’s REMOTE ACCESS filter blocks the lateral movement phase. When the operator attempts to write files to file servers or domain controllers via SMB shares, the kernel intercepts and denies the remote write operation:
- File name filter:
*.exe;*.dll;*.bat;*.cmd;*.ps1 - Program name filter:
REMOTE ACCESS(exact, case sensitive—matches any remote SMB write attempt) - Operations: Write, Create
- Drive type: Hard drives
- Install type: Servers
- Result: No remote machine can write executable files to the server’s local drives through network share access. Local processes on the server operate without restriction. Lateral movement via compromised workstations is blocked at the file system layer on the target server.
The operator borrowed legitimate tooling, so signature-based detection had nothing to catch. FileSure doesn’t care whether the binary is signed or the process is trusted—it controls what file operations that process can perform. The MSI write is denied. The implant never stages. The domain controllers stay out of reach.
Start a free 21-day trial at bystorm.com and see kernel-level file operation control block the delivery vectors signature-based tools miss.
Source: IT Support Impersonation Turns a Teams Chat Into Domain-Controller Access
Category: Threat Intelligence
Tags: it support impersonation, social engineering, lateral movement, winrm, remote access abuse, kernel filter driver, file system security, domain controller compromise
