In our last blog post, we showed how pen testers can use misconfigurations within Active Directory group management to escalate privileges. However, that technique is heavily dependent on having access to privileged or misconfigured accounts in the first place.
This week, we discuss another finding that we frequently take advantage of during both the privilege escalation and post-exploitation phases of our assessments. Having access to account credentials is a vital aspect of every penetration test, so we are always on the lookout for methods to obtain valid password credentials of key accounts within the organization. We use a variety of techniques to gain access, but one of the simplest and most reliable methods is to find clear text credentials on the internal network. Clear text passwords don't require decryption to be viewed.
On some assessments, the user accounts we initially compromise from phishing emails enable us to spread laterally within the network and escalate the domain. In other assessments, our initial access does not grant administrative access anywhere in the organization. In some cases, organizations are adequately managing their Active Directory groups to avoid such misconfigurations, and in others, our phishing emails are unable to trick any of the organization's more privileged users. Regardless, there are some assessments where we can't immediately escalate the domain by abusing Active Directory groups. This is a strength for the organization. However, it makes our job as pen testers more difficult.
If we can't escalate the domain, the next step is to leverage our current access to get additional credentials within the organization. This is where share-hunting (finding internal file shares on the network) comes into play. Organizations have been doing a better job of locking down administrative access to internal hosts, but they may not always lock down access to internal file shares. Even though a normal user may only need access to a limited number of file shares for their day-to-day work, they may have been granted access to additional share drives.
We prefer to use the Invoke-ShareFinder function from the PowerShell script Powerview.ps1 to identify which file shares are available in the network. This script identifies all hosts in the current domain, and queries each one directly to determine what shares are available. Furthermore, it can also attempt to read from each share to determine what shares the current user can access. The result is a comprehensive list of all shared drives that our compromised user can read. This list includes the primary file shares that employees access on a regular basis, plus old file shares that may be left over from legacy systems or misconfigured hosts that were not intended to share data.
Once we have a list of all shares, the next step is one of the most tedious parts of penetration testing — we spend time looking through shares for interesting files. There are some keywords we can trigger for automated searching (e.g., password, secret, config), but our testers frequently attain more valuable files by manually searching for them. Sometimes we will get lucky with a "passwords.txt" or "passwords.xlsx" file, but normally we end up finding forgotten domain administration scripts or system configuration files that contain hardcoded passwords. Once we collect credentials for various accounts, we will attempt to validate them and use them to spread laterally, while continuing to escalate our privileges within the domain.
One important thing to note is that most of our public sector clients have implemented multi-factor authentication for regular user domain accounts. This means that all users require a smart card and PIN to perform an interactive login. Although this does not stop us from using compromised accounts for lateral movement, it does cut down on the number of valid clear text passwords we find for domain users. However, many Service Accounts and Administrative Accounts do not user multi-factor and still use traditional username and passwords combinations for authentication. This makes those privileged accounts significantly easier for us to abuse – and for malicious hackers to exploit.
A critical part of any assessment is the post-exploitation phase. Not all executives fully comprehend the risks associated with an attacker gaining domain administrator privileges to their organization. Therefore, the purpose of this phase is to show impact to help executives better understand the risks that come from their organization's vulnerabilities and misconfigurations.
We find it most effective to show impact by identifying and exfiltrating highly protected information. Sometimes this takes the form of Personally Identifiable Information (PII) such as Social Security Numbers; other times it takes the form of sensitive budgeting and billing documents.
Most organizations take additional steps to safeguard their most sensitive information. Frequently, we find that systems containing sensitive information are not joined to the domain, but instead managed by separate, local accounts. Therefore, gaining domain administrator level access does not provide us direct access to sensitive data. In this case, we try to hunt down the administrators in charge of these systems to monitor how they access these systems (e.g., SSH, web applications) and the accounts they use.
Once we're on the administrator's workstation, we often find that admins write down their passwords in an insecure format. Oftentimes it is as simple as a clear text file on their desktop, or a home share named something like passwords.txt, secret.docx, or stuff.xlsx. In addition, we sometimes find administrators storing all passwords in an encrypted file, such as a KeePass file.
On the surface, this is a good practice that we encourage of our clients. However, it is very important that this file is protected by a very strong password that only the owner knows. On multiple occasions, we have seen admins shortcut this process by saving both the location of the KeePass file and its associated password in an insecure medium (e.g., passwords.txt).
These clear text password files provide invaluable information for our testers. First, they almost always provide valid credentials to the sensitive system that we are attempting to access. It is likely possible that we could get the same credentials by starting a keylogger on the admin's workstation, but having access to the clear text file can save us a lot of time. Next, admins are typically responsible for administering multiple systems, so these password files also provide credentials to other sensitive systems we may not have discovered.
Frequently, these password files also tell us the location (e.g., hostname, IP address, web URL) of the sensitive system where the credentials are used. Again, this is something that we might have been able to identify provided enough time, but obtaining files that give us an exact roadmap of where sensitive data is stored, and how to access it, will save our testers a significant amount of time – or again, make it easier for attackers to get into this valuable information.
Proper auditing of internal file shares is a very important task for any organization. It is critical that organizations apply the principle of least privilege when assigning access controls to internal file share access. Proper auditing may also help to discover hosts that are misconfigured to allow excessive sharing. Auditing of individual stored files can help limit exposure of credentials stored insecurely within the network. Enabling two-factor authentication where possible can also help mitigate risk associated with possible insecure administrative credentials. Lastly, restricting the IP space that can log into these servers can slow down our testers from using credentials we find during the assessment.
In our next blog, we will discuss the pitfalls of weak service account passwords. Catch up on the latest blogs in our penetration testing series, and learn more about our penetration testing services.