Penetration Testing — FAQ
Is penetration testing the same thing as "hacking," just with permission?
Functionally, many of the same techniques are involved — but the permission isn't just a legal formality layered on top of identical activity; it changes the entire structure of the engagement. A pen test operates within an explicitly defined scope, rules of engagement, and reporting obligation that don't exist in unauthorized hacking at all — you're not just "allowed" to test, you're contracted to test specific things, within specific boundaries, and to document what you find for the benefit of the organization being tested. Unauthorized access to a computer system is illegal in essentially every jurisdiction (the US Computer Fraud and Abuse Act and India's IT Act are both explicitly named in this course's own material) regardless of intent — "I was just testing their security" is not a legal defense without prior written authorization.
If I find a vulnerability on a website I don't have permission to test, can I just report it to them anyway?
This is genuinely legally risky territory, and the safe answer is: only through an established responsible disclosure channel or bug bounty program, if one exists — not by actively testing further to confirm the vulnerability first. Simply discovering something by accident during normal browsing is different from actively probing a system without authorization; the moment you start sending crafted payloads (SQL injection test strings, XSS payloads) to confirm a suspicion, you've crossed into unauthorized testing regardless of your intent to help. Many organizations have a security.txt file or a published bug bounty program specifically to give researchers a legal channel — if neither exists, consult with a lawyer or a responsible disclosure coordination service (like CERT/CC) before actively probing anything further, rather than assuming good intent provides legal cover.
Why does OSCP specifically restrict how much Metasploit you can use, when it's a legitimate professional tool used constantly in real engagements?
The restriction exists to test whether a candidate actually understands why an exploit works, not just whether they can select the right pre-built module and click run — Metasploit is genuinely useful and widely used in real engagements, but relying on it exclusively doesn't demonstrate the manual exploitation understanding the certification is specifically designed to validate. This is a training/certification design choice specific to proving a particular skill, not a claim that Metasploit itself is somehow illegitimate or shouldn't be used professionally — most real-world pentesters use it heavily once certified.
What's the actual difference between a pen test and a "vulnerability assessment"? Job postings use both terms inconsistently.
A vulnerability assessment identifies and catalogs potential weaknesses (often via automated scanning) without attempting to exploit them — the deliverable is a list of "here's what might be wrong." A penetration test goes further: it attempts actual exploitation, chains findings together into realistic attack paths, and demonstrates concrete impact ("here's what an attacker could actually access, using this exact vulnerability"). The inconsistent job-posting terminology is a real, common source of confusion — worth clarifying explicitly in an interview which one a specific role actually involves, since the skill sets and daily work genuinely differ.
Is red teaming just a more advanced form of penetration testing?
Not quite — they test different things, not just different skill levels. A pen test's goal is finding as many vulnerabilities as possible within a scope, generally announced to the target organization's defenders in advance. A red team engagement's goal is testing whether the organization's detection and response capability actually works — often without the blue team (defenders) knowing an exercise is happening at all, since foreknowledge would defeat the point of testing detection. This course's own material frames this well: pen testing asks "what vulnerabilities exist," red teaming asks "would we actually notice and stop a real attacker." They're complementary disciplines with different objectives, not a beginner/advanced version of the same exercise.
Why do wordlists like rockyou.txt keep showing up in course material and cheatsheets — isn't that list ancient at this point?
It keeps showing up because it's still genuinely effective, not out of habit — rockyou.txt (originally leaked from a 2009 breach) remains useful specifically because human password choices haven't fundamentally changed as much as the age of the list might suggest; a large share of real-world passwords still overlap with patterns from over a decade ago. That said, it's a starting point, not a complete toolkit — professional password-cracking work in practice supplements it with newer breach-derived lists, rule-based mangling (appending years, common substitutions), and target-specific wordlists built from OSINT about the specific organization being tested, rather than relying on one static list alone.
What actually happens if a pen tester accidentally crashes a production system during testing?
This is exactly why "rules of engagement" (covered in this course's own Fundamentals material) explicitly define things like testing windows, whether production or staging is in scope, and an emergency contact — a professional engagement should have this scenario planned for before testing begins, including a clear escalation path and, often, contractual liability terms addressing exactly this risk. In practice: stop testing that specific vector immediately, notify the emergency contact right away rather than trying to quietly fix it or continue, and document exactly what happened for the post-engagement report. This is also a major reason authorized engagements generally test staging/pre-production environments where entirely possible, reserving production testing for cases where the client explicitly understands and accepts that specific risk.
Do I need to know how to write exploits from scratch (like buffer overflow development) to get a pen testing job?
It depends heavily on the specific role, and it's worth being honest that this varies a lot rather than assuming one universal answer. Many pen testing roles, especially web-application-focused ones, rarely if ever require writing a novel exploit from scratch — most real-world findings involve known vulnerability classes (SQLi, XSS, IDOR, misconfigurations) rather than custom zero-day development. Buffer overflow / exploit development skills matter more for specific specializations (OSED-track work, vulnerability research) than for general web/network pen testing. That said, OSCP specifically does test basic buffer overflow exploitation as part of its curriculum, which is part of why it's respected — it validates a baseline of "you understand how memory corruption exploitation actually works," even for candidates whose day-to-day work afterward is mostly web application testing.
Why does this course keep emphasizing "get it in writing" for authorization — isn't a verbal agreement with the client enough if you trust them?
Because the written authorization protects you, not just formalizes something you and the client both already agree on informally — if anything goes wrong during testing (a system crashes, an unexpected legal question arises, a stakeholder who wasn't in the loop objects), a verbal agreement offers essentially no protection in a legal dispute, while written, signed rules of engagement (defining scope, testing windows, and explicit authorization) are the actual evidence that what you did was authorized. This isn't about distrust of a specific client — it's that verbal agreements are unenforceable as proof after the fact, regardless of how much good faith existed at the time.
Is there a meaningful difference between "ethical hacking" and "penetration testing" as terms, or are they interchangeable?
In practice they're used close to interchangeably, but "ethical hacking" is the broader umbrella term (covering pen testing, red teaming, bug bounty work, and vulnerability research generally under an authorized/ethical framing), while "penetration testing" specifically refers to the structured, scoped engagement methodology (PTES-style phases, a defined report deliverable) covered throughout this course. CEH (Certified Ethical Hacker) as a certification name reflects the broader umbrella term; OSCP (Offensive Security Certified Professional) reflects the more specific, hands-on pen testing skill set — worth knowing the distinction mainly because it explains why the two certifications test somewhat different things (CEH leans more theoretical/broad tool knowledge via multiple choice; OSCP is a live hands-on exam focused specifically on the pen testing methodology itself).