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. 

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!

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. 

The Experts Conference (TEC) 2023 – September 19-20 in Atlanta, Georgia

About the Author

Paul Robichaux

Paul Robichaux, an Office Apps and Services MVP since 2002, works as the senior director of product management at Keepit, spending his time helping to make awesome data protection solutions for the multi-cloud world we’re all living in. Paul's unique background includes stints writing Space Shuttle payload software in FORTRAN, developing cryptographic software for the US National Security Agency, helping giant companies deploy Office 365 to their worldwide users, and writing about and presenting on Microsoft’s software and server products. Paul’s an avid (but slow) triathlete, an instrument-rated private pilot, and an occasional blogger (at and Tweeter (@paulrobichaux).


  1. Paul Robichaux

    I am about 50% Team Tony on this one and 50% Team Andres.

    Open federation is very convenient for end users, and having allow-list in my environment generates additional support overhead and hassle for the IT team, which must add domains on demand. (Of course you could automate the request/approval process). At Keepit I argued hard for allowing open federation and I lost the argument.

    In practice, this has been a no-op. Relatively few of our users want or need to use open *outbound* federation, and the majority of them are using a small set of domains. There’s relatively little business value to just allowing J. Random TeamsUser to reach out to our employees, so *inbound* federation hasn’t been missed.

    1. Joshua Bines

      I’m 25% Team Tony and 75% Team Andres. The idea of whitelisting domains still feels a bit antiquated to me. We don’t do this for email, telephone calls, linkedin, facebook or any other number of apps… all of which could allow some form of attack so why should Teams be any different? I would dispute the fact there’s relatively little business value to using Open Fed. Allowing users multiple channels to communicate freely will increase productivity in the org and hopefully reducing the amount of email ping pong i see. We all must ask ourselves do the risks really out way the benefits? Every org is different but wish more people were at least open to the idea of Open Federation. Don’t mind my pun…

      In most cases, requesting a domain to be added to the whitelist is too diffcult for users, particularly for those ‘every so often’ chats and instead they revert to using old forms of communication or plan endless meetings. I’m amazed how much open fed is used by users when it is enabled.

      @Paul Robichaux you do make a excellent point about the Microsoft Defender for Office 365 support for Microsoft Teams which is currently in preview. Until this goes GA I could understand why some choose tio limit external access but at which point you would have to ask Teams Messages vs Emails the same or different? At the end of the day they both sit in an Exchange Mailbox 😉

      1. Avatar photo
        Tony Redmond

        I’m all for openness, but where a vulnerability exists it should be blocked. Applying the block by restricting the set of domains available for federation just seems like a simple step to take. It’s how I protect my domain.

        1. Joshua Bines

          I wish it was that black and white Tony. That’s like saying we should block all docx attchments from unknown senders because some might have dody marcos… but i see your point and I have the feeling we will still be debating this topic for many years to come 🙂

          1. Avatar photo
            Tony Redmond

            I think it is black and white until Microsoft fixes the vulnerability in Teams. Until then, it’s easy for users to ask for a new domain to be added by an administrator.

  2. Andres Bohren

    While it would lower the Attack Surface – the allow-list approach is not practical.
    It’s like asking your Mailserver Admin to put in a SMTP Route to every Organization you want to communicate with.

    1. Avatar photo
      Tony Redmond

      I disagree. Most organizations have a limited set of domains that they would want to allow users to communicate with via federated Teams chat. It’s easy enough to use PowerShell to update the domain allow list for external access. For example, explains how to find the domains used by guest accounts and add them to the external access list.

  3. Jon Jones

    The issue with federation is that you can’t use wildcards in the ACL. All you can use are explicit domains. Unless you have a very small circle of companies you expect to deal with, then the allow-list approach is not practical.

    The issue that client implemented policies are not signed so can be modified in transit is just crazy. MS should be fixing that pretty quick.

    The issue of whether some of these policies should even be client side should be seriously looked at too: As everything goes through MS’s cloud infrastructure, why aren’t these policies implemented there? It’s not like Teams is a peer-to-peer system!

    1. Paul Robichaux

      1,000,000% agree– it’s crazy beans that policies aren’t protected against tampering in transit. It’s almost like one part of Microsoft forgot all the lessons learned that led to the use of Kerberos for AD authentication.

Leave a Reply