Microsoft Teams RCE

The Microsoft Teams RCE is an epic find, but nonetheless extremely scary. I have discussed with quite some people my personal fear for this kind of vulnerabilities in applications like Slack/Outlook/Teams. Basically, applications that need to/can “receive” data from the whole internet. Especially the Electron-based stuff makes me wonder why people think it’s a good idea to build applications in JavaScript and throw away the whole security model of a browser. It took the industry many years to build a somewhat secure browser model — and with Electron, we ditch the model and start from scratch again…😒

Luckily for almost all Teams users, this isn’t a real 0-day anymore and Teams auto-updates, so impact is most probably low. Having said that, there are still people who try to figure out ways to disable the auto-update feature of Teams.

We’ve decided to release a hunt. Mostly for people to check if this Teams vulnerability has been abused before it was disclosed this week. But also for those who have managed to successfully disable the auto-update feature. Finally, you might want to fine-tune this rule and use it as a detection rule for future exploits.

Blue: Luckily, this vulnerability is fairly easy to detect in most cases. Teams isn’t an application that necessarily spawns a lot of different child processes. So our hunt basically looks for all the child processes of teams.exe, excludes all the expected child processes and voila. The whitelisted processes fall in 3 categories.

1. Office applications (Word, Excel, PowerPoint, Notepad, Paint).
2. System utilities (7Zip, Browsers, etc.).
3. Misc (protocol handler, werfault, etc.).

There is one catch here, since the exploit code uses the file:///, we’re unsure how that will be handled for various file types (executables, batch script, powershell scripts, etc.). Hence we look for all the child processes of protocolhandler.exe which have teams.exe as parent, i.e. teams.exe ➡ protocolhandler.exe ➡ suspicious.exe.

One big gap in this hunt is that the whitelisting is performed on file name. The file name is easily controlled by an attacker — in a production environment, you might want to put in the extra effort and whitelist based on path instead of file name only.

You can find the query here.

Red: This vulnerability has been patched in production, so you won’t be using this any time soon, unless you’re really lucky. However, if you want to bypass this rule for any future exploit, we see two options:

1. Blend in using a file name that’s expected to be a child process of Teams. This is tricky since you might be caught if the defenders look at the full path instead of file names only.
2. Use “open an Office file” with your macros. This takes away the “zero-click” effect though. Depending on your guesstimate of the blue team’s abilities, it might be worth the trade-off.

FireEye red_team_tool_countermeasures KQL queries

Earlier this week our industry colleagues at FireEye sadly had to announce they have suffered a breach. As part of this regretful incident some of their red team tooling had been compromised. In addition to their press release about the breach FireEye has published a ton of indicators, YARA and Snort rules and signatures in the following GitHub repository. This information can be used to detect active use of their tooling.

In order to make these files a little more applicable to the community that uses Microsoft Defender for Endpoint (MDE), we have converted most of the applicable rules to KQL; in some cases with some alterations. This will enable you to start hunting and convert the info to detections for your environment; after some tuning in some cases.

Please note we do not want to take credit for these detections, these are heavily based on the files as kindly and professionally supplied by the FireEye team. Secondly, not all rules have been converted, partially since some of our previous FalconFriday rules already covered them and also since MDE does not have the same capabilities in terms of telemetry.

Omissions and additions have been applied to improve the fidelity for some of the rules. In their current state most rules have a pretty acceptable volume of results. They have been checked in some environments, and showed interesting results. Please note: additional tuning might still be required in your environment!

Please keep in mind quite a few of these rules are heavily signature-based and require additional research to be more resilient against behavior variations.

You can find all 44 queries we have interpreted over here.

Don’t forget to check out the rest of our repository.

Knowledge center

Other articles

FalconForce realizes ambitions by working closely with its customers in a methodical manner, improving their security in the digital domain.

KVK 76682307
BTW NL860745314B01