rtexit-method 0.1.0 → 0.1.2

package/packaged-assets/.agents/skills/rt-technical-report/template.md

@@ -0,0 +1,41 @@
+# Technical Report Template
+
+## Document Control
+
+| Field | Value |
+|---|---|
+| Engagement Ref | [REF] |
+| Client | [CLIENT] |
+| Methodology | [METHODOLOGY] |
+| Report Date | [DATE] |
+
+## Scope and Constraints
+
+[Approved assets, exclusions, accounts, testing windows, and constraints.]
+
+## Methodology
+
+[Planning, reconnaissance, validation, post-exploitation impact analysis, reporting.]
+
+## Findings Summary
+
+| ID | Title | Severity | CVSS | Asset | Status |
+|---|---|---|---:|---|---|
+
+## Detailed Findings
+
+Include each finding from `_rtexit-output/docs/findings/`.
+
+## Attack Chains
+
+| Chain | Findings | Objective | Business Impact |
+|---|---|---|---|
+
+## Appendices
+
+- Evidence index
+- Chain of custody
+- CVSS vectors
+- MITRE mapping
+- Tool output references
+

package/packaged-assets/.agents/skills/rt-technical-report/workflow.md

@@ -0,0 +1,68 @@
+# Workflow - rt-technical-report
+
+## Purpose
+
+This workflow standardizes how $skill is executed inside RTExit. It is designed for authorized engagements, evidence-first documentation, and consistent handoff into reporting.
+
+## Authorization Gate
+
+Before execution, confirm:
+
+- SEAD exists and explicitly covers the target asset or activity.
+- Rules of Engagement define allowed techniques, rate limits, and stop conditions.
+- The operator knows the evidence handling rules.
+- Any active or sensitive validation has client approval.
+
+If any item is unclear, pause and invoke 
+
+## Required Inputs
+
+| Input | Source | Notes |
+|---|---|---|
+| Engagement reference | _rtexit/config.toml or SEAD | Used in output names. |
+| Target asset(s) | Scope document | Must be explicitly approved. |
+| Operator name | Config/user context | Used in timeline entries. |
+| Evidence directory | _rtexit-output/docs/evidence/ | Store logs, screenshots, and artifacts. |
+| Finding tracker | _rtexit-output/docs/findings/ | Create/update findings when confirmed. |
+
+## Execution Steps
+
+1. Load current engagement configuration.
+2. Read scope, exclusions, and current findings.
+3. Build a small test plan for this skill with target, expected control, and evidence type.
+4. Run the lowest-risk validation first.
+5. Capture baseline behavior before proof behavior.
+6. Record exact timestamp, account/role used, and affected asset.
+7. Stop when evidence is sufficient; avoid unnecessary data access.
+8. Create or update findings through the RTExit finding tracker.
+9. Map remediation owner and recommended timeline.
+10. Add a timeline entry and evidence chain entry.
+
+## Evidence Requirements
+
+| Evidence | Required? | Notes |
+|---|---|---|
+| Command or action summary | Yes | Redact secrets and tokens. |
+| Screenshot or transcript | If useful | Store under evidence folder. |
+| Request/response pair | For web/API | Redact cookies and bearer tokens. |
+| Config excerpt | For cloud/infra | Include only relevant lines. |
+| Business impact note | Yes | Explain why it matters. |
+
+## Autodoc Commands
+
+`ash
+python _rtexit/scripts/autodoc_engine.py log --skill rt-technical-report --phase auto --cmd "workflow execution" --output "summary"
+python _rtexit/scripts/finding_tracker.py list
+`
+
+## Completion Criteria
+
+- Scope and authorization are referenced.
+- Evidence is stored and redacted.
+- Findings are added or explicitly marked as not found.
+- Remediation guidance is actionable.
+- Timeline and chain of custody are updated where applicable.
+
+## Handoff
+
+Send confirmed findings to 

package/packaged-assets/.agents/skills/rt-threat-model/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: rt-threat-model
+description: "Build threat model for the engagement — identify crown jewel assets, map threat actors, define attack scenarios, and prioritize by business impact. Uses STRIDE and PASTA frameworks. Creates threat-model.md in engagement docs."
+---
+
+# rt-threat-model
+
+# Threat Modeling Workflow
+
+## Framework: STRIDE + PASTA hybrid
+
+## Step 1 — Asset Inventory
+Identify and classify assets by business value:
+| Asset | Type | Business Impact | Data Sensitivity |
+|-------|------|-----------------|------------------|
+| User authentication system | Auth | CRITICAL | High (credentials) |
+| Payment processing | Financial | CRITICAL | PCI-DSS |
+| User PII database | Data | HIGH | GDPR/Privacy |
+| Admin panel | Control | CRITICAL | Full system access |
+| API endpoints | Service | HIGH | Business logic |
+
+## Step 2 — Threat Actor Profiling
+Define realistic threat actors for this engagement:
+
+**External Attackers:**
+- Script kiddies (automated scanners, known CVEs)
+- Cybercriminal groups (ransomware, data theft)
+- Competitor espionage (targeted)
+- State-sponsored APT (if relevant)
+
+**Internal Threats:**
+- Malicious employee
+- Compromised contractor
+- Accidental data exposure
+
+## Step 3 — STRIDE Analysis
+For each component, analyze:
+- **S**poofing: Can identity be faked?
+- **T**ampering: Can data be modified?
+- **R**epudiation: Can actions be denied?
+- **I**nformation Disclosure: Can data be leaked?
+- **D**enial of Service: Can availability be disrupted?
+- **E**levation of Privilege: Can permissions be escalated?
+
+## Step 4 — Attack Scenarios
+Define 3-5 realistic attack scenarios:
+
+SCENARIO A — [External Attacker → Data Breach]
+Attack path: [Reconnaissance → Initial Access → Privilege Escalation → Data Exfiltration]
+Target: [specific assets]
+Impact: [business/regulatory impact]
+
+## Step 5 — Prioritization Matrix
+Plot scenarios on Likelihood vs Impact grid:
+- HIGH likelihood + HIGH impact = Immediate testing priority
+- Map to engagement test cases
+
+## Step 6 — Save Threat Model
+Create: `_rtexit-output/docs/engagement/threat-model.md`

package/packaged-assets/.agents/skills/rt-threat-model/template.md

@@ -0,0 +1,32 @@
+# Threat Model Template
+
+## Scope
+
+| Asset | Owner | Data Class | Business Criticality |
+|---|---|---|---|
+
+## Trust Boundaries
+
+| Boundary | From | To | Controls |
+|---|---|---|---|
+
+## Actors
+
+| Actor | Motivation | Capability | Likelihood |
+|---|---|---|---|
+
+## Abuse Cases
+
+| ID | Abuse Case | Asset | Impact | Existing Controls | Gap |
+|---|---|---|---|---|---|
+
+## Attack Paths
+
+| Path | Entry Point | Steps | Final Impact | Break Point |
+|---|---|---|---|---|
+
+## Recommended Testing Focus
+
+| Priority | Skill | Why |
+|---:|---|---|
+

package/packaged-assets/.agents/skills/rt-threat-model/workflow.md

