tribunal-kit 1.0.0 → 2.4.0

package/.agent/skills/red-team-tactics/SKILL.md

@@ -1,199 +1,201 @@
 ---
 name: red-team-tactics
 description: Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting.
-allowed-tools: Read, Glob, Grep
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 1.0.0
+last-updated: 2026-03-12
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 ---
 
-# Red Team Tactics
+# Red Team & Penetration Testing Principles
 
-> Adversary simulation principles based on MITRE ATT&CK framework.
+> A red team engagement is a controlled attack.
+> The goal is to find what a real attacker would find — before they do.
+
+⚠️ **These techniques are for authorized security testing only. Unauthorized use is illegal.**
 
 ---
 
-## 1. MITRE ATT&CK Phases
+## Engagement Scope First
 
-### Attack Lifecycle
+Before any testing activity:
 
-```
-RECONNAISSANCE → INITIAL ACCESS → EXECUTION → PERSISTENCE
-       ↓              ↓              ↓            ↓
-   PRIVILEGE ESC → DEFENSE EVASION → CRED ACCESS → DISCOVERY
-       ↓              ↓              ↓            ↓
-LATERAL MOVEMENT → COLLECTION → C2 → EXFILTRATION → IMPACT
-```
+1. **Written authorization** — who authorized this engagement and in what scope?
+2. **Scope definition** — which systems, IPs, domains, time windows are in scope?
+3. **Rules of engagement** — what is prohibited? (production data access, social engineering of specific roles, DDoS)
+4. **Emergency contact** — who do you call if you discover a critical live breach mid-engagement?
+5. **Deconfliction** — does the blue team know an engagement is running, or is it blind?
 
-### Phase Objectives
-
-| Phase | Objective |
-|-------|-----------|
-| **Recon** | Map attack surface |
-| **Initial Access** | Get first foothold |
-| **Execution** | Run code on target |
-| **Persistence** | Survive reboots |
-| **Privilege Escalation** | Get admin/root |
-| **Defense Evasion** | Avoid detection |
-| **Credential Access** | Harvest credentials |
-| **Discovery** | Map internal network |
-| **Lateral Movement** | Spread to other systems |
-| **Collection** | Gather target data |
-| **C2** | Maintain command channel |
-| **Exfiltration** | Extract data |
+No authorization = no testing.
 
 ---
 
-## 2. Reconnaissance Principles
+## Attack Phases (Based on MITRE ATT&CK)
 
-### Passive vs Active
+### 1. Reconnaissance
+Passive and active information gathering before touching the target.
 
-| Type | Trade-off |
-|------|-----------|
-| **Passive** | No target contact, limited info |
-| **Active** | Direct contact, more detection risk |
+**Passive (no target contact):**
+- DNS lookup: `nslookup`, `dig`, certificate transparency logs
+- OSINT: LinkedIn for employee names/roles, GitHub for leaked configs, Shodan for exposed infrastructure
 
-### Information Targets
+**Active (target is contacted):**
+- Port scanning: `nmap -sV -sC <target>`
+- Web tech detection: `whatweb`, `wappalyzer`
+- Subdomain enumeration: `amass`, `subfinder`
 
-| Category | Value |
-|----------|-------|
-| Technology stack | Attack vector selection |
-| Employee info | Social engineering |
-| Network ranges | Scanning scope |
-| Third parties | Supply chain attack |
+### 2. Initial Access
+How does an attacker get their first foothold?
 
----
+Common vectors:
+- Phishing (credential harvest or malicious attachment)
+- Exposed admin interfaces with default or weak credentials
+- Publicly exposed vulnerable services (`searchsploit`, `nuclei`)
+- Supply chain compromise (malicious npm package, CI/CD injection)
 
-## 3. Initial Access Vectors
+### 3. Persistence
+Maintaining access after initial compromise:
 
-### Selection Criteria
+- Scheduled tasks / cron jobs
+- Web shells on compromised web servers
+- New user accounts with admin rights
+- SSH authorized_keys injection
 
-| Vector | When to Use |
-|--------|-------------|
-| **Phishing** | Human target, email access |
-| **Public exploits** | Vulnerable services exposed |
-| **Valid credentials** | Leaked or cracked |
-| **Supply chain** | Third-party access |
+### 4. Lateral Movement
+Moving from initial foothold to higher-value targets:
 
----
+- Pass-the-hash / pass-the-ticket (Active Directory)
+- SSH key reuse across hosts
+- Credential reuse (if one service is compromised, others sharing the password are vulnerable)
+- Internal network scanning to map new targets
 
-## 4. Privilege Escalation Principles
+### 5. Exfiltration
+Getting data out without triggering alerts:
 
-### Windows Targets
+- Small, slow transfers to blend with normal traffic
+- Staging data in cloud storage linked to attacker-controlled accounts
+- DNS exfiltration (for heavily monitored networks)
 
-| Check | Opportunity |
-|-------|-------------|
-| Unquoted service paths | Write to path |
-| Weak service permissions | Modify service |
-| Token privileges | Abuse SeDebug, etc. |
-| Stored credentials | Harvest |
+---
 
-### Linux Targets
+## Common Vulnerability Targets
 
