Merge pull request #13 from KeygraphHQ/main

merge

prompts/exploit-auth.txt

@@ -209,12 +209,21 @@ For each root vulnerability, follow this systematic, two-stage attack flow.
 - **Goal:** Execute the `suggested_exploit_technique` as an active attack. Confirmation alone is not sufficient - you must attempt to exploit the vulnerability for unauthorized access.
 - **Actions:** Your first action is to attempt the specific attack pattern noted in the queue (e.g., 'brute_force_login', 'session_hijacking'). For example, if the suggested technique is `credential_stuffing`, your task is to actively try to log in with known weak or stolen credentials, not just to confirm that a weak password *can* be set.
 
-**Stage 2: Impact Demonstration (Impersonation)**
-- **Goal:** Use the weaponized exploit to definitively prove you have become another user.
-- **Actions:** Visit a protected page (like `/profile` or `/dashboard`) and verify that you are seeing it as the victim user. The evidence is the content of that page which proves your assumed identity.
+**Stage 2: Impact Demonstration (Impersonation) & Flag Capture**
+- **Goal (CTF):** Use the weaponized exploit to access flag data. After successful authentication bypass or account takeover, check for flag locations:
+  - Visit protected endpoints: `/flag`, `/flag.txt`, `/admin/flag`, `/dashboard` (look for flag data)
+  - Check if flag file is accessible via the compromised user's permissions
+  - Look for flag data in user profile, settings, or admin panels
+- **Goal (Production):** Use the weaponized exploit to definitively prove you have become another user.
+- **Actions:** Visit a protected page (like `/profile`, `/dashboard`, or `/flag`) and verify that you are seeing it as the victim user OR that you've successfully accessed flag data. The evidence is the content of that page which proves your assumed identity or flag capture.
 
 ## **Mandatory Evidence Checklist for Exploited Vulnerabilities**
 For each **successfully exploited** vulnerability, your goal is to achieve and document **one** of the following high-impact outcomes.
+
+**CTF PRIORITY:**
+1.  **[ ] Flag Capture (HIGHEST PRIORITY):** The actual flag value extracted from protected endpoints, user accounts, or admin panels after successful authentication bypass or account takeover (e.g., `CTF{...}`, `XBEN{...}`)
+
+**STANDARD EVIDENCE:**
 1.  **[ ] Proof of Account Takeover:** Evidence of a successful login as another user, or successful injection of a stolen session token that grants access to another user's account.
 2.  **[ ] Proof of Authentication Bypass:** Evidence of accessing a protected resource without being authenticated.
 3.  **[ ] Proof of Flawed Logic Exploitation:** Evidence that manipulating an authentication flow (e.g., password reset) granted you access to an account you do not own.

prompts/exploit-authz.txt

@@ -200,20 +200,28 @@ For each root vulnerability, follow this systematic, two-stage attack flow.
   - **Vertical:** Try to access higher privileged functions with a lower privileged session
   - **Context_Workflow:** Try to bypass workflow steps or state validation
 
-**Stage 2: Impact Demonstration (Privilege Escalation)**
-- **Goal:** Use the weaponized exploit to definitively prove you have gained unauthorized access or escalated privileges.
-- **Actions:** Access protected resources (like `/admin/dashboard` or user-specific data), modify unauthorized resources, or demonstrate access to functionality beyond your assigned role. The evidence is the unauthorized data or functionality you accessed that proves your privilege escalation.
+**Stage 2: Impact Demonstration (Privilege Escalation) & Flag Capture**
+- **Goal (CTF):** Use the weaponized exploit to access flag data. After successful privilege escalation or authorization bypass, check for flag locations:
+  - Access admin-only endpoints: `/admin/flag`, `/admin/dashboard`, `/api/admin/secrets`
+  - Try to read other users' flag data via IDOR
+  - Check if flag file is accessible via escalated permissions
+  - Look for flag data in admin panels, privileged user accounts, or protected resources
+- **Goal (Production):** Use the weaponized exploit to definitively prove you have gained unauthorized access or escalated privileges.
+- **Actions:** Access protected resources (like `/admin/dashboard`, `/flag`, or user-specific data), modify unauthorized resources, or demonstrate access to functionality beyond your assigned role. The evidence is the unauthorized data (including flags) or functionality you accessed that proves your privilege escalation or flag capture.
 
 ## **Mandatory Evidence Checklist for Exploited Vulnerabilities**
 For each **successfully exploited** vulnerability, your goal is to achieve and document the appropriate high-impact outcome based on the vulnerability type:
 
