I had a manager who liked to say, "There are no advanced techniques – only the basics, mastered." While I'm not sure that always applies to this field, I think the core lesson holds a lot of wisdom for information security professionals.
So, in the interest of getting better at the basics, I reviewed our 2018 penetration testing projects and reports to see what issues were at the heart of these engagements. Even though each assessment took place in a different environment, noteworthy trends became apparent as I looked at them side by side.
I focused on internal penetration testing engagements, which occur from within a client network and allows our team to identify security risks posed by an attacker who has bypassed the external defenses (through phishing, vulnerable applications, etc.) or gained physical access to the network as an employee, contractor, or visitor. These assessments give us a unique perspective on an organization's security posture.
During this process, I looked at the exploit chain (the discrete steps taken between gaining network access and achieving the assessment goals) for each engagement and identified the most prominent issues repeated across internal testing engagements. This allowed me to see what the most successful attacks have been and what the most effective mitigations might be.
In this post, I’ll examine five of the most common issues found in internal environments throughout 2018 that directly contributed to domain, system, and data compromise:
This technique is simple, effective, and could have been used in most of the internal environments tested in 2018. This technique requires a low threshold of technical skill to perform it, and mitigating this type of attack should be a priority for Blue Teams.
How it works
When the local "hosts" file and Domain Naming System (DNS) both fail to resolve name resolution queries, Windows uses the Link-Local Multicast Name Resolution (LLMNR) protocol as the initial fallback, followed by the NetBIOS Name Service (NBT-NS) API as a secondary option. Both methods broadcast a name request to the local subnet in the hopes that another host has a record for the requested resource.
The same thing happens if Windows hosts do not receive a web proxy configuration through Dynamic Host Configuration Protocol (DHCP). The host will look for instructions for accessing corporate web proxies with the Web Proxy Auto-Discovery Protocol (WPAD) by querying its hosts file and DNS for systems named "wpad" (e.g. "wpad.example.com"). If no suitable response is received, it falls back to LLMNR.
This process, however, is fundamentally flawed. Windows hosts will implicitly trust the first response to LLMNR and NBT-NS requests, regardless of where the response came from, and it has no way to determine if it is accurate. This allows attackers on a local subnet to listen for such requests and respond with their own address. When the Windows host attempts to access the resource, it is coerced into providing the NTLMv2 password hash of the logged-in user as a part of the authentication process.
Captured NTLMv2 password hashes are not immediately useable on the network for pass-the-hash attacks the way ordinary NTLM hashes are but can be "cracked" to recover the plaintext password.
Several steps may be required to fully mitigate this type of attack. First, if business requirements allow, disable LLMNR and NBT-NS. These Windows components are typically only used when Windows hosts cannot resolve resources through the DNS. If the corporate DNS can resolve names that are needed within the internal environment, LLMNR and NBT-NS are not required.
Additionally, a WPAD DNS entry should be created in all corporate domains and subdomains (e.g. wpad.example.com and wpad.subdomain.example.com). This entry should direct hosts to the corporate web proxy, or an inert address, such as a host's loopback address.
As always, ensure these steps are thoroughly tested before being widely deployed.
Weak passwords are so common that I expect them to be an issue at most organizations. Many 2018 engagements hinged on users’ propensity to select poor and predictable passwords (if your password is "Winter2019!", you may want to change it right now).
One reason weak passwords featured so heavily in our 2018 exploit chains is because there are several ways they can be exploited besides simply brute-forcing login fields. As previously mentioned, successful NBT-NS and LLMNR poisoning provides usernames matched with NTLMv2 hashes. NTLMv2 hashes are not useful by themselves, but they can be "cracked" by 1) guessing a possible password, 2) hashing that guess, and then 3) comparing the result to the original hash from the network. Run that through a few powerful GPUs, and you can reasonably make tens of millions of guesses every second. Under these conditions, weak passwords are revealed quickly and used to authenticate to resources as if we were normal users.
Likewise, hashes for service accounts can be obtained through attacks like Kerberoasting once a valid domain account is compromised. Weak service account passwords, when cracked, typically allow for the escalation of privileges within an environment because of the often-privileged roles of the accounts. (Now seems like a good time to recommend service accounts not be domain administrators).
Weak passwords continue to be useful after we gain control over a domain. Domain Administrator privileges make it possible to create a copy of the Active Directory database, including hashed passwords for all domain users. In time, most of these can be cracked, providing access to internal resources that may not have been available before (e.g. MSSQL servers).
If the idea of a GPU-laden password cracking apparatus sounds expensive, specialized, and far-fetched, think about your friend's Ethereum mining rig that's now collecting dust. I know that might be hurtful, but the truth is that the hardware is available, and these types of attacks have never been more practical.
Creating a strong password policy that balances security and usability can seem challenging. But strong password policies will go a long way in limiting the effectiveness of password attacks. And a great way to identify and proactively weed out weak passwords from your organization is by conducting the same type of password audits regularly. Snarky comments about idle Ethereum rigs aside, an excellent resource for getting started with password cracking without the hardware overhead can be found here.
Sometimes it doesn't matter how strong a password is. Complexity requirements are not meaningful when an unencrypted password can simply be taken from system memory, which is what happens in the case of credential theft. This is a very common and critical component to internal attacks, the favorite tool being mimikatz and its myriad of implementations.
Mimikatz targets Windows' Local Security Authority Subsystem Service (LSASS). The LSASS is responsible for storing credentials so users can automatically authenticate when accessing resources that require the original passphrase. With SYSTEM level privileges (or local administrator with debug privileges), these credentials can be decrypted through the injection of a malicious Dynamically Linked Library into the LSASS. Plaintext passwords, hashes, certificates, and Kerberos tickets for every open session since the system's last boot can be retrieved.
There are several reliable tools publicly available that significantly lower the barrier of entry for anyone with administrative rights (like users with local admin rights on systems where domain administrators have also logged in). To make matters worse, this process can be automated through a variety of tools, executing mimikatz across entire subnets within minutes and obtaining many plaintext passwords very quickly. This is part of the reason for the success of NotPetya.
Sadly, the process for preventing credential theft in a Windows environment is quite complicated. The most important step is to limit administrative privileges to only those who need them and to monitor for unusual authentication events. Easier said than done. Microsoft provides more concrete guidance on Credential Protection and Management, which boils down to a few key points:
For systems prior to Windows 8.1 and Windows Server 2012 R2, ensure Microsoft’s KB2871997 patch is applied and the UserLogonCredential registry entry is set to 0.
Additional recommendations to help mitigate the effects of credential abuse can be found in the Mitigating Pass-the-Hash and Other Credential Theft white papers. They’re good reads, but if you want the CliffsNotes: Most strategies will still depend on effective detection through monitoring event logs for suspicious or weird authentication events.
Remote Code Execution (RCE) describes conditions where an attacker can run arbitrary code on a victim's system from somewhere else on the network. In 2018, critical RCE vulnerabilities significantly contributed to the compromising of critical assets in internal environments on a few of our engagements. In the context of an internal penetration test, this is almost certainly the result of unpatched systems or applications.
RCE vulnerabilities vary greatly in where and how they are found, whether in the Windows operating system or as unsafe deserialization of unauthenticated Java objects in IBM WebSphere application servers. However, the constant is they allow control over a system by enabling an attacker to execute malicious code that they made up, which is never a good thing.
Often, serious RCE vulnerabilities exist because no one knew an application was vulnerable (or that it even existed). Often a system was missed during patching or the impact of a missed patch was not realized. Preventing, identifying, and removing known RCE vulnerabilities from an internal environment can be straightforward with the two-pronged approach of robust patch management and vulnerability management. Though a bigger deal than flipping a registry value, these cornerstone programs can handle much of the responsibility of quickly repairing serious vulnerabilities, validating the fix, and identifying any gaps in coverage.
Accessing assets “protected” by default credentials or no credentials at all was surprisingly common and effective in 2018, and one of the least technical issues that emerged during this review. A few instances included: administrative local Windows accounts with no passwords, default secure shell (SSH) credentials on appliances, and unauthenticated Network File System (NFS) shares with backups of critical systems and data.
The risk involved here should be obvious, but the gravity of these issues cannot be overstated. Providing a foothold within the internal environment, regardless of how inconsequential the resource may seem, can quickly become a very serious issue through privilege escalation, lateral movement, and further exploitation.
Sensitive resources should require authentication and access controls based upon business needs. Non-sensitive resources should be authenticated because someone, at some point in time, will likely introduce sensitive data to it. Changing default credentials should be an explicit step in deployment processes. These credentials are known information, often made available by the manufacturer, which means the resource is effectively unauthenticated. Additionally, a thorough vulnerability management program can help identify most issues.
Stolen or cracked passwords are pointless unless they can be used somewhere it counts. Leveraging stolen credentials to move laterally within an environment without anyone noticing is invaluable to attackers and one of the most significant issues facing many organizations. Although a serious concern, addressing this issue can be complex and often differs between environments. For general rules, monitoring for unusual login events and implementing multi-factor authentication (MFA) can have a debilitating effect on lateral movement.
The trends listed here are by no means the only issues that I came across – just the most prevalent. They are not necessarily the most "advanced" issues, but more the "basics" organizations need to master. Admittedly, this is not groundbreaking research or novel new concepts, but from a testing perspective, these issues are certainly the lowest-hanging fruit for attackers. My goal is to bring attention to the most common critical issues we continue to see on internal penetration tests. If those responsible for defending organizations from security threats can identify, monitor, resolve, and master these issues, they can improve their internal security posture by leaps and bounds.
Subscribe to Focal Point's Risk Rundown below - a once-a-month newsletter with templates, webinars, interesting white papers, and news you may have missed. Thousands of your colleagues and competitors have signed up! You can unsubscribe at any time.