OSINT and Reconnaissance Guide: Measuring and Reducing Your Exposed Footprint

Most intrusions start with information the victim organisation published itself: a key in a public repository, a forgotten cloud bucket, a staff directory that makes phishing easy. Attackers collect this open source intelligence (OSINT) before they touch a single system, and MITRE ATT&CK gives it its own tactic, Reconnaissance (TA0043). This guide is about turning that lens on your own organisation: finding what you expose, measuring it, and shrinking it. It covers leaked credentials and API keys, exposed cloud and internet assets, DNS and certificate data, and the organisational information that feeds social engineering. It is written for security engineers, vulnerability management and threat intelligence teams, and for anyone scoping OSINT work inside a penetration test. It deliberately does not cover profiling or tracking individuals.

Key takeaways

• Reconnaissance is mostly passive and leaves few or no traces in your logs, so you cannot rely on detection: you have to reduce what is there to find.
• Secrets in public code are the highest-value finding because they turn reconnaissance straight into valid access; revoke and rotate first, clean history second.
• Your footprint is wider than your asset register: subdomains, certificates, storage buckets, supplier-hosted pages and contractor repositories all count.
• Organisational data is an exposure too: published role structures, email formats and help desk procedures make impersonation cheaper. Measure it at the organisational level, not by profiling people.
• Run it as a continuous programme with owners, service levels and trend metrics, not as a one-off report at the start of a penetration test.

What attacker reconnaissance looks like in ATT&CK

ATT&CK v20 lists the techniques under Reconnaissance (TA0043). Mapping your own exposure against them gives a structured inventory of what to look for and stops the exercise drifting into whatever a favourite tool happens to show.

Two points follow from this table. First, nearly every technique is passive or uses third-party data, so your SIEM will not see it. ATT&CK's answer is mitigation M1056 Pre-compromise: reduce the attack surface and make preparation harder, rather than wait to detect it. Second, the techniques most often linked to real intrusions are the ones that produce credentials or impersonation material, which is where to start.

Leaked credentials, API keys and secrets in public code

Hardcoded secrets are the most direct route from reconnaissance to access, and they are frequently non-human identity credentials: cloud access keys, CI tokens, database connection strings and AI service keys. GitGuardian, a vendor that scans public code, reports that about 23.8 million new hardcoded secrets were added to public GitHub in 2024, a 25% rise on the year before, and that 70% of secrets it found leaked in 2022 were still valid. Treat these as the vendor's figures, but the pattern matches incident history.

• Where to look: organisation repositories, personal repositories of staff and contractors that mention the organisation, gists, public package registries, public container images, paste and code formatter sites, CI logs and public issue trackers. GitHub secret scanning covers the full Git history on all branches plus issues, pull requests, Discussions, wikis and secret gists.
• Use the platform controls: on GitHub, secret scanning runs at no cost on public repositories, and push protection for users is on by default and blocks pushes containing supported secrets to public repositories. Repository-level push protection on private repositories needs GitHub Secret Protection and is off by default. Restrict who may bypass with delegated bypass, and review every bypass alert.
• Validity first: validity checks tell you whether a detected secret is still active, which is the main triage signal. GitHub's own guidance is to rotate the credential immediately, since rewriting history is slow and often unnecessary once the key is revoked.
• Contractors and suppliers: many of the worst exposures sit in repositories the organisation does not own. Contract terms should require secret scanning and prompt notice of exposure.
• Response: follow a rehearsed process: revoke, rotate, review access logs for the key's lifetime, then clean up. See the Leaked Credential Response Playbook and the Git Secret Scanning Guide.

The Toyota T-Connect key exposure shows how long this can go unnoticed: a subcontractor uploaded code containing a data server access key to a public GitHub repository in December 2017, and it stayed public until September 2022, exposing email addresses and customer numbers for up to 296,019 customers. The CISA Private-CISA GitHub leak adds two lessons: the contractor had disabled GitHub's protection against publishing secrets, and the exposed AWS keys reportedly stayed valid for about 48 hours after the repository was taken down.

Exposed cloud and internet-facing assets

