Your helpdesk doesn't ask users to install software through a remote session initiated via Teams chat. But a threat actor will.
Microsoft Threat Intelligence has documented a campaign exploiting Microsoft Teams' external collaboration features. Attackers impersonate IT support, gain remote access through legitimate tools, and establish persistent command-and-control infrastructure. This isn't just phishing for credentials. It's a multi-stage operation aiming to map your Active Directory, access domain controllers, and prepare for data theft or ransomware.
If your security awareness program still treats collaboration platforms as safe internal spaces, this checklist will help you close that gap.
Prerequisites
Before implementing these controls, ensure you have:
- Administrative access to Microsoft Teams tenant settings, You'll need Global Administrator or Teams Administrator roles to enforce external collaboration policies.
- Endpoint detection and response (EDR) telemetry, You need visibility into process execution, command-line arguments, and file-system activity on user endpoints.
- Security awareness training platform, Preferably one that supports simulated phishing and custom scenarios.
- Incident response playbook ownership, Someone must own the decision tree for suspected remote-access compromise.
Compliance Checklist
External Collaboration Controls
☐ 1. Configure Teams external access to display clear tenant labels
Users must see visual indicators when communicating with external tenants. Ensure every external Teams message displays "External" or the source tenant name. Test by initiating a chat from a personal Microsoft account to a work account.
☐ 2. Disable anonymous meeting join for internal meetings
Prevent unauthenticated users from joining Teams meetings without explicit approval. Meeting organizers should see a lobby screen showing external participants waiting for admission. Verify in Teams admin center under Meeting policies > Participants & guests > Anonymous users can join a meeting is set to Off.
☐ 3. Block file sharing from external tenants in Teams chats
External participants shouldn't send executable files or installers through Teams. Configure under Teams admin center > Messaging policies > File sharing from external tenants.
Remote Access Tool Governance
☐ 4. Maintain an approved remote support tool inventory
Document every legitimate remote assistance application authorized for use. A single-page reference sheet should list each approved tool, its primary use case, and the team authorized to initiate sessions. Update quarterly and distribute to security operations.
☐ 5. Deploy application control policies for remote management tools
Only IT support personnel on managed devices should launch approved remote-access software. Implement using Windows Defender Application Control or AppLocker.
☐ 6. Alert on Quick Assist execution outside IT service desk hours
EDR should generate high-priority alerts when remote-access tools run during off-hours or from non-IT accounts. Configure detection rules in your EDR platform.
Script Execution and Installer Monitoring
☐ 7. Monitor PowerShell downloads followed by msiexec silent installation
Detect the pattern of PowerShell downloading files and immediately invoking msiexec with the /qn silent flag. Tune to exclude known software deployment pipelines.
☐ 8. Restrict Node.js execution to developer workstations
Node.js runtime shouldn't execute from user-writable directories on non-development endpoints. Implement through application control or EDR behavioral rules.
☐ 9. Block execution of renamed legitimate binaries
Prevent execution of files whose internal metadata (OriginalFilename) doesn't match the on-disk filename. Test by renaming cmd.exe to test.exe and attempting execution.
Active Directory Reconnaissance Detection
☐ 10. Alert on ADSI queries from non-administrative endpoints
Standard user workstations shouldn't enumerate domain controllers, certificate authorities, or perform bulk user lookups. Configure through EDR telemetry or Windows event log monitoring (Event ID 4662 for directory service access).
☐ 11. Monitor WinRM connections to domain controllers from user endpoints
Standard users shouldn't initiate Windows Remote Management sessions to identity infrastructure. Network detection tools or EDR network telemetry should flag the source IP, destination, and initiating process.
Security Awareness Training
☐ 12. Simulate IT impersonation through Teams external contacts
Quarterly phishing simulations must include Teams-based social engineering scenarios. Metrics should track who accepts external contacts, who reports suspicious requests, and who grants remote sessions.
☐ 13. Train users to verify IT requests through out-of-band channels
Security training should explicitly teach users to confirm support requests by calling the service desk directly. Users should complete a quiz requiring them to identify the correct verification process.
Common Mistakes
Assuming Microsoft Teams is an internal-only platform. External collaboration is enabled by default. Your users can receive chats from any Microsoft tenant unless you explicitly restrict it.
Trusting legitimate tools in unexpected contexts. Node.js, PowerShell, and msiexec are signed Microsoft or open-source components. The threat isn't the tool; it's the tool executing from %LOCALAPPDATA% at the direction of an external operator.
Failing to connect remote-access events to subsequent reconnaissance. A Quick Assist session followed 10 minutes later by ADSI queries and WinRM connections is the attack chain in progress. Alert fatigue causes teams to investigate these events separately instead of correlating them.
Skipping application control because it's "too restrictive." Application control doesn't require blocking everything. Start with high-risk paths: executables in user-writable directories, renamed binaries, and remote-access tools outside IT personnel.
Next Steps
After completing this checklist, your immediate actions:
Run a tabletop exercise simulating a Teams-based IT impersonation scenario. Walk through your detection, alert escalation, and containment process. Identify gaps before a real incident.
Review your remote-access tool telemetry for the past 30 days. Identify any Quick Assist or third-party RMM sessions initiated outside your IT service desk. Investigate anomalies.
Update your incident response playbook to include a decision tree for suspected remote-access compromise: isolate the endpoint, revoke user credentials, audit WinRM connections from the affected system, and check domain controllers for lateral movement indicators.
Schedule a quarterly review of this checklist. Threat actors adapt their lures and tooling. Your controls and training scenarios must evolve with them.
The shift from email phishing to collaboration-platform social engineering isn't hypothetical. It's documented, it's active, and it hands external operators credential-backed access to your internal infrastructure. These controls won't eliminate human error, but they'll make it significantly harder for a threat actor to turn a single compromised user into enterprise-wide access.
