Writing OSINT Reports

Learning Objectives

• Structure a complete OSINT report that answers the client’s original question
• Write the same finding differently for executives and for technical teams
• Write findings that include evidence, a source grade, a confidence level, impact, and recommendations
• Rate risk consistently and write recommendations people can act on
• Handle, label, and distribute a sensitive report safely, including only the personal information that’s needed

What a Report Is For

The report is the dissemination step of the OSINT cycle. It’s usually the only part of your work the client ever sees. A brilliant investigation with a confusing report has little value; a clear report turns findings into decisions and fixes.

A good OSINT report:
- Answers the question set during planning (the intelligence requirement)
- Puts the bottom line up front (BLUF): the most important conclusions come first
- Backs every claim with evidence the reader can check
- States confidence using consistent estimative language (see 7.2-analysis-and-cognitive-bias.md)
- Separates facts from judgments
- Recommends specific actions
- Includes only the personal information needed (minimization)
- Can be reproduced from the investigation log (see 7.3-documentation-and-evidence.md)

Writing for Your Audience

Most OSINT reports have more than one audience. Structure the report so each reader can find what they need.

The same finding, two ways (fictional)

For executives:

A software developer accidentally published a password-like key for one of our cloud services on a public code site. Anyone who found it could potentially access customer data stored in that service. It should be disabled today.

For the technical team:

A cloud storage access key was committed to the public repository github.com/companyx-dev/deploy-scripts in commit a1b2c3d (2026-08-02) in config/prod.env, line 14. The key was removed in a later commit but remains in the repository history. We did not test whether the key is valid (outside the authorized scope). Rotate the key immediately, review the service’s access logs from 2026-08-02 onward, purge the key from repository history, and enable secret scanning on the organization.

Full Report Template

# OSINT Assessment Report: <Client / Target Name>

**Handling:** TLP:AMBER+STRICT (Company X security team only)
**Report ID:** CASE-2026-014 | **Version:** 1.0 | **Date:** 2026-09-20
**Prepared by:** <names / team> | **Reviewed by:** <peer reviewer>
**Distribution list:** <named recipients only>

---

## 1. Executive Summary
- What we were asked to find out (one sentence)
- Bottom line: the most important conclusions, with confidence
- Overall exposure rating
- Top 3–5 recommended actions

## 2. Scope & Authorization
- Authorized by: <name, role, date of written authorization>
- In scope: <domains, organization, named roles, time window>
- Out of scope: <e.g., employees' family members, personal accounts not linked to work, active scanning>
- Rules of engagement: passive collection only; no account logins; no contact with employees

## 3. Methodology
- Collection period: <start – end, UTC>
- Approach: OSINT cycle; passive collection; verification and ACH for key judgments
- Source categories used: <search engines, social media, DNS/CT logs, code repositories, breach-notification services, etc.>
- Tools: <list with versions where relevant>
- Source grading: Admiralty Code (reliability A–F, credibility 1–6)
- Confidence and likelihood language: see Appendix D
- Limitations: <e.g., no access to paid breach databases; LinkedIn data limited without login; findings reflect a point in time>

## 4. Summary of Findings
| ID | Finding | Risk | Confidence |
|----|---------|------|------------|
| F-01 | Cloud access key exposed in public code repository | Critical | High |
| F-02 | Security stack and VPN details exposed through job posts and internet-facing systems | High | High |
| F-03 | Employee directory and email format enable targeted phishing | Medium | High |
| F-04 | Old credential data circulating with some password reuse | Medium | Moderate |

## 5. Detailed Findings
(one section per finding, using the finding template)

## 6. How an Attacker Could Combine These Findings
- Narrative attack path showing how findings chain together
- Diagram (link chart or attack path)

## 7. Recommendations (Prioritized)
| Priority | Action | Addresses | Owner (suggested) | Effort |
|----------|--------|-----------|-------------------|--------|

## 8. Intelligence Gaps & Limitations
- What we could not determine, and what would close the gap

## Appendices
- A. Evidence index (ID, description, file, SHA-256, collection time)
- B. Investigation log (or reference to it)
- C. Restricted personal data annex (separately encrypted, need-to-know only)
- D. Likelihood / confidence key and Admiralty Code key
- E. Glossary

Finding template

### F-XX: <Short, specific title>
**Risk:** <Critical / High / Medium / Low / Informational>
**Confidence:** <High / Moderate / Low>

**Summary:** <2–3 sentences: what was found and why it matters>

**Details:** <What, where, when. Facts first, then judgments, clearly labeled.>

**Evidence:**
| Evidence ID | Description | Source (grade) | Captured (UTC) |
|---|---|---|---|

**Impact:** <What an attacker could do with this; business consequences>

**Recommendations:**
1. <Immediate action>
2. <Longer-term fix>

