How your messenger used for internal communication (Teams or S4B) might compromise your company

In this blog post, some techniques about the messengers Microsoft Skype-for-Business (S4B) and Microsoft Teams regarding attacking a company network are demonstrated.

The following are just some well-known techniques, which work way too often and companies and employees are not aware off. The success rate for this kind of phishing / social engineering is very high.

Most of the named points derive from the mdsec or the mr.d0x blog.

tl;dr

S4B in a self hosted version permits timebased user-enumeration and password-spraying against the complete Active Directory and not only against users with a Skype account
S4B, if external communication is enabled, allows attackers to send messages directly to employees
Teams, even if external communication is prohibited, allows user-enumeration via e-mail addresses,
Teams, if external communication is enabled, allows user-enumeration, status gathering and attackers to send messages directly to employees
If an alias address is in use, e.g. <<ADUSER>>.company.org, Teams and S4B will happily resolve the AD-User to first and last name

Introduction

When we talk about Skype-for-Business (S4B), it is important to note that the predecessor Lync is also likely affected by the same vulnerabilites.

S4B

Detection of Skype for Business (S4B)

S4B can often be detected via a subdomain called lyncdiscover.company.org. If the domain exists, it will typically return an XML file, which reveals where the S4B server can be found.

(curl https://lyncdiscover.##OnPrem##.com).rawcontent
HTTP/1.1 200 OK
X-MS-Server-Fqdn: SI0PLY01.de.##OnPrem##.com
[...]

{"_links":{"self":{"href":"https://si-pool1-webext.##OnPrem##.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=##OnPrem##.com"},"user":{"href":"https://si-pool1-webext.##OnPrem##.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=##OnPrem##.com"},"xframe":{"href":"https://si-pool1-webext.##OnPrem##.com/Autodiscover/XFrame/XFrame.html"}}}

If S4B is hosted by Microsoft, the response would look like this:

(curl http://lyncdiscover.##OnMS##.com).rawcontent
HTTP/1.1 200 OK
[...]

{"_links":{"self":{"href":"https://webdirgb1.online.lync.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=##OnMS##.com"},"xframe":{"href":"https://webdir1E.online.lync.com/Autodiscover/AutodiscoverService.svc/root/xframe"},"redirect":{"href":"https://webdir1E.online.lync.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=##OnMS##.com"}}}

If you follow the link to the S4B server, you may get a 403 - Forbidden: Access is denied. response. You can still identify the S4B by the favicon, or you could just try to reach the /scheduler endpoint. This endpoint displays a wonderful login page for discovering internal ActiveDirectory credentials. Scheduler endpoint

NTLM Authentication

If a S4B instance is onprem, there are several endpoints, which allow NTLM authentication.

An endpoint allowing NTLM authentication leaks some useful information for an attacker. With the tool NTLMRecon or also with an good old nmap script, we can gather the hostname and more importantly the internal domain name (FQDN).

NMAP Extracting Domaindata with Nmap Extracting Domaindata with NTLMRecon

Furthermore, NTLM Authentication endpoints are great for password spraying, as the speed of NTLM authentication is rather fast and also permits multithreading.

User enumeration

If we already discovered the user syntax by OSINT, we can just validate accounts here. One big plus of S4B in a selfhosted environment is that it is querying against the complete ActiveDirectory and also reporting users which definetly have no skype account, like the krbtgt user, which can be used to verify if everything is working.

Tools like lyncsmasher come in handy here, or we can also just use burp to measure the response time. A valid user will have a significant shorter response time then an invalid one. Typically the difference should be about 500ms for valid user and 5s for an invalid user. If the account is disabled, S4B will mention this in a message.

Please note, that S4B will typically take either the e-mail address or the username with the domain prefix, like AD-Customer\MMustermann

Statistically likely

If we don’t know the user syntax, or just want to gather more users, we can use special lists, like the repository https://github.com/insidetrust/statistically-likely-usernames , or gather our own lists, for example with typical lastnames for that country from wikipedia. To create accounts with more variation, we can also try simple tools like namemash.

Be aware, that if there is a custom prefix (e.g. DE1) or suffix to the username, this technique might fail.

Password spraying

Skype will respond in various ways to us.

If the user does not exist, the response will be typically around 5s, or at least significant longer then when we have a valid user.
If we have entered a wrong password, Skype will tell us
If the account is disabled, Skype will tell us
If we have valid credentials, but the account does not have a Skype account, we will get a message
If we can login to Skype

Pew pew pew

Got creds?

S4B does not support MFA by default, so you can login for example under the /scheduler endpoint. Here, you have the possibility to untertake some easy user enumeration by using the check names feature of a meeting. You can upload a few thousand names here and just see which names resolve. The endpoint will happily translate the AD User to an e-mail if there is an account connected.

Skype scheduler

And remember to check https://aka.ms/mfasetup, because an attacker controlled, added MFA is quite useful.

Skype / Teams hosted by Microsoft

As Microsoft announced in 2021 that they are changing the default setting for external communication in Teams, threat actors and RedTeams all over the world celebrated. This opened a new door for highly effective phishing attacks. External communication is now allowed by default and must actively be turned off.

Test tenant

To attack such a setting, we need an AAD with a Teams account. The free version of Teams, does work for enumeration, but will likely not work for communication or display at least more warnings.

Microsoft offers the possibility to register a development AAD. https://developer.microsoft.com/en-us/microsoft-365/dev-program

Developer-AAD Sounds great, doesn’t it :)

There are some restrictions in place, for example, it is not possible to share public available files. However, the Teams service runs great and we can (ab)use this to compromise our target.

Sidenote: The TestAAD also allows us to send emails. However, the score of the outgoing SMTP is so bad, that Microsoft itself does not accept those emails for other tenants. But, of course, there might be a lot of companies out there which still accept those kind of emails.

Leak of user information

Sometimes Skype does permit communication from external users, meaning from another tenant. By using Teams, it is also possible to query Skype. Therefore, we can check from a tenant with access to Teams if external communication is allowed.

If the external communication is allowed, we can gather the status of the user (available, busy, dnd, out-of-office).

Developer-AAD User Enumeration

But even if not, we still can verify emails against the company, as Teams will return a different message if the user exists. Developer-AAD User Enumeration

We can also do this in a automated manner, either via proxy (Burp Suite) or via GoMapEnum.

Skype or Teams phishing (skyshing / tishing)

Sometimes Skype does allow communication from external users, meaning from another tenant. As Skype is typically regarded as internal communication tool this is a high efficent phishing vector!

An additional interesting feature is that the message will be sent as an email, if there was no reaction over some time. This allows us to send a email, technically coming from the internal Skype server to the user. This mail will typical not be flagged as external and also not land in quarantine.

Faking a contact person

With our developer AAD, we can add users as we wish. For example, we can add some user called ithelpdesk@company.com as nickname. Unfortunately, we can not simply improve this, by adding a generic company logo as profile picture, because the profile picture is not shared across the tenants.

Developer-AAD Showing the Identity

If we start a group chat instead of a one-to-one chat, different and more dangerous scenarios from the defender perspective arise. A quite effective attack is attacking two employees at the same time.

If we have a look at the account, this is quite confusing and does trick people into believing the identity of the account. Only by hovering over the account preview, there will be a full address like it-helpdeskcompany@t0#####.onmicrosoft.com which is still quite trustworthy, as onmicrosoft.com emails are used for every AAD in background. Furthermore, as the name of the AAD can be choosen during the setup phase, it is also possible to choose something like selfservice-company.onmicrosoft.com.

Spoofing

S4B / Teams does also not offer protection against spoofing things in messages. For example, a simple HTML spoofing is possible. Meaning the text and the link are pointing to different sites. By looking at the requests necessary to send a new message, it is quite obvious how to change the tags. Developer-AAD Spoofing a link

By doing this, it is possible to craft messages, which open a malicious URL despite showing a company owned URL. Developer-AAD Spoofed link in message

This is a very well-known attack vector for emails and most appliances detect this technique for emails.

Analysis of TOP DAX companies

To further provide some data about the possible risk, the DAX-Companies have been quickly analyzed. The DAX (Deutscher Aktienindex (German stock index) is the most important stock market index consisting of 40 major German companies:

Adidas
Airbus
Allianz
BASF
Bayer
Beiersdorf
BMW
Brenntag
Continental
Covestro
Daimler Truck
Deutsche Bank
Deutsche Börse
Deutsche Post
Deutsche Telekom
E.ON
Fresenius
Fresenius Medical Care
Hannover Rück
HeidelbergCement
HelloFresh
Henkel
Infineon
Linde
Mercedes-Benz Group
Merck
MTU Aero Engines
Münchener Rück
Porsche SE
Puma
Qiagen
RWE
SAP
Sartorius
Siemens
Siemens Healthineers
Symrise
Volkswagen
Vonovia
Zalando

These companies have been analyzed in regard to their S4B or Teams infrastructure. The following very simple methodic was used:

Find the main domain and some email addresses

To gather some email addresses and the main domain, common third party tools can be used. Just to name some: phonebook.cz, … Just take the TLD with the most hits, in most cases this is good.

Developer-AAD Collect some emails for checks

Check for Lync / S4B

Enumerate some subdomains to identify Lync / S4B installations. The most common subdomains are:

lyncdiscover.company.org
meet.company.org
dialin.company.org
lync-fe.company.org

The following script was used:

add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
    public bool CheckValidationResult(
        ServicePoint srvPoint, X509Certificate certificate,
        WebRequest request, int certificateProblem) {
        return true;
    }
}
"@
$AllProtocols = [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12'
[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy


$dax = Import-Csv D:\dax.csv # A list with the DAX domains
$dax | ForEach-Object {$u = "https://lyncdiscover.$($_.domain)"; $u;  iwr -uri $u}
$dax | ForEach-Object {$u = "https://meet.$($_.domain)"; $u;  iwr -uri $u}
$dax | ForEach-Object {$u = "https://dialin.$($_.domain)"; $u;  iwr -uri $u}
$dax | ForEach-Object {$u = "https://lync-fe.$($_.domain)"; $u;  iwr -uri $u}

Identify if external collaboration is enabled

By querying the endpoint https://teams.microsoft.com/api/mt/part/emea-03/beta/users/FIRST.LAST@company.com/externalsearchv3?includeTFLUsers=true with the adjusted data from the email gathering, or by just using the search field in the webclient, we can detect what setup is in use. A typical result will look like this: Developer-AAD Result of the external collaboration

Outcome

The results of the checks are a little bit suprising:

24 / 40 still have S4B in place, some hosted by Microsoft (online.lync.com).
08 / 40 have a self hosted and reachable S4B instance
35 / 40 use Teams or Teams <-> S4B interaction
10 / 40 allow external tenant communication

Detection & Mitigation

It is necessary to differ here. Password spraying can be detected by logging the amount of failed attempts. As the lockout policy will likely not trigger, it is important to monitor a bigger timeframe, like five failed attempts for one account within 24h. Tools like Microsofts Defender Identity can support here.

There is no protection against Teams email enumeration, besides to stop using Teams. However, a company email address should not be considered as secret, as there are several ways to gather and verify them.

To protect against tishing (phishing via Teams), the easiest solution is to block external communication and to use the allowlist feature provided by Microsoft.

These settings can be made in the Teams administration, similiarly for S4B.

Developer-AAD Teams settings for external communication

And as usual, if there is no technical countermeassure, users should be trained to be aware of the risk. However, as we know, there will always be this one click, or this one password entered.

Conclusion

Microsoft’s S4B and Teams deliver an attacker a good attack surface. At a minimum, it is possible to enumerate email addresses and therefore validate users collected from OSINT. If there is a selfhosted S4B, it permits password spraying against the ActiveDirectory and will leak the FQDN of the server. If external tenant communication is allowed, an attacker could perform tishing, which is very effective, as most employees see Teams as an internal messenger and therefore trust it. The fact that, for example, the username or links can be spoofed increases the chances of an attacker to deliver an successfull attack.

It is strange that the security features, which were implemented for email appliances over decades are just ignorred for messengers. Furthermore, the decision from Microsoft to enable the external communication by default is highly questionable from a security perspective.

Links

Work and inspiration from others: