Over the years, I have seen many penetration test reports that heavily rely on the results of a vulnerability scanner such as Nessus or Qualys. While vulnerability scans are a critical component of a functional security program and are often included in security assessments, there is a distinction between a vulnerability scan and a penetration test that seems to be poorly communicated. Regardless of which side of the network you support, attack or defense, it is critical to understand the difference between those products. In this three-part series, we are going to look at the motivation behind pentesting, the methods of a realistic and motivated pentester, and some of the tools that may be leveraged at each step along the way.
One of my favorite ways to think about the ongoing maturity of network defense comes from John Lambert, founder and manager of the Microsoft Threat Intelligence Center, at a presentation at the Kaspersky Security Analyst Summit. While I highly recommend watching the entire talk, there is one slide in particular I keep coming back to.
The first pair of concepts, list of assets vs graph of assets, can be extended to include vulnerability scan vs pentesting. Vulnerability scanning cultivates a list of unresolved, potentially exploitable, issues on a network. It may even list them by criticality. It rarely, however, takes into account the sensitivity of the host that is on, who has access to that host, where those users typically operate on the network, etc. A pentest should not rely on the method of the exploit used to gain access, but instead needs to take stock of the current level of access, where the goal is, and what obstacles exist in between those points.
Another item on the list is how pentest results are viewed. Simply relying on a vulnerability scan implies that if all vulnerabilities are remediated, then there is no problem and the environment is secure. A good pentester knows that they are much more likely to have success if they are not wholly relying on outdated patches or remote code execution. Indeed, it is often more effective, harder to detect, and more likely to succeed if the primary escalation methods used are native behaviors.
The final point I want to discuss is the last on the list: modern defenders want to increase attacker requirements. It is well-established that no environment is safe from a sufficiently motivated attacker. The primary goal of defensive security is to increase the difficulty, reduce the reward, and reduce the appeal of a successful compromise. Defense can no longer strive for “absolute security” – that is a fiction. Instead, reduce or remove the motivations behind an attack, and security will follow.
Types of Pentests
How a pentester or red team approaches an engagement is going to depend on the program maturity of the target organization, the capabilities of the attacker, and the desired results. The final scope and ultimate goal of a pentest will need to be determined prior to the signing of a contract, to ensure that all parties are on the same page. Here is a non-comprehensive outline of types of pentests, roughly from least to most technically complex:
With assistance from the IT department, the attacker is allowed to place their own hardware on the network. This hardware is not joined to the domain, and has no user rights. The pentester will need to establish a presence on the domain in order to proceed.
Again with assistance from the IT department, the attacker is given access to a typical organization workstation, generally a newly-configured workstation and a domain account with typical privileges. The pentester will attempt to escalate rights beyond what has been initially granted.
Similar to an insider threat model, an assumed breach again gives the attacker access to internal hardware, but this time the IT department is not aware of the engagement. This serves to test not only the technical controls in place, but also the incident response ability of the information security program, both in timely detection of an intrusion and the effective remediation of a breach.
Whitebox Social Engineering
Unlike the previous scenarios, social engineering tests begin from outside the organization’s network. Typical forms of social engineering include email phishing, pretext phone calls, and physical site visits. In a whitebox test, the attacker is provided a target list of employees, and will generally work with the client to determine an appropriate scenario, scope, and ensure that all materials reach the intended targets via whitelisting, if necessary. This is designed to be both a test of security controls as well as employee security training effectiveness. If social engineering is successful, the attacker will start the pentest with domain user rights.
Blackbox Social Engineering
Unlike whitebox tests, blackbox tests begin with almost no information from the target organization. The attacker will have to gather a list of targets from publicly available sources, and use whatever enumeration tactics will ensure that the test is successful. This closely simulates the approach that a real-world attacker would have to take in order to successfully gain access to an internal network, and is recommended for most mature organizations.
Red Team Operation
A red team operation is a broad test of an organization’s entire security structure, and may include social engineering, joined host, or assumed breach characteristics. The primary distinction between a typical pentest and a red team operation is scope – red team operations are usually long engagements, often lasting weeks or months, with a very broad scope of targets. A red team wants to go low and slow in order to avoid detection for as long as possible.
The Pentesting Model
In a Windows domain environment, privilege escalation is done in this order:
This would be where a “joined host” type pentest would begin. The attacker does not have domain-joined hardware, nor access to a domain user account.
Most, if not practically all accounts in a Windows domain should have domain user rights. If properly secured, this means highly restricted administrator rights to hosts, and limited access to network resources (following the concept of least privilege).
Some domain users may have admin rights over one or multiple hosts. Assuming that domain users are generally not granted admin privileges (although I often see that every user does, despite the risks), individual users may require admin rights for certain software to function properly. Also common is service accounts that are not assigned to an individual person, but instead perform some automated task. Finally, every Windows host has at least one local admin account, which is present before the computer is joined to the domain but can still be leveraged to perform admin actions over that host.
Domain administrators have unrestricted access to the entirety of the domain. This is essentially the finish line of a pentest – once a domain administrator account is compromised, it is trivial to compromise sensitive data, cover tracks from earlier pentesting, and establish persistence on the network.
In environments with multiple domains (namely large organizations), enterprise admins are a step above domain admins, having administrator rights into every domain below them. While most methods of escalating to enterprise admin rights are going to be very similar to the methods for escalating to domain admins, there are some specialized approaches that only apply in a multiple-domain environment. Determining whether or not enterprise admins are in scope should be one of the components of pre-engagement communications with the client, as domains in the same Active Directory forest may not even belong to the same organization.
In the next two posts in this series, we will be looking at some of the tools and escalation methods available at each step of the pentesting process. There are as many methods of escalation as there are networks to test – remember, realistic attackers think in graphs, and each Windows domain has a unique fingerprint. No two pentests will ever be exactly the same, but by loading up with some of the best tools available, pentesters can find recommended remediation in even the most hardened networks. Remember, China doesn’t use Nessus to pentest – and neither should you.
Latest posts by Tyler Butler (see all)
- Pentesting the Hard Way, Part One: What is a Pentest? - July 12, 2016
- Security for Everybody: Secure Your Browser - June 21, 2016
- Cracking Domain Passwords from NTDS.dit with Metasploit and john - May 3, 2016