One GIFShell to Rule Them All: How To Detect An Attack

Last month, security researcher Bobby Rauch published two blogs revealing a new vulnerability in Microsoft Teams. Known as GIFShell, the vulnerability utilizes seven different insecure design elements within Microsoft Teams to create the situation whereby an attacker can launch an exfiltration or malware attack against a victim – simply by sending them a GIF with embedded commands in a Teams chat.

The second blog then revealed how spoofed attachments with malicious deeplinks exploit a lack of permissions enforcement in Microsoft Teams to carry out remote code exploitation (RCE) via an NTLM relay attack, which would steal credentials information to facilitate the RCE.

While Rauch identified these vulnerabilities through the Teams Internal API, Reco Security Researcher, Gabriel Cohen, used the Graph Chat API (the API used by Reco to connect to Teams) to receive messages from the suspicious chat, and analyze the message properties identifying the key areas of the attack.

Both replicated tests began with the researcher connecting with a user for the first time. This brought up the first warning in which Microsoft asks for permission before accepting messages from an external user. From there, the researcher was able to replicate both attacks.

Replicating a GIFShell attack

This attack simulation only replicated the steps required for the researcher to see the attack at the API level:

1. Send the victim a short message to intercept the request.
2. Use the intercepted request and modified body to send a GIF containing the command.

The researcher sent the opening message, and extracted the request. The screenshots below show the data of the interaction, and the GIF in the chat.

After replicating the chat, the researcher extracted the message containing the GIF from the API. The screenshot below demonstrates where the sent GIF can be found:

Replicating an attachment spoofing attack

Again, this test replicated some of the attack steps described by Rauch in order to understand how such an attack can be detected at the API level:

1. Send the victim a short message to intercept the request.
2. Use the intercepted request and modified body. For this test, the researcher used a dummy IP (256.256.256.256) to avoid replicating the attack itself.

The researcher created a Microsoft deeplink (ms-excel:/ofv|u|//256.256.256.256/ROPNOP/test.xls) by following the Office URI scheme.

Once the user accepted the external chat (see above), we sent a spoofed attachment in the chat posing as the external user. The attachment Christmas_party_photo.jpeg is sent in this chat.

And the chat API returned the following data:

This is in comparison to the API data for a non-malicious GIF sent via Teams:

Analyzing the data to understand what to look for

This data from the API told us several interesting details:

The API data enabled us to detect that the message came from a user who is not part of an AD for any organization.

In this case, the “from” property for the “user” object had the property “userIdentityType” and the value “personalMicrosoftAccountUser”. By contrast, an AD user will have the “userIdentityType : aadUser”.

The attachment contained a deep link URL format. Microsoft does not validate URLs with Microsoft deep link formats, nor do they scan URLs or attachments sent within the platform for malicious content, and as a result will not identify this deep link as malicious.

The API data doesn’t distinguish between user or script-made requests using this kind of attack. Again demonstrating how Microsoft is unable to identify a malicious request.

These findings potentially have critical implications for an organization. A successful attack using these methods will give an attacker access to the victim’s OneDrive and by extension the company’s SharePoint, files, and more. In addition, Teams routinely stores sensitive information including password information in plain text, and an attacker who has successfully exploited these vulnerabilities will be able to access this information.

Using context to detect GIFShell attacks

These findings highlight the challenges of protecting your organization against external users who interact with your employees. Both Rauch and most of the commentary we read suggested that one way of dealing with these vulnerabilities is to remove the ability to collaborate with external users via Teams. But for many organizations who use collaboration with third parties such as business partners and vendors every single day, this simply isn’t an option.

As a result, it’s important to help the organization collaborate securely. Reco’s AI-based business context justification engine monitors all traffic entering an organization’s collaboration tools, including instant messaging tools such as Microsoft Teams. The engine then builds a context map of interactions, and analyzes actions for justification in every communication that takes place with an external party.

Reco therefore protects against the kind of attacks that these vulnerabilities could cause by identifying the following as unjustified actions:

• The attacker sent a message for the first time to the victim, most likely from a domain that the victim does not communicate with on a frequent basis (if ever). That will raise an incident in the Reco platform based on the fact we have not seen justification for the two parties to communicate.
• The attacker doesn’t appear to be part of an organization or connected to the victim’s organization in any way – another sign of no justification.

Want to learn more about our solution? Discover Reco: www.reco.ai.

Gabriel Cohen, Data Security Expert, Reco

‍