The NCSC describes external attack surface management (EASM) as finding, monitoring and reducing weaknesses in internet-accessible assets from an outside viewpoint, and notes that using such a service is generally unlikely to increase your exposure because internet-facing services are scanned constantly anyway. Whether you buy a service or build your own, the asset classes are the same.

Certificate Transparency (RFC 9162, an Experimental protocol that obsoletes RFC 6962) works for defenders as well as attackers: the logs are append-only and anyone can monitor them, and the RFC explicitly expects domain holders to watch for certificates they did not expect. The same data tells you which hostnames you have announced to the world.

AWS documents that Block Public Access applies the most restrictive combination of organisation, account, bucket and access point settings, and that it does not modify existing ACLs or policies, so switching a setting off can make a previously blocked resource public again. That is a useful rollback warning for any change programme. The exposed .env files campaign and the misconfigured Git servers study show how mass scanning finds these weaknesses at scale. For the wider discipline see the Attack Surface Management Guide.

Organisational information that feeds social engineering

The NCSC phishing guidance makes reducing information available to attackers part of its first layer of defence. It advises limiting website content to what visitors need, taking particular care with details of high-profile staff because they support whaling, developing a digital footprint policy for all users, and considering what partners, contractors and suppliers reveal about you. The defensive aim is to make impersonation harder, not to watch staff.

• Measure at the organisational level: count what the organisation itself publishes (named administrators, help desk processes, tooling in job adverts, org charts, document metadata). Do not compile dossiers on individual employees: it adds privacy risk without adding defensive value.
• Job adverts: listing exact product versions, identity provider and privileged tooling tells an attacker which help desk story will sound plausible. Describe skills, not your configuration.
• Help desk and reception procedures: any published or easily elicited reset process is reconnaissance material. In the MGM Resorts breach, the attackers claimed they found an employee on LinkedIn and then called the IT help desk posing as that person; MGM has not confirmed the method. The control is strong verification, covered in the Account Recovery and Help Desk Security Guide.
• Email address format: it is rarely practical to hide, so assume it is known and rely on phishing-resistant MFA and anti-spoofing rather than secrecy.
• Breach data: check corporate domains against breach notification services that verify domain ownership, then force resets and look for password reuse. See the Password Spraying and Credential Stuffing Defence Guide.
• Staff guidance: fold digital footprint advice into awareness training, framed around protecting staff as well as the organisation. See the Security Awareness and Human Risk Management Guide.

Legal and ethical boundaries for self-assessment

• Scope to what you own or are authorised to test: passive collection of public data about your own domains is low risk; active scanning of ranges you do not control, or of supplier systems, needs written permission. See the Penetration Test Scoping Checklist.
• Do not use found credentials: a discovered key is evidence to revoke, not a door to try. Validation should use the issuing platform's own validity checks or a non-invasive, pre-agreed method.
• Personal data still counts: breach data and staff information are personal data under UK GDPR and EU GDPR even when public. Collect the minimum, store it securely, keep it short-lived and record the purpose. See the GDPR Compliance Guide for Security Teams.
• Make reporting easy for outsiders: publish a security.txt file (RFC 9116) at /.well-known/security.txt; the Contact and Expires fields are mandatory and the RFC recommends an Expires date less than a year ahead. Researchers who find your exposed keys need somewhere to send them. See the Bug Bounty and Vulnerability Disclosure Guide.

Building the programme: a phased approach

1. Define the footprint (weeks 1 to 2): list registered domains, IP ranges, cloud accounts, code hosting organisations, package namespaces and container registries, plus suppliers that host assets for you. Assign an owner to each. This seed list drives everything else.
2. Turn on built-in protections (weeks 2 to 4): secret scanning and push protection on all code hosting organisations, S3 Block Public Access (or equivalent) at organisation or account level, DMARC monitoring. Pilot on one business unit, then extend. Roll back by setting exceptions per repository or bucket rather than disabling at the top.
3. Baseline passive discovery (month 1): run a first sweep of CT logs, passive DNS, public scan data, public code and breach data. Expect many unknown assets; record each with provenance and confidence, as the NCSC EASM guidance advises, and remove false positives.
4. Triage and remediate (months 1 to 3): live secrets first, then exposed admin services and known-exploited vulnerabilities (CISA KEV), then dangling DNS and public storage, then information leakage on websites and job adverts. Track fixes in your normal ticketing workflow.
5. Add authorised active testing (month 3 onwards): scheduled external vulnerability scans and an OSINT phase in penetration tests and red team exercises, with testers given the asset seed list. Make sure the SOC can recognise the tooling's scan traffic, another NCSC point.
6. Make it continuous (ongoing): daily or weekly automated discovery, alerts to owners, monthly trend reporting, and a quarterly review of the seed list as acquisitions, rebrands and new suppliers change it.