-| Check | Opportunity |
-|-------|-------------|
-| SUID binaries | Execute as owner |
-| Sudo misconfiguration | Command execution |
-| Kernel vulnerabilities | Kernel exploits |
-| Cron jobs | Writable scripts |
+| Target | What to Test |
+|---|---|
+| Web applications | OWASP Top 10, auth bypass, IDOR, SSRF |
+| APIs | Object-level authorization, mass assignment, rate limiting |
+| Authentication | Brute force protection, token entropy, password reset flow |
+| Secrets | Exposed env files, git history, CI/CD environment variables |
+| Third-party integrations | Webhook validation, OAuth redirect URI validation |
+| Infrastructure | Open S3 buckets, exposed admin ports, default credentials |
 
 ---
 
-## 5. Defense Evasion Principles
+## Detection Evasion (for Authorized Testing)
 
-### Key Techniques
+When testing detection capabilities:
 
-| Technique | Purpose |
-|-----------|---------|
-| LOLBins | Use legitimate tools |
-| Obfuscation | Hide malicious code |
-| Timestomping | Hide file modifications |
-| Log clearing | Remove evidence |
+- Slow scan rates to stay under IDS thresholds
+- Use legitimate user agents and headers
+- Blend with normal traffic patterns
+- Test from IP ranges the organization wouldn't expect
 
-### Operational Security
+---
 
-- Work during business hours
-- Mimic legitimate traffic patterns
-- Use encrypted channels
-- Blend with normal behavior
+## Reporting Format
 
----
+```markdown
+# Red Team Report: [Engagement Name]
 
-## 6. Lateral Movement Principles
+## Executive Summary
+[2–3 sentences: what was tested, biggest risk found, business impact]
 
-### Credential Types
+## Scope
+[Systems tested, date range, authorization reference]
 
-| Type | Use |
-|------|-----|
-| Password | Standard auth |
-| Hash | Pass-the-hash |
-| Ticket | Pass-the-ticket |
-| Certificate | Certificate auth |
+## Critical Findings
 
-### Movement Paths
+### CRIT-01: [Title]
+**Risk:** Critical
+**CVSS:** 9.8
+**Description:** [What the vulnerability is]
+**Evidence:** [Screenshot, payload, response]
+**Impact:** [What an attacker could do]
+**Remediation:** [Specific fix with code or config example]
 
-- Admin shares
-- Remote services (RDP, SSH, WinRM)
-- Exploitation of internal services
+## Attack Narrative
+[Chronological story of the full attack path from initial access to objective]
 
----
+## Remediation Priority
+| Finding | Severity | Fix By |
+|---|---|---|
+```
 
-## 7. Active Directory Attacks
+---
 
-### Attack Categories
+## Ethical Boundaries
 
-| Attack | Target |
-|--------|--------|
-| Kerberoasting | Service account passwords |
-| AS-REP Roasting | Accounts without pre-auth |
-| DCSync | Domain credentials |
-| Golden Ticket | Persistent domain access |
+- Stop immediately if you discover evidence of an active breach by a real attacker — report it, don't continue testing
+- Don't access, copy, or delete real user data even if you can
+- Document everything — every command run, every finding noted
+- Brief the client team before leaving — no surprises in the report
 
 ---
 
-## 8. Reporting Principles
+## Output Format
 
-### Attack Narrative
+When this skill produces a recommendation or design decision, structure your output as:
 
-Document the full attack chain:
-1. How initial access was gained
-2. What techniques were used
-3. What objectives were achieved
-4. Where detection failed
+```
+━━━ Red Team Tactics Recommendation ━━━━━━━━━━━━━━━━
+Decision:    [what was chosen / proposed]
+Rationale:   [why — one concise line]
+Trade-offs:  [what is consciously accepted]
+Next action: [concrete next step for the user]
+─────────────────────────────────────────────────
+Pre-Flight:  ✅ All checks passed
+             or ❌ [blocking item that must be resolved first]
+```
 
-### Detection Gaps
 
-For each successful technique:
-- What should have detected it?
-- Why didn't detection work?
-- How to improve detection
 
 ---
 
-## 9. Ethical Boundaries
+## 🤖 LLM-Specific Traps
 
-### Always
+AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
 
-- Stay within scope
-- Minimize impact
-- Report immediately if real threat found
-- Document all actions
+1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
+2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
+3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
+4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
 
-### Never
+---
 
-- Destroy production data
-- Cause denial of service (unless scoped)
-- Access beyond proof of concept
-- Retain sensitive data
+## 🏛️ Tribunal Integration (Anti-Hallucination)
 
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 10. Anti-Patterns
+### ❌ Forbidden AI Tropes
 
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Rush to exploitation | Follow methodology |
-| Cause damage | Minimize impact |
-| Skip reporting | Document everything |
-| Ignore scope | Stay within boundaries |
+1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
+2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
+3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
 
----
+### ✅ Pre-Flight Self-Audit
+
+Review these questions before confirming output:
+```
+✅ Did I rely ONLY on real, verified tools and methods?
+✅ Is this solution appropriately scoped to the user's constraints?
+✅ Did I handle potential failure modes and edge cases?
+✅ Have I avoided generic boilerplate that doesn't add value?
+```
+
+### 🛑 Verification-Before-Completion (VBC) Protocol
 
-> **Remember:** Red team simulates attackers to improve defenses, not to cause harm.
+**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
+- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
+- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.