By Jimmy BayneIntroduction Microsoft Teams Rooms (MTR), formerly known as Skype Room System and Lync Room Systems, is the latest and greatest solution from Microsoft for managing online collaborative meetings. In many businesses across the globe, a Teams Rooms console (“Teams console”) is the lifeblood of the conference room. The console typically consists of a supported computer system, management dock, camera, and output device(s). The Teams Room application suite runs on Windows 10 Enterprise or Windows 10 Enterprise IoT. For offensive security testers, this post will cover a simple case where attacking Teams gear may be beneficial when conducting a physical or internal penetration test. For defenders and system administrators, this post will highlight opportunities to reduce the attack surface of your expensive, often forgotten conferencing equipment. Let’s get started… Teams Console Test Deployment My motivation for looking at Teams’ security began after troubleshooting a technical issue with a Teams console. As I learned more about the device, it became clear to me that there was a potentially untapped attack surface. But first, I needed to figure out how I could deploy teams on a test platform since leveraging the local enterprise conferencing unit was out of the question (for good reason). Note: Please feel free to skip this step if you do not plan on deploying your own test system. Test Deployment Requirements After a quick Google search, I came across an excellent Teams Room Guide on Microsoft Docs. After reviewing the hardware requirements and seeing Surface Pro compatibility on the list, I believed I had the proper equipment and resources to cobble together a functional test system. Ultimately, the test setup comprised of the following:
Source: https://forums.lenovo.com/t5/ThinkSmart/ThinkSmart-Hub-500/td-p/4061083 Test Deployment Setup After all requirements have been met, a test device can be deployed as follows:
Observations & Attack Scenarios Out-of-box, Out-of-mind When I setup the Teams console for the first time, it seemed that this device was truly designed to “set it and forget it” although post-setup guidance from Microsoft recommends otherwise (which is a good thing). Microsoft states that “Existing devices, by default, update automatically from Windows Update and the Windows Store” (Microsoft Docs). As such, many Teams console suites that are purchased from vendors are designed to work out-of-the-box. In many organizations, default configurations likely go unchanged, especially if the vendor setup process was smooth, the Office365 account configuration was successful, and the Teams meeting software worked flawlessly thereafter. From a post-deployment perspective, the following questions may be relevant -
Local Default Credentials After the setup process is completed (or when the Teams gear is shipped to the customer), several interesting defaults are present. A local account named skype is created during the deployment process. Of note, the account is not configured with a password, which is likely a design choice. At startup, the skype user is automatically logged into the machine, and the Teams Rooms front-end splash application (Microsoft.SkypeRoomSystem.exe) is launched. Although likely not impossible, successfully accessing the Windows desktop with the account is likely improbable. In addition to the local skype account, a local administrator account named admin is created. The default password is sfb. On non-domain joined machines, this account is chosen by default for exiting the Teams Rooms splash console application and logging into the device. Source: https://docs.microsoft.com/en-us/microsoftteams/rooms/rooms-prep Office365 Credential Whether the Teams Rooms console is a standalone device or a member of a domain, an Office365 (or domain) credential is stored on this device in some way. Capturing the plaintext of the account and taking control of it can be very useful for a security tester. At the very least, it is a gateway for other post-exploitation use cases. Remote Administration If the base station is domain- joined or if an administrator configured the device to allow for remote administration (via RDP), it may be possible to take control of the machine with the default admin account created by the Teams installation. Other Physical Attacks If the console base station has an accessible USB port, it is possible to leverage a hardware device, such as a Hak5 Rubber Ducky, to gain control of the device. Discovery Methodology & Theoretical Attack Walkthrough This simple walkthrough was conducted from the perspective of a standalone, on-site console. Escaping the Console At the MTR console, the Teams splash application interface is shown – Select More then select Settings. Windows Explorer prompts for credentials. In this case, we can see that the user is admin. After entering the default password (sfb), access is granted to the settings pane – After selecting Account, we can see the email account username that is used to manage the conference room bookings. Of course, the plaintext password is not visible - To escape the splash screen, simply select Windows Settings – This takes us to the login screen. We see our two local users – skype and admin. Select admin and enter the default password to login – We now have a legitimate, “Explorer” session – Locating the Office365 Credential Storage In Windows, there are plenty of subsystems and/or techniques that could be used to store the credential such as the Credential Manager/Windows Vault, a configuration file on disk, a blob in the registry, etc. Instead of jumping to conclusions, I decided to take a methodical approach and leverage a few tools to aid in proper discovery. Already having knowledge of the password, I opted to recreate my SkypeSettings.xml configuration file and capture how that was processed upon boot up. After the system boots, the configuration is read, and the XML file is deleted. Procmon Boot Logging can be used to capture the startup and initial logon events - After repeating our “break out” procedure and logging in admin, I opened Procmon, saved the collection, and analyzed the events. Applying a filter on our path revealed that the XML file is processed by the MS Teams application (Microsoft.SkypeRoomSystem.exe) - Although this was a step in the right direction, ‘granular’ details of the XML file processing were still unknown to me. Leveraging the SysInternals Strings tool, I attempted to scan Microsoft.SkypeRoomSystem.exe without much success. I used Strings to run a recursive query across all DLL files within the Teams program directory structure - c:\Program Files\WindowsApps\Microsoft.SkypeRoomSystem_4.3.33.0_x64__8wekyb3d8bbwe It became clear that Microsoft.SkypeRoomSystem.exe has numerous dependencies. Reviewing the output file, I searched for SkypeSettings.xml and successfully discovered that the string was referenced by the Microsoft.SkypeRoomSystem.dll - Reviewing the nearby results from Strings, the credential appeared to be stored in the Windows Vault: - Revealing the Plaintext For ease, I decided to load Cobalt Strike’s Beacon and connect back to a TeamServer under my control. This provided access to (shady) tools and helped overcome session disparity. After elevating to NT AUTHORITY\SYSTEM and verifying Beacon’s callback, I logged out of the admin console session and logged back in as the skype user, which loaded the Teams application and interface. After injecting a Beacon payload into a skype user process, I could now leverage the context of this user to potentially reveal our Office365 credential. First, I verified that our desired credential is stored in the Vault. This can be done with the vaultcmd command After validating the credential storage, I leveraged the power of Mimikatz vault::list to reveal the plaintext password: Defensive Considerations
Here are a few recommendations to deter MTR console abuse:
before applying your baseline Group Policies.
Comments are closed.
|