@gpzhang2001/sharpkit-skills 0.2.1

package/skills/analysis/severity_calibration.md

@@ -0,0 +1,130 @@
+---
+name: severity-calibration
+description: Qualitative rubric for what actually deserves high/critical severity, and an acceptance checklist to apply before rating a finding
+---
+
+# Severity Calibration
+
+CVSS gives you a number once you have chosen the metrics. This skill is
+about choosing them honestly — deciding what class of issue genuinely
+belongs at each severity before you fill in the vector.
+
+Calibrate severity **after** you have established reachability and run
+the counterevidence pass, never before. Severity is a conclusion, not an
+opening position.
+
+## The Test That Matters
+
+Before rating anything high or critical, ask:
+
+> Would this be accepted as high/critical in serious audit or bug bounty
+> triage, by a firm putting its reputation on the line?
+
+If the honest answer is "only if you accept a chain of assumptions", it
+is not high. Rate the weakness you proved, not the worst case you can
+imagine reaching from it.
+
+## Critical
+
+Reserve for findings where a realistic attacker gets decisive control or
+mass data access, with evidence:
+
+- Unauthenticated remote code execution, or command/code execution
+  reachable by any user on internet-exposed surface.
+- Full authentication bypass, or trivially forgeable authentication
+  (accepted unsigned tokens, `alg: none`, signature not verified).
+- Mass extraction of other users' or other tenants' sensitive data.
+- Compromise of signing keys, control-plane credentials, or credentials
+  granting broad infrastructure access.
+- Complete cross-tenant isolation failure in a multi-tenant system.
+
+Factors that push a high up to critical: no authentication required,
+internet reachable, zero user interaction, wormable/self-propagating,
+or the impact spans all tenants rather than one.
+
+## High
+
+- Authenticated RCE, or RCE requiring a common non-privileged role.
+- Privilege escalation crossing a real trust boundary (user → admin,
+  tenant → tenant, read → write on protected objects).
+- Object-level authorization failures exposing or modifying other users'
+  sensitive data at scale.
+- SQL injection or equivalent injection reaching real data.
+- SSRF that demonstrably reaches internal services, cloud metadata, or
+  credentials.
+- Sensitive credential or PII exposure that an attacker can actually
+  reach.
+
+## Medium
+
+- Stored XSS in a limited context, or reflected XSS requiring user
+  interaction.
+- CSRF on a meaningful state-changing action.
+- Authorization gaps on lower-value objects.
+- Information disclosure that materially aids a further attack.
+- Findings whose high-impact version is blocked by a real constraint you
+  confirmed (internal-only exposure, a required privileged role, a
+  narrow precondition).
+
+## Low / Informational
+
+- Missing security headers, cookie flag issues, verbose errors.
+- Self-XSS, or XSS requiring the victim to paste a payload.
+- Open redirect with no credential or token leakage.
+- Rate-limiting and enumeration issues without a demonstrated impact.
+- Defense-in-depth gaps with no reachable exploitation path.
+
+## Usually NOT High or Critical
+
+These are over-rated constantly. Each needs unusual, demonstrated
+circumstances to exceed medium:
+
+- Self-XSS and clickjacking on non-sensitive actions.
+- Missing headers, cookie attributes, TLS configuration nits.
+- Open redirect on its own.
+- Theoretical memory-safety issues with no reachable attacker input.
+- "Could matter if chained with several unproven assumptions."
+- Anything already requiring admin, shell, or physical access — if the
+  attacker already has that, the finding adds little.
+- Session-management weaknesses that require the attacker to already
+  hold a victim secret (a stolen cookie, an intercepted link). The
+  acquisition of that secret is not free; unless the *same* finding shows
+  how to obtain it, this is usually low/medium.
+- Enumeration that only confirms an account, domain, or version exists.
+
+## Downgrade, Don't Delete
+
+A finding that turns out to be constrained gets a lower severity — not a
+silent drop. Internal-only reachability, a required privileged role, or a
+narrow precondition are all reasons to reduce severity and say so in the
+report. They are not reasons to withhold the finding.
+
+Equally: missing evidence about deployment or exposure lowers your
+**confidence**, not the severity floor. Do not treat "I could not confirm
+this is internet-facing" as if it were "this is internal-only".
+
+## Acceptance Checklist for High / Critical
+
+All of these must be true. If any is not, drop a level:
+
+- [ ] The attack path is realistic and in scope — not a lab-only
+      condition, not dependent on an unproven prior compromise.
+- [ ] The attacker position required is one an attacker can actually
+      obtain, and the CVSS `privileges_required` / `attack_complexity`
+      reflect that honestly.
+- [ ] The impact is material and demonstrated, not asserted — `C:H` /
+      `I:H` mean proven broad or systemic read/write, not one record.
+- [ ] The counterevidence pass found no constraint that meaningfully
+      limits exploitation, or you have explained why the constraint does
+      not hold.
+- [ ] You have concrete evidence of reachability, not an assumption
+      about how the application is deployed.
+- [ ] You would defend this rating in a client debrief.
+
+## Output
+
+Severity still comes from the CVSS vector — this rubric decides which
+vector is honest. When your intuitive rating and the computed CVSS
+severity disagree, re-examine the metrics: usually one of
+`privileges_required`, `attack_complexity`, or the impact triad was set
+optimistically. Fix the metric, do not override the result.

