Organization-Owned Sources

Learning Objectives

• Map the information an organization publishes about itself: websites, documents, job postings, and policies
• Extract intelligence from document metadata and explain what it reveals
• Read a job posting as a technology inventory of the target
• Use a site’s own files (robots.txt, sitemap.xml, security.txt) as reconnaissance
• Explain how Terms of Service and privacy policies both restrict you and hint at what’s possible

Why an Organization Is Its Own Biggest Leak

Organizations publish an enormous amount about themselves on purpose, for marketing, recruiting, sales, and legal compliance. Each of those goals leaks something useful to an investigator. This is almost entirely passive collection with one caveat: browsing the target’s own website puts your IP address in their web server logs. That makes it “semi-passive” (see Module 4 and Module 8). Reading an archived copy instead keeps you fully passive (see Module 6).

The Company Website

The website is the anchor of organizational OSINT.

• About / Team / Leadership pages: names, titles, photos, and bios. Bios often mention prior employers, hobbies, and hometowns (great for password-guessing and social engineering, which is exactly why they matter defensively).
• Contact pages: phone numbers and email addresses that reveal the email address format (e.g., first.last@companyx.com or flast@companyx.com). Learn the format from one known address, and you can guess everyone else’s from a LinkedIn employee list.
• Locations: office addresses, hours, and sometimes photos of the building and reception (useful for physical assessments and for understanding time zones).
• Customers, partners, vendors: “Our clients” and “Trusted by” logos reveal business relationships that can be used for supply-chain-style pretexting (“Hi, I’m from [known vendor]…”).
• Blog and news section: covered under press releases below.

Documents Hosted on the Site (and Their Metadata)

Organizations publish PDFs, spreadsheets, and slide decks: reports, brochures, price lists, manuals. These files are findable with search operators (details in Module 4):

site:companyx.com filetype:pdf
site:companyx.com filetype:xlsx OR filetype:docx OR filetype:pptx

Why documents are gold: metadata. Office documents and PDFs carry hidden metadata created by the software that made them. This can include:
- Author name and internal username (e.g., jsmith — often the network login)
- The software and version used (e.g., “Microsoft Word 2016”) — a hint at patch levels
- Internal file paths (e.g., C:\Users\jsmith\Documents\... or a network share \\FILESRV01\...)
- Printer names, email addresses, and edit history
- For images inside documents, sometimes GPS coordinates (EXIF)

Discovering the internal username format lets an attacker map email addresses to network accounts, which feeds password spraying and phishing.

Tools (used more in Module 4):
- exiftool — reads metadata from a downloaded file
- metagoofil — searches an engine for a domain’s documents, downloads them, then defers metadata extraction to tools like exiftool (installed by default in Kali)
- FOCA — a Windows GUI tool that finds documents via search engines and extracts and correlates their metadata

Defensive note: organizations should strip metadata from documents before publishing them (many tools and workflows can do this).

Job Postings: A Free Technology Inventory

Job postings are one of the highest-value organizational sources because they must be specific to attract the right candidates.

• Exact technologies: a security engineer posting might list “Splunk, CrowdStrike Falcon, Palo Alto firewalls, AWS, Okta, Terraform.” That’s a partial map of the security stack, including what to bypass.
• Versions and gaps: “migrating from on-prem Exchange to Microsoft 365” tells an attacker exactly what transition state the target is in.
• Team structure: multiple related postings reveal team size and reporting lines.
• Locations and shift patterns: on-call and shift language hints at coverage gaps.

Where to look beyond the careers page: LinkedIn Jobs, Indeed, and the applicant-tracking systems that host many companies’ boards. Recognizing these URL patterns helps you find postings and identify the ATS in use:
- Greenhouse: boards.greenhouse.io/<company> or job-boards.greenhouse.io/<company>
- Lever: jobs.lever.co/<company>
- Workday: <company>.wd1.myworkdayjobs.com (numbers vary)
- Ashby: jobs.ashbyhq.com/<company>

You can dork these too: site:boards.greenhouse.io "Company X".

Defensive balance: recruiters need enough detail to attract candidates, but “must have 3 years defending against APTs with our Cisco ASA and legacy Windows Server 2012 fleet” is a gift to attackers. Security teams should review postings.

The Site’s Own Control Files

Websites publish small standardized files that are meant for machines. Investigators read them directly.

