Penetration Testing Methodology and Execution Questions

Approach summary
I explain how I manually detect blind SQLi, craft boolean- and time-based probes, tune payloads by DBMS, and responsibly demonstrate impact without destructive actions. I frame this from a penetration-testing / secure-assessment mindset.

Detection (no errors)

• Send baseline benign request and record response fingerprint (length, headers, content tokens).
• Inject simple tautology/contradiction and compare subtle differences (HTML length, JSON field values, redirects).
• Example probes:

' AND 1=1 -- 
' AND 1=2 -- 

• Use multiple locations (params, headers, cookies) and URL-encode where needed.

Boolean-based payloads

• Flip logic to observe true/false branch behavior; use EXISTS for read-only checks.

' AND (SELECT CASE WHEN (SUBSTRING((SELECT database()),1,1)='a') THEN 1 ELSE 0 END)=1 --

• Automate character-by-character extraction by iterating positions and comparing response fingerprint.

Time-based payloads

• Use DBMS sleep/delay functions when responses are identical:
  • MySQL: SLEEP(5)
  • MSSQL: WAITFOR DELAY '00:00:05'
  • PostgreSQL: pg_sleep(5)
  • Oracle: dbms_lock.sleep(5)

' AND IF(ASCII(SUBSTRING((SELECT user()),1,1))>100, SLEEP(5), 0) --

• Measure response time increases to infer true/false.

DBMS tuning

• MySQL: SLEEP(), BENCHMARK() for noisy environments.
• MSSQL: WAITFOR DELAY or heavy but safe functions (DATEADD).
• PostgreSQL: pg_sleep(); use CAST/TYPE differences.
• Oracle: dbms_lock.sleep(), use SELECT FROM dual.
• Adjust quoting, comment styles, and payload encoding per DBMS and application layer (ORMs, prepared statements).

Safe, non-destructive reporting

• Limit extraction: show existence or a single benign metadata value (current user or database name) rather than full dumps.
• Use short, minimal delays (2–5s) to prove time-based behavior without resource exhaustion.
• Prefer boolean existence checks over UNION/SELECT *; avoid data modification statements.
• Demonstrate PoC on a staging instance where possible; obtain written authorization.
• Provide remediation steps and example parameterized queries or ORM-safe patterns.

Example minimal proof-of-impact

• Confirmed: application returns different response when true vs false for an injected predicate (shows DB user). Include request/response diffs and short timing logs.

Situation (context)
During an authorized penetration test I discovered a previously unknown remote code execution vulnerability (zero-day) in a component we use. The same component is covered by an active third‑party bug‑bounty program whose disclosure rules differ from our contract.

Task (goal)
Protect the organization and users, avoid accidental weaponization or legal exposure, and coordinate disclosure so fixes occur promptly while respecting the bounty program and any contractual/legal constraints.

Actions (steped approach)

• Immediate risk control: paused any exploit development that would increase exposure, preserved logs and reproducible PoC under strict access control, and stopped automated scans that might be noisy. Principle: avoid expanding the blast radius.
• Legal & leadership: notified the engagement owner, CISO and corporate counsel within 24 hours with a factual incident brief (scope, reproducible steps, risk impact). Requested legal guidance on contractual limits and nondisclosure obligations.
• Triage & severity: performed impact analysis (exploitability, affected assets, exposure) and assigned CVSS-style urgency to inform timelines.
• Coordinate with bug‑bounty/vendor teams: reviewed the third‑party program’s policy and vendor disclosure SLA. If the bounty’s public disclosure rules conflict with our contractual NDA or incident-handling policy, worked with counsel to request a temporary embargo or coordinated disclosure through the vendor/platform (e.g., private report with “do not disclose” until patch).
• Disclosure timeline & process: proposed a staged timeline — immediate private notification to vendor/platform and legal, remediation window agreed (e.g., 30/60 days depending on severity), weekly status updates, and public disclosure only after fix or agreed deadline. Documented all communications and decisions.
• Decision transparency: convened a short cross-functional meeting (security, legal, engineering, product, and program owner) to approve the plan; captured rationale, risks, and mitigation steps in a decision memo. If pausing testing or withholding PoC was required, recorded legal guidance and approvals.

Result & learnings
This approach balanced rapid remediation with legal/ethical obligations: we limited weaponization risk, adhered to contractual NDAs, and coordinated with the bounty/vendor to produce a patch before public disclosure. Lessons: codify escalation and embargo workflows in engagement contracts, include explicit clauses about overlapping external programs, and maintain a runbook for zero‑days discovered during assessments.

Ethical principles applied

• Do no harm: minimize exploitation and exposure
• Duty to protect users and assets over public curiosity or reputation
• Transparency with internal stakeholders and affected vendors, documented and legally reviewed decisions

Executive report (CISO / Board)

• Tone: concise, business-risk focused, non-technical.
• Structure:
  1. Executive summary (one paragraph: scope, date, high-level risk posture).
  2. Key findings (top 3–5 risks ranked by business impact / likelihood).
  3. KPIs & metrics: % high/critical findings, mean time-to-remediate (MTTR) target, % systems tested, residual risk score.
  4. Impact scenarios (financial, regulatory, reputational) and recommended priority actions with estimated effort/cost.
  5. Visuals: heatmap (impact vs likelihood), trend chart, remediation roadmap timeline.
  6. Decision asks: approvals, budget, executive owners.

Developer report (Application teams)

