Penetration Testing and Vulnerability Analysis (CY-702 (A)) - Unit 1 Short Notes

UNIT 1: Penetration Testing & Vulnerability Analysis

I. Foundations and Planning of Penetration Testing

Legal and Ethical Considerations

• Impact on Decision-Making:

  • Authorization: Formal, written consent (Get-Out-of-Jail-Free card) is mandatory. Unauthorized testing is illegal (Computer Fraud and Abuse Act, IT Act 2000).

  • Liability & Scope: Defines boundaries. Testing outside scope (e.g., DoS on production) can cause service disruption, leading to lawsuits.

  • Compliance: Regulations like PCI-DSS (mandates regular pen tests for card data) and GDPR (requires security testing for personal data) drive organizational decisions.

  • Ethics: Tester must act with integrity, avoid data destruction/exfiltration beyond proof-of-concept, and maintain confidentiality of findings.

• Rules of Engagement (ROE): Document detailing what, when, how, and what not to test. Includes testing windows, communication channels, and incident response contacts.

• > [!TIP] Exam Focus: Always link legal/ethical points to organizational risk (financial, reputational, regulatory).

Penetration Testing Types & Use Cases

Pre-engagement & Scoping

• Define Objectives & Success Criteria: "Find all critical vulnerabilities in the customer portal" vs. "Simulate an APT to access finance DB." Success is measured against these goals.

• Stakeholder Engagement: Align with CISO (risk), IT Ops (disruption), Legal (compliance), Business Units (impact).

• Case Study: rgpvonline.com

  • Objective: Likely to assess security of an educational portal handling student/faculty data (PII, grades).

  • Scope: In-scope: *.rgpvonline.com, associated APIs, login portals. Out-of-scope: Third-party payment gateways, student database servers (if owned by separate entity).

  • Key Considerations: Compliance with education data laws (like FERPA if US-based), high user traffic windows (avoid exam periods).

II. Reconnaissance and Information Gathering

Passive Reconnaissance

• Goal: Gather intelligence without interacting directly with target systems.

• DNS Reconnaissance:

  • Purpose: Map digital footprint (subdomains, IP ranges, server locations).

  • Techniques:

    1. Zone Transfer (AXFR): Attempt unauthorized DNS record dump (dig axfr @ns1.target.com target.com).

    2. Enumeration: Query for common records (A, AAAA, MX, TXT, SRV).

    3. Subdomain Discovery: Use search engines, certificate transparency logs (crt.sh), tools (Sublist3r, Amass).

• OSINT (Open-Source Intelligence):

  • Sources: Company website, LinkedIn (employee roles/tech stack), GitHub (code leaks, credentials), Shodan/Censys (exposed services), WHOIS, social media.

• > [!TIP] Why External Footprint First? Reveals attack surface (public IPs, apps, cloud storage), informs active scanning strategy, and avoids premature detection.

Active Reconnaissance

• Network Scanning & Enumeration:

  • Port Scanning (Nmap): Identify open ports/services (-sS SYN scan, -sV version detection).

  • OS/Service Fingerprinting: Determine OS, service versions/patches (Nmap -O, -A).

  • Vulnerability Scanning: See Section III.

• > [!CRITICAL] Understanding Architecture is Paramount: You cannot exploit what you don't understand.

  • Network Topology: Firewalls, DMZs, VLANs, proxy chains.

  • Systems & Apps: OS types, web servers (Apache/IIS), frameworks (Spring, .NET), databases.

  • Dependencies: Third-party libraries, APIs, cloud services.

  • Why? Determines exploit feasibility, payload choice, and evasion techniques. A Windows SMB exploit won't work on a Linux-only network.

III. Vulnerability Analysis

Vulnerability Scanning

• Purpose: Automated identification of known vulnerabilities (CVEs), misconfigurations, missing patches.

• Methodology: Credentialed (more accurate, deeper) vs. Non-credentialed (black-box).

• Common Tools:

  • Nessus: Comprehensive, commercial, excellent reporting.

  • OpenVAS: Open-source Nessus alternative.

  • Nikto: Specialized web server scanner.

• Automated vs. Manual:

  • Automated: Fast, broad coverage, high false positives/negatives. Finds known vulns.

  • Manual Verification: Essential to confirm findings, identify logic flaws, chained vulnerabilities, and business logic errors missed by scanners.

• Interpreting Results:

  • False Positives: Scanner reports vuln that doesn't exist. Always manually verify.

  • Risk Rating: Based on CVSS (Common Vulnerability Scoring System) score (0-10). Consider Exploitability (ease of attack) and Impact (confidentiality, integrity, availability loss).