package/skills/analysis/source_aware_discovery.md

@@ -0,0 +1,211 @@
+---
+name: source-aware-discovery
+description: Enumeration discipline for reading code — which locations to keep as separate candidates, which safe siblings prove nothing, and the per-family sweeps that are routinely missed
+---
+
+# Source-Aware Discovery
+
+Reading code for bugs fails in two directions. You collapse many real
+instances into one candidate and under-report, or you stop at the loudest
+issue in a file and never sweep the family around it.
+
+This skill is about *what to enumerate*, not how to exploit it — the
+vulnerability-class skills cover exploitation. Discovery decides
+plausibility and preserves evidence; severity comes later.
+
+## Instance Discipline
+
+**One root cause is not one candidate.** If a dangerous helper has six
+call sites and four are independently reachable, that is four candidates
+— not one "the helper is unsafe" note. Each needs its own source, its own
+closest control, and its own line. A reader has to be able to fix them
+individually.
+
+**Do not collapse distinct proof tuples that share a route.** Command
+execution, SSRF, path/file write, parser abuse, template execution, and
+authorization bypass on the same endpoint are separate findings when the
+sink, the broken control, or the impact differ. Sharing a URL is not
+sharing a bug.
+
+**Keep the wrapper and the shared helper both visible.** When the path
+crosses from an entrypoint into a shared sink or control, record both:
+the wrapper proves reachability, the helper is where the fix goes. Losing
+either one makes the finding unactionable.
+
+**A safe sibling is a negative control for itself and nothing else.** A
+correctly-parameterized query three lines above a concatenated one proves
+the developer knew better, not that the concatenated one is safe.
+
+**Label your locations.** Mark each as entrypoint, root control, sink, or
+concrete implementation. Multi-location findings that don't say which
+line is which force the reader to re-derive your analysis.
+
+## Where the Real Control Lives
+
+The most common discovery error is anchoring on the dramatic sink and
+missing the reusable broken control behind it.
+
+- When a resolver, allowlist, denylist, class filter, or guard is the
+  thing that's wrong, that line is the candidate. The transport that
+  reaches it proves reachability — it doesn't replace it.
+- When the same filter or resolver is **duplicated** across core, server,
+  client, plugin, or import packages, each copy is its own candidate.
+  Fixing one leaves the others live.
+- In a concrete strategy / handler / converter / operation subclass, read
+  the specialized helper, not just the top-level `handle` / `apply` /
+  `perform` override. If the subclass splits, filters, canonicalizes, or
+  rebuilds attacker input before delegating to a shared evaluator, the
+  subclass line is the root control.
+- Branch-specific transforms — append, wildcard, fallback, copy/move
+  `from`, default-value, type-resolution — routinely bypass or narrow the
+  shared validator. Keep the branch predicate as its own location. A
+  finding on the shared helper does not close them.
+
+## Family Sweeps
+
+When you find one instance of these, sweep the whole family before
+closing it out.
+
+**Deserialization / object construction.** Enumerate every registered
+codec, deserializer, converter, and container handler — array,
+collection, map, bean, enum, throwable, generic object. A top-level
+parser-config finding does not close a concrete codec that recursively
+re-invokes parsing or type resolution on attacker data.
+
+**XML / parsers.** Enumerate parser factories, readers, converters,
+validators, transformers, and unmarshal entrypoints independently.
+Hardening that is best-effort does not suppress anything: a
+secure-processing flag alone, a `setFeature` call whose failure is
+swallowed or logged, or a safe default factory all leave
+caller-supplied factories and converter paths open.
+
+**Object models for untrusted formats.** Sweep the primitive and
+container helpers that traverse or convert attacker-controlled documents
+— `to*Array`, `get*`, numeric conversion, `parse*`, iterators, size
+accessors, unchecked casts, allocation loops. Missing type, size, shape,
+recursion, or numeric guards here cause type confusion, unbounded
+traversal, and resource exhaustion. These sweeps create candidate rows,
+not automatic findings — promote one only when malformed input plausibly
+reaches it and the missing guard has a concrete security effect.
+
+**Archive extraction and import/restore.** Keep four things visible per
+operation: the member name, the destination join, the containment check,
+and the extract/write call. A later copy step, manifest gate, or UUID
+check does not close it if the write already happened. "The stdlib
+normalizes paths" is not containment evidence — the code must show
+per-entry containment *before* the write, including symlink, hardlink,
+and recursive-copy paths. The write does not need to escape the app root
+to matter: overwriting config, a peer tenant's directory, or a shared
+imported subtree is still file impact.
+
+**Path-sensitive filesystem operations.** Enumerate each exported
+operation separately — restore, import, export, backup, copy, move,
+download, open, key/config fetch. For each, keep the decode, join,
+normalize, canonicalize, strip-prefix, extension-check, and
+destination-selection lines candidate-visible.
+
+**Static-file and resource serving.** The candidate is the line that
+decides whether an attacker-chosen path is allowed: the allowlist, the
+matcher, the canonicalization, the URL decode, the resource selection. Do
+not substitute a safer sibling handler for the vulnerable legacy one.
+
+**Outbound requests.** For URL importers, webhook and callback clients,
+preview/render fetchers, `downloadFrom`-style helpers, and
+redirect-following clients: enumerate each attacker-controlled
+destination and its closest allow/deny/redirect control. Do not drop the
+row because the fetch is an intended feature, because the filter is
+operator-configured or empty by default, or because it only runs
+pre-request.
+
+**Command and action runners.** Enumerate every attacker-controllable
+argument type and execution mode before you call command injection
+covered. Type-safety maps, unsafe-type denylists, template substitution,
+shell wrapping, direct-exec branches, and API-side argument ingestion are
+each separate controls. A denylist covering three types says nothing
+about the no-op typecheck branches that still render into a shell string.
+Frontend widget constraints are not controls at all.
+
+**Query APIs (SQL, NoSQL, LDAP, XPath, and friends).** Do not suppress
+because the endpoint is already user-facing, because it's an insert
+rather than a read, or because a later business check appears to limit
+the effect. If attacker input reaches query syntax or selector operators,
+carry it forward and record the later check as counterevidence.
+
+**Structured patch / edit APIs.** For JSON Patch, document edits, and
+config mutations, enumerate the request-selected operations — add,
+remove, replace, move, copy, test. Operation-specific path transforms,
+array-append handling, and wildcard selection stay candidate-visible when
+they feed a shared evaluator or binder.
+
+**Authentication state machines.** The candidate is the line that
+installs or reuses a principal, credential, token, issuer, or protocol
+state *after* a transition — pre-auth to authenticated, TLS upgrade,
+redirect, assertion consumption, IdP handoff. Missing rebind or
+reauthentication at that seam authenticates the wrong identity.
+
+**SSO / SAML / federation.** Keep response and assertion validators
+distinct from generic claims authorizers and from service-method
+authorization; they fail differently. Include the lines doing assertion
+selection, list indexing, DOM access, node cloning, signed-object lookup,
+subject confirmation, recipient, audience, destination, ACS URL, and
+issuer binding — each decides *which* assertion is trusted.
+
+The signature failure to watch for: a validation loop or a
+`foundValid`-style flag, followed by a **separate** fixed-index,
+first-element, clone, re-serialization, or return path. Treat that later
+selection line as the broken control until you have proven the validated
+object and the consumed object are byte-identical and equally bound. This
+is the validated-vs-consumed mismatch, and it is invisible if you only
+read the validator.
+
+**Realms and authenticators.** Enumerate the concrete implementations —
+LDAP, Kerberos, PAM, SAML, OAuth/OIDC, custom realms — before promoting a
+generic HTTP auth finding. In multi-step or TLS-upgraded binds, keep the
+bind/rebind and credential-installation line visible.
+
+**Self-service update routes.** Include the guard that compares the
+requested object against the persisted one. Missing checks on
+security-sensitive scalars and collection aliases let a user change their
+own identity, roles, group membership, tenancy, or account-recovery
+properties.
+
+**Protocol utility code.** In protocol-heavy repositories, read the
+version, capability, feature, and negotiation helpers even when the
+obvious candidates are REST and admin routes. Look for `Version`,
+`versionCompare`, `Capability`, `Feature`, `Negotiation`, and the
+comparator methods around them — downgrade and confusion bugs live there,
+and nobody looks.
+
+**Public webhook / status / callback endpoints.** Enumerate these
+independently from nearby credential bugs whenever they read protected
+objects, trigger jobs, or mutate protected state.
+
+## Cross-Boundary Inputs
+
+In frameworks and libraries, stored client, tenant, application, IdP,
+exception, and imported-configuration values are attacker-controlled when
+they are later rendered, evaluated, parsed, or used for authorization —
+provided there is a plausible runtime path from some boundary. Do not
+suppress just because the writer lives outside this repository. That
+requires evidence the value is trusted-only in normal deployments, not an
+assumption.
+
+Similarly, do not suppress a high-impact candidate because the API is
+deprecated, opt-in, or documented as dangerous. Record that as a
+precondition and keep the candidate — shipped code with a bypassable
+control is shipped code.
+
+## The Finding Bar
+
+Worth opening a candidate: authorization bypass, confused deputy, SSRF,
+path traversal, injection with a real sink, cross-tenant exposure,
+sensitive state change without enforcement, sandbox or trust-boundary
+escape.
+
+Not worth it: "this could use more validation" with no path, style and
+maintainability complaints, and cosmetic variants of a candidate you
+already opened.
+
+Keep reading until no distinct plausible candidate remains — then record
+what you swept with `record_coverage`, including the families that came
+back clean.