• robots.txt (companyx.com/robots.txt): tells crawlers which paths not to index. Standardized as RFC 9309 in 2022. Because it lists paths the owner wanted hidden from search engines, it sometimes points at admin panels, staging environments, backups, or internal tools. It is not an access control; it’s a request to crawlers. Reading the current file touches the site; reading an archived copy (Module 6) stays passive.
• sitemap.xml (companyx.com/sitemap.xml): lists pages the owner wants indexed, which can still surface forgotten or bulk pages you wouldn’t find by browsing.
• security.txt (companyx.com/.well-known/security.txt): standardized as RFC 9116, this file tells security researchers how to report a vulnerability. Its required fields are a contact and an expiry date; it may also list an encryption key, policy link, and preferred languages. For a defender it’s good practice; for an investigator it’s a quick way to find the right security contact.
• humans.txt, ads.txt, and app-association files occasionally reveal vendors and staff too.

Terms of Service and Privacy Policies

These legal pages are sources and rules.

As sources:
- Privacy policies often enumerate the third-party services a company uses: analytics, advertising, payment processors, cloud providers, support chat, email senders. That’s a partial vendor map.
- Subprocessor lists (common for SaaS companies under GDPR) go further, naming every vendor that processes customer data. Security writers have noted that a public subprocessor list hands attackers a ready-made map of the target’s supply chain.
- Terms of Service describe how the product and any API are allowed to be used, which reveals what the product can do.

As rules (tie back to Module 2): the ToS tells you what you may and may not do on the platform: scraping, automation, account requirements, and API use. Read it before you start.

The subtle point — prohibitions hint at what’s possible:
Rules are usually written because something can be done, and often because someone already did it.
- “You may not use automated means to collect profile data” implies profile data can be collected at scale.
- “You may not use the API to access data beyond what’s needed to display the service” implies the API returns more than the website shows.
- “You may not use the service to determine a person’s location” implies location data exists in the system.

Developer and API documentation work the same way: they enumerate the data fields and endpoints that exist. Treat these as leads to investigate, not as proof and not as permission. Possible is not the same as permitted.

Press, Investor Relations, and Marketing

• Press releases / newsroom: product launches, acquisitions, partnerships, leadership changes, new offices, funding. Wire services (PR Newswire, Business Wire) syndicate these.
• Investor relations (for public companies): overlaps with SEC filings (see 5.7-public-records.md) but the IR site itself hosts earnings-call transcripts and investor decks full of operational detail.
• Vendor case studies: “How Company X uses [Product]” pages, published by the vendor, confirm exactly what software the target runs, straight from a source the target can’t easily edit. Search: "Company X" case study site:vendorname.com.
• Conference talks, webinars, and slide decks: engineers frequently explain internal architecture in public talks (YouTube, SlideShare, Speaker Deck). Search speaker lists and past agendas.
• Employee and engineering blogs: detailed write-ups of internal tools, migrations, and incidents. Great for defenders to audit (“did we just publish our whole architecture?”).

Putting It Together (Example)

A single afternoon on a target’s own material can yield:
- Email format from the contact page (first.last@companyx.com)
- An employee list from LinkedIn (Module 5 file 02) mapped onto that format
- The security stack from three job postings (Splunk, CrowdStrike, Okta)
- Internal usernames and a file-server name from PDF metadata
- The cloud and email providers from the privacy policy’s subprocessor list
- A staging path from robots.txt

No packet was ever sent to anything but the public website, yet an attacker now knows who to target, how their email should look, and what defenses to expect. A defender running the same pass knows exactly what to lock down.

Key Terms

• Email address format: the pattern an organization uses for addresses (e.g., flast@), guessable from one example
• Metadata: hidden data inside a file describing who made it, with what software, and where
• ATS (Applicant Tracking System): software like Greenhouse or Workday that hosts a company’s job board
• robots.txt / sitemap.xml / security.txt: standardized site files that guide crawlers and researchers
• Subprocessor list: a public list of the third-party vendors that handle a company’s customer data
• Semi-passive: collection that touches the target (e.g., loading its website) but looks like normal traffic

Key Takeaways

• Organizations leak the most about themselves on purpose (marketing, recruiting, compliance)
• One contact-page email reveals the format for the whole company
• Document metadata exposes usernames, software versions, and internal file paths
• Job postings are a technology inventory of the target
• robots.txt is not access control; it often lists paths the owner wanted hidden
• Privacy policies and subprocessor lists map the vendor supply chain
• A ToS prohibition hints that something is possible, but possible ≠ permitted

References

• RFC 9309: Robots Exclusion Protocol (RFC Editor)
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (RFC Editor)
• security.txt: A Simple File with Big Value (CISA)
• metagoofil (opsdisk, GitHub)
• FOCA (ElevenPaths, GitHub)
• Job board URL for Greenhouse-hosted job board (Greenhouse Support)
• Why Public Subprocessor Lists Are a Security Risk (Simple Trust Portal)