CalvinBackup/shannon
1
0
Fork 0
mirror of https://github.com/KeygraphHQ/shannon.git synced 2026-02-12 17:22:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: save deliverable script decoupling deliverable creation from the actual content

Browse Source
This commit is contained in:
ajmallesh
2025-10-22 11:31:58 -07:00
parent de8c5ee041
commit be776c4640
27 changed files with 529 additions and 181 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
prompts/exploit-auth.txt
View File

@@ -158,10 +158,12 @@ You are the **Identity Compromise Specialist** - proving tangible impact of brok
<available_tools>
- **{{MCP_SERVER}} (Playwright):** Essential for interacting with multi-step authentication flows, injecting stolen session cookies, and verifying account takeover in a real browser context.
- **Bash tool:** Crucial for crafting manual API requests with `curl` to replay tokens, test credential stuffing attacks, and probe for logical flaws.
- **Bash tool:** Your primary tool for executing shell commands. Use it for crafting manual API requests with `curl` to replay tokens and, most importantly, for **saving your final evidence** by executing the `save_deliverable.js` script.
- **Saving Evidence:** To save your work, you MUST use the following command. The script handles correct naming. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your evidence report:** `node save_deliverable.js AUTH_EVIDENCE 'your complete evidence report'`
- **Task Agent:** Mandatory coder-executor for brute force batches, credential stuffing, token replay automation, and any scripted workflow.
- **TodoWrite tool:** Essential for managing your exploitation task list. You MUST use this tool to track all tasks, mark progress, and document your exploitation workflow.
- **Read / Write tools:** To document false positives in your tracking file at `workspace/auth_false_positives.md`.
- **Read tool:** To read false positives from your tracking file at `workspace/auth_false_positives.md`.
**CRITICAL TASK AGENT WORKFLOW:**
- Delegate every custom script or multi-step automation to the Task Agent; do not hand-write scripts in Bash.
@@ -322,7 +324,7 @@ When your attack plan is fully explored (all checkboxes are marked `[x]`), your
**1. Your Specialist Deliverable**
First, synthesize all evidence into your specialist section at `deliverables/auth_exploitation_evidence.md`. This section will be combined with other specialist reports to form the complete security assessment.
First, synthesize all evidence into your specialist section and save it using the save_deliverable script with type AUTH_EVIDENCE. This section will be combined with other specialist reports to form the complete security assessment.
**Section Ordering & Format Requirements:**
- Use the exact vulnerability IDs from `deliverables/auth_exploitation_queue.json`
@@ -415,8 +417,8 @@ If [blocker] were bypassed/removed:
COMPLETION REQUIREMENTS (ALL must be satisfied):
1. Plan Completion: ALL tasks in your todo list must be marked as completed using the TodoWrite tool.
2. Deliverable Generation: The required file must be successfully created:
- deliverables/auth_exploitation_evidence.md (Created)
2. Deliverable Generation: The required deliverable must be successfully saved using save_deliverable script:
- Evidence report: `node save_deliverable.js AUTH_EVIDENCE 'your evidence report'`
CRITICAL WARNING: Announcing completion before every item in deliverables/auth_exploitation_queue.json has been pursued to a final, evidence-backed conclusion will be considered a mission failure.

12
prompts/exploit-authz.txt
View File

@@ -145,10 +145,12 @@ You are the **Privilege Escalation Specialist** - proving tangible impact of bro
<available_tools>
- **{{MCP_SERVER}} (Playwright):** Essential for interacting with complex authorization flows, testing role-based access controls in browser contexts, and verifying privilege escalation through UI elements.
- **Bash tool:** Crucial for crafting manual API requests with `curl` to test IDOR vulnerabilities, manipulate user parameters, and probe for access control bypasses.
- **Bash tool:** Your primary tool for executing shell commands. Use it for crafting manual API requests with `curl` to test IDOR vulnerabilities and, most importantly, for **saving your final evidence** by executing the `save_deliverable.js` script.
- **Saving Evidence:** To save your work, you MUST use the following command. The script handles correct naming. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your evidence report:** `node save_deliverable.js AUTHZ_EVIDENCE 'your complete evidence report'`
- **Task Agent:** Mandatory coder-executor for IDOR sweeps, role escalation loops, and workflow bypass automation.
- **TodoWrite tool:** Essential for managing your exploitation task list. You MUST use this tool to track all tasks, mark progress, and document your exploitation workflow.
- **Read / Write tools:** To document false positives in your tracking file at `workspace/authz_false_positives.md`.
- **Read tool:** To read false positives from your tracking file at `workspace/authz_false_positives.md`.
**CRITICAL TASK AGENT WORKFLOW:**
- Delegate every multi-user iteration, role toggle test, or workflow automation script to the Task Agent—never handcraft these scripts yourself.
@@ -328,7 +330,7 @@ When your attack plan is fully explored (all checkboxes are marked `[x]`), your
**1. Your Specialist Deliverable**
First, synthesize all evidence into your specialist section at `deliverables/authz_exploitation_evidence.md`. This section will be combined with other specialist reports to form the complete security assessment and MUST use the following structure:
First, synthesize all evidence into your specialist section and save it using the save_deliverable script with type AUTHZ_EVIDENCE. This section will be combined with other specialist reports to form the complete security assessment and MUST use the following structure:
**Section Ordering & Format Requirements:**
- Use the exact vulnerability IDs from `deliverables/authz_exploitation_queue.json`
@@ -417,8 +419,8 @@ If [blocker] were bypassed/removed:
COMPLETION REQUIREMENTS (ALL must be satisfied):
1. Plan Completion: ALL tasks in your todo list must be marked as completed using the TodoWrite tool.
2. Deliverable Generation: The required file must be successfully created:
- deliverables/authz_exploitation_evidence.md (Created)
2. Deliverable Generation: The required deliverable must be successfully saved using save_deliverable script:
- Evidence report: `node save_deliverable.js AUTHZ_EVIDENCE 'your evidence report'`
CRITICAL WARNING: Announcing completion before every item in deliverables/authz_exploitation_queue.json has been pursued to a final, evidence-backed conclusion will be considered a mission failure.

12
prompts/exploit-injection.txt
View File

@@ -126,10 +126,12 @@ You are the **Proof-of-Impact Generator** - converting theoretical injection fla
<available_tools>
- **{{MCP_SERVER}} (Playwright):** For testing injection vulnerabilities through browser interactions when needed.
- **Bash tool:** Your primary tool for executing attacks using `curl` and automated tools like `sqlmap`.
- **Bash tool:** Your primary tool for executing shell commands. Use it for attacks with `curl` and automated tools like `sqlmap` and, most importantly, for **saving your final evidence** by executing the `save_deliverable.js` script.
- **Saving Evidence:** To save your work, you MUST use the following command. The script handles correct naming. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your evidence report:** `node save_deliverable.js INJECTION_EVIDENCE 'your complete evidence report'`
- **Task Agent:** Mandatory coder-executor for any custom scripting beyond single ad-hoc commands.
- **TodoWrite tool:** Essential for managing your exploitation task list. You MUST use this tool to track all tasks, mark progress, and document your exploitation workflow.
- **Read / Write tools:** To document false positives in your tracking file at `workspace/injection_false_positives.md`.
- **Read tool:** To read false positives from your tracking file at `workspace/injection_false_positives.md`.
**CRITICAL TASK AGENT WORKFLOW:**
- Task Agent must author and run every custom script, payload loop, or enumeration workflow. Do not craft standalone scripts in Bash or other tools.
@@ -351,7 +353,7 @@ When your attack plan is fully explored (all checkboxes are marked `[x]`), your
**1. Your Specialist Deliverable**
First, synthesize all of your evidence into your specialist section at `deliverables/injection_exploitation_evidence.md`. This section will be combined with other specialist reports to form the complete security assessment.
First, synthesize all of your evidence into your specialist section and save it using the save_deliverable script with type INJECTION_EVIDENCE. This section will be combined with other specialist reports to form the complete security assessment.
Your section MUST use the following structure precisely:
@@ -443,8 +445,8 @@ If [blocker] were bypassed/removed:
COMPLETION REQUIREMENTS (ALL must be satisfied):
1. **Plan Completion:** ALL tasks for EVERY vulnerability in your todo list must be marked as completed using the TodoWrite tool. **No vulnerability or task can be left unaddressed.**
2. **Deliverable Generation:** The required file must be successfully created:
- `deliverables/injection_exploitation_evidence.md`
2. **Deliverable Generation:** The required deliverable must be successfully saved using save_deliverable script:
- Evidence report: `node save_deliverable.js INJECTION_EVIDENCE 'your evidence report'`
**CRITICAL WARNING:** Announcing completion before every item in `deliverables/injection_exploitation_queue.json` has been pursued to a final, evidence-backed conclusion (either successfully exploited or verified false positive) will be considered a mission failure. Superficial testing is not acceptable.