Choosing the approach: tooling and sourcing

Small organisations get most of the value from platform-native controls, a domain and cloud account inventory, DMARC and a security.txt file. Large organisations with subsidiaries, many brands and heavy contractor use need continuous discovery, because their real footprint drifts away from the asset register every month.

Where identity fits

Much of what reconnaissance finds is identity material: human credentials in breach data and, increasingly, non-human credentials such as cloud access keys, CI tokens, OAuth client secrets and AI API keys in code, images and logs. The durable fix is to remove long-lived static secrets from places they can leak, using workload identity federation, short-lived tokens and a secrets manager, which is what NIST SP 800-53 IA-5(7) (No Embedded Unencrypted Static Authenticators) asks for. See the Secrets Management Guide.

Detection and measurement

You will rarely see passive reconnaissance, but you can see its consequences and the active parts.

• What to log and watch: secret scanning and push protection bypass alerts; cloud audit events that change public access settings (for example S3 Block Public Access changes recorded in AWS CloudTrail); new certificates for your domains in CT logs; use of known-leaked keys from unusual locations; help desk calls asking about process or staff; spikes in external scanning against new assets.
• Canary credentials: deliberately planted, monitored fake keys in places attackers search give an early signal that someone is harvesting.

Common failure patterns

• Deleting the commit instead of revoking the key: once a secret has been public it must be assumed copied, and only revocation closes it.
• Scoping only what is in the CMDB: the exposure is usually in what the CMDB does not know, such as contractor repositories, agency sites and acquired brands.
• Disabling guardrails to get work done: push protection or public access blocks switched off for a deadline and never switched back on, as in the CISA contractor case above.
• Treating OSINT as a profiling exercise: building files on employees creates a privacy liability and a sensitive dataset of its own, while organisational fixes (process, published content, MFA) do the actual risk reduction.
• Findings without owners: long PDF reports of discovered assets that no team accepts, so nothing changes between annual tests.
• Ignoring non-code leak paths: container images, CI logs, paste sites and code formatter links leak as many secrets as repositories; see the Docker Hub secrets leak.

Framework mapping

Practitioner checklist

• Maintain a seed list of domains, IP ranges, cloud accounts, code organisations, registries and supplier-hosted assets, each with an owner.
• Enable secret scanning and push protection on every code hosting organisation, and restrict bypass to named reviewers.
• Enforce public access blocks for cloud storage at organisation or account level, with documented exceptions.
• Monitor Certificate Transparency logs and passive DNS for your domains, and remove dangling records on decommission.
• Rehearse revoke-and-rotate for leaked keys and measure time to revocation.
• Review websites, job adverts and help desk content for information that helps impersonation, and adopt a digital footprint policy.
• Check corporate domains against breach data and enforce resets for exposed accounts.
• Publish and maintain security.txt with a working contact and an Expires date under a year away.
• Put contractor and supplier exposure duties, including secret scanning, into contracts.
• Report the six metrics monthly and feed findings into penetration test and red team scoping.

Standards and references

• MITRE ATT&CK: Reconnaissance (TA0043)
• NCSC: Phishing attacks: defending your organisation
• NCSC: External attack surface management buyer's guide
• GitHub Docs: About secret scanning
• AWS: Blocking public access to your Amazon S3 storage
• IETF: RFC 9162 Certificate Transparency Version 2.0
• IETF: RFC 9116 A File Format to Aid in Security Vulnerability Disclosure
• OWASP: Web Security Testing Guide, Information Gathering

Related NHI Mgmt Group resources: Attack Surface Management Guide · Git Secret Scanning Guide · Penetration Testing Guide · Social Engineering and Physical Penetration Testing Guide · Phishing Guide