• Tone: technical, actionable, collaborative.
• Structure:
  1. Scope and environment details.
  2. Findings list: vulnerability title, severity, reproducible steps, PoC, affected components, exploitability.
  3. Remediation guidance: code snippets, config changes, CVE references, test cases.
  4. KPIs: number of open issues per component, SLA for fixes, verification checklist.
  5. Visuals: call graphs, sequence diagram, annotated logs.
  6. Appendix: full scan output, exploit scripts, raw logs.

Balancing urgency & clarity

• Use tiering: mark Critical = stop-the-line, High = <2 weeks, Medium/Low = scheduled sprints.
• For executives, translate technical risk into business impact and clear asks.
• For devs, supply exact repros and unit/integration tests to reduce friction.
• Communicate via a follow-up triage workshop: align owners, set deadlines, assign verification steps; provide automated retest pipeline to measure progress.

Approach summary
Start by treating the API as a state machine; fuzzing must exercise state transitions, authenticated flows, and abuse rate limits. Combine targeted mutation fuzzing for business logic with generational fuzzing for schema-driven inputs.

Selecting targets/endpoints

• Prioritize privileged and stateful endpoints: login, token refresh, purchase/checkout, user-settings, webhooks.
• Map flows: auth -> create -> update -> delete. Build sequences that cross services (e.g., create order then refund).
• Add high-risk parameters (IDs, enums, JSON arrays, timestamps).

Generational vs Mutation

• Use generational (schema-aware) for structured JSON to maintain valid shapes and reach deeper logic.
• Use mutation for fuzzing edge cases and catching deserialization bugs.
• Orchestrate hybrid: gen to create valid sequences, mutation to corrupt intermediate messages.

Auth/session management

• Implement harness that automates OAuth/JWT flows, refresh tokens, and session cookies.
• Reproduce realistic user roles and scopes; rotate tokens to bypass caching.
• Maintain per-fuzzer credential pools and rate-limit-aware pacing; backoff and resume to avoid bans.

Handling rate-limiting

• Detect 429 responses; implement token rotation, multiple client IPs (via proxies), and exponential backoff.
• Measure effective request budget per token and distribute workload across credentials.

Measuring coverage

• Instrument server with code-coverage (if whitebox) or use API-side telemetry: unique endpoints hit, branch hits, response-code diversity, and state transitions exercised.
• Correlate fuzzer inputs to trace IDs or request IDs to map coverage to code paths.

Detecting crashes and logical failures

• Crash detection: monitor HTTP 5xx, service restarts, core dumps, sanitizer logs, and elevated error rates.
• Logical failures: assert business invariants post-sequence (e.g., balance >= 0, order status transitions). Implement oracle checks via golden-state or shadow copies (read DB snapshots).
• Use anomaly detection on responses (schema violations, auth bypasses, unexpected state).

Metrics & tooling

• Track inputs/sec, unique coverage per hour, unique crashes, logical failures, and repro rate.
• Use Burp/Boofuzz/fuzzilli for mutation; create custom harness in Python using requests + asyncio; integrate with CI and crash triage (minimizers, replay).

Reasoning: schema-aware generation reaches deep logic; mutation finds parsing bugs. Managing auth and rate limits preserves access to stateful flows. Instrumentation and oracles turn crashes and subtle business-logic violations into actionable findings.

Approach summary (safe, non-destructive)

• Get written authorization, scope, and a test window. Work on staging where possible. Treat production as if sensitive — avoid data exfiltration.
• Demonstrate SSRF by proving access to an internal metadata endpoint with minimal, non-destructive indicators (status codes, short trimmed responses, response headers, lengths) rather than retrieving secrets.

Safe testing constraints

• Only query read-only, low-sensitivity paths (e.g., top-level /latest/meta-data/), do not request tokens, credentials, or user-data.
• Rate-limit: 1 request/second max; cap total requests (e.g., 20).
• Use timeouts (5s) and single-connection concurrency.
• Ensure requests include a unique test identifier in headers or query (for correlation) that doesn’t leak sensitive info.

Non-destructive verification techniques

• Expectable signals: HTTP 200 or 403 from metadata IPs (e.g., 169.254.169.254), specific server headers, or predictable path names (e.g., "ami-id") — capture only names/lengths.
• Record response code, content-length, and first N bytes (e.g., 64 bytes), then discard body. Avoid storing or printing sensitive content.
• Use checksum/hash (SHA256) of response body to prove access without storing plaintext.

Logs & telemetry to collect

• Request timestamp, source IP, target URL, method, headers, response status, content-length, response hash, correlation ID.
• Application logs, proxy/WAF logs, host firewall logs, and IDS alerts.
• Include Burp/mitm proxy capture (sanitized), and cloud audit logs if available.

Reproduce safely in local lab

• Create a local metadata mock (e.g., simple HTTP server listening on 169.254.169.254 via Docker with --add-host or network alias). Example:

# run a small metadata mock container
docker run --rm -p 127.0.0.1:8000:80 --name md-mock nginx
# or run a tiny Python server
docker run --rm -p 8000:8000 python:3 sh -c "python -m http.server 8000"

• Configure the target application in a sandbox to accept URLs from attacker-controlled input and point to the mock IP.
• Use Burp / curl to reproduce SSRF against the mock, capture full safe logs and response hashes.

Reproduction report contents

• Scope & authorization, exact payloads used, rate limits applied, timestamps, captured logs, sanitized response hashes, remediation recommendations (input validation, allowlist, egress filtering, metadata protection like IMDSv2).