Microsoft Teams as APT Command & Control: Why Slack and Discord Matter for Incident Response

MuddyWater APT uses Microsoft Teams for C2: attack patterns, detection strategies, why Teams became the perfect hiding place.

Microsoft Teams as APT Command & Control: Why Slack and Discord Matter for Incident Response

MuddyWater, the Iran-linked APT group, just weaponized the one tool your organization explicitly trusts: Microsoft Teams. Their latest campaign (detected in early 2026) bypassed email filters, endpoint detection, and network monitoring by moving command & control infrastructure into your corporate collaboration platform.

This is the inflection point where traditional incident response frameworks break down. Your SIEM ignores Teams traffic. Your email gateway can't see message attachments in Teams channels. Your SOC watches the wrong place.

How Teams Became APT Infrastructure

The attack sequence was elegant and low-tech:

1. Social engineering via Teams DM — Attacker sends phishing link disguised as an internal security notification

2. Initial compromise — Victim executes malicious script (PowerShell, disguised as legitimate IT automation)

3. C2 via Teams bot — Compromised machine communicates with attacker-controlled Teams bot in legitimate-looking channels

4. Data exfiltration via Teams — Stolen credentials, files, and reconnaissance data posted to encrypted Teams channels

5. No alert — Teams traffic looks identical to legitimate business communication

Why this works:

Teams traffic is encrypted end-to-end (even your security team can't inspect content)
Teams channels appear legitimate on network logs (high-trust destination)
Teams message history is ephemeral (deletion happens faster than log retention cycles)
Most organizations lack Teams traffic analytics or audit controls

Taken together: Teams is a perfect C2 infrastructure hiding in plain sight.

The Real Threat: Trust Inversion

Traditional APT infrastructure is easy to spot: attacker-controlled domains, suspicious IP addresses, unusual protocols. Your threat intel team flags it. Your firewall blocks it.

But when the C2 server is teams.microsoft.com (which is already whitelisted), detection inverts. You have to find the malicious behavior inside trusted infrastructure, not block the infrastructure itself.

MuddyWater's execution was worth analyzing because it demonstrates how modern APTs exploit organizational trust:

Use messaging platforms instead of email (bypasses email security)
Use cloud storage instead of exfil servers (looks like legitimate data sync)
Use automation tools instead of custom malware (evades signature detection)
Use legitimate user accounts instead of compromised accounts (fewer alerts)

Why Your SOC Will Miss This

Most security operations centers are optimized to detect anomalies in unauthorized channels. They watch for unusual outbound connections, unknown domains, suspicious processes.

They are not optimized to detect malicious behavior in authorized channels. Teams traffic is expected. Slack usage is expected. Discord activity (increasingly) is expected in development teams.

This inversion of the threat model demands different detection logic:

You need to monitor:

Teams bot activity patterns — Bots posting at odd hours, bots with no human interaction, bots in archived channels
Message content anomalies — Encoded payloads, encoded commands, binary data in message attachments
Channel creation velocity — Rapid creation of new private channels followed by deletion
Cross-chat bridging — Users copying/pasting between Teams and external communication platforms
Deleted message patterns — Channels with unusually high deletion rates

You should implement:

Teams audit log ingestion into SIEM (Teams provides it; most organizations don't enable it)
Content inspection of Teams file uploads (zip files, executables, suspicious archives)
User behavior baseline — Establish normal Teams activity per user, alert on deviations
Teams app permission audit — List all installed bots; verify none were sideloaded by attackers

Actionable Defense for This Week

Triage (24 hours):

Check if you have Teams audit logging enabled (Settings > Organization > Org-wide settings > Teams > Analytics & reporting)
List all installed Teams apps and bots; verify each one
Check for Teams channels with unusual names (looks-like-legitimate, but auto-created)

Implement (this sprint):

Enable Teams audit logging and ingest into your SIEM
Create alerting rule: new Teams bots created without IT approval
Monitor for Teams channel creation/deletion patterns
Implement DLP (Data Loss Prevention) rules for Teams message content

Strategic:

Update your APT playbooks to include "compromise via Teams" scenario
Train your SOC team on Teams-based attack patterns
Consider Slack/Discord in the same threat model (same problem)

The Pattern You Should Generalize

MuddyWater's use of Teams is a symptom, not an isolated incident. APTs will continue to use whatever tools your organization already trusts. In 2024, it was Slack. In 2025, it was Discord. In 2026, it's Teams.

The pattern: High-trust infrastructure becomes the perfect hiding place.

Your response can't be to block Teams (it's critical for business). It has to be to understand that trust ≠ security, and that detection rules designed for external threats fail against threats inside your trusted systems.

Vouch's code security scanner integrates with organizational audit logs to flag patterns like unusual bot activity, suspicious automation, and data exfiltration via APIs. If you want to monitor Teams, Slack, and Discord as part of your security baseline, we can help you do that automatically.