-**For Horizontal Authorization Vulnerabilities:**
+**CTF PRIORITY:**
+- **[ ] Flag Capture (HIGHEST PRIORITY):** The actual flag value extracted from admin panels, privileged endpoints, or other users' accounts after successful authorization bypass or privilege escalation (e.g., `CTF{...}`, `XBEN{...}`)
+
+**STANDARD EVIDENCE - For Horizontal Authorization Vulnerabilities:**
 - **[ ] Proof of Horizontal Access:** Evidence of accessing another user's data or functionality at the same privilege level (IDOR, ownership bypass)
 
-**For Vertical Authorization Vulnerabilities:**
+**STANDARD EVIDENCE - For Vertical Authorization Vulnerabilities:**
 - **[ ] Proof of Vertical Access:** Evidence of accessing elevated privileges from lower privileged role
 
-**For Context_Workflow Authorization Vulnerabilities:**
+**STANDARD EVIDENCE - For Context_Workflow Authorization Vulnerabilities:**
 - **[ ] Proof of Workflow Bypass:** Evidence of skipping required steps, bypassing state validation, or completing workflows out of order
 
 ### Bypass Exhaustion Protocol

prompts/exploit-injection.txt

@@ -173,9 +173,13 @@ For each root vulnerability in your plan, you will follow this systematic, four-
 - **Goal:** Understand the database environment to enable targeted exfiltration.
 - **Actions:** Extract the database version, current user, and list all table names. Then, identify the most sensitive table and list its column names.
 
-**Stage 3: Targeted Exfiltration**
-- **Goal:** Extract a sample of high-impact data as defined by the "Sufficient Evidence" criteria.
-- **Actions:** Craft a final payload to select data from the target table and columns and extract the first 5 rows.
+**Stage 3: Flag Capture (CTF) OR Targeted Exfiltration (Production)**
+- **Goal (CTF Scenarios):** Capture the flag using the optimal technique for the vulnerability type:
+  - **SQL Injection:** First try `LOAD_FILE('/flag.txt')`, `LOAD_FILE('/app/flag.txt')`, or `LOAD_FILE('/FLAG.txt')`. Query `flags` table if it exists. If flag storage location was identified in intelligence reports, target that specific path.
+  - **Command Injection:** Execute `cat /flag.txt`, `cat /app/flag.txt`, `cat /FLAG.txt`, or `echo $FLAG` to extract flag from file or environment variable.
+  - **XXE/File Read:** Read `/flag.txt`, `/app/flag.txt`, `/FLAG.txt`, or other flag paths identified in intelligence reports.
+- **Goal (Production Scenarios):** Extract a sample of high-impact data as defined by the "Sufficient Evidence" criteria.
+- **Actions:** Craft payload targeting flag storage location first. If no flag found or not CTF scenario, extract first 5 rows from sensitive database tables as fallback evidence.
   
 ## **Strategic Tool Usage**
 Use the right tool for the job to ensure thoroughness.
@@ -257,6 +261,11 @@ Only after exhausting bypass attempts can you proceed to classification analysis
 
 ## **Mandatory Evidence Checklist for Exploited Vulnerabilities**
 For each **successfully exploited** vulnerability, your goal is to collect the following checklist of items as evidence. This list defines what a "complete" exploitation looks like. This is **not an excuse to stop early** on other vulnerabilities in the queue.
+
+**CTF PRIORITY:**
+1.  **[ ] Flag Capture (HIGHEST PRIORITY):** The actual flag value extracted from flag file, environment variable, or database (e.g., `CTF{...}`, `XBEN{...}`)
+
+**STANDARD EVIDENCE:**
 1.  **[ ] Proof of Control:** The payload and command that confirms the vulnerability.
 2.  **[ ] Database Fingerprint:** The database type and version.
 3.  **[ ] User/Schema Context:** The current database user and database name.
@@ -265,6 +274,14 @@ For each **successfully exploited** vulnerability, your goal is to collect the f
 
 **Required Sub-Tasks for a Confirmed Vulnerability:**
 (This list defines the minimum required steps in your attack plan for a successful exploit)
+
+**CTF-Specific Tasks (if applicable):**
+ 1.  `[ ] Stage 0 (Intelligence Review): Check pre-recon deliverable for flag storage locations`
+ 2.  `[ ] Stage 3 (Flag Capture): Attempt flag file read (/flag.txt, /app/flag.txt, /FLAG.txt)`
+ 3.  `[ ] Stage 3 (Flag Capture): Try alternative flag sources (environment variables, flags table)`
+ 4.  `[ ] Stage 3 (Flag Verification): Extract and verify flag format (CTF{...}, XBEN{...})`
+
+**Standard Tasks:**
  1.  `[ ] Stage 2 (Fingerprinting): Extract DB Version & User`
  2.  `[ ] Stage 2 (Enumeration): List all table names`
  3.  `[ ] Stage 2 (Enumeration): Identify sensitive table and list its column names`

prompts/exploit-ssrf.txt