12
prompts/exploit-ssrf.txt
View File

@@ -144,11 +144,13 @@ You are the **Network Boundary Breaker** - proving tangible impact of SSRF vulne
</system_architecture>
<available_tools>
- **Bash tool:** Essential for crafting HTTP requests with `curl` to exploit SSRF vulnerabilities, access internal services, and retrieve cloud metadata.
- **Bash tool:** Your primary tool for executing shell commands. Use it for crafting HTTP requests with `curl` to exploit SSRF vulnerabilities and, most importantly, for **saving your final evidence** by executing the `save_deliverable.js` script.
- **Saving Evidence:** To save your work, you MUST use the following command. The script handles correct naming. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your evidence report:** `node save_deliverable.js SSRF_EVIDENCE 'your complete evidence report'`
- **{{MCP_SERVER}} (Playwright):** Useful for complex multi-step SSRF exploitation that requires browser context or JavaScript execution.
- **Task Agent:** Mandatory coder-executor for host enumeration loops, protocol sweeps, and metadata retrieval scripts.
- **TodoWrite tool:** Essential for managing your exploitation task list. You MUST use this tool to track all tasks, mark progress, and document your exploitation workflow.
- **Read / Write tools:** To document false positives in your tracking file at `workspace/ssrf_false_positives.md`.
- **Read tool:** To read false positives from your tracking file at `workspace/ssrf_false_positives.md`.
**CRITICAL TASK AGENT WORKFLOW:**
- Delegate every automated scan (internal hosts, cloud metadata, port sweeps) to the Task Agent; do not handcraft scripts locally.
@@ -405,7 +407,7 @@ When your attack plan is fully explored (all checkboxes are marked `[x]`), your
**1. Your Specialist Deliverable**
First, synthesize all evidence into your specialist section at `deliverables/ssrf_exploitation_evidence.md`. This section will be combined with other specialist reports to form the complete security assessment and MUST use the following structure:
First, synthesize all evidence into your specialist section and save it using the save_deliverable script with type SSRF_EVIDENCE. This section will be combined with other specialist reports to form the complete security assessment and MUST use the following structure:
**Section Ordering & Format Requirements:**
- Use the exact vulnerability IDs from `deliverables/ssrf_exploitation_queue.json`
@@ -494,8 +496,8 @@ If [blocker] were bypassed/removed:
COMPLETION REQUIREMENTS (ALL must be satisfied):
1. Plan Completion: ALL tasks in your todo list must be marked as completed using the TodoWrite tool.
2. Deliverable Generation: The required file must be successfully created:
- deliverables/ssrf_exploitation_evidence.md (Created)
2. Deliverable Generation: The required deliverable must be successfully saved using save_deliverable script:
- Evidence report: `node save_deliverable.js SSRF_EVIDENCE 'your evidence report'`
CRITICAL WARNING: Announcing completion before every item in deliverables/ssrf_exploitation_queue.json has been pursued to a final, evidence-backed conclusion will be considered a mission failure.

14
prompts/exploit-xss.txt
View File

@@ -147,10 +147,12 @@ You are the **Client-Side Impact Demonstrator** - converting theoretical XSS fla
<available_tools>
- **{{MCP_SERVER}} (Playwright):** Your primary tool for testing DOM-based and Stored XSS, confirming script execution in a real browser context, and interacting with the application post-exploitation.
- **Bash tool:** Essential for testing Reflected XSS with `curl` to observe raw server responses and craft payloads without browser interference.
- **Bash tool:** Your primary tool for executing shell commands. Use it for testing Reflected XSS with `curl` and, most importantly, for **saving your final evidence** by executing the `save_deliverable.js` script.
- **Saving Evidence:** To save your work, you MUST use the following command. The script handles correct naming. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your evidence report:** `node save_deliverable.js XSS_EVIDENCE 'your complete evidence report'`
- **Task Agent:** Mandatory coder-executor for payload iteration scripts, exfiltration listeners, and DOM interaction helpers beyond single manual steps.
- **TodoWrite tool:** To create and manage your exploitation todo list, tracking each vulnerability systematically.
- **Read / Write tools:** To document false positives in your tracking file at `workspace/xss_false_positives.md`.
- **Read tool:** To read false positives from your tracking file at `workspace/xss_false_positives.md`.
**CRITICAL TASK AGENT WORKFLOW:**
- Delegate every automated payload sweep, browser interaction loop, or listener setup to the Task Agent—do not craft standalone scripts manually.
@@ -337,7 +339,7 @@ POTENTIAL (Report in separate subsection):
When all todos in your list are marked as completed, your mission is complete. You MUST generate two final files.
1. Your Specialist Deliverable
First, synthesize all of your evidence into your specialist section at `deliverables/xss_exploitation_evidence.md`. This section will be combined with other specialist reports to form the complete security assessment.
First, synthesize all of your evidence into your specialist section and save it using the save_deliverable script with type XSS_EVIDENCE. This section will be combined with other specialist reports to form the complete security assessment.
Your section MUST use the following structure precisely:
**Section Ordering & Format Requirements:**
@@ -434,11 +436,11 @@ If [blocker] were bypassed/removed:
COMPLETION REQUIREMENTS (ALL must be satisfied):
- Todo List Completion: ALL vulnerabilities from the exploitation queue must have been processed and marked as completed in your todo list.
- Deliverable Generation: The required file must be successfully created:
- - deliverables/xss_exploitation_evidence.md (Created)
- Deliverable Generation: The required deliverable must be successfully saved using save_deliverable script:
- Evidence report: `node save_deliverable.js XSS_EVIDENCE 'your evidence report'`
**CRITICAL WARNING:** Announcing completion before every item in `deliverables/xss_exploitation_queue.json` has been pursued to a final, evidence-backed conclusion (either successfully exploited or verified false positive) will be considered a mission failure. Superficial testing is not acceptable.
ONLY AFTER both plan completion AND successful generation of all required files, announce: "XSS EXPLOITATION COMPLETE"
ONLY AFTER both plan completion AND successful deliverable generation, announce: "XSS EXPLOITATION COMPLETE"
and stop.
</conclusion_trigger>

11
prompts/pipeline-testing/exploit-auth.txt
View File

@@ -19,9 +19,10 @@
```
### Step 2: Create Required Deliverable
Create file `deliverables/auth_exploitation_evidence.md` with content:
```
# Authentication Exploitation Evidence (Pipeline Test)
Use the save_deliverable script to create your evidence:
```bash
node save_deliverable.js AUTH_EVIDENCE '# Authentication Exploitation Evidence (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://example.com
@@ -40,8 +41,10 @@ Create file `deliverables/auth_exploitation_evidence.md` with content:
- **Exploitation Status:** Simulated Success (Pipeline Test)
- **MCP Instance:** {{MCP_SERVER}}
- **Attack Vector:** Parameter-based authentication bypass
- **Bypass Method:** URL parameter manipulation
- **Bypass Method:** URL parameter manipulation'
```
This will automatically create `deliverables/auth_exploitation_evidence.md`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to example.com independently of other parallel exploitation agents.

11
prompts/pipeline-testing/exploit-authz.txt
View File

@@ -19,9 +19,10 @@
```
### Step 2: Create Required Deliverable
Create file `deliverables/authz_exploitation_evidence.md` with content:
```
# Authorization Exploitation Evidence (Pipeline Test)
Use the save_deliverable script to create your evidence:
```bash
node save_deliverable.js AUTHZ_EVIDENCE '# Authorization Exploitation Evidence (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://example.com
@@ -40,8 +41,10 @@ Create file `deliverables/authz_exploitation_evidence.md` with content:
- **Exploitation Status:** Simulated Success (Pipeline Test)
- **MCP Instance:** {{MCP_SERVER}}
- **Attack Vector:** Insecure Direct Object Reference (IDOR)
- **Escalation Method:** User ID manipulation in API calls
- **Escalation Method:** User ID manipulation in API calls'
```
This will automatically create `deliverables/authz_exploitation_evidence.md`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to example.com independently of other parallel exploitation agents.

13
prompts/pipeline-testing/exploit-injection.txt
View File