@@ -0,0 +1,68 @@
+# Workflow - rt-threat-model
+
+## Purpose
+
+This workflow standardizes how $skill is executed inside RTExit. It is designed for authorized engagements, evidence-first documentation, and consistent handoff into reporting.
+
+## Authorization Gate
+
+Before execution, confirm:
+
+- SEAD exists and explicitly covers the target asset or activity.
+- Rules of Engagement define allowed techniques, rate limits, and stop conditions.
+- The operator knows the evidence handling rules.
+- Any active or sensitive validation has client approval.
+
+If any item is unclear, pause and invoke 
+
+## Required Inputs
+
+| Input | Source | Notes |
+|---|---|---|
+| Engagement reference | _rtexit/config.toml or SEAD | Used in output names. |
+| Target asset(s) | Scope document | Must be explicitly approved. |
+| Operator name | Config/user context | Used in timeline entries. |
+| Evidence directory | _rtexit-output/docs/evidence/ | Store logs, screenshots, and artifacts. |
+| Finding tracker | _rtexit-output/docs/findings/ | Create/update findings when confirmed. |
+
+## Execution Steps
+
+1. Load current engagement configuration.
+2. Read scope, exclusions, and current findings.
+3. Build a small test plan for this skill with target, expected control, and evidence type.
+4. Run the lowest-risk validation first.
+5. Capture baseline behavior before proof behavior.
+6. Record exact timestamp, account/role used, and affected asset.
+7. Stop when evidence is sufficient; avoid unnecessary data access.
+8. Create or update findings through the RTExit finding tracker.
+9. Map remediation owner and recommended timeline.
+10. Add a timeline entry and evidence chain entry.
+
+## Evidence Requirements
+
+| Evidence | Required? | Notes |
+|---|---|---|
+| Command or action summary | Yes | Redact secrets and tokens. |
+| Screenshot or transcript | If useful | Store under evidence folder. |
+| Request/response pair | For web/API | Redact cookies and bearer tokens. |
+| Config excerpt | For cloud/infra | Include only relevant lines. |
+| Business impact note | Yes | Explain why it matters. |
+
+## Autodoc Commands
+
+`ash
+python _rtexit/scripts/autodoc_engine.py log --skill rt-threat-model --phase auto --cmd "workflow execution" --output "summary"
+python _rtexit/scripts/finding_tracker.py list
+`
+
+## Completion Criteria
+
+- Scope and authorization are referenced.
+- Evidence is stored and redacted.
+- Findings are added or explicitly marked as not found.
+- Remediation guidance is actionable.
+- Timeline and chain of custody are updated where applicable.
+
+## Handoff
+
+Send confirmed findings to 

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

