rtexit-method 0.1.0 → 0.1.1

package/packaged-assets/.agents/skills/rt-osint/osint-sources.csv

@@ -0,0 +1,12 @@
+source,type,use_case,notes
+Search engines,passive,Index discovery,Use scoped queries and document URLs
+Certificate Transparency,passive,Subdomain and certificate history,crt.sh Censys Google CT
+WHOIS/RDAP,passive,Registration and ownership metadata,Respect privacy and accuracy limits
+DNS records,passive,MX TXT SPF DMARC NS discovery,Useful for email security and hosting
+Git hosting,passive,Code endpoint and accidental secret leads,Validate before reporting
+Package registries,passive,Technology and maintainer discovery,npm PyPI RubyGems NuGet
+Job postings,passive,Technology stack clues,Do not overstate confidence
+LinkedIn/company pages,passive,Department and role mapping,Follow engagement privacy rules
+Cloud asset search,passive,Public buckets apps and endpoints,Only access approved resources
+Breach corpuses,restricted,Credential exposure leads,Use only if authorized and redact
+

package/packaged-assets/.agents/skills/rt-osint/workflow.md

@@ -0,0 +1,68 @@
+# Workflow - rt-osint
+
+## 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-osint --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-party-mode/SKILL.md

@@ -0,0 +1,249 @@
+---
+name: rt-party-mode
+description: "Red Team War Gaming — spawn all 7 RTExit agents as independent subagents (not roleplay) to collaboratively analyze and plan attack strategy. Commander sets objectives, Scout reports recon gaps, Breaker identifies best vectors, Navigator covers mobile/desktop, Ghost plans post-exploitation, Phantom suggests social engineering, Scribe notes documentation needs. Real multi-agent consensus."
+---
+
+# rt-party-mode
+
+## 1. Purpose and When to Use
+
+rt-party-mode activates a full red team war-gaming session by spawning all 7 RTExit specialist agents as independent subagents. Each agent runs with genuine autonomy — not as roleplay by a single model — and contributes its domain expertise to produce a coordinated attack strategy.
+
+**Use this skill when you need:**
+
+- A full-scope assessment where multiple attack surfaces must be evaluated simultaneously
+- Cross-domain consensus before committing to an engagement plan
+- Sanity-checking a proposed attack path against specialists who may see blind spots
+- Collaborative threat modeling for a new target profile
+- Pre-engagement planning sessions where completeness matters more than speed
+- Debriefs after a failed or partial engagement to identify what was missed
+
+**Do not use for:**
+
+- Quick single-vector checks (use the dedicated agent skill directly instead)
+- Purely automated scan workflows (use RTExit scripts directly)
+- Production systems without explicit written authorization
+
+---
+
+## 2. Agent Roster
+
+| Agent | Role | Primary Focus |
+|---|---|---|
+| Commander | Engagement lead | Sets objectives, arbitrates conflicts, owns the final plan |
+| Scout | Reconnaissance | Identifies recon gaps, OSINT coverage, attack surface inventory |
+| Breaker | Exploitation | Identifies highest-confidence attack vectors, CVE mapping |
+| Navigator | Client coverage | Mobile and desktop client-side vectors, browser/app surface |
+| Ghost | Post-exploitation | Persistence, lateral movement, data exfil planning |
+| Phantom | Social engineering | Pretexting, phishing, physical access vectors |
+| Scribe | Documentation | Notes gaps, tracks findings, flags what needs writing up |
+
+---
+
+## 3. Step-by-Step Workflow
+
+### Step 1 — Invoke the skill
+
+```
+/rt-party-mode
+```
+
+Optionally pass a target context to focus the session:
+
+```
+/rt-party-mode target: Acme Corp web app + mobile clients, scope: external perimeter only
+```
+
+### Step 2 — Commander opens the session
+
+Commander receives the target context and sets engagement objectives. Output includes:
+
+- Engagement goal statement (e.g., "achieve domain admin or exfiltrate PII")
+- Scope boundaries
+- Time-box for the planning session
+- Questions to surface before proceeding
+
+### Step 3 — Scout reports recon status
+
+Scout reviews available recon data (or notes what is missing) and produces:
+
+- Known assets: domains, IPs, exposed services, employee data found
+- Recon gaps: what intelligence is still needed before exploitation can begin
+- Recommended recon tasks with tooling suggestions (e.g., amass, theHarvester, Shodan queries)
+
+### Step 4 — Breaker identifies attack vectors
+
+Breaker analyzes the recon picture and proposes:
+
+- Top 3-5 exploitation vectors ranked by confidence and impact
+- CVE or technique references (MITRE ATT&CK mapped where applicable)
+- Prerequisites each vector needs from Scout
+- Estimated effort per vector
+
+### Step 5 — Navigator covers client-side surface
+
+Navigator assesses mobile and desktop attack surface:
+
+- Web application client-side issues (DOM XSS, client secrets, CORS misconfig)
+- Mobile app attack surface (APK/IPA static analysis needs, deep link abuse, certificate pinning)
+- Desktop client vectors if applicable
+- Intersection with Breaker's vectors — what can be chained
+
+### Step 6 — Ghost plans post-exploitation
+
+Ghost assumes a foothold and plans forward:
+
+- Persistence mechanisms appropriate to the target environment
+- Lateral movement paths based on known topology
+- Data exfiltration routes and staging options
+- Detection evasion considerations
+
+### Step 7 — Phantom adds social engineering layer
+
+Phantom evaluates the human attack surface:
+
+- Pretext scenarios ranked by plausibility
+- Phishing campaign design (lure theme, delivery method, payload)
+- Physical access vectors if in scope
+- Which Breaker vectors can be enabled or accelerated by SE
+
+### Step 8 — Scribe produces session output
+
+Scribe consolidates all agent contributions into a structured session record:
+
+- Master finding list with agent attribution
+- Open questions requiring follow-up
+- Documentation gaps that must be filled before the engagement
+- Recommended next skills or scripts to run
+
+### Step 9 — Commander issues final plan
+
+Commander reviews all agent inputs and publishes:
+
+- Prioritized attack plan (Phase 1 / Phase 2 / contingency)
+- Agent assignments for execution phase
+- Go/no-go decision with rationale
+- Escalation triggers (conditions under which to pause and re-plan)
+
+---
+
+## 4. Integration with RTExit Scripts and Other Skills
+
+### Script integration
+
+| Phase | RTExit Script | Triggering Agent |
+|---|---|---|
+| Recon | `rt-recon.sh`, `rt-osint.sh` | Scout |
+| Exploitation | `rt-scan.sh`, `rt-exploit.sh` | Breaker |
+| Client-side | `rt-mobile.sh`, `rt-webclient.sh` | Navigator |
+| Post-exploitation | `rt-persist.sh`, `rt-lateral.sh` | Ghost |
+| Phishing | `rt-phish.sh` | Phantom |
+| Reporting | `rt-report.sh` | Scribe |
+
+### Skill integration
+
+- Run `rt-recon` before invoking rt-party-mode to give Scout real data to work from
+- After the session, use `rt-scribe` to expand Scribe's notes into a full engagement log
+- Use `rt-breaker` in isolation when you only need vector analysis without full war-gaming overhead
+- Chain into `rt-debrief` after an engagement to run a retrospective party-mode session
+
+### Passing context between agents
+
+Each agent receives the full session context accumulated so far. Agents read prior outputs and explicitly reference them — Commander's objectives inform all subsequent agents, and Scribe's running notes are updated after each agent speaks.
+
+---
+
+## 5. Example Outputs and Interactions
+
+### Example — Commander opening
+
+```
+COMMANDER — Engagement objectives set
+
+Target: Acme Corp external perimeter
+Goal: Achieve authenticated access to internal network or exfiltrate customer PII
+Scope: External-facing web, mobile apps (iOS + Android), no physical access
+Time-box: 14-day engagement, planning session today
+
+Open questions before proceeding:
+1. Scout — do we have valid employee email format confirmed?
+2. Breaker — is the Acme VPN gateway in scope or explicitly excluded?
+3. Phantom — is vishing authorized or email-only?
+```
+
+### Example — Scout recon gap report
+
+```
+SCOUT — Recon status
+
+Confirmed assets:
+- 3 subdomains: app.acme.com, api.acme.com, admin.acme.com
+- LinkedIn: 47 employees identified, IT/DevOps team of 6 named
+- Shodan: port 8443 open on 203.0.113.45, banner suggests Pulse Secure
+
+Gaps — action required before Breaker can proceed:
+- Email format unconfirmed (first.last vs flast vs f.last)
+- No certificate transparency data pulled yet — may reveal more subdomains
+- admin.acme.com returns 403 — need to determine if it is truly restricted or just redirect
+
+Recommended: run rt-osint.sh --target acme.com --ct-logs before next session
+```
+
+### Example — Breaker vector ranking
+
+```
+BREAKER — Attack vectors
+
+1. Pulse Secure CVE-2021-22893 (CVSS 10.0) — if unpatched, unauthenticated RCE
+   Confidence: medium (version not confirmed), Impact: critical
+   Needs Scout to confirm version via banner grab or Shodan history
+
+2. Credential stuffing against app.acme.com/login
+   Confidence: high (no MFA observed on login flow), Impact: high
+   Needs Scout to confirm email format, then Phantom to source wordlist
+
+3. API key leakage in mobile app
+   Confidence: medium (Navigator to confirm via APK static analysis), Impact: high
+
+Recommended first path: confirm Pulse Secure version. If vulnerable, this is primary.
+```
+
+### Example — Scribe session summary
+
+```
+SCRIBE — Session record v1
+
+Open findings:
+- [Scout] Email format TBD — blocks Phantom phishing and credential stuffing
+- [Breaker] Pulse Secure version unconfirmed — blocks vector 1
+- [Navigator] APK not yet extracted — blocks vector 3 assessment
+- [Ghost] Lateral movement plan deferred pending foothold path decision
+- [Phantom] Vishing authorization status unclear — Commander to confirm with client
+
+Documentation gaps:
+- Rules of engagement doc not reviewed in this session — Scribe to flag for Commander
+- No evidence log template set up yet — recommend rt-scribe before execution begins
+
+Next recommended actions:
+1. Run rt-osint.sh to close Scout gaps
+2. Commander confirms vishing scope with client
+3. Navigator pulls APK from Play Store and runs rt-mobile.sh
+```
+
+---
+
+## 6. Practical Usage Tips
+
+**Give Scout real data first.** Running rt-party-mode on an empty recon picture produces speculative output. Even a basic `rt-recon.sh` run before the session gives Scout concrete gaps to report rather than generic recommendations.
+
+**Let Commander arbitrate conflicts.** Agents will sometimes propose contradictory priorities — for example, Breaker may want to exploit immediately while Scout flags missing intelligence. Commander's role is to make the call. Do not override Commander decisions mid-session without restarting the objective-setting phase.
+
+**Scribe output is the artifact.** The Scribe session record is the document you carry forward. After the session ends, pipe Scribe's output into `rt-scribe` for full write-up expansion before the engagement begins.
+
+**Keep scope explicit.** Agents will expand their analysis to fill available scope. If physical access, vishing, or out-of-scope systems are not explicitly excluded in the Commander phase, agents will include them. Set hard boundaries at step 2.
+
+**Run post-engagement party-mode as debrief.** Invoking rt-party-mode after an engagement — with findings as context — produces a structured retrospective. Ghost and Breaker will identify what was missed; Scribe will note documentation gaps; Commander will assess whether objectives were met.
+
+**Subagents are independent.** Each agent runs as a real subagent, not a persona adopted by a single model instance. Expect genuine disagreement between agents. This is a feature — surface conflicts rather than suppressing them.
+
+**Minimum viable session.** If time is constrained, run Commander + Scout + Breaker only, then skip to Scribe. Ghost, Phantom, and Navigator can run as follow-on sessions once a primary vector is selected.

package/packaged-assets/.agents/skills/rt-party-mode/workflow.md

@@ -0,0 +1,68 @@
+# Workflow - rt-party-mode
+
+## 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-party-mode --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