Introduction to Pentesting

Why This Matters

Interviewers expect you to articulate what you do with precision. The difference between a vulnerability assessment and a penetration test, the meaning of black/white/grey box, rules of engagement, and legal boundaries — these come up in every interview, and vague answers signal inexperience regardless of your technical skill.

What Is a Penetration Test?

A penetration test (pentest) is an authorized, simulated attack against a system, network, or application to identify security weaknesses that could be exploited by a real attacker. The key word is authorized — the same actions performed without authorization are criminal offenses under laws like India's IT Act 2000/2008, the US Computer Fraud and Abuse Act (CFAA), and the UK Computer Misuse Act.

A pentest is not:

A guarantee that no vulnerabilities exist (only that the tester, with defined time and scope, didn't find more)
A one-time certification of security
The same as a vulnerability scan (a scan is automated tool output; a pentest involves human judgment, chaining findings, and demonstrating real-world impact)

Types of Security Assessments — The Full Spectrum

Understanding the distinctions between assessment types is essential because clients ask you to scope engagements, and interviewers test whether you know what you're selling/doing.

Vulnerability Assessment (VA)

Definition: Systematic identification and classification of vulnerabilities in a target environment using automated tools and manual review.

Depth: Enumerate vulnerabilities, assign severity (CVSS scores), report findings. Does not involve exploitation.

Deliverable: A prioritized list of vulnerabilities with remediation recommendations.

Limitation: Cannot confirm exploitability. A VA may flag a vulnerability that isn't actually exploitable in the target's specific configuration. It also doesn't show business impact — you know a patch is missing, but you don't demonstrate what an attacker could actually do with it.

When clients choose VA: Compliance requirements, regular hygiene checks, quick snapshot before a pentest.

Penetration Test (PT)

Definition: Authorized simulation of an attacker's actions, including exploitation of vulnerabilities, to demonstrate real-world impact.

Depth: Find vulnerabilities → exploit them → demonstrate impact (data accessed, privilege escalated, lateral movement achieved) → report the attack chain, not just individual vulnerabilities.

Deliverable: Report showing attack paths, demonstrated impact, prioritized remediation. The evidence is more compelling than a VA because it shows what an attacker would actually achieve.

Key distinction from VA: A pentester asks "can I actually use this?" A VA asks "does this exist?"

Red Team Assessment

Definition: Adversary simulation — the red team acts as a specific threat actor to test the organization's detection, response, and resilience, not just to find vulnerabilities.

Depth: Long-duration (weeks or months), stealthy, goal-oriented (e.g., "reach the CEO's email" or "exfiltrate financial data"). The blue team (SOC, IR team) is typically unaware.

Key distinction from PT: A pentest finds as many vulnerabilities as possible within scope. A red team uses a minimal footprint — they may walk past a known vulnerability if exploiting it would trigger detection. The goal is to achieve objectives while evading detection, testing the organization's entire security program.

Deliverable: Purple team review, MITRE ATT&CK mapping, detection gap analysis, improvement recommendations.

Internal Vulnerability Assessment (IVA)

Vulnerability assessment performed from inside the network — simulating what an attacker who has already breached the perimeter (or an insider) could find. Typically covers servers, workstations, network devices, AD infrastructure.

External Vulnerability Assessment (EVA)

Vulnerability assessment of internet-facing assets — the attack surface visible from the internet. Web applications, email servers, VPN gateways, DNS, etc.

Internal Penetration Test (IPT)

Exploitation-focused assessment from inside the network. Often simulates a compromised employee workstation or a contractor with basic network access. Covers lateral movement, privilege escalation, AD attacks, internal web applications.

External Penetration Test (EPT)

Exploitation from the internet. Goal is typically to breach the perimeter — achieve a foothold on internal infrastructure via an internet-facing vulnerability.

Application Security Testing (AST)

Focused on a specific application — web, API, mobile, desktop. Includes:

DAST (Dynamic Application Security Testing): Black-box testing against a running application
SAST (Static Application Security Testing): Review of source code without executing it
IAST (Interactive AST): Agent-based testing during runtime

Approved Scanning Vendor (ASV)

PCI-DSS specific. ASVs are organizations approved by the PCI Security Standards Council to perform quarterly external vulnerability scans for merchants and service providers who handle cardholder data. The ASV scan must follow specific methodology and produce a pass/fail report against PCI-DSS requirements. This is not a pentest — it's a compliance scan.

Testing human controls — phishing simulations, pretexting calls (vishing), physical security (attempting to tailgate into a facility).

Configuration Review

Reviewing the configuration of systems, devices, and applications against security baselines (CIS benchmarks, vendor hardening guides). Does not involve exploitation — it's a compliance and configuration audit.

Source Code Review (Secure Code Review)

Manual or automated review of application source code to identify security vulnerabilities. Can be done with or without access to the running application.

Segmentation Testing

Verifying that network segmentation controls work as intended — testing that a host in the DMZ cannot reach internal servers, that PCI environments are isolated from the corporate network, that OT/ICS networks are properly separated.

Testing Approaches: Black, White, and Grey Box

Black Box

What the tester knows: Only the target name or IP range. No credentials, no architecture diagrams, no source code.

Simulates: External attacker with no insider knowledge.

Advantages: Realistic simulation of an external threat. Tests whether the organization's perimeter holds against someone with no information advantage.

Limitations: Inefficient — testers spend significant time on reconnaissance that internal teams already know. May miss internal vulnerabilities entirely. Not the best use of testing budget if you want comprehensive coverage.

White Box

What the tester knows: Everything — credentials, architecture diagrams, source code, network topology, infrastructure details.

Simulates: Insider threat, or an attacker who has performed extensive reconnaissance and obtained internal information.

Advantages: Maximum coverage in minimum time. Allows testing of internal components that wouldn't be reachable in black-box testing. Source code review requires white-box access. Finds far more vulnerabilities per hour of engagement.

Limitations: Less realistic simulation of an external attacker. Can feel artificial.

Grey Box

What the tester knows: Partial information — typically user-level credentials, some network documentation, maybe an application architecture overview but not full source code.

Simulates: A compromised employee account, or a contractor with limited access.

Most common in practice. Grey box balances realism with efficiency — you know enough to test meaningfully without spending the entire engagement on reconnaissance that doesn't demonstrate security risk.

The Penetration Testing Methodology

Several frameworks define pentest methodology. Know all of them by name and key phases.

PTES — Penetration Testing Execution Standard

The most widely referenced pentest methodology framework. Seven phases:

1. Pre-Engagement Interactions: Define scope, objectives, testing types, timeline, legal authorization (Statement of Work, Rules of Engagement). Establish emergency contacts. Define what happens if a real attacker is discovered during the test.

2. Intelligence Gathering (Reconnaissance): Passive and active information gathering about the target — OSINT, DNS enumeration, WHOIS, network mapping, employee information, technology stack identification.

3. Threat Modeling: Based on gathered intelligence, identify which threats are most relevant to this target. What assets are most valuable? What attack paths are most likely? This guides testing priority.

4. Vulnerability Identification: Scanning and manual analysis to identify potential weaknesses in the target. Not exploitation yet — identification.

5. Exploitation: Attempting to leverage identified vulnerabilities to gain access, escalate privileges, or achieve defined objectives. Demonstrating that the vulnerability is actually exploitable.

6. Post-Exploitation: After gaining access, determine the extent of impact — what data is accessible, what can be pivoted to, what persistence mechanisms are available. This phase determines business impact.

7. Reporting: Document findings, evidence, attack chains, impact, and prioritized remediation recommendations. The report is the deliverable the client actually uses.

OWASP Testing Guide (OTG)

Focused on web application security testing. Provides detailed test cases organized by category (Authentication Testing, Authorization Testing, Input Validation Testing, etc.). The OTG is a reference for web application pentests — not a step-by-step methodology but a catalog of tests to perform.

OWASP MASTG (Mobile Application Security Testing Guide)

The equivalent of OTG for mobile applications (Android and iOS). Defines the MASVS (Mobile Application Security Verification Standard) as the requirement set and MASTG as the testing guide. Essential reading for mobile pentesters.

OSSTMM (Open Source Security Testing Methodology Manual)

More rigorous and academic than PTES. Defines "attack surface" quantitatively and covers physical security, wireless, networks, and human factors. Less commonly cited in interviews but useful for understanding scope.

MITRE ATT&CK

Not a pentest methodology but a knowledge base of adversary tactics, techniques, and procedures (TTPs) organized by attack phase. Used to map pentest findings to real-world threat actor behavior, and increasingly used in red team engagements to ensure coverage of known TTP categories.

Tactics (the "why" — goal of each phase): Reconnaissance → Resource Development → Initial Access → Execution → Persistence → Privilege Escalation → Defense Evasion → Credential Access → Discovery → Lateral Movement → Collection → Command and Control → Exfiltration → Impact

Each tactic has multiple techniques, each with sub-techniques and associated threat actor mappings.

Rules of Engagement (ROE)

The Rules of Engagement define what the tester is and is not authorized to do. This is one of the most important documents in any pentest. Testing outside the ROE is potentially criminal, even if you've been hired to test.

Typical ROE contents:

Scope definition: - IP ranges, domains, applications explicitly in scope

Explicitly out-of-scope items (shared hosting environments, third-party SaaS, production databases without explicit approval, etc.)
Geographic/jurisdictional limitations

Testing windows: - When testing is authorized (business hours? 24/7? only on weekends?)

Blackout periods (around product launches, critical business events)

Authorized techniques: - Are DoS/DDoS tests authorized?

Is phishing of employees authorized?
Is physical security testing authorized?
Are destructive tests authorized?
Is exploitation (not just identification) authorized?

Authorization chain: - Who specifically has authorized the test?

Contact information for the client's technical team (in case you need to verify something in real time)
Emergency stop contacts (if you accidentally take down a production system)

Third-party services: - Cloud providers, CDN, SaaS — you generally cannot test these without their authorization, even if your client authorizes it. AWS, Azure, GCP all have their own penetration testing authorization processes.

Proof of authorization: Always obtain written authorization before starting any test. A "get-out-of-jail letter" (signed scope document) should be carried physically or be immediately accessible during physical engagements. This proves to law enforcement that your activities are authorized if questioned.

Legal Framework

India — IT Act 2000 and Amendment 2008

The primary legislation governing computer-related offenses in India.

Section 43: Unauthorized access, downloading data, introducing viruses, denial of service — civil liability, compensation.

Section 66: Same as Section 43 but with criminal intent — imprisonment up to three years and/or fine.

Section 66B: Dishonestly receiving stolen computer resource or communication device — three years, fine.

Section 66C: Identity theft (fraudulently using electronic signature, password, or unique identification) — three years, ₹1 lakh fine.

Section 66D: Cheating by personation using computer resource — three years, ₹1 lakh fine.

Implication for pentesters: Written authorization from the asset owner before any testing. If you test systems belonging to a company, authorization must come from someone with legal authority to grant it (CISO, CEO, legal team — not just the IT admin).

US — CFAA (Computer Fraud and Abuse Act)

18 U.S.C. § 1030. Broad law covering unauthorized access to computers. "Exceeding authorized access" has been applied broadly — in some interpretations, even violating a website's Terms of Service could technically apply. Bug bounty programs and signed SOWs provide the legal authorization that makes pentest activities lawful.

UK — Computer Misuse Act 1990

Three key offenses: unauthorized access, unauthorized access with intent to commit further offenses, unauthorized modification. Even attempted unauthorized access is an offense.

The Critical Point

Authorization is everything. The same technical actions — connecting to a server, sending a crafted HTTP request, running a scan — are either professional security work or criminal offenses depending solely on whether you have written authorization. Never assume verbal authorization is sufficient. Never assume a client's verbal "go ahead" covers systems not explicitly listed in the scope document.

Professional Ethics

Confidentiality: Everything you discover during an engagement — client data, vulnerabilities, architecture — is confidential. Sharing client data, even with good intentions, is a breach of trust and potentially contractual obligation. Sign NDAs and honor them.

Minimal footprint: Access only what's necessary to demonstrate impact. If you need to prove you can read a sensitive file to demonstrate SQL injection impact, access one file — don't exfiltrate an entire database.

Report everything you find: Don't selectively report. A client can decide the risk is acceptable — that's their decision. Your job is to give them accurate, complete information.

Don't leave backdoors: Always remove any shells, persistence mechanisms, or modifications made during the test. Document anything you installed or changed so it can be cleaned up.

Data handling: Any sensitive data extracted during testing (passwords, PII, financial records) must be handled per the scope agreement — typically deleted securely after the engagement or returned to the client.

Scope creep: If you find a path to an out-of-scope system, stop and notify the client. You cannot test what isn't in scope just because it's technically accessible from in-scope systems. Get written authorization to expand scope.

Emergency escalation: If during a pentest you discover evidence that an actual threat actor is also on the network, stop and notify the client immediately. You are not authorized to investigate a live incident.

Bug bounties vs pentests: Bug bounty programs are public programs where researchers submit vulnerabilities for reward. They have specific scope rules and responsible disclosure timelines. They are not open authorization to test anything on a company's infrastructure — only what's explicitly in the program scope.

The Pentest Report — Brief Introduction

The report is the deliverable. Everything you find is worthless if it isn't communicated effectively.

A report has two primary audiences:

Technical audience: System administrators, developers, security engineers — they need enough detail to reproduce and fix the issue.
Executive audience: CISO, CTO, board — they need to understand business risk, not technical detail.

Report structure (covered in depth at Level 1): 1. Executive Summary — business risk, key findings, strategic recommendations 2. Scope and Methodology 3. Findings (ranked by severity) 4. Appendices (raw output, detailed evidence)

Severity rating: CVSS v3.1 base score is the industry standard, but always include contextual severity — a CVSS 9.8 vulnerability in an isolated test environment may be lower business risk than a CVSS 5.0 authentication bypass in a customer-facing payment portal.

Key Terms to Know Cold

Term	Definition
SOW	Statement of Work — contractual document defining engagement scope and deliverables
ROE	Rules of Engagement — specific technical and behavioral constraints on testing
NDA	Non-Disclosure Agreement — confidentiality obligation
POC	Proof of Concept — minimal code or steps demonstrating a vulnerability is exploitable
CVE	Common Vulnerabilities and Exposures — public vulnerability identifier (e.g., CVE-2021-44228 = Log4Shell)
CVSS	Common Vulnerability Scoring System — severity scoring framework
TTPs	Tactics, Techniques, and Procedures — attacker behavior patterns
IOC	Indicator of Compromise — artifact suggesting a breach (IP, hash, domain)
MITRE ATT&CK	Framework mapping attacker TTPs to named techniques
PTES	Penetration Testing Execution Standard
OWASP	Open Web Application Security Project
MASTG	Mobile Application Security Testing Guide
MASVS	Mobile Application Security Verification Standard