Penetration testing methodology and KittySploit mapping

Phases of a penetration test

A professional penetration test is not a random sequence of scans. It follows a documented cycle, negotiated with the client and traced in the KittySploit workspace.

Phase 0 --- Preparation and mandate

Before opening the console:

Engagement letter or contract defining the perimeter (IP, domains, exclusions).
Time window and emergency contacts.
Rules of engagement: authorized exploitation or passive black-box only.
Definition of expected reports and retest workflow.

In KittySploit: workspace create, scope add, notes in the workspace.

Phase 1 --- Reconnaissance

Objective: understand the attack surface without modifying the target's state.

Web fingerprinting	`scanner -u URL`, `scanner/http/*_detect` modules
Passive discovery	`search`, `inventory`, manual analysis
Traffic capture	`proxy start`, application browsing

Phase 2 --- Analysis and prioritization

Transform observations into vulnerability hypotheses ranked by impact and likelihood. Do not confuse ``exposed service'' with ``exploitable vulnerability''.

Group scanner findings by severity.
Manually validate HIGH alerts before exploitation.
Record host and vuln to feed campaign.

Phase 3 --- Controlled exploitation

Vulnerability validation within the mandate. Every intrusive action must be justifiable and reversible where possible.

check before run when the module allows it.
Explicit --approve-risk for the agent.
Documented sessions (sessions -l, timestamp, source module).

Phase 4 --- Post-exploitation (if authorized)

Collect impact evidence, lateral movement in the isolated test environment, demonstrate business risk without unnecessary exfiltration.

post/ modules, SOCKS pivot, route, internal enumeration.

Phase 5 --- Reporting and retest

campaign --formats report,navigator,timeline
attack export for the MITRE matrix.
agent retest after client remediation.

OWASP Web Security Testing Guide and KittySploit

The WSTG structures web tests into categories. Here is how to cover them with the framework (without listing every module: use search with the WSTG keyword).

WSTG	Theme	KittySploit approach
WSTG-CONF	Configuration	`security_headers_detect`, `exposed_env_detect`
WSTG-IDNT	Identity management	Auth modules, agent `--goal obtain-auth`
WSTG-ATHN	Authentication	Bruteforce in isolated test environment, reset password modules
WSTG-ATHZ	Authorization	Manual IDOR + agent HTTP replay
WSTG-SESS	Sessions	Cookie analysis via KittyProxy
WSTG-INPV	Input validation	SQLi, XSS, upload --- DVWA / WebGoat
WSTG-ERR	Error handling	`django_debug_detect`, stack traces
WSTG-CRYP	Cryptography	TLS analysis, certificates
WSTG-BUSL	Business logic	Proxy + manual tests, agent reasoning
WSTG-CLNT	Client side	`browser_server`, browser modules

Engagement models

Black box

No internal information. KittySploit starts from the public URL or IP. agent <target> --goal recon --safety-profile discreet.

Gray box

Test accounts provided. Configure username/password options on modules and --reuse-proxy-auth after manual login.

White box

Access to code or architecture. Combine internal module inventory, code review, and validation scans (--goal detection-validation).

Effort / tool matrix

Phase	Manual	`scanner`	`agent`
CVE validation	Required	Useful	Optional with approval
Full local validation chain	Required	Useful	Useful with bounded scope
ATT&CK report	Required review	Not applicable	Useful draft input

Logging and traceability

Every action must be reproducible by a third party (auditor, client, team):

history
workspace save

Keep: workspace identifier, KittySploit version (banner), date, scope perimeter, list of executed modules with non-sensitive options.

Anti-patterns to avoid

Running scanner --auto-exploit on production without explicit mandate.
Ignoring mass scan false positives.
Mixing client workspace and personal isolated test environment.
Storing client passwords in plaintext in shell history.
Confusing module coverage with test quality.