GIFShell Attack Exploits Teams Logs, GIFs, Adaptive Cards, and the Incoming Webhook Connector
The Proof of Concept (POC) attack techniques to exploit holes in Microsoft Teams described in this BleepingComputer article are not good news (note to self: security flaws are seldom good news). The article describes how attackers can exploit several Teams vulnerabilities (collectively known as “GIFShell”) to deliver malware, run commands, and exfiltrate data using GIFs.
Bobby Rauch, a cybersecurity consultant and pentester, discovered the vulnerabilities exploited by GIFShell. According to the article, Rauch disclosed the problems to Microsoft in May and June of 2022, but nothing has been done yet to close the gaps. As reported by BleepingComputer, Microsoft says that the two techniques disclosed by Ruach “do not meet the bar for an urgent security fix.”
Part of the logic for Microsoft’s view that an urgent fix is unnecessary is that the attack depends on loading a malware executable on a Windows PC. In other words, an attacker must first compromise a computer to plant the malware. Nothing else can happen unless the attacker has access to a compromised target, so Microsoft considers the techniques to be post exploitation.
Log Monitoring
The executable (“the stager”) monitors the contents of the Teams logs stored on the PC at AppData\Roaming\Microsoft\Teams\IndexedDB\https_teams.microsoft.com_0.indexeddb.leveldb. These logs are the Teams local cache and not the actual Teams message data, which remains stored in Azure Cosmos DB. However, the local cache does contain copies of Teams messages.
The screenshot published in the article makes it seem like the researcher used Teams consumer rather than Teams enterprise because the folder he references uses teams.live.com. I see a different setup on my PCs running Teams enterprise. This isn’t surprising because Teams consumer uses the V2 architecture while Teams enterprise still uses V1. The researcher doesn’t say what version of Teams he tested on, but some of the screenshots show the web client connected to teams.microsoft.com.
The Special GIFs used by GIFShell
Rauch points out that the default Teams configuration allows external access with any other tenant and uses this to send a chat message containing a special GIF to a user in another tenant. The GIF could contain commands to execute on the target machine. The stager monitors the Teams logs and when it finds a GIF, it extracts and runs the commands. The base64 encoded output is used as a filename for a remote GIF embedded in an adaptive card submitted by the stager to the URL for the incoming webhook connector created for a Teams channel in the attacker’s tenant. It’s easy to send data to Teams in this manner, and it’s certainly a convenient way for the attacker to transmit information back to their server.
The presence of the GIF forces Teams to connect to the URL (using the URL pointing to the attacker’s server) to retrieve the GIF, which the attacker can intercept to see the content sent from the target machine. Rauch points out that Microsoft’s skype.com servers handle this traffic, so it’s considered legitimate.
Clever Attack But
As mentioned above, the GIFShell attack depends on being able to send a message to an external user. One practical and quick way to stop similar attacks is to update the external settings for Teams to block access from any organization other than those on an allow list (Figure 1).
The downside of this arrangement is that you won’t be able to use functionality like federated chat or shared channels with external users from a domain that’s not on the allowed list. However, that’s a small price to pay for better security and control over external communications. Remember that if you’re going to set up shared channels to collaborate with another organization, you might want to create an Azure AD cross-tenant access policy, so part of that process can be to add the target domain to the allow list.
Update: One way to populate the domain allow list for external access is to base it on the domains of guest accounts in a tenant. All explained in this article.
Relax but Stay Vigilant
Given the size of the Teams installed base (the last reported number was 270 million monthly active users), it’s no mystery why attackers might consider Teams a nice target. Microsoft appears to be pretty sure that the reported technique penetrated no security boundary. They know more about security than I do, so I accept what they say. However, it’s still not good when security researchers find weaknesses. The vulnerabilities might not be exploitable today, but that’s no guarantee that they couldn’t be a path to penetrate a tenant in the future.
The Microsoft 365 Kill Chain and Attack Path Management
An effective cybersecurity strategy requires a clear and comprehensive understanding of how attacks unfold. Read this whitepaper to get the expert insight you need to defend your organization!
Do you know if there is a way to audit which external domains are already in contact with internal staff? It would be good if I could obtain a list of those external domains so I can add them to the allowed list as soon as I turn on ‘Allow only specific domains’. I dont want to turn it on to have a flurry of emails/complaints that staff cant talk to certain externals. Thanks in advance!
One way is to scan for guest accounts in the tenant and examine their domains to build a list of domains to use.
Paul, try this: https://practical365.com/teams-external-access-powershell/
It’s been said everyday is a school day 🙂 Never looked at the .ldb files. Thanks for sharing those links!
Hey @Tony….. Think you left out a keyword that implies so much context, I was wondering what u meant by 270 users until I clicked on the link, the million part is missing 🙂
“Given the size of the Teams installed base (the last reported number was 270 (million) monthly active users), it’s no mystery why attackers might consider Teams a nice target”
That’s a real Friday evening publishing error… Fixed now!
Thanks for the reply Tony. I’ve never seen any clear text message data in the cache so had to ask.
For anyone wanting to get acquainted with what’s in the Teams local cache: https://onlinelibrary.wiley.com/doi/10.1111/1556-4029.15014?af=R
Or (free) https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/microsoft-teams-and-skype-logging-privacy-issue/
The researcher is referring to the Teams local cache, where copies of messages are kept to make it easier (and faster) for Teams to work, especially when network conditions degrade. The local cache is like Outlook’s OST and PST files, and it is possible to find message data there, which is what the malware did.
While that article was an interesting read I couldn’t really take it seriously when it suggested that “Microsoft stores Teams messages in a parsable log file, located locally on the victim’s machine, and accessible by a low-privileged user” and “All received messages are saved to these logs and are readable by all Windows user groups, meaning any malware on the device can access them”.
Most of us know Teams messages are processed in Azure chat service (Cosmos DB) and only writes compliance records to hidden folders in mailboxes. Nothing is saved locally, other than the debug, media and desktop logs. Also makes me wonder what kind of environment this was tested in, surely not with the security features enabled such as Threat policies (safe links, safe attachments) and the rest of the Defender suite. Or perhaps I’m missing something.
I agree, there are lots of issues with the original article. It seems to be designed for clickbait rather than educate people about security issues.
The main exploit they are demoing is the remote control though teams, but you already of had to of compromised the victim’s computer to install malicious software to read out of the Teams directory. If I’m an attacker and I’ve already done that… Why would I want use Teams to exfiltrate the data out when I could use one of the other countless methods like DNS, HTTPS, etc. Which are much less likely to be logged.
I still agree with Tony that tenants should adopt a whitelist approach for allowing external messaging