Practical Protection: Two Routes to Avoiding Malware in Teams 

Vulnerabilities in Teams

There’s an old saying about security: defenders have to be perfect every time, but attackers only need to get lucky once. This fundamental truth underlies a lot of the protective measures that we try to apply as defenders, including reducing the number of things that attackers can get to (“attack surface reduction”) and hardening the things that remain. 

Recently, security researchers at JumpSec labs identified a vulnerability in Teams that allow malware delivery through Teams chat. However, Microsoft has a couple of different ways to mitigate both this specific attack but also a broader class of similar attacks. Before we dive into discussing how you can protect yourself, let’s look at the attack itself. 

The JumpSec Attack Explained 

It’s no surprise that an attacker might try to use Teams to send malware to a target. After all, attackers use file shares, websites, email, and pretty much every other communications method newer than smoke signals to try to drop malicious payloads on their target networks; why should Teams be any different?  We saw an example of this in 2022 with the GIFshell attack, which combined two things: the fact that users in Teams chats can send animated GIFs, and the fact that Teams message logs on a local machine could be read by any user. The attack constructed by JumpSec follows a similar pattern to GIFshell: userA receives a message from userB, in an external organization, and the message contains malicious content which does something bad when userA opens it. 

This might seem unlikely; after all, the default Teams external access policy doesn’t allow cross-tenant file sharing in chats. However, many Teams policies are interpreted on the client, similar to how Group Policy Objects work. The client reads a set of policies from a trusted source, then applies them. In the case of Teams, the policies that control whether userB is able to send a file in a chat can be subverted by modifying them in transit between the service and the client. An example of this policy tampering can be found here. As you’ll see when you read it, this tampering is trivial to do using Fiddler. Because the policies are not cryptographically signed, and because the policy controls what the sender is able to do (and not the recipient), the attacker can override the service policy to have his userB account send malware to userA through the chat. 

What Microsoft Isn’t Doing 

Simply put, they’re not immediately fixing the problem. Microsoft’s security team told JumpSec that this problem “did not meet the bar for immediate servicing.” This requires some interpretation: Microsoft didn’t say they would never fix the problem, and they didn’t deny that the problem exists; they said instead that it isn’t critical enough to fix right now. Generally, when they use this “immediate servicing” phrase, what they truly mean is, “There are other ways to protect yourself that are good enough for now, so we won’t break our backs to fix this immediately.” And so it is in this case. 

The Simple Mitigation: Limit Federation 

Apart from the rather glaring problem with Teams policies being vulnerable to substitution, there’s a more obvious problem here: userB is allowed to communicate with userA in the first place! By default, Teams tenants are open to external access through federation. In an open tenant, your users can receive chat messages and audio/video calls from any other Teams user. This seems like a reasonable approach. After all, it’s how telephones have worked for decades; if you don’t know the caller, you don’t have to answer. However, it’s a better idea to reduce your attack surface by either disabling federation altogether or limiting it to certain select domains. To reduce risk, for example, my employer limits federation to a few key supplier and business-partner domains. This means I can use Teams chat with some outside organizations but not others. You will rarely find a better example of the tradeoff between convenience and security. Open federation is extremely convenient for your users because they can use Teams to chat with any of the hundreds of millions of other Teams users. However, it is evidently less secure than a more restricted federation. 

Using Defender for More Comprehensive Protection 

You might imagine that good endpoint security protections would limit the risk or damage of malware included in a Teams chat, and you’d be correct. Running Window Defender or other similar endpoint-protection solutions is one obvious way to mitigate this risk. Microsoft is rolling out another potentially useful feature, the ability for users to report suspicious chat messages directly in the Teams client. This feature is part of the “Collaboration Security for Microsoft Teams” initiative that Microsoft announced in March 2023; customers with Microsoft E5, Microsoft E5 Security, or Microsoft Defender for Office 365 licenses can opt into the preview of this program and then enable end-user message reporting. For now, as described in MC567578, you can opt to let users report suspicious messages to Microsoft (although the option only works if you’ve also opted into the Collaboration Security preview). However, after Microsoft completes the rollout of this policy control, they will default it to “on.” The time period for this is a little fuzzy, although, in the message center notification, Microsoft has promised to give at least 30 days’ grace before defaulting the policy to on. 

Besides message reporting, the Collaboration Security preview also brings zero-hour auto-purge (ZAP), first developed for Exchange, to the Teams world. ZAP automatically and retroactively removes malicious content from Teams chats once they’re identified, without user action. This is a really useful feature because it actively removes malicious content, in many cases, before users see it. For example, as I write this, it is the national Constitution Day holiday in Ukraine, but it’s late in the evening, Kyiv time. If an attacker sends a malicious message to any of my Ukrainian coworkers, as soon as Defender detects it, it will remove it from their chat storage, likely before they wake up and check their messages tomorrow morning. 

Not Quite a Tragedy of the Commons 

While the use of federation to send malware is a real risk, the degree of risk for your individual organization may vary according to the security awareness of your users and what other protective measures you have in place. For most of us, the combination of those two factors means there is a legitimate risk and that locking down federation is a good idea. There will doubtlessly be other discoveries of vulnerabilities in Teams from the tireless legions of red-team researchers around the world, so you might as well address this one quickly.