---
name: reduce-osint-exposure
description: "Reducing and monitoring the organization's open-source-intelligence footprint so an attacker's free reconnaissance stops feeding initial access (MITRE ATT&CK TA0043: T1589.001, T1589.002, T1589.003, T1591, T1593.001, T1593.003, T1596, T1594, T1597.002, feeding T1078, T1110.004, T1566). Signals live in GitHub org audit logs and secret-scanning alerts, Entra ID AADUserRiskEvents and SigninLogs, Okta System Log, HIBP domain breach data, and canarytoken alerts. Gives the defender's method for shrinking leaked data, exposed services, and the employee footprint, plus hunts and framework-mapped hardening. Use when reducing your OSINT attack surface, hunting for leaked credentials or secrets in public code, responding to a breach-dump exposure of employee accounts, cutting the employee social and email footprint, or asking 'what can an attacker learn about us for free'."
---

# Reduce OSINT Exposure - Defensive Methodology

> **Tier 2 - methodology skill.** No bespoke UMBRASEC detection rule ships with this skill yet. It gives the defender's method, the log sources and signals, and the hardening, and points to public rule sources. Promotion to Tier 1 (a sourced, tuned UMBRASEC rule) is tracked in [COVERAGE.md](https://github.com/umbrasec-labs/umbra-blue/blob/main/COVERAGE.md). Do not treat the content below as citing a UMBRASEC rule; there is none for this threat yet.

## What it looks like, defender view

Reconnaissance is the one tactic that mostly happens off your systems: an attacker queries GitHub, breach-dump markets, LinkedIn, Shodan, and certificate-transparency logs, and almost none of it touches infrastructure you log. So the defender's job is not to "catch the recon" in real time; it is to shrink what is findable and to instrument the few places where harvested data comes back as an action against you. Three footprints matter here. Leaked data: API keys, tokens, and connection strings committed to public code, plus employee credentials sold in breach dumps. Exposed services: internet-facing hosts and versions an attacker enumerates for free (that leg is owned by the sibling skill [monitor-external-attack-surface](../monitor-external-attack-surface/SKILL.md); cross-reference it rather than duplicate it). Employee footprint: names, roles, email patterns, and over-sharing on social media that fuel spear-phishing and password guesses. The detectable moment is almost always the pivot: a leaked key used, a dumped password replayed, a decoy credential touched.

## Log sources and signals

- **GitHub (and GitLab/Bitbucket) org telemetry.** Org **audit log** events and **secret-scanning alerts** are the primary signal for leaked secrets. Watch audit-log actions `secret_scanning_alert.create`, `repo.create`/`repo.access` (public), `protected_branch.*`, and **push-protection** bypass events (`secret_scanning_push_protection.bypass`). A real-time scanner (GitHub secret scanning with push protection, or CI running Gitleaks / TruffleHog) is the control that stops the leak before it is public; the alert stream is what you monitor. Normal: zero public secret-scanning alerts on org repos. Anomaly: any alert, especially on a repo that recently flipped to public.
- **Identity provider sign-in and risk logs.** For Entra ID, the `AADUserRiskEvents` table with `RiskEventType == "leakedCredentials"` is Microsoft Identity Protection reporting your users' credentials found in a public or dark-web dump, the single strongest built-in OSINT-exposure signal. Pair it with `SigninLogs`: bursts of `ResultType` 50126 (invalid username or password) across many accounts from few IPs is password spraying (T1110.003) or credential stuffing (T1110.004) feeding on harvested emails and dump passwords; `RiskLevelDuringSignIn` and `RiskState` carry Identity Protection's verdict. For Okta, the **System Log** `eventType` values `user.session.start` with `outcome.result == FAILURE`, `security.threat.detected`, and `user.account.lock` cover the same stuffing pattern. For AWS, CloudTrail `ConsoleLogin` with `errorMessage "Failed authentication"`.
- **Breach-exposure feeds.** Have I Been Pwned **domain search** (`breacheddomain` / `breachedaccount`) lists which of your mailboxes appear in which breach. This is public intelligence about your own exposure; fold it into the identity picture above so a dump hit becomes a forced-reset ticket, not a footnote.
- **Victim-owned web and DNS logs.** Webserver access logs and DNS query logs show scraping of your public site and staff directory (T1594) and data-broker crawlers; watch for scraper user agents and high-rate directory enumeration from a single `c-ip`.
- **Canarytoken / honeytoken alerts.** A decoy AWS key, decoy document, or decoy credential seeded in a public-looking repo or paste fires only when someone who harvested it tries to use it. Any hit is near-binary evidence that your leaked-data surface was collected and acted on.

## Detection approach

There is no single alert for "we were OSINT'd", so layer sources and alert on the pivot, not the search.

