rtexit-method 0.1.0 → 0.1.1

package/packaged-assets/.agents/skills/rt-attack-surface-map/template.md

@@ -0,0 +1,62 @@
+# Attack Surface Map Template
+
+## Engagement
+
+| Field | Value |
+|---|---|
+| Client | [CLIENT] |
+| Reference | [REF] |
+| Date | [YYYY-MM-DD] |
+| Scope Source | SEAD / Scope document |
+
+## Executive Snapshot
+
+| Metric | Count | Notes |
+|---|---:|---|
+| Root domains | 0 | |
+| Subdomains | 0 | |
+| Live web apps | 0 | |
+| APIs | 0 | |
+| Exposed admin panels | 0 | |
+| Cloud assets | 0 | |
+| High-priority assets | 0 | |
+
+## Asset Inventory
+
+| Asset | Type | Exposure | Tech | Owner | Priority | Evidence |
+|---|---|---|---|---|---|---|
+| [asset] | web/api/cloud/network | internet/internal | [stack] | [owner] | H/M/L | [path] |
+
+## Attack Surface Categories
+
+### Web Applications
+
+| URL | Status | Auth Required | Technology | Notes |
+|---|---:|---|---|---|
+
+### APIs
+
+| Endpoint | Protocol | Auth | Documentation | Notes |
+|---|---|---|---|---|
+
+### Network Services
+
+| Host | Port | Service | Exposure | Risk |
+|---|---:|---|---|---|
+
+### Cloud Assets
+
+| Provider | Resource | Public? | Identity Risk | Notes |
+|---|---|---|---|---|
+
+## Priority Queue
+
+| Priority | Asset | Reason | Recommended Skill |
+|---:|---|---|---|
+| 1 | [asset] | [reason] | [rt-skill] |
+
+## Evidence Index
+
+| Evidence | Source | Hash | Notes |
+|---|---|---|---|
+

package/packaged-assets/.agents/skills/rt-autodoc/SKILL.md

