Skip to main content

cross-attack-chains

Use when two or more verified findings may combine into a higher-impact authorized attack path.

소스 정보

저장소
uphiago/recon-skills
최근 소스 활동
2026년 7월 30일 00:23
감지된 SKILL.md 언어
영어
스타
1,297
포크
218

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
cross-attack-chains
description
Use when two or more verified findings may combine into a higher-impact authorized attack path.
version
2.0.0
license
MIT
platforms
["any"]
compatibility
Requires evidence from the owning validation skills
tags
["chains","attack-path","validation","reporting"]
category
chains
related_skills
["attack-patterns-reference","evidence-hygiene","report-writing","triage-validation","wordpress-full-compromise"]
# Cross-Attack Chains An attack chain is a sequence of verified security behaviors in which each step provides a prerequisite for the next. Several findings on the same target do not form a chain unless the dependency between them is demonstrated. ## When to Use - Two or more validated findings affect the same trust boundary. - One finding exposes an identity, token, route, host, or capability needed by another. - A report needs to distinguish standalone impact from compound impact. - The next chain step cannot be tested safely and must be labeled inferred. ## Prerequisites - Captured evidence and negative controls for every component finding. - Current authorization for the compound test and any increased side effects. - Approved identities, synthetic records, callbacks, and cleanup procedure. - A clear stop condition for sensitive data, availability, or scope changes. ## How to Run Create a chain record beneath the target output directory: ```bash TARGET_ID="example-test" OUTPUT_DIR="${OUTPUT_DIR:-./output}" CHAIN_DIR="$OUTPUT_DIR/$TARGET_ID/chains" mkdir -p "$CHAIN_DIR" touch "$CHAIN_DIR/EXPLOIT_CHAINS.md" ``` Use evidence states consistently: | State | Meaning | |---|---| | Observed | Present in captured output | | Confirmed | Security impact reproduced with a control | | Inferred | Plausible dependency that has not been tested | | Not tested | Excluded by scope, safety, or missing prerequisites | ## Procedure ### 1. Normalize Component Findings For each component, record: - expected and observed behavior; - target, identity, and timestamp; - positive evidence and negative control; - side effects and cleanup; - demonstrated impact; - assumptions and testing limits. Discard scanner labels and version-only leads that have not passed their owning skill's verification. ### 2. Draw the Dependency ```text Finding A output: approved user identifier enables: object lookup in Finding B Finding B output: unauthorized synthetic object read enables: none ``` If A and B are merely co-located, document them separately. ### 3. Test the Transition The transition is the core of the chain. Demonstrate that the exact output from one step is accepted by the next step under the same authorized conditions. Examples: | Candidate path | Transition to prove | |---|---| | Source map to hidden API | Extracted base URL resolves to the tested API | | User enumeration to IDOR | Enumerated identifier addresses another approved identity's object | | CORS to protected-data read | Approved browser session returns non-public response to controlled origin | | SSRF to internal service | Controlled callback or response identifies the internal service | | Exposed credential to repository access | Scoped credential is valid for an approved test resource | Do not use real user data, broad credential testing, or destructive operations to bridge a missing transition. ### 4. Recalculate Compound Impact State: 1. what each component demonstrates alone; 2. what additional capability the verified transition creates; 3. which final impact was reproduced; 4. which downstream consequences remain inferred. The chain severity cannot exceed the evidence. A theoretical final step does not become confirmed because earlier steps worked. ### 5. Preserve Cleanup and Limits Record removal of synthetic users, objects, uploads, callbacks, and temporary tokens. If testing stops before the final step, explain why and preserve the last confirmed state. ## Pitfalls - Co-occurrence is not dependency. - A username is not a credential. - A valid credential does not imply access to every service. - File upload does not imply code execution. - Internal reachability does not imply control of an internal service. - Several low-confidence steps compound uncertainty, not confidence. - Compound testing may need authorization beyond the individual findings. ## Verification - Every component passed its owning skill's verification. - Every arrow has evidence that the preceding output enables the next input. - Negative controls distinguish the path from public or expected behavior. - State-changing steps use synthetic resources and include cleanup. - Inferred and not-tested steps remain visibly labeled. - The final report separates demonstrated impact from plausible consequences.
GitHub에서 보기