Over the course of the past six months, I’ve noticed a common theme of vulnerabilities when performing internal, external, and application penetration assessments for our NTT Group clients. In each case, the presence of these vulnerabilities allowed NTT Security to gain unfettered access to the domain, a critical environment or allowed access to exfiltrate sensitive data. In some cases, several of these vulnerabilities were exploited in a chained manner in order to gain high-privileged access. So, without further ado, here’s the list.
Internal Penetration Assessment
- Weak Passwords/Shared Accounts
- Legacy OS Support (E.g., MS08-067)
When reviewing the above list, one can determine quickly how old some of these vulnerabilities are and may question how can these types of vulnerabilities still exist in networks today? While I’m sure I could write an entire blog on answering this question, that will have to happen another time. Instead, let’s look at these vulnerabilities and how we use these vulnerabilities to successfully compromise a host or an entire domain.
This is a well-documented critical risk vulnerability that became public with the Equation Group/Shadow Brokers tools disclosure.  MS17-010 is the Microsoft Security bulletin identifier associated with vulnerabilities in Server Message Block v.1 (SMBv1) related to the Shadow Brokers’ disclosure. Several tools are available to exploit this vulnerability including working versions of exploits crafted from the Shadow Brokers’ tools and information, . Metasploit tools are available to exploit CVE-2017-0143, CVE-2017-0146, and CVE-2017-0147 which are all associated with MS17-010 and the Shadow Brokers’ disclosure. If or when an AV solution picks up on the Metasploit exploits, a tool called  Fuzzbunch can increase success as long as you do some work to get it working against additional versions of Microsoft Windows and Microsoft Windows Server.
Successfully exploiting these vulnerabilities grants NT Authority\System level access to the host. This high-privileged access then allows us to retrieve user account hashes from the compromised system, in-memory clear-text credentials for local and domain users who are either currently authenticated to the host, or who didn’t log out of the host properly. MS17-010 is usually one of the first vulnerabilities we’ll look for when performing reconnaissance against the internal network, because we know we will have a high rate of success when attempting exploitation.
Link Local Multicast Name Resolution (LLMNR)
 For those not familiar with how this protocol works, I’ll give you a quick overview. Essentially when a host makes a request that a DNS server either can’t resolve or doesn’t respond to, the host will send out an LLMNR request to obtain that information. By poisoning responses to those requests, we can convince the requesting host we have that information and are willing to give the host that information after they authenticate to us. Hopefully the word “poisoning” should give you a clue that we’re not really an authoritative host to provide that information, and the requesting host doesn’t really ask. Thus, we see the weakness in the protocol itself. As a result of successfully poisoning responses, we can sit back and start collecting user hashes which we use in offline password attacks.
While exploiting LLMNR in this way is good, it is often slow and relies on an organization using easy to guess passwords. Yet another way to attack the LLMNR protocol is to replay or relay captured user hashes in order to get an authenticated session on the requesting host. This type of attack requires another vulnerability in how SMB is configured on hosts, specifically the default configuration of SMB message signing turned off. With the presence of LLMNR (or NetBios over TCP Naming Service), one can relay captured authentication attempts and login to the victim host in order to run a command under the context of the requesting user. Typically, Threat Services’ consultants will establish Command and Control (C2) by delivering a payload to the target system. Thus, granting us stable access to the system.
 These are vulnerabilities that, as old as they are, keep on giving shells, and as consultants, we love finding them for the same reason we love finding MS17-010. Exploits for these vulnerabilities are incredibly reliable and some of them help evade AV when attempting exploitation. Successful exploitation also grants NT Authority\System level privileges on Windows targets. We find that Metasploit exploits/payloads seem to get picked up by AV rather quickly, as expected. We’ve had particular success with another  python-based tool granting a shell type functionality which allows us to execute commands and inject our C2 payload into the system’s memory. Again, this vulnerability is an initial method we use to compromise a host. Along with these, Java Deserialization vulnerabilities in JBoss, IBM WebSphere, and other products using the Apache commons collections libraries, grant a similarly reliable way into a host.
