rtexit-method 0.1.0 → 0.1.1

package/packaged-assets/.agents/skills/rt-exploit-osticket/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: rt-exploit-osticket
+description: "Authorized osTicket/helpdesk portal security testing skill covering public ticket flows, staff authentication, attachment handling, stored-content risk, rate limits, sensitive ticket data, and remediation."
+---
+
+# rt-exploit-osticket - Helpdesk Portal Security Testing
+
+> Coordinate with helpdesk owners before any workflow, volume, or attachment testing. Public support portals often connect directly to operational staff.
+
+## Overview
+
+Helpdesk portals combine public input, file attachments, staff workflows, notification systems, and sensitive historical data. This skill evaluates osTicket-style deployments for application security and business process risk.
+
+## Prerequisites
+
+- Portal URL and staff panel scope.
+- Test customer account if applicable.
+- Approved attachment types and size limits.
+- Approved rate limits.
+- Helpdesk owner contact.
+- Rules for testing stored content and notifications.
+
+## Assessment Areas
+
+| Area | Checks |
+|---|---|
+| Public Ticket Creation | CAPTCHA, rate limits, required fields, abuse protection. |
+| Staff Authentication | MFA, lockout, password policy, exposed staff panel. |
+| Authorization | Ticket ID enumeration, department separation, attachment access. |
+| Attachment Handling | Type validation, malware scanning, storage location, direct serving. |
+| Stored Content | Safe rendering of names, subject, message, and custom fields. |
+| Data Retention | Sensitive credentials or PII in old tickets. |
+| Notifications | Header injection, notification flooding, sensitive content in emails. |
+
+## Workflow
+
+1. Map public and staff endpoints.
+2. Create test tickets with harmless markers.
+3. Validate whether markers are rendered safely to staff.
+4. Test attachment controls with benign files only.
+5. Review access control around ticket IDs and attachments.
+6. Review operational controls: rate limits, spam handling, staff MFA.
+7. Document business impact and fixes.
+
+## Evidence
+
+Capture ticket IDs, timestamps, role used, rendered output screenshots, response headers, and redacted email notifications. Never upload real malware or active web shells.
+
+## Remediation
+
+- Enforce MFA for staff.
+- Restrict `/scp/` staff panel.
+- Add strict attachment allowlists and scanning.
+- Encode all user-controlled fields in staff views and email templates.
+- Add rate limiting and abuse monitoring.
+- Reduce sensitive data retention in tickets.
+
+## Autodoc
+
+```bash
+python _rtexit/scripts/autodoc_engine.py log --skill rt-exploit-osticket --phase exploitation --cmd "helpdesk validation" --output "redacted portal findings"
+```
+

