Authorised OSINT Toolkit

View saved version →

---
name: cloud-saas-exposure
description: "Assess attributable cloud storage, SaaS, package-registry and cloud-native exposure using passive or read-only methods. Use only for owned or explicitly authorised targets; exclude credential submission, exploitation and control-plane access."
---

# Cloud and SaaS Exposure

## Authorisation and safety

- Confirm the target is owned by the user or covered by written authorisation before sending target-directed traffic, executing bundled recon scripts, validating credentials, enumerating users, scanning ports or scheduling recurring checks. Record the exact in-scope domains, IP ranges, methods, rate limits and engagement window.
- Passive analysis of user-supplied data and public documentation may proceed without target interaction. Clearly label unverified attribution and do not convert discovered sibling assets into scan scope.
- Do not exploit vulnerabilities, bypass access controls, submit or replay credentials, perform password spraying, induce state changes, evade detection, send phishing messages, access non-public data or use destructive probes.
- Treat exposed secrets and personal data as sensitive. Minimise collection, redact reports, avoid unnecessary validation and follow the engagement's evidence-handling and disclosure rules.
- Stop when authorisation is absent or ambiguous, a technique would exceed scope, rate limiting or defensive blocking appears, or an action could materially affect a system. Ask for a narrower safe action.

## Workflow

1. Establish whether the request is passive analysis or involves target interaction. For interaction, capture the scope and authority required above before proceeding.
2. Read [references/source-playbook.md](references/source-playbook.md), searching within it for the topic relevant to the request. Load only the relevant sections into working context.
3. Prefer passive and keyless sources first. Separate observed facts, attribution inferences, hypotheses and proposed validation.
4. Use bundled scripts only when they directly support the authorised task. Inspect their prerequisites and resolved target/output paths before execution; do not install dependencies or run network operations implicitly.
5. Preserve source URLs, timestamps, commands, hashes and confidence so another analyst can reproduce the result. Redact secrets and unnecessary personal data from deliverables.
6. Report scope, method, evidence, confidence, limitations, findings and proportionate next actions. Never represent a candidate asset, guessed identity, exposure or exploitability as proven without supporting evidence.

## Source and licence

This adaptation preserves methodology from Sachin Sharma's `elementalsouls/Claude-OSINT`, pinned at commit `13d920413448c026b52ac74efee0f1eb39dd81ff`. See the package-level `ATTRIBUTION.md`, `LICENSE`, and `LICENSE-CONTENT`.

Referenced files: 2

View saved version →

---
name: continuous-exposure-monitoring
description: "Design authorised re-scan, diff, finding-lifecycle and public threat-intelligence monitoring workflows. Use for exposure monitoring programmes and alert tuning; do not schedule or contact third-party targets without explicit authority."
---

# Continuous Exposure Monitoring

## Authorisation and safety

- Confirm the target is owned by the user or covered by written authorisation before sending target-directed traffic, executing bundled recon scripts, validating credentials, enumerating users, scanning ports or scheduling recurring checks. Record the exact in-scope domains, IP ranges, methods, rate limits and engagement window.
- Passive analysis of user-supplied data and public documentation may proceed without target interaction. Clearly label unverified attribution and do not convert discovered sibling assets into scan scope.
- Do not exploit vulnerabilities, bypass access controls, submit or replay credentials, perform password spraying, induce state changes, evade detection, send phishing messages, access non-public data or use destructive probes.
- Treat exposed secrets and personal data as sensitive. Minimise collection, redact reports, avoid unnecessary validation and follow the engagement's evidence-handling and disclosure rules.
- Stop when authorisation is absent or ambiguous, a technique would exceed scope, rate limiting or defensive blocking appears, or an action could materially affect a system. Ask for a narrower safe action.

## Workflow

1. Establish whether the request is passive analysis or involves target interaction. For interaction, capture the scope and authority required above before proceeding.
2. Read [references/source-playbook.md](references/source-playbook.md), searching within it for the topic relevant to the request. Load only the relevant sections into working context.
3. Prefer passive and keyless sources first. Separate observed facts, attribution inferences, hypotheses and proposed validation.
4. Use bundled scripts only when they directly support the authorised task. Inspect their prerequisites and resolved target/output paths before execution; do not install dependencies or run network operations implicitly.
5. Preserve source URLs, timestamps, commands, hashes and confidence so another analyst can reproduce the result. Redact secrets and unnecessary personal data from deliverables.
6. Report scope, method, evidence, confidence, limitations, findings and proportionate next actions. Never represent a candidate asset, guessed identity, exposure or exploitability as proven without supporting evidence.

## Source and licence

