Analysis And Reporting

Analysis & Reporting

Sub-skill of offensive-osint. Load osint-methodology for pipeline and triage context. Authorized targets only.

BEHAVIORAL CONTRACT

When triggered: Endpoint scoring, finding severity classification, attack-path hint generation, mobile app ownership assessment, vulnerability prioritization, sector-specific recon analysis, AI-assisted OSINT analysis, evidence preservation, or tooling/automation setup is needed.

Execute:

1. For every classified API endpoint, compute the endpoint interest score (§1). If score >= 70, attach an attack-path hint from §3 templates.
2. For mobile apps, compute ownership confidence (§2). Accept if >= 70; below threshold = mobile_review_pending.
3. For every finding, classify severity using the decision matrix (§4). Apply sector severity overrides (§5) when target is in a regulated sector.
4. For HIGH/CRITICAL findings, emit the matching attack-path hint from §3 templates.
5. Write sidecar JSON files (§6) for cross-module coordination when this module produces outputs that feed other modules.
6. Evidence handling: preserve all artifacts per §8 — URL + UTC timestamp + SHA-256 + operator ID for all downloads; store on encrypted volume.
7. For bulk JS/response analysis, apply AI-assisted OSINT patterns (§7) using local models for sensitive content.
8. For tooling setup and automation pipelines, follow §9 patterns and reference docs/reference/tool-directory.md.

Output: Scored findings with severity, attack-path hints, and sidecar JSON where applicable. All findings use osint-methodology §3 schema.

Severity rules: §1 thresholds for endpoint scores (>=90 CRITICAL, 70-89 HIGH, 50-69 MEDIUM, 25-49 LOW, <25 INFO). §4 decision matrix (92 examples). §5 sector overrides are mandatory -- never downgrade a sector-specific severity.

Gating rules: Mobile apps below ownership threshold 70 = mobile_review_pending, do not deep-analyze. ICS/SCADA targets require explicit OT team coordination before any active probing.

Chain to: Feed severity + attack-path hints to osint-methodology §14 for client deliverable generation. Receive findings from all other sub-skills for classification.

1. Endpoint Interest Score — 0–100 Rubric

For every classified API endpoint, apply this rubric:

Thresholds:

For score ≥ 70, attach an attack_path_hint in evidence (see §3).

2. Mobile App Ownership Confidence — 0–100 Rubric

Before deep APK static analysis, score whether the app belongs to the target. Threshold: ≥70 = accept.

Apps below threshold: tag mobile_review_pending. Operator can lower threshold with --mobile-ownership-threshold 50.

3. Attack-Path Hint Patterns — 35 Templates

When emitting a HIGH/CRITICAL finding (score >= 70), include a one-sentence attack_path_hint:

4. Severity Decision Matrix — Worked Examples (selected)

5. Sector Severity Overrides

Full sector context and vendor details: docs/reference/specialty-domains.md

6. Cross-Module Sidecar Coordination

Each module writes a sidecar JSON when it finishes:

• <scan>/mobile_endpoints.json — endpoints + hostnames from APK static analysis.
• <scan>/secrets_sidecar.json — hostnames + endpoints + Firebase project IDs.
• <scan>/sso_tenants.json — discovered IdP tenants for breach correlation.

Downstream modules check for sidecars on start; if present, ingest.

Sidecar shape:

{
  "endpoints": [
    {
      "method": "GET",
      "url": "https://api.acme.com/v1/users",
      "source": "apk:com.acme.android"
    }
  ],
  "hostnames": ["api.acme.com"],
  "firebase_project_ids": ["acme-prod-12345"]
}

7. AI-Assisted OSINT Patterns

LLMs accelerate offline analysis of large, unstructured recon artifacts. All analysis below happens on already-collected data — no network interaction, zero detectability.

JS bundle summarization. Feed minified/webpack bundles to an LLM and ask it to extract API endpoints, internal hostnames, hardcoded tokens, and Firebase project IDs. This replaces hours of manual grep with a single structured pass.

Prompt template for bulk analysis:

Analyze this JS bundle and extract:
1. API endpoints (full URL or path pattern)
2. Internal hostnames and IP addresses
3. Hardcoded tokens, API keys, or secrets
4. Firebase project IDs or GCP resource identifiers
5. WebSocket URLs
6. Third-party service integrations (Stripe, Twilio, Sentry, etc.)

Output as JSON with keys: endpoints, hostnames, secrets, firebase_ids, websockets, third_party.