- **Leaked secrets.** Enable GitHub secret scanning with push protection org-wide and alert on every `secret_scanning_alert.create` and every push-protection bypass; run Gitleaks or TruffleHog in CI as a second layer for providers GitHub does not cover. The maintained [SigmaHQ GitHub audit rules](https://github.com/SigmaHQ/sigma/tree/master/rules/application/github/audit) already carry the matching analytics: `github_push_protection_bypass_detected.yml`, `github_push_protection_disabled.yml`, `github_secret_scanning_feature_disabled.yml`, and `github_pages_site_changed_to_public.yml`. Treat any alert as credential-compromised: rotate first, investigate second, because the window between public commit and automated harvesting is minutes.
- **Dumped credentials.** Alert on `AADUserRiskEvents` `leakedCredentials` and force a reset for each named user. Detect the replay with password-spray / credential-stuffing logic over `SigninLogs` 50126 bursts and the Okta `user.session.start` FAILURE pattern. Do not invent a rule here; the public SigmaHQ rules cover it. The maintained [Azure Identity Protection rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure/identity_protection) include `azure_identity_protection_leaked_credentials.yml` and `azure_identity_protection_impossible_travel.yml`, the [Azure sign-in-log rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure/signin_logs) carry conditional-access and failure analytics, and the [Okta identity rules](https://github.com/SigmaHQ/sigma/tree/master/rules/identity/okta) cover token, admin, and session abuse. A tuned UMBRASEC rule is not yet shipped for this threat.
- **Harvest tripwire.** Seed decoy credentials and documents (canarytokens) where a harvester would find them. This converts a fuzzy "are we being collected" question into a binary alarm, the same deception principle the Kerberoasting honeypot SPN uses, applied to your public footprint.

## Threat hunt

Hypothesis: our leaked data and employee footprint are already collected, and the first use will look like legitimate access. Hunt the pivot, not the search.

1. **Enumerate your own leak surface.** List org members' public repos and public gists, and personal repos pushing commits authored from a corporate email. Search public code for your internal hostnames, cloud account IDs, and token prefixes (for example `AKIA`, `ghp_`, `xoxb-`, `-----BEGIN`). Every hit is a candidate leak to rotate and remove, not just from the current HEAD but from history.
2. **Reconcile breach dumps to active accounts.** Pull the HIBP domain list, join it to your identity directory, and flag any breached mailbox whose password was not reset after the breach date. Rank by privilege: a dumped credential for an admin or a service mailbox outranks any volume signal.
3. **Hunt the replay.** In `SigninLogs` / Okta System Log over 90 days, look for `ResultType` 50126 (or Okta `outcome.result FAILURE`) spread thin across many usernames from few source IPs or ASNs, then a single success from the same origin. That shape is harvested-email-plus-dump-password stuffing landing. Cross-check successes against the HIBP list from step 2.
4. **Map the human footprint.** Identify the staff whose role, email, and social presence make them the obvious spear-phishing and voice-phishing targets (finance, IT admins, executives, new hires). Confirm those accounts carry phishing-resistant MFA and that your inbound mail controls flag display-name spoofing of harvested executive names.
5. **Verify the tripwires.** Confirm each seeded canarytoken still exists where a harvester would reach it and that its alert path works; a silent, expired decoy is a blind spot.

## Hardening

Shrink what is findable, then close the gap between a public exposure and your response. Mappings follow the control codes used in the UMBRASEC [security foundations guide](https://umbrasec.dev/guide/foundation.html), [identity and access guide](https://umbrasec.dev/guide/identity-and-access.html), [governance and maturity guide](https://umbrasec.dev/guide/governance-and-maturity.html), and [detection and response guide](https://umbrasec.dev/guide/detection-and-response.html); D3FEND countermeasures are added where one maps. A cell is left `-` where nothing maps cleanly. Data classification and DLP (keeping secrets and sensitive data out of code and public shares in the first place) belong here too but are carried in prose, because the guide does not ground a single control code for them.

| Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 | MITRE D3FEND |
|---|---|---|---|---|---|
| Keep an external asset and footprint inventory | Know every internet-facing host, public repo, and corporate-branded account, so an exposure can be matched to something you own and retired | Assumed prerequisite (know what you own) | A.5.9 Inventory of assets | ID.AM Asset Management | D3-AI Asset Inventory |
| Secret scanning, rotation, and short-lived credentials | Catch and revoke leaked keys fast, and prefer tokens that expire so a harvested secret is stale before it is used | - | A.5.17 Authentication information | PR.AA-01 Identities and credentials | - |
| Breach-exposure monitoring and forced reset | Reconcile HIBP and Identity Protection leaked-credential hits to accounts and force a reset so a dumped password is dead on arrival | - | A.5.7 Threat intelligence | ID.RA; GV.RM Risk strategy | - |
| Security-awareness training on footprint and phishing | Reduce over-sharing and raise resistance to the spear-phishing and vishing that harvested employee data enables | - | A.6.3 Awareness | PR.AT Awareness and Training | - |
| Supplier and third-party exposure review | Account for data and credentials leaked through vendors, contractors, and acquired subsidiaries, which an attacker aggregates against you | Beyond E8 | A.5.19-5.22 Supplier relationships | GV.SC Supply chain | - |
| Seed decoy credentials and public releases | Plant honeytokens where harvesters look, so collection and use of your leaked footprint raises a near-zero-false-positive alarm | - | A.8.16 Monitoring activities | DE.CM Continuous monitoring | D3-DUC Decoy User Credential; D3-DPR Decoy Public Release |

## Honest limitations

Most reconnaissance is invisible to you by design: it runs against GitHub, breach markets, social platforms, and third-party scanners you do not control, so you will see the pivot, not the search, and sometimes not even that. You cannot un-leak data; once a secret is public, assume it is collected and rotate rather than delete. `AADUserRiskEvents` leaked-credentials detection requires Entra ID P2 licensing and only reports dumps Microsoft has ingested, so a fresh or niche breach will not appear; HIBP has the same ingestion lag. Secret scanning covers known provider token formats, so a bespoke or encoded secret can still slip public. Canarytokens catch only harvesters who take the bait and act, not a patient collector who reads and waits. MITRE D3FEND maps few Reconnaissance (TA0043) techniques precisely for exactly this reason, so the D3FEND cells above are deliberately sparse and honest. Baseline every source before you alert on it, and treat the footprint inventory as the detection it really is.

## ATT&CK and D3FEND

- MITRE ATT&CK (Reconnaissance, [TA0043](https://attack.mitre.org/tactics/TA0043/)): [T1589 Gather Victim Identity Information](https://attack.mitre.org/techniques/T1589/) (incl. [.001 Credentials](https://attack.mitre.org/techniques/T1589/001/), [.002 Email Addresses](https://attack.mitre.org/techniques/T1589/002/), [.003 Employee Names](https://attack.mitre.org/techniques/T1589/003/)); [T1591 Gather Victim Org Information](https://attack.mitre.org/techniques/T1591/); [T1593 Search Open Websites/Domains](https://attack.mitre.org/techniques/T1593/) (incl. [.001 Social Media](https://attack.mitre.org/techniques/T1593/001/), [.003 Code Repositories](https://attack.mitre.org/techniques/T1593/003/)); [T1596 Search Open Technical Databases](https://attack.mitre.org/techniques/T1596/); [T1594 Search Victim-Owned Websites](https://attack.mitre.org/techniques/T1594/); [T1597.002 Purchase Technical Data](https://attack.mitre.org/techniques/T1597/002/). Leads to [T1078 Valid Accounts](https://attack.mitre.org/techniques/T1078/), [T1110.004 Credential Stuffing](https://attack.mitre.org/techniques/T1110/004/), and [T1566 Phishing](https://attack.mitre.org/techniques/T1566/).
- MITRE D3FEND: [D3-AI Asset Inventory](https://d3fend.mitre.org/technique/d3f:AssetInventory/), [D3-DUC Decoy User Credential](https://d3fend.mitre.org/technique/d3f:DecoyUserCredential/), [D3-DPR Decoy Public Release](https://d3fend.mitre.org/technique/d3f:DecoyPublicRelease/). D3FEND's coverage of the Reconnaissance tactic is thin because the activity happens off your systems.
- Related UMBRASEC skill: [monitor-external-attack-surface](../monitor-external-attack-surface/SKILL.md) for the exposed-services leg (Shodan/Censys/CT and CISA KEV).
- Public rule sources (SigmaHQ): [Azure Identity Protection](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure/identity_protection), [Azure sign-in logs](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure/signin_logs), [Okta identity](https://github.com/SigmaHQ/sigma/tree/master/rules/identity/okta), and [GitHub audit](https://github.com/SigmaHQ/sigma/tree/master/rules/application/github/audit).
- Vendor references: [Microsoft Entra ID Protection risk detections](https://learn.microsoft.com/entra/id-protection/concept-identity-protection-risks); [GitHub secret scanning](https://docs.github.com/code-security/secret-scanning/about-secret-scanning) and push protection; [Have I Been Pwned domain search](https://haveibeenpwned.com/DomainSearch).

**Scope note.** This is a defensive skill. It explains open-source reconnaissance only to the depth needed to reduce exposure, detect the pivot, and mitigate it, and deliberately ships no collection, enumeration, or harvesting tooling. UMBRASEC publishes defense, not offense.