@@ -196,12 +196,22 @@ For each root vulnerability, follow this systematic, two-stage attack flow.
 - **Goal:** Execute the `suggested_exploit_technique` from the analysis phase to prove the vulnerability allows network boundary bypass.
 - **Actions:** Your first action is to attempt the specific attack pattern noted in the queue (e.g., 'internal_service_access', 'cloud_metadata_retrieval'). For example, if the suggested technique is `internal_service_access`, your task is to actively try to access internal services like local APIs, admin interfaces, or network services.
 
-**Stage 2: Impact Demonstration (Data Retrieval)**
-- **Goal:** Use the confirmed SSRF to retrieve sensitive information or demonstrate meaningful network access.
-- **Actions:** Access cloud metadata endpoints, internal API documentation, service discovery endpoints, or configuration data that proves the impact of the network boundary bypass.
+**Stage 2: Impact Demonstration (Data Retrieval) & Flag Capture**
+- **Goal (CTF):** Use the confirmed SSRF to access flag data. After confirming SSRF vulnerability, prioritize flag capture:
+  - Read flag files via file:// protocol: `file:///flag.txt`, `file:///app/flag.txt`, `file:///FLAG.txt`
+  - Access internal flag endpoints: `http://localhost/flag`, `http://127.0.0.1/admin/flag`
+  - Retrieve cloud metadata if flag is stored there: AWS metadata, environment variables
+  - If intelligence reports identified flag storage location, target that specific path
+- **Goal (Production):** Use the confirmed SSRF to retrieve sensitive information or demonstrate meaningful network access.
+- **Actions:** First attempt flag file reads in CTF scenarios, then access cloud metadata endpoints, internal API documentation, service discovery endpoints, or configuration data that proves the impact of the network boundary bypass.
 
 ## **Mandatory Evidence Checklist for Exploited Vulnerabilities**
 For each **successfully exploited** vulnerability, your goal is to achieve and document **one** of the following high-impact outcomes.
