Unit1 - Subjective Questions

Penetration Testing is a simulated cyberattack against your computer system to check for exploitable vulnerabilities. It involves a human-driven analysis to identify security weaknesses and attempt to exploit them to understand the impact.

Difference between Penetration Testing and Vulnerability Assessment:

• Vulnerability Assessment (VA):

  • Focus: Identifying and listing as many vulnerabilities as possible.
  • Method: Usually automated scanning.
  • Depth: Breadth-over-depth; rarely validates false positives.
  • Outcome: A list of potential vulnerabilities ranked by severity.

• Penetration Testing (PT):

  • Focus: Exploiting vulnerabilities to prove they exist and determining the impact.
  • Method: Manual + Automated tools (Goal-oriented).
  • Depth: Depth-over-breadth; validates findings via exploitation.
  • Outcome: Proof of concept (PoC) showing how an attacker could gain access or steal data.

These strategies are defined by the level of information provided to the tester prior to the engagement:

1. Black Box Testing:

   • Knowledge: The tester has zero prior knowledge of the target infrastructure (simulates an external hacker).
   • Pros: Realistic simulation of an external attack.
   • Cons: Time-consuming; may miss internal vulnerabilities.

2. White Box Testing (Crystal Box):

   • Knowledge: The tester has full knowledge (network diagrams, source code, IP addresses, credentials).
   • Pros: Most thorough; finds logic errors and internal bugs; faster.
   • Cons: Less realistic regarding external threat actors.

3. Grey Box Testing:

   • Knowledge: The tester has partial knowledge (e.g., user-level credentials, network map, but no admin access).
   • Pros: Balanced approach; simulates an insider threat or an attacker who has breached the perimeter.
   • Cons: Requires careful scoping to define what information is shared.

The Rules of Engagement (RoE) is a formal document that acts as the contract and guideline for the penetration test. Its importance includes:

• Legal Protection: It serves as the 'Get Out of Jail Free' card, protecting testers from criminal liability (e.g., CFAA in the US) by proving authorization.
• Scope Definition: It clearly defines what is in-scope (allowed to be tested) and out-of-scope (forbidden).
• Operational Boundaries: It sets time windows for testing (e.g., 9 PM - 5 AM) to minimize business disruption.
• Attack Limitations: It specifies forbidden attack types (e.g., no Denial of Service, no Social Engineering).
• Communication: It lists emergency contact numbers and escalation paths if a critical vulnerability is found or a service goes down.

The PTES is a standard designed to provide a common language and scope for performing penetration tests. It ensures the quality and consistency of the testing process.

The seven main sections are:

1. Pre-engagement Interactions: Scoping, metrics, and RoE definition.
2. Intelligence Gathering: OSINT and reconnaissance.
3. Threat Modeling: Identifying assets and potential attackers.
4. Vulnerability Analysis: Discovering flaws in systems.
5. Exploitation: Actively attacking to bypass security controls.
6. Post Exploitation: Determining the value of the compromised machine (pillaging, pivoting).
7. Reporting: Documenting findings for both executive and technical audiences.

Scope Creep refers to the uncontrolled expansion of a project's scope without adjustments to time, cost, or resources. In pentesting, this occurs when a client asks to test additional IP addresses, applications, or features that were not in the original contract.

Impact:

• Delays in timeline.
• Resource burnout.
• Legal issues if testing touches unauthorized assets.

Management:

• Strict Contract: Clearly define the scope in the Statement of Work (SOW).
• Change Management: Require a formal 'Change Order' for any additions, potentially adjusting fees and deadlines.
• Communication: Maintain clear lines of communication with stakeholders regarding the limits of the engagement.

Compliance frameworks often mandate penetration testing as a requirement for certification or legal operation.

• Mandatory Frequency: For example, PCI-DSS Requirement 11.3 requires pentesting at least annually and after any significant infrastructure change.
• Scope Definition: Compliance dictates specific areas to test (e.g., the Cardholder Data Environment - CDE).
• Methodology: Some standards require testing from both inside and outside the network.
• Reporting: The final report must be structured to prove compliance to auditors, often requiring specific evidence of remediation.
• Data Privacy: Regulations like GDPR or HIPAA enforce strict rules on how PII/PHI (Personal/Health Information) accessed during the test must be handled and sanitized.