Web Application Vulnerability Analysis (OWASP Top 10 Context)

• SQL Injection (SQLi):

  • Definition: Injection of malicious SQL code via user input, altering the intended database query.

  • Primary Risks:

    1. Data Exfiltration: UNION SELECT to dump entire tables.

    2. Authentication Bypass: ' OR '1'='1 to log in without credentials.

    3. Data Manipulation/Destruction: UPDATE/DROP statements.

    4. Remote Code Execution: (In some DBs like MSSQL with xp_cmdshell).

  • > [!TIP] Exam Answer Structure: State definition → List 3-4 primary risks with brief examples.

• HTTP Strict Transport Security (HSTS):

  • What: Security header (Strict-Transport-Security: max-age=31536000; includeSubDomains) forcing browsers to use HTTPS only for a domain.

  • Why Crucial:

    1. Prevents SSL Stripping: Stops man-in-the-middle from downgrading HTTPS to HTTP.

    2. Protects Against Protocol Downgrade Attacks.

    3. Enforces Secure Connections even if user types http://.

  • Implementation: Must be served over a valid HTTPS connection initially.

IV. Exploitation and Attack Vectors

Exploitation Fundamentals

• Role of Architecture Understanding: Determines:

  • Exploit Selection: Buffer overflow for unpatched Windows service vs. SQLi for a PHP/MySQL app.

  • Payload Crafting: 32-bit vs. 64-bit shellcode, OS-specific commands.

  • Evasion: Bypassing AV/EDR, firewall rules, WAFs based on known defenses.

• Proof of Concept (PoC): Minimal, reliable code demonstrating the vulnerability. Goal: Prove impact (e.g., id command output, whoami) without causing unnecessary damage.

Wireless Network Exploitation

• Importance of Packet Sniffing (Monitoring):

  1. Capture Handshakes: For offline WPA/WPA2 cracking (4-way handshake).

  2. Identify Networks & Clients: Map SSIDs, BSSIDs, client MACs.

  3. Analyze Traffic: Detect clear-text protocols (HTTP, FTP), identify active users/sessions.

  4. Deauthentication Attacks: Sniff to find target client, then send deauth frames to kick them off, forcing a handshake capture.

• Common Attacks:

  • Evil Twin: Rogue AP mimicking legitimate one to capture credentials.

  • Rogue AP: Unauthorized AP within network for man-in-the-middle.

  • Deauthentication Attack: Disrupt client-AP communication.

Social Engineering (Wireless Focus)

• Tactics:

  1. Phishing for Wi-Fi Credentials: Fake captive portal/login page.

  2. Baiting with Rogue AP: "Free Public Wi-Fi" (Evil Twin) to harvest credentials or traffic.

  3. Tailgating/Pretexting: Gaining physical access to deploy rogue devices.

• Mitigation via Employee Training:

  • Awareness: Recognize suspicious Wi-Fi networks, phishing cues.

  • Policy: Never enter corporate credentials on unknown networks.

  • Reporting: Establish clear channels to report suspicious activity.

  • > [!TIP] Human is the Weakest Link: Technical controls (WPA3, 802.1X) are ineffective if employee willingly connects to a malicious AP.

V. Cryptography in Penetration Testing

Cryptographic Principles & Attacks (RSA Example)

• RSA Algorithm for Secure Communication:

  1. Key Generation:

     • Choose large primes $p, q$.

     • Compute $$\displaystyle n = p \times q $$, $$\displaystyle \phi(n) = (p-1)(q-1) $$.

     • Choose public exponent $e$ (usually 65537) where $$\displaystyle 1 < e < \phi(n) $$ and $$\displaystyle \gcd(e, \phi(n)) = 1 $$.

     • Compute private exponent $d$ such that $$\displaystyle d \equiv e^{-1} \mod \phi(n) $$.

     • Public Key: $(e, n)$. Private Key: $(d, n)$.

  2. Encryption (by sender with public key): $$\displaystyle c = m^e \mod n $$.

  3. Decryption (by receiver with private key): $$\displaystyle m = c^d \mod n $$.

  • > [!BOX] Core Security: Relies on computational hardness of factoring large integers ($n$).

• Decryption in Testing Context: Testing for weak keys, padding oracle attacks (e.g., Bleichenbacher), side-channel attacks (timing, power analysis), or implementation flaws (poor RNG).

Cryptography Audit & Assessment