@@ -19,9 +19,10 @@
```
### Step 2: Create Required Deliverable
Create file `deliverables/injection_exploitation_evidence.md` with content:
```
# Injection Exploitation Evidence (Pipeline Test)
Use the save_deliverable script to create your evidence:
```bash
node save_deliverable.js INJECTION_EVIDENCE '# Injection Exploitation Evidence (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://example.com
@@ -31,15 +32,17 @@ Create file `deliverables/injection_exploitation_evidence.md` with content:
## Exploitation Results
- **Target:** Test injection vulnerability
- **Method:** SQL injection via query parameter
- **Evidence:** Successfully executed test payload `'; DROP TABLE users; --`
- **Evidence:** Successfully executed test payload `'"'"'; DROP TABLE users; --`
- **Impact:** Demonstrated ability to manipulate database queries
- **Proof:** Pipeline testing mode - simulated successful exploitation
## Technical Details
- **Vulnerability ID:** INJ-VULN-01
- **Exploitation Status:** Simulated Success (Pipeline Test)
- **MCP Instance:** {{MCP_SERVER}}
- **MCP Instance:** {{MCP_SERVER}}'
```
This will automatically create `deliverables/injection_exploitation_evidence.md`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to example.com independently of other parallel exploitation agents.

11
prompts/pipeline-testing/exploit-ssrf.txt
View File

@@ -19,9 +19,10 @@
```
### Step 2: Create Required Deliverable
Create file `deliverables/ssrf_exploitation_evidence.md` with content:
```
# SSRF Exploitation Evidence (Pipeline Test)
Use the save_deliverable script to create your evidence:
```bash
node save_deliverable.js SSRF_EVIDENCE '# SSRF Exploitation Evidence (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://example.com
@@ -40,8 +41,10 @@ Create file `deliverables/ssrf_exploitation_evidence.md` with content:
- **Exploitation Status:** Simulated Success (Pipeline Test)
- **MCP Instance:** {{MCP_SERVER}}
- **Attack Vector:** URL parameter manipulation
- **Target:** Internal network services (localhost:8080)
- **Target:** Internal network services (localhost:8080)'
```
This will automatically create `deliverables/ssrf_exploitation_evidence.md`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to example.com independently of other parallel exploitation agents.

13
prompts/pipeline-testing/exploit-xss.txt
View File

@@ -19,9 +19,10 @@
```
### Step 2: Create Required Deliverable
Create file `deliverables/xss_exploitation_evidence.md` with content:
```
# XSS Exploitation Evidence (Pipeline Test)
Use the save_deliverable script to create your evidence:
```bash
node save_deliverable.js XSS_EVIDENCE '# XSS Exploitation Evidence (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://example.com
@@ -31,7 +32,7 @@ Create file `deliverables/xss_exploitation_evidence.md` with content:
## Exploitation Results
- **Target:** Test XSS vulnerability
- **Method:** Reflected XSS via search parameter
- **Evidence:** Successfully executed payload `<script>alert('XSS')</script>`
- **Evidence:** Successfully executed payload `<script>alert('"'"'XSS'"'"')</script>`
- **Impact:** Demonstrated JavaScript code execution in user context
- **Proof:** Pipeline testing mode - simulated successful exploitation
@@ -39,8 +40,10 @@ Create file `deliverables/xss_exploitation_evidence.md` with content:
- **Vulnerability ID:** XSS-VULN-01
- **Exploitation Status:** Simulated Success (Pipeline Test)
- **MCP Instance:** {{MCP_SERVER}}
- **Attack Vector:** Reflected XSS in search functionality
- **Attack Vector:** Reflected XSS in search functionality'
```
This will automatically create `deliverables/xss_exploitation_evidence.md`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to example.com independently of other parallel exploitation agents.

8
prompts/pipeline-testing/pre-recon-code.txt
View File

@@ -1 +1,7 @@
Create file `deliverables/code_analysis_deliverable.md` with content "Pre-recon analysis complete".
Use the save_deliverable script to create your deliverable:
```bash
node save_deliverable.js CODE_ANALYSIS 'Pre-recon analysis complete'
```
This will automatically create `deliverables/code_analysis_deliverable.md` with the correct filename.

8
prompts/pipeline-testing/recon.txt
View File

@@ -1 +1,7 @@
Create file `deliverables/recon_deliverable.md` with content "Reconnaissance analysis complete".
Use the save_deliverable script to create your deliverable:
```bash
node save_deliverable.js RECON 'Reconnaissance analysis complete'
```
This will automatically create `deliverables/recon_deliverable.md` with the correct filename.

21
prompts/pipeline-testing/vuln-auth.txt
View File

@@ -19,20 +19,21 @@
```
### Step 2: Create Required Deliverables
Create these 2 files:
1. `deliverables/auth_analysis_deliverable.md` with content:
```
# Auth Analysis Complete (Pipeline Test)
Use the save_deliverable script to create both deliverables:
**1. Analysis Report:**
```bash
node save_deliverable.js AUTH_ANALYSIS '# Auth Analysis Complete (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://example.net
**Screenshot:** auth-agent-test.png
**Status:** Browser isolation test successful
**Status:** Browser isolation test successful'
```
2. `deliverables/auth_exploitation_queue.json` with content:
```json
{
**2. Exploitation Queue:**
```bash
node save_deliverable.js AUTH_QUEUE '{
"vulnerabilities": [
{
"ID": "AUTH-VULN-01",
@@ -46,8 +47,10 @@ Create these 2 files:
"witness_payload": "Authorization: Bearer invalid_token"
}
]
}
}'
```
These commands will automatically create the correct files in `deliverables/`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to example.net independently of other parallel agents.

21
prompts/pipeline-testing/vuln-authz.txt
View File

@@ -19,20 +19,21 @@
```
### Step 2: Create Required Deliverables
Create these 2 files:
1. `deliverables/authz_analysis_deliverable.md` with content:
```
# Authorization Analysis Complete (Pipeline Test)
Use the save_deliverable script to create both deliverables:
**1. Analysis Report:**
```bash
node save_deliverable.js AUTHZ_ANALYSIS '# Authorization Analysis Complete (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://jsonplaceholder.typicode.com
**Screenshot:** authz-agent-test.png
**Status:** Browser isolation test successful
**Status:** Browser isolation test successful'
```
2. `deliverables/authz_exploitation_queue.json` with content:
```json
{
**2. Exploitation Queue:**
```bash
node save_deliverable.js AUTHZ_QUEUE '{
"vulnerabilities": [
{
"ID": "AUTHZ-VULN-01",
@@ -45,8 +46,10 @@ Create these 2 files:
"witness_payload": "GET /admin/users with regular user token"
}
]
}
}'
```
These commands will automatically create the correct files in `deliverables/`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to jsonplaceholder.typicode.com independently of other parallel agents.

23
prompts/pipeline-testing/vuln-injection.txt
View File

@@ -19,20 +19,21 @@
```
### Step 2: Create Required Deliverables
Create these 2 files:
1. `deliverables/injection_analysis_deliverable.md` with content:
```
# Injection Analysis Complete (Pipeline Test)
Use the save_deliverable script to create both deliverables:
**1. Analysis Report:**
```bash
node save_deliverable.js INJECTION_ANALYSIS '# Injection Analysis Complete (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://example.com
**Screenshot:** injection-agent-test.png
**Status:** Browser isolation test successful
**Status:** Browser isolation test successful'
```
2. `deliverables/injection_exploitation_queue.json` with content:
```json
{
**2. Exploitation Queue:**
```bash
node save_deliverable.js INJECTION_QUEUE '{
"vulnerabilities": [
{
"ID": "INJ-VULN-01",
@@ -45,11 +46,13 @@ Create these 2 files:
"sink_call": "db.query at app.js:20",
"slot_type": "SQL-val",
"mismatch_reason": "User input directly concatenated into SQL query",
"witness_payload": "'; DROP TABLE users; --"
"witness_payload": "'"'"'; DROP TABLE users; --"
}
]
}
}'
```
These commands will automatically create the correct files in `deliverables/`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to example.com independently of other parallel agents.

21
prompts/pipeline-testing/vuln-ssrf.txt
View File

@@ -19,20 +19,21 @@
```
### Step 2: Create Required Deliverables
Create these 2 files:
1. `deliverables/ssrf_analysis_deliverable.md` with content:
```
# SSRF Analysis Complete (Pipeline Test)
Use the save_deliverable script to create both deliverables:
**1. Analysis Report:**
```bash
node save_deliverable.js SSRF_ANALYSIS '# SSRF Analysis Complete (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://httpbin.org
**Screenshot:** ssrf-agent-test.png
**Status:** Browser isolation test successful
**Status:** Browser isolation test successful'
```
2. `deliverables/ssrf_exploitation_queue.json` with content:
```json
{
**2. Exploitation Queue:**
```bash
node save_deliverable.js SSRF_QUEUE '{
"vulnerabilities": [
{
"ID": "SSRF-VULN-01",
@@ -45,8 +46,10 @@ Create these 2 files:
"witness_payload": "http://internal.localhost/admin"
}
]
}
}'
```
These commands will automatically create the correct files in `deliverables/`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to httpbin.org independently of other parallel agents.

21
prompts/pipeline-testing/vuln-xss.txt
View File

@@ -19,20 +19,21 @@
```
### Step 2: Create Required Deliverables
Create these 2 files:
1. `deliverables/xss_analysis_deliverable.md` with content:
```
# XSS Analysis Complete (Pipeline Test)
Use the save_deliverable script to create both deliverables:
**1. Analysis Report:**
```bash
node save_deliverable.js XSS_ANALYSIS '# XSS Analysis Complete (Pipeline Test)
**MCP Server Used:** {{MCP_SERVER}}
**Test Site:** https://example.org
**Screenshot:** xss-agent-test.png
**Status:** Browser isolation test successful
**Status:** Browser isolation test successful'
```
2. `deliverables/xss_exploitation_queue.json` with content:
```json
{
**2. Exploitation Queue:**
```bash
node save_deliverable.js XSS_QUEUE '{
"vulnerabilities": [
{
"ID": "XSS-VULN-01",
@@ -47,8 +48,10 @@ Create these 2 files:
"witness_payload": "<script>alert(1)</script>"
}
]
}
}'
```
These commands will automatically create the correct files in `deliverables/`.
### Step 3: Verify MCP Isolation
This agent should be using {{MCP_SERVER}} and navigating to example.org independently of other parallel agents.

11
prompts/pre-recon-code.txt
View File

@@ -18,7 +18,7 @@ Objective: Your task is to analyze the provided source code to generate a securi
- Identify trust boundaries, privilege escalation paths, and data flow security concerns
- Include specific examples from the code when discussing security concerns
- At the end of your report, you MUST include a section listing all the critical file paths mentioned in your analysis.
- **MANDATORY:** You MUST save your complete analysis report to `deliverables/code_analysis_deliverable.md` using the Write tool.
- **MANDATORY:** You MUST save your complete analysis report using the `save_deliverable` tool with type `CODE_ANALYSIS`.
</critical>
<system_architecture>
@@ -78,8 +78,9 @@ You are the **Code Intelligence Gatherer** and **Architectural Foundation Builde
**Available Tools:**
- **Task Agent (Code Analysis):** Your primary tool. Use it to ask targeted questions about the source code, trace authentication mechanisms, map attack surfaces, and understand architectural patterns. MANDATORY for all source code analysis.
- **TodoWrite Tool:** Use this to create and manage your analysis task list. Create todo items for each phase and agent that needs execution. Mark items as "in_progress" when working on them and "completed" when done.
- **Write tool:** Use this to save your complete analysis to `deliverables/code_analysis_deliverable.md`. This is your primary deliverable that feeds all subsequent agents.
- **Bash tool:** For creating directories (`mkdir -p outputs/schemas`), copying schema files, and any file system operations required for deliverable organization.
- **Bash tool:** Your primary tool for executing shell commands. Use it for creating directories, copying files, and, most importantly, for **saving your final deliverable** by executing the `save_deliverable.js` script.
- **Saving Deliverable:** To save your work, you MUST use the following command. The script handles correct naming and validates output. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your analysis report:** `node save_deliverable.js CODE_ANALYSIS 'your complete markdown report'`
</available_tools>
<task_agent_strategy>
@@ -122,7 +123,7 @@ After Phase 1 completes, launch all three vulnerability-focused agents in parall
- Create the `outputs/schemas/` directory using mkdir -p
- Copy all discovered schema files to `outputs/schemas/` with descriptive names
- Include schema locations in your attack surface analysis
- Save complete analysis to deliverables/code_analysis_deliverable.md
- Save complete analysis using: `node save_deliverable.js CODE_ANALYSIS 'your complete markdown report'`
**EXECUTION PATTERN:**
1. **Use TodoWrite to create task list** tracking: Phase 1 agents, Phase 2 agents, and report synthesis
@@ -380,7 +381,7 @@ A component is **out-of-scope** if it **cannot** be invoked through the running
- Phase 3: Synthesis and report generation completed
2. **Deliverable Generation:** The following files must be successfully created:
- `deliverables/code_analysis_deliverable.md` (Created using Write tool)
- `deliverables/code_analysis_deliverable.md` (Created using save_deliverable script with CODE_ANALYSIS type)
- `outputs/schemas/` directory with all discovered schema files copied (if any schemas found)
3. **TodoWrite Completion:** All tasks in your todo list must be marked as completed

8
prompts/recon.txt
View File

@@ -60,7 +60,9 @@ Please use these tools for the following use cases:
- Task tool: **MANDATORY for ALL source code analysis.** You MUST delegate all code reading, searching, and analysis to Task agents. DO NOT use Read, Glob, or Grep tools for source code.
- {{MCP_SERVER}} (Playwright): To interact with the live web application at the target.
- **CRITICAL RULE:** For all browser interactions, you MUST use the {{MCP_SERVER}} (Playwright).
- Bash tool: For running simple, non-intrusive commands to gather more information if needed.
- Bash tool: Your primary tool for executing shell commands. Use it for simple, non-intrusive commands and, most importantly, for **saving your final deliverable** by executing the `save_deliverable.js` script.
- **Saving Deliverable:** To save your work, you MUST use the following command. The script handles correct naming and validates output. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your reconnaissance report:** `node save_deliverable.js RECON 'your complete markdown report'`
**CRITICAL TASK AGENT RULE:** You are PROHIBITED from using Read, Glob, or Grep tools for source code analysis. All code examination must be delegated to Task agents for deeper, more thorough analysis.
</available_tools>
@@ -129,7 +131,7 @@ You must follow this methodical four-step process:
</systematic_approach>
<deliverable_instructions>
When you have a complete understanding of the attack surface, you MUST synthesize all of your findings into a single, detailed Markdown report located at `deliverables/recon_deliverable.md`.
When you have a complete understanding of the attack surface, you MUST synthesize all of your findings into a single, detailed Markdown report and save it using the save_deliverable script with type RECON.
Your report MUST use the following structure precisely:
@@ -386,5 +388,5 @@ Vulnerability Sources by Type
</deliverable_instructions>
<conclusion_trigger>
Once you have written the complete deliverable to `deliverables/recon_deliverable.md`, your phase is complete. Announce "RECONNAISSANCE COMPLETE" and await further instructions.
Once you have saved the complete deliverable using the save_deliverable script (`node save_deliverable.js RECON 'your report'`), your phase is complete. Announce "RECONNAISSANCE COMPLETE" and await further instructions.
</conclusion_trigger>

29
prompts/vuln-auth.txt
View File

@@ -78,17 +78,18 @@ An **exploitable vulnerability** is a logical flaw in the code that represents a
**Available Tools:**
- **Task Agent (Code Analysis):** Your primary tool. Use it to ask targeted questions about the source code, trace authentication logic paths, and understand session/credential handling. MANDATORY for all source code analysis.
- **Bash tool:** For crafting manual API requests with `curl` to probe endpoint behavior and validate hypotheses about access control (without performing malicious actions).
- **Bash tool:** Your primary tool for executing shell commands. Use it for crafting manual API requests with `curl` to probe endpoint behavior and, most importantly, for **saving your final deliverables** by executing the `save_deliverable.js` script.
- **Saving Deliverables:** To save your work, you MUST use the following commands. The script handles correct naming and validates JSON where applicable. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your analysis report:** `node save_deliverable.js AUTH_ANALYSIS 'your complete markdown report'`
- **For your exploitation queue:** `node save_deliverable.js AUTH_QUEUE '{"vulnerabilities": [...]}'`
- **{{MCP_SERVER}} (Playwright):** To interact with the live web application to understand multi-step flows like password reset or registration.
- **TodoWrite Tool:** Use this to create and manage your analysis task list. Create a todo item for each endpoint/flow that needs analysis. Mark items as "in_progress" when working on them and "completed" when done.
- **Write tool:** Use this to create or update `deliverables/auth_exploitation_queue.json` following the exploitation queue format. Always write an empty array when no vulnerabilities are found to signal completion.
</available_tools>
<data_format_specifications>
<exploitation_queue_format>
**Purpose:** Defines the structure for a "exploitation queue" saved to `deliverables/auth_exploitation_queue.json` via the Write tool.
**Purpose:** Defines the structure for a "exploitation queue" saved via the save_deliverable script with type AUTH_QUEUE.
**Structure:** The `vulnerability` JSON object MUST follow this exact format:
{
"ID": "unique ID for each vulnerability json (AUTH-VULN-XX)",
@@ -179,7 +180,7 @@ Rule: when uncertain, round down (favor Medium/Low) to minimize false positives.
# Documenting Findings (MANDATORY)
For each check you perform from the list above (Transport, Rate Limiting, Session Management, etc.), you must make a final **verdict**.
- If the verdict is **`vulnerable`**, you must document the finding using the Write tool to update `deliverables/auth_exploitation_queue.json`.
- If the verdict is **`vulnerable`**, you must document the finding using the save_deliverable script to update the exploitation queue.
- If the verdict is **`safe`**, you **MUST NOT** add the finding to the exploitation queue. These secure components should be documented in the "Secure by Design: Validated Components" section of your final Markdown report.
</methodology>
@@ -197,7 +198,7 @@ For each check you perform from the list above (Transport, Rate Limiting, Sessio
When you have systematically analyzed all relevant endpoints and logic paths, you MUST generate two final files. Follow these instructions precisely.
**1. Your Specialist Deliverable**
First, synthesize all of your findings into a detailed Markdown report at `deliverables/auth_analysis_deliverable.md`.
First, synthesize all of your findings into a detailed Markdown report and save it using the save_deliverable script with type AUTH_ANALYSIS.
Your report MUST use the following structure precisely:
---
@@ -206,7 +207,7 @@ Your report MUST use the following structure precisely:
## 1. Executive Summary
- **Analysis Status:** Complete
- **Key Outcome:** Critical authentication flaws were identified, primarily related to weak session management and insufficient transport security.
- **Purpose of this Document:** This report provides the strategic context on the application's authentication mechanisms, dominant flaw patterns, and key architectural details necessary to effectively exploit the vulnerabilities listed in `deliverables/auth_exploitation_queue.json`.
- **Purpose of this Document:** This report provides the strategic context on the application's authentication mechanisms, dominant flaw patterns, and key architectural details necessary to effectively exploit the vulnerabilities listed in the exploitation queue.
## 2. Dominant Vulnerability Patterns
@@ -237,9 +238,9 @@ These components were analyzed and found to have robust defenses. They are low-p
<exploitation_queue_requirements>
**Exploitation Queue (MANDATORY)**
Regardless of whether vulnerabilities are found, you MUST create `deliverables/auth_exploitation_queue.json` using the Write tool:
- **If vulnerabilities found:** Add each confirmed hypothesis using the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
- **If no vulnerabilities found:** Create an empty file by using the Write tool to save `{"vulnerabilities": []}`.
Regardless of whether vulnerabilities are found, you MUST create the exploitation queue using the save_deliverable script:
- **If vulnerabilities found:** Use `node save_deliverable.js AUTH_QUEUE '{"vulnerabilities": [...]}'` with each confirmed hypothesis following the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
- **If no vulnerabilities found:** Use `node save_deliverable.js AUTH_QUEUE '{"vulnerabilities": []}'`.
- **QUEUE INCLUSION CRITERIA:** ONLY include vulnerabilities where `externally_exploitable = true`. Exclude any vulnerability requiring internal network access, VPN, or direct server access.
This file serves as the handoff mechanism and must always be created to signal completion.
</exploitation_queue_requirements>
@@ -248,9 +249,9 @@ This file serves as the handoff mechanism and must always be created to signal c
**COMPLETION REQUIREMENTS (ALL must be satisfied):**
1. **Systematic Analysis:** ALL relevant API endpoints and user-facing features identified in the reconnaissance deliverable must be analyzed for AuthN/AuthZ flaws.
2. **Deliverable Generation:** Both files must be successfully created:
- `deliverables/auth_analysis_deliverable.md` (Created)
- `deliverables/auth_exploitation_queue.json` (Created)
2. **Deliverable Generation:** Both required deliverables must be successfully saved using save_deliverable script:
- Analysis report: `node save_deliverable.js AUTH_ANALYSIS 'your report'`
- Exploitation queue: `node save_deliverable.js AUTH_QUEUE '{"vulnerabilities": [...]}'`
**ONLY AFTER** both systematic analysis AND successful file generation, announce "**AUTH ANALYSIS COMPLETE**" and stop.
**ONLY AFTER** both systematic analysis AND successful deliverable generation, announce "**AUTH ANALYSIS COMPLETE**" and stop.
</conclusion_trigger>

29
prompts/vuln-authz.txt
View File

@@ -82,17 +82,18 @@ An **exploitable vulnerability** is a logical flaw in the code that represents a
**Available Tools:**
- **Task Agent (Code Analysis):** Your primary tool. Use it to ask targeted questions about the source code, trace authorization logic paths, and understand permission models. MANDATORY for all source code analysis.
- **Bash tool:** For crafting manual API requests with `curl` to probe endpoint behavior and validate hypotheses about access control (without performing malicious actions).
- **Bash tool:** Your primary tool for executing shell commands. Use it for crafting manual API requests with `curl` to probe endpoint behavior and, most importantly, for **saving your final deliverables** by executing the `save_deliverable.js` script.
- **Saving Deliverables:** To save your work, you MUST use the following commands. The script handles correct naming and validates JSON where applicable. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your analysis report:** `node save_deliverable.js AUTHZ_ANALYSIS 'your complete markdown report'`
- **For your exploitation queue:** `node save_deliverable.js AUTHZ_QUEUE '{"vulnerabilities": [...]}'`
- **{{MCP_SERVER}} (Playwright):** To interact with the live web application to understand multi-step flows and role-based access controls.
- **TodoWrite Tool:** Use this to create and manage your analysis task list. Create a todo item for each endpoint that needs authorization analysis. Mark items as "in_progress" when working on them and "completed" when done.
- **Write tool:** Use this to create or update `deliverables/authz_exploitation_queue.json` following the exploitation queue format. Always write an empty array when no vulnerabilities are found to signal completion.
</available_tools>
<data_format_specifications>
<exploitation_queue_format>
**Purpose:** Defines the structure for a "exploitation queue" saved to `deliverables/authz_exploitation_queue.json` via the Write tool.
**Purpose:** Defines the structure for a "exploitation queue" saved via the save_deliverable script with type AUTHZ_QUEUE.
**Structure:** The `vulnerability` JSON object MUST follow this exact format:
{
"ID": "unique ID for each vulnerability (e.g., AUTHZ-VULN-01)",
@@ -237,7 +238,7 @@ An **exploitable vulnerability** is a logical flaw in the code that represents a
For each analysis you perform from the lists above, you must make a final **verdict**:
- If the verdict is **`vulnerable`**, you must document the finding using the Write tool to update `deliverables/authz_exploitation_queue.json`.
- If the verdict is **`vulnerable`**, you must document the finding using the save_deliverable script to update the exploitation queue.
- If the verdict is **`safe`**, you **MUST NOT** add the finding to the exploitation queue. These secure components should be documented in the "Secure by Design: Validated Components" section of your final Markdown report.
</methodology>
@@ -275,7 +276,7 @@ When you have systematically analyzed all relevant endpoints and logic paths, yo
**1. Your Specialist Deliverable**
First, synthesize all of your findings into a single, detailed Markdown report located at `deliverables/authz_analysis_deliverable.md`. This report is the official record of your work.
First, synthesize all of your findings into a single, detailed Markdown report and save it using the save_deliverable script with type AUTHZ_ANALYSIS. This report is the official record of your work.
Your report MUST use the following structure precisely:
@@ -285,7 +286,7 @@ Your report MUST use the following structure precisely:
## 1. Executive Summary
- **Analysis Status:** Complete
- **Key Outcome:** ONLY high-confidence authorization vulnerabilities (horizontal, vertical, and context/workflow) were recorded. All findings have been passed to the exploitation phase via the machine-readable queue at `deliverables/authz_exploitation_queue.json`.
- **Key Outcome:** ONLY high-confidence authorization vulnerabilities (horizontal, vertical, and context/workflow) were recorded. All findings have been passed to the exploitation phase via the machine-readable exploitation queue.
- **Purpose of this Document:** This report provides the strategic context, dominant patterns, and architectural intelligence necessary to effectively exploit the vulnerabilities listed in the queue. It is intended to be read alongside the JSON deliverable.
## 2. Dominant Vulnerability Patterns
@@ -341,9 +342,9 @@ examples:
<exploitation_queue_requirements>
**Exploitation Queue (MANDATORY)**
Regardless of whether vulnerabilities are found, you MUST create `deliverables/authz_exploitation_queue.json` using the Write tool:
- **If vulnerabilities found:** Add each confirmed hypothesis using the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
- **If no vulnerabilities found:** Create an empty file by using the Write tool to save `{"vulnerabilities": []}`.
Regardless of whether vulnerabilities are found, you MUST create the exploitation queue using the save_deliverable script:
- **If vulnerabilities found:** Use `node save_deliverable.js AUTHZ_QUEUE '{"vulnerabilities": [...]}'` with each confirmed hypothesis following the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
- **If no vulnerabilities found:** Use `node save_deliverable.js AUTHZ_QUEUE '{"vulnerabilities": []}'`.
- **QUEUE INCLUSION CRITERIA:** ONLY include vulnerabilities where `externally_exploitable = true`. Exclude any vulnerability requiring internal network access, VPN, or direct server access.
This file serves as the handoff mechanism and must always be created to signal completion.
</exploitation_queue_requirements>
@@ -352,11 +353,11 @@ This file serves as the handoff mechanism and must always be created to signal c
**COMPLETION REQUIREMENTS (ALL must be satisfied):**
1. **Todo Completion:** ALL tasks in your TodoWrite list must be marked as "completed"
2. **Deliverable Generation:** All three outputs must be successfully created:
- `deliverables/authz_analysis_deliverable.md`
- `deliverables/authz_exploitation_queue.json`
2. **Deliverable Generation:** Both required deliverables must be successfully saved using save_deliverable script:
- Analysis report: `node save_deliverable.js AUTHZ_ANALYSIS 'your report'`
- Exploitation queue: `node save_deliverable.js AUTHZ_QUEUE '{"vulnerabilities": [...]}'`
**ONLY AFTER** both todo completion AND successful file generation, announce "**AUTHORIZATION ANALYSIS COMPLETE**" and stop.
**ONLY AFTER** both todo completion AND successful deliverable generation, announce "**AUTHORIZATION ANALYSIS COMPLETE**" and stop.
**FAILURE TO COMPLETE TODOS = INCOMPLETE ANALYSIS** - You will be considered to have failed the mission if you generate deliverables before completing comprehensive testing of all authorization vectors.
</conclusion_trigger>

22
prompts/vuln-injection.txt
View File

@@ -84,16 +84,18 @@ An **exploitable vulnerability** is a confirmed source-to-sink path where the en
**Available Tools:**
- **Task Agent (Code Analysis):** Your primary tool. Use it to ask targeted questions about the source code, map query/command construction paths, and verify sanitization coverage. MANDATORY for all source code analysis.
- **Bash tool:** For crafting manual API requests with `curl` to probe injection surfaces and validate hypotheses about server behavior (without performing malicious actions).
- **Bash tool:** Your primary tool for executing shell commands. Use it for crafting manual API requests with `curl` to probe injection surfaces and, most importantly, for **saving your final deliverables** by executing the `save_deliverable.js` script.
- **Saving Deliverables:** To save your work, you MUST use the following commands. The script handles correct naming and validates JSON where applicable. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your analysis report:** `node save_deliverable.js INJECTION_ANALYSIS 'your complete markdown report'`
- **For your exploitation queue:** `node save_deliverable.js INJECTION_QUEUE '{"vulnerabilities": [...]}'`
- **{{MCP_SERVER}} (Playwright):** To interact with the live web application to understand multi-step flows like password reset or registration.
- **TodoWrite Tool:** Use this to create and manage your analysis task list. Create a todo item for each injection source that needs analysis. Mark items as "in_progress" when working on them and "completed" when done.
- **Write tool:** Use this to create or update `deliverables/injection_exploitation_queue.json` following the exploitation queue format. Always write an empty array when no vulnerabilities are found to signal completion.
</available_tools>
<data_format_specifications>
<exploitation_queue_format>
**Purpose:** Defines the structure for a "exploitation queue" saved to `deliverables/injection_exploitation_queue.json` via the Write tool.
**Purpose:** Defines the structure for a "exploitation queue" saved via the save_deliverable script with type INJECTION_QUEUE.
**Structure:** The `vulnerability` JSON object MUST follow this exact format:
{
@@ -359,10 +361,10 @@ These input vectors were traced and confirmed to have robust, context-appropriat
<exploitation_queue_requirements>
**Exploitation Queue (MANDATORY)**
Regardless of whether vulnerabilities are found, you MUST create `deliverables/injection_exploitation_queue.json` using the Write tool:
Regardless of whether vulnerabilities are found, you MUST create the exploitation queue using the save_deliverable script:
- **If vulnerabilities found:** Add each exploitable injection vulnerability (vertict: "vulnerable") using the exploitation_queue_format
- **If no vulnerabilities found:** Create an empty file by using the Write tool to save `{"vulnerabilities": []}`
- **If vulnerabilities found:** Use `node save_deliverable.js INJECTION_QUEUE '{"vulnerabilities": [...]}'` with each exploitable injection vulnerability (verdict: "vulnerable") following the exploitation_queue_format
- **If no vulnerabilities found:** Use `node save_deliverable.js INJECTION_QUEUE '{"vulnerabilities": []}'`
This file serves as the handoff mechanism to the Exploitation phase and must always be created to signal completion of your analysis.
</exploitation_queue_requirements>
@@ -371,11 +373,11 @@ This file serves as the handoff mechanism to the Exploitation phase and must alw
**COMPLETION REQUIREMENTS (ALL must be satisfied):**
1. **Todo Completion:** ALL tasks in your TodoWrite list must be marked as "completed"
2. **Deliverable Generation:** Both required files must be successfully created:
- `deliverables/injection_analysis_deliverable.md`
- `deliverables/injection_exploitation_queue.json`
2. **Deliverable Generation:** Both required deliverables must be successfully saved using save_deliverable script:
- Analysis report: `node save_deliverable.js INJECTION_ANALYSIS 'your report'`
- Exploitation queue: `node save_deliverable.js INJECTION_QUEUE '{"vulnerabilities": [...]}'`
**ONLY AFTER** both todo completion AND successful file generation, announce "**INJECTION ANALYSIS COMPLETE**" and stop.
**ONLY AFTER** both todo completion AND successful deliverable generation, announce "**INJECTION ANALYSIS COMPLETE**" and stop.
**FAILURE TO COMPLETE TODOS = INCOMPLETE ANALYSIS** - You will be considered to have failed the mission if you generate deliverables before completing comprehensive testing of all input vectors.
</conclusion_trigger>

31
prompts/vuln-ssrf.txt
View File

@@ -77,17 +77,18 @@ An **exploitable vulnerability** is a data flow where user-controlled input infl
**Available Tools:**
- **Task Agent (Code Analysis):** Your primary tool. Use it to ask targeted questions about the source code, trace data flows, and understand HTTP client usage. MANDATORY for all source code analysis.
- **Bash tool:** For crafting manual HTTP requests with `curl` to test endpoint behavior and validate hypotheses about request forwarding (without performing malicious actions).
- **Bash tool:** Your primary tool for executing shell commands. Use it for crafting manual HTTP requests with `curl` to test endpoint behavior and, most importantly, for **saving your final deliverables** by executing the `save_deliverable.js` script.
- **Saving Deliverables:** To save your work, you MUST use the following commands. The script handles correct naming and validates JSON where applicable. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your analysis report:** `node save_deliverable.js SSRF_ANALYSIS 'your complete markdown report'`
- **For your exploitation queue:** `node save_deliverable.js SSRF_QUEUE '{"vulnerabilities": [...]}'`
- **{{MCP_SERVER}} (Playwright):** To interact with the live web application to understand multi-step flows that might involve URL redirection or proxy functionality.
- **TodoWrite Tool:** Use this to create and manage your analysis task list. Create a todo item for each SSRF sink that needs analysis. Mark items as "in_progress" when working on them and "completed" when done.
- **Write tool:** Use this to create or update `deliverables/ssrf_exploitation_queue.json` following the exploitation queue format. Always write an empty array when no vulnerabilities are found to signal completion.
</available_tools>
<data_format_specifications>
<exploitation_queue_format>
**Purpose:** Defines the structure for a "exploitation queue" saved to `deliverables/ssrf_exploitation_queue.json` via the Write tool.
**Purpose:** Defines the structure for a "exploitation queue" saved via the save_deliverable script with type SSRF_QUEUE.
**Structure:** The `vulnerability` JSON object MUST follow this exact format:
{
"ID": "unique ID for each vulnerability json (SSRF-VULN-XX)",
@@ -214,7 +215,7 @@ Confidence levels:
### **4) Documentation**
- **Vulnerable paths** → add to exploitation queue, include a minimal `witness_payload` (e.g., `http://127.0.0.1:22/`).
- **Safe paths** → log in "Vectors Analyzed and Confirmed Secure" in `deliverables/ssrf_analysis_deliverable.md`.
- **Safe paths** → log in "Vectors Analyzed and Confirmed Secure" in your analysis deliverable.
# Confidence scoring (analysis phase; applies to all checks above)
- **High** — The flaw is directly established and deterministic in the target context. You have direct evidence with no material alternate control. Scope is clear (which endpoints/parameters).
@@ -226,7 +227,7 @@ Rule: when uncertain, round down (favor Medium/Low) to minimize false positives.
# Documenting Findings (MANDATORY)
For each check you perform from the list above, you must make a final **verdict**.
- If the verdict is **`vulnerable`**, you must document the finding using the Write tool to update `deliverables/ssrf_exploitation_queue.json`.
- If the verdict is **`vulnerable`**, you must document the finding using the save_deliverable script to update the exploitation queue.
- If the verdict is **`safe`**, you **MUST NOT** add the finding to the exploitation queue. These secure components should be documented in the "Secure by Design: Validated Components" section of your final Markdown report.
</methodology>
@@ -244,7 +245,7 @@ For each check you perform from the list above, you must make a final **verdict*
When you have systematically analyzed all relevant endpoints and request-making functions, you MUST generate two final files. Follow these instructions precisely.
**1. Your Specialist Deliverable**
First, synthesize all of your findings into a detailed Markdown report at `deliverables/ssrf_analysis_deliverable.md`.
First, synthesize all of your findings into a detailed Markdown report and save it using the save_deliverable script with type SSRF_ANALYSIS.
Your report MUST use the following structure precisely:
---
@@ -253,7 +254,7 @@ Your report MUST use the following structure precisely:
## 1. Executive Summary
- **Analysis Status:** Complete
- **Key Outcome:** Several high-confidence server-side request forgery vulnerabilities were identified, primarily related to insufficient URL validation and internal service access.
- **Purpose of this Document:** This report provides the strategic context on the application's outbound request mechanisms, dominant flaw patterns, and key architectural details necessary to effectively exploit the vulnerabilities listed in `deliverables/ssrf_exploitation_queue.json`.
- **Purpose of this Document:** This report provides the strategic context on the application's outbound request mechanisms, dominant flaw patterns, and key architectural details necessary to effectively exploit the vulnerabilities listed in the exploitation queue.
## 2. Dominant Vulnerability Patterns
@@ -284,9 +285,9 @@ These components were analyzed and found to have robust defenses. They are low-p
<exploitation_queue_requirements>
**Exploitation Queue (MANDATORY)**
Regardless of whether vulnerabilities are found, you MUST create `deliverables/ssrf_exploitation_queue.json` using the Write tool:
- **If vulnerabilities found:** Add each confirmed hypothesis using the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
- **If no vulnerabilities found:** Create an empty file by using the Write tool to save `{"vulnerabilities": []}`.
Regardless of whether vulnerabilities are found, you MUST create the exploitation queue using the save_deliverable script:
- **If vulnerabilities found:** Use `node save_deliverable.js SSRF_QUEUE '{"vulnerabilities": [...]}'` with each confirmed hypothesis following the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
- **If no vulnerabilities found:** Use `node save_deliverable.js SSRF_QUEUE '{"vulnerabilities": []}'`.
- **QUEUE INCLUSION CRITERIA:** ONLY include vulnerabilities where `externally_exploitable = true`. Exclude any vulnerability requiring internal network access, VPN, or direct server access.
This file serves as the handoff mechanism and must always be created to signal completion.
</exploitation_queue_requirements>
@@ -295,9 +296,9 @@ This file serves as the handoff mechanism and must always be created to signal c
**COMPLETION REQUIREMENTS (ALL must be satisfied):**
1. **Systematic Analysis:** ALL relevant API endpoints and request-making features identified in the reconnaissance deliverable must be analyzed for SSRF vulnerabilities.
2. **Deliverable Generation:** Both files must be successfully created:
- `deliverables/ssrf_analysis_deliverable.md` (Created)
- `deliverables/ssrf_exploitation_queue.json` (Created)
2. **Deliverable Generation:** Both required deliverables must be successfully saved using save_deliverable script:
- Analysis report: `node save_deliverable.js SSRF_ANALYSIS 'your report'`
- Exploitation queue: `node save_deliverable.js SSRF_QUEUE '{"vulnerabilities": [...]}'`
**ONLY AFTER** both systematic analysis AND successful file generation, announce "**SSRF ANALYSIS COMPLETE**" and stop.
**ONLY AFTER** both systematic analysis AND successful deliverable generation, announce "**SSRF ANALYSIS COMPLETE**" and stop.
</conclusion_trigger>

33
prompts/vuln-xss.txt
View File

@@ -82,15 +82,16 @@ An **exploitable vulnerability** is a confirmed source-to-sink path where the en
- **Terminal (curl):** MANDATORY for testing HTTP-based XSS vectors and observing raw HTML responses. Use for reflected XSS testing and JSONP injection testing.
- **{{MCP_SERVER}} (Playwright):** MANDATORY for testing DOM-based XSS and form submission vectors. Use for stored XSS testing and client-side payload execution verification.
- **TodoWrite Tool:** Use this to create and manage your analysis task list. Create a todo item for each sink you need to analyze.
**Logging Tools:**
- **Write tool:** Use this to create or update `deliverables/xss_exploitation_queue.json` following the exploitation queue format. Always write an empty array when no vulnerabilities are found to signal completion.
- **Bash tool:** Your primary tool for executing shell commands. Use it for testing XSS vectors with `curl` and, most importantly, for **saving your final deliverables** by executing the `save_deliverable.js` script.
- **Saving Deliverables:** To save your work, you MUST use the following commands. The script handles correct naming and validates JSON where applicable. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your analysis report:** `node save_deliverable.js XSS_ANALYSIS 'your complete markdown report'`
- **For your exploitation queue:** `node save_deliverable.js XSS_QUEUE '{"vulnerabilities": [...]}'`
</available_tools>
<data_format_specifications>
<exploitation_queue_format>
Purpose: Defines the structure for a "exploitation queue" saved to `deliverables/xss_exploitation_queue.json` via the Write tool.
Purpose: Defines the structure for a "exploitation queue" saved via the save_deliverable script with type XSS_QUEUE.
Structure: The vulnerability JSON object MUST follow this exact format:
{
"ID": "unique ID for each vulnerability json (XSS-VULN-XX)",
@@ -175,8 +176,8 @@ This rulebook is used for the **Early Termination** check in Step 2.
- Include both safe and vulnerable paths to demonstrate **full coverage**.
- Craft a minimal `witness_payload` that proves control over the render context.
- For every path analyzed, you must document the outcome. The location of the documentation depends on the verdict:
- If the verdict is 'vulnerable', you MUST use the Write tool to save the finding to `deliverables/xss_exploitation_queue.json`, including complete source-to-sink information.
- If the verdict is 'safe', you MUST NOT add it to the exploitation queue. Instead, you will document these secure paths in the "Vectors Analyzed and Confirmed Secure" table of your final report (deliverables/xss_analysis_deliverable.md).
- If the verdict is 'vulnerable', you MUST use the save_deliverable script to save the finding to the exploitation queue, including complete source-to-sink information.
- If the verdict is 'safe', you MUST NOT add it to the exploitation queue. Instead, you will document these secure paths in the "Vectors Analyzed and Confirmed Secure" table of your final analysis report.
- For vulnerable findings, craft a minimal witness_payload that proves control over the render context.
### **8) Score Confidence**
@@ -267,20 +268,16 @@ These input vectors were traced and confirmed to have robust, context-appropriat
## Exploitation Queue (MANDATORY)
Regardless of whether vulnerabilities are found, you MUST create:
`deliverables/xss_exploitation_queue.json`
using the **Write tool**.
Regardless of whether vulnerabilities are found, you MUST create the exploitation queue using the save_deliverable script.
- **If exploitable vulnerabilities found:**
Add each exploitable XSS vulnerability (verdict: "vulnerable") using the `exploitation_queue_format` when writing the file. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
Use `node save_deliverable.js XSS_QUEUE '{"vulnerabilities": [...]}'` with each exploitable XSS vulnerability (verdict: "vulnerable") following the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
- **If no exploitable vulnerabilities found:**
Create an empty file by using the Write tool to save the following JSON:
Use `node save_deliverable.js XSS_QUEUE '{"vulnerabilities": []}'`
```json
{"vulnerabilities": []}
```
- **QUEUE INCLUSION CRITERIA:** ONLY include vulnerabilities where `externally_exploitable = true`. Exclude any vulnerability requiring internal network access, VPN, or direct server access.
This file is the mandatory handoff to the Exploitation phase.
</exploitation_queue_requirements>
@@ -288,9 +285,9 @@ This file is the mandatory handoff to the Exploitation phase.
COMPLETION REQUIREMENTS (ALL must be satisfied):
1. Systematic Analysis: ALL input vectors identified from the reconnaissance deliverable must be analyzed.
2. Deliverable Generation: Both required files must be successfully created:
- deliverables/xss_analysis_deliverable.md (Created)
- deliverables/xss_exploitation_queue.json (Created)
2. Deliverable Generation: Both required deliverables must be successfully saved using save_deliverable script:
- Analysis report: `node save_deliverable.js XSS_ANALYSIS 'your report'`
- Exploitation queue: `node save_deliverable.js XSS_QUEUE '{"vulnerabilities": [...]}'`
ONLY AFTER both systematic analysis AND successful file generation, announce "XSS ANALYSIS COMPLETE" and stop.
ONLY AFTER both systematic analysis AND successful deliverable generation, announce "XSS ANALYSIS COMPLETE" and stop.
</conclusion_trigger>

27
src/setup/environment.js
View File

@@ -114,21 +114,36 @@ export async function setupLocalRepo(repoPath) {
// Non-fatal - continue without Git setup
}
// Copy TOTP generation script to local repository for agent accessibility
// Copy tools to local repository for agent accessibility
try {
const totpScriptSource = path.join(import.meta.dirname, '..', '..', 'login_resources', 'generate-totp-standalone.mjs');
const toolsDir = path.join(import.meta.dirname, '..', '..', 'tools');
// Copy TOTP generation script
const totpScriptSource = path.join(toolsDir, 'generate-totp-standalone.mjs');
const totpScriptDest = path.join(sourceDir, 'generate-totp.mjs');
if (await fs.pathExists(totpScriptSource)) {
await fs.copy(totpScriptSource, totpScriptDest);
await fs.chmod(totpScriptDest, '755'); // Make executable
console.log(chalk.green('✅ TOTP generation script (standalone) copied to target repository'));
console.log(chalk.green('✅ TOTP generation script copied to target repository'));
} else {
console.log(chalk.yellow('⚠️ TOTP script not found, authentication may fail if TOTP is required'));
}
} catch (totpError) {
console.log(chalk.yellow(`⚠️ Failed to copy TOTP script: ${totpError.message}`));
// Non-fatal - continue without TOTP script
// Copy save_deliverable tool
const saveDeliverableSource = path.join(toolsDir, 'save_deliverable.js');
const saveDeliverableDest = path.join(sourceDir, 'save_deliverable.js');
if (await fs.pathExists(saveDeliverableSource)) {
await fs.copy(saveDeliverableSource, saveDeliverableDest);
await fs.chmod(saveDeliverableDest, '755'); // Make executable
console.log(chalk.green('✅ save_deliverable tool copied to target repository'));
} else {
console.log(chalk.yellow('⚠️ save_deliverable tool not found, deliverable creation may fail'));
}
} catch (toolError) {
console.log(chalk.yellow(`⚠️ Failed to copy tools: ${toolError.message}`));
// Non-fatal - continue without tools
}
return sourceDir;

131
tools/generate-totp-standalone.mjs Normal file
View File

@@ -0,0 +1,131 @@
#!/usr/bin/env node
import { createHmac } from 'crypto';
/**
* Standalone TOTP generator that doesn't require external dependencies
* Based on RFC 6238 (TOTP: Time-Based One-Time Password Algorithm)
*/
function parseArgs() {
const args = {};
for (let i = 2; i < process.argv.length; i++) {
if (process.argv[i] === '--secret' && i + 1 < process.argv.length) {
args.secret = process.argv[i + 1];
i++; // Skip the next argument since it's the value
} else if (process.argv[i] === '--help' || process.argv[i] === '-h') {
args.help = true;
}
}
return args;
}
function showHelp() {
console.log(`
Usage: node generate-totp-standalone.mjs --secret <TOTP_SECRET>
Generate a Time-based One-Time Password (TOTP) from a secret key.
This standalone version doesn't require external dependencies.
Options:
--secret <secret> The base32-encoded TOTP secret key (required)
--help, -h Show this help message
Examples:
node generate-totp-standalone.mjs --secret "JBSWY3DPEHPK3PXP"
node generate-totp-standalone.mjs --secret "u4e2ewg3d6w7gya3p7plgkef6zgfzo23"
Output:
A 6-digit TOTP code (e.g., 123456)
`);
}
// Base32 decoding function
function base32Decode(encoded) {
const alphabet = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567';
const cleanInput = encoded.toUpperCase().replace(/[^A-Z2-7]/g, '');
if (cleanInput.length === 0) {
return Buffer.alloc(0);
}
const output = [];
let bits = 0;
let value = 0;
for (const char of cleanInput) {
const index = alphabet.indexOf(char);
if (index === -1) {
throw new Error(`Invalid base32 character: ${char}`);
}
value = (value << 5) | index;
bits += 5;
if (bits >= 8) {
output.push((value >>> (bits - 8)) & 255);
bits -= 8;
}
}
return Buffer.from(output);
}
// HOTP implementation (RFC 4226)
function generateHOTP(secret, counter, digits = 6) {
const key = base32Decode(secret);
// Convert counter to 8-byte buffer (big-endian)
const counterBuffer = Buffer.alloc(8);
counterBuffer.writeBigUInt64BE(BigInt(counter));
// Generate HMAC-SHA1
const hmac = createHmac('sha1', key);
hmac.update(counterBuffer);
const hash = hmac.digest();
// Dynamic truncation
const offset = hash[hash.length - 1] & 0x0f;
const code = (
((hash[offset] & 0x7f) << 24) |
((hash[offset + 1] & 0xff) << 16) |
((hash[offset + 2] & 0xff) << 8) |
(hash[offset + 3] & 0xff)
);
// Generate digits
const otp = (code % Math.pow(10, digits)).toString().padStart(digits, '0');
return otp;
}
// TOTP implementation (RFC 6238)
function generateTOTP(secret, timeStep = 30, digits = 6) {
const currentTime = Math.floor(Date.now() / 1000);
const counter = Math.floor(currentTime / timeStep);
return generateHOTP(secret, counter, digits);
}
function main() {
const args = parseArgs();
if (args.help) {
showHelp();
return;
}
if (!args.secret) {
console.error('Error: --secret parameter is required');
console.error('Use --help for usage information');
process.exit(1);
}
try {
const totpCode = generateTOTP(args.secret);
console.log(totpCode);
} catch (error) {
console.error(`Error: ${error.message}`);
process.exit(1);
}
}
main();

145
tools/save_deliverable.js Executable file
View File

@@ -0,0 +1,145 @@
#!/usr/bin/env node
/**
* Save Deliverable Tool
*
* This tool handles saving deliverable files with correct filenames and validation.
* AI agents call this instead of using fs.writeFile directly.
*
* Usage: node save_deliverable.js <TYPE> <content>
*
* Example: node save_deliverable.js INJECTION_QUEUE '{"vulnerabilities": []}'
*/
import { writeFileSync, mkdirSync } from 'fs';
import { join, dirname } from 'path';
import { fileURLToPath } from 'url';
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
// Hard-coded filename mappings from agent prompts
const DELIVERABLE_TYPES = {
// Pre-recon agent
CODE_ANALYSIS: 'code_analysis_deliverable.md',
// Recon agent
RECON: 'recon_deliverable.md',
// Vulnerability analysis agents
INJECTION_ANALYSIS: 'injection_analysis_deliverable.md',
INJECTION_QUEUE: 'injection_exploitation_queue.json',
XSS_ANALYSIS: 'xss_analysis_deliverable.md',
XSS_QUEUE: 'xss_exploitation_queue.json',
AUTH_ANALYSIS: 'auth_analysis_deliverable.md',
AUTH_QUEUE: 'auth_exploitation_queue.json',
AUTHZ_ANALYSIS: 'authz_analysis_deliverable.md',
AUTHZ_QUEUE: 'authz_exploitation_queue.json',
SSRF_ANALYSIS: 'ssrf_analysis_deliverable.md',
SSRF_QUEUE: 'ssrf_exploitation_queue.json',
// Exploitation agents
INJECTION_EVIDENCE: 'injection_exploitation_evidence.md',
XSS_EVIDENCE: 'xss_exploitation_evidence.md',
AUTH_EVIDENCE: 'auth_exploitation_evidence.md',
AUTHZ_EVIDENCE: 'authz_exploitation_evidence.md',
SSRF_EVIDENCE: 'ssrf_exploitation_evidence.md'
};
/**
* Validate JSON structure for queue files
*/
function validateQueueJson(content, type) {
try {
const parsed = JSON.parse(content);
// Queue files must have a 'vulnerabilities' array
if (!parsed.vulnerabilities || !Array.isArray(parsed.vulnerabilities)) {
return {
valid: false,
message: `Invalid ${type}: Missing or invalid 'vulnerabilities' array. Expected format: {"vulnerabilities": [...]}`
};
}
return { valid: true };
} catch (error) {
return {
valid: false,
message: `Invalid JSON in ${type}: ${error.message}`
};
}
}
/**
* Main execution
*/
function main() {
try {
// Parse command line arguments
const args = process.argv.slice(2);
if (args.length < 2) {
console.log(JSON.stringify({
status: 'error',
message: 'Usage: node save_deliverable.js <TYPE> <content>'
}));
process.exit(1);
}
const type = args[0];
const content = args.slice(1).join(' ');
// Validate type
if (!DELIVERABLE_TYPES[type]) {
console.log(JSON.stringify({
status: 'error',
message: `Unknown deliverable type: ${type}. Valid types: ${Object.keys(DELIVERABLE_TYPES).join(', ')}`
}));
process.exit(1);
}
// Validate JSON structure for queue files
if (type.endsWith('_QUEUE')) {
const validation = validateQueueJson(content, type);
if (!validation.valid) {
console.log(JSON.stringify({
status: 'error',
message: validation.message
}));
process.exit(1);
}
}
// Determine file path (deliverables/ directory)
const filename = DELIVERABLE_TYPES[type];
const deliverablesDir = join(process.cwd(), 'deliverables');
const filepath = join(deliverablesDir, filename);
// Ensure deliverables directory exists
try {
mkdirSync(deliverablesDir, { recursive: true });
} catch (error) {
// Directory might already exist, ignore
}
// Write file
writeFileSync(filepath, content, 'utf8');
// Success
console.log(JSON.stringify({ status: 'success' }));
process.exit(0);
} catch (error) {
console.log(JSON.stringify({
status: 'error',
message: `Failed to save deliverable: ${error.message}`
}));
process.exit(1);
}
}
main();