External Penetration Testing:

• Perspective: Attacks from the internet (outside the firewall).
• Target: Public-facing assets (Web servers, DNS, Email servers, Firewalls).
• Goal: To determine if an outside attacker can breach the perimeter.

Internal Penetration Testing:

• Perspective: Attacks from within the network (inside the firewall).
• Target: Internal servers, workstations, Active Directory, intranet sites.
• Goal: To simulate an insider threat (disgruntled employee) or an attacker who has already breached the perimeter via phishing or physical access. It assesses lateral movement capabilities.

Environmental considerations involve choosing where to test to balance risk and realism.

Production Environment:

• Definition: The live environment used by real customers/employees.
• Pros: Results are 100% accurate to the real-world security posture.
• Cons: High risk. Testing (especially DoS or heavy scanning) can crash services, corrupt data, and cause financial loss.

Staging/QA Environment:

• Definition: A replica of production used for testing.
• Pros: Safe. Crashes do not impact business operations.
• Cons: Often not a perfect mirror (different patches, configs, no real user traffic), potentially leading to false negatives (missing bugs that exist in prod) or false positives.

OSSTMM is a peer-reviewed methodology for security testing maintained by ISECOM. Unlike other standards that focus purely on vulnerabilities, OSSTMM focuses on operational security and metrics.

• Scientific Approach: It provides a scientific methodology for network interaction and security testing.
• Dimensions: It tests five channels: Human, Physical, Wireless, Telecommunications, and Data Networks.
• Metrics: It uses the Risk Assessment Values (RAVs) to calculate a security score, allowing organizations to measure improvement over time quantitatively.
• Focus: It emphasizes checking controls and security presence rather than just finding specific exploits.

Post-Exploitation occurs after a tester has successfully compromised a target system. It answers the question: "Now that I'm in, what can I do?"

Key Activities:

• Privilege Escalation: Going from a low-level user to Admin/Root.
• Pillaging: Stealing sensitive data (passwords, customer DBs, trade secrets).
• Pivoting/Lateral Movement: Using the compromised machine to attack other systems deep in the network.
• Persistence: Installing backdoors to maintain access.

Criticality: It proves the Business Impact. Finding a vulnerability is technical, but showing that it leads to the theft of the CEO's email or the entire customer database translates technical risk into business risk ($$).

In information security and pentest planning, Risk is conceptually derived as:

Or sometimes simplified as:

Relevance to Scoping:

1. Prioritization: Scoping should focus on assets with the highest Risk. Systems with high Impact (e.g., Payment Gateway) and high Likelihood of attack (public-facing) are prioritized over low-impact internal logs.
2. Resource Allocation: More time and budget (higher marks/effort) are allocated to testing high-risk areas.
3. Risk Appetite: The organization's tolerance for risk determines if they do a simple vulnerability scan (low assurance) or a full Red Team engagement (high assurance).

• Red Teaming: An adversarial goal-based assessment. The Red Team acts as the attacker. Their goal is to achieve a specific objective (e.g., steal data) without being detected, testing the organization's detection and response capabilities.
• Blue Teaming: The defensive security team internal to the organization (SOC, Incident Response). Their goal is to detect, block, and mitigate the attacks launched by the Red Team.
• Purple Teaming: A collaborative approach where Red and Blue teams work together. The Red team launches an attack, and the Blue team checks if they saw it. They then tune the defenses in real-time. It maximizes the learning efficiency of the engagement.

1. What is the goal of the test? (Compliance, security validation, or testing incident response?)
2. What are the target assets? (List of IP addresses, URLs, Domains, or physical locations).
3. What is the testing window? (Dates, times, and duration; e.g., weekends only or 24/7).
4. Are there any restricted attacks? (e.g., DoS, Social Engineering, or specific destructive exploits that are off-limits).
5. Who are the emergency contacts? (The specific individuals to call immediately if a service goes down or a breach is confirmed).

NIST SP 800-115 is a standard guide for Information Security Testing and Assessment. It divides the methodology into four phases:

1. Planning: Defining scope, rules of engagement, and obtaining authorization.
2. Discovery:
   • Network Discovery: Enumerating systems.
   • Vulnerability Scanning: Identifying weaknesses.
3. Attack: Verifying vulnerabilities through exploitation. This phase confirms if a vulnerability is a false positive or a real risk.
4. Reporting: Documenting findings, assessing risk levels, and providing remediation recommendations.

NIST emphasizes that testing is an integral part of the risk management process.

Social Engineering involves manipulating individuals into divulging confidential information or performing actions that compromise security (e.g., Phishing, Vishing, Tailgating).

Why it is often excluded (Out of Scope):

• Human Factor: It targets people, not machines. Organizations may fear embarrassing employees or damaging morale.
• Legal/HR Issues: There are complex legal implications regarding privacy and entrapment.
• Focus: Many organizations want to focus specifically on technical controls (firewalls, software) rather than human error during a standard pentest.
• Cost/Time: Effective social engineering campaigns can be time-consuming to set up properly.

Blind Testing (Black Box):

• Tester: Has no prior knowledge of the target.
• Target Organization: The IT/Security staff knows the test is happening.
• Purpose: Tests the attacker's ability to find vulnerabilities from scratch.

Double-Blind Testing (Zero Knowledge):

• Tester: Has no prior knowledge.
• Target Organization: The IT/Security staff does not know the test is happening (only upper management knows).
• Purpose: This is the ultimate test of readiness. It tests the Incident Response team's ability to detect and respond to an active attack. If the Blue Team doesn't notice the Double-Blind test, their monitoring is insufficient.

Reconnaissance (or OSINT - Open Source Intelligence) is the foundation of the attack.

• Expanding the Attack Surface: Attackers find subdomains, hidden servers, and forgotton dev environments that the organization might not monitor. The more you find, the more you can attack.
• Efficiency: Good recon allows the tester to choose the specific exploits that will work, rather than noisily trying everything (which triggers alarms).
• Passive vs. Active: It allows gathering info without touching the target heavily, keeping the attacker stealthy.
• Context: It provides employee names, email formats, and technology stacks (e.g., knowing a site runs on WordPress vs. IIS changes the entire attack strategy).

Risks:

1. System Crash/DoS: Bringing down a production server.
2. Data Corruption: Accidentally modifying or deleting DB records.
3. Legal Liability: Accessing systems outside the scope.
4. Alarm Fatigue: Triggering too many alerts for the SOC.

Mitigation during Planning:

• Backup: Ensure data is backed up before testing.
• Non-Destructive Testing: Agree to avoid 'dangerous' exploits in the RoE.
• Timing: Test during off-peak hours.
• Whitelisting: Informing the ISP or Cloud provider (e.g., AWS) to prevent blocking the tester's IP, ensuring the test completes.

Testing cloud environments (AWS, Azure, GCP) introduces the Shared Responsibility Model:

• Authorization: Unlike on-prem servers, you do not own the physical infrastructure. You must often obtain permission (or follow strict policy guidelines) from the Cloud Provider before testing.
• Scope Restrictions: You can usually test your own EC2 instances (IaaS), but testing the provider's SaaS services (like Gmail or Office 365 core infrastructure) is strictly prohibited.
• DDoS Restrictions: Cloud providers almost universally ban DDoS testing because it affects other tenants on the shared infrastructure.
• API Rate Limiting: Testers must be aware of API limits; aggressive scanning can get the account throttled or banned by the provider.

A professional report typically includes:

1. Executive Summary: Non-technical overview for management. Summarizes overall risk posture and key findings without jargon.
2. Methodology: Describes the tools and techniques used (e.g., PTES, NIST).
3. Scope and Limitations: Re-states what was tested and what was out of bounds.
4. Detailed Findings (Technical Report):
   • Vulnerability Name.
   • Severity (CVSS Score).
   • Proof of Concept (Screenshots/Logs).
   • Remediation (How to fix it).
5. Risk Matrix: A visual representation of the findings based on impact and likelihood.
6. Conclusion: Final thoughts and roadmap for security maturity.