authorized_osint_recon v1.0.0

name: authorized_osint_recon description: >- Run open source recon on an organization you are authorized to test: written scope and rules of engagement first, passive sources before any active probing, a verified asset inventory built from domains, certificates, public records, and third party datasets, honest scoring, and a report a client can act on. Use when starting an authorized recon, building an external asset inventory, checking what an organization exposes publicly, or scoping a security assessment. Do not use without written authorization for the specific assets in scope.

Authorized OSINT Recon

Purpose

Build a verified inventory of what an organization exposes in public sources, under a written authorization, so the client can confirm, remove, or protect what you found. The work is passive first, evidence logged from the first query, and scored honestly. This skill stops at recon and inventory. It does not teach exploitation, credential attacks, social engineering, or attack path work. Those need a separate engagement, a separate authorization, and a different skill.

Workflow

1. Pass the authorization gate, or stop

Do not run a single query against a named target until all of these are true:

• A scope and rules of engagement document is signed by a person who owns, or is delegated to authorize testing of, every asset in scope. Template: references/scope-and-roe-template.md, following NIST SP 800-115 Appendix B and the PTES pre-engagement phase.
• The document lists in scope assets by identifier: domains, CIDRs, cloud account IDs, named tenants or repositories. Descriptions such as "our web presence" do not count.
• It lists exclusions by identifier, allowed methods, prohibited methods, test windows with time zone, a deconfliction contact reachable during work, stop conditions, and data handling rules.
• The dates cover today. Expired authorization means no work, not even passive queries presented as an engagement. Renew it in writing first.
• For any cloud account in scope, the provider testing rules have been checked and noted. A client signature does not override a provider prohibition.

If any item is missing, return the gap list to the client and stop. Starting anyway is the failure this skill exists to prevent.

2. Freeze the claimed scope

• Record the client claimed inventory exactly as given: their domain list, IP ranges, cloud accounts, brands, subsidiaries, and prior inventory.
• Save it as the scope file for the tool in step 5. Use examples/scope.example.json as the shape. Required fields are organization, authorization reference, authorized by, valid from, valid to, and at least one in scope list.
• Note every asset the client could not confirm they own. Those start as owner unverified, however confident the team feels.

3. Collect passive sources, in order

Work references/passive-sources.md from top to bottom:

1. Client provided records
2. Registration data through RDAP and ICANN Lookup
3. Certificate Transparency through crt.sh and similar CT indexes
4. DNS history held by third parties
5. Public records and filings
6. Web archives and search indexes
7. Third party scan datasets such as urlscan.io public scans and Censys
8. Public code and document indexes

Rules for this step:

• Passive means no traffic to the target. Reading a dataset, registry, archive, or index that a third party already built is passive. Sending a DNS query to the target authoritative server, fetching a target page, or resolving a target name yourself is active in the log, even if it feels harmless.
• Log every query as you go, in the evidence format at the end of references/passive-sources.md. A finding with no log line does not go in the report.
• Record names exactly as the source spells them. Normalizing case and trailing dots happens in the tool, not in your notes.
• Treat personal data under a minimization rule: record business roles and published business contacts only. Do not build lists of private individuals, private addresses, or personal accounts. If a source mixes them in, record the asset and note that personal data was present, without copying it.
• If a source shows a credential, private key, or secret, do not copy the value, do not test it, and do not download more of that file. Note the location, stop that line, and notify the deconfliction contact the same day.

4. Decide if any active step is allowed, separately

Recon under this skill can finish fully passive, and for many clients it should.

• An active step, such as live DNS resolution, an HTTP request to confirm a host is alive, or a port check, needs its own line in the signed rules of engagement naming that method, the targets it covers, the window, and the source addresses.
• If the signed document says passive only, or says nothing about a method, that method is not allowed. Silence is not consent.
• Keep any approved active step minimal: confirm existence only, at a low rate, inside the window, and stop at once on any stop condition. No vulnerability scanning, probing for flaws, or exploitation under this skill.
• Log active steps apart from passive ones, so the report reader can tell which claims rest on which kind of evidence.

5. Build and verify the inventory

Put every observation into a JSON file shaped like examples/observations.example.json. Each observation needs asset, asset type, source, observed date, and method, plus confidence and owner verified when you know them.

Run the bundled offline tool. It makes no network calls:

python3 ~/workspace/skills/authorized-osint-recon/scripts/inventory.py --scope scope.json --observations observations.json --out-json inventory.json --out-md inventory.md --as-of 2026-10-28

What the tool does, and what you must still do by hand:

• It fails closed with exit code 2 if authorization is missing or out of date on the as-of date. Do not work around that output. Fix the authorization.
• It rejects any observation whose method is not in the scope allowed methods, and counts the rejection in the summary.
• It merges duplicate assets, keeps every source, checks domains against the in scope domains and exclusions, checks IPs against the in scope CIDRs, and flags out of scope, stale (over 90 days by default), single source, unconfirmed, and owner unverified items.
• It assigns a triage priority from a printed rubric. That number orders human review only.
• By hand: take every owner unverified and out of scope item to the client or scope owner and get a written answer. Update owner verified only on that written answer, then rerun the tool. A shared certificate, a shared IP, or a similar name is a reason to ask, never a reason to mark ownership confirmed yourself.

Worked result from the bundled examples, run on 2026-10-28: 5 assets after merging, 4 in scope, 1 out of scope (partner-other.com, found on a shared certificate), 1 stale, and 1 observation rejected because its method was active while the scope allowed passive only. The top item was vpn.example.com at priority 60, because the name is in the high sensitivity word group and ownership was not yet verified.

6. Score honestly

• The inventory triage priority is not a risk score. Say so in the report, next to the table.
• Give a CVSS score only for a confirmed vulnerability, and only with its full vector string, using CVSS v4.0 from FIRST. A hostname, an old banner, or a staging name is not a vulnerability and gets no CVSS score.
• Add CISA Known Exploited Vulnerabilities status or a FIRST EPSS probability only for a confirmed vulnerability they actually cover, labeled as extra signals with their dates.
• Rate confidence per finding, in three words only: confirmed (two independent passive sources, or one source plus written client confirmation), likely (one credible source, current), unconfirmed (single, stale, or indirect source). The report summary must use the same ratings as the finding sections.
• State coverage limits plainly: which sources were checked, on what dates, and that indexes and datasets are samples with gaps. Absence from a source is not proof an asset does not exist.

7. Report so the client can act

Use references/report-template.md. Every report contains:

• Executive summary with the decisions needed, in half a page
• Authorization and method section, including what was not done
• The full inventory table from the tool, with out of scope rows kept in and marked
• One section per finding: evidence with source and date, confidence, why it matters in client terms, scoring done under step 6, a recommended action with an owner and a date or trigger
• An out of scope section with no probing notes, because no probing happened
• A housekeeping list: expiring domains and certificates, dead names the client confirmed, register gaps the client confirmed
• The full evidence log as an appendix, plus the scope and observations files, so a second tester can rebuild the same inventory

8. Close out

• Deliver the report through the channel named in the rules of engagement, to the people named there, and to no one else. A recon report is a map of an organization, treat it as sensitive.
• Delete working exports and saved source files on the deletion date in the data handling section, or hand them to the client as the rules require. Note which you did.
• If the client fixes or removes an item, a recheck is a new dated run of steps 3 to 5 against that item only, recorded as a recheck, not an edit to the original report.

Output Contract

Deliver all of these, or state which one is missing and why:

1. Signed scope and rules of engagement, or the gap list that stopped the work
2. Inventory in JSON and Markdown from scripts/inventory.py, built from a dated observations file
3. Evidence log covering every query and every finding
4. Report in the template shape, with confidence ratings that match between summary and findings, and no CVSS score on any item that is not a confirmed vulnerability
5. Close out note: delivery channel and recipients, retention or deletion action taken, and any recheck scheduled

Operating Rules

1. No authorization, no recon. Written, in date, by identifier, signed by someone entitled to give it. This rule has no exceptions for small or quick jobs.
2. Passive first, and passive only unless an active method is named and signed. When in doubt about whether a step is passive, label it active and check.
3. Out of scope means hands off. Log it, report it to the scope owner, and wait for a signed change. Curiosity is not a scope change.
4. Never use credentials, keys, or secrets found in public sources. Never test whether they work. Report the location and stop.
5. No social engineering, phishing, pretext calls, or contact with target staff outside the named client contacts, under any authorization for this skill.
6. No denial of service, scanning at volume, exploitation, or persistence under this skill, even if a client asks in chat. Those need a different engagement and a written change first.
7. Minimize personal data. Business assets and roles are the subject. Private individuals are not inventory items.
8. Every claim carries a source and a date. Unverifiable claims are cut, or written as unconfirmed with the gap named.
9. Keep the report and evidence inside the agreed handling rules. Do not paste client asset lists, evidence, or findings into public tools, tickets, or chats outside the agreed channel.
10. If a stop condition triggers, stop, preserve the log as it stands, and call the deconfliction contact. Resume only on a written go ahead from the client contact.