This article illustrates how custom command and control (C2) implants can circumvent network monitoring systems and security measures by piggybacking on Microsoft Teams traffic. Such C2 channels could facilitate unauthorized data transfers or enable malicious activities within the victim network and systems. The major goal of threat actors is to establish such channels covertly and to go unnoticed along all other network communication. This post does not detail how to get malicious code running on a victim system but rather how an implant maintains an interactive communication channel with the attacker.

Compass runs quite some red team exercises. With red teaming we specifically refer to full chain attacks, including initial access, detection evasion activities and maintaining access to complete missions. Usually, without knowing much about the victim organization. Working in these fields is a little arms race as detection teams and tooling picks up with the red teamers’ ideas gradually. Thus, we invest significant time to search for new techniques to bypass malware filters and into approaches to establish covert channels.

We understand that this knowledge is very sensitive, but we also want to share our fact findings with the community, so folks on the white hat side of cyber have a chance to understand the impact and get means to elaborate and discuss effective prevention and detection measures.

With the rise of remote work, Microsoft Teams has become the de-facto standard for video conferences, chat, and collaboration. The nature of the Teams architecture are some central systems that route information between parties. Therefore, Teams client software must be allowed to communicate with systems on the Internet. Microsoft even recommends letting Teams traffic bypass inspection proxies for compatibility reasons. Its network communication pattern has significant overlap with malicious C2 traffic and thus it is nearly impossible for blue teams to spot adversary communication. Therefore, Teams is an interesting candidate to be abused for C2 traffic.

The illustrated covert channels enable connections between two parties and pass through Microsoft servers as a fixed hop to avoid detection.

Figure 1: Basic Overview

The above figure (Figure 1: Basic Overview) depicts the scheme of the covert channels, using Microsoft Teams as the information carrier. One channel transports instructions from the attacker, while the other returns query results from the victim back to the attacker.

In this article, four covert channels are discussed, with three dedicated to outgoing and the fourth to incoming traffic. The identified covert channels for outgoing traffic include a webhook, a Teams message, and a Teams call channel. However, for incoming traffic, the article outlines a message covert channel, which is different from any of the outgoing message channel.

Outgoing Channel: Webhook

TL;DR this is a somewhat complicated approach to let the MS Teams central servers query arbitrary URLs (incl. exfiltration payloads) on behalf of a victim. It’s basically some kind of SSRF that helps an attacker fly under the radar because all victim requests are sent to the MS webhook endpoint.

A webhook is an HTTP-based callback function to forward information into a Teams channel. In the Microsoft Teams settings, a webhook can be attached to a Teams channel, providing an outside world API to deposit messages in that channel. An endpoint URL is composed as https://xxxx.webhook.office.com/yyyyy, where xxxx corresponds to the tenant of the webhook’s owner and yyyy to the randomly generated ID. The webhook accepts Teams cards (JSON) as input. Thus, cards are sent with an HTTP POST to the webhook.

The following issues play a key role to establish such covert channels:

  1. Anyone can send messages to the webhook without any authentication token.
  2. Images linked in the JSON body of a Teams card can be fetched from any URL.

The covert channel is created by crafting a Teams card with an image linking to an attacker-controlled server. Data to be exfiltrated will be appended to the image URL. Specifically, the flow works as outlined in Figure 2.

