icon-carat-right menu search cmu-wordmark

A Repository of Common Penetration-Testing Weaknesses

Marisa Midler Samantha Chaves
and

Penetration testing is an important step in identifying weaknesses in an organization’s IT infrastructure. It is a crucial assessment activity for organizations to use when defending their environments against cyberattacks. The SEI conducts cybersecurity assessments for organizations and designs and develops applications that facilitate the collection and automation of the reporting of findings identified on assessments.

This post introduces a penetration-testing findings repository that is now publicly available on GitHub. Findings refer to the vulnerabilities and weaknesses identified during a penetration-testing assessment. The repository standardizes the language of findings and minimizes the time and effort for report writing. Moreover, the standardized finding-name format assists in analyzing aggregated data across multiple penetration-testing assessments.

This repository was created in response to the naming inconsistency of findings on penetration-testing assessments and to create a large collection of standardized weaknesses for assessors to use. Assessors would name findings differently on assessments. Some assessors would name a finding after a cyberattack while others would name it after a process. The penetration-testing findings repository focuses on naming a finding after the vulnerability and weaknesses that were identified on an assessment rather than cyberattacks or processes. To help assessors locate findings more quickly during an assessment, the repository uses an affinity-grouping technique to categorize weaknesses, which increases usability by sorting the findings into a hierarchical three-tier structure. Moreover, the findings repository includes resources to help assessed organizations remediate the findings identified on a penetration-testing assessment.

A key step in securing organizational systems is identifying and understanding the specific vulnerabilities and weaknesses that exist in an organization’s network. Once identified, the vulnerabilities and weaknesses must be put into context and certain questions must be answered, as outlined in the blog post How to Get the Most Out of Penetration Testing:

  • Which vulnerabilities and weaknesses should you spend finite resources addressing?
  • Which vulnerabilities and weaknesses are easily exploitable, and which aren’t?
  • Which vulnerabilities and weaknesses put critical assets at risk?
  • Which vulnerabilities and weaknesses must be addressed first?

Without this context, an organization might dedicate resources to addressing the wrong vulnerabilities and weaknesses, leaving itself exposed elsewhere. The repository provides a default finding-severity level to help an assessed organization prioritize which findings to remediate first. An assessor can adjust the default severity level of the findings depending on the other security controls in place in an organization’s environment.

Repository Overview

The penetration-testing findings repository is a collection of Active Directory, phishing, mobile-technology, system, service, web-application, and wireless-technology weaknesses that may be discovered during a penetration test. The repository contains default names, descriptions, recommendations for remediation, references, mappings to various frameworks, and severity levels for each finding. This repository and its structure serve four primary purposes:

  • standardization—The repository standardizes the reporting process by providing defined findings for an assessor to select from during an assessment.
  • streamlined reporting—Providing pre-populated attributes (finding name, description, remediation, resources, and severity level) saves significant time during the reporting process, allowing assessors to focus on operations.
  • comprehensiveness—The repository’s layered structure gives assessors flexibility in how they present their findings as the vulnerability landscape evolves. When possible, assessors select a specific finding. If no specific finding accurately describes what was discovered, assessors can select a general finding and tailor it accordingly.
  • ease of navigation—To make the repository easier to navigate, it uses a tiered classification structure. Findings are grouped by the findings categories, allowing assessors to report on both general and specific findings when creating reports.

As mentioned above, the findings repository is a hierarchical structure containing the following three tiers:

  • Finding Category Tier—lists the overarching categories: Active Directory Weakness, Phishing Weakness, Mobile Technology Weakness, System or Service Weakness, Web Application Weakness, Wireless Technology Weakness.
  • General Finding Tier—lists 27 high-level findings that are like subcategories of the overarching Finding Category. General Findings can be used as an individual finding on an assessment when there isn’t a suitable Specific Finding.
  • Specific Finding Tier—lists 111 low-level findings that pinpoint a distinct weakness that can be exploited during an assessment. The specific findings consist of common findings frequently identified during assessments.

As shown in the table below, there are six Finding Categories:

Finding Categories
Category Description
Active Directory Weakness Active Directory (AD) is configured improperly. Some misconfigurations include unnecessary service accounts and permissions, insecure encryption ciphers, weak password policies, and/or insecure user or computer accounts. Attackers have various methods of pursuing AD weaknesses, including Kerberoasting, Golden Ticket attacks, Pass the Hash, or Pass the Ticket, which can lead to a total takeover of the infrastructure.
Phishing Weakness A phishing weakness allows an attacker to send a weaponized email through the network border that executes on the local host when a user performs an action. These emails can contain a variety of luring attachments, Uniform Resource Locators (URLs), scripts, and macros. Inadequate protections allow malicious payloads to be executed.
Mobile Technology Weakness Mobile technologies are increasingly used to deliver services and data. The amount of data stored on mobile devices makes their applications targets for attack. Compared to traditional computers, the functionality on mobile devices is more difficult to regulate, and mobile devices support more complex interfaces (e.g., cellular, Wi-Fi, Bluetooth, Global Positioning System [GPS]), that expose more surfaces to attack. Insecure mobile technology has vulnerabilities that attackers can exploit to gain access to sensitive information and resources.
System or Service Weakness Weaknesses within a system or service can result in missing critical security controls that leave the organization vulnerable to attacks. These weaknesses can include weak configuration guidance that insecurely configures systems and services throughout the organization, insufficient or missing configuration management that results in ad hoc or default configurations, etc.
Web Application Weakness The security of websites, web applications, and web services (e.g., application programming interfaces [APIs]) is referred to as web application security. Web applications can be attacked by exploiting vulnerabilities at the application layer, transport layer, and software supply chain. Web application weaknesses are typically vulnerabilities, system flaws, or misconfigurations in a web-based application. Attackers often exploit these weaknesses to either manipulate source code or gain unauthorized access to information or functions. Attackers may be able to find vulnerabilities even in a fairly robust security environment.
Wireless Technology Weakness Wireless technologies allow mobile devices (e.g., laptops, smart phones, Internet of Things [IoT] devices, and printers) to connect to the enterprise network. Wireless networks can introduce potential vulnerabilities to an organization through weak policies that allow insecure wireless technology (e.g., insecure devices, insecure configurations, weak authentication processes, insecure encryption) on the network.

The repository also maps each finding to the three following frameworks:

Future Work

The plan is to update the repository as new common vulnerabilities and weaknesses are identified. Since the repository is open source, however, the cybersecurity community can access the repository and add to it.

In addition to the Penetration Testing Findings Repository, a repository of common risks that can be identified during high-value asset (HVA) assessments is in the works. The purpose of this repository is to standardize the language among risks reported by assessors, in turn minimizing time and effort for report writing on assessments. Like the penetration-testing repository, this new repository will contain risk statements, descriptions, and recommendations for mitigation of risks identified on HVA assessments.

Additional Resources

How to Get the Most Our of Penetration Testing by Michael Cook

7 Guidelines for Being a Trusted Penetration Tester by Karen Miller

Get updates on our latest work.

Each week, our researchers write about the latest in software engineering, cybersecurity and artificial intelligence. Sign up to get the latest post sent to your inbox the day it's published.

Subscribe Get our RSS feed