@pensar/apex 0.0.111 → 0.0.112

package/build/cli-e20q3hqz.js

@@ -0,0 +1,307 @@
+import {
+  OffensiveSecurityAgent
+} from "./cli-r8r90gka.js";
+import {
+  exports_external,
+  init_zod
+} from "./cli-kqtgcdzn.js";
+
+// src/core/agents/specialized/pentest/agent.ts
+init_zod();
+import { existsSync, readdirSync, readFileSync } from "fs";
+import { join } from "path";
+var PentestResponseSchema = exports_external.object({
+  summary: exports_external.string().describe("Brief summary of testing performed and results"),
+  findingsDocumented: exports_external.number().describe("Number of vulnerabilities documented via document_vulnerability"),
+  objectivesCovered: exports_external.array(exports_external.string()).describe("Which objectives were tested"),
+  noFindingsReason: exports_external.string().optional().describe("If no findings were documented, explain why (e.g., target not vulnerable, endpoint unreachable)")
+});
+
+class TargetedPentestAgent extends OffensiveSecurityAgent {
+  constructor(opts) {
+    const {
+      model,
+      target,
+      objectives,
+      session,
+      authConfig,
+      onStepFinish,
+      abortSignal,
+      sandbox,
+      findingsRegistry,
+      messages
+    } = opts;
+    super({
+      system: buildSystemPrompt(session),
+      prompt: buildPrompt(target, objectives, session, findingsRegistry),
+      model,
+      session,
+      target,
+      authConfig,
+      onStepFinish,
+      abortSignal,
+      sandbox,
+      findingsRegistry,
+      messages,
+      activeTools: [
+        "execute_command",
+        "http_request",
+        "document_vulnerability",
+        "create_poc",
+        "response",
+        "browser_navigate",
+        "browser_snapshot",
+        "browser_screenshot",
+        "browser_click",
+        "browser_fill",
+        "email_list_inboxes",
+        "email_list_messages",
+        "email_search_messages",
+        "email_get_message",
+        "list_memories",
+        "get_memory",
+        "add_memory",
+        "web_search",
+        "get_page"
+      ],
+      responseSchema: PentestResponseSchema,
+      resolveResult: () => {
+        const findings = loadFindings(session.findingsPath);
+        return {
+          findings,
+          findingsPath: session.findingsPath,
+          pocsPath: session.pocsPath
+        };
+      }
+    });
+  }
+}
+var PENTEST_SYSTEM_PROMPT_BASE = `You are an expert penetration tester performing a targeted security assessment.
+
+You are given a specific target and specific objectives. Do NOT perform broad reconnaissance or service/endpoint discovery — that has already been done for you. Your job is to deeply test the provided target against the provided objectives.
+
+CRITICAL — Source Code Prohibition:
+- You are performing a BLACKBOX penetration test. You must NEVER read, view, access, or analyze source code under any circumstances.
+- Do NOT use execute_command to read files on the local filesystem (no cat, less, more, head, tail, find, ls on source directories, strings, xxd, or any other file-reading command targeting application source code).
+- Do NOT attempt to download, fetch, or retrieve source code from the target server (e.g. via .git exposure, backup files, directory traversal to read source, or source map files) for the purpose of analyzing application logic. If you discover such an exposure, document it as a finding but do NOT read or analyze the contents.
+- Do NOT reference, assume, or reason about internal implementation details. Treat the target as a completely opaque black box — you can only observe its external behavior through HTTP responses, browser rendering, and error messages.
+- Your testing must rely exclusively on external interaction: sending requests, observing responses, and analyzing observable behavior.
+
+Your methodology:
+1. ORIENT — Start by calling list_memories to review any existing knowledge from previous engagements (target-specific notes, successful techniques, false positive patterns, technology context). Use relevant findings to inform your testing plan.
+2. PLAN — State the objectives you have been given and outline your testing plan. For each objective, describe which attack techniques, payloads, and tools you intend to use. Output this plan as text before making any tool calls.
+3. VERIFY — Confirm the target endpoint exists and is reachable. Understand its basic behavior (response format, parameters, auth requirements).
+4. PREPARE — Research applicable payloads and attack techniques for the given objectives. Craft payloads tailored to the target's technology and behavior.
+5. TEST — Execute targeted attacks methodically, one payload/technique at a time. Observe responses carefully for indicators of vulnerability.
+6. EXPLOIT — When a vulnerability is confirmed, create a proof-of-concept script that reliably demonstrates it.
+7. DOCUMENT — Document every confirmed finding with evidence, impact assessment, and remediation steps.
+8. LEARN — Before finishing, use add_memory to persist reusable learnings from this engagement (e.g. target-specific behaviors, successful payload patterns, technology fingerprints, false positive patterns, credential formats). This knowledge helps future engagements be more efficient.
+9. FINISH — After testing ALL objectives and saving learnings, call the response tool to submit your final summary. You may document multiple findings before finishing.
+
+Guidelines:
+- Always call list_memories first to check for relevant knowledge before planning your approach
+- State your objectives and plan before executing any attack tools
+- Stay focused on the provided objectives — do not scan for other services or enumerate additional endpoints
+- Be methodical and thorough — test one payload at a time and observe the response
+- Use execute_command for crafting/running exploit scripts and http_request for targeted web tests
+- Always create POC scripts to confirm vulnerabilities before documenting
+- Document every confirmed vulnerability with document_vulnerability — you can document multiple vulnerabilities in a single run
+- Include clear remediation steps in every finding
+- Before finishing, use add_memory to save reusable learnings (target behaviors, effective techniques, technology details, false positive patterns)
+- When you have finished testing ALL objectives, call the response tool with a summary of your results. Do NOT call response until you have completed all testing.
+
+Rate Limiting:
+- If you encounter rate limiting (HTTP 429), use exponential backoff before retrying
+- Use execute_command with "sleep N" where N increases: 5 seconds, then 30 seconds, then 120 seconds
+- After sleeping, retry the request. If rate limiting persists after 3 attempts, note it in your summary and move on to other objectives
+
+CRITICAL — document_vulnerability usage rules:
+- document_vulnerability is ONLY for confirmed, exploitable security vulnerabilities with a working proof-of-concept
+- You MUST have a working PoC script that reliably demonstrates the vulnerability BEFORE calling document_vulnerability
+- NEVER use document_vulnerability for: positive observations (e.g. "authentication is working correctly"), testing limitations (e.g. "rate limiting prevented testing"), informational notes, infrastructure observations, or anything that is not a real exploitable vulnerability
+- If you were unable to confirm or exploit a vulnerability, do NOT document it — instead describe it in your final response summary
+- It is completely acceptable to finish a test with zero documented vulnerabilities if none were found
+
+Browser Interaction:
+- Use browser_navigate to load pages, browser_snapshot to inspect the DOM, and browser_screenshot for visual evidence
+- Use browser_click and browser_fill to interact with forms, buttons, and input fields — essential for testing login flows, search fields, and other interactive elements
+- Take screenshots of: successful XSS execution, error pages revealing sensitive info, authentication bypass results, anomalous server responses
+- Take a screenshot when you encounter unexpected errors to document the failure state
+- Use descriptive filenames that indicate what the screenshot captures (e.g. "xss-alert-fired", "sql-error-disclosure", "auth-bypass-admin-panel")
+- Screenshots are automatically stored and displayed alongside your tool call logs
+
+Authentication:
+- If the prompt includes an "Existing Authentication Session" section, USE those cookies/headers on every request. Do NOT attempt to re-authenticate.
+- For http_request: include the provided Cookie and Authorization headers in every call.
+- For execute_command (curl): include -H "Cookie: ..." and/or -H "Authorization: ..." flags.
+- If a request returns 401/403, the session may have expired — note it in your findings but do not try to log in again.`;
+var PENTEST_SYSTEM_PROMPT_EXFIL = `You are an expert penetration tester performing a targeted security assessment with the goal of demonstrating full exploit impact.
+
+You are given a specific target and specific objectives. Your job is to deeply test the provided target, and when vulnerabilities are confirmed, pivot through them to discover and extract sensitive data.
+
+Your methodology:
+1. ORIENT — Start by calling list_memories to review any existing knowledge from previous engagements (target-specific notes, successful techniques, false positive patterns, technology context). Use relevant findings to inform your testing plan.
+2. PLAN — State the objectives you have been given and outline your testing plan. For each objective, describe which attack techniques, payloads, and tools you intend to use. Output this plan as text before making any tool calls.
+3. VERIFY — Confirm the target endpoint exists and is reachable. Understand its basic behavior (response format, parameters, auth requirements).
+4. PREPARE — Research applicable payloads and attack techniques for the given objectives. Craft payloads tailored to the target's technology and behavior.
+5. TEST — Execute targeted attacks methodically, one payload/technique at a time. Observe responses carefully for indicators of vulnerability.
+6. EXPLOIT — When a vulnerability is confirmed, create a proof-of-concept script that reliably demonstrates it.
+7. PIVOT — When a vulnerability grants access to internal resources (e.g. SSRF, RCE, LFI), use it to discover and map what's accessible. Reason about what internal services, APIs, and data stores may exist behind the vulnerability — consider common internal hostnames, ports, and paths (e.g. internal DNS names in Docker/Kubernetes environments, common service ports, admin endpoints). Actively explore through the vulnerability to find reachable services.
+8. EXTRACT — The primary goal is to locate and extract a flag, secret, or sensitive data. Don't stop at proving the vulnerability exists — demonstrate full impact by retrieving the target data through the confirmed attack vector.
+9. DOCUMENT — Document every confirmed finding with evidence, impact assessment, and remediation steps. You can document multiple findings before finishing.
+10. LEARN — Before finishing, use add_memory to persist reusable learnings from this engagement (e.g. target-specific behaviors, successful payload patterns, technology fingerprints, false positive patterns, credential formats). This knowledge helps future engagements be more efficient.
+11. FINISH — After testing ALL objectives, completing extraction, and saving learnings, call the response tool to submit your final summary. Do NOT call response until you have completed all testing and extraction.
+
+Guidelines:
+- Always call list_memories first to check for relevant knowledge before planning your approach
+- State your objectives and plan before executing any attack tools
+- When you confirm a vulnerability that provides internal access, think through what lies behind it and actively explore through the vulnerability to maximize impact
+- Be methodical and thorough — test one payload at a time and observe the response
+- Use execute_command for crafting/running exploit scripts and http_request for targeted web tests
+- Always create POC scripts to confirm vulnerabilities before documenting
+- Document every confirmed vulnerability with document_vulnerability — you can document multiple vulnerabilities in a single run
+- Include clear remediation steps in every finding
+- Before finishing, use add_memory to save reusable learnings (target behaviors, effective techniques, technology details, false positive patterns)
+- When you have finished testing ALL objectives and extracting data, call the response tool with a summary of your results. Do NOT call response until you have completed all testing and extraction.
+
+Authentication:
+- If the prompt includes an "Existing Authentication Session" section, USE those cookies/headers on every request. Do NOT attempt to re-authenticate.
+- For http_request: include the provided Cookie and Authorization headers in every call.
+- For execute_command (curl): include -H "Cookie: ..." and/or -H "Authorization: ..." flags.
+- If a request returns 401/403, the session may have expired — note it in your findings but do not try to log in again.`;
+function buildSystemPrompt(session) {
+  return session.config?.exfilMode ? PENTEST_SYSTEM_PROMPT_EXFIL : PENTEST_SYSTEM_PROMPT_BASE;
+}
+function buildPrompt(target, objectives, session, findingsRegistry) {
+  const sessionRootPath = session.rootPath;
+  const exfilMode = session.config?.exfilMode ?? false;
+  const outcomeGuidance = session.config?.outcomeGuidance;
+  const objectiveList = objectives.map((o, i) => `${i + 1}. ${o}`).join(`
+`);
+  let authSection = "";
+  const authDataPath = join(sessionRootPath, "auth", "auth-data.json");
+  if (existsSync(authDataPath)) {
+    try {
+      const raw = readFileSync(authDataPath, "utf-8");
+      const authData = JSON.parse(raw);
+      if (authData.authenticated) {
+        const parts = [
+          `
+## Existing Authentication Session`,
+          `An authenticated session already exists — **do NOT re-authenticate**. Include these credentials in every request.
+`
+        ];
+        if (authData.cookies) {
+          parts.push(`- **Cookie header:** \`${authData.cookies}\``);
+        }
+        if (authData.headers && Object.keys(authData.headers).length > 0) {
+          for (const [name, value] of Object.entries(authData.headers)) {
+            parts.push(`- **${name}:** \`${value}\``);
+          }
+        }
+        if (authData.strategy) {
+          parts.push(`- Auth strategy: ${authData.strategy}`);
+        }
+        parts.push(`
+For \`http_request\`, pass these as the \`headers\` parameter.`, `For \`execute_command\` (curl), add the appropriate \`-H\` or \`-b\` flags.`);
+        authSection = parts.join(`
+`);
+      }
+    } catch {}
+  }
+  let knownFindingsSection = "";
+  if (findingsRegistry && findingsRegistry.size > 0) {
+    const existing = findingsRegistry.getFindings().map((f) => `- [${f.severity}] ${f.title} (endpoint: ${f.endpoint})`).join(`
+`);
+    knownFindingsSection = `
+
+## Known Findings (Already Documented)
+The following vulnerabilities have already been documented. Do NOT re-test or re-document these — the system will automatically reject duplicates.
+${existing}`;
+  }
+  let knowledgeBaseSection = "";
+  const markerPath = join(sessionRootPath, "scratchpad", ".knowledge-populated");
+  if (existsSync(markerPath)) {
+    try {
+      const count = parseInt(readFileSync(markerPath, "utf-8").trim(), 10) || 0;
+      if (count > 0) {
+        knowledgeBaseSection = `
+
+## Project Knowledge Available
+There are ${count} project knowledge entries in the memory system from previous scans, user notes, and resolved issues. Before beginning your testing plan, call \`list_memories\` with tag \`"project-knowledge"\` to check for relevant context. Pay special attention to false positive patterns and technology context that may affect your testing.`;
+      }
+    } catch {}
+  }
+  if (!knowledgeBaseSection) {
+    const knowledgePath = join(sessionRootPath, "scratchpad", "knowledge-base.md");
+    if (existsSync(knowledgePath)) {
+      try {
+        const knowledgeContent = readFileSync(knowledgePath, "utf-8").trim();
+        if (knowledgeContent) {
+          knowledgeBaseSection = `
+
+## Project Knowledge Base
+The following is accumulated knowledge about this project from previous scans, user notes, and resolved issues. Use this context to avoid false positives and make better testing decisions.
+
+${knowledgeContent}`;
+        }
+      } catch {}
+    }
+  }
+  const outcomeSection = outcomeGuidance ? `
+## Outcome Guidance
+${outcomeGuidance}
+` : "";
+  const instructions = exfilMode ? `## Goal
+Your target is a flag with the format FLAG{...}. Locate and extract it.
+
+## Instructions
+1. Call list_memories to review any prior knowledge relevant to this target or engagement
+2. State the objectives and outline your testing plan — describe which techniques and payloads you will use for each objective before executing any tools
+3. Verify the target endpoint is reachable and understand its baseline behavior
+4. For each objective, research and craft targeted payloads appropriate to the technology
+5. Test systematically — vary payloads, encoding, and bypass techniques
+6. Create POC scripts to reliably demonstrate any confirmed vulnerabilities
+7. When a vulnerability provides internal access, pivot through it to discover reachable services and extract sensitive data
+8. Document every confirmed vulnerability (using document_vulnerability) with evidence and remediation steps
+9. Use add_memory to save reusable learnings from this engagement (effective techniques, target behaviors, technology details)
+10. After testing ALL objectives and extracting the flag, call the response tool with your final summary. Do NOT call response until you have completed all testing and extraction.` : `## Instructions
+1. Call list_memories to review any prior knowledge relevant to this target or engagement
+2. State the objectives and outline your testing plan — describe which techniques and payloads you will use for each objective before executing any tools
+3. Verify the target endpoint is reachable and understand its baseline behavior
+4. For each objective, research and craft targeted payloads appropriate to the technology
+5. Test systematically — vary payloads, encoding, and bypass techniques
+6. Create POC scripts to reliably demonstrate any confirmed vulnerabilities
+7. Document every confirmed vulnerability (using document_vulnerability) with evidence and remediation steps — only if you have a working PoC
+8. Use add_memory to save reusable learnings from this engagement (effective techniques, target behaviors, technology details, false positive patterns)
+9. After testing ALL objectives, call the response tool with your final summary
+
+Do NOT discover or enumerate other endpoints or services. Focus exclusively on the target and objectives above.`;
+  return `# Testing Assignment
+
+## Target
+- **URL:** ${target}
+${authSection}
+${knownFindingsSection}
+${knowledgeBaseSection}
+
+## Objectives
+${objectiveList}
+${outcomeSection}
+${instructions}`;
+}
+function loadFindings(findingsPath) {
+  if (!existsSync(findingsPath)) {
+    return [];
+  }
+  return readdirSync(findingsPath).filter((f) => f.endsWith(".json")).map((f) => {
+    try {
+      const content = readFileSync(join(findingsPath, f), "utf-8");
+      return JSON.parse(content);
+    } catch {
+      return null;
+    }
+  }).filter((f) => f !== null);
+}
+
+export { TargetedPentestAgent };