Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
The user is asking for active exploitation, post-exploitation, lateral movement, AD privilege escalation, malware development, or anything beyond reconnaissance — those are out of scope.
The user is asking for blue-team / defensive content (SIEM rules, detection engineering) — different domain.
The target's authorization is unclear and the user is asking you to act against a third-party asset they don't own — see §1 below; gently surface the scope question before proceeding.
1. Authorization & Legal Posture
This skill is intended for assets the operator owns or has written authorization to assess (red-team rules of engagement, bug-bounty in-scope assets, ASM contracts).
Soft scope check: when a user asks you to act against a target whose authorization isn't established earlier in the conversation, ask once before proceeding:
"Quick scope check: is this a target you own or have written authorization to assess (e.g., a red-team engagement, in-scope bug-bounty asset, or your own infrastructure)? I want to make sure we stay on the right side of the engagement boundary."
Once authorization is asserted, proceed without re-asking. If the user explicitly states the engagement type (e.g., "this is for our pentest of acme.com under contract"), you don't need to ask again.
Always-on guardrails (regardless of authorization):
Never weaken auth, rate limits, banners, or any safety control that enforces scope on the target side.
Never run destructive probes (true SYN scans on production, masscan at line rate, fuzzing/brute-force) outside an explicit DEEP / --aggressive mode.
Never paste real PII, valid credentials, session tokens, API keys, or other secrets into cloud-hosted LLMs or third-party services.
Diese SKILL.md ist sehr gross, daher zeigt SkillsMP hier nur den ersten Abschnitt.Auf GitHub ansehen
Never take action against assets outside the documented scope, even if "obviously related" (subsidiaries, vendors, employees' personal accounts, etc.).
2. Confidence Levels
Every assertion you make during an engagement should carry a confidence level. Three levels:
Level
Meaning
Examples
TENTATIVE
Plausible based on indirect evidence; unverified.
Snippet-only Google dork match; email pattern inferred from name; subdomain returned by one passive source only; favicon-hash overlap (two hosts share a favicon — could be shared infra, could be a coincidence).
FIRM
Directly observed but uncorroborated.
Subdomain that resolves to an IP; HEAD-confirmed bucket exists (private); CT-log entry shows certificate; Shodan banner returned.
CONFIRMED
Multiple independent corroborations OR directly verified.
Live-validated PMAK token (read-only /me returned 200); breach corpus + crt.sh + DNS all agree; bucket listable AND files retrievable; user enumerated AND password reset flow returns valid hint.
Rule of three for attribution: require three independent weak signals, OR one strong + one weak, before asserting linkage. Don't single-source attribute.
2.1 Confidence Upgrade Workflows
Confidence isn't static — every TENTATIVE asset should have a documented path to FIRM and to CONFIRMED. Use these per-asset-type rules.
Asset type
TENTATIVE → FIRM
FIRM → CONFIRMED
Subdomain
Returned by ≥2 independent passive sources, OR DNS A/AAAA/CNAME resolves successfully.
Serves on a standard port (80/443/22/etc.) AND HTTP banner / TLS cert / SSH banner returned.
IP
Discovered via ≥2 sources (passive DNS, ASN lookup, Shodan).
Active probe responds (TCP SYN-ACK on at least one port, or ICMP echo reply).
WebApp
URL extracted from JS / API / archive but not yet hit.
Generated from a name pattern OR returned by snippet-only dork.
Listed in Hunter.io / EmailRep / IntelX / breach corpus, OR MAIL FROM/RCPT TO SMTP probe returns 250 (without delivery — abort at DATA).
Bucket (S3/GCS/Azure)
Permutation candidate; no probe yet.
HEAD returns 200, 301, or 403 (existence confirmed). Then CONFIRMED when GET returns object listing or known object retrieval.
Endpoint (API / wayback)
Extracted from JS regex / Wayback / Postman.
HTTP request returns non-404 (route exists). Then CONFIRMED when the endpoint's behavior is fingerprinted (auth posture, response shape, rate limits).
Credential / secret
Matches catalog regex in captured text.
Read-only validator (/me, auth.test, sts:GetCallerIdentity, /user) returns success. Then CONFIRMED with documented scope + account ID.
Person
Name extracted from a single source (LinkedIn / breach / GitHub commit).
Confirmed by a second source (Hunter.io role + LinkedIn profile, or two breach sources with same email).
Repo
Name match on org keyword in GitHub search.
Repo metadata shows confirmed org/email/website match. Then CONFIRMED when commit-history shows employee involvement.
Mobile app
Name match in app store.
Ownership-confidence score ≥70 (see companion skill §21). Then CONFIRMED when binary metadata (signing cert, package name, dev account) ties back to target.
Certificate
Returned by crt.sh once.
CT-log entry confirmed in ≥2 logs. Then CONFIRMED when serving on a discovered host.
SSO tenant
Discovery-endpoint returns OIDC metadata.
Tenant GUID extracted AND domain resolves through the tenant's expected MX / autodiscover / SP record.
Default reporting posture: never claim CONFIRMED without explicit corroboration. When in doubt, downgrade. Operators trust under-claims more than over-claims.
3. Output Format Conventions
When you produce findings during an active session, structure each finding to match the schema below — it drops cleanly into asset-managementtools.
Finding:
id: <stable hash or UUID>
module: <which technique discovered it; "manual" if hand-found>
asset_key: <typed key, e.g. sub:api.example.com or webapp:https://example.com/admin>
category: <e.g. SECRET_LEAK, MISSING_HSTS, OPEN_GRAPHQL_API, LEAKED_CRED, SSO_EXPOSURE>
severity: <info|low|medium|high|critical>
confidence: <tentative|firm|confirmed>
title: <one-line summary>
description: <2-5 sentences>
evidence:
url: <where it was found>
timestamp: <UTC ISO8601>
sha256: <hash of any downloaded artifact>
raw: <truncated to 2 KiB>
references:
- <CVE-ID, advisory URL, vendor doc>
remediation: <action the asset owner can take>
Always use UTC timestamps. Local time creates correlation bugs across notes/screenshots/logs.
4. Source Hygiene & Citations
For every artifact you capture, record: URL + UTC timestamp + SHA-256 hash +command-line version + run_id.
Hash all downloaded files with SHA-256.
Screenshot in PNG (lossless, smaller than full-page WARC for evidence packs).
Capture raw HTTP requests/responses, capped at 2 KiB body to keep evidence packs small.
Use JSONL (NDJSON) logs, one line per event, with a run_id so the entire engagement is replayable.
Separate evidence read-only from working copies; never edit captured artifacts.
When citing a source in your output, prefer durable references (CVE, vendor advisory, ATT&CK technique ID, RFC) over ephemeral ones (a Twitter post, a forum thread). If the only source is ephemeral, archive it (archive.today, Wayback SavePageNow) before citing.
5. Do NOT (hard rules)
DO NOT paste creds, session tokens, API keys, real PII, infostealer logs, or unique pivots into cloud LLMs (ChatGPT, Claude.ai, Gemini, Perplexity). Use local models (Ollama, LM Studio, GPT4All) for sensitive analysis.
DO NOT assume vendor labels are ground truth. Cross-label sanity: TRM, Chainalysis, Arkham can disagree. Treat every label as a hypothesis.
DO NOT assume 1:1 bridge flows. Bridges/mixers/wrappers introduce mint/burn semantics; validate with on-chain proofs.
DO NOT assert ownership from a single signal. Favicon-hash overlap, shared CT issuer, shared NS — each is a hypothesis. Need rule-of-three.
DO NOT run fuzzing, SYN scans, masscan, or nuclei fuzzing/* templates outside an explicit DEEP / --aggressive mode.
DO NOT use a credential validator to do anything except read-only verification (no create/delete/send).
DO NOT mirror-image (assume the target thinks like you do). Separate capability from intent and sponsorship.
DO NOT confuse correlation with control.
DO NOT escalate when you encounter active defenses; back off and document (see §6.4).
6. OpSec
6.1 Sock Puppets
A sock puppet is a fake account that cannot be linked to you. Build a posting history, age the account, use it from a separate browser profile.
Disposable phone numbers: Burner, Silent Link (some platforms reject VoIP — keep a backlog of numbers).
Hardware passkeys for any high-value persona; store recovery codes offline.
Audit every browser extension before installation. Supply-chain attacks on popular extensions have repeatedly targeted investigators — assume the popular ones are at higher risk, not lower.
Maintain chain-of-custody: timestamp every action, hash every key artifact, recordcommand-line versions per case.
Personas should look like real low-engagement accounts: profile photo (synthetic), bio, a few low-effort posts spread across weeks before the persona is "used."
Every probe leaves a footprint. Tag every operation in your notes with a detectability level so you can reason about the SIEM trail you're leaving on the target's side.
Tag
Examples
Low
Passive Shodan InternetDB; CT-log queries (crt.sh); Wayback CDX; passive DNS (SecurityTrails); Hunter.io email enrichment; HTTP HEAD on public buckets; getuserrealm.srf; Microsoft OIDC metadata fetch.
Medium
Microsoft GetCredentialType user-enum; Okta /api/v1/authn user-enum; Postman API key validation; AWS sts:GetCallerIdentity (logs to CloudTrail); Slack auth.test; full-page screenshots; Swagger/GraphQL probes against a 28/13-path wordlist; targeted favicon-hash + JARM fingerprinting.
High
Active port scans (naabu / masscan / nmap); Nuclei full template runs against production; subdomain brute-force at scale; APK download from third-party mirrors; deep-mode user enumeration past N attempts per tenant; SMTP RCPT TO enumeration; web fuzzing (ffuf/gobuster).
When working with a client, document the operations actually run and their detectability tag in the engagement report — clients appreciate knowing what their detection stack should have caught.
Defaults: passive by default. Active probes only when (a) explicitly authorized, (b) within agreed maintenance windows, and (c) with the operator's awareness of the resulting log volume.
6.3 Validator Discipline
When you discover a credential in the wild (a leaked API key, a sourcemap-exposed token, a hard-coded PMAK in a public Postman workspace), you may want to confirm it's live. Do this with read-only validators only.
Discipline:
Read-only endpoint only (e.g., /me, /whoami, auth.test, sts:GetCallerIdentity).
Never use the validated credential to create, modify, delete, or send anything.
Tag the validation attempt with detectability — every validator generates an audit-log entry on the provider side.
Record checked_at (UTC), the response (truncated), and the scope/account-ID returned.
If the operator's rules of engagement forbid validation, mark the credential validation_skipped_by_policy and stop.
Concrete validator endpoints (Postman, AWS, GitHub, Slack, Anthropic, OpenAI, npm, Atlassian, DataDog) live in the companion offensive-osint skill.
6.4 Detection-Aware Probing (signs of detection + back-off)
Your probes will eventually hit detection. Recognize the signs and back off before you trip an active response.
Signs you've been detected (in roughly increasing severity):
Rate-limit responses — 429 Too Many Requests, Retry-After header set, X-RateLimit-Remaining: 0.
Status code drift — endpoints that previously returned 200/401 now return 403 only from your IP.
Banner change — server header shape or response timing changes consistently.
DNS poisoning back to NXDOMAIN — target's authoritative servers stop resolving subdomains (probably their CDN took over).
Honeypot bait — endpoints that look too good (/admin/db_dump.sql, exposed .env with credentials that don't validate). Real exposures rarely look this clean.
Direct contact — your sock-puppet email gets a "we noticed unusual activity" message; or, in extreme cases, your IP gets a courtesy abuse-contact email.
Back-off ladder:
Slow down. Halve your concurrency. Add 2–10s jitter between requests.
Switch endpoints. Stop hitting the path that triggered. Move to a different module of the recon pipeline.
Switch persona. New User-Agent (rotate among realistic browsers), new TLS fingerprint (different httpx/curl version).
Switch IP. Rotate to a new egress (residential proxy, Tor for sensitive lookups, a different cloud region).
Pause. Wait 1–24 hours. Many WAFs have rolling-window IP-based reputation; passive time often resets it.
Document and consult. If you've hit (3) WAF, (4) status drift, or (8) direct contact, stop active probing and consult the engagement lead. Continued probing past these signals risks scope violation.
Persona / IP rotation rules:
Never rotate persona to one that's been used in a prior engagement against the same target.
Use residential proxies (Bright Data, Smartproxy, IPRoyal) for high-detectability work — but be aware they're sometimes IP-blocklisted by Cloudflare.
Tor exit nodes are useful for passive lookups (CT logs, archive sites) but are blocked by most active-probe targets.
Cloud egress IPs (AWS / GCP / Azure) are often blocklisted aggressively for recon. Use sparingly.
Document every rotation with timestamp + reason; reviewers will ask.
Don't:
Don't try to "outsmart" a confirmed WAF block by sending more aggressive payloads. That's how clients get extra logs and how you get caught.
Don't switch source IPs to evade an explicit block-list — that crosses into evasion territory and may breach the rules of engagement.
Don't ignore signals because the dashboard says "still up." The probe is being silently logged; the response will come later.
7. External Red-Team Recon Pipeline
A 5-stage pipeline for any authorized external assessment. Stages are sequential; modules within a stage can run concurrently.
Stage 1 — Seed Discovery
Establish the ground truth of who/what the target is.
WHOIS on the seed domain (registrant, dates, name servers).
ASN enumeration: which AS does the org own/use? (Hurricane Electric BGP Toolkit, RIPEstat, BGPView.)
DNS records (A/AAAA/MX/TXT/NS/SOA/CAA) — records-only, no walking yet.
Certificate Transparency history for the root domain (crt.sh, Censys).
Stage 2 — Asset Expansion
Discover everything that might belong to the target.
Subdomain enumeration (passive sources first: crt.sh, VirusTotal, AlienVault OTX, Shodan, then permutations and bruteforce).
Cloud bucket enumeration (S3/GCS/Azure permutations from company name + subdomain stems — see §15).
Typosquat domain generation (dnstwist variants → resolve → WHOIS) — for both phishing risk and adjacent corp assets.
Wayback CDX archive endpoints for forgotten paths.
Mobile app discovery (Android via google-play-scraper, iOS via iTunes Search API — see §14).
DNS deep walking (NSEC walk on misconfigured zones, AXFR opportunism).
Reproduction package (run_id,command-line versions, raw evidence, JSONL log).
Bug bounty submission (if applicable — see §30).
7.5 Pipeline Priority Order (highest signal density first)
When budget is constrained, work in this order:
Breaches — infostealer logs (HudsonRock Cavalier free tier) + HIBP + DeHashed. Highest ROI for red teams; often gives valid plaintext creds for corp SSO. Requires emails as input.
1-day standard recon — full Stages 1–4 with the priority order above. Output: per-asset finding list + asset graph + exec summary.
1-week deep recon — all of standard, plus: deep-mode user enumeration, JS deep analysis at full budget, mobile attack surface, cloud-native fingerprinting, vendor product fingerprinting, package registry leak hunting, vulnerability prioritization. Output: full client deliverable package + reproduction bundle.
Ongoing monitoring (weekly diff) — re-run Stages 1–3 weekly; diff against baseline; alert on new asset / new finding / asset disappeared.
When to abort early:
After Stage 1 if scope is wrong (target turns out to be subsidiary of unrelated corp; rules of engagement need clarification).
After Stage 2 if attack surface is below threshold (no public webapps + no exposed services + no leaked emails → little to find externally).
During any stage if you hit the WAF / detection signs in §6.4.
8. Asset Graph Discipline
Treat every discovery as a typed asset in a graph, not a free-floating string.
Every discovery is an asset. Don't write findings against free-floating strings; create the asset first, then attach the finding.
Dedup by key, not by value. Same value, different type ≠ same asset (sub:api.example.com and webapp:https://api.example.com/ are different assets with a BELONGS_TO_HOST edge).
Provenance is non-negotiable.sources[] must list every source. If two sources confirmed it, both go in.
Confidence is per-source, then aggregated. A subdomain returned by 3 passive sources is FIRM; one returned by snippet-only Bing is TENTATIVE.
Late binding via sidecars. When module A produces output that module B needs, write a JSON sidecar (mobile_endpoints.json, secrets_sidecar.json) — don't block module B on module A. See §24.
8.5 Asset-Level Triage Rules
When you have a mixed bag of assets and limited probe budget, prioritize by what each asset enables:
WebApp priority by hostname signal (highest first):
Often unmonitored or alias forwarded; less personal context.
Repo priority by recency + naming:
Recently-pushed (last 30 days) > stale.
Public repo with target name in description > target name only in code.
Forked from internal-looking parent > standalone.
Mentions prod, internal, private, secret in name → priority HIGH despite being public (may be misnamed or accidentally exposed).
Application order: when you have N assets and budget for M probes (M < N), apply asset-type priority first, then within-type priority. E.g.: 50 subdomains → probe API + admin + dev first (~15), then auth + prod-app (~20), defer marketing/content to a later pass.
9. Findings Rubric & Severity Mapping
Severity is operational, not subjective. Use these anchors:
9.1 CRITICAL
Pre-auth code execution, confirmed valid credentials, listable production data, fundamental trust violations.
Examples:
.git/config exposed on production webapp (full source-code disclosure).
/.env exposed (credentials in plaintext, often DB / cloud / API).
Spring Boot /actuator/env or /actuator/heapdump reachable unauthenticated.
Listable S3 / GCS / Azure bucket containing user data.
Unauthenticated POST/PUT/DELETE to a write endpoint that mutates state.
Open Firebase Realtime Database (https://{project}.firebaseio.com/.json returns data).
android:debuggable=true in a production Android app.
Live-validated credential (PMAK, AWS key, Anthropic/OpenAI key) with broad scope.
≥10 employees compromised in a breach corpus + their tenant identified (SSO_EXPOSURE).
Open Elasticsearch cluster (/_cat/indices returns data).
Open Docker API (/v1.40/containers/json returns containers).
Open Redis (no AUTH; can write authorized_keys).
Open Kubernetes API server with anonymous-auth enabled.
Existing investigative work (threat-actor research, doxxing investigations, attribution) operates under different posture than offensive recon. Switch posture explicitly.
Aspect
Investigative Mode
Offensive Recon Mode
Probing rate
Slow, single-threaded, blend with normal traffic.
Bursts, parallel, but rate-limited per provider.
OpSec posture
Sock-puppet only, never reveal investigator.
Persona may be the engagement persona; team may notify SOC.
Evidence handling
Court-grade chain of custody; hashes, timestamps, screenshots.
Engagement-grade; same hashing/timestamp discipline but evidence is for the client report.
Severity in scope
All severity levels relevant for context.
CRIT/HIGH/MED matter; LOW/INFO often dropped from exec summary.
Authorization posture
Public-record / OSINT-only; no probing private resources without authorization.
Written rules of engagement; explicit scope; explicit out-of-scope list.
Tactics: breadth-first; rely on automation for asset discovery; manual triage on findings.
Very large org (10K+) or conglomerate:
Brand-pivot maps before anything else: enumerate every brand domain, every subsidiary.
Breach corpus dominates: 10K+ employees mean significant past-breach exposure.
Identity fabric may differ per business unit (legal entity boundaries).
Tactics: scope pruning is the most important step; sampling + automation throughout; deep dive only on high-priority findings.
Cross-scale principle: the smaller the org, the more individual-account focus pays off. The larger the org, the more systemic posture findings (DMARC gaps, SSO_EXPOSURE breadth, vendor-product version sweeps) pay off.
11. Identity Fabric Mapping
An organization's IdP/SSO posture is a high-value target: compromise the identity fabric and you don't need to break into individual apps. Map it methodically.
11.1 Subdomain prefix enumeration
Probe these prefixes against the target's root domain (and any sibling brand domains discovered):
Autodiscover v2 — https://autodiscover-s.outlook.com/autodiscover/metadata/json/1 POST with email; detects tenant membership.
GetCredentialType (deep-mode user-enum) — https://login.microsoftonline.com/common/GetCredentialType POST {"username": "<email>"}. Response indicates whether email exists in tenant. Detectability: medium. Cap attempts at 20 per tenant.
11.3 Okta
Org slug derivation — derive candidate slugs from subdomains + root domain stem; Okta tenants live at <slug>.okta.com (or <slug>.oktapreview.com).
/api/v1/authn user-enum (deep-mode) — POST {"username": "<email>", "password": "invalid"}. 400 vs 401 response code indicates user existence. Detectability: medium. Cap at 20 per tenant.
11.4 ADFS
Passive fingerprint — GET https://{domain}/adfs/idpinitiatedsignon.aspx → 200 indicates ADFS present.
Active mex endpoint (deep-mode) — https://{domain}/adfs/Services/Trust/mex returns SOAP metadata.
SAML metadata XML contains: EntityID, signing certs, SingleSignOnService URL, NameIDFormat.
11.8 AWS account-ID extraction
S3 bucket region header — HEAD on a known target bucket returns x-amz-bucket-region; correlate with bucket-name entropy to infer account.
ARN regex in JSON / HTML responses — search for arn:aws:[a-z0-9-]+:[a-z0-9-]*:([0-9]{12}): (the 12-digit AWS account ID is the capture group).
AccountId property in JS / API responses — common in IAM-related error messages and CloudFormation outputs.
OAuth client_id leaks — Google OAuth: <digits>-<chars>.apps.googleusercontent.com; MSAL: GUID in clientId property.
11.9 Output
Each discovered IdP becomes a Service asset with attrs.product, attrs.tenant_id, attrs.discovery_endpoint. Then in Stage 4, correlate with breach data: every compromised user under a discovered tenant becomes an SSO_EXPOSURE finding (CRITICAL — see §22.3).
11.10 Microsoft 365 Deep Surface
Beyond plain Entra fingerprinting, M365 exposes a wider attack surface that's worth enumerating in depth.
Teams federation status: https://teams.microsoft.com/api/mt/<region>/beta/users/<email>/externalsearchv3 (requires authenticated request from a federated tenant; useful for confirming whether external Teams chat is allowed).
External chat enabled = soft-attack surface (vishing, smishing, "from-IT" pretexts via Teams chat).
Open Federation (any tenant can chat) is the default; check whether the target restricted it.
SharePoint subdomains:
<target-stem>.sharepoint.com — main tenant SharePoint.
<target-stem>-my.sharepoint.com — OneDrive-for-Business URLs (per-user personal sites).
<target-stem>-admin.sharepoint.com — SharePoint admin center (auth-required, but presence confirms tenancy).
Where <target-stem> is derived from the company name (often the part before .com).
The endpoint https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration lists supported endpoints; some tenants leave device_authorization_endpoint enabled (device-code phishing target).
Power Platform / Power Apps:
https://make.powerapps.com/environments (auth-required); environment IDs sometimes leak in URLs.
*.crm.dynamics.com (Dynamics 365 / Power Apps default URLs).
*.azurewebsites.net for App Service deployments.
M365 OAuth misconfig findings to look for:
device_authorization_endpoint enabled on common tenant (device-code phishing target) → MEDIUM (operational risk; not directly exploitable but enables attack).
Custom OAuth app with Public client flow enabled and broad scopes (offline_access, Mail.Read, Files.Read.All) → HIGH if app is approved for the tenant.
Multi-tenant OAuth app published by the target (others can consent) → check whether scopes include sensitive Graph permissions.
Detectability: all M365 endpoint probes log to Entra sign-in logs / audit logs (medium-low for fetch-only; medium for any auth attempt).
12. API & Auth-Map Methodology
Modern targets expose REST, GraphQL, and undocumented internal APIs. The OSINT goal is to enumerate them, classify them, and rank by attack interest.
12.1 Discovery paths
Swagger / OpenAPI — probe a 28-path wordlist (companion skill §16.1) on every alive webapp. Parse YAML/JSON; extract every endpoint (method + path).
GraphQL — probe a 13-path wordlist (companion skill §16.2). POST a standard introspection query. If schema returns, you have full type/query/mutation/subscription enumeration.
GraphQL when introspection is disabled — fall back to field-suggestion enumeration (companion skill §22.9).
Postman — query Postman's public universal-search endpoint with the target name; walk each matching workspace; extract requests, headers, pre-request scripts, test scripts, env vars.
JS-extracted endpoints — every endpoint extracted from JavaScript bundles feeds into the same classifier.
Mobile-extracted endpoints — every endpoint from APK static analysis feeds in via sidecar (mobile_endpoints.json).
Send GET without auth → 200 = auth_required=false; 401/403 = auth_required=true.
Capture response headers for WWW-Authenticate (auth_type), RateLimit-* / X-RateLimit-*.
Send a request with Origin: https://attacker.example → response Access-Control-Allow-Origin reflected = cors_policy=reflected.
Trigger an error → check response for stack traces, ORM hints.
12.3 Interest score (0–100)
See companion skill §20 for the full rubric. Score ≥ 70 → HIGH/CRITICAL finding with attack_path_hint in evidence.
12.4 Attack-path hints
When emitting a HIGH/CRITICAL finding, include a one-sentence attack-path hint in the evidence so the operator knows where to start exploiting. Templates in companion skill §39.
13. JavaScript Deep Analysis
For every alive webapp, scrape its JS — it's where modern frontends leak.
13.1 Script discovery
Parse HTML for <script src="..."> and <link rel="modulepreload" href="...">.
Probe a guess-path list (companion skill §16.9) for common bundlers.
13.2 Sourcemap detection (HIGH info disclosure)
Inline reference: regex //[#@]\s*sourceMappingURL= at end of bundle.
Sibling fetch: try <bundle>.map next to every discovered JS.
If accessible: parse the sourcemap's sources[] (leaks repo structure) and sourcesContent[] (full original source code embedded). Run the secret catalog over sourcesContent[].
Severity: HIGH INFO_DISCLOSURE.
13.3 Secret scanning
Run the 29+-pattern catalog (companion skill §17) over every JS body and every parsed sourcesContent[] blob. Each hit = SECRET_LEAK finding with the catalog's per-pattern severity.
13.4 Endpoint extraction
Three regex tiers (companion skill §16.10). Each unique endpoint becomes a wayback_endpoint asset and feeds into the API classifier in §12.
13.5 Internal-host leakage detection
Three patterns (companion skill §16.11): RFC1918, internal DNS suffixes, K8s service DNS. Each match = MEDIUM INFO_DISCLOSURE.
13.6 GraphQL introspection probe
When an extracted endpoint ends in /graphql or /graphiql, POST the standard introspection query. If schema returns → HIGH MISCONFIG. Then enumerate mutations and subscriptions for high-value targets.
13.7 Next.js manifest parsing
_buildManifest.js and _ssgManifest.js enumerate every Next.js page route — exposes the application's full route structure.
13.8 Budget guidelines
Cap webapps analyzed per engagement: 40 default, 120 with --deep.
Cap JS files per webapp: 40 default, 80 with --deep.
Cap individual JS file size: 2 MiB.
Per-file timeout: 10 seconds.
14. Mobile Attack Surface
Mobile apps are often the weakest link.
14.1 App discovery
Android — google-play-scraper. Search by company name, brand keywords, root domain stem.
iOS — iTunes Search API.
14.2 Ownership confidence (0–100)
See companion skill §21. Threshold: ≥70 for deep analysis.
Bluesky AT Protocol — DID resolution via bsky.social/xrpc/com.atproto.identity.resolveHandle; identity doc via plc.directory/<did>; firehose at Firesky; SkyView for graphs. Archive early — handle migration / post deletion.
Mastodon / Fediverse — instance matters (jurisdiction, logging); WebFinger for discovery; FediSearch cross-instance; instance enumeration via Fediverse Observer; ActivityPub objects are JSON-LD.
Threads — IG-API-similar limitations.
18.4 Auditory clues
Languages, dialects, background noises (train horns, prayer calls, wildlife). Tools: Audacity, Sonic Visualiser, SoundCMD. Spectrograms for unique patterns; Shazam/SoundHound for music.
18.5 Frame extraction
FFmpeg, VLC. Stitch panoramas; stabilize panning footage (FFmpeg deshake or Blender VSE). Prefer original uploads over re-encodes.
19. Chronolocation and Time Analysis
19.1 Shadow Analysis
Tools: SunCalc, ShadeMap, Bellingcat Shadow-Finder, NOAA Solar Calculator.
19.2 Astronomical Calculations
Stellarium, SkyMap, MoonCalc to simulate sky at different times/locations.
19.3 Satellite Imagery Time
Google Earth Pro (historical imagery slider), Sentinel Hub EO Browser (Sentinel + Landsat with timelapse). Record coordinates in WKT; hash cached tilesets.
20. Threat Actor Investigation
20.1 Actor-Centric Workflow
Scoping — actor hypothesis (APT28/29, Turla, Sandworm; APT10/41, Mustang Panda, Volt Typhoon). Seed reports from CERTs/vendors.
This is the highest-ROI single technique for external red teams. Execute it on every engagement.
22.1 Source stack
Source
Tier
Notes
Hudson Rock Cavalier
FREE
Infostealer-log corpus; very high signal for corp SSO.
Have I Been Pwned
Free + paid
Domain-wide existence + Pwned Passwords (k-anonymity).
DeHashed
Paid
Searchable per-record API.
IntelX
Free + paid
Aggregator; phonebook search.
Local breach corpus
Operator-supplied
Whatever's on disk.
22.2 Domain-level severity
Stat
Severity
≥10 employees compromised
CRITICAL
1–9 employees compromised
HIGH
≥1 end-user (non-employee) compromised
MEDIUM
Domain seen in breach with 0 named accounts
INFO
22.3 SSO_EXPOSURE correlation
After Stage 3 has run identity-fabric mapping AND breach lookups have completed: for every discovered IdP tenant, intersect with breach corpus on the tenant's domain. Non-empty intersection → SSO_EXPOSURE finding, severity CRITICAL. Evidence: tenant ID + product + employee count + per-account source attribution.
22.4 Operational handling of stealer logs
Treat as PII; encrypt at rest.
SHA-256 every artifact; record source URL + acquisition timestamp.
Never paste plaintext passwords into cloud LLMs.
Document chain of custody.
For client reports: redact passwords by default; offer the operator a separate encrypted credential bundle for raw data.
23. Infrastructure OSINT
23.1 IP & Domain Discovery
Shodan, Censys, Onyphe, DNSDB.
23.2 Certificate & Passive DNS
crt.sh, SecurityTrails.
23.3 Malware & Artifact Analysis Workflow
Static triage — SHA-256, strings, import tables, PDB path, Rich header. Don't rely solely on AV labels.
In ad-hoc engagement: tmpdir + JSON sidecars + one-line manifest makes operations composable.
24.3 Multi-Engine Corpus Run Methodology
Running a large dork corpus across multiple engines:
Pluggable engines — wrap each engine (DDG, Bing, Brave, SerpAPI, Yandex, Baidu) behind a common interface. Default DDG (keyless); fall back to others when keys available.
Per-engine rate-limiting — each engine has its own quota and ban posture. Use a token bucket per engine.
Asserting 1:1 bridge flows. Bridges mint and burn; aggregators rebalance.
Treating snippet-only Google dorks as confirmed. TENTATIVE until you visit.
Pasting real PII / creds into cloud LLMs. Local models for sensitive analysis.
Mirror-imaging the threat actor. They don't think like you.
Attribution by IP geolocation. IPs lie; VPNs and residential proxies exist.
Ignoring the 7-day optimistic-rollup challenge window. L2 finality is delayed.
Ignoring CT-log lag. New certs take minutes-to-hours to surface; absence ≠ doesn't exist.
Counting Wayback snapshots as "the site at time T." Best-effort; many requests fail.
Trusting whoami from a discovered API. Could be a honeypot.
Letting the asset graph carry untyped strings. Every discovery is an asset.
Skipping the scope check. Ask once when in doubt.
Forgetting UTC. Local time creates correlation bugs.
Continuing to probe after a WAF block. See §6.4 — back off.
Skipping confidence-upgrade documentation. TENTATIVE assets need a path to CONFIRMED.
Treating exec-summary writing as an afterthought. See §31 — plan deliverables at engagement start, not at the end.
27. WAF / CDN Bypass & Origin Discovery
Web targets are increasingly behind Cloudflare / Akamai / Fastly / AWS CloudFront. The CDN itself is hard to attack; the origin server is often softly defended. Six techniques to find it.
27.1 DNS history pivot
The target's domain may have pointed directly at the origin IP before the CDN was deployed. Query historical passive DNS:
SecurityTrails — https://api.securitytrails.com/v1/history/<domain>/dns/a (paid; the most complete).
RiskIQ PassiveTotal — passive DNS lookups; freemium.
DNSDB (Farsight) — paid; long history.
Validin.com — newer, has free tier.
Censys host search — historical IP-cert mapping.
What to look for: an IP that resolved 1–5 years ago and is not in the current CDN's published IP ranges (Cloudflare / Akamai / etc.). Cross-check the IP's current banner — if it serves the same site without the CDN, you've got the origin.
27.2 Certificate SAN pivot
Certificates often get re-issued with the same SAN list across origin and CDN. Search CT logs:
crt.sh ?q=%.<target.com>&exclude=expired — find certs with the target's domain in SAN.
Cross-reference issued certs against current CDN-fronted cert. The "extra" cert (not the CDN one) often points to origin via its CN/SAN.
Tools like cero (go install github.com/glebarez/cero@latest) crawl IPs and pull certs; correlate IPs whose certs include the target's hostname.
27.3 Favicon hash + JARM origin clustering
If the target has a unique favicon, the origin server still serves it (CDNs proxy but don't strip the favicon). Compute the favicon's mmh3 hash and search:
Returned IPs that are not in CDN ranges are origin candidates.
JARM (TLS handshake hash) works similarly: compute the target's JARM via jarm, search Shodan ssl.jarm:<jarm-hash>. Origin servers usually have a different JARM than CDNs.
27.4 Direct IP probe with Host header
If you have an origin candidate IP from steps 27.1–27.3:
If the response matches the public site (same title, same body fingerprint) — you've found the origin. CDN-only IPs return generic CDN error pages or 403 to wrong Host.
27.5 mail.* / ftp.* / cpanel.* exception
Targets often forget to put auxiliary subdomains behind the CDN:
mail.<target> — often points at the actual mail server, sometimes co-located with web origin.
ftp.<target>, sftp.<target> — likewise.
cpanel.<target>, whm.<target>, webmail.<target> — shared hosting controls; same IP as web origin.
Send an email to a non-existent address at the target. The bounce often reveals origin mail server IPs in the Received: headers — these mail servers are sometimes on the same IP / netblock as the web origin. (Use a sock-puppet email; never your real engagement persona.)
27.8 Confidence rules
Origin IP found via DNS history: TENTATIVE until corroborated by direct probe.
Origin IP corroborated by Host-header probe matching content: FIRM.
Origin IP corroborated by Host-header probe + cert SAN match + favicon match: CONFIRMED.
When unsure, document the hypothesis in the asset attrs — don't claim origin discovery without ≥2 corroborating signals.
Trickest CVE → POC mapping — community-maintained mapping of CVEs to public POCs.
28.2 Prioritization rubric
For each CVE in your list, score:
Signal
Weight
Listed in CISA KEV
+50 (proven exploited; treat as immediate)
EPSS score ≥ 0.7
+30
EPSS score 0.3–0.69
+15
Public Metasploit module exists
+25
Public POC on ExploitDB / GitHub
+15
Vendor-issued advisory + patch
+10 (means the vuln is real and patchable; not always exploitable)
Auth-required vs unauth-required
unauth +20, post-auth +0
Network-vector (network) vs adjacent / local
network +15, adjacent +5, local +0
CVSS v3 base ≥ 9.0
+15
Total score → priority tier:
Score
Tier
Action
≥ 100
P0
Immediate validation; surface in engagement summary now.
70–99
P1
Validate this engagement; include in technical report.
40–69
P2
Mention in technical report; validate if time permits.
< 40
P3
List in appendix; no validation expected.
28.3 Validation discipline
Validate = run a single read-only proof (e.g., a version banner check, a static-page fetch that confirms the vulnerable component) without triggering exploitation.
Do NOT run the actual exploit unless the rules of engagement explicitly permit. Many bug bounty programs forbid PoC execution against production.
For client engagements: deliver the prioritized list with reproduction commands but defer actual exploitation to a follow-on assessment if needed.
28.4 Handle CVE-less findings
Many real-world findings (sourcemap exposure, open GraphQL introspection, public bucket) don't have a CVE. Score them by their independent interest score (companion skill §20 for endpoints; §40 for severity-mapping examples). Don't gate on CVE availability.
29. Phishing Infrastructure & Pretext Development
Authorized red team engagements often include phishing. The OSINT side of phishing — building the phishing-feasibility shortlist and the pretext list — is in scope here. Crafting actual phishing payloads is out of scope (operational tradecraft, separate domain).
29.1 Phishing-feasibility shortlist
For an authorized engagement, the operator typically wants three lists:
A. Already-registered typosquats — these are findings (someone is squatting; client should know).
B. Available-for-registration typosquats — these are the operator's phishing-domain shortlist for the engagement.
C. Cert-SAN impersonation patterns — domains the operator could register that would make convincing certs (e.g., acme-secure.com, acme-login.com, acme-vpn-portal.com).
Generation pattern:
Run dnstwist (or equivalent) on the target's primary domain → get all variations (homoglyph, typosquatting, bit-flip, hyphenation, addition).
Check WHOIS for each: registered = list A, unregistered = list B.
For list C: combine target stem + plausible service words (secure, login, vpn, portal, mail, helpdesk, it, account, verify, support, password, auth, sso).
29.2 Subdomain takeover for trusted-domain phishing
If you found a takeover-able subdomain (companion skill §16.12), you can host phishing content on a subdomain of the actual target. This bypasses every brand-impersonation defense the user has.
Procedure:
Confirm takeover signature on the candidate (<sub>.target.com CNAMEd to unclaimed <x>.herokuapp.com).
Register the unclaimed resource (<x>.herokuapp.com on Heroku).
Now <sub>.target.com serves your content.
Stop and consult the engagement lead before going live with phishing content. Even in authorized engagements, the takeover step itself may need explicit client sign-off.
29.3 Email spoof feasibility
Use email security analysis (companion skill §16.14) to determine spoof feasibility:
SPF policy
DMARC policy
Spoof feasibility
~all (softfail) or absent
p=none or absent
HIGH — direct spoof of <anything>@<target> likely lands.
~all
p=quarantine
MEDIUM — lands in spam folder, but lands.
-all (hardfail)
p=quarantine
LOW — most providers reject; some still deliver to spam.
-all
p=reject
VERY LOW — spoof rejected by major providers. Requires lookalike domain.
If spoof is hard, fall back to lookalike (list B) or compromised-third-party (different engagement). Document the postural finding regardless.
29.4 Pretext development from OSINT
Pretexts work when they tap a target's existing context. Build pretexts from harvested OSINT.
Pretext sources:
Job titles + reporting structure (LinkedIn) — "Hi , this is 's assistant; can you look at this finance file?"
Recent corporate events (press releases, news, careers page) — "We're following up on the layoffs / new acquisition; please confirm your benefits info."
Vendor relationships (job postings mentioning "experience with Workday/Salesforce/etc.") — "Workday password reset required by EOD."
Public conferences / travel (LinkedIn posts, conference pages) — "Hi , we met at ; following up on what we discussed."
GitHub commits / open-source work — "I saw your fix in ; want to collaborate on a related PR?"
Office locations (LinkedIn) — "On-site IT for the office requires a quick auth check."
Per-role pretext templates (the ones operators use most):
End-users (general staff): IT helpdesk password reset, Workday HR action required, Microsoft 365 storage full, package delivery confirmation.
When you find an issue on a bug-bounty target (HackerOne, Bugcrowd, Intigriti, YesWeHack) or on a non-program target where you choose to disclose responsibly.
VRT (Vulnerability Rating Taxonomy) instead of CVSS for severity.
Intigriti
intigriti.com
EU-strong; flexible scope models.
YesWeHack
yeswehack.com
EU-headquartered; growing.
HackenProof
hackenproof.com
Crypto/blockchain-focused programs.
Open Bug Bounty
openbugbounty.org
Free for sites without official programs (only XSS/SSRF disclosure).
security.txt
rfc9116
Universal: every site should publish /.well-known/security.txt.
30.2 Report structure (works on any platform)
Title: [Severity] [Affected component] Brief description
Example: [HIGH] [api.acme.com] Unauthenticated SSRF via /v1/proxy
Summary
2-3 sentences explaining what was found and why it matters.
Steps to Reproduce
1. Numbered, copy-pasteable.
2. Include exact URLs, payloads, expected vs actual response.
3. Reproduce the issue from a fresh state where possible.
Proof of Concept
- Screenshot showing the vulnerability triggered.
- HTTP request/response (sanitize sensitive data; redact other users' data).
- Or short video/GIF for complex multi-step issues.
Impact
Quantify: what data is at risk, how many users, what business functions break.
Tie to the program's impact criteria where defined.
Severity (per program criteria)
- CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Score: 9.8 (Critical)
- Justification: <1-2 sentence reasoning>
Remediation
- Concrete recommendation. "Validate the URL parameter against an allowlist before fetching."
- If a quick fix: WAF rule, header check.
- If a structural fix: refactor recommendation.
Affected component
- URL: https://api.acme.com/v1/proxy
- Date discovered: 2026-04-27 14:23 UTC
- Method: HTTP GET / POST / etc.
30.3 Severity inference per program
HackerOne uses CVSS v3 with program-specific multipliers (some programs cap at HIGH; some pay 10x for CRITICAL).
Intigriti uses Exceptional / Critical / High / Medium / Low tiers.
For programs that pay flat rates per severity tier, don't inflate. Conservative severity → trust → repeat awards.
30.4 Disclosure for unprogrammed targets (CVD)
If the target has no bug bounty program but you found a real vulnerability during authorized testing (e.g., a customer's external assessment surfacing a third-party vendor's bug):
Check for <target>/.well-known/security.txt — if present, follow its Contact: and Encryption: (PGP) instructions.
If absent, try security@<target> then abuse@<target>.
If those bounce, escalate via the registered abuse contact in WHOIS.
CERT/CC (cert.org) and national CERTs (CISA, CERT-EU, JPCERT) for coordination if vendor unresponsive.
Standard 90-day disclosure window before public release (Project Zero norm).
30.5 Cloud provider / SaaS-specific channels
AWS abuse: aws-security@amazon.com. For exposed AWS keys: also notify the account owner if discoverable via WHOIS/contact.
GCP: google-cloud-trust@google.com.
Azure: Microsoft Security Response Center (MSRC) at https://msrc.microsoft.com/.
GitHub: secret-scanning auto-revokes most published secrets via GitHub's partner program; if you find one, the scanning is usually faster than manual disclosure but back-up notify GitHub at security@github.com.
npm / PyPI / Docker Hub: each has an abuse@ or security@ channel; npm specifically auto-revokes leaked tokens via their secret scanner.
30.6 Things to avoid in reports
Don't include anyone else's PII / passwords / data in the report (redact).
Don't post the report or PoC publicly until the disclosure window expires.
Don't escalate via social media first (always direct channel first).
Don't demand a specific bounty amount; let the program decide.
Don't submit the same finding to multiple programs (duplicates can hurt your reputation).
31. Client Deliverable Templates
Operator-facing artifacts (asset graph, JSONL log, finding DB) are not the same as client-facing artifacts (exec summary, technical report). Build deliverables intentionally.