**Notes / limitations:** <What was not tested and why; assumptions>

Rating Risk

CVSS and similar systems score software vulnerabilities, not information exposure, so most OSINT reports use a simple likelihood × impact rating. Whatever system you choose, define it in the report and apply it consistently.

• Likelihood: how easily could an attacker find and use this? (Found on page one of a search? Requires paid tools? Requires insider knowledge?)
• Impact: what’s the worst realistic outcome? (Direct system access? Better-targeted phishing? Embarrassment only?)

Example Findings (Fictional Company X)

F-01: Cloud access key exposed in public code repository

Risk: Critical | Confidence: High (that the key was exposed; validity was not tested)

Summary: A cloud storage access key for Company X was published in a public GitHub repository belonging to a Company X developer account. Anyone who finds the key could potentially read or change data in that storage service.

Details: The repository companyx-dev/deploy-scripts is public and linked from a Company X engineer’s public profile. Commit a1b2c3d (2026-08-02) added config/prod.env, which contains a variable named STORAGE_ACCESS_KEY. A later commit deleted the file, but the key remains visible in the repository history. We did not attempt to use the key; testing credentials was outside the authorized scope.

Evidence:
| Evidence ID | Description | Source (grade) | Captured (UTC) |
|—|—|—|—|
| EV-003 | Full-page capture of commit a1b2c3d showing the key (key partially masked in this report) | GitHub (A1) | 2026-09-16T20:11Z |
| EV-004 | Saved copy of the repository page linking it to Company X | GitHub (A2) | 2026-09-16T20:14Z |

Impact: If the key is still valid, an attacker could access or alter files stored in the service, which may include customer data. Automated scanners regularly search public repositories for exposed keys, so we assess it is likely others have already seen it.

Recommendations:
1. Disable and replace (rotate) the key immediately.
2. Review the storage service’s access logs from 2026-08-02 onward for unauthorized use.
3. Remove the key from repository history and review other repositories for similar issues.
4. Enable secret scanning for all Company X repositories and add pre-commit secret checks.

F-02: Security stack and VPN details exposed

Risk: High | Confidence: High

Summary: Job postings, certificate logs, and an internet-scan search engine together reveal Company X’s firewall vendor, endpoint security product, and VPN product. This lets an attacker choose exploits and phishing lures that match Company X’s exact technology.

Details:
- Three current job postings name the firewall vendor, the endpoint detection product, and “experience administering ” (EV-007 to EV-009).
- Certificate Transparency logs list vpn.companyx.com (EV-010).
- An internet-scan search engine shows a login page for that VPN product on the matching IP address, including a version string in the page (EV-011).
- Judgment: Company X very likely runs the named VPN product at vpn.companyx.com. We did not check whether the version shown has known vulnerabilities by interacting with the system; any vulnerability check should be done by the internal team.

Impact: VPN appliances are a frequent target for attackers. Knowing the exact product and version lets an attacker quickly check for known vulnerabilities.

Recommendations:
1. Confirm the VPN appliance is fully patched.
2. Hide version information on the login page if the product allows it.
3. Write job postings with general skill categories (“enterprise firewall experience”) rather than exact products where recruiting allows.
4. Require phishing-resistant MFA on VPN access.

F-03: Employee directory and email format enable targeted phishing

Risk: Medium | Confidence: High

Summary: A list of 14 IT staff with job titles can be built from public professional profiles, and Company X’s email format is confirmed. Together, these let an attacker send convincing, targeted phishing emails to people with administrative access.

Details:
- Company X’s email format is first.last@companyx.com, confirmed by five independent examples: the website contact page, two press releases, and two commit email addresses (EV-012 to EV-016).
- 14 employees list IT or security roles at Company X on public professional profiles. Names are listed only in Appendix C (restricted). Roles include two domain administrators and a help desk lead.
- Several of these employees publicly list the specific tools they administer.

Impact: Administrators are high-value phishing targets because their accounts have broad access.

Recommendations:
1. Give IT staff targeted phishing awareness training.
2. Require phishing-resistant MFA for administrative accounts.
3. Offer guidance on what staff share publicly about internal tools and roles.
4. Monitor for lookalike domains that could be used for phishing.

F-04: Old credential data with some password reuse

Risk: Medium | Confidence: Moderate

Summary: A post on a paste site advertises “fresh” Company X credentials. Our analysis indicates the data very likely comes from a 2019 third-party breach rather than a new compromise, but three current employees still use the exposed passwords.

Details: See the ACH worked example in 7.2-analysis-and-cognitive-bias.md. Confidence is moderate because the conclusion relies partly on client-provided HR records. No passwords are reproduced in this report. The three affected employees were identified to the security team through a separate secure channel.

Recommendations:
1. Force password resets for the three affected accounts immediately.
2. Check all current accounts against known breached passwords at login and password change.
3. Enforce MFA for all employees.