@@ -0,0 +1,258 @@
+---
+name: rt-autodoc
+description: "Manual trigger for RTExit auto-documentation engine. Logs activities, commands, and findings to engagement timeline and evidence chain. Wraps autodoc_engine.py for skill-level integration. Use explicitly to log important activities not automatically captured. Creates SHA-256 hashed evidence entries."
+---
+
+# rt-autodoc Skill Guide
+
+## 1. Purpose and When to Use
+
+`rt-autodoc` is the manual documentation trigger for the RTExit auto-documentation engine. It ensures that significant activities, findings, commands, and decisions are captured in the engagement timeline and evidence chain even when automatic capture does not occur.
+
+### Primary purposes
+
+- Log discrete activities or findings that fall outside automated capture hooks
+- Commit SHA-256 hashed evidence entries to the immutable evidence chain
+- Maintain a coherent, auditable engagement timeline across all RTExit operations
+- Bridge gap when other skills produce outputs that must be formally recorded
+
+### When to invoke explicitly
+
+- After running discovery scans or recon commands manually in a terminal
+- When documenting analyst decisions or interpretation of ambiguous findings
+- To record out-of-band communications or observations (e.g., client call notes)
+- After importing external evidence files not produced by RTExit scripts
+- When a prior skill execution produced findings but autodoc hooks did not fire
+- To create checkpoint entries before and after high-risk or destructive actions
+- Any time you need a tamper-evident record of a specific moment in the engagement
+
+### When NOT to invoke
+
+- Routine script executions that already trigger autodoc hooks automatically
+- Duplicate logging of entries already present in the timeline
+- Administrative bookkeeping unrelated to the active engagement
+
+---
+
+## 2. Step-by-Step Workflow
+
+### Step 1 - Identify what to document
+
+Determine the category of the entry:
+
+- `activity` - general analyst action (e.g., started port scan)
+- `command` - specific command or tool invocation with its output
+- `finding` - discovered vulnerability, misconfiguration, or artifact
+- `decision` - analyst judgment or scope change
+- `evidence` - file, screenshot, or artifact to anchor in the chain
+
+### Step 2 - Gather required fields
+
+Collect the following before invoking:
+
+| Field | Description | Required |
+|---|---|---|
+| `category` | Entry type (activity, command, finding, decision, evidence) | Yes |
+| `title` | Short human-readable summary (max 120 chars) | Yes |
+| `detail` | Full description, command text, or finding narrative | Yes |
+| `severity` | info / low / medium / high / critical (findings only) | Conditional |
+| `artifact_path` | Absolute path to associated file or output | Optional |
+| `tags` | Comma-separated labels for later filtering | Optional |
+
+### Step 3 - Invoke the skill
+
+The skill wraps `autodoc_engine.py`. A typical invocation pattern:
+
+```
+rt-autodoc
+category: finding
+title: SMB signing disabled on 10.10.1.45
+detail: nmap --script smb-security-mode output confirms message_signing: disabled. Host is susceptible to relay attacks.
+severity: high
+tags: smb, relay, lateral-movement
+```
+
+### Step 4 - Engine processing
+
+`autodoc_engine.py` performs the following internally:
+
+1. Reads the active engagement context from the RTExit session state
+2. Stamps the entry with ISO-8601 UTC timestamp
+3. Generates SHA-256 hash of (timestamp + category + title + detail)
+4. Appends entry to `timeline.jsonl` in the engagement output directory
+5. Appends hash to `evidence_chain.log` with back-reference to the previous hash (chain linkage)
+6. Writes a human-readable summary line to `activity_log.txt`
+7. Returns the entry ID and hash for confirmation
+
+### Step 5 - Verify the entry
+
+After the skill returns, confirm the entry was recorded:
+
+```
+cat <engagement_dir>/evidence_chain.log | tail -5
+```
+
+The last line should contain the new hash and entry ID.
+
+---
+
+## 3. Integration with RTExit Scripts and Other Skills
+
+### autodoc_engine.py
+
+`rt-autodoc` is a skill-level wrapper around `autodoc_engine.py`. The engine exposes a CLI interface:
+
+```
+python autodoc_engine.py \
+  --category finding \
+  --title "SMB signing disabled" \
+  --detail "Full detail text here" \
+  --severity high \
+  --tags smb,relay
+```
+
+The skill handles argument marshalling, session context injection, and error reporting on top of this CLI.
+
+### Engagement session state
+
+The engine reads the active engagement from the RTExit session state file (typically `.rtexit_session.json` in the project root). This file must exist and contain a valid `engagement_id` before `rt-autodoc` can log entries. Use `rt-init` or `rt-session` to establish the session first.
+
+### Integration with other skills
+
+| Skill | Integration point |
+|---|---|
+| `rt-recon` | Call rt-autodoc after manual recon steps to capture findings not auto-logged |
+| `rt-exploit` | Log pre-exploitation decision entries and post-exploitation artifacts |
+| `rt-report` | Timeline and evidence chain produced by rt-autodoc feed directly into report generation |
+| `rt-evidence` | rt-autodoc creates evidence chain anchors; rt-evidence manages associated files |
+| `rt-session` | Provides session context that rt-autodoc reads to scope entries correctly |
+
+### File outputs
+
+| File | Purpose |
+|---|---|
+| `<engagement_dir>/timeline.jsonl` | Machine-readable JSONL timeline of all entries |
+| `<engagement_dir>/evidence_chain.log` | Append-only SHA-256 hash chain for tamper detection |
+| `<engagement_dir>/activity_log.txt` | Human-readable chronological activity summary |
+
+---
+
+## 4. Example Outputs and Interactions
+
+### Example 1 - Logging a command and its output
+
+**Input to skill:**
+
+```
+rt-autodoc
+category: command
+title: Ran nmap SYN scan against 10.10.1.0/24
+detail: Command: nmap -sS -p 22,80,443,445,3389 10.10.1.0/24 -oN nmap_syn.txt
+Result: 14 hosts up. Ports 445 and 3389 open on multiple hosts. Full output in nmap_syn.txt.
+artifact_path: /engagements/ENG-2026-001/evidence/nmap_syn.txt
+tags: nmap, portscan, smb, rdp
+```
+
+**Timeline entry written (timeline.jsonl):**
+
+```json
+{
+  "entry_id": "ae7f3c1b",
+  "timestamp": "2026-05-31T09:14:22Z",
+  "category": "command",
+  "title": "Ran nmap SYN scan against 10.10.1.0/24",
+  "detail": "Command: nmap -sS -p 22,80,443,445,3389 10.10.1.0/24 ...",
+  "artifact_path": "/engagements/ENG-2026-001/evidence/nmap_syn.txt",
+  "tags": ["nmap", "portscan", "smb", "rdp"],
+  "hash": "3a7f9bc2d4e1058fa6c3b7d92e4f1a0c8b5d3e7f9a2c4b6d8f0e2a4c6b8d0f2",
+  "prev_hash": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c"
+}
+```
+
+**Evidence chain append:**
+
+```
+2026-05-31T09:14:22Z | ae7f3c1b | 3a7f9bc2d4e1058fa6c3b7d92e4f1a0c8b5d3e7f9a2c4b6d8f0e2a4c6b8d0f2
+```
+
+### Example 2 - Logging a high-severity finding
+
+**Input:**
+
+```
+rt-autodoc
+category: finding
+title: Kerberoastable service account discovered - svc_sql
+detail: GetUserSPNs.py output identified svc_sql with SPN MSSQLSvc/db01.corp.local:1433. Account has no pre-auth requirement. Hash captured for offline cracking.
+severity: high
+tags: kerberoasting, active-directory, credential-access
+artifact_path: /engagements/ENG-2026-001/evidence/kerberoast_hashes.txt
+```
+
+**Skill response:**
+
+```
+[rt-autodoc] Entry logged successfully.
+  Entry ID : b3d9e2f1
+  Category : finding
+  Severity : high
+  Timestamp: 2026-05-31T11:03:45Z
+  Hash     : 8f2a1c3e5b7d9f1a3c5e7b9d1f3a5c7e9b1d3f5a7c9e1b3d5f7a9c1e3b5d7f9
+  Chain pos: 47 (prev: 9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0)
+```
+
+### Example 3 - Logging an analyst decision
+
+**Input:**
+
+```
+rt-autodoc
+category: decision
+title: Deferred exploitation of CVE-2024-1234 pending client approval
+detail: Discovered RCE vector on 10.10.1.20 (CVE-2024-1234). Risk of service disruption is high. Decision made to pause exploitation and notify client via secure channel before proceeding. Awaiting written go-ahead.
+tags: scope, client-communication, deferred
+```
+
+**Activity log line written:**
+
+```
+[2026-05-31 13:22:07 UTC] [decision] Deferred exploitation of CVE-2024-1234 pending client approval (entry: c1f4a8b2)
+```
+
+---
+
+## 5. Practical Usage Tips
+
+### Build a habit of pre/post entries for high-risk actions
+
+Before any destructive or high-impact action, log a `decision` entry stating intent. After the action, log a `command` or `finding` entry with the result. This creates a clear before-and-after bracket in the evidence chain.
+
+### Use tags consistently
+
+Establish a tag taxonomy at engagement start and stick to it. Consistent tags allow timeline filtering during report generation. Suggested base tags: `discovery`, `credential-access`, `lateral-movement`, `exfiltration`, `persistence`, `scope-change`.
+
+### Attach artifacts whenever possible
+
+If a tool produced a file, pass the path via `artifact_path`. The engine will record the file's SHA-256 hash alongside the entry hash, creating a two-layer integrity check on the evidence.
+
+### Chain entries for multi-step findings
+
+For findings that unfold across multiple steps (initial discovery, exploitation, impact demonstration), log a `finding` entry at each stage and use the same root tag to group them. The timeline JSONL can later be filtered by tag to reconstruct the kill chain.
+
+### Recovering from missed auto-capture
+
+If you realize several steps were not logged (e.g., you ran commands in a separate terminal), log them retroactively using the `detail` field to include approximate timing. The engine stamps entries with the actual invocation time, so note any time offset explicitly in the detail text.
+
+### Verify chain integrity periodically
+
+Run the RTExit chain integrity checker against `evidence_chain.log` at the end of each session to confirm no entries were altered or dropped:
+
+```
+python autodoc_engine.py --verify-chain <engagement_dir>/evidence_chain.log
+```
+
+A clean chain returns: `Chain integrity: OK - N entries verified`.
+
+### Do not edit timeline.jsonl or evidence_chain.log manually
+
+Manual edits break the hash chain and will cause integrity verification to fail. If an entry contains an error, log a corrective `decision` entry referencing the original entry ID rather than modifying the existing record.