This adaptation preserves methodology from Sachin Sharma's `elementalsouls/Claude-OSINT`, pinned at commit `13d920413448c026b52ac74efee0f1eb39dd81ff`. See the package-level `ATTRIBUTION.md`, `LICENSE`, and `LICENSE-CONTENT`.

Referenced files: 2

View saved version →

---
name: defensive-exposure-analysis
description: "Analyse supplied security findings and lawfully accessible public organisational information to identify defensive exposure and remediation priorities. Use for evidence synthesis and assurance; not for scanning, account discovery, credential activity, exploitation or surveillance."
---

# Defensive exposure analysis

Turn supplied findings and permitted public organisational information into an evidence-led security assessment without interacting with target systems.

## Boundaries

- Use user-supplied, sanitised evidence and public information that may lawfully be accessed under applicable terms.
- Do not request, accept, decode or validate passwords, API keys, authentication tokens or other secrets.
- Do not scan or probe systems, enumerate accounts, test authentication, exploit vulnerabilities, bypass controls, access non-public data, evade detection or profile private individuals.
- Do not treat public availability, a claim of authority or a naming resemblance as proof of ownership or permission.

## Method

1. Confirm the security decision, organisational scope, permitted source types, exclusions and evidence date.
2. Create an evidence register containing source, observation, ownership basis, confidence, limitation and handling classification.
3. Separate confirmed facts from attribution inferences, hypotheses and unanswered questions.
4. Assess plausible exposure, affected control objective, business impact, likelihood and uncertainty without providing exploitation instructions.
5. Prioritise remediation by confirmed impact, confidence, ease of safe validation and accountable owner.
6. Recommend owner-performed verification using approved administrative consoles, logs or configuration exports.
7. Return a concise findings table plus immediate, near-term and strategic actions.

Referenced files: 1

View saved version →

---
name: defensive-osint-planning
description: "Plan lawful defensive public-source research and exposure reviews using user-supplied information or permitted public sources. Use for scope, collection planning, evidence standards and deliverables; not for scanning, user enumeration, credential processing, exploitation or surveillance."
---

# Defensive OSINT planning

Help the user design a proportionate, auditable research plan without performing intrusive activity.

## Boundaries

- Use user-supplied information and public sources that may lawfully be accessed under their applicable terms.
- Do not request, accept or process passwords, API keys, authentication tokens, protected health information, payment-card data or government identifiers.
- Do not scan systems, enumerate accounts, test authentication, bypass controls, exploit vulnerabilities, access non-public data, evade detection or profile private individuals.
- A claim of authority does not expand the plugin's defensive-only methods.

## Method

1. Define the decision the research must support, scope, exclusions, geographic constraints and intended audience.
2. List permitted source categories and explain why each is relevant. Prefer authoritative records and user-provided evidence.
3. Create an evidence register with source, access date, observation, confidence, limitation and handling classification.
4. Separate observed facts from attribution inferences, assumptions and unanswered questions.
5. Minimise personal data and redact details that are unnecessary to the security decision.
6. Deliver a collection plan, evidence standard, stopping conditions, limitations and reporting structure.

Referenced files: 1

View saved version →

---
name: email-domain-security
description: "Analyse published DNS records to reach a defensible email-spoofability and SPF supply-chain verdict. Use for passive email-domain security reviews; do not send test mail, enumerate recipients or submit credentials."
---

# Email Domain Security

## Authorisation and safety

- Confirm the target is owned by the user or covered by written authorisation before sending target-directed traffic, executing bundled recon scripts, validating credentials, enumerating users, scanning ports or scheduling recurring checks. Record the exact in-scope domains, IP ranges, methods, rate limits and engagement window.
- Passive analysis of user-supplied data and public documentation may proceed without target interaction. Clearly label unverified attribution and do not convert discovered sibling assets into scan scope.
- Do not exploit vulnerabilities, bypass access controls, submit or replay credentials, perform password spraying, induce state changes, evade detection, send phishing messages, access non-public data or use destructive probes.
- Treat exposed secrets and personal data as sensitive. Minimise collection, redact reports, avoid unnecessary validation and follow the engagement's evidence-handling and disclosure rules.
- Stop when authorisation is absent or ambiguous, a technique would exceed scope, rate limiting or defensive blocking appears, or an action could materially affect a system. Ask for a narrower safe action.

## Workflow