Figure 2: Incoming Webhook Covert Channel Flowchart

  1. On the victim side, a Teams card (JSON) is created including an image reference linking to the attacker’s server (AS), appending data to be exfiltrated (resultquery).
  2. The Microsoft server (MS) accepts the input from the client and it responds with a 201 status code.
  3. During the rendering, MS tries to fetch the linked image from AS. The GET request is sent out to AS (e.g., https://attacker-webserver.com/resultquery).
  4. The AS will log the incoming request path and send back a 404 to MS, indicating a missing resource on the server (the server might alternatively return a random picture). MS renders the card with a default image without any error.

The video (Figure 3: Webhook Data Exfiltration Demo) displays a proof-of-concept setup and procedure for how data can be exfiltrated using webhooks.

The screen is split in three areas:

  • The Teams window displays a channel with a malicious webhook.
  • The top left command shell is the attacker server.
  • The bottom left command shell is the victim workstation.

The video will start by displaying the attacker’s public Internet address and proving that the attacker server can neither be reached by PING nor by HTTP requests. Therefore, traffic must be sent over Teams webhook endpoints (https://xxxx.webhook.office.com/yyyyy).

Afterwards, the victim will launch a script that sends Teams cards to the webhook and appends each entry from a list of strings (data to exfiltrate) to an embedded image, which is then ultimately being requested from the attacker server. That way, the list of strings is exfiltrated.

So much for the attacker’s point of view. How can we prevent the scenario?

This type of covert channel could be prevented by blocking requests towards the webhook endpoint at the cost of functionality. Alternatively, we might consider to closely monitoring the webhook API requests for Teams cards that come with potentially malicious links to external images.

It might not be obvious at first glance but note that prohibiting webhook creation by Teams configuration will not necessarily stop an attacker from creating their own channel with a malicious webhook and using that one for an attack.

Outgoing Channel: Teams Message

This covert channel exploits the possibility to retrieve authentication data from the filesystem and using it to interact with the Microsoft API. The authentication data is buried in cookies that are encrypted with a key which itself is protected by the DPAPI.

The relevant files are stored in the user profile folders:

  • AppData/Roaming/Microsoft/Teams/cookies (key protected auth data)
  • AppData/Roaming/Microsoft/Teams/LocalState (the DPAPI protected key)

Decrypting the key with DPAPI allows for further decryption (AES-GCM) of the cookies. Interacting with the API directly allows an adversary to create, modify, delete, and read old messages from the chat. The API used to interact with the server is https://amer.ng.msg.teams.microsoft.com/, which is notably different than the Graph API advertised by Microsoft.

We agree, blocking access to the API is not the solution as it renders Teams useless. Alternative measure could include detection of unusual process communicating with the endpoint, detection of large chat messages or a high frequency of chat messages, which all would be a pattern of data exfiltration activity. However, this would need interception or proxyfication of Teams traffic which is not necessarily supported. Beyond that, most ideas boil down to preventing malware execution in the first place.

Outgoing Channel: Teams Call

A Microsoft Teams call can be established with two different protocols: STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT). The first protocol allows P2P communication, while the second protocol uses a relay server to set up the call in a client-server manner. The covert channel can be created by encapsulating the data into UDP packets and sending them over to the relay server. The incoming packets are not validated by the server and are thus forwarded to the other user on the call (the attacker).

The ICE protocol is required to negotiate with the server about the protocols to be used in the channel, since the client is unaware of the firewall’s enforced policy. It needs to check if a UDP or TCP connection can be established. The ICE protocol also determines where to connect and informs the client about the NAT setting of its own network. Once the client is successfully authenticated to the relay server, it should be able to send traffic to the server using e.g. UDP.

For the PoC videos, both User A and User B are run on the same local network segment. However, to avoid any confusion, the PoC is designed to inject additional packets to an outgoing UDP call (Figure 4) connection which was previously negotiated using the ICE protocol and all traffic is relayed over an Internet server.

The PoC concept is to wait on an established call and then to attach to the socket to inject UDP packets which are then sent to the relay server who happily forwards the packets to the attacker.

On the receiving end (the attacker side) of the call, a script sniffs on the incoming UDP stream and writes packet data to the console. See Figure 5.

To be fair, this is a rough implementation. However, piggybacking on the audio UDP stream did not influence voice quality which comes in really handy. Thus, the PoC clearly highlights the feasibility of data exfiltration over standard phone call communication protocols. Anyways, to be fair again, Teams is not the only software that implements some sort of hole-punching and relaying to allow NATed devices to communicate with each other.

Mitigations for this type of channel are even harder to implement. You could restrict UDP traffic for the downsides that come with voice over TCP. Injection into TCP is surely harder to achieve and would be a great field to push this study further. At least in theory, behavioral analysis of network traffic could help to detect such traffic. Unfortunately, the call’s UDP packets and the data to exfiltrate, specifically when data is encrypted before exfiltration, have very similar entropy.

Incoming Channel: Messages

This fourth and last covert channel allows for an incoming connection from the attacker to the victim. The channel allows carrying instructions from the C2 server to the victim’s computer. Note that the communication between attacker and victim is always indirect, with a Microsoft server relaying messages in between. The channel exploits the message flow in a similar manner as the previous covert channel. To send a Microsoft Teams message through the API on https://amer.ng.msg.teams.microsoft.com, the following JSON structure is needed:

{
   "content":"",
   "contenttype":"text",
   "messagetype":"text",
   "clientmessageid":,
   "imdisplayname":"",
   "properties":{
      "importance":"",
      "subject":""
   }
}

It is possible to send HTML instead of text in the “content” field, defining key “messagetype” to “RichText/Html”. 

{
   "content":"<p value='secretMessage'> message </p> "",
   "contenttype":"text",
   "messagetype":"RichText/Html",
   "clientmessageid":,
   "imdisplayname":"",
   "properties":{
      "importance":"",
      "subject":""
   }
}

In this case, there seems to be a lack of validation for special attributes within a tag. The paragraph tag allows defining “value” attributes that are not stripped by the server. The content of the value attribute is not visualized by Microsoft Teams, despite being transferred to the victim’s computer. Once the server has sent the message through the receiver’s WebSocket, the entire message can be fetched from the WebSocket using the Teams cookies or by reading the log file maintained by the Teams Application at the following path: %userprofile%/AppData/Roaming/Microsoft/Teams/IndexedDB/https_teams.microsoft.com _0.indexeddb.leveldb

The same mitigations strategies apply: content filtering and detection of unusual content.

General Defense and Countermeasures

Although there needs to be adequate content filtering, blocking certain IP addresses that offer webhook capability would help mitigate the webhook covert channel. The usual image path requested for the Teams card diverges significantly when data is being exfiltrated and that should be easy to spot.

Regarding the message and the call channels, disabling the functionality of communication with external tenants would eliminate these channels completely. However, this comes with the burden of whitelisting trusted peer tenants.

This is also Microsoft’s recommendation. Best practice for exchanging information with other tenants is individually whitelisting them using tools such as Microsoft Purview Information Barriers.  Alternatively, to reduce the risk while still allowing the communication with external users, the detection can be applied to the message covert channel using Microsoft auditing service.

The detection for the call covert channel is extremely complex since the identification of (additional) bytes inside the UDP has similar entropy as the media data.

Conclusion

The discovery of covert channels within Microsoft Teams introduces new opportunities for extracting information, even in the presence of security policies and strict egress traffic rules. This work demonstrates the potential to establish covert channels by leveraging the architecture of Microsoft Teams and emphasizes the need for configuration hardening and whitelisting approaches.

The discussed covert channels come with quite high stability and performance, being able to exfiltrate 90KB/s with the message, 32KB/s with the call, and 6KB/s with the webhook covert channel.

Currently, there is no command-and-control framework known to us using these covert channels. Maybe due to Teams’ continuous transformation. The infrastructure changes constantly and to make the C2 reliable, the implant would need to change constantly as well, especially with the upcoming new Microsoft Teams release.

Credits

Previous work on covert channels using GIF images has already been conducted by Bobbyr, where he introduces the concept of covert channels in MS Teams.

This research was conducted by Massimo Bertocchi and takes Bobbyr’s article as a basis to advance the study of covert channels. The practical work was conducted under the supervision of Compass Security and formed the foundation for his Master Thesis at the Royal Institute of Technology (KTH), Stockholm, Sweden. The full 75 pages paper outlining general Teams details and further C2 or malware design details is available at the KTH diva portal.