Author
Mathias Fuchs
Published
28. September 2022
Our partner Vectra has recently published an article, which describes how, under certain circumstances, attackers can gain access to teams accounts’ authentication tokens. There have been a lot of questions about this from our customers, so we have decided to summarise and analyse the most important information here.
Like many other applications today, the Teams desktop application has been developed using a framework called “Electron”. Electron allows applications to be developed once and to run uniformly on platforms such as Windows, Mac OS and Linux. This minimises the effort and increases the application’s reach. Other prominent examples of Electron-based applications are 1Password, Slack, Signal and WhatsApp in their corresponding desktop versions. The use of Electron is not risky per se. However, Electron applications are much easier to analyse than classic programmes.
Vectra researchers have taken advantage of this and taken a closer look at the Microsoft Teams application. Teams users will be familiar with the fact that they do not usually need to log in every time they open the application. This works that way because the Teams server generates a token when you log in, which is used to authenticate all future requests to the Teams server, up until the token expires or is rendered invalid by logging out. Of course, the Teams application needs to consistently save this token so that it does not need to log in again after restarting. Vectra researchers have found that this is done in the form of a LevelDB database stored on the user's hard drive. It is crucial to know that Electron applications are actually web applications that run on a local Chromium browser. The database identified by Vectra is the cookie database of this same embedded browser. A search of this database for the word “token” quickly turned up something.
What does that mean?
The tokens that are extracted by the method described provide access to all team services that are available to the token's legitimate owner. When the token is used, there is no need for re-authentication. This means that in effect, multi-factor authentication is also circumvented.
According to the researchers, the token allows access not only to the Teams-specific APIs but also to the Outlook APIs. However, this should only work if Outlook is also used in M365. It is unclear whether SharePoint can also be accessed, as this service is often used for file exchange in Teams chats.
What are attack scenarios?
Vectra describes different attack scenarios. At InfoGuard, we usually describe attacks using the Cyber Kill Chain. To exploit the situation described, you already need to have access to the file system of the computer on which the Teams application is installed. This means that the attack is already in an advanced phase. Therefore, the potential gap is not suitable for an initial attack.
One potential scenario is that common credential stealers – i.e. malware spread by malicious e-mails or manipulated programmes – are also very swiftly on the lookout for the tokens that we have referred to. This is also the aspect which, in our opinion, is the biggest problem. We do not find credential stealers particularly often on company PCs, but they are much more common on private PCs, where the security settings and secure use of the device are often compromised. Particularly over the past two years, it must be assumed that team applications used for corporate communication often end up on private PCs as well.
So, one potential attack path is that valid Teams tokens are stolen from a computer by a credentials stealer. The attacker can then use these tokens to take over the user's digital identity in the Teams environment. This situation can then lead to information being leaked, as well as also being specifically used to tempt other employees into committing risky acts using the position of trust.
The particularly dangerous scenario described by Vectra of taking over an account of a high-ranking employee obviously requires the token to be stolen from exactly that person’s computer. This reduces the attack surface to some extent.
They go on to describe how the file system can also be remotely accessed. This is correct in principle. However, if attackers in the corporate network already have the capability to access the file systems of external PCs, the Teams token may not be the most urgent problem. In this case, the attackers already have at least one high-ranking account under their control.
Another foreseeable scenario is one where malware is widely distributed; it extracts tokens and exploits them while they are still on the affected PC to generate calls to premium numbers. This would be a direct widespread utilisation of the potential loophole.
Last but not least, Vectra describes how extracting the data from the working memory is more time-consuming, and this makes the loophole described highly convenient for attackers. From our point of view, this is not the main issue, as experiments have shown that extracting from RAM is just as easy if you know what you are looking for. This can also be easily tested with tools like bulk_extractor.
Basically, it is a fact that tokens can be retrieved from file systems and especially from the main memory at many different points in time. This is nothing new, and is only able to be restricted to a certain extent, so it is a good thing that this is not a situation that would permit a primary attack to be made.
Counter-measures
When facts like this are published, there are always questions that arise, of course. For example: What does this mean? Does something have to be done? And if so, what?
The first piece of information related to this is that Microsoft is not currently providing a patch. The Vectra researchers suggest storing the tokens in encrypted form. Unfortunately, this only works to a limited extent. To use the token, it would have to be decrypted again. To do so, the system needs to hold the keys. The net outcome is that it would increase complexity, which is a start anyway. Recommending developers to use the Keytar Library makes sense here, but even this can be very easily bypassed in this case, as access is bound to the application framework and attackers can also take advantage of this. The problem with securely storing credentials on systems that need to use them unencrypted is also seen in other places in Windows systems. If you are interested in knowing about this in greater detail, you should take a look at LSA Secrets.
Another Vectra recommendation – which misses the mark in many of the scenarios described – is to use the Teams web application instead of the installed application. However, as soon as you use web-based software, you become the real hunting ground for credentials stealers, and the corresponding tokens can leak out all over again.
As far as we can see, there is currently no suitable technical solution. There is the option of reducing the token’s lifespan, which would lead to significantly more logins for employees. In the end, however, this only provides limited help if the circumstances that allow access to the tokens (e.g. credentials stealer) are still in place.
As regards potential CEO fraud within the company, it could be said that even before the facts described here became known, it was possible to supposedly take the place of a senior member of staff – and this happens on a daily basis too. This can be done using falsified e-mails and telephone numbers. These alternatives require much less access to the company than what is being described here.
Our conclusion
In short: Don’t panic, but do get to the root of the problem. This means preventing illegal access to computers, or at least detecting it quickly. Usually, the result of detecting this kind of access is to change the password of the affected user anyway, which means that the token is automatically invalidated anyway.
Do you have any other questions? Please contact us. My colleagues and I will be happy to help you.
