TL;DR: How to attack self-hosted Skype for Business (Lync) servers. If you're using O365 wait for the next post. Note: For the sake of brevity throughout this post, Skype for Business and Microsoft Lync will both be referred to under the umbrella designation of 'Skype4B'. When companies choose to host Skype for Business (previously Microsoft Lync) on-premises, they can inadvertently introduce a large attack surface. Skype for Business, by design, is meant to encourage communication between individuals and it is often externally-accessible so that employees can stay connected 24x7 without the need for a VPN. This bit of convenience makes Skype4B an attractive target to attackers. In a very real sense, Skype4B provides a bridge from The Internet into a company's internal network, allowing an attacker to interact with the internal Active Directory environment. In this blog post, I will walk through information gathering, user-enumeration, and brute-force attacks against an internal network, using only the attack-surface opened by a standard implementation of self-hosted Skype for Business.

Locating the Front-End Server

Before Skype4B can be attacked, it is necessary to determine the location of the Front-End server.  This server will be our primary target throughout the attack. Luckily, locating these servers is usually not an issue.  Microsoft's recommended naming format for the autodiscover URL is: https://lyncdiscover.contoso.com (external) https://lyncdiscoverinternal.contoso.com (internal) If the 'lyncdiscover' subdomain exists, it will serve an XML file that references the Front-End server. In the example below, the Front-End server is '2013-lync-fe.contoso.com'.

Figure 1 - Lyncdiscover Domain Points to Front-End Server

If XML references the domain 'online.lync.com', then the Skype server in question is hosted by Microsoft and these attacks will not work. (information on attacking hosted Skype will be published in a future post). If the 'lyncdiscover' subdomain does not exist, all is not lost.  The following subdomains will often point to the Front-End server and are worth investigating. dialin.contoso.comscheduler.contoso.commeet.contoso.comWeb Login Portals Having found the Skype4B Front-End server, we can explore the two login portals that are commonly enabled in Skype4B installations: Dial-in Conferencing, and the Web Scheduler. These can normally be found at: https://dialin.contoso.comhttps://lync-fe.contoso.com/dialin/ and https://scheduler.contoso.comhttps://lync-fe.contoso.com/scheduler/

Figure 2 - Dial-In Conferencing Portal

Figure 3 - Lync Web Scheduler Portal

These two portals clearly indicate that the login format is DOMAIN\Username.  Examination of the source code of these pages shows that they both perform a POST of an XML document to the same back-end service located at: https://lync-fe.contoso.com/WebTicket/WebTicketService.svc/Auth Capturing the POST in Burp Suite reveals an XML document containing a base64-encoded username and password. (It is worth noting that while a 'Lifetime' value exists with a short timestamp specified, these values do not appear to be evaluated when testing if credentials are valid). Since login requires a valid internal domain, the internal NetBIOS name will have to be discovered. This is sometimes easy to guess if it is similar to the organization's domain name, but for those domains consisting of cryptic initialisms or shorthand names, Skype again provides a helpful hand.  

Information Leakage via NTLM

