Microsoft Teams as APT Infrastructure: Why Legitimate Tools Became the Perfect C&C

UNC6692 deployed Snow malware via Teams webhooks as C&C infrastructure. Learn how attackers use legitimate tools and 6 controls for detection and response.

Microsoft Teams as APT Infrastructure: Why Legitimate Tools Became the Perfect C&C

When Mandiant researchers discovered the Snow malware campaign, they expected the typical indicators: suspicious domains, port scanning, unusual outbound traffic patterns.

Instead, they found something simpler and far more troubling: the adversary (UNC6692) was using Microsoft Teams as their command-and-control (C&C) infrastructure.

Snow wasn't communicating over underground forums or bulletproof hosting. It was using your organization's trusted collaboration platform to receive commands and exfiltrate data.

This is the new paradigm of APT operations: not breaking through your security, but leveraging the tools you've already allowed through.

How Snow + Teams Works

Step 1: Initial compromise via social engineering

UNC6692 targets users with convincing social engineering—phishing emails that look legitimate, or messaging that appears to come from colleagues. The attacker's goal: get the user to download and execute Snow malware.

Snow arrives as a seemingly legitimate file: a tool, a utility, a script. Once executed:

Step 2: Snow establishes presence

Snow deploys three components:

A browser extension (hooks browser traffic, can inject content, steal credentials)
A tunneler (establishes encrypted tunnels for data exfiltration)
A backdoor (enables remote command execution)

Step 3: Snow phones home via Teams

Instead of connecting to an attacker-controlled server, Snow connects to a Teams channel or chat room controlled by the attacker.

How? Teams webhooks.

Microsoft Teams supports incoming webhooks—URLs that allow external services to post messages into Teams channels. The attacker creates a throwaway Teams workspace, generates webhook URLs, and distributes them to Snow instances.

When Snow needs to receive commands, it makes an HTTPS request to the Teams webhook URL (a perfectly legitimate Microsoft domain), receives instructions in a Teams message, and executes them.

When Snow needs to exfiltrate data, it posts results back to the Teams webhook.

From a network perspective, this looks like normal Teams activity. Your firewall sees HTTPS traffic to teams.microsoft.com. Your proxy logs show the expected traffic patterns. Your IDS/IPS has no malicious signatures because the traffic is completely legitimate—it's actual Teams traffic.

The C&C channel is hidden in the public-ish chat messages or private messages within Teams.

Why This Is Devastating

Problem 1: You can't block Teams without breaking productivity

Microsoft Teams is essential collaboration infrastructure for most organizations. Blocking teams.microsoft.com is not feasible. By using Teams as C&C, the attacker ensures their communications will be allowed through even the most restrictive firewall.

Problem 2: Normal encryption defeats monitoring

Teams traffic is encrypted. You can't inspect the contents of Teams messages to look for command syntax or data exfiltration patterns. Even if you could, legitimate Teams communication volume is so high that anomalies would be buried in noise.

Problem 3: Detection requires application-layer analysis

Your network monitoring (IDS, firewall logs, proxy analysis) is blind to Teams C&C. To detect it, you'd need:

EDR visibility into Snow processes communicating with Teams
Email gateway analysis for initial compromise
Teams API logs showing unusual webhook activity
User behavior analysis to catch anomalous data posting

Most organizations don't instrument Teams for security analytics. It's collaboration infrastructure, not a security control point.

Problem 4: Attribution is harder

With traditional C&C over attacker-controlled domains, you can link the malware to infrastructure. With Teams webhooks, the infrastructure is Microsoft's. The attacker's only identifying trace is the Teams workspace they created—which can be deleted or abandoned at any time.

The Broader Ecosystem of Legitimate C&C

Snow using Teams isn't novel—it's a matured technique. Other legitimate services that APTs now use for C&C:

Slack: Webhooks and bots enable command execution and data exfiltration. Slack API logs might show bot activity, but legitimate bots are everywhere.

Discord: Free, ephemeral, globally distributed, encrypted. Perfect for botnets. Discord servers can be created and deleted without authentication. Defenders have largely given up monitoring Discord as C&C infrastructure.

GitHub: Attackers create repositories where malware checks for commands in code comments, pull requests, or release notes. GitHub traffic is trusted and unmonitored. Code analysis is difficult because the infrastructure looks like legitimate development workflow.

Google Drive / OneDrive: Malware checks for commands in shared documents. Exfiltration happens via legitimate file sharing. Your network monitoring sees normal cloud storage activity.

S3 / Azure Blob Storage: Attackers with proper AWS credentials can use public S3 buckets as dead-drop C&C. Hundreds of thousands of S3 access requests per day across your organization. Detecting one malicious access is like finding a specific packet in a data center.

