rtexit-method 0.1.0 → 0.1.2

package/packaged-assets/.agents/skills/rt-js-analysis/workflow.md

@@ -0,0 +1,68 @@
+# Workflow - rt-js-analysis
+
+## 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-js-analysis --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-kill-chain-map/SKILL.md

@@ -0,0 +1,393 @@
+---
+name: rt-kill-chain-map
+description: "Map the full attack chain to Lockheed Martin Cyber Kill Chain 7 phases: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, C2, Actions on Objectives. Creates Mermaid diagram showing attack progression and defender disruption opportunities at each phase. Core visual for executive reports."
+---
+
+# rt-kill-chain-map
+
+## Overview
+
+The Kill Chain Map is the visual spine of every executive report. It translates a fragmented list of technical findings into a single narrative: how an attacker moved from open-source intelligence to domain admin. Executives understand timelines and stories; they do not read CVE tables. This skill produces the diagram and the accompanying narrative that sits on page 2 of every executive report.
+
+**When to run this skill:**
+- After the exploitation phase, when at least 3-4 confirmed findings exist
+- Before generating the executive report (rt-agent-scribe KC command)
+- Whenever the engagement has a clear end-to-end attack path to demonstrate
+
+**Output:** `_rtexit-output/docs/attack-chains/kill-chain-map.md`
+
+---
+
+## Engagement Lifecycle Position
+
+```
+[Recon] → [Weaponization] → [Delivery] → [Exploitation] → [Post-Exploitation]
+                                                                    ↓
+                                               rt-kill-chain-map runs HERE
+                                                                    ↓
+                                               [Executive Report generation]
+```
+
+This skill is a **reporting artifact**, not an attack tool. It reads confirmed findings from `findings-master.csv` and reconstructs the narrative arc of the engagement.
+
+---
+
+## Step-by-Step Workflow
+
+### Step 1 — Load Confirmed Findings
+
+Pull all confirmed findings from the tracker, sorted by phase:
+
+```bash
+python3 _rtexit/scripts/finding_tracker.py list --severity CRITICAL
+python3 _rtexit/scripts/finding_tracker.py list --severity HIGH
+python3 _rtexit/scripts/finding_tracker.py export --format csv
+```
+
+Review the `phase` column in `findings-master.csv`. Each finding should already have a kill chain phase assigned when it was added. If any findings have an empty `phase` field, assign one now using the mapping table in Step 2.
+
+**Example findings-master.csv rows you will work with:**
+
+```
+id,title,severity,cvss,status,asset,cwe,cve,mitre,phase,date,operator,notes
+F-001,Subdomain Enumeration via Certificate Transparency,INFO,0.0,CONFIRMED,*.acmecorp.com,CWE-200,,T1596.003,Reconnaissance,2026-05-12,op1,Found 47 subdomains via crt.sh
+F-002,Exposed Swagger UI on dev-api.acmecorp.com,MEDIUM,5.3,CONFIRMED,dev-api.acmecorp.com,CWE-200,,T1592,Reconnaissance,2026-05-12,op1,Full API schema exposed unauthenticated
+F-003,Default Credentials on Jenkins CI (admin/admin),CRITICAL,9.8,CONFIRMED,jenkins.acmecorp.com,CWE-798,CVE-2024-23897,T1078.001,Delivery,2026-05-13,op1,Direct console access
+F-004,RCE via Jenkins Script Console (Groovy),CRITICAL,9.9,CONFIRMED,jenkins.acmecorp.com,CWE-94,,T1059.002,Exploitation,2026-05-13,op1,Reverse shell as jenkins user
+F-005,Plaintext AWS Keys in /var/lib/jenkins/workspace/,CRITICAL,9.1,CONFIRMED,jenkins.acmecorp.com,CWE-312,,T1552.001,Installation,2026-05-14,op1,Keys have S3 FullAccess + EC2 Describe
+F-006,EC2 Instance Metadata SSRF → IAM Role Exfiltration,HIGH,8.6,CONFIRMED,10.0.1.45,CWE-918,,T1552.005,C2,2026-05-14,op1,Retrieved arn:aws:iam::123456789012:role/prod-ec2-role
+F-007,S3 Bucket Exfiltration — PII Database Dump,CRITICAL,9.4,CONFIRMED,acmecorp-prod-db-backups,CWE-359,,T1530,Actions on Objectives,2026-05-15,op1,Downloaded 4.2GB backup; 1.2M customer records
+```
+
+### Step 2 — Map Findings to Kill Chain Phases
+
+Use this mapping table if any findings lack a `phase` value:
+
+| Kill Chain Phase | What Happened Here | MITRE Tactic |
+|---|---|---|
+| Reconnaissance | OSINT, subdomain enum, port scanning, API schema discovery | TA0043 |
+| Weaponization | Payload crafting, exploit modification, phishing template creation | TA0042 |
+| Delivery | Phishing email sent, exploit delivered, malicious file uploaded, login with credentials | TA0001 |
+| Exploitation | Vulnerability triggered, shell obtained, auth bypass | TA0002 |
+| Installation | Persistence mechanism, backdoor, credential harvesting tool | TA0003 |
+| C2 | Beacon established, lateral movement tooling, data staging | TA0011 |
+| Actions on Objectives | Data exfiltration, ransomware deployment, account takeover | TA0009 |
+
+Update any untagged findings:
+
+```bash
+python3 _rtexit/scripts/finding_tracker.py update F-003 --phase "Delivery"
+```
+
+### Step 3 — Build the Phase Summary Table
+
+For each of the 7 phases, write one row. Be specific — use real hostnames, real finding IDs, real techniques. Never write generic descriptions.
+
+**Template (fill in for your engagement):**
+
+| Phase | What the Attacker Did | Finding(s) | Defender Opportunity |
+|---|---|---|---|
+| Reconnaissance | Enumerated 47 subdomains via Certificate Transparency logs; identified exposed Swagger UI revealing internal API schema | F-001, F-002 | Alert on crt.sh enumeration; remove Swagger from non-prod exposure |
+| Weaponization | No custom weaponization required — default credentials eliminated this phase | — | Credential hygiene program would have broken the chain here |
+| Delivery | Authenticated to Jenkins CI using default credentials admin/admin — no phishing required | F-003 | Enforce non-default credentials; MFA on all admin panels |
+| Exploitation | Executed Groovy script in Jenkins Script Console to obtain reverse shell as jenkins service account | F-004 | Disable Script Console in production; restrict to admin IP |
+| Installation | Discovered plaintext AWS access keys committed to Jenkins workspace build artifacts | F-005 | Secrets scanning in CI pipeline; rotate all keys; use IAM roles |
+| Command & Control | Used stolen AWS keys to query EC2 Instance Metadata Service; retrieved IAM role credentials for prod-ec2-role | F-006 | IMDSv2 enforcement; least-privilege IAM roles |
+| Actions on Objectives | Downloaded 4.2 GB S3 backup containing 1.2 million customer records including names, emails, hashed passwords | F-007 | S3 bucket policies restricting access by VPC; CloudTrail alerting on bulk GetObject |
+
+### Step 4 — Generate the Mermaid Diagram
+
+Produce the Mermaid flowchart. Structure: left-to-right flow through phases, with findings as nodes, and defender disruption points marked in red.
+
+**Standard diagram template:**
+
+````markdown
+```mermaid
+flowchart LR
+    subgraph Phase1["1. Reconnaissance"]
+        R1["F-001: Subdomain Enum\ncrt.sh — 47 subdomains"]
+        R2["F-002: Swagger UI Exposed\ndev-api.acmecorp.com"]
+    end
+
+    subgraph Phase2["2. Weaponization"]
+        W1["(Skipped — default creds\neliminated need)"]
+    end
+
+    subgraph Phase3["3. Delivery"]
+        D1["F-003: Default Credentials\nJenkins admin/admin"]
+    end
+
+    subgraph Phase4["4. Exploitation"]
+        E1["F-004: RCE via Groovy\nScript Console — reverse shell"]
+    end
+
+    subgraph Phase5["5. Installation"]
+        I1["F-005: AWS Keys in\nbuild workspace (plaintext)"]
+    end
+
+    subgraph Phase6["6. Command & Control"]
+        C1["F-006: SSRF → IMDS\nIAM role credential theft"]
+    end
+
+    subgraph Phase7["7. Actions on Objectives"]
+        A1["F-007: S3 Exfiltration\n1.2M customer records — 4.2 GB"]
+    end
+
+    Phase1 --> Phase2 --> Phase3 --> Phase4 --> Phase5 --> Phase6 --> Phase7
+
+    style Phase1 fill:#1a1a2e,stroke:#4a4a8a,color:#fff
+    style Phase2 fill:#1a1a2e,stroke:#4a4a8a,color:#fff
+    style Phase3 fill:#2d1b1b,stroke:#8b2c2c,color:#fff
+    style Phase4 fill:#2d1b1b,stroke:#cc0000,color:#fff
+    style Phase5 fill:#2d1b1b,stroke:#cc0000,color:#fff
+    style Phase6 fill:#2d1b1b,stroke:#cc0000,color:#fff
+    style Phase7 fill:#3d0000,stroke:#ff0000,color:#fff
+```
+````
+
+**Disruption opportunities diagram (add after the attack flow):**
+
+````markdown
+```mermaid
+flowchart TD
+    D1["BREAK HERE: Credential hygiene\n+ MFA on Jenkins\n→ Stops chain at Delivery"]:::fix
+    D2["BREAK HERE: Secrets scanning in CI\n→ Stops chain at Installation"]:::fix
+    D3["BREAK HERE: IMDSv2 + least-privilege IAM\n→ Stops chain at C2"]:::fix
+    D4["BREAK HERE: S3 VPC endpoint policy\n+ CloudTrail alerting\n→ Stops chain at Actions"]:::fix
+
+    classDef fix fill:#0a3d0a,stroke:#00cc00,color:#fff
+```
+````
+
+### Step 5 — Write the Executive Narrative (200-300 words)
+
+This paragraph goes directly under the diagram in the executive report. Write it in plain English. No jargon. Focus on business impact.
+
+**Example narrative:**
+
+> Our team gained access to 1.2 million customer records in three days — without sending a single phishing email. The attack began with publicly available information: your Jenkins build server was discoverable through certificate transparency logs, and its login page accepted the default password "admin." From that single misstep, we obtained a command shell on a production-adjacent server, discovered Amazon Web Services credentials stored in plain text inside a build log, and used those credentials to download a complete backup of your customer database from cloud storage.
+>
+> The Cyber Kill Chain diagram above shows every step. More importantly, it shows where a single defensive control would have stopped the entire chain. Enforcing non-default passwords with multi-factor authentication on Jenkins breaks the attack at Delivery — phases four through seven never happen. Adding automated secrets scanning to your CI pipeline breaks it at Installation. You do not need to fix all seven findings simultaneously; fixing the two highest-leverage controls neutralizes the complete attack path.
+>
+> The customer data accessed includes full names, email addresses, physical addresses, and password hashes for accounts created before 2024-01-01. Depending on jurisdiction, this exposure triggers notification obligations under GDPR Article 33 and PDPL Article 20.
+
+### Step 6 — Save the Kill Chain Document
+
+Write the final document to the standard output path:
+
+```
+_rtexit-output/docs/attack-chains/kill-chain-map.md
+```
+
+Document structure:
+
+```
+# Kill Chain Map — [Client Name] — [Engagement Reference]
+**Date:** YYYY-MM-DD
+**Operator:** [callsign]
+**Engagement:** [REF-YYYY-NNN]
+
+## Executive Summary (2 sentences max)
+## Attack Phase Table
+## Kill Chain Diagram (Mermaid)
+## Defender Disruption Opportunities (Mermaid)
+## Executive Narrative
+## Finding References
+```
+
+### Step 7 — Log to Autodoc Engine
+
+```bash
+python3 _rtexit/scripts/autodoc_engine.py log \
+  --skill rt-kill-chain-map \
+  --phase "Reporting" \
+  --note "Kill chain map generated — 7 phases, 7 findings mapped" \
+  --finding "F-001,F-002,F-003,F-004,F-005,F-006,F-007"
+```
+
+---
+
+## Integration with finding_tracker.py
+
+**Pull all findings for mapping:**
+```bash
+python3 _rtexit/scripts/finding_tracker.py list
+python3 _rtexit/scripts/finding_tracker.py stats
+```
+
+**Update phase tags on existing findings:**
+```bash
+python3 _rtexit/scripts/finding_tracker.py update F-003 --phase "Delivery"
+python3 _rtexit/scripts/finding_tracker.py update F-004 --phase "Exploitation"
+```
+
+**Export to CSV for batch review:**
+```bash
+python3 _rtexit/scripts/finding_tracker.py export --format csv
+```
+
+The `phase` field in `findings-master.csv` is the source of truth. Kill chain maps must never contradict what is in the tracker. If a finding is tagged `Exploitation` in the tracker, it appears in the Exploitation phase of the diagram — no exceptions.
+
+---
+
+## Integration with autodoc_engine.py
+
+Log the start of kill chain mapping:
+```bash
+python3 _rtexit/scripts/autodoc_engine.py log \
+  --skill rt-kill-chain-map \
+  --phase "Reporting" \
+  --note "Started kill chain map construction"
+```
+
+Log each phase as you complete it:
+```bash
+python3 _rtexit/scripts/autodoc_engine.py log \
+  --skill rt-kill-chain-map \
+  --phase "Reporting" \
+  --note "Reconnaissance phase mapped — 2 findings (F-001, F-002)"
+```
+
+Log completion and output file:
+```bash
+python3 _rtexit/scripts/autodoc_engine.py log \
+  --skill rt-kill-chain-map \
+  --phase "Reporting" \
+  --note "Kill chain map complete — saved to attack-chains/kill-chain-map.md"
+```
+
+The timeline entry confirms to QA reviewers exactly when the kill chain was finalized and whether it was produced before or after the executive report was drafted.
+
+---
+
+## Complete Example Output
+
+The following is what a finished `kill-chain-map.md` looks like for the AcmeCorp engagement:
+
+---
+
+```markdown
+# Kill Chain Map — AcmeCorp Ltd — RT-2026-007
+
+**Date:** 2026-05-15
+**Operator:** Ghost
+**Engagement:** RT-2026-007 — External Black-Box Penetration Test
+**Scope:** acmecorp.com and all subdomains; AWS account 123456789012
+
+---
+
+## Attack Summary
+
+An unauthenticated external attacker achieved full exfiltration of 1.2 million
+customer records in 72 hours using a 7-step attack chain originating from
+publicly available infrastructure intelligence.
+
+---
+
+## Phase Table
+
+| Phase | Attacker Action | Finding | Defender Disruption |
+|---|---|---|---|
+| Reconnaissance | Enumerated subdomains via CT logs; identified Jenkins and Swagger UI | F-001, F-002 | Monitor CT logs; restrict admin service exposure |
+| Weaponization | Not required — default credentials negated this phase | — | Credential hygiene breaks chain here |
+| Delivery | Logged into Jenkins CI with admin/admin | F-003 | Non-default passwords + MFA breaks chain here |
+| Exploitation | Executed reverse shell via Jenkins Groovy Script Console | F-004 | Disable Script Console; restrict by source IP |
+| Installation | Read plaintext AWS keys from Jenkins build workspace logs | F-005 | Secrets scanner in CI pipeline breaks chain here |
+| C2 | SSRF to EC2 IMDS retrieved IAM role credentials for prod-ec2-role | F-006 | IMDSv2 mandatory; least-privilege IAM breaks chain here |
+| Actions on Objectives | Downloaded 4.2 GB S3 backup containing 1.2M customer PII records | F-007 | VPC endpoint S3 policy + CloudTrail alerting breaks chain here |
+
+---
+
+## Kill Chain Diagram
+
+[Mermaid diagram as shown in Step 4]
+
+---
+
+## Defender Disruption Opportunities
+
+[Disruption diagram as shown in Step 4]
+
+---
+
+## Executive Narrative
+
+Our team gained access to 1.2 million customer records in three days — without
+sending a single phishing email. [... full narrative as shown in Step 5 ...]
+
+---
+
+## Finding References
+
+| ID | Title | Severity | CVSS |
+|---|---|---|---|
+| F-001 | Subdomain Enumeration via Certificate Transparency | INFO | 0.0 |
+| F-002 | Exposed Swagger UI on dev-api.acmecorp.com | MEDIUM | 5.3 |
+| F-003 | Default Credentials on Jenkins CI | CRITICAL | 9.8 |
+| F-004 | RCE via Jenkins Script Console | CRITICAL | 9.9 |
+| F-005 | Plaintext AWS Keys in Jenkins Workspace | CRITICAL | 9.1 |
+| F-006 | EC2 IMDS SSRF → IAM Role Exfiltration | HIGH | 8.6 |
+| F-007 | S3 Bucket PII Exfiltration — 1.2M Records | CRITICAL | 9.4 |
+```
+
+---
+
+## Quality Checklist
+
+Before submitting the kill chain map for executive report inclusion, verify every item:
+
+**Coverage**
+- [ ] All 7 Kill Chain phases are present in the diagram (even if a phase was skipped, document why)
+- [ ] Every CRITICAL and HIGH finding appears in at least one phase
+- [ ] No finding appears in the wrong phase (cross-check with findings-master.csv `phase` field)
+- [ ] Finding IDs in the diagram match finding IDs in the tracker exactly (F-001 not "Finding 1")
+
+**Accuracy**
+- [ ] Hostnames, IPs, and service names in the diagram match what was actually tested
+- [ ] MITRE technique IDs in the phase table are valid and current (ATT&CK v15+)
+- [ ] No placeholder text remains (no "[TARGET]", no "[INSERT HERE]", no "[TBD]")
+- [ ] CVSS scores in the finding reference table match the tracker
+
+**Narrative Quality**
+- [ ] Executive narrative contains zero technical jargon (no CVE IDs, no "RCE", no "SSRF")
+- [ ] Business impact is stated in concrete terms (number of records, regulatory framework, dollar equivalent if known)
+- [ ] At least two specific defender disruption points are called out with actionable controls
+- [ ] Narrative is 200-350 words — not shorter (too thin), not longer (executive loses interest)
+
+**Mermaid Diagram**
+- [ ] Diagram renders correctly (test in any Mermaid live editor before including in report)
+- [ ] Phase boxes are color-coded: blue/dark for early phases, red gradient for destructive phases
+- [ ] Disruption diagram is separate from the attack flow diagram
+- [ ] Node labels are readable at 80% zoom — no label exceeds 40 characters per line
+
+**Logging**
+- [ ] `autodoc_engine.py log` called at start and completion
+- [ ] Output file saved to `_rtexit-output/docs/attack-chains/kill-chain-map.md`
+- [ ] Timeline entry confirms the map was completed before the executive report was generated
+
+---
+
+## Common Mistakes to Avoid
+
+**1. Skipping phases without explanation**
+Wrong: Simply leaving Weaponization blank in the diagram.
+Right: Add a node that says "Weaponization bypassed — default credentials eliminated this phase" with a note explaining the defensive implication. A skipped phase is itself a finding about attacker efficiency.
+
+**2. Putting findings in the wrong phase**
+Discovering a credential in a config file is Installation, not Reconnaissance. Reconnaissance is passive information gathering before any access. Once you have a foothold, you are past Delivery. Misclassified phases confuse defenders who use the map to prioritize controls.
+
+**3. Writing the narrative in technical language**
+Wrong: "We leveraged CVE-2024-23897 to achieve RCE via the Jenkins LFI vulnerability, obtaining a reverse shell with UID 1001."
+Right: "We gained full control of your build server using a known vulnerability in Jenkins. This gave us the same access as your development team — including their stored credentials."
+
+**4. Copying the phase table verbatim as the narrative**
+The table and the narrative serve different audiences. The table is for technical readers who will act on it. The narrative is for the CEO who needs to understand why this matters to the business. They should tell the same story in two different registers.
+
+**5. Generating the map before findings are confirmed**
+Never map unconfirmed or potential findings to the kill chain. If a finding is marked `POTENTIAL` in the tracker, do not include it. The kill chain is a factual record of what was demonstrated, not a speculation about what might be possible.
+
+**6. Forgetting the disruption diagram**
+The attack flow diagram shows what happened. The disruption diagram shows what would have stopped it. Without the disruption diagram, the kill chain map is a horror story with no resolution. Executives need to leave the meeting knowing there are concrete actions that break the chain.
+
+**7. Not logging to autodoc_engine.py**
+The timeline in `engagement/timeline.md` is legal evidence that the kill chain map was produced during the engagement and not retroactively. Always log. Always include the `--phase "Reporting"` flag so the timeline is accurate.