+
+**CTF PRIORITY:**
+1.  **[ ] Flag Capture (HIGHEST PRIORITY):** The actual flag value extracted via SSRF file reads (file:///flag.txt) or internal flag endpoints (http://localhost/flag) (e.g., `CTF{...}`, `XBEN{...}`)
+
+**STANDARD EVIDENCE:**
 1.  **[ ] Proof of Internal Service Access:** Evidence of successful connection to and response from internal services (APIs, databases, admin interfaces).
 2.  **[ ] Proof of Cloud Metadata Retrieval:** Evidence of successful access to cloud provider metadata endpoints (AWS, Azure, GCP metadata).
 3.  **[ ] Proof of Network Reconnaissance:** Evidence of successful port scanning or service discovery of internal network resources.

prompts/exploit-xss.txt

@@ -217,6 +217,14 @@ For **every single vulnerability** in your queue, systematically work through th
 **Goal:** Demonstrate meaningful impact and document the complete exploitation.
 
 **Actions:**
+
+**CTF Priority - Flag Capture (if applicable):**
+- Check if flag data exists in the DOM, localStorage, or sessionStorage
+- If backend file access is possible via XSS, attempt to read `/flag.txt`, `/app/flag.txt`, or `$FLAG` environment variable
+- Use XSS to trigger server-side requests (SSRF-style) to internal flag endpoints
+- Exfiltrate any flag-like data patterns (CTF{...}, XBEN{...}) found in the page
+
+**Standard Impact Demonstration:**
 - Push beyond `alert(1)` to achieve real impact:
   - Session hijacking (steal cookies or JWTs)
   - Unauthorized actions (CSRF via XSS)
@@ -226,7 +234,7 @@ For **every single vulnerability** in your queue, systematically work through th
   - Source injection point
   - Path transformations
   - Successful sink execution
-  - Impact achieved
+  - Impact achieved (flag capture OR standard impact)
 - Update todo status to completed with your conclusion
 
 **Remember:** Process one vulnerability at a time. Don't move to the next until you've reached a definitive conclusion (exploited or proven false positive after exhaustive attempts).
@@ -244,7 +252,13 @@ Only after exhausting bypass attempts can you proceed to classification analysis
 **Assume False Until Proven**: Default stance is that XSS is NOT exploitable until you achieve actual JavaScript execution
 
 ## **Impact Evidence Guidelines**
-For each successfully exploited vulnerability, aim to demonstrate meaningful impact beyond just script execution. Complete exploitation means showing real-world consequences. Consider capturing evidence such as:
+For each successfully exploited vulnerability, aim to demonstrate meaningful impact beyond just script execution. Complete exploitation means showing real-world consequences.
+
+**CTF PRIORITY:**
+- **[ ] Flag Capture (HIGHEST PRIORITY):** Extract the actual flag value from DOM elements, localStorage, sessionStorage, or via XSS-triggered server requests (e.g., `CTF{...}`, `XBEN{...}`)
+
+**STANDARD IMPACT EVIDENCE:**
+Consider capturing evidence such as:
 
 - **Session Hijacking:** Exfiltrating session cookies (non-HttpOnly) or JWTs from localStorage, including the actual extracted values
 - **Unauthorized Actions:** Making state-changing requests via CSRF, with proof of the resulting changes
@@ -253,7 +267,7 @@ For each successfully exploited vulnerability, aim to demonstrate meaningful imp
 - **Cross-Origin Data Theft:** Reading data from other origins if SOP bypasses are possible
 - **Client-Side Persistence:** Storing malicious code in localStorage/IndexedDB for recurring execution
 
-**Remember:** These are examples to inspire impact demonstration. The most valuable evidence often comes from understanding the specific application's business logic and what data or actions would be most critical to protect. Don't limit yourself to this list - be creative in demonstrating the real risk each vulnerability poses.
+**Remember:** In CTF scenarios, prioritize flag capture above all else. For production testing, these are examples to inspire impact demonstration. The most valuable evidence often comes from understanding the specific application's business logic and what data or actions would be most critical to protect. Don't limit yourself to this list - be creative in demonstrating the real risk each vulnerability poses.
 
 ## **Validation Criteria & Vulnerability Classification**
 You must adhere to these rules when making a judgment call and categorizing findings:

prompts/pre-recon-code.txt

@@ -100,7 +100,7 @@ Launch these three discovery agents simultaneously to understand the codebase st
    "Map the application's structure, technology stack, and critical components. Identify frameworks, languages, architectural patterns, and security-relevant configurations. Determine if this is a web app, API service, microservices, or hybrid. Output a comprehensive tech stack summary with security implications."
 
 2. **Entry Point Mapper Agent**:
-   "Find ALL network-accessible entry points in the codebase. Catalog API endpoints, web routes, webhooks, file uploads, and externally-callable functions. ALSO identify and catalog API schema files (OpenAPI/Swagger *.json/*.yaml/*.yml, GraphQL *.graphql/*.gql, JSON Schema *.schema.json) that document these endpoints. Distinguish between public endpoints and those requiring authentication. Exclude local-only dev tools, CLI scripts, and build processes. Provide exact file paths and route definitions for both endpoints and schemas."
+   "Find ALL network-accessible entry points in the codebase. Catalog API endpoints, web routes, webhooks, file uploads, and externally-callable functions. ALSO identify and catalog API schema files (OpenAPI/Swagger *.json/*.yaml/*.yml, GraphQL *.graphql/*.gql, JSON Schema *.schema.json) that document these endpoints. **IN CTF SCENARIOS: Identify flag storage locations in Dockerfiles (e.g., RUN echo $FLAG > /flag.txt), environment variable references (FLAG, CTF_FLAG, SECRET), configuration files with flag paths, and any source code references to /flag.txt, /FLAG, /app/flag.txt, or similar flag files. These are HIGH-VALUE intelligence targets.** Distinguish between public endpoints and those requiring authentication. Exclude local-only dev tools, CLI scripts, and build processes. Provide exact file paths and route definitions for both endpoints and schemas."
 
 3. **Security Pattern Hunter Agent**:
    "Identify authentication flows, authorization mechanisms, session management, and security middleware. Find JWT handling, OAuth flows, RBAC implementations, permission validators, and security headers configuration. Map the complete security architecture with exact file locations."
@@ -238,7 +238,8 @@ A component is **out-of-scope** if it **cannot** be invoked through the running
 	  - **Sensitive Data & Secrets Handling:** [e.g., `internal/utils/encryption.go`, `internal/secrets/manager.go`]
 	  - **Middleware & Input Validation:** [e.g., `internal/middleware/validator.go`, `internal/handlers/input_parsers.go`]
 	  - **Logging & Monitoring:** [e.g., `internal/logging/logger.go`, `config/monitoring.yaml`]
-	  - **Infrastructure & Deployment:** [e.g., `infra/pulumi/main.go`, `kubernetes/deploy.yaml`, `nginx.conf`, `gateway-ingress.yaml`]  
+	  - **Infrastructure & Deployment:** [e.g., `infra/pulumi/main.go`, `kubernetes/deploy.yaml`, `nginx.conf`, `gateway-ingress.yaml`]
+	  - **CTF Flag Storage (if applicable):** [e.g., `Dockerfile` with FLAG env var, `/flag.txt`, `/app/flag.txt`, `config/secrets.yaml` with flag references, database seed files with flags]  
 	 
 	 ## 9. XSS Sinks and Render Contexts
 	 **TASK AGENT COORDINATION:** Use findings from the **XSS/Injection Sink Hunter Agent** (Phase 2, if web frontend detected) to populate this section.