LLM-assisted pattern matching. Feed HTTP response bodies to identify non-standard API patterns that regex misses — custom RPC formats, protobuf-over-HTTP, GraphQL aliases, envelope patterns wrapping REST, and vendor-specific error schemas that leak framework internals.

Sensitive-content caveat. Never paste target PII, credentials, session tokens, or customer data into cloud-hosted LLMs (ChatGPT, Claude API, etc.). For engagement artifacts containing sensitive content, use local models (ollama, llama.cpp, vLLM) running on the operator's machine. This is a hard rule, not a preference.

Detectability: NONE. All analysis is offline against already-downloaded artifacts.

8. Evidence Preservation & Archiving

Every artifact collected during an engagement must be preserved with integrity metadata. This is non-negotiable for client deliverables and legal defensibility.

URL archiving. Before analyzing a page, archive it:

• archive.org: curl -s -d "url=<https://target.com/page"> <https://web.archive.org/save> — returns archived URL.
• archive.today: Submit via their form endpoint as a backup when archive.org is slow or blocked.
• Local mirror: wget --mirror --convert-links --adjust-extension --page-requisites --no-parent -P ./evidence/ <https://target.com/path> for a full offline copy.
• Other archivers: URLScan.io (scan + resource map), ArchiveBox (self-hosted HTML/PDF/screenshots), SingleFileZ (offline single-file HTML), Wayback SavePageNow API v3 (on-demand, returns job IDs), Hunchly (investigator capture, paid), Kasm Workspaces (containerized browser isolation).

Screenshot evidence. Capture visual state of findings:

• gowitness scan single --url <https://target.com/admin> --screenshot-path ./evidence/screenshots/
• playwright screenshot --url <https://target.com/admin> --output ./evidence/screenshots/admin.png
• EyeWitness for bulk URL screenshot runs from a target list.

Hashing discipline. SHA-256 every downloaded artifact immediately upon collection:

sha256sum ./evidence/artifact.html >> ./evidence/checksums.sha256

Never modify an artifact after hashing. If transformation is needed (e.g., deobfuscation), work on a copy and hash both the original and the copy.

Chain of custody. Every artifact record must include:

• UTC timestamp (ISO 8601): 2026-05-29T14:32:00Z
• Source URL or retrieval command
• SHA-256 hash of the file as retrieved
• Operator ID (engagement handle, not personal name)

Storage. All engagement data lives on an encrypted volume:

• Linux: LUKS-encrypted partition or loopback device.
• Cross-platform: VeraCrypt container.
• Air-gapped storage for sensitive engagements (government, healthcare, finance).

Retention. Follow the client contract retention clause. Default: 90 days post-delivery. Cryptographic destruction (wipe + key deletion) on engagement close. Document the destruction date and method.

9. Automation & Tooling Quick-Install

Full tool catalog, version pins, and installation details: docs/reference/tool-directory.md. This section covers integration patterns only.

One-liner install patterns for the most common tool ecosystems:

• Go tools: go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
• Python tools: pip install trufflehog semgrep (use the shared venv)
• Cargo tools: cargo install rustscan
• System packages: sudo apt install nmap masscan jq or brew install nmap masscan jq

Workflow automation. Chain tools with bash pipelines and jq for structured output:

subfinder -d target.com -silent | httpx -silent -json | jq -r '.url' | nuclei -silent -json | jq '.'

Structured output preference. Always use -json or -o json flags when available. Structured output enables programmatic severity classification (§4), sidecar generation (§6), and evidence hashing (§8) without fragile text parsing.

Sidecar integration. Automation pipelines should write their outputs in sidecar-compatible JSON (§6 shape) so downstream modules can ingest results automatically.

Structured Outrider run contract

Follow the shared run-contract instructions in ../_shared/run-contract.md.

• Contract skill identifier: analysis-and-reporting.
• Consume skill_request version 1 and produce skill_result version 1 when participating in an Outrider run.
• Use evidence IDs for all claims; do not cite unregistered local paths as claim evidence.
• Discoveries are observations and do not expand scope or approval.
• Do not claim final finding validation; use finding_candidate only when a human-reviewed candidate should be handed off.
• Do not directly edit manifest.json, scope.yaml, run.jsonl, evidence.jsonl, or approvals.jsonl.
• Use policy-gated MCP with the explicit run_dir; the Python control layer and MCP boundary must reevaluate current controls.

Finding promotion boundary

Analysis may classify evidence-backed claims as finding_candidate and may recommend a severity, but it must not finalize severity, create validated_finding, or self-promote a claim. Human promotion occurs only through outrider finding promote after the Python control layer verifies the source contract, registered evidence, current scope, and workflow state.