Skype for Business is normally configured with a number of directories protected with NTLM authentication. NTLM authentication can be disabled, but in my experience, it rarely is. In real-world testing, the '/abs/' directory on the 'Dialin' or Front-End Skype4B server is a reliable target (e.g., https://dialin.contoso.com/abs/ and https://2013-lync-fe.contoso.com/abs/). If you browse to this path in a browser, a prompt will appear requesting authentication.

Figure 4 - NTLM Authentication Request

Other paths that will likely be protected with NTLM authentication include: /WebTicket/WebTicketService.svc /WebTicket/ /abs/ /GroupExpansion /CertProv /RgsClients /RequestHandlerExt /mcx To extract the internal server name, NetBIOS domain name, and full DNS domain name, all you need to do is fire up Nmap with the 'http-ntlm-info' script, and point it at a directory protected by NTLM authentication: nmap -v -Pn -sS -p443 --script http-ntlm-info --script-args http-ntlm-info.root=/abs/ dialin.contoso.com

Figure 5 - Internal NetBIOS Domain Name Revealed via NTLM

As shown in the screenshot, the internal NetBIOS domain name is CONTOSO. We will use this vital piece of information to next perform a user-enumeration timing attack against the back-end WebTicket service that was identified in the Dialin and Scheduler portals.

 User-Enumeration Timing-Attack Vulnerability

Another information-leaking vulnerability exists in the authentication process in Skype4B that enables an attacker to enumerate valid domain accounts. The basis of the vulnerability is that a login attempt made with a VALID username responds much more quickly than an attempt made with an INVALID username or domain. In this way, it is possible to differentiate valid users from invalid, allowing for further targeted attacks.

Figure 6 - Timing Responses of Valid vs Invalid Usernames in Authentication Attempts

The above screenshot shows the response time on two failed login attempts. Note the short response time for a valid user versus the delayed response for an invalid user. (Side Note: This user-enumeration bug was reported to Microsoft in June 2016. They promptly responded that this "did not meet the bar for security servicing." Further exploration of the issue revealed that this 'feature' is not unique to Skype, but has actually existed in Exchange for years (http://h.foofus.net/?p=784 ). Since this is obviously meant to be a feature, and not a bug, it likely isn't going away any time soon.) To exploit this user-enumeration issue, I developed a tool called 'lyncsmash' (https://github.com/nyxgeek/lyncsmash). To perform user-enumeration attacks, lyncsmash must be supplied with the address of a Skype4B Front-End server, the internal NetBIOS domain name, a list of usernames, and a password to test with. The first two items – the Front-End server address and the NetBIOS domain name – are known, leaving just the username list and password to be selected. If the username format is not known, try a mixed list of common names in standard username patterns, such as the 'top-formats.txt' list from the 'statistically-likely-usernames' set by InsideTrust (https://github.com/insidetrust/statistically-likely-usernames.git). Once the username format has been verified, a targeted list can be created if further enumeration is desired. (Other sources for determining username formats include scraping the metadata from PDFs and MS Office files, as well as examining email addresses.) For password selection, I recommend classic seasonal passwords like Summer2017. Yes, people still use them. To begin user-enumeration using Lyncsmash, run the following command: python lyncsmash.py enum –H 2013-lync-fe.contoso.com –U userlist.txt –p Summer2017 –d CONTOSO The script will first make a series of login attempts against the Skype4B/Lync server with randomly-generated usernames and times the response time. With this average response time for invalid usernames established, the script then proceeds to cycle through the supplied user list. The responses from the server are analyzed, and both valid usernames as well as successful logins are reported.

All Accounts Are Fair Game

One notable design feature of Skype is that there is no way to restrict login attempts to specific OUs. This means that every account, from service accounts to domain admins, can be enumerated and attacked. Depending on lockout policies, an attacker could leverage this feature to gain access via repeated brute force attacks, or cause a denial-of-service condition by locking out accounts. A handy trick to verify that everything is working correctly is to test against the 'krbtgt' account. This account is ideal for testing with because it is a built-in account, it cannot be renamed, and it does not matter if the account becomes locked. As long as the correct domain is specified, the 'krbtgt' account will always return the time-signature of a valid account. Due to limitations of the timing attack, this user-enumeration technique is inherently slow. It must be single-threaded, because if multi-threading is used the response time becomes exaggerated and skewed, and are unreliable for user-enumeration. This built-in speedbump means that processing tens of thousands of usernames will take some time. If time is limited, I recommend switching to a targeted brute-force attack once the username format has been discovered.

Brute Force Attacks

There are two ways to proceed with a brute-force attack against the Skype environment. The first and fastest way is to attack the NTLM-auth directories with a tool like Medusa. This attack has minimal overhead and is multi-threaded. The brute-force speed with this method is so fast that using a generic user list of the correct username format is usually effective. If stealth is not a concern, then it is faster (and louder) to throw usernames against the wall and see what sticks. To attack the /abs/ NTLM-auth directory, use the following Medusa command: medusa -h dialin.contoso.com -U userlist.txt -p 'Summer2017' -M http -m AUTH:NTLM -m DIR:/abs/ -m DOMAIN:CONTOSO –s

Figure 7 - Performing a Brute-Force Attack with Medusa

The authentication service behind the Dialin and Scheduler pages is another target for pure brute-force attacks. Since user-enumeration is no longer the goal, multi-threading can be used, making Burp Suite an ideal candidate. With Burp set to Intercept mode, perform a login attempt from either the Dialin or Scheduler pages using the password that you wish to brute-force accounts with (e.g., 'Summer2017'), and forward the capture to Burp Intruder. Once there, three additional steps are necessary to process the candidate usernames.

Figure 8 - Configuring Burp Intruder for Brute-Force Attack

First, a rule must be added to 'Payload Processing' to add the domain prefix to the username (this could also be performed in the user list itself). This should be in the format of "Add prefix: CONTOSO\" as shown in the screenshot above. Next, the username must be base64-encoded. Finally, be certain to uncheck the box for 'Payload Encoding'. Since the base64-encoded username will contain some of those special characters, URL encoding will cause all login attempts to fail. Once these steps have been completed, a username list can be loaded and the attack is ready to launch. Valid responses are easily identified as they will return a '200' response code.

Figure 9 - Successful Brute-Force using Burp Intruder

Watch for Part 2 of the “Hacking Skype for Business” series, where we will examine Skype for Business with Office365 and Active Directory Federated Services.