package/skills/cloud/aws.md

@@ -0,0 +1,231 @@
+---
+name: aws
+description: AWS cloud security testing covering IAM misconfigurations, S3 exposure, metadata abuse, and privilege escalation paths
+---
+
+# AWS Cloud Security
+
+AWS misconfigurations frequently expose credentials, data, and lateral movement paths. This skill covers direct AWS API testing and post-compromise enumeration from EC2/Lambda/container workloads. For SSRF-mediated metadata access, combine with the ssrf skill.
+
+## Attack Surface
+
+**Identity**
+- IAM users, roles, groups, policies (inline and managed)
+- Access keys, session tokens, SSO/SAML federation
+- Cross-account roles, trust policies, permission boundaries
+
+**Storage & Data**
+- S3 buckets, objects, bucket policies, ACLs, Block Public Access settings
+- EBS snapshots, RDS snapshots, AMIs shared publicly
+- Secrets Manager, SSM Parameter Store, KMS keys
+
+**Compute**
+- EC2 instances, Lambda functions, ECS/EKS tasks
+- Instance metadata service (IMDSv1/v2) at `169.254.169.254`
+- User data, launch templates, AMIs
+
+**Network**
+- Security groups, NACLs, VPC endpoints, public subnets
+- ELB/ALB/CloudFront misconfigurations
+
+**Management**
+- CloudTrail, Config, GuardDuty gaps
+- Cognito user pools, API Gateway, AppSync
+
+## Reconnaissance
+
+**Credential Discovery**
+- Environment variables: `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`
+- `~/.aws/credentials`, `~/.aws/config`, CI/CD env vars, `.env` files
+- Hardcoded keys in source, mobile apps, JavaScript bundles
+
+**Unauthenticated Enumeration**
+
+Use two separate checks — they answer different questions and must not be conflated:
+
+**1. Bucket existence (does the name resolve?)**
+
+Goal: learn whether a bucket name exists in AWS, without needing `s3:ListBucket`.
+- `head-bucket` or `curl -I` HTTP status is the signal — not `aws s3 ls`.
+- `403 Forbidden` → bucket exists but you lack access (private or wrong account).
+- `404 Not Found` → bucket does not exist in that region, or name is wrong.
+
+```
+aws s3api head-bucket --bucket target-bucket --no-sign-request 2>&1
+curl -I https://target-bucket.s3.amazonaws.com/
+```
+
+**2. Public listing (is ListBucket granted to anonymous users?)**
+
+Goal: confirm `s3:ListBucket` is publicly granted — a separate and stronger finding than existence alone.
+- Only run `aws s3 ls` for this step; a successful listing returns object keys/prefixes.
+- Failure here does not disprove existence (a private bucket still returns 403 on list).
+
+```
+aws s3 ls s3://target-bucket --no-sign-request
+```
+
+**Authenticated Enumeration (with any credentials)**
+```
+aws sts get-caller-identity
+aws iam get-account-authorization-details 2>/dev/null
+aws iam list-users
+aws iam list-roles
+aws iam list-attached-user-policies --user-name <user>
+aws s3 ls
+aws ec2 describe-instances
+```
+
+## Key Vulnerabilities
+
+### S3 Misconfigurations
+
+- Public read/write buckets (ACL `public-read`, policy `"Principal":"*"`)
+- AuthenticatedUsers group grants (`http://acs.amazonaws.com/groups/global/AuthenticatedUsers`)
+- ListBucket enabled publicly → object key enumeration
+- Sensitive object keys guessable: `backup/`, `db/`, `.env`, `config/`, `logs/`
+
+**Test:**
+```
+aws s3 ls s3://BUCKET --no-sign-request
+aws s3 cp s3://BUCKET/sensitive-file . --no-sign-request
+curl https://BUCKET.s3.amazonaws.com/
+```
+
+### IAM Privilege Escalation
+
+Common escalation paths (verify with `aws iam simulate-principal-policy` when possible):
+
+| Permission | Escalation |
+|------------|------------|
+| `iam:CreatePolicyVersion` | Attach admin policy version to self |
+| `iam:SetDefaultPolicyVersion` | Roll back to older permissive policy version |
+| `iam:PassRole` + `lambda:CreateFunction` | Create Lambda with admin role, invoke |
+| `iam:PassRole` + `ec2:RunInstances` | Launch EC2 with instance profile |
+| `sts:AssumeRole` on overprivileged role | Cross-account or same-account pivot |
+| `iam:UpdateAssumeRolePolicy` | Add self to trust policy of privileged role |
+| `iam:AttachUserPolicy` / `PutUserPolicy` | Self-grant admin |
+
+**Test:**
+```
+aws iam list-attached-user-policies --user-name $(aws sts get-caller-identity --query Arn --output text | cut -d/ -f2)
+aws iam simulate-principal-policy --policy-source-arn <arn> --action-names iam:CreateAccessKey --resource-arns "*"
+```
+
+### Instance Metadata Abuse
+
+**IMDSv1 (no token required)**
+```
+curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
+curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
+curl http://169.254.169.254/latest/user-data
+```
+
+**IMDSv2 bypass contexts**
+- SSRF with header injection if server forwards `X-aws-ec2-metadata-token`
+- Container sidecars without hop limit enforcement
+- Misconfigured proxies allowing link-local access
+
+### Snapshot and Backup Exposure
+
+- Public EBS/RDS snapshots: `aws ec2 describe-snapshots --restorable-by-user-names all`
+- AMIs with `Public` launch permission containing secrets or keys
+- Backup vaults cross-account without proper isolation
+
+### Lambda and Serverless
+
+- Overprivileged execution roles (`AdministratorAccess` on Lambda role)
+- Environment variables containing secrets (visible via `lambda:GetFunctionConfiguration`)
+- Function URLs or API Gateway without auth
+- Event source mappings triggering on attacker-controlled events
+
+### Cognito Misconfigurations
+
+- Self-signup enabled with elevated default group membership
+- Missing app client secret on confidential flows
+- Custom attribute write permissions allowing privilege fields (`custom:role`, `custom:admin`)
+- ID token custom claims trusted by backend without verification
+
+### KMS and Secrets
+
+- KMS key policies allowing `Principal: *` or overly broad accounts
+- Secrets Manager secrets readable by unintended roles
+- SSM parameters under `/` with `GetParameter` for unauthenticated or low-priv callers
+
+## Advanced Techniques
+
+**Cross-Account Role Assumption**
+- Find roles trusting `*` or external accounts broadly
+- Confused deputy: service assumes role without external ID validation
+
+**CloudFront Origin Exposure**
+- Origin pointing directly to S3 website or ALB bypassing WAF
+- Signed URL/cookie misconfiguration allowing object access
+
+**Resource-Based Policy Gaps**
+- S3 bucket policy allowing `s3:GetObject` from unintended principals
+- Lambda resource policy `Principal: *` with weak condition keys
+
+## Testing Methodology
+
+1. **Discover credentials** — Keys in code, env, metadata, or SSRF
+2. **Identify principal** — `get-caller-identity`, map effective permissions
+3. **Enumerate resources** — S3, EC2, IAM, Lambda within policy bounds
+4. **Escalation paths** — Run escalation checklist against attached policies
+5. **Data exposure** — Public buckets, snapshots, secrets, user-data scripts
+6. **Persistence** — New access keys, backdoor roles, Lambda triggers (only in authorized scope)
+
+## Validation
+
+1. Demonstrate unauthorized read/write of S3 objects or snapshots with evidence (object keys, ETags)
+2. Show IAM escalation from low-priv to higher-priv with exact API calls and resulting permissions
+3. Prove metadata credential theft path (SSRF or IMDS) with redacted temporary credentials scope
+4. Document resource ARN, policy statement, and misconfiguration root cause
+5. Confirm fix would block the specific principal/action/resource combination
+
+## False Positives
+
+- Intentionally public static assets bucket with no sensitive keys
+- Read-only `s3:ListBucket` on empty marketing bucket
+- Metadata endpoint unreachable from tested context (no SSRF, IMDSv2 enforced with hop limit)
+- Simulated escalation blocked by permission boundary or SCP
+- 403 on S3 that indicates existence but not readable content (still note for recon, not data breach)
+
+## Impact
+
+- Mass data exfiltration from S3/RDS/snapshots
+- Full account or organization compromise via IAM escalation
+- Persistent backdoor access through new keys or roles
+- Regulatory exposure (PII/PCI in unencrypted public buckets)
+
+## Pro Tips
+
+1. Always run `get-caller-identity` first to know your effective principal
+2. Distinguish 403 vs 404 on S3 — both are useful, mean different things
+3. Check instance profile role, not just user credentials, from metadata
+4. Review trust policies on roles, not just permission policies
+5. Combine with subdomain takeover — dangling S3 bucket names in DNS CNAMEs
+
+## Tooling
+
+Prefer credential-light, install-once CLIs. The sandbox has `awscli`/`python`/`pipx`/`go` and build-time egress.
+
+- **awscli** — the primary enumeration tool (used throughout this skill). Always start with `aws sts get-caller-identity`.
+- **enumerate-iam** (andresriancho) — tiny script that brute-forces which API calls a set of keys can make when you can't read your own policy:
+  ```
+  git clone https://github.com/andresriancho/enumerate-iam && cd enumerate-iam
+  pip install -r requirements.txt
+  python enumerate-iam.py --access-key AKIA... --secret-key ...
+  ```
+- **cloudsplaining** (Salesforce) — offline IAM policy risk analysis; finds privilege-escalation/resource-exposure in the auth-details JSON:
+  ```
+  pipx install cloudsplaining
+  aws iam get-account-authorization-details > auth.json
+  cloudsplaining scan --input-file auth.json
+  ```
+- **CloudFox** (BishopFox) — single Go binary for fast post-compromise inventory and "what can I do from here" surfacing: `cloudfox aws --profile <profile> all-checks`
+- **Pacu** (Rhino Security Labs) — the standard AWS exploitation framework; heavier, but its `iam__privesc_scan` module automates the escalation table above. Use for a full exploitation session (`run iam__enum_permissions`, then `run iam__privesc_scan`).
+
+## Summary
+
+AWS security requires least-privilege IAM, blocked public data paths, IMDSv2 with hop limits, and tight resource policies. Enumerate from any credential found — even limited read access often reveals escalation chains.