@@ -0,0 +1,338 @@
+---
+name: rt-timeline
+description: "View and manage engagement activity timeline. Shows chronological list of all activities, commands run, findings discovered, and milestones reached. Reads from _rtexit-output/docs/engagement/timeline.md. Useful for reporting engagement duration and activity sequence, creating a log for legal documentation."
+---
+
+# rt-timeline
+
+## Overview
+
+The engagement timeline is the authoritative chronological record of everything that happened during a red team engagement — every command run, every finding discovered, every milestone reached, and every decision made. It serves as the narrative backbone of the engagement, supporting the final technical report, executive summary, and any legal documentation the client requires.
+
+This skill reads from, displays, and helps manage `_rtexit-output/docs/engagement/timeline.md`. It is the operator's primary tool for reviewing engagement history, reconstructing the attack chain for reporting, and demonstrating professional conduct to auditors, legal counsel, or client security teams.
+
+### When to Use This Skill
+
+- At the start of each session to review what was accomplished previously before continuing.
+- After completing a phase (recon, exploitation, post-exploitation) to confirm all activities are logged.
+- When writing the final technical report to retrieve the accurate sequence of events.
+- When a client or legal team asks for an engagement activity log.
+- When handing off to another operator on a team engagement.
+- Before closing the engagement to verify completeness of the activity record.
+- Anytime you need to answer: "What did we do, and in what order?"
+
+### What the Timeline Contains
+
+Each timeline entry records:
+
+- **Timestamp** — UTC date and time the activity occurred
+- **Phase** — engagement phase (Planning, Recon, Exploitation, Post-Exploitation, Reporting)
+- **Activity type** — command run, finding discovered, milestone reached, tool output captured, operator note
+- **Description** — plain-language summary of what happened and what it means
+- **Reference links** — cross-references to findings (F-XXX), evidence files, or other skill outputs
+
+---
+
+## Prerequisites
+
+Before using this skill, confirm:
+
+1. Engagement is initialized. The timeline file is created by `autodoc_engine.py init`:
+
+   ```bash
+   python3 _rtexit/scripts/autodoc_engine.py init \
+     --ref ENG-2024-047 \
+     --client "Meridian Financial Group" \
+     --methodology ptes
+   ```
+
+2. The output file exists at `_rtexit-output/docs/engagement/timeline.md`. If it does not, run the init command above.
+
+3. You know the engagement reference number (e.g., `ENG-2024-047`) and the current phase.
+
+---
+
+## Step-by-Step Workflow
+
+### Step 1 — View the Full Timeline
+
+Load and display the complete contents of the timeline file:
+
+```
+_rtexit-output/docs/engagement/timeline.md
+```
+
+Present the entries in chronological order (oldest first). For each entry show:
+- Timestamp (UTC)
+- Phase label
+- Activity type tag
+- Description
+
+If the file does not exist, inform the operator and suggest running `autodoc_engine.py init`.
+
+---
+
+### Step 2 — Filter by Phase or Activity Type
+
+To focus on a specific phase or type of activity, filter the timeline entries and display only matching lines.
+
+**Filter by phase:**
+
+```
+Planning | Recon | Exploitation | Post-Exploitation | Reporting
+```
+
+**Filter by activity type:**
+
+```
+COMMAND | FINDING | MILESTONE | NOTE | TOOL-OUTPUT | HANDOFF
+```
+
+Example request: "Show me all findings discovered during the Exploitation phase."
+
+Display filtered results with the same format as the full timeline view, preceded by a count of matching entries.
+
+---
+
+### Step 3 — Add a Timeline Entry
+
+When the operator reports an activity that is not yet logged, append a new entry to the timeline file using `autodoc_engine.py`:
+
+```bash
+python3 _rtexit/scripts/autodoc_engine.py timeline \
+  --ref ENG-2024-047 \
+  --phase Exploitation \
+  --type FINDING \
+  --description "Discovered unauthenticated IDOR on /api/v2/users/{id} — any authenticated session can read arbitrary user PII. Logged as F-004."
+```
+
+**Entry format in the timeline file:**
+
+```markdown
+## 2024-11-14T14:30:22Z | Exploitation | FINDING
+
+Discovered unauthenticated IDOR on /api/v2/users/{id} — any authenticated session can read arbitrary user PII. Logged as F-004.
+
+References: F-004, evidence/http-logs/F-004-idor-user-pii-2024-11-14T143022Z.xml
+```
+
+If `autodoc_engine.py` does not support a `timeline` subcommand in the current installation, append the formatted entry directly to the file and confirm the write was successful.
+
+---
+
+### Step 4 — Generate Timeline Summary for Reporting
+
+When the operator needs a reporting-ready summary of the engagement timeline, produce a condensed narrative version suitable for inclusion in the executive report or technical appendix.
+
+**Format:**
+
+```
+Engagement Timeline Summary — ENG-2024-047
+
+Start: 2024-11-11T08:00:00Z
+End:   2024-11-22T17:00:00Z
+Duration: 11 days
+
+Phase Activity Log:
+  [Planning]         3 milestones, 0 findings, 8 commands
+  [Recon]            12 milestones, 2 findings, 47 commands
+  [Exploitation]     8 milestones, 9 findings, 134 commands
+  [Post-Exploitation] 5 milestones, 3 findings, 61 commands
+  [Reporting]        2 milestones, 0 findings, 4 commands
+
+Total findings documented: 14 (2 Critical, 4 High, 5 Medium, 3 Low)
+Total commands logged: 254
+Total evidence artifacts: 31
+```
+
+After the summary, offer to show the full chronological list sorted by phase.
+
+---
+
+### Step 5 — Validate Timeline Completeness
+
+Before closing the engagement, check the timeline for gaps:
+
+1. Confirm the engagement has entries spanning from the start date to the current date with no unexplained multi-day gaps.
+2. Cross-reference with the findings tracker: every finding in `_rtexit-output/docs/findings/` should have at least one corresponding timeline entry of type `FINDING`.
+3. Cross-reference with the evidence chain log: every evidence artifact should have a corresponding `TOOL-OUTPUT` or `COMMAND` timeline entry near the same timestamp.
+4. Check that all four required milestones are present: SEAD created, scope finalized, exploitation authorized, final report delivered.
+
+Report any gaps found and prompt the operator to fill them before the engagement is closed.
+
+---
+
+## Integration with RTExit Scripts and Other Skills
+
+### autodoc_engine.py
+
+The primary script that creates and maintains the timeline file. Key operations:
+
+```bash
+# Initialize engagement and create timeline.md
+python3 _rtexit/scripts/autodoc_engine.py init --ref ENG-2024-047 --client "Acme Corp" --methodology ptes
+
+# Add a timeline entry (if timeline subcommand is available)
+python3 _rtexit/scripts/autodoc_engine.py timeline --ref ENG-2024-047 --phase Recon --type MILESTONE --description "Attack surface map completed. 3 high-priority targets identified."
+
+# Generate engagement summary
+python3 _rtexit/scripts/autodoc_engine.py summary --ref ENG-2024-047
+```
+
+### Related Skills
+
+| Skill | Relationship to rt-timeline |
+|---|---|
+| `rt-status` | Reads last 10 timeline entries for the status dashboard. Run `rt-status` for a quick overview; run `rt-timeline` for the full history. |
+| `rt-evidence-chain` | Generates evidence custody entries that should correspond to `TOOL-OUTPUT` or `FINDING` timeline entries. Cross-reference both logs before reporting. |
+| `rt-finding-document` | Every call to `rt-finding-document` should produce a matching `FINDING` entry in the timeline. |
+| `rt-executive-report` | The executive report engagement narrative section is derived from the timeline summary. Run `rt-timeline` step 4 to produce the input for that section. |
+| `rt-technical-report` | The attack chain and chronological methodology sections of the technical report are built directly from timeline entries filtered by phase. |
+| `rt-create-sead` | SEAD creation is a `Planning` phase `MILESTONE` — confirm it appears in the timeline after running this skill. |
+| `rt-scope-definition` | Scope finalization is a `Planning` phase `MILESTONE` — confirm it appears in the timeline. |
+| `rt-kill-chain-map` | Kill chain maps are derived from `Exploitation` and `Post-Exploitation` phase `COMMAND` and `FINDING` entries in the timeline. |
+
+---
+
+## Example Outputs and Interactions
+
+### Example 1 — Viewing the Full Timeline
+
+**Operator:** "Show me the full engagement timeline."
+
+**Agent response:**
+
+```
+Engagement Timeline — ENG-2024-047 | Meridian Financial Group
+
+[2024-11-11T08:15:04Z] Planning | MILESTONE
+  Engagement initialized. SEAD created, rules of engagement signed by client CISO.
+  References: docs/engagement/sead.md
+
+[2024-11-11T09:42:17Z] Planning | MILESTONE
+  Scope finalized. 3 external IP ranges, 2 web applications, 1 internal network segment in scope.
+  References: docs/engagement/scope.md
+
+[2024-11-12T10:05:33Z] Recon | COMMAND
+  Ran subdomain enumeration on meridianfinancial.com. Discovered 14 subdomains, 3 resolving to out-of-scope CDN.
+  References: docs/recon/subdomain-enum-2024-11-12.md
+
+[2024-11-12T14:22:09Z] Recon | FINDING
+  Discovered exposed .git directory on dev.meridianfinancial.com. Logged as F-001 (High).
+  References: F-001, evidence/http-logs/F-001-git-exposure-2024-11-12T142209Z.txt
+
+[2024-11-13T09:18:55Z] Recon | MILESTONE
+  Attack surface map completed. 5 high-priority targets identified.
+  References: docs/recon/attack-surface-map.md
+
+[2024-11-14T10:00:00Z] Exploitation | MILESTONE
+  Exploitation phase authorized by operator. Targeting high-priority web application findings.
+
+[2024-11-14T14:30:22Z] Exploitation | FINDING
+  IDOR on /api/v2/users/{id} — unauthenticated access to arbitrary user PII. Logged as F-004 (Critical).
+  References: F-004, evidence/http-logs/F-004-idor-pii-2024-11-14T143022Z.xml
+
+Total entries: 7 | Duration so far: 3 days 6 hours
+```
+
+---
+
+### Example 2 — Adding a Missing Entry
+
+**Operator:** "I ran nmap on 192.168.1.0/24 yesterday at 2pm UTC and forgot to log it."
+
+**Agent response:**
+
+```
+Adding timeline entry for the nmap scan.
+
+Entry details:
+  Timestamp: 2024-11-13T14:00:00Z (operator-provided, UTC)
+  Phase:     Recon
+  Type:      COMMAND
+  Description: Ran nmap -sV -sC -p- scan against 192.168.1.0/24. Identified 14 live hosts, 3 with open management ports (22, 3389, 5985).
+
+Appending to _rtexit-output/docs/engagement/timeline.md...
+Done. Entry added. Note: manually-backdated entries are flagged with [LATE-ENTRY] in the custody log to maintain audit integrity.
+```
+
+---
+
+### Example 3 — Reporting Summary
+
+**Operator:** "Give me the timeline summary for the executive report."
+
+**Agent response:**
+
+```
+Engagement Timeline Summary — ENG-2024-047
+
+Start:    2024-11-11T08:15:04Z
+End:      2024-11-22T16:45:00Z
+Duration: 11 days, 8 hours, 29 minutes
+
+Phase Breakdown:
+  Planning          (Nov 11)       2 milestones, 0 findings,  6 commands
+  Recon             (Nov 11-13)    3 milestones, 2 findings, 31 commands
+  Exploitation      (Nov 14-19)    4 milestones, 9 findings, 98 commands
+  Post-Exploitation (Nov 19-21)    2 milestones, 3 findings, 44 commands
+  Reporting         (Nov 21-22)    1 milestone,  0 findings,  3 commands
+
+Totals:
+  Milestones logged: 12
+  Findings logged:   14  (2 Critical, 4 High, 5 Medium, 3 Low)
+  Commands logged:   182
+  Evidence artifacts: 27
+
+Key Milestones:
+  2024-11-11 — Engagement authorized, SEAD and scope signed
+  2024-11-13 — Attack surface map completed
+  2024-11-14 — Exploitation phase initiated
+  2024-11-19 — Internal pivot achieved, lateral movement complete
+  2024-11-22 — Final report delivered to client
+```
+
+---
+
+### Example 4 — Completeness Validation
+
+**Operator:** "Validate the timeline before we close out."
+
+**Agent response:**
+
+```
+Timeline Completeness Check — ENG-2024-047
+
+Checking coverage gaps... No multi-day gaps detected.
+Checking findings cross-reference...
+  F-001 through F-014: All 14 findings have matching FINDING timeline entries. PASS
+Checking evidence cross-reference...
+  27 of 27 evidence artifacts have matching COMMAND or TOOL-OUTPUT entries within 30 minutes of artifact timestamp. PASS
+Checking required milestones...
+  SEAD created:             PASS (2024-11-11T08:15:04Z)
+  Scope finalized:          PASS (2024-11-11T09:42:17Z)
+  Exploitation authorized:  PASS (2024-11-14T10:00:00Z)
+  Final report delivered:   PASS (2024-11-22T16:45:00Z)
+
+Result: Timeline is complete and consistent. Safe to close engagement.
+```
+
+---
+
+## Practical Usage Tips
+
+**Log activities in real time, not at end of day.** Timestamps that are clustered at day-end or session-end are a red flag for auditors and suggest the log was reconstructed from memory rather than captured live. Run `autodoc_engine.py timeline` or note activities as they happen.
+
+**Use LATE-ENTRY for backdated additions.** If you must add an entry after the fact, flag it explicitly. Auditors prefer a clearly marked late entry over an artificially tidy log that looks fabricated.
+
+**Cross-reference everything.** Every FINDING entry should reference the finding ID (F-XXX). Every COMMAND entry that produced an evidence file should reference the evidence filename. This makes the timeline self-navigable for report writing.
+
+**Phase transitions are milestones.** Whenever you shift from one phase to the next, log a MILESTONE entry stating that the phase began and why (e.g., "Exploitation authorized — all recon objectives complete, attack surface map signed off by lead operator").
+
+**Use the timeline to write reports, not your memory.** When drafting the technical report or executive summary, load the timeline first and work through it chronologically. Every section of the narrative should trace to a timeline entry.
+
+**The timeline is a legal document.** In the event of a dispute, incident, or post-engagement legal proceeding, the timeline log — combined with the evidence chain — is the primary record of operator conduct. Maintain it as if a court will read it.
+
+**Protect the output directory.** The `_rtexit-output/` directory contains the timeline, findings, and evidence. Restrict access to authorized operators only. Do not store it on shared or unencrypted drives.
+
+**Before handing off to another operator**, run this skill to display the last 20 entries and confirm the incoming operator has read and acknowledged the current engagement state. Log the handoff as a `HANDOFF` type milestone entry.