Recently, the Rhino Security Labs team was tasked with an internal network assessment for an environment which ran a predominantly Windows environment. There are some bells that go off immediately in an assessor’s mind when within a Windows network, such as checking for anonymous write access to shares, if SMB signing is enabled uniformly, and checking if  LLMNR/NBT-NS protocols were disabled on workstations. These three things in tandem can allow for a swift compromise of an internal active directory environment.  The purpose of this blog is to illustrate how being cognizant of how tools operate can net you unexpected access.

More specifically, attacks can come from many angles. As a security professional, it is important to focus on vulnerabilities in context. As a penetration tester it’s your responsibility to take in all sorts of information, process it and see how these pieces fit together as part of a larger puzzle and share that detail with your clients. Providing that insight is an essential part of helping to set a higher bar for security and reduce the likelihood of an attack.

In nearly every environment, the LLMNR and NBT-NS protocols tend to be enabled on workstations. The details of these protocols fall outside the scope of this post, but when these protocols are enabled it becomes trivial to relay captured hashes to machines without SMB signing to gain code execution (A full guide can be found from @byt3bl33d3r’s blog post here). To expedite the process of capturing and relaying hashes, additional -r and -w flags are passed to pick up clients connecting to the internet. While monitoring the logs of the relaying session (using Core Security’s impacket framework), the team noticed an interesting line of output from the logs:

It appeared that a client was beaconing out to a login page that passed its login parameters via a GET request with query parameters user-id, password and ismd5. Blindly dropping the this password hash into hashcat failed as the password was _not_ MD5 after all. This indicated some transformation may have been done on the MD5 hash during the submission of the credentials. As a result, if we could discover the transformation mechanism, the team could recover the MD5 password hash.

Doing some basic google searching for the path /sm_login/sm_login.asp led us to discover the device was a ShoreTel Communicator, a teleconferencing device. Cross referencing this with the results of an nmap scan that fetched HTTP Titles, we successfully discovered the address of the Shoretel Communicator Device. The first and most obvious thing to attempt was to simply copy paste the full path including the user-id and password query parameters to see if the device would successfully authenticate us.

The device authenticated us successfully, but we were presented with a JSON response, most likely returned from an API. To gain access to the web interface we would need to dig deeper into the login page of the device to determine how the password hash was being transposed. The HTML of the login page wasn’t overtly complex, and by inspecting the HTML we discover the culprit of our mismatched hash length.

Now that we know how the password hash is being transformed we can inspect the jumble_client.js file to reverse the algorithm. This reversing would’ve been necessary if the jumble_client.js file didn’t already contain a function to reverse the transformation. The function JumbleHexToPlain simply does the reverse of PlainToHexJumble, which allowed us to recover the MD5 of the login.

Finally, passing this MD5 hash to hashcat yielded a successfully cracked password as shown below.

Now that we had both a username and cleartext password we could successfully authenticate to the ShoreTel Communicator. This granted access to voicemails, call history, the ability to make outbound phone calls and more.

Attacking an environment can be done from many different angles. As a penetration tester it’s your responsibility to take in all available information, process it and see how these pieces fit together as part of a larger puzzle. At the onset we were trying to relay hashes to machines without SMB signing to gain code execution; however, because we were diligent and monitoring our logs, we were able to compromise another (unexpected) asset – the ShoreTel Communicator – through a series of chained analyses.
Being aware of your environment and the data your tools collect can make the difference between a successful and failed engagement.

Services that use DNS for authentication have been on ICANN and DHS’s radar for at least a year. When first searching for the /sm_login/sm_login.asp path, we located a presentation on the Ordinal Dataset that showed a variety of services that used DNS for authentication. The presentation can be found here: https://www.icann.org/en/system/files/files/presentation-ordinal-datasets-colliding-domains-13may17-en.pdf