• Key Elements in Report:

  1. Cipher Suite Analysis: List supported/negotiated ciphers. Flag weak ones (RC4, DES, 3DES, NULL, EXPORT).

  2. Key Management: Key generation, storage, rotation, destruction policies.

  3. Protocol Vulnerabilities: TLS/SSL version support (SSLv2/3, TLS 1.0/1.1), renegotiation issues, compression (CRIME).

  4. Certificate Validation: Chain of trust, expiration, hostname mismatch, self-signed usage.

  5. Implementation Flaws: Use of deprecated libraries, hardcoded keys, improper random number generation.

• Stakeholder Engagement for Implementation:

  • Developers/Architects: Explain why changes (e.g., disable TLS 1.0) are needed, provide secure coding patterns.

  • SysAdmins/DevOps: Configure servers (Apache/Nginx, Java, .NET) to enforce strong ciphers and protocols.

  • Management: Translate technical risks (e.g., "POODLE vulnerability") into business impact (data breach, compliance failure).

  • > [!TIP] Audit is Useless Without Buy-in: Recommendations must be actionable, prioritized (Critical/High/Med/Low), and aligned with business constraints.

VI. Specialized Testing Domains

Cloud Security Penetration Testing

• Shared Responsibility Model: Provider secures the cloud (infrastructure). Customer secures the in-cloud (configurations, data, access).

• Common Misconfigurations:

  • AWS S3 Buckets: Public read/write access (s3:PutObject for *).

  • IAM Policies: Overly permissive ("Action": "*"), unused keys, no MFA for privileged users.

  • Exposed Services: Unrestricted access to databases (RDS), management consoles (EC2 Instance Connect), or serverless functions (Lambda URLs).

  • Default Credentials: Using default passwords on cloud VMs/containers.

• Tooling & Methodologies:

  • Tools: Pacu (AWS), ScoutSuite, Prowler, CloudGoat (intentionally vulnerable AWS environments).

  • Methodology: Enumerate cloud assets (using provider APIs), assess IAM, storage, compute, and network configurations.

Capture The Flag (CTF) Competitions

• Simulation of Real-World Scenarios:

  1. Time Pressure & Resource Constraints: Mimic incident response or limited engagement windows.

  2. Diverse Skill Application: Requires web app hacking, binary exploitation (pwn), crypto cracking, forensics, reverse engineering—just like a real assessment with varied systems.

  3. Problem-Solving Under Uncertainty: Flags are hidden; must chain vulnerabilities, think creatively.

  4. Tool Proficiency & Adaptability: Must learn/use new tools quickly.

• Skill Development: Technical depth in specific domains, research ability, persistence, and clear documentation of steps (for write-ups).

VII. Methodology and Reporting

Penetration Testing Methodologies

• Structured Approaches (Web App Focus):

  • OWASP Testing Guide: Comprehensive checklist (v4.2) covering all OWASP Top 10 categories.

  • PTES (Penetration Testing Execution Standard): Phases: Pre-engagement, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, Reporting.

  • NIST SP 800-115: Technical guide to security testing.

• Importance of Repeatable & Thorough Method:

  • Consistency: Ensures same depth across different targets/time.

  • Completeness: Reduces chance of missing critical attack surfaces.

  • Quality: Provides defensible, auditable process.

  • Efficiency: Clear phases prevent wasted effort.

Documentation & Reporting

• Key Components of a Pen Test Report:

  1. Executive Summary: Non-technical overview for management. Business impact, overall risk posture, high-level recommendations.

  2. Scope & Methodology: What was tested, how, and tools used.

  3. Detailed Findings: For each vulnerability:

     • Title & Risk Rating (CVSS score).

     • Description: What it is.

     • Evidence: Screenshots, curl commands, PoC code.

     • Impact: Business consequences (data loss, system compromise).

     • Remediation: Clear, actionable steps (e.g., "Implement parameterized queries").

  4. Conclusion & Strategic Recommendations: Long-term security improvements.

• Case Study: Reporting on rgpvonline.com

  • Finding Example: "SQL Injection in search.php allows database user enumeration."

  • Evidence: search.php?q=test' UNION SELECT user,password FROM users-- - returns user table.

  • Impact: "Attacker can harvest all student/faculty credentials, leading to account takeover and PII breach."

  • Remediation: "Use prepared statements (parameterized queries). Input validation on server-side."

• > [!TIP] Golden Rule: Write for the audience. Executives care about risk & cost. Developers/IT need technical details & fixes. Never bury critical findings in jargon.

END OF UNIT 1 NOTES