Weak Passwords/Shared Accounts
This next item on our top five list may or may not come as a surprise to some of you but depending upon how early in the assessment we are able to uncover user passwords or hashes, exploiting this type of vulnerability can provide an opportunity for an initial compromise. It can also make lateral movement through a network easier by allowing authentication to additional hosts.
Shared user accounts are a very common finding, hence why it made the list. If several hosts use the same password for the ‘Administrator’ account, when we are able to compromise one host, for example by exploiting any of the previously listed vulnerabilities, gathering credentials off of one system enables us to move laterally onto other systems configured with the same credentials. Several tools such as  Microsoft LAPS exist to help with the resource overhead involved with using a unique password for each local ‘Administrator’ account but even those tools have their own weaknesses. For example, on a recent engagement my teammate and I were facing an enterprise-wide configuration of LAPS. This helped to prevent lateral movement using shared local accounts. However, we discovered a domain user account that was used to run services on several hosts. This also happened to have local ‘Administrator’ access on a large number of hosts in the environment. So, while LAPS prevented us from using the local ‘Administrator’ account, we could accomplish the same task using the Domain account used for running services.
Legacy OS Support
If anyone tells you that change management and patch management are easy, I would argue it is quite the opposite. I’ve seen a rather large number of Windows XP, Windows Server 2003, and even Windows Server 2000 hosts on recent engagements all with a common theme. They host legacy applications critical to the organization’s business. I don’t think this is a unique challenge for today’s organizations and I’m sure many enterprises have some sort of legacy system or systems running on their networks. Needless to say, older vulnerabilities such as MS08-067 and others may work reliably on these versions of Windows and Windows Server, along with MS17-010. Like the above, these Legacy OS vulnerabilities often provide NTT Security consultants an initial way onto the host.
Typical Methodology or Process
The process that has worked well for me over the past six months for gaining initial access looks something like the following:
- Port scanning to identify live hosts by looking at TCP ports 21-25, 53, 80, 88, 137, 443, 445, 8080, 8443, 9080, 9001, 9007, and UDP 53, 137, 161
- Additional live hosts are identified by interrogating DNS and then scanned for the same open ports, making sure not to scan the same host more than once
- Filter the output of tasks 1 and 2 to further scan TCP port 445 hosts with service enumeration to identify OS version, and the NMAP scripting engine scripts looking for MS17-010, and SMB configuration
- Filter the output of task 1 to get service output of port 80, 443, 8080, 9080 looking for JBoss, IBM WebSphere hosts service banners
- If hosts are found vulnerable to MS17-010, I attempt exploitation with Metasploit or Fuzzbunch to deliver a C2 payload to the host to try and gain initial access
- If hosts from task 3 are discovered, I run additional tests to see if JMX-Console, JMXInvokerServlet, EJBInvokerServlet exist, and are accessible without authentication
- If by this point, the environment is patched, and I don’t have access to any hosts, I’ll run additional checks to see if LLMNR is enabled on the network
- Depending upon the output of task 7, I’ll begin poisoning LLMNR and NBT-NS responses. If SMB Signing is disabled, I’ll relay hashes to gain access to hosts by running a command to inject a C2 payload into memory
- If SMB message signing is disabled, collected hashes from LLMNR poisoning will go to the password cracking machine we have at NTT Security to speed up offline password cracking
- If the above doesn’t net initial access to any hosts, then the iterative process of reconnaissance, vulnerability discovery, exploitation, post-exploitation, and clean up continue until we achieve the goal of the engagement
Root Causes and Recommendations
Each vulnerability on the top five can be broken down to the following gaps in an organization’s Information Security practice:
- Change Management (Legacy OS Support)
- Patch Management (MS17-010, Legacy OS Support)
- Configuration Management (LLMNR/NBT-NS, JMX-Console, JMXInvokerServlet, EJBInvokerServlet)
- Server Hardening (LLMNR/NBT-NS, JMX-Console, JMXInvokerServlet, EJBInvokerServlet)
- Password Policy/Password Management (Weak Passwords/Shared Accounts)
Fixing these gaps can cost an organization a considerable amount of resources, especially managing local ‘Administrator’ accounts for all of the hosts within their environment. Tools such as  Microsoft’s LAPS can make this process easier but come with its own considerations as highlighted previously in this blog. If your organization must support legacy operating systems or devices, I cannot stress enough, how important it is to isolate those systems into their own segment using only required ingress and egress firewall rules. The idea is that if the hosts become compromised, an attacker will have a difficult time moving out of that legacy environment into adjacent network segments. An egress firewall rule from that environment might use a default deny all ruleset but allow established/related outbound. This assumes the hosts don’t require DNS, or DHCP access to adjacent environments.
Patching requires testing in order to make sure patches don’t break other applications or services running on the host. In the case of MS17-010, disabling SMBv1 goes a long way to help mitigate the vulnerability. Still, nothing beats timely patching, as difficult as it can be to execute on a regular basis. Centrally managed patch management tools can help with this, such as using Microsoft’s Windows Server Update Services.
Make sure to continually update your Configuration Management and Server Hardening processes and procedures to make sure unnecessary protocols or services don’t introduce additional risk into your organization. LLMNR and NBT-NS can provide a beneficial function, but I find the risk of running these protocols far outweighs the benefit in many organizations. Disabling them requires little testing, and there’s a low risk of causing disruptions on the network.
The challenges to close gaps in the aforementioned processes can be quite daunting. Using a trusted advisor and partner like NTT Security goes a long way in helping your organization mature its Information Security program in a way that most benefits your organization. Penetration testing services performed by the Threat Services team can help identify unknown organizational risk in IT assets, as well as provide remediation recommendations for closing the identified gaps. Other NTT Security consulting services can help provide higher executive level oversight to any organization looking to augment their staff and mature their Information Security practice.