This chapter covers vulnerability identification, the process of discovering and categorizing weaknesses in target systems and networks. As a core component of Domain 2 (Recon Enumeration) and Objective 2.3, this topic appears in roughly 15–20% of PT0-002 exam questions. You will learn how to plan, execute, and analyze vulnerability scans, interpret findings, and avoid common pitfalls that lead to false positives or missed vulnerabilities. Mastery of this chapter is essential for both the exam and real-world penetration testing.
Jump to a section
A vulnerability scanner is like a master locksmith hired to assess a building's security. The locksmith walks through every door, window, and vault, trying each lock with a standard set of picks and bypass tools. He doesn't break in; he simply tests if the lock yields. For each lock, he records: the lock type (e.g., deadbolt, padlock, electronic), its manufacturer, model, and whether it resisted or opened. He also notes any unusual features like a hidden keypad or a broken latch. After the walkthrough, he compiles a report listing every weak lock, its location, and recommendations (e.g., 'replace with Grade 1 deadbolt'). The building owner uses this report to prioritize fixes—fix the broken back door before upgrading the front lobby lock. The locksmith's tools are like the scanner's plugin database: each pick is designed for a specific lock family (e.g., CISA, Schlage). If a lock is brand-new and no pick exists, it won't be tested—a 'zero-day' lock. The locksmith's speed matters: a quick test might miss a subtle defect, while a thorough test takes time but catches more. This mirrors how a scanner sends probes and analyzes responses to identify vulnerabilities without exploitation.
What is Vulnerability Identification and Why Does It Exist?
Vulnerability identification is the systematic process of discovering, classifying, and prioritizing security weaknesses in an organization's IT environment. In the context of PT0-002, this falls under Domain 2 (Recon Enumeration) and specifically Objective 2.3: 'Given a scenario, perform vulnerability identification.' The purpose is to move beyond simple asset discovery and port enumeration to actively probe for known vulnerabilities. This step bridges reconnaissance and exploitation—it tells a pen tester which weaknesses are present and which can be exploited to achieve the engagement objectives. Without proper vulnerability identification, a tester might waste time trying to exploit non-existent vulnerabilities or, worse, miss critical ones that could lead to a breach.
How Vulnerability Identification Works Internally
Vulnerability identification typically uses automated scanners (e.g., Nessus, OpenVAS, Qualys) that follow a multi-phase process:
Discovery Phase: The scanner identifies live hosts, open ports, and running services. This uses techniques like ICMP ping sweeps, TCP SYN scans, and UDP probes. The scanner builds a list of targets and their network fingerprints.
Service Enumeration: For each open port, the scanner performs banner grabbing and service fingerprinting. It may send specially crafted packets to elicit responses that reveal the service name, version, and sometimes configuration details. For example, an HTTP server might return a 'Server: Apache/2.4.41 (Unix)' header. The scanner stores this information in a structured database.
Vulnerability Detection: The scanner compares the enumerated service information against a database of known vulnerabilities (e.g., CVE, Bugtraq, OSVDB). Each vulnerability check is a plugin or script that tests for a specific condition. For instance, plugin 12345 might check if the SSH version is less than 7.4, which is vulnerable to CVE-2016-6210. The plugin sends a probe (e.g., a malformed SSH handshake) and analyzes the response to determine if the vulnerability exists.
Result Analysis: The scanner reports findings with severity levels (Critical, High, Medium, Low, Info) based on CVSS scores (Common Vulnerability Scoring System, version 3.1). A critical vulnerability might have a CVSS score of 9.0–10.0, while informational findings are non-exploitable but useful for hardening. Each finding includes a description, affected systems, remediation steps, and references.
Key Components, Values, Defaults, and Timers
CVSS v3.1 Base Score Categories:
- Critical: 9.0–10.0 - High: 7.0–8.9 - Medium: 4.0–6.9 - Low: 0.1–3.9 - None: 0.0 - Default Scan Ports: Most scanners scan the top 1,000 or 10,000 TCP ports by default. For example, Nmap's default scan covers 1,000 ports. Full port scans (65,535 ports) are slower but more thorough. - Rate Limiting: Scanners can adjust packet send rate to avoid overwhelming targets or triggering IDS/IPS. Default rates vary: Nessus might default to 5 packets/second per host, while Nmap uses a timing template (T1–T5) with T3 as default. - Plugin Database Update Frequency: Scanners update their vulnerability databases periodically. Nessus updates plugins daily; OpenVAS updates the NVTs (Network Vulnerability Tests) via a scheduled feed sync (default every 24 hours). - Scan Timeout: Individual service probes often have a timeout of 5–10 seconds. If no response is received within that window, the probe is considered unanswered.
Configuration and Verification Commands
While the exam does not require memorizing specific scanner commands, you should be familiar with typical usage:
Nmap (for discovery and enumeration):
nmap -sV -p 1-1000 192.168.1.0/24-sV: Enables version detection.
-p: Specifies port range.
Nessus CLI (if using Nessus Professional):
./nessuscli scan new --name "Internal Scan" --policy "Basic Network Scan" --targets 192.168.1.0/24
./nessuscli scan run <scan_id>OpenVAS (gvm-cli):
gvm-cli --gmp-username admin --gmp-password pass socket --socketpath /var/run/gvmd.sock --xml "<create_task><name>Quick Scan</name><target><hosts>192.168.1.0/24</hosts></target><config><id>daba56c8-73ec-11df-a475-002264764cea</id></config></create_task>"Verification of results is done through the scanner's report interface, which can be exported in PDF, HTML, or CSV formats.
Interaction with Related Technologies
Firewalls and IDS/IPS: Scanners must account for filtering. A SYN scan might be blocked, leading to false negatives. Conversely, aggressive scanning can trigger IPS alerts, causing the scanner's IP to be blocked. The pen tester should coordinate with the client to whitelist the scanning host.
Authentication: For authenticated scans (e.g., Windows domain credentials), the scanner uses provided credentials to log in and enumerate local vulnerabilities (e.g., missing patches, weak local passwords). This yields more accurate results than unauthenticated scans.
Cloud Environments: Scanners must be deployed within the cloud VPC or use cloud-native tools (e.g., AWS Inspector). Cloud security groups and network ACLs can block scanning traffic if not properly configured.
Step-by-Step Process of a Typical Vulnerability Scan
Define Scope: Determine which IP ranges, subnets, or domains to scan. Obtain written authorization. Set scan intensity (e.g., 'discovery only' vs 'full vulnerability scan').
Select Scan Type: Choose between unauthenticated (external) or authenticated (internal with credentials). Each has different coverage. Authenticated scans can check registry settings, patch levels, and local user permissions.
Configure Scanner: Set target hosts, select scan policy (e.g., 'Basic Network Scan', 'Web Application Scan'), adjust performance options (max hosts per scan, network timeout). For example, Nessus's 'Basic Network Scan' policy runs all plugins except those marked as dangerous.
Execute Scan: Launch the scan. Monitor for errors (e.g., host unreachable, authentication failure). The scan may take minutes to hours depending on network size and scan intensity.
Analyze Results: Review the report. Filter by severity. Validate critical findings: some may be false positives due to service fingerprinting errors. For instance, an outdated Apache banner might be a honeypot or a misconfigured service.
Remediation and Reporting: Provide a prioritized list of vulnerabilities to fix. The client will patch systems, update configurations, or apply workarounds. A re-scan confirms fixes.
Common Pitfalls and How to Avoid Them
False Positives: Scanners often misidentify services. For example, a server running a custom web server on port 80 might be incorrectly flagged as Apache. Validate banners manually using tools like curl -I or telnet.
False Negatives: An unpatched system might not be detected if the scanner lacks the latest plugin. Always update the plugin database before scanning. Also, some vulnerabilities require multiple conditions (e.g., a specific configuration) that the scanner cannot test without authentication.
Scanning Impact: Aggressive scanning can crash vulnerable services or trigger rate limiting. Use conservative timing (e.g., Nmap T2 or T3) for production environments.
Credential Issues: Incorrect credentials lead to failed authenticated scans. Verify credentials before the scan and ensure they have sufficient privileges (e.g., local admin on Windows).
Case Study: Real-World Scenario
A pen tester is hired to assess a corporate network of 500 hosts. The tester uses Nessus with an authenticated scan policy against Windows servers. The scan discovers a critical vulnerability: MS17-010 (EternalBlue) on a legacy file server. The report shows that the server is missing the security update from March 2017. The tester validates by connecting to the server and checking the registry: Get-HotFix -Id KB4012212 returns nothing. The client is advised to patch immediately. This finding alone justifies the scan cost.
Define Scan Scope
Determine the exact IP addresses, subnets, or hostnames to scan. This includes obtaining written authorization from the client. The scope should be clearly defined in the Rules of Engagement (RoE). For example, scanning 10.0.0.0/24 but excluding 10.0.0.5 due to sensitivity. The pen tester must also decide scan intensity: 'discovery only' (just find hosts and ports) versus 'full vulnerability scan' (probe for vulnerabilities). The scope impacts scan duration and network load.
Select Scan Type and Policy
Choose between unauthenticated (external) or authenticated (internal) scans. Authenticated scans require valid credentials (e.g., domain admin on Windows). The scan policy defines which plugins run, port ranges, and performance settings. For example, Nessus's 'Web Application Tests' policy focuses on HTTP/HTTPS vulnerabilities. The policy also sets severity thresholds for reporting. A misconfigured policy might exclude critical checks.
Configure Scanner Settings
Set target hosts, scan policy, and performance options. Key settings include max hosts per scan (default 30), max concurrent checks per host (default 5), and network timeout (default 5 seconds). For authenticated scans, provide credentials (username, password, domain). Also set email alerts for scan completion. Ensure the scanner's plugin database is updated to the latest version to detect recent vulnerabilities.
Execute the Scan
Launch the scan and monitor its progress. The scanner first performs host discovery (ICMP ping, TCP SYN to common ports). Then it enumerates open ports and services. Finally, it runs vulnerability plugins against each service. The scan can be paused or cancelled if it causes network issues. Logs show which hosts are unreachable or have authentication failures. Typical scan duration: 1–4 hours for a Class C subnet with full vulnerability checks.
Analyze and Validate Results
After the scan completes, review the report. Filter by severity (Critical, High, etc.). Investigate each critical finding to confirm it is not a false positive. For example, if the scanner reports 'Apache 2.2.8 mod_ssl vulnerability', manually check the server banner with `curl -I https://target` to verify version. Also check if the vulnerability is actually exploitable given the current configuration. Prioritize findings based on CVSS score and business impact.
Enterprise Scenario 1: External Perimeter Scan for a Financial Institution
A bank engages a pen tester to perform an external vulnerability scan of its internet-facing infrastructure. The scope includes 10 public IPs hosting web servers, mail servers, and VPN gateways. The tester uses an unauthenticated scan with a Nessus policy that includes all plugins but excludes denial-of-service tests to avoid disrupting production. The scan reveals a critical vulnerability: CVE-2021-44228 (Log4Shell) on the web server. The tester validates by running a crafted payload that triggers a DNS callback. The bank immediately patches Log4j and implements a WAF rule. This scenario highlights the importance of scanning external assets regularly, as they are the first line of defense. Performance considerations: the tester limits the scan to 10 packets/second to avoid triggering the bank's IDS. The scan completes in 30 minutes. A common mistake is to scan only the web server's IP but miss the load balancer's IP, which might have a different patch level.
Enterprise Scenario 2: Internal Authenticated Scan for a Healthcare Provider
A hospital network of 2,000 endpoints needs a vulnerability assessment. The tester uses an authenticated scan with domain admin credentials. The scanner logs into each Windows host and checks for missing patches, weak local admin passwords, and insecure registry settings. The scan discovers that 30% of workstations are missing the MS17-010 patch (EternalBlue). The tester validates by checking the registry on a sample of machines. The hospital prioritizes patching these machines within 48 hours. A challenge in this scenario is credential rotation: the scanner's credentials might expire during the scan if the scan takes longer than the password change interval. The tester should use service accounts with non-expiring passwords or coordinate with IT. Another issue is scan performance: scanning 2,000 hosts with authenticated checks can take 8–12 hours. The tester schedules the scan during off-peak hours to minimize impact.
Enterprise Scenario 3: Cloud Environment Scan for a SaaS Company
A SaaS company uses AWS with a mix of EC2 instances, RDS databases, and S3 buckets. The pen tester uses AWS Inspector for vulnerability scanning within the VPC. The scope includes all instances in the production VPC (approx. 50 instances). The tester configures Inspector to run a network assessment (checks for open ports and software vulnerabilities) and a host assessment (requires AWS Systems Manager Agent). The scan reveals that an EC2 instance running an old Amazon Linux AMI has multiple critical CVEs. The tester validates by connecting via SSH and checking the package versions. The company updates the AMI and redeploys. A key consideration in cloud scanning is that security groups can block the scanner's traffic. The tester must ensure the scanner's IP is whitelisted in the security group. Also, cloud costs: scanning instances generate network traffic and CPU usage, which can increase AWS bills if not monitored. Common misconfiguration: scanning only the public IPs but missing internal IPs used for inter-instance communication.
What PT0-002 Tests on Vulnerability Identification
Objective 2.3 explicitly states: 'Given a scenario, perform vulnerability identification.' The exam expects you to know the process, tools, and analysis of vulnerability scans. Specific sub-objectives include: - 2.3.1: Identify the appropriate scanning methodology (e.g., authenticated vs. unauthenticated, full vs. partial). - 2.3.2: Use appropriate tools (e.g., Nessus, OpenVAS, Qualys, Nmap scripts). - 2.3.3: Analyze scan results to prioritize vulnerabilities. - 2.3.4: Mitigate false positives and validate findings.
Common Wrong Answers and Why Candidates Choose Them
'Always use an unauthenticated scan because it simulates an external attacker.' This is wrong because authenticated scans provide deeper visibility into local vulnerabilities. The correct approach is to use both: unauthenticated for external perspective, authenticated for internal depth.
'The highest severity vulnerability should always be fixed first.' While severity matters, business context (e.g., a medium vulnerability on a critical server may be more urgent than a critical vulnerability on an isolated test system). The exam tests that you consider asset criticality and exploitability.
'A vulnerability scan is complete after the scan finishes.' No, you must validate findings and address false positives. The exam emphasizes validation as a key step.
'Nmap is a vulnerability scanner.' Nmap is a port scanner and enumeration tool; it can run NSE scripts for some vulnerability checks, but it is not a full vulnerability scanner like Nessus. The exam distinguishes between discovery and vulnerability identification.
Specific Numbers, Values, and Terms on the Exam
CVSS v3.1 Score ranges: Critical 9.0–10.0, High 7.0–8.9, Medium 4.0–6.9, Low 0.1–3.9.
Common port scanning defaults: Nmap's default scan covers 1,000 ports; full scan covers 65,535 ports.
Plugin update frequency: Nessus updates plugins daily; OpenVAS updates NVTs every 24 hours.
Scan timeouts: Typical timeout for a service probe is 5 seconds.
Terms: 'Plugin', 'NVT', 'CVSS', 'Authenticated scan', 'False positive', 'False negative'.
Edge Cases and Exceptions the Exam Loves to Test
Scanning through a firewall: A scanner behind a firewall might not see hosts that are NAT'd. The exam may ask how to handle this (use a scanner inside the network or configure firewall rules).
Zero-day vulnerabilities: Scanners cannot detect zero-days because no plugin exists. The exam tests that you understand this limitation.
Rate limiting: If a scanner sends packets too fast, it may be blocked by IPS. The exam asks about appropriate timing (e.g., Nmap T2 for stealth).
Credential expiration: Authenticated scans fail if credentials expire mid-scan. The exam expects you to verify credentials before the scan.
How to Eliminate Wrong Answers Using the Underlying Mechanism
When faced with a question about vulnerability identification, think about the mechanism:
- If a question asks about the best scan type for a specific scenario, consider what the scanner can see with vs. without credentials. For example, to check local patch levels, you need authenticated access. - If a question asks about why a vulnerability was not detected, consider plugin coverage, firewall rules, or service fingerprinting errors. - For false positive questions, recall that banner grabbing can be spoofed; always validate with manual techniques. By understanding the inner workings of scanners, you can deduce the correct answer even if you haven't memorized every tool command.
Vulnerability identification is a systematic process that includes discovery, enumeration, detection, and analysis.
CVSS v3.1 scores categorize vulnerabilities: Critical (9.0-10.0), High (7.0-8.9), Medium (4.0-6.9), Low (0.1-3.9), None (0.0).
Authenticated scans provide deeper visibility than unauthenticated scans and are preferred for internal assessments.
Scanners cannot detect zero-day vulnerabilities—only those with existing plugins.
Always validate critical findings manually to avoid false positives in reports.
Update scanner plugin databases before each scan to ensure coverage of recent vulnerabilities.
Scan timing and rate limiting are crucial to avoid triggering IDS/IPS or overwhelming target hosts.
The exam tests the difference between port scanning (discovery) and vulnerability scanning (detection).
False positives are common; always verify by checking service banners or using alternative tools.
Risk prioritization should consider both CVSS score and business context (asset criticality, exploitability).
These come up on the exam all the time. Here's how to tell them apart.
Unauthenticated Scan
Does not require credentials; simulates an external attacker.
Only checks network-facing services and open ports.
Cannot assess local patch levels, registry settings, or local user permissions.
Faster to run, as it does not need to log into each host.
Produces more false negatives for internal vulnerabilities.
Authenticated Scan
Requires valid credentials (e.g., domain admin on Windows).
Can check local system state, including installed patches, registry, and file permissions.
Provides deeper visibility into vulnerabilities that are not network-accessible (e.g., missing patches).
Slower because it logs into each host and runs local checks.
Produces more accurate results for internal vulnerabilities, but requires careful credential management.
Mistake
A vulnerability scanner can detect all known vulnerabilities.
Correct
Scanners can only detect vulnerabilities for which they have a plugin. They cannot detect zero-day vulnerabilities or vulnerabilities that require complex multi-step interactions. Additionally, false negatives occur if the service version is misidentified or if the vulnerability depends on a specific configuration that the scanner cannot verify.
Mistake
An unauthenticated scan is sufficient for internal assessments.
Correct
Unauthenticated scans only see network-facing vulnerabilities. They cannot assess local patch levels, registry settings, or weak local passwords. Authenticated scans provide a more complete picture. For internal assessments, always use authenticated scans when possible.
Mistake
If a scanner reports a vulnerability with a CVSS score of 10.0, it must be fixed immediately.
Correct
CVSS score indicates severity of the vulnerability itself, but not the risk to the organization. A critical vulnerability on a non-essential system may be less urgent than a medium vulnerability on a critical system. Risk assessment should consider asset value, exploitability, and existing controls.
Mistake
Port scanning and vulnerability scanning are the same thing.
Correct
Port scanning (e.g., Nmap) identifies open ports and services. Vulnerability scanning goes further by probing for known weaknesses in those services. Port scanning is a subset of vulnerability identification, but they are distinct phases.
Mistake
Once a scan is complete, the results are final and do not need validation.
Correct
Scanners produce false positives and false negatives. Each critical finding should be manually validated. For example, a scanner might flag a service as vulnerable based on its banner, but the actual service might be patched behind a reverse proxy. Validation ensures accuracy before reporting.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A vulnerability scan is an automated process that identifies known vulnerabilities by comparing system information against a database. It produces a list of potential weaknesses. A penetration test goes further by attempting to exploit vulnerabilities to determine if they are actually exploitable. The exam distinguishes between the two: scanning identifies vulnerabilities; penetration testing validates exploitability. In PT0-002, vulnerability identification is part of the reconnaissance phase, while exploitation is a separate domain.
There is no one-size-fits-all answer, but industry best practices recommend scanning at least quarterly, and after any significant network change. For high-security environments, monthly or even weekly scans may be appropriate. The exam expects you to understand that scanning frequency depends on risk appetite and regulatory requirements (e.g., PCI DSS requires quarterly external scans and after any network change).
A false positive occurs when a scanner reports a vulnerability that does not actually exist. This can happen due to banner spoofing, misidentified services, or outdated plugin logic. For example, a server might return an Apache banner but actually run Nginx behind a reverse proxy. The scanner might flag an Apache vulnerability that does not apply. To reduce false positives, validate findings manually using tools like `curl`, `openssl s_client`, or by checking the system directly.
CVSS (Common Vulnerability Scoring System) provides a standardized score (0–10) for vulnerability severity. It considers factors like attack vector, complexity, privileges required, user interaction, and impact. The base score is used to prioritize vulnerabilities. In PT0-002, you need to know the score ranges and that CVSS v3.1 is the current version. However, the exam also emphasizes that CVSS score alone should not dictate priority; business context matters.
Yes, many scanners include plugins for configuration auditing. For example, Nessus has policies for CIS benchmarks that check for weak passwords, unnecessary services, and insecure registry settings. Authenticated scans are required for deep configuration checks. The exam may ask about scanning for compliance with standards like PCI DSS or HIPAA.
Immediately stop the scan and inform the client. Some vulnerability checks (e.g., denial-of-service tests) can crash unstable services. Always use non-intrusive policies for production environments. If a crash occurs, document the incident and review the scan settings to avoid recurrence. The exam stresses the importance of obtaining written authorization and using safe scanning practices.
When scanning through a NAT device, the scanner sees only the public IP addresses. To scan internal hosts, you need to either place a scanner inside the network or use agent-based scanning. In PT0-002, you might be asked to identify challenges with NAT and propose solutions like deploying a scanner in the internal network or using VPN access.
You've just covered Vulnerability Identification — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?