1. Establish whether the request is passive analysis or involves target interaction. For interaction, capture the scope and authority required above before proceeding.
2. Read [references/source-playbook.md](references/source-playbook.md), searching within it for the topic relevant to the request. Load only the relevant sections into working context.
3. Prefer passive and keyless sources first. Separate observed facts, attribution inferences, hypotheses and proposed validation.
4. Use bundled scripts only when they directly support the authorised task. Inspect their prerequisites and resolved target/output paths before execution; do not install dependencies or run network operations implicitly.
5. Preserve source URLs, timestamps, commands, hashes and confidence so another analyst can reproduce the result. Redact secrets and unnecessary personal data from deliverables.
6. Report scope, method, evidence, confidence, limitations, findings and proportionate next actions. Never represent a candidate asset, guessed identity, exposure or exploitability as proven without supporting evidence.

## Source and licence

This adaptation preserves methodology from Sachin Sharma's `elementalsouls/Claude-OSINT`, pinned at commit `13d920413448c026b52ac74efee0f1eb39dd81ff`. See the package-level `ATTRIBUTION.md`, `LICENSE`, and `LICENSE-CONTENT`.

Referenced files: 2

View saved version →

---
name: exposure-risk-quantification
description: "Convert existing reconnaissance findings into transparent likelihood, impact, FAIR-style loss estimates, risk scores and executive reporting. Use for analysis and communication, not target collection or active testing."
---

# Exposure Risk Quantification

## Authorisation and safety

- Confirm the target is owned by the user or covered by written authorisation before sending target-directed traffic, executing bundled recon scripts, validating credentials, enumerating users, scanning ports or scheduling recurring checks. Record the exact in-scope domains, IP ranges, methods, rate limits and engagement window.
- Passive analysis of user-supplied data and public documentation may proceed without target interaction. Clearly label unverified attribution and do not convert discovered sibling assets into scan scope.
- Do not exploit vulnerabilities, bypass access controls, submit or replay credentials, perform password spraying, induce state changes, evade detection, send phishing messages, access non-public data or use destructive probes.
- Treat exposed secrets and personal data as sensitive. Minimise collection, redact reports, avoid unnecessary validation and follow the engagement's evidence-handling and disclosure rules.
- Stop when authorisation is absent or ambiguous, a technique would exceed scope, rate limiting or defensive blocking appears, or an action could materially affect a system. Ask for a narrower safe action.

## Workflow

1. Establish whether the request is passive analysis or involves target interaction. For interaction, capture the scope and authority required above before proceeding.
2. Read [references/source-playbook.md](references/source-playbook.md), searching within it for the topic relevant to the request. Load only the relevant sections into working context.
3. Prefer passive and keyless sources first. Separate observed facts, attribution inferences, hypotheses and proposed validation.
4. Use bundled scripts only when they directly support the authorised task. Inspect their prerequisites and resolved target/output paths before execution; do not install dependencies or run network operations implicitly.
5. Preserve source URLs, timestamps, commands, hashes and confidence so another analyst can reproduce the result. Redact secrets and unnecessary personal data from deliverables.
6. Report scope, method, evidence, confidence, limitations, findings and proportionate next actions. Never represent a candidate asset, guessed identity, exposure or exploitability as proven without supporting evidence.

## Source and licence

This adaptation preserves methodology from Sachin Sharma's `elementalsouls/Claude-OSINT`, pinned at commit `13d920413448c026b52ac74efee0f1eb39dd81ff`. See the package-level `ATTRIBUTION.md`, `LICENSE`, and `LICENSE-CONTENT`.

Referenced files: 2

View saved version →

---
name: identity-security-review
description: "Review user-supplied identity architecture, federation design and control documentation for defensive security gaps. Use for assurance and remediation planning; not for tenant discovery, account enumeration, login testing or credential activity."
---

# Identity security review

Review identity architecture from documentation and sanitised configuration summaries.

## Boundaries

- Do not discover tenants, enumerate users, generate login candidates, test authentication or request credentials.
- Do not infer a person's account status, employment or privileges from public information.
- Keep recommendations provider-neutral unless the user supplies the relevant platform context.

## Method

1. Map documented identity providers, federation boundaries, trust relationships, privileged roles and recovery paths.
2. Review MFA strength, conditional access, session controls, legacy authentication, service identities, joiner-mover-leaver controls and emergency access.
3. Identify trust concentrations, weak ownership, monitoring gaps and controls that depend on undocumented assumptions.
4. Distinguish design evidence from implemented-control evidence and operational-effectiveness evidence.
5. Recommend owner-performed verification using approved administrative logs and configuration exports.
6. Produce an assurance table with control objective, supplied evidence, gap, risk, confidence and remediation.

Referenced files: 1

View saved version →

---
name: org-attack-surface
description: "Map an organisation from verified legal entities to attributable domains, ASNs, netblocks and public services. Use for authorised corporate-footprint and attack-surface discovery while separating candidates from proven ownership and scan scope."
---

