Vulnerability Analysis

Vulnerability Scanning


In vulnerability analysis, adjudication is the process of evaluating and ranking vulnerabilities in terms of the potential threat they may pose to the organization. It also implies that some action can and will be taken to minimize this threat. Adjudication is useful because it is one of the most important factors that will influence how you prioritize your exploitation efforts, with the goal of maximizing the test’s efficiency.

Note: Do not confuse adjudication with mitigation.

Although you are certainly free to use your own system for scoring threat levels, it’s usually a good idea to rely on an industry standard like the Common Vulnerability Scoring System (CVSS) to do this for you. The CVSS is an open standard that defines how vulnerability data can be quantified while taking into account the degrees of risk to different types of systems or information. It does this by using three core metric groups (base, temporary, and environmental) to describe vulnerabilities in multiple ways. Scoring in CVSS (version 3) is numerical, and a range of numbers is also given a rating.


Score Range











The CVSS is leveraged by several industry-recognized vulnerability databases. The U.S. government’s National Vulnerability Database (NVD), which provides a list of vulnerabilities in the Common Vulnerabilities and Exposures (CVE) database, pairs each vulnerability with a CVSS score.

CVSS example of a SQL Injection

Vulnerability Prioritization

After you rank vulnerabilities by threat level, or consult a service like CVSS that does this for you, you’ll need to decide what vulnerabilities to dedicate your time and money on. After all, your deadline and limited budget will likely prevent you from testing every single vulnerability out there. By prioritizing vulnerabilities, you determine what vulnerabilities get the most attention when it comes to doing further research on how to exploit them. This ensures your time and money are being used effectively.

As mentioned earlier, the results of your adjudication will have a large influence on how you prioritize vulnerabilities. Vulnerabilities marked “critical” will be the most attractive targets, and may end up being the easiest to exploit and/or lead to the most significant outcomes. However, it’s not always as simple as sorting by rating and then proceeding from there. Sometimes, you’ll need to strike a balance between the likelihood of exploitation and the impact of that exploitation. The client organization’s unique environments will almost always inform how you go about doing this. For example, there might be a “critical” vulnerability that enables privilege escalation on a Windows domain controller, which can lead to severe consequences for the organization. However, the exploit might require certain factors that are very difficult to replicate in the organization’s environment. You might therefore demote this vulnerability based on your knowledge of the target. Likewise, you might promote a “high” or “medium” vulnerability that provides a better opportunity for exploitation, even if its impact is not as severe.

It’s important to keep in mind that threat ratings are not the only contributing factor to your prioritization efforts. You also need to consider the cost of mitigation. Even if the impact of a vulnerability isn’t particularly high, it might be very difficult or expensive for the organization to fix it. Consequently, there’s a higher likelihood that the organization will decide to accept the risk and forgo mitigation. This could prompt you to promote the vulnerability because there’s a chance it’ll be easier to exploit.

False Positives

Vulnerability scans have the potential to produce large amounts of false positives. There are numerous reasons that the scanner may trigger a false positive, including:

  • The scanner vendor may be trying to make their product look good by programming the scanner to report more vulnerabilities than there truly are.
  • The scanner is unable to recognize that another control is compensating for some identified deficiency.
  • The scanner is using a vulnerability database with outdated definitions.
  • The scanner incorrectly scores a vulnerability as more severe or easily exploited than it actually is.
  • Customizations in the target environment are inadvertently triggering the scanner to identify a vulnerability.
  • The scanner is not properly configured; e.g., it has been supplied with an incorrect target or credentials.

As a pen tester, you must be able to identify when results indicate a false lead on a vulnerability. Doing so will help you avoid wasting time chasing a lead that takes you to a dead end. There are several tactics you can employ to identify false positives; one of the most effective is results validation. Through a validation process, you compare what you’ve learned about the target environment to individual scan results and identify whether or not the results are truly applicable and accurate. For example, your scanner may indicate that a target Windows Server is susceptible to weaknesses in Server Message Block (SMBv1). However, a past service scan indicates that the SMB service running on the server is patched and running version 3, the latest. You might therefore conclude that the scanner is in error.

If you were playing the defensive blue team, you’d have an easier time identifying false positives because your understanding of the target environment would be complete. As a pen tester, there may be gaps in your knowledge, especially if you’re conducting a black box test. In this case, you’ll need to try your best with what you have and concede that you won’t necessarily be able to avoid false positives entirely. You may choose to conduct more reconnaissance on the target environment if you are intent on avoiding as many false positives as possible.

Common Themes

As you analyze vulnerability scan results and observe the target environment, you will encounter recurring conditions and/or common themes. These can be:

  • Lax physical security.
  • Employees not following corporate policy or best practices.
  • Lack of adequate cybersecurity training.
  • Lack of software patching and updating.
  • Lack of operating system hardening.
  • Poor software development practices.
  • Use of outdated networking protocols.
  • Use of obsolete cryptographic protocols.
  • And more.

By identifying common themes like these, you may stumble on a pattern of behavior. This pattern could extend to assets that you haven’t yet tested or hadn’t planned on testing. If you plan on testing them in the future, you can make certain educated guesses and assumptions that can make your job easier, or lead you down certain paths that you otherwise wouldn’t have taken. Ultimately, identifying common themes provides you with a more complete picture of your target environment and its weaknesses.

Vulnerability Mapping & Prioritization

Vulnerability mapping is the act of recognizing the connection between a vulnerability and its associated target. The target can be a person, process, device, technology, physical (non-computer) object, etc. Having this mapping gives you a reference for choosing attack techniques and exploits. A vulnerability map is more comprehensive than the results of a single scan. It is a tactical document that is informed by all of your vulnerability scans. It can also contain non-technical information such as phishing targets and points of weak physical security. You update it with newly discovered vulnerabilities, and use it to plan your attacks. The vulnerability map can be a separate document, or part of your larger tactical planning document.

Activity Priorities

When pen testing, you want to give priority to activities that are most likely to achieve the client’s requirements. Your day-to-day activities may have shifting priorities as investigations turn up promising leads or reach dead ends. Most pen tests are also time constrained, so you may have to shift priorities based on schedule and availability of targets or your own resources. When prioritizing activities, follow these best practices:

  • Project manage your pen test team resources to achieve client requirements within the given time constraints. Give early priority to activities that need extra time or are dependent on opportunity such as slow scans or social engineering.
  • Give priority to activities most likely to reveal new targets and attack vectors.
  • Consider strategically maximizing the timing of “quick wins” and compromising “low-hanging fruit” for political purposes, such as if the client needs to see successes during status briefings.

Guidelines for Analyzing Vulnerability Scan Results

When analyzing vulnerability scan results:

  • Determine an approach to categorizing client assets.
  • Categorize assets according to the approach you’ve chosen.
  • Identify the reasons why a scanner may produce false positives.
  • Conduct results validation by comparing results to what you know about the target environment.
  • Acknowledge that you may not be able to eliminate false positives entirely.
  • Rank vulnerabilities in terms of the potential threat they pose.
  • Consider using an established ranking system like the CVSS.
  • Determine vulnerability priorities to use your time and money as effectively as possible.
  • Use threat rankings to influence how you prioritize vulnerabilities.
  • Strike a balance between a vulnerability’s impact and its ease of exploitation.
  • Consider mitigation costs as an effect on your vulnerability prioritization.
  • Identify common themes in your vulnerability results and target observations.
  • Leverage a pattern of behavior on future testing efforts.
  • Use common themes to develop a more complete picture of the target environment.

Leave a Reply

Your email address will not be published. Required fields are marked *