Ethical, legal, and operational framework

Offensive security as a discipline of responsibility

An offensive security framework is not merely a set of technical functions. It is an amplifier: it accelerates reconnaissance, standardizes modules, facilitates test repetition, and can automate decisions. This power demands strict operational hygiene.

Before any campaign, the operator must be able to answer the following questions clearly:

• What is the exact authorized perimeter (IP, FQDN, applications, exclusions)?
• Which actions are forbidden, even if a vulnerability makes them possible?
• Which time windows and rate limits must be respected?
• How will evidence be collected, protected, and returned?
• Who must be contacted in case of unexpected impact (incident)?
• What log and capture retention period is acceptable for the client and compliant with applicable law?

From technical capability to mandate

KittySploit can help explore a system, detect services, execute modules, manage sessions, compile or select payloads, automate hypotheses via the agent, and produce traces (history, campaign artifacts). The mandate, however, determines what is permitted. A capability present in the tool is never implicit authorization to use it.

Legal framework --- overview (France and EU)

This chapter does not replace legal advice. It situates penetration testing practice within the texts French-speaking auditors encounter most often.

Penetration testing and authorization

In France, fraudulent access to an automated data processing system is punishable (relevant articles of the penal code on fraudulent access and maintenance). The engagement letter, purchase order, or framework contract with a penetration testing clause forms the basis of your defense in case of dispute: perimeter, dates, contacts, limits.

GDPR and personal data

The General Data Protection Regulation (GDPR) applies whenever you process personal data --- which frequently occurs in penetration testing (user databases, application logs, proxy captures, partial SQL dumps).

• Legal basis: the test is generally based on the data controller's legitimate interest or on execution of the audit contract; verify with the client (DPO).
• Minimization: collect only necessary evidence. A masked hash or a line excerpt is often sufficient; avoid full exports of users tables.
• Retention period: define in the mandate the retention duration of reports, KittyProxy captures, and workspaces; destroy or return after retest.
• Subprocessing: if you are a service provider, the contract must cover data processing (GDPR Article 28) and transfers outside the EU where applicable.
• Notification: accidental data leakage during the audit may trigger a notification obligation; plan the procedure with the client.

Other useful frameworks

Rules of Engagement (ROE) --- template

Rules of Engagement translate the contract into operational instructions for the offensive team. KittySploit allows reflecting them technically via scope, host, and agent profiles (--safety-profile, --approve-risk).

Typical ROE document structure

1. Identification: client, service provider, dates, document version.
2. Perimeter: authorized assets (IP/URL table), excluded environments (payment production, third parties).
3. Authorized / forbidden techniques: active exploitation, phishing, DoS, data modification, persistence.
4. Time windows: test slots, time zone, excluded days.
5. Rate limits: max threads, agent --request-budget, no destructive scanning.
6. Contact points: client project manager, SOC on-call, incident escalation.
7. Evidence and storage: format, encryption, duration, location (EU).
8. Stop criteria: major compromise, service instability, client request.

Example perimeter table (fictional excerpt)

+-------------+------------------+----------+------------------+
| Actif       | URL / IP         | Autorise | Notes            |
+-------------+------------------+----------+------------------+
| Web app     | https://app.test  | YES      | Exclude /admin prod |
| API         | api.isolated test environment:443      | YES      | Rate limit 10/s  |
| Legacy      | 10.0.0.99        | NON      | Exclu contrat    |
| DVWA local  | 127.0.0.1        | YES      | Isolated test environment formation    |
+-------------+------------------+----------+------------------+

In KittySploit, reflect the authorized rows:

workspace create client-acme-2026
workspace use client-acme-2026
scope add app.isolated test environment api.isolated test environment
scope add 127.0.0.1 --note "isolated test environment, internal only"

Technique / risk matrix

Incident management during an audit

An authorized test can trigger a real incident: disk saturation, service crash, SOC alert triggering, accidental leakage of test data to a third-party logging system.

Five-step procedure

1. Immediate stop: stop the module or jobs -k, close test sessions (sessions -k).
2. Notification: contact the ROE point within contractual deadlines (often < 1 hour for service impact).
3. Preservation: export history, timestamp, workspace ID; do not destroy logs --- they serve post-mortem analysis.
4. Containment: help the client isolate the asset if necessary (outside mandate unless incident assistance clause).
5. Written report: timeline, KittySploit commands, modules used, data touched, proposed corrective measures.

# Operational emergency
jobs -l
jobs -k <job_id>
sessions -l
sessions -k <session_id>
history

Communication

Avoid unnecessary jargon with the client SOC. Provide: UTC time, auditor source IP, target, KittySploit module, intention (SQLi validation workflow), observed impact. Propose a retest window after stabilization.

Logging, traceability, and evidence

Audit credibility rests on reproducible evidence and a clear chain of custody.

KittySploit log sources

• history: commands from the current console session.
• Workspace: recorded hosts, services, vulns (vuln list, host services).
• Agent artifacts: agent explain <run_id>, reports under artifacts/.
• campaign: graph, executable plan, report.md.
• KittyProxy: captured traffic for web scenarios.
• lab score: automatic validation of local objectives.

Logging best practices

1. Timestamping: note UTC time in your reports; Docker isolated test environments can be replayed weeks later.
2. Correlation ID: keep the agent run_id and workspace name in every report finding.
3. Integrity: store exports on an encrypted volume; SHA-256 checksum for sensitive reports if the client requires it.
4. Separation: one workspace per mission; no mixing client A / client B.
5. Retention: policy aligned with GDPR and contract (often 6--12 months then destruction).

# Minimal evidence block for a report
Workspace : dvwa-recon
Module    : auxiliary/.../sqli
Target    : http://127.0.0.1/vulnerabilities/sqli/?id=1'
Proof     : response containing "First name: admin"
Timestamp : 2026-06-26T14:32:00Z

Documentation writing rules

This documentation adopts three principles:

1. Explain concepts and architectures with precision.
2. Reserve offensive operations for isolated test environment environments or explicitly described mandates.
3. Prefer reproducible and defensive reference tasks over decontextualized recipes.

This approach makes the documentation useful for learning, auditing, and developing, while keeping documentation compatible with responsible professional practice.

KittySploit usage charter

On first launch of python kittyconsole.py, the framework may display a usage charter. Accept it only if you commit to respecting the rules above.

Links to the rest of the documentation

• Methodology: PTES alignment and phase-to-command mapping.
• Scope management: authorized targets and campaign hygiene.
• Agent policies: profiles and --approve-risk levels.
• Reporting: retest notes aligned with client and GDPR expectations.