O365 Calendar: Attackers post commands in calendar event titles or descriptions. Calendar sync happens regularly. Monitoring would require parsing calendar data for command patterns.

The pattern is clear: every SaaS tool your organization trusts is a potential C&C infrastructure.

Why Traditional Detection Fails

Your endpoint detection looks for:

Suspicious process spawning
Unusual network connections to attacker infrastructure
Registry modifications
Credential dumping
File system anomalies

Snow + Teams bypasses all of this:

Processes appear normal (Teams client connecting to Teams services)
Network connections go to Microsoft IP ranges (not attacker infrastructure)
Registry modifications are minimal (just malware installation)
Credential dumping might happen, but it's just one component
File system footprint is small (the malware itself, not necessarily detectable)

Your SIEM would need to correlate:

EDR alert: Snow process installed
Network logs: Nothing suspicious (just Teams traffic)
Email logs: Phishing that got through
User behavior: Anomalous data access

Without correlation and without deep Teams API instrumentation, the attack remains invisible.

Defense: Six Critical Controls

1. Inventory and monitor Teams webhooks and connectors

Regularly audit your Teams workspace for:

Incoming webhooks (Settings → Connectors)
OAuth apps with Teams permissions
Custom bots that have been added

Delete anything you don't recognize. Webhooks should be explicitly approved and documented.

Implement Teams audit logging and alert on new webhook creation. Webhook activity should be monitored for unusual patterns (messages at odd hours, messages with command-like syntax, etc.).

2. Implement application-layer monitoring for Teams

Enable Teams audit logs and forward them to your SIEM. Monitor for:

Webhook creation and modification
Bot activities
External guest access
Large file uploads or downloads
Unusual chat patterns (messages with encoded data, suspicious links, etc.)

3. Phishing and email gateway hardening

Snow delivery typically starts with phishing. Implement:

Email link rewriting (click-time security)
Sandboxing for attachments
Behavioral analysis for phishing (domain look-alikes, urgency language, etc.)
User training focused on file download risks

4. Browser extension management

Snow deploys as a browser extension. Control which extensions can be installed:

Whitelist only approved extensions
Disable user installation capability
Monitor for extensions from untrusted sources

Implement this via Group Policy (Windows), MDM (mobile), and browser policy (Chrome, Edge, Firefox).

5. EDR tuning for legitimate application C&C

Configure EDR to flag:

Known legitimate applications making unusual outbound connections (Teams connecting to non-standard URLs)
Applications spawning child processes (Teams spawning PowerShell, cmd, etc.)
Applications accessing browser cache or credential stores
Applications modifying network settings

These are low-confidence alerts individually, but high-confidence when correlated.

6. Network segmentation for sensitive data

Data that shouldn't be exfiltrated via Teams should be stored on systems where users don't have Teams access. Use network segmentation to prevent collaboration tools from reaching data repositories:

Research data on isolated network segment
Financial data accessed via jump hosts
Customer data not accessible from general workstations

Incident Response if Snow Was Deployed

If you discover Snow or similar malware in your environment:

1. Isolate affected systems immediately. Don't wait for further investigation.

2. Revoke Teams webhooks. Delete all webhooks from your Teams workspace and audit for suspicious ones.

3. Review Teams audit logs for the past 90 days. Look for webhook creation, suspicious messages, unusual activity.

4. Check browser extensions on affected systems. Remove anything suspicious.

5. Credential rotation. Assume all credentials accessible from compromised systems are compromised.

6. Network logs review. Even though C&C is hidden in Teams traffic, look for lateral movement, data exfiltration, or other suspicious activity.

The Uncomfortable Truth

The SaaS tools we've deployed to improve collaboration and productivity are now, by definition, attack infrastructure.

It's not Microsoft's fault. Teams is a well-designed product that does exactly what it's supposed to do. The problem is that what it's designed to do (allow external services to post messages, enable bots, support collaboration) is also exactly what attackers need for C&C.

There's no way to make Teams secure against this attack without making it less useful for legitimate collaboration.

The defense is detection and response, not prevention. You can't block Teams. You can't prevent webhooks (legitimate use requires them). You have to assume that every collaboration tool in your stack could be abused by an attacker and instrument accordingly.

Start today by auditing your Teams workspace for existing webhooks. Delete anything you can't explain. Then implement logging and monitoring. The attack is happening—your job is to make sure you can see it when it does.

---

Vouch Security Research Team · Analysis based on Mandiant disclosure of UNC6692 and Snow malware campaign. Organizations should review Microsoft Teams security hardening guidance and implement webhook monitoring immediately.