InfoSec Basics - Pen Test!

Pen test? That’s when you try to identify who’s who in this photo of the famous magicians Penn & Teller (https://en.wikipedia.org/wiki/Penn_&_Teller), right? The correct answer, of course, is that Penn is on the left, while Teller is on the right. Fun fact: It’s even easier to tell them apart when they’re talking since, well, Teller doesn’t (at least during performances).

Wait, what? That’s not what a pen test is?

Seriously, a “pen test” (https://en.wikipedia.org/wiki/Penetration_test, also known as a “pentest”, or “penetration test”), is an “authorized simulated attack on a computer system”. The term has a technical meaning in the InfoSec community (with some variations), but is also used with wild abandon by those outside that community.

“Penetration test” is often used interchangeably with terms such as “ethical hack”, “risk assessment” or “vulnerability assessment”. It’s also sometimes used to describe automated scanning of a system using various tools. Those familiar with InfoSec generally either get annoyed or give up on terms like this, but I’ll try to clarify things a bit.

First, a penetration test is an assessment of the security of a specific system or application, rather than an ongoing process. For example, an organization might conduct an annual penetration test on a given application as part of its compliance program.

In contrast, ethical hacking is an ongoing practice within an organization, of which penetration testing may be a part. Similarly, a penetration test is usually a part of a vulnerability or risk assessment, in concert with multiple other processes. Depending on the size of an organization, multiple penetration tests might be conducted as part of a larger vulnerability or risk assessment.

For completeness, I’ll note that “physical penetration tests” (which generally focus on gaining physical access to a facility) are sometimes done in concert with “traditional” penetration tests. One scenario would be for a tester to gain access to a facility, then use that access to facilitate external access to the network. (eg, by plugging something directly into an unsecured network port)

But what is a penetration test, really?

First off, it’s very important to note the terms “authorized” and “simulated” in the definition above. A penetration test is NOT where someone decides to try and access a system when they choose, or blindly runs something without an understanding of the potential impact.

As a fascinating side-note on the idea of “authorized” action, the US Justice Department recently authorized the FBI to “copy and remove malicious web shells from hundreds of vulnerable computers in the United States” (https://www.justice.gov/usao-sdtx/pr/justice-department-announces-court-authorized-effort-disrupt-exploitation-microsoft). These web shells were left in January and February of 2021, by attackers exploiting vulnerabilities in Microsoft Exchange Server, and the FBI taking direct action of this sort seems to be a notable departure from past actions.

A penetration test is usually conducted as part of a larger vulnerability assessment or security audit, and aside from being authorized, it needs to be well-defined and planned, to ensure that there is no unanticipated impact or confusion.

This is an important point, as many people have an image of a “white hat” hacker learning of a potential issue and deciding to access a system in order to confirm or fix it. That’s not how it works.

It’s vitally important to ensure that the scope of a test is well-understood, that all parties are clear on what will (or will not) be done in the course of the test, and how the results will be documented. In some organizations, these details may be handled by parties other than the actual tester, but it’s vital for the tester to have a clearly-documented scope.

It’s hard to overestimate the importance of this point – consider a vaguely-worded requirement to test “all domains owned/managed by the company”. Then consider that the company owns a domain which is pointing at a cloud-based service that is NOT owned by the company. Conducting an unauthorized penetration test against a third party is not only likely (almost certainly) to be a breach of contract with the cloud-based service, but is illegal in most countries. Not a good thing!

Clearly defining the scope of a test is also important since systems can be attacked in many ways, ranging from obtaining unauthorized access through obtaining or guessing a password, to disabling access to the system, all the way to destroying data or components of the system. While a malicious party can and will do all of this, the penetration tester must be far more careful not to cause more harm than good.

In general, penetration tests will include guidelines such as limiting attacks to a specific (sub)system, avoiding attacks which could cause a server or service to fail, or not using tools with a high risk of damage to the system. This makes things somewhat harder for the penetration tester, but in many cases it is possible to demonstrate the viability of an attack without actually conducting it, so it’s mostly about being careful (and legal).

One part of identifying the scope is to determine the level of initial information provided to the tester. This is where we hear terms like “whitebox” (where the tester is provided background information on the system ahead of time), “blackbox” (where no such information is provided), and “greybox” (where some degree of information is provided). This is mainly about providing a starting point for the testing, and has an impact on the type of testing which will be used.

Now, when we get to the actual test, it’s generally broken into phases. Many organizations break down the steps differently, but here is an example breakdown:

• Planning / Reconnaissance
  

  • This is where you would plan out the test and learn as much about the system as you can beforehand. You can gather a lot of information via “OSINT” (https://en.wikipedia.org/wiki/Open-source_intelligence) before you even look at a system...

• Scanning
  

  • There is a vast array of scanning tools out there, ranging from simple online tools anyone can use, to custom tools developed for testing of specific vulnerabilities or specific systems

  • It should be noted that some refer to the scans they provide as “vulnerability assessments”. I disagree with this usage, and consider these scans to be tools used in a penetration test, or tools used to provide information for a vulnerability assessment

• Gaining Access
  

  • Once a potential vulnerability is identified, it needs to be confirmed. Some tools provide ways to automate part of this, but humans are the ultimate arbiter. It will be interesting to see how this process evolves over time, but I don’t think of it as a “real” penetration test if it’s fully automated

• Maintaining Access
  

  • Once you get in, there are different ways to stay in. The Microsoft Exchange vulnerability referred to earlier is an interesting example of this. The vulnerability was bad enough, but the bigger threat is what was done once an actor got in. Many actors install other tools once they get inside, in order to will retain access even after the original vulnerability is patched.

• Analysis / Reporting
  

  • Once a test is completed, it’s necessary to document the results so that issues can listed, assessed, prioritized, and then addressed. Generally, the penetration tester will list the issues identified, and others will review and discuss the impact and actions to be taken

Penetration testing is a very powerful tool for testing the security of a system, but it can be very time-consuming and expensive. In addition, the level of automation of various actions is increasing rapidly, so it may be that the term will start being used for processes which are fully automated. Whether (or when) that happens, and what the impact might be, all remains to be seen, but it seems clear that humans will still be running the show for the foreseeable future.

Cheers!