Hack

HACKING SKILLS / HackSkills

Overview

This is the master quality gate and technical router for authorized bug bounty, web/API security, pentest, code audit, source-leak work, and (when the task is blue) SOC / detection / IR.

It does not replace specialized techniques. It makes the agent:

1. Pass the start gate (authorization, role, scope, success definition)
2. Spend effort on paths that reach real control
3. Route by observed behavior to the correct category / deep topic skill
4. Prefer structured methodology over baseline-model memory and scanner dumps

This file is a quality gate, not a capability ceiling. Surfaces not listed here stay in play if field evidence exists.

This file is not an exploit cookbook. Weaponized details live in deep topic skills and are used only on authorized targets.

Load on demand:

• Red-team execution → RED_TEAM.md
• Test matrix and effort → TEST_MATRIX.md
• Blue-team execution → BLUE_TEAM.md
• Code audit → CODE_AUDIT.md
• Source leak → SOURCE_LEAK.md
• Evidence and report → EVIDENCE_REPORT.md

0. Task Start Gate

Complete in order. Stop if any item is missing:

1. Authorization: written auth, RoE, scope, prohibitions, contact, emergency stop. No authorization → refuse.
2. Role: red-team test / code audit / source leak / middleware audit / blue triage / detection engineering / IR. Parallel work is allowed; there is only one primary role.
3. Scope mode:

• User gave a fixed URL / system / repo → locked scope: follow same-product hosts, gateways, API domains, and same-host extra paths that the business flow naturally exposes. Do not scan unrelated brand lines.
• User gave an org name and asked to find boundary assets → exploratory scope: finish the current asset cluster before opening the next. Do not search many seeds shallowly.

1. Success definition: what "done" means for this task. Scanner-finished, report-emitted, and ticket-closed are not success.
2. Destruction boundary: list actions that must never happen.
3. Working directory before any test: assets/ (URLs, API inventory, script excerpts), evidence/ (requests, diffs, screenshots), reports/ (confirmed findings only).
4. Questions: if scope is unclear, ask only the 1–3 technical blockers (target, stack, whether an account exists). Do not use "should I continue" as a way to stop. Missing a second account → degrade to what is testable; do not idle waiting for account B.

Do not expand onto unauthorized assets.

1. Hard Constraints

• Stay in scope. Out-of-scope clues: record, then request expansion. No silent expansion.
• No destructive testing or destructive containment: delete other people's business data, DROP/TRUNCATE, bulk config change, encrypt/ransom-like actions, unbounded DoS, wipe logs, wipe images.
• Write-ops that prove access: create only identifiable test objects, delete that one object immediately. Do not change other people's orders, addresses, passwords, roles, or bindings. No charge, stock wipe, or account lock.
• Do not log out, revoke, or deactivate a session the user provided. If password/binding change is required to prove impact, revert immediately; if revert fails, stop at the response — do not brick the account.
• Do not cause irreversible damage to prove a break. Prefer read-only, copy, or low-privilege proof.
• Evidence must be readable and reproducible. A conclusion without repro steps is a hypothesis.
• Do not fabricate PoCs, logs, or exploit chains. If path, file, query, and screenshot do not line up, downgrade or withdraw.
• Copied secrets are clues until they pass the liveness gate: production accepts the real value (rejects a fake), and one read-only call returns identity or an object list.
• A finding reached with a session is not "anonymous unauthorized". Anonymous only if the break had no login state.
• For internal users, assume false positive or mistake until the timeline proves otherwise.
• If a security control blocks real work, it will be bypassed. Remediation must include a usable safe path.

2. Role Routing

When a task crosses red and blue, freeze evidence for the current phase before switching role.

3. Operating Model

Step 1: Draw the surface from the application

With a URL or an application in hand, map the surface first: attack-surface-mapping. Portrait, business plane, JS/traffic inventory (keys not just paths), response classes, object graph. Do not scan into a blank portrait. Do not open with directory brute or payload spray.

Step 2: Route by observed behavior