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

UNIT 4: PENETRATION TESTING AND VULNERABILITY ANALYSIS

1.0 PRE-ENGAGEMENT & LEGAL/ETHICAL FOUNDATIONS

1.1 Legal and Ethical Considerations

• Legal Impact on Decision-Making:

  • Authorization: Written, scope-defined consent is mandatory. Without it, testing is illegal (Computer Fraud and Abuse Act, IT Act 2000).

  • Compliance: Tests must align with regulations (GDPR, HIPAA, PCI-DSS) to avoid regulatory penalties.

  • Liability: Defines responsibility for accidental system disruption or data exposure.

• Ethical Boundaries & Professional Conduct:

  • Adherence to codes (e.g., (ISC)² Code of Ethics, OSSTMM).

  • Confidentiality: Protecting client data and findings.

  • Integrity: Honest reporting of all findings, including null results.

  • Scope Adherence: Never exceed defined boundaries.

[!TIP] Exam Focus: Questions often ask to evaluate impact. Link legal/ethical factors directly to organizational risk, reputation, and financial liability.

1.2 Scoping and Types of Penetration Tests

[!TIP] Comparative Analysis: For a 7m question, create a two-column table in your answer highlighting Scope, Tools, and Primary Risk for each type.

2.0 RECONNAISSANCE & INFORMATION GATHERING

2.1 DNS Reconnaissance

• Purpose: Map the target's digital footprint, identify attack surface (subdomains, servers), and uncover infrastructure details.

• Key Techniques:

  1. Zone Transfer (AXFR): Attempt unauthorized transfer of entire DNS zone file (dig @ns1.target.com target.com AXFR).

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

  3. Subdomain Discovery: Using wordlists, search engines, certificate transparency logs (crt.sh), and tools like sublist3r, amass.

• Methodology: Passive (search engines, public databases) → Active (direct queries to DNS servers).

2.2 External Presence & OSINT

• Critical Pre-engagement Step: Reveals information the organization itself has published.

• Key OSINT Sources:

  • Public Records: WHOIS, DNS records, business registries.

  • Social Media & Job Postings: Reveal tech stack, employee names (for phishing), office locations.

  • Certificate Transparency Logs: Discover subdomains via SSL/TLS certificates.

  • Code Repositories (GitHub): Often leak configuration files, API keys, internal IPs.

2.3 Target System Architecture Analysis

• Why Crucial Before Exploitation?

  • Prevents "shooting in the dark" and unnecessary system crashes.

  • Identifies critical systems, trust relationships, and choke points.

  • Maps potential attack paths (e.g., "Compromise DMZ web server → pivot to internal DB server").

• Analysis Focus:

  • Network topology diagrams (if available).

  • System dependencies (which apps talk to which databases?).

  • Entry/exit points for data (firewall rules, proxy configurations).

[!TIP] Common Pitfall: Skipping architecture analysis leads to wasted effort, missed high-value targets, and increased detection risk.

3.0 VULNERABILITY ANALYSIS & SCANNING

3.1 Vulnerability Scanning Tools

3.2 Web Application Penetration Testing Methodologies

• Structured Frameworks: OWASP Testing Guide (most common), PTES (Penetration Testing Execution Standard).

• Standard Phases:

  1. Discovery: Passive/active info gathering, mapping app structure.

  2. Analysis: Identify vulnerabilities (automated + manual).

  3. Attack: Exploit confirmed vulnerabilities to assess impact (e.g., extract data, escalate privileges).

  4. Reporting: Document findings, evidence, and remediation.

• Key Testing Areas: Authentication, Session Management, Input Validation (SQLi, XSS), Access Control, API Security.

4.0 EXPLOITATION & ATTACK VECTORS

4.1 Web Application Security Vulnerabilities

• SQL Injection (SQLi):

  • Primary Risk: Data Exfiltration (steal entire databases), Authentication Bypass, Data Manipulation/Deletion.

  • Types: Error-based, Union-based, Blind (Boolean/Time-based).

  • Mitigation: Prepared Statements (Parameterized Queries), Input Validation, Least Privilege DB accounts.

• HTTP Strict Transport Security (HSTS):

  • Crucial Role: Server header Strict-Transport-Security: max-age=... forces browsers to only use HTTPS.

  • Prevents: Protocol downgrade attacks (SSL Stripping) and cookie hijacking via man-in-the-middle.

4.2 Wireless Penetration Testing

• Packet Sniffing Importance:

  • Capture WPA/WPA2 handshakes for offline cracking.

  • Analyze traffic for plaintext protocols (HTTP, FTP, Telnet).

  • Identify misconfigurations (open networks, weak encryption like WEP).

• Tools: Wireshark (analysis), aircrack-ng suite (airodump-ng, aireplay-ng) for handshake capture & cracking.

4.3 Social Engineering (Wireless & General)

• Common Tactics Targeting Wireless:

  1. Rogue Access Points (Evil Twin): Mimic legitimate SSID to trick users into connecting.

  2. Phishing for Credentials: Fake captive portal ("Enter Wi-Fi password") to harvest credentials.

  3. Wireless Phishing (Wi-Fi Phishing): Sending targeted emails about "network issues" to lure credential disclosure.

