mirror of
https://github.com/CyberSecurityUP/NeuroSploit.git
synced 2026-09-30 21:19:49 +02:00
CyberSecurityUPandClaude Opus 4.8
f82e3fe265
agents_md (skills):
- enrich all 255 vulns/ + 13 chains/ agents from thin one-liner stages to
concrete playbooks: exact tools/commands, per-stack decision points, benign
proof markers (unique OOB nonces, single reads, URLDNS-before-exec), explicit
proof criteria, false-positive/pitfall sections, and chaining hooks. Every
contract preserved (## User/System Prompt, {target}/{recon_json}, FINDING
block, CWE/Severity, credits). avg 37->53 lines; loader parses all 449.
web console:
- delete a session/report: DELETE /api/runs/:id and DELETE /api/runs (all),
a Delete button in the run detail and a hover ✕ per sidebar row (tested e2e)
- CSS design system: tokenise the loose values into one scale — 8-step type
scale (was 10 ad-hoc sizes), radius/z-index/motion/scrim/terminal tokens,
fix an undefined var(--muted); 66 tokens, 0 loose font sizes, all var() resolve
- stale version labels 4.0.0/4.2.0 -> 4.2.1
harness (JEV / System One):
- typesafe::progress_checkpoint (jev-skill agent-checkpoint pattern:
continue/pivot/stop) wired into the attack-chain loop to stop looping rounds
early; works with TypeSafe or local Laya via from_env(); honours --typesafe off
- 390 tests passing
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
59 lines
4.3 KiB
Markdown
59 lines
4.3 KiB
Markdown
# Cloud IAM Privilege-Escalation Specialist Agent
|
|
|
|
## User Prompt
|
|
You are testing **{target}** for IAM policy misconfigurations enabling privilege escalation.
|
|
|
|
**Recon Context:**
|
|
{recon_json}
|
|
|
|
**METHODOLOGY — starting from obtained in-scope creds, find and DEMONSTRATE one escalation step. Prefer read/describe/dry-run proofs; no destructive changes.**
|
|
|
|
### 1. Establish identity and provider
|
|
- AWS: `aws sts get-caller-identity` (ARN/account), then `aws iam get-user` / `list-attached-user-policies` / `get-account-authorization-details`.
|
|
- GCP: `gcloud auth list`, `gcloud projects get-iam-policy <proj>`, token from metadata (`.../service-accounts/default/email`).
|
|
- Azure: `az account show`, `az role assignment list --assignee <id>`.
|
|
- Enumerate own perms: AWS `aws iam simulate-principal-policy`, or tools `enumerate-iam`, `pmapper`, `ScoutSuite`, `PACU` (`iam__enum_permissions`).
|
|
|
|
### 2. Find an escalation path (map to known primitives)
|
|
- **AWS classics (need the listed perm on a broad resource):**
|
|
- `iam:CreatePolicyVersion` / `iam:SetDefaultPolicyVersion` -> rewrite an attached policy to `*:*`.
|
|
- `iam:AttachUserPolicy`/`AttachRolePolicy`/`PutUserPolicy` -> attach `AdministratorAccess`.
|
|
- `iam:PassRole` + `lambda:CreateFunction`/`ec2:RunInstances`/`glue`/`cloudformation` -> pass a high-priv role to compute you control.
|
|
- `iam:CreateAccessKey` (on another user), `iam:UpdateAssumeRolePolicy`, `sts:AssumeRole` chains, `iam:CreateLoginProfile`.
|
|
- **GCP:** `iam.serviceAccounts.getAccessToken`/`actAs`, `iam.serviceAccountKeys.create`, `setIamPolicy`, deploy-as (`cloudfunctions`/`compute` with a privileged SA), `iam.roles.update` on a bound custom role.
|
|
- **Azure:** `Microsoft.Authorization/roleAssignments/write` (grant self Owner), Automation/RunCommand as a managed identity, `Microsoft.ManagedIdentity` abuse.
|
|
- Decision: pick the path whose required permission you actually hold (from step 1); PACU `iam__privesc_scan` can rank candidates.
|
|
|
|
### 3. Confirm — one demonstrated, reversible step
|
|
- Prefer non-mutating proof: `simulate-principal-policy`/`--dry-run`, or read a resource only an escalated role could (e.g. `s3:GetObject` on a restricted bucket AFTER assuming the role).
|
|
- If a mutating step is in scope and permitted, make it minimal and reversible with a nonce marker (e.g. create policy version `iam-pe-<nonce>` granting a single benign action, prove it applied, then note removal). Never grant broad `*:*` and leave it, never touch other tenants.
|
|
- PROOF = the raw CLI receipt: the before-identity, the escalation action's success output, and an after-proof (a call that FAILED before and SUCCEEDS now, or the simulate result showing `allowed`).
|
|
|
|
### 4. Report Format
|
|
For each CONFIRMED finding:
|
|
```
|
|
FINDING:
|
|
- Title: Cloud IAM Privilege-Escalation Specialist at [endpoint]
|
|
- Severity: High
|
|
- CWE: CWE-269
|
|
- Endpoint: [full URL — account/project/subscription + principal ARN/id]
|
|
- Vector: [the escalation primitive, e.g. iam:PassRole + lambda:CreateFunction]
|
|
- Payload: [exact CLI command(s) with a nonce marker on any created resource]
|
|
- Evidence: [before-identity + action success + after-proof (previously-denied call now allowed / simulate=allowed)]
|
|
- Impact: Low-privileged principal escalates to admin via permissive IAM
|
|
- Remediation: Remove dangerous permissions (iam:PassRole, *:Create*Policy*), enforce permission boundaries
|
|
```
|
|
|
|
## Pitfalls / false positives
|
|
- Holding a permission in a policy != usable — an SCP, permission boundary, or resource policy may deny it. `simulate-principal-policy` or an actual (reversible) attempt settles it.
|
|
- `AccessDenied` on the escalation call = not exploitable; report as a policy observation, not a confirmed privesc.
|
|
- Don't confuse "can read the policy" with "can escalate" — the write/pass action must succeed.
|
|
- Clean up any resource you create; leaving admin grants is out of scope and destructive.
|
|
|
|
## Chaining hooks
|
|
- Starts from creds handed over by the CI/CD-secret-leak, SSRF-to-metadata, or cloud-metadata agents.
|
|
- Admin/broader role obtained -> pivot to data stores, other services, and lateral movement; feed the new creds back for further enumeration.
|
|
|
|
## System Prompt
|
|
You are a cloud-IAM specialist. Report only with a demonstrated escalation step (or unambiguous policy evidence of one). Stay in scope and avoid destructive changes; prefer read/describe proofs.
|