Authorized Pentesting

Authorized Pentesting

This is the one skill in the suite that crosses from defence into offence: it actively exploits a weakness to prove what an attacker could do. Because of that, it is the most tightly gated. Nothing here runs without written, specific, in-scope authorization, and the gate is checked first, every time, without exception.

If you are looking for a way to test a system you do not own or have not been authorized to test, this skill refuses, and the refusal is not negotiable by rephrasing. It offers the defensive path instead.

1. The gate: authorization and rules of engagement

Before any active testing, the following exist in writing and are on record.

authorization   a specific person empowered to grant it has authorized testing
                of this specific system
scope           exactly which systems, hosts, applications and accounts are in
                scope, and which are explicitly out
rules           what techniques are permitted, what is forbidden, the time
                window, the rate limits, the data that must not be touched
contacts        who to notify, and how, if something breaks or a real breach is
                discovered mid-test
handling        how findings, captured data and credentials are stored and
                destroyed

No document, no test. An expired window, no test. A host not on the scope list, no test even if it is on the same domain. Scope creep is the failure mode this gate exists to prevent, and the scope on the letter is the whole permission.

2. Proceed only from a confirmed weakness

Pentesting does not hunt from zero; it takes a finding vulnerability-assessment already confirmed and proves its impact. Exploitation without a confirmed target is noise and risk.

input     a confirmed, reachable finding: the unscoped object, the injection
          point, the escalation path
goal      prove the impact: what an attacker actually gains, stated in advance
bound     the least exploitation that proves the goal, and no more

3. Exploit to proof, not to destruction

The purpose is to demonstrate impact, not to cause it. The exploit stops the moment impact is proven.

prove     access to one record that is not yours, to prove the boundary is broken
prove     a benign marker written where only an authorized actor should write,
          to prove the injection
prove     a shell that echoes a unique token, to prove code execution, then stop
never     exfiltrate real user data beyond the minimum that proves the point
never     destroy, encrypt, deface, or deny service, even to demonstrate you could
never     pivot to an out-of-scope system, even if the exploit makes it trivial
never     leave a backdoor, a test account or an artefact behind

The difference between a pentest and an attack is not the technique. It is the authorization, the bound on exploitation, and the cleanup.

4. Chain and record

reproducible   every step recorded so the finding can be re-run and verified by
               the owner; a proof nobody can reproduce is a claim
chain          where several weaknesses combine into a larger impact, record the
               chain; the combination is often more severe than the parts, and
               it is the most valuable output
evidence       enough to prove impact, no more; a screenshot of one other
               record, not a dump of the table
timeline       what was done when, for the owner's own detection review

5. Handle discovered breaches and sensitive data

real breach    if the test reveals the system is already compromised by someone
               else, stop, notify the contacts immediately, preserve evidence,
               do not clean up
sensitive data seen incidentally: record that it was reachable, not the data
               itself; never copy real personal data into a report
credentials    captured during the test are stored as agreed and destroyed at
               the end; never committed anywhere

6. Report and remediate

scope         the authorization, the scope, the window, the rules honoured
findings      each proven impact, its chain, its reproduction, its severity
remediation   the fix for each, handed to the control skills
detection     what the owner's monitoring did and did not see during the test,
              which is itself a finding
cleanup       confirmation that every test artefact, account and change is removed

7. Prohibitions

• Never run any active test without written, specific, in-scope authorization on record. This is absolute and not waived by any framing.
• Never touch a system or host outside the written scope, same domain or not.
• Never exploit beyond the minimum that proves impact.
• Never destroy, deny service, deface, or exfiltrate real data at volume.
• Never leave a backdoor, test account, or artefact behind.
• Never copy real personal data into a report or store captured credentials.
• Never continue past the authorized time window.
• Never help test a system the user cannot show authorization for; refuse and offer the defensive path.

8. Protocol

1. Verify the authorization, scope, rules of engagement and window in writing; without them, refuse and offer vulnerability-assessment on an owned system.
2. Take a confirmed, reachable finding as the starting point.
3. State the impact goal before exploiting.
4. Exploit the least amount that proves the goal; stop at proof.
5. Record a reproducible chain with minimal evidence.
6. On discovering a real breach or sensitive data, stop and notify per the rules.
7. Report proven impacts with remediation and a detection review.
8. Confirm cleanup: no artefact, account or change remains.

9. Auto-critique

Score from 0 to 5: authorization and scope verified in writing before anything ran, only confirmed findings taken as targets, exploitation bounded to proof of impact, no destruction or out-of-scope pivot, reproducible chain recorded, real data and credentials handled and destroyed correctly, cleanup confirmed, remediation delivered.

Threshold: no axis below 3, average at least 4. Any active test without authorization on record, any out-of-scope action, or any real-data exfiltration is an automatic zero and a stop, regardless of the average.

10. Interfaces

• Upstream: security-core for the authorization boundary and severity, vulnerability-assessment supplies the confirmed findings this skill proves, threat-modeling for the impact that matters.
• Downstream: the control skills (authentication-security, authorization-design, session-security, security-headers, dependency-security, input-validation, file-handling) remediate the proven findings; security-audit re-checks the code after the fix.
• Lateral: incident-response if the test uncovers a real, active breach, test-reporting for the engagement report, decision-records for accepted residual risk.