• Employee Training Programs as Mitigation:

  • Awareness: Teach tactics (rogue APs, phishing cues).

  • Simulation Exercises: Regular, controlled phishing tests.

  • Reporting Culture: Encourage employees to report suspicious activity/APs.

  • Policy Enforcement: Clear rules on connecting to unknown networks.

4.4 Cryptography in Penetration Testing

• RSA Algorithm for Secure Communication:

  • Purpose: Asymmetric encryption for key exchange (e.g., in TLS) and digital signatures.

  • Process:

    1. Key Generation:

$$n = p \times q$$

$$\phi(n) = (p-1)(q-1)$$

        Choose $e$ (public exponent), compute $d$ (private exponent) such that $e \cdot d \equiv 1 \mod \phi(n)$.

    2.  **Encryption (by sender with *public* key $(n, e)$):**

$$C = M^e \mod n$$

    3.  **Decryption (by receiver with *private* key $d$):**

$$M = C^d \mod n$$

• Decryption Context in Pentesting:

  • Cracking weak encryption (short keys, poor RNG).

  • Analyzing captured encrypted traffic (if private key obtained or weak cipher used).

  • Testing for cryptographic flaws (padding oracle, weak ciphersuites).

• Cryptography Audit Documentation - Key Elements:

  • Algorithms & Protocols Used (e.g., TLS 1.3, AES-256-GCM, RSA-2048).

  • Key Management Process (generation, storage, rotation, destruction).

  • Configuration Review (cipher suite order, certificate validity, HSTS policy).

  • Findings & Evidence (e.g., "SSLv2 enabled", "RSA key < 2048 bits").

5.0 POST-EXPLOITATION, REPORTING & COMMUNICATION

5.1 Documentation & Reporting

• Standard Penetration Test Report Structure:

  1. Executive Summary: High-level risks, business impact, budget implications (for management).

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

  3. Technical Findings: Detailed vulnerabilities, proof-of-concept (PoC) code/screenshots, CVSS scores.

  4. Remediation Recommendations: Specific, actionable steps (prioritized).

  5. Conclusion & Overall Risk Rating.

• Cryptography Audit Report Specifics:

  • Must include cryptographic inventory (all uses of crypto in the system).

  • Detailed algorithm and key length analysis against current standards (NIST, BSI).

  • Review of PKI infrastructure (CA, certificate chain, revocation).

5.2 Stakeholder Engagement

• Importance for Success: Technical findings are useless if not understood or acted upon.

• Communicating to Non-Technical Management:

  • Translate technical risk into business risk (e.g., "SQLi vulnerability → potential for full customer database theft → regulatory fines & reputational damage").

  • Use risk matrices (Likelihood vs. Impact).

  • Avoid jargon; focus on impact and cost.

• Facilitating Remediation:

  • Collaborative Meetings: Walk developers/network teams through findings.

  • Prioritization: Help stakeholders understand which fixes are critical vs. low-effort wins.

  • Retesting: Schedule validation to ensure fixes are effective.

6.0 SPECIAL CONTEXTS & ADVANCED SCENARIOS

6.1 Case Study: https://www.rgpvonline.com (Educational Portal)

• Primary Test Objectives:

  1. Data Leakage: Student PII, grades, financial data exposure.

  2. Authentication & Authorization: Bypassing login, privilege escalation (student → admin).

  3. Information Disclosure: Error messages, server banners, source code leaks.

  4. API Security: If mobile app/API exists, test for IDOR, excessive data exposure.

• Likely Threat Model: Students (insider threat), external attackers seeking data, competitors.

6.2 Capture The Flag (CTF) Competitions

• Simulation of Real-World Scenarios:

  • Time Pressure: Mimics incident response or limited engagement windows.

  • Diverse Skill Sets: Requires blending of recon, exploitation, forensics, crypto, web.

  • Unknown Environment: "Black-box" testing; no prior knowledge of systems.

  • Learning Outcome: Develops adaptive problem-solving and rapid research skills under pressure.

6.3 Cloud Security Penetration Testing

• Unique Considerations:

  • Shared Responsibility Model: Pentester must know what the cloud provider secures (hypervisor, physical) vs. what the client secures (IAM, S3 buckets, app config).

  • API Security: Cloud is API-driven. Test for excessive permissions, insecure direct object references (IDOR) in cloud APIs (AWS, Azure).

  • Misconfiguration: #1 risk. Focus on:

    • S3 Buckets: Public read/write access.

    • IAM Policies: Overly permissive roles, unused keys.

    • Security Groups/NSGs: Open ports (0.0.0.0/0 on 22, 3389).

• Cloud-Specific Tools: ScoutSuite, Prowler (AWS), Azure Security Toolkit, CloudGoat (training).

[!TIP] Final Exam Strategy: For "Discuss" questions (7m), use point-wise structure: Definition → Key Features → Example/Tool → Impact/Risk → Mitigation. Always link back to real-world business impact.