3.2 Vulnerability Impact Assessment & Prioritization

The Necessity of Impact Assessment and Prioritization

Vulnerability scanning and service enumeration often produce dozens or hundreds of potential security findings across an enterprise network. For a penetration tester operating under strict time constraints, attempting to exploit every identified vulnerability in arbitrary order is inefficient, noisy, and hazardous to system stability.

To achieve testing objectives—such as demonstrating unauthorized access to sensitive data or compromising target systems—testers must systematically assess the potential impact of each vulnerability and prioritize attack vectors. This prioritization balances exploitability (how easily and reliably the flaw can be triggered) against impact (the operational leverage gained upon successful exploitation).

Common Vulnerability Scoring System (CVSS v3.1) Fundamentals

The Common Vulnerability Scoring System (CVSS), maintained by the Forum of Incident Response and Security Teams (FIRST), is the vendor-agnostic industry standard for quantifying vulnerability severity. While defensive teams use CVSS to schedule software patching cycles, penetration testers use its metric breakdowns to evaluate attack viability.

CVSS v3.1 organizes vulnerability characteristics into three primary metric groups:

1. Base Metric Group: Represents the intrinsic qualities of a vulnerability that are constant over time and across user environments.
2. Temporal Metric Group: Reflects characteristics that evolve over the vulnerability's lifecycle, such as exploit code maturity and patch availability.
3. Environmental Metric Group: Customizes scores based on the specific organizational implementation, mitigating controls, and target asset value.

The Base Metric Group: Exploitability and Impact

The CVSS Base Score ranges from 0.0 to 10.0 and is calculated from two sub-scores: Exploitability and Impact.

1. Exploitability Metrics

These metrics reflect the technical ease with which an attacker can execute the vulnerability:

• Attack Vector (AV): Defines the contextual barrier between the attacker and the vulnerable target:

  • Network (N): Remotely exploitable across layer 3 boundaries without physical or local network access. This is the primary vector for external penetration testers.
  • Adjacent (A): Requires physical or logical adjacency, such as sharing the same local broadcast domain, IP subnet, or wireless network.
  • Local (L): Requires prior access to the host (e.g., an existing shell) or user interaction to run a malicious executable locally. This characterizes local privilege escalation vulnerabilities.
  • Physical (P): Requires physical access to the target hardware or peripheral interface (e.g., Cold Boot attacks, FireWire DMA).

• Attack Complexity (AC): Measures conditions beyond the attacker's immediate control:

  • Low (L): The attack is repeatable and deterministic; no specialized configurations, race conditions, or specific memory states are required.
  • High (H): Successful exploitation relies on circumstances outside the attacker's direct control, such as winning a race condition, bypassing complex operating system protections, or gathering specialized reconnaissance data.

• Privileges Required (PR): Assesses the level of authorization an attacker must possess prior to exploitation:

  • None (N): Unauthenticated exploitation; anyone with network access can trigger the vulnerability.
  • Low (L): Requires standard unprivileged user credentials or basic interactive shell privileges.
  • High (H): Requires administrative, root, or domain administrative privileges.

• User Interaction (UI): Identifies whether human intervention is necessary:

  • None (N): The vulnerability can be exploited autonomously without user participation.
  • Required (R): A legitimate user must take an action, such as clicking a malicious link, opening an infected file attachment, or logging into an active session (common in Reflected XSS and CSRF).

2. Scope Metric