package/packaged-assets/.agents/skills/rt-exploit-phishing/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: rt-exploit-phishing
+description: "Email-based social engineering testing skill. Requires explicit SEAD authorization for phishing simulation. Tests organization's email security posture, employee awareness, and DMARC/SPF/DKIM configuration. Output: phishing simulation results and email security hardening recommendations."
+---
+
+# rt-exploit-phishing — Email Security Testing
+
+> ⚠️ **AUTHORIZATION REQUIRED**: This skill must only be executed with explicit written authorization in the SEAD document. Phishing simulation must be within defined engagement scope.
+
+## Overview
+
+This skill tests an organization's email security posture by:
+1. Analyzing DNS email security records (DMARC, SPF, DKIM)
+2. Identifying email spoofing vulnerabilities
+3. Conducting authorized phishing simulations (if in scope)
+4. Providing email security hardening recommendations
+
+## Prerequisites
+
+- [ ] SEAD explicitly authorizes phishing simulation
+- [ ] Target email domains confirmed in scope
+- [ ] Phishing simulation type approved (generic vs. spear phishing)
+- [ ] Notification procedures confirmed with client
+- [ ] GoPhish or approved platform configured
+
+---
+
+## Step 1 — Email Security DNS Analysis
+
+```bash
+TARGET_DOMAIN="target.com"
+
+# Check DMARC policy
+dig _dmarc.$TARGET_DOMAIN TXT
+# CRITICAL: p=none = report only (spoofing may succeed)
+# p=quarantine = suspicious mail to spam
+# p=reject = unauthorized mail blocked
+
+# Check SPF record
+dig $TARGET_DOMAIN TXT | grep "v=spf1"
+# ~all = softfail (may deliver)
+# -all = hardfail (reject)
+
+# Check DKIM (requires selector knowledge)
+dig selector1._domainkey.$TARGET_DOMAIN TXT
+dig google._domainkey.$TARGET_DOMAIN TXT
+
+# Full email security assessment
+python3 << 'EOF'
+import subprocess
+
+domain = "target.com"
+
+dmarc = subprocess.run(["dig", f"_dmarc.{domain}", "TXT", "+short"],
+                       capture_output=True, text=True).stdout
+spf = subprocess.run(["dig", domain, "TXT", "+short"],
+                     capture_output=True, text=True).stdout
+
+print("=== EMAIL SECURITY ASSESSMENT ===")
+print(f"DMARC: {dmarc.strip()}")
+print(f"SPF: {[l for l in spf.splitlines() if 'spf1' in l]}")
+
+if "p=none" in dmarc:
+    print("[CRITICAL] DMARC p=none: Email spoofing may bypass enforcement")
+elif "p=quarantine" in dmarc:
+    print("[HIGH] DMARC p=quarantine: Spoofed emails may reach spam folder")
+elif "p=reject" in dmarc:
+    print("[SECURE] DMARC p=reject: Unauthorized emails blocked")
+else:
+    print("[CRITICAL] No DMARC record: No email authentication enforcement")
+EOF
+```
+
+## Step 2 — GoPhish Campaign Setup (Authorized Simulation)
+
+```bash
+# Installation
+wget https://github.com/gophish/gophish/releases/latest/download/gophish-linux-64bit.zip
+unzip gophish-linux-64bit.zip
+chmod +x gophish
+./gophish
+# Admin UI: https://localhost:3333 (default: admin / gophish)
+
+# Campaign components needed:
+# 1. Sending Profile (SMTP configuration)
+# 2. Landing Page (credential capture or awareness page)
+# 3. Email Template (authorized simulation email)
+# 4. User Group (target employees from scope)
+# 5. Campaign (combines all above)
+```
+
+## Step 3 — Email Template Design
+
+Design emails that test employee awareness for common scenarios:
+
+**Scenario 1 — IT Support Password Reset**
+- From: IT Support (authorized test email)
+- Subject: Action Required: Password Expiration Notice
+- Content: Links to awareness training page
+- Objective: Test response to urgency + authority
+
+**Scenario 2 — HR Annual Review Document**
+- From: HR Team (authorized test email)
+- Subject: Your Performance Review is Ready
+- Content: Links to credential harvest page (if authorized)
+- Objective: Test response to relevant/expected communications
+
+**Scenario 3 — Finance Invoice Verification**
+- From: Finance Team (authorized test email)
+- Subject: Invoice Approval Needed
+- Content: Attachment or link requiring interaction
+- Objective: Test response to financial urgency
+
+## Step 4 — Email Security Testing Results
+
+Document findings:
+
+```markdown
+## Email Security Assessment Results
+
+### DNS Configuration
+| Check | Result | Risk |
+|-------|--------|------|
+| DMARC Policy | p=none | CRITICAL |
+| SPF Strictness | ~all | HIGH |
+| DKIM | Configured | PASS |
+
+### Phishing Simulation Results (if authorized)
+| Metric | Result |
+|--------|--------|
+| Emails sent | X |
+| Emails opened | X (X%) |
+| Links clicked | X (X%) |
+| Credentials entered | X (X%) |
+| Reports by employees | X (X%) |
+```
+
+## Skill Levels
+
+| Level | Activities |
+|-------|-----------|
+| BEGINNER | DNS record analysis, manual DMARC check |
+| INTERMEDIATE | GoPhish setup, basic campaign execution |
+| ADVANCED | Spear phishing with OSINT targeting, evasion techniques |
+| EXPERT | BEC scenario design, multi-stage campaigns |
+
+## Remediation Recommendations
+
+For `p=none` DMARC:
+```dns
+v=DMARC1; p=reject; rua=mailto:dmarc-reports@domain.com; pct=100
+```
+
+For SPF `~all`:
+```dns
+v=spf1 include:spf.protection.outlook.com -all
+```
+
+## Log Activity
+
+```bash
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py log \
+  --skill rt-exploit-phishing \
+  --phase exploitation \
+  --cmd "dig _dmarc.target.com TXT" \
+  --output "DMARC p=none confirmed"
+```
+
+## Resources
+- GoPhish: github.com/gophish/gophish
+- DMARC Guide: dmarc.org
+- SPF Record Syntax: openspf.org
+- Email Security Testing: emailsecuritygrader.com

package/packaged-assets/.agents/skills/rt-exploit-phishing/templates/README.md

@@ -0,0 +1,4 @@
+# Phishing Simulation Templates
+
+Store client-approved awareness templates here. Do not include live credential-harvesting pages or deceptive production-ready templates.
+

package/packaged-assets/.agents/skills/rt-exploit-phishing/workflow.md

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