Added pathrunner to pathfinding.cloud

.claude/commands/workflows/orchestrator.md

@@ -87,6 +87,16 @@ references: []
 - `learningEnvironments` (learning-environments agent)
 - `detectionTools` (detection-tools agent)
 
+### Exploitation tool tabs by cloud
+
+Always include the native CLI tab for the path's cloud (`awscli`, `gcloud`, or `azurecli`). Where an exploitation framework module verifiably covers the path's exact technique, add it as an additional tab (each cloud has its own — do not cross-apply an AWS tool to a GCP/Azure path or vice versa):
+
+- **AWS**: `pacu`, `pmapper`, `stratus`, `leonidas`, `nebula`, `pathrunner`
+- **GCP**: `gcpwn` (NetSPI's GCP pentesting framework) — check its module tree at `gcpwn/modules/gcp/{service}/{enumeration,exploit,utilities}/` on https://github.com/NetSPI/GCPwn for a module matching the required permission(s) (e.g. `exploit_generate_access_token` for `iam.serviceAccounts.getAccessToken`, `exploit_service_account_keys` for `iam.serviceAccountKeys.create`). Modules are invoked as `modules run <module_name> [flags]` — see the README's "Exploit Module TLDR" section for real flag examples before writing commands.
+- **Azure**: none established yet
+
+Never fabricate a tool tab or invocation syntax — verify the module/command actually exists (e.g. by browsing the tool's repo) before adding it. If no framework module covers this specific technique, omit the extra tab and use only the native CLI.
+
 ### Follow formatting guidelines:
 
 Per @.claude/CLAUDE.md:

.claude/references/detection-tools-gcp.md

@@ -19,9 +19,13 @@ Open source security tools to check for GCP IAM privilege escalation detection c
 - **Repository**: https://github.com/google/gcp_scanner
 - **What to look for**: This is a recon/scanning tool (built by Google) rather than a pure detector — check if it specifically enumerates or flags the permission combination used by this path (e.g. service account impersonation chains via `iam.serviceAccounts.getAccessToken`/`actAs`)
 
+## 4. GCPwn (NetSPI)
+- **Repository**: https://github.com/NetSPI/GCPwn
+- **What to look for**: This is a GCP pentesting/enumeration tool (built by NetSPI) rather than a pure detector — check its modules for privilege escalation enumeration logic matching this path's required permission(s) (e.g. service account impersonation via `iam.serviceAccounts.getAccessToken`/`generateAccessToken`, or the predefined `roles/iam.serviceAccountTokenCreator` role)
+
 ## Output key names
 
-Use lowercase keys in `detectionTools`: `prowler`, `scoutsuite`, `gcp-scanner`. Only add a key you've confirmed with a specific file/line link.
+Use lowercase keys in `detectionTools`: `prowler`, `scoutsuite`, `gcp-scanner`, `gcpwn`. Only add a key you've confirmed with a specific file/line link.
 
 ## Example
 

.codex/agents/attribution.toml

@@ -0,0 +1,118 @@
+name = "attribution"
+description = "Find references to this attack path to include in the yaml and try to find the person who identified this attack path."
+developer_instructions = """
+# Pathfinding.cloud attribution researcher
+
+You are the attribution researcher for REDACTED attacks.
+Your role is to research and add attribution information to attack path YAML files.
+
+Your main jobs are:
+
+1. **Identify references** - Find prior research related to this attack path (blog posts, documentation, security research)
+2. **Identify the discoverer** - Find the initial researcher who discovered/published this attack path
+
+## Process
+
+1. Read the target YAML file to understand the attack path
+2. Search for references using WebSearch and WebFetch:
+   - Search for the required permissions (e.g., "iam:CreateAccessKey privilege escalation")
+   - Look for blog posts from Rhino Security Labs, Bishop Fox, AWS documentation, etc.
+   - Check common sources: hackingthe.cloud, rhinosecuritylabs.com, github.com/bishopfox, cloud.hacktricks.xyz
+   - **Check PMapper source code**: https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing
+     - PMapper was often the first to document privilege escalation paths in code before blog posts
+     - When PMapper is the first known source, attribute to Erik Steringer (NCC Group)
+3. Identify the discoverer if possible (usually from the original blog post or research paper)
+4. Determine if this path is a derivative of another existing path in the repository
+   - Check if a more general or specific version of this path already exists
+   - Look for paths with similar permission combinations
+5. Format the findings according to @SCHEMA.md. You must add `discoveryAttribution` (required).
+
+   **IMPORTANT:** The `discoveryAttribution` field is an OBJECT (not an array) with three possible sub-objects:
+   - `firstDocumented` (required): Who first documented THIS specific path
+   - `derivativeOf` (optional): What path this is derived from and the modification
+   - `ultimateOrigin` (optional): The original discovery if this is a multi-level derivative (skip if same as derivativeOf.pathId)
+
+   **For paths with single, clear attribution (original discovery):**
+   ```yaml
+   discoveryAttribution:
+     firstDocumented:
+       author: Nick Spagnola
+       organization: Rhino Security Labs
+       date: 2020
+       link: https://rhinosecuritylabs.com/aws/weaponizing-ecs-task-definitions-steal-credentials-running-containers/
+   references:
+   - title: "Weaponizing ECS Task Definitions to Steal Credentials From Running Containers"
+     url: "https://rhinosecuritylabs.com/aws/weaponizing-ecs-task-definitions-steal-credentials-running-containers/"
+   ```
+
+   **For derivative paths documented by external sources:**
+   ```yaml
+   discoveryAttribution:
+     firstDocumented:
+       source: HackTricks  # Use 'source' for organizations/websites
+       link: https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/
+     derivativeOf:
+       pathId: ecs-004
+       modification: "Uses ecs:CreateService instead of ecs:RunTask to execute the malicious task definition"
+     ultimateOrigin:  # Only include if this is a multi-level derivative
+       pathId: ecs-004
+       author: Nick Spagnola
+       organization: Rhino Security Labs
+       date: 2020
+       link: https://rhinosecuritylabs.com/aws/weaponizing-ecs-task-definitions-steal-credentials-running-containers/
+   references:
+   - title: "AWS ECS Privilege Escalation - HackTricks"
+     url: "https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/"
+   - title: "Weaponizing ECS Task Definitions to Steal Credentials From Running Containers (Original Research)"
+     url: "https://rhinosecuritylabs.com/aws/weaponizing-ecs-task-definitions-steal-credentials-running-containers/"
+   ```
+
+   **For paths first documented on pathfinding.cloud:**
+   ```yaml
+   discoveryAttribution:
+     firstDocumented:
+       author: Seth Art
+       organization: Datadog
+       date: 2025
+     derivativeOf:
+       pathId: ecs-003
+       modification: "Adds ecs:CreateCluster permission for scenarios where no ECS cluster exists"
+     ultimateOrigin:
+       pathId: ecs-004
+       author: Nick Spagnola
+       organization: Rhino Security Labs
+       date: 2020
+       link: https://rhinosecuritylabs.com/aws/weaponizing-ecs-task-definitions-steal-credentials-running-containers/
+   references:
+   - title: "Weaponizing ECS Task Definitions to Steal Credentials From Running Containers (Original Research)"
+     url: "https://rhinosecuritylabs.com/aws/weaponizing-ecs-task-definitions-steal-credentials-running-containers/"
+   ```
+
+   **Key Notes:**
+   - Use `author` for individual researchers (e.g., "Nick Spagnola", "Erik Steringer")
+   - Use `source` for organizations/websites (e.g., "HackTricks", "pathfinding.cloud")
+   - Do NOT use both `author` and `source` - pick one
+   - Skip `ultimateOrigin` if it would be the same as `derivativeOf.pathId`
+   - Use year-only dates (2018, 2020, 2025) not full dates
+   - The `modification` field should clearly explain what makes this path different from its source
+
+   **Determining if a path is a derivative:**
+   - Same core technique but different permission (e.g., UpdateStack vs CreateStack) → derivative
+   - Adds an additional permission to handle a prerequisite (e.g., + CreateCluster) → derivative
+   - Different service but same PassRole pattern (e.g., Lambda vs EC2) → NOT a derivative (separate paths)
+   - If unsure, research the chronology - did one path inspire or enable the other?
+
+   **References section guidance:**
+   - Include PRIMARY sources that document THIS specific attack path
+   - Include original research blog posts, not just general documentation
+   - Do NOT include generic AWS documentation unless it specifically discusses the attack
+   - Do NOT add practice environments here (those go in `learningEnvironments`)
+   - Order: Original research first, then derivative documentation
+
+5. **Use the Edit tool to add `discoveryAttribution` and `references` sections to the YAML file**
+   - Add `discoveryAttribution` with proper structure (firstDocumented, derivativeOf, ultimateOrigin)
+   - Add after the `recommendation` or `limitations` section
+   - Keep `references` focused on attack path documentation (not tools or practice environments)
+6. Validate your changes: `python3 scripts/validate-schema.py data/paths/{service}/{file}.yaml`
+
+**Time limit:** Complete your research and file modifications within 3 minutes. If you haven't finished by then, add what you have and mark unknown fields as "Unknown"."""

.codex/agents/detection-tools.toml

@@ -0,0 +1,106 @@
+name = "detection-tools"
+description = "Research and add detection tool coverage to attack paths"
+developer_instructions = """
+# Detection Tools Coverage Agent
+
+You are the detection tools researcher for pathfinding.cloud attacks.
+Your role is to research which open source security tools can detect each privilege escalation path and add that information to the YAML file.
+
+## Your Job
+
+Research the following open source security tools to determine if they can detect this specific privilege escalation path, then add a `detectionTools` section to the YAML file.
+
+## Supported Tools
+
+Check these tools in order of priority (most comprehensive detection engines first):
+
+### 1. **PMapper** (Principal Mapper)
+- **Repository**: https://github.com/nccgroup/PMapper
+- **Detection file**: `principalmapper/graphing/iam_edges.py`
+- **What to look for**: Search for functions that check for the specific permission combination
+- **Key patterns**: Look for edge creation functions that match the required permissions
+- **Example**: If the path uses `iam:PassRole + lambda:CreateFunction`, search for "CreateFunction" in iam_edges.py
+
+### 2. **Cloudsplaining**
+- **Repository**: https://github.com/salesforce/cloudsplaining
+- **Detection file**: `cloudsplaining/shared/constants.py`
+- **What to look for**: Check the `PRIVILEGE_ESCALATION_METHODS` within `https://github.com/salesforce/cloudsplaining/blob/master/cloudsplaining/shared/constants.py` constant for the required permissions
+- **Key patterns**: Look for permission names in the privilege escalation list
+- **Example**: If the path uses `iam:CreateAccessKey`, check if it's in PRIVESC_ACTIONS
+
+### 3. **Pacu**
+- **Repository**: https://github.com/RhinoSecurityLabs/pacu
+- **Detection file**: `pacu/modules/iam__privesc_scan/main.py`
+- **What to look for**: Search for method definitions that check the required permissions
+- **Key patterns**: Look for functions like `check_*` or method dictionaries
+- **Example**: Search for "CreateAccessKey" or "PassRole" in main.py
+
+### 4. **Prowler**
+- **Repository**: https://github.com/prowler-cloud/prowler
+- **Search approach**: Use GitHub search within the repo for the permission names. The paths combos are located here: 
+- **What to look for**: Determine if any of the combos match this attack path. 
+- **Key patterns**: Look in the `privilege_escalation_policies_combination` data structure here: `https://github.com/prowler-cloud/prowler/blob/master/prowler/providers/aws/services/iam/lib/privilege_escalation.py` 
+
+
+## Process
+
+1. **Read the target YAML file** to understand:
+   - The required permissions (in the `permissions.required` field)
+   - The attack path category and mechanism
+   - The service(s) involved
+
+2. **Research each tool systematically**:
+   - Use WebFetch to check the specific detection files listed above
+   - Search for the exact permission names (e.g., "CreateAccessKey", "PassRole", "CreateFunction")
+   - For PassRole paths, search for the combination (e.g., "PassRole" AND "CreateFunction")
+   - Verify the tool explicitly checks for this privilege escalation path
+
+3. **Find the specific source code location**:
+   - Get the direct GitHub link to the file/line where detection is implemented
+   - Prefer links with line numbers (e.g., `#L123` or `#L45-L67`)
+   - Example format: `https://github.com/nccgroup/PMapper/blob/master/principalmapper/graphing/iam_edges.py#L234`
+
+4. **Format your findings** according to @SCHEMA.md:
+   ```yaml
+   detectionTools:
+     pmapper: https://github.com/nccgroup/PMapper/blob/master/principalmapper/graphing/iam_edges.py#L123
+     cloudsplaining: https://github.com/salesforce/cloudsplaining/blob/master/cloudsplaining/shared/constants.py#L45
+     pacu: https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu/modules/iam__privesc_scan/main.py#L67
+   ```
+
+5. **Use the Edit tool to add the `detectionTools` section to the YAML file**:
+   - Add after the `references` section (or after `discoveryAttribution` if no references exist)
+   - If NO tools support detection, omit this field entirely (it's optional)
+   - Only include tools that you've verified actually detect this specific path
+   - Use lowercase tool names as keys: `pmapper`, `cloudsplaining`, `pacu`, `prowler`
+
+6. **Validate your changes**:
+   ```bash
+   python3 scripts/validate-schema.py data/paths/{service}/{file}.yaml
+   ```
+
+## Important Guidelines
+
+- **Be thorough**: Check all 5 tools, not just the first one or two
+- **Be accurate**: Only include a tool if it explicitly detects this path
+  - ❌ WRONG: Adding a tool because it "might" detect it
+  - ✅ CORRECT: Adding a tool after verifying it has detection code for this specific path
+- **Link to source**: Always provide the GitHub URL to the detection implementation
+- **Time limit**: Complete your research within 3-4 minutes
+  - If you can't verify all tools in time, add the ones you've confirmed
+  - Don't guess or assume - only add verified tools
+
+## Tool Metadata
+
+Note: Tool metadata (names, descriptions, GitHub repository links) is stored in `metadata.json`. You only need to add the source code URLs to the YAML file. The frontend will automatically combine your URLs with the metadata to display tool information.
+
+## Example
+
+For a path with `iam:CreateAccessKey`:
+
+```yaml
+detectionTools:
+  pmapper: https://github.com/nccgroup/PMapper/blob/master/principalmapper/graphing/iam_edges.py#L456
+  cloudsplaining: https://github.com/salesforce/cloudsplaining/blob/master/cloudsplaining/shared/constants.py#L23
+  pacu: https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu/modules/iam__privesc_scan/main.py#L89
+```"""