• Scope (S): Evaluates whether an exploited vulnerability can impact resources managed by a different security authority:
  • Unchanged (U): The compromised component affects only its own security domain.
  • Changed (C): The attacker breaches an authorization boundary to impact external components (e.g., a virtual machine escape compromising the hypervisor, or Cross-Site Scripting compromising a user's browser execution environment).

3. Impact Metrics

The impact sub-score measures the degree of loss across the classic CIA triad:

• Confidentiality Impact (C): High (H), Low (L), or None (N). Evaluates unauthorized disclosure of restricted data.
• Integrity Impact (I): High (H), Low (L), or None (N). Evaluates unauthorized modification or destruction of system data.
• Availability Impact (A): High (H), Low (L), or None (N). Evaluates disruption or termination of services, resources, or network connectivity.

The CVSS Vector String

A CVSS rating is represented compactly by an official vector string. For example, the vector string for EternalBlue (MS17-010 / CVE-2017-0144) is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

This vector indicates an unauthenticated (PR:N), network-accessible (AV:N), low-complexity (AC:L), zero-user-interaction (UI:N) flaw that results in total loss of confidentiality, integrity, and availability (C:H/I:H/A:H), yielding a maximum Critical base score of 9.8.

Vulnerability Categorization for Penetration Testing

Offensive operators classify vulnerabilities according to operational utility rather than purely theoretical severity scores. In practical testing scenarios, findings fall into four primary categories:

1. Remote Code Execution (RCE) and Command Injection

• Operational Utility: Priority 1 (Initial Foothold).
• Technical Mechanism: RCE flaws allow attackers to execute arbitrary machine instructions, shellcode, or operating system commands on the remote target host. This typically occurs through memory corruption (stack/heap buffer overflows), unsafe deserialization of untrusted objects, or direct shell command concatenation (command injection).
• Objective: Establishing an interactive reverse or bind shell on the target system with the execution privileges of the listening daemon (e.g., www-data, nobody, or SYSTEM).

2. Authentication Bypass and Default Credentials

• Operational Utility: Priority 1 (Clean Access).
• Technical Mechanism: Bypassing security boundaries via improper session validation, SQL injection in login parameters (admin' OR '1'='1), logic flaws, or exploiting factory-default credentials (admin:admin, root:toor, cisco:cisco).
• Objective: Obtaining immediate administrative control without memory corruption risks. Because authentication exploits use standard protocol mechanisms, they produce no application crashes and generate minimal forensic artifacts.

3. Information Disclosure

• Operational Utility: Priority 2 (Intelligence Gathering and Attack Chaining).
• Technical Mechanism: Exposure of internal configurations, source code files, database connection strings, password hashes, or private IP address spaces. Examples include directory traversal (../../../../etc/shadow), exposed .git directories, and unauthenticated status endpoints (/server-status).
• Objective: Harvesting credentials and architectural data to construct secondary attack paths. An information disclosure flaw on its own does not provide a shell, but leaking an administrator password or database hash frequently leads directly to full compromise.

4. Denial of Service (DoS)

• Operational Utility: Strictly Prohibited in Standard Engagements.
• Technical Mechanism: Forcing target daemons or operating systems into unrecoverable crash states (e.g., kernel panic, Blue Screen of Death, socket exhaustion, CPU resource starvation).
• Ethical and Practical Mandate: In commercial penetration tests and practical certification exams, executing DoS exploits is strictly forbidden unless explicitly requested in writing within the Rules of Engagement (RoE). Crashing a target host destroys client business operations, disrupts network infrastructure, and halts the penetration testing assessment. Furthermore, in practical exams, crashing a target machine freezes your lab environment and may require resetting the lab, erasing active shells and unrecorded flags.

Triage and Prioritization Workflow

When presenting multiple potential vulnerabilities, a penetration tester applies a structured triage process to determine the optimal exploitation path:

Discovery & Enumeration Data
             |
             v
Are there Default / Weak Credentials? ----> YES ----> Log in & Inspect (Cleanest Path)
             | NO
             v
Is there Unauthenticated Web / Logic RCE? -> YES ---> Execute Web Shell / Command Injection
             | NO
             v
Is there a High-Reliability Remote Exploit? -> YES -> Verify Architecture & Deploy Payload
             | NO
             v
Are there Information Leaks / Files? -----> YES ----> Harvest Hashes / Passwords & Pivot
             | NO
             v
Do only Unstable Memory / DoS Flaws Exist? -> Document finding; DO NOT deploy in exam/prod

Exploit Reliability and Target Stability

Before running any exploit against a live host, evaluate the stability and reliability of the code:

1. Metasploit Module Rankings: When selecting modules in Metasploit (msfconsole), review the Rank column:
   • Excellent: The exploit will never crash the service; it uses command execution, clean memory logic, or auto-detects targets reliably.
   • Great: The exploit has an auto-detection routine and safely handles memory manipulation.
   • Good: The exploit works against specific software versions but lacks universal auto-detection.
   • Manual / Low / Average: The exploit relies on hardcoded memory addresses or unstable return pointers and carries a significant risk of crashing the daemon.
2. Exploit-DB Verification: In Searchsploit results, prioritize exploits marked with an [EDB Verified] badge. These proofs of concept have been replicated and confirmed by security researchers in controlled environments.
3. Architecture and Patch Matching: Verify the precise CPU architecture (x86 vs. x64) and operating system build before deploying binary exploits. Attempting to execute an x86 payload against an x64 Windows kernel service can trigger an immediate system crash (IRQL_NOT_LESS_OR_EQUAL BSOD).

The Principle of Least Invasiveness

A professional penetration testing engagement follows the Principle of Least Invasiveness. Always attempt the simplest, quietest, and least destructive vector before moving to complex or volatile techniques:

• Level 1 (Non-Invasive): Credential stuffing, default credential testing, exploiting authentication logic errors.
• Level 2 (Application Layer): Web application command injection, SQL injection, unrestricted file upload.
• Level 3 (Reliable Network Exploitation): Validated remote code execution modules against known vulnerable network daemons.
• Level 4 (High-Risk Binary Exploits): Low-level memory corruption or kernel exploitation (reserved only when all other avenues are exhausted and explicit client consent is verified).

CVSS v3.1 Severity Scale and Impact Criteria

The following table summarizes the CVSS v3.1 qualitative severity ratings, their technical characteristics, and their operational prioritization in offensive testing: