Penetration Testing vs. Vulnerability Scanning
| Property | Vulnerability Scanning | Penetration Testing |
|---|---|---|
| What it does | Identifies potential weaknesses; checks for conditions that could be exploited | Actively exploits confirmed vulnerabilities; demonstrates real-world impact |
| Exploitation | None — no attacks are performed | Yes — actual exploitation techniques are attempted |
| Operational risk | Minimal; production-safe in most cases | Real risk of service disruption; exploits can crash systems |
| Invasiveness | Minimally invasive | Intentionally invasive — simulates full attacker behavior |
| What it confirms | "This version has a known vulnerability" | "This vulnerability is exploitable in this environment and here is the impact" |
| Required authorization | Scope defined; rules less formal | Formal rules of engagement required before any testing; legal authorization essential |
| Frequency | Continuous or frequent (weekly, monthly) | Periodic (annual, after major changes, or as mandated) |
Rules of Engagement — Required Elements
| Element | What It Defines | Why It Is Required |
|---|---|---|
| Type of testing | External (from internet), internal (from inside network), physical (breach physical security), social engineering | Different test types carry different risk profiles; testers need to know which techniques are authorized |
| Permitted timing | Hours during which testing is allowed (e.g., after 6 PM only, weekends only) | Protects business operations from disruption; testing during peak hours risks impacting users |
| In-scope systems | Specific IP ranges, domains, or applications the tester may probe and attack | Defines what the tester is authorized to touch; anything not in scope is off-limits |
| Out-of-scope systems | Explicitly excluded systems that must not be tested, even if discovered as part of the engagement | Protects production-critical systems, third-party infrastructure, and shared systems from unauthorized testing |
| Emergency contacts | Named contacts for both the testing team and the organization with 24/7 availability | Enables immediate testing halt if a system becomes critical or a real incident occurs during the test window |
| Sensitive data handling | Procedures for storing, protecting, and destroying sensitive data discovered during the engagement | Sensitive data found during a pen test is real data; mishandling creates real liability |
The Four Penetration Testing Phases
| Phase | Goal | Common Techniques | What It Reveals |
|---|---|---|---|
| 1. Initial exploitation | Gain the first foothold inside the target environment | Buffer overflow, SQL injection, phishing, credential brute force, physical tailgating, social engineering | Weaknesses in perimeter security; whether external defenses can be bypassed |
| 2. Lateral movement | Expand access from the initial foothold to additional internal systems | Pass-the-hash, credential theft from memory, shared folder exploitation, remote management protocol abuse (RDP, WinRM) | Inadequate internal segmentation; excessive internal trust; lack of internal monitoring |
| 3. Persistence | Ensure continued access even if the original vulnerability is patched or session detected | Unauthorized account creation, backdoor installation, default password changes, scheduled task modification, startup service modification | Gaps in change monitoring; unauthorized account detection; log review adequacy |
| 4. The pivot | Use a compromised system as a proxy to reach otherwise-inaccessible network segments | Port forwarding through compromised host, SOCKS proxying, exploiting trusted connections between systems (database connections, API calls) | Over-permissive network trust relationships; segmentation that exists on paper but not in practice; excessive service permissions |
Persistence Techniques — Types and Detection
| Technique | How It Works | Detection Method |
|---|---|---|
| Unauthorized account creation | Attacker creates new administrative user accounts on compromised systems | Monitor for new account creation events; audit account lists against baseline; alert on unexpected admin group membership changes |
| Default password modification | Attacker changes or verifies default service/application account passwords to known values they control | Audit service account credentials against policy; monitor for password change events on service accounts |
| Backdoor installation | Remote access tool (RAT) installed that beacons to attacker C2 on schedule or on startup | Endpoint detection for unknown processes; network monitoring for unusual outbound connections; file integrity monitoring |
| Startup service modification | Malicious code added to startup services, scheduled tasks, or boot scripts to execute on every restart | Monitor startup service changes; scheduled task creation/modification events; application whitelisting to block unauthorized executables |
| Web shell installation | Script file placed in web server directory that provides remote command execution through HTTP requests | File integrity monitoring on web directories; unusual web server process activity; HTTP request pattern analysis |
Responsible Disclosure — Four-Step Sequence
| Step | Who Acts | What Happens | Timing |
|---|---|---|---|
| 1. Private report | Researcher | Reports vulnerability details privately to the vendor through a security disclosure channel or bug bounty platform; no public disclosure; provides reproduction steps and severity assessment | Immediately upon discovery |
| 2. Vendor investigates and fixes | Vendor / manufacturer | Reproduces the issue, identifies root cause, develops and tests a patch, prepares deployment; may consult researcher for clarification | Typically 90 days (industry norm); may be faster for critical issues |
| 3. Patch deployed | Vendor | Distributes patched software version to users; coordinates release timing | End of remediation window |
| 4. Public disclosure | Vendor + Researcher | Vulnerability details and CVE published simultaneously with patch availability; researcher credited; users can protect themselves immediately upon learning of the risk | Simultaneous with or after patch deployment |
Bug Bounty Programs — How They Work
| Element | Details |
|---|---|
| Who runs them | Software vendors and major technology companies (Google, Microsoft, Meta, Apple); some government agencies and financial institutions |
| Who participates | Independent security researchers, ethical hackers, students, professional penetration testers — anyone authorized by the program rules |
| What qualifies for a bounty | Valid vulnerabilities within the defined scope; must include reproduction steps, impact demonstration, and severity assessment; must be privately reported before any public disclosure |
| Reward structure | Tiered by severity: Critical vulnerabilities may earn $10,000–$1,000,000+; High may earn $1,000–$50,000; lower severity findings earn proportionally less or nothing |
| Researcher obligations | Test only in scope; do not exploit beyond proof of concept; report privately; do not disclose to third parties; do not access or exfiltrate data beyond what is needed to demonstrate the vulnerability |
| Benefit to vendor | Access to global security research community that exceeds internal testing capacity; cost-effective security testing; improved product security |