Telling the Attack Path Story

Executives often understand risk best as a story. Show how separate findings combine:

An attacker searching public sources could learn which VPN product Company X uses and that its version is shown on the login page (F-02). They could then identify IT administrators and their email addresses (F-03) and send them a convincing phishing email pretending to be a VPN security update, directing them to a fake VPN login page. Separately, an exposed cloud key (F-01) might give direct access to stored data with no phishing needed at all.

Pair this with a simple diagram (a link chart or attack path). ICD 203 lists effective visual information as an analytic tradecraft standard for good reason: a diagram often communicates the chain faster than text.

Writing Style Tips

• Plain language, active voice, short sentences. “An attacker could reset the password” beats “It may be possible for password reset functionality to be leveraged.”
• Define terms the first time you use them, or link to the glossary.
• Be precise, not dramatic. Avoid words like “catastrophic” or “trivial”; let the evidence and risk rating speak.
• Label judgments. Use “we assess” or “likely” for judgments; state facts plainly with their source.
• Be consistent. Use the same term for the same thing throughout (don’t switch between “credential,” “login,” and “password” for one item).
• Use screenshots well. Crop to the relevant part (on a working copy), highlight key details, caption every image, and reference its evidence ID.
• State what you didn’t do. “We did not test the key” protects you and tells the reader exactly how far the finding goes.

Handling and Distributing Sensitive Reports

An OSINT report is a roadmap for attackers. Treat it accordingly.

Label it

Use a clear handling label on every page. Many security teams use the Traffic Light Protocol (TLP) from FIRST (version 2.0, released August 2022):
- TLP:RED: for the individual recipients only; no further sharing
- TLP:AMBER: limited sharing on a need-to-know basis within the recipient’s organization and its clients
- TLP:AMBER+STRICT: like AMBER, but restricted to the recipient’s organization only (see FIRST’s page for exact wording)
- TLP:GREEN: may be shared within the recipient’s community
- TLP:CLEAR: no limit on sharing

Protect it

• Encrypt the report and any evidence packages, in storage and in transit.
• Deliver securely: use an encrypted file-sharing method agreed with the client, not an ordinary email attachment. Send passwords through a different channel.
• Keep a distribution list and send only to named people.
• Version control: number versions and record who received which version.
• Redact properly. Drawing black boxes over text in a document often leaves the text underneath, where it can be copied out. Use a real redaction tool that removes the underlying content, then check the output.
• Watermark copies per recipient if leaks are a concern.
• Retention: agree how long the report and evidence will be kept, and securely delete them afterward.

Minimize personal information

• Include personal data only when a finding needs it.
• Prefer roles and counts over names in the main body (“14 IT staff, including two domain administrators”).
• Put any necessary names or identifiers in a separate restricted appendix.
• Never include plaintext passwords; mask secrets (show only the first few characters) and share specifics through a separate secure channel.
• Leave out family members, minors, home addresses, health information, and other sensitive details unless the scope specifically requires them, and even then think hard.
• Say what you deliberately excluded: “Personal social media accounts of employees were out of scope and were not reviewed.”

Pre-Delivery Checklist

• The executive summary answers the original question in plain language
• Every finding has evidence IDs that match the evidence index and hashes
• Every judgment has a confidence level and uses consistent likelihood terms
• Facts, assumptions, and judgments are clearly separated
• Risk ratings follow the defined method
• Recommendations are specific and prioritized
• Scope, authorization, and limitations are stated
• Personal data is minimized; no plaintext secrets
• Redactions have been verified
• Handling label, version, and distribution list are on the document
• A peer reviewer has checked the findings against the log

Key Terms

• Dissemination: delivering finished intelligence to the people who need it
• BLUF (Bottom Line Up Front): putting the key conclusions at the start
• Intelligence requirement: the question the investigation was set up to answer
• Finding: a single, specific result with evidence, risk, and recommendations
• Attack path: how an attacker could chain several findings together
• TLP (Traffic Light Protocol): FIRST’s standard labels for how widely information may be shared
• Minimization: including only the personal information a purpose requires
• Redaction: permanently removing sensitive content from a document

Key Takeaways

• Bottom line up front: answer the client’s question first
• Write for each audience: business impact for executives, exact details for technical teams
• Every finding = evidence + source grade + confidence + impact + recommendation
• Define your risk rating and apply it consistently
• Tell the attack path story to show how small exposures combine
• Say what you did not test or review
• The report is an attacker’s roadmap: label it, encrypt it, limit it
• Roles and counts over names; never include plaintext passwords

References

• Traffic Light Protocol (TLP) — FIRST
• ICD 203: Analytic Standards — Office of the Director of National Intelligence (PDF)
• Berkeley Protocol on Digital Open Source Investigations — OHCHR