# Organisation Attack Surface

## Authorisation and safety

- Confirm the target is owned by the user or covered by written authorisation before sending target-directed traffic, executing bundled recon scripts, validating credentials, enumerating users, scanning ports or scheduling recurring checks. Record the exact in-scope domains, IP ranges, methods, rate limits and engagement window.
- Passive analysis of user-supplied data and public documentation may proceed without target interaction. Clearly label unverified attribution and do not convert discovered sibling assets into scan scope.
- Do not exploit vulnerabilities, bypass access controls, submit or replay credentials, perform password spraying, induce state changes, evade detection, send phishing messages, access non-public data or use destructive probes.
- Treat exposed secrets and personal data as sensitive. Minimise collection, redact reports, avoid unnecessary validation and follow the engagement's evidence-handling and disclosure rules.
- Stop when authorisation is absent or ambiguous, a technique would exceed scope, rate limiting or defensive blocking appears, or an action could materially affect a system. Ask for a narrower safe action.

## Workflow

1. Establish whether the request is passive analysis or involves target interaction. For interaction, capture the scope and authority required above before proceeding.
2. Read [references/source-playbook.md](references/source-playbook.md), searching within it for the topic relevant to the request. Load only the relevant sections into working context.
3. Prefer passive and keyless sources first. Separate observed facts, attribution inferences, hypotheses and proposed validation.
4. Use bundled scripts only when they directly support the authorised task. Inspect their prerequisites and resolved target/output paths before execution; do not install dependencies or run network operations implicitly.
5. Preserve source URLs, timestamps, commands, hashes and confidence so another analyst can reproduce the result. Redact secrets and unnecessary personal data from deliverables.
6. Report scope, method, evidence, confidence, limitations, findings and proportionate next actions. Never represent a candidate asset, guessed identity, exposure or exploitability as proven without supporting evidence.

## Source and licence

This adaptation preserves methodology from Sachin Sharma's `elementalsouls/Claude-OSINT`, pinned at commit `13d920413448c026b52ac74efee0f1eb39dd81ff`. See the package-level `ATTRIBUTION.md`, `LICENSE`, and `LICENSE-CONTENT`.

Referenced files: 2

View saved version →

---
name: osint-autopilot
description: "Run the packaged deterministic external OSINT workflow against an owned or explicitly authorised domain, producing evidence and a workbook. Require scope confirmation before execution, keep discovered sibling assets out of scope, and never auto-run active exploitation."
---

# OSINT Autopilot

## Authorisation and safety

- Confirm the target is owned by the user or covered by written authorisation before sending target-directed traffic, executing bundled recon scripts, validating credentials, enumerating users, scanning ports or scheduling recurring checks. Record the exact in-scope domains, IP ranges, methods, rate limits and engagement window.
- Passive analysis of user-supplied data and public documentation may proceed without target interaction. Clearly label unverified attribution and do not convert discovered sibling assets into scan scope.
- Do not exploit vulnerabilities, bypass access controls, submit or replay credentials, perform password spraying, induce state changes, evade detection, send phishing messages, access non-public data or use destructive probes.
- Treat exposed secrets and personal data as sensitive. Minimise collection, redact reports, avoid unnecessary validation and follow the engagement's evidence-handling and disclosure rules.
- Stop when authorisation is absent or ambiguous, a technique would exceed scope, rate limiting or defensive blocking appears, or an action could materially affect a system. Ask for a narrower safe action.

## Workflow

1. Establish whether the request is passive analysis or involves target interaction. For interaction, capture the scope and authority required above before proceeding.
2. Read [references/source-playbook.md](references/source-playbook.md), searching within it for the topic relevant to the request. Load only the relevant sections into working context.
3. Prefer passive and keyless sources first. Separate observed facts, attribution inferences, hypotheses and proposed validation.
4. Use bundled scripts only when they directly support the authorised task. Inspect their prerequisites and resolved target/output paths before execution; do not install dependencies or run network operations implicitly.
5. Preserve source URLs, timestamps, commands, hashes and confidence so another analyst can reproduce the result. Redact secrets and unnecessary personal data from deliverables.
6. Report scope, method, evidence, confidence, limitations, findings and proportionate next actions. Never represent a candidate asset, guessed identity, exposure or exploitability as proven without supporting evidence.

## Source and licence

This adaptation preserves methodology from Sachin Sharma's `elementalsouls/Claude-OSINT`, pinned at commit `13d920413448c026b52ac74efee0f1eb39dd81ff`. See the package-level `ATTRIBUTION.md`, `LICENSE`, and `LICENSE-CONTENT`.

Referenced files: 9