Adversaries may search freely available websites and domains for information about victims. MITRE lists this under Reconnaissance with platform PRE, last modified in May 2026. Sources include social media, news sites, and sites that carry hiring or contract information.
Three sub-techniques sit under it: social media, search engines, and code repositories.
How attackers use it
MITRE says adversaries choose the sites depending on what they want to find. What they gather can lead to more reconnaissance, such as phishing for information or searching open technical databases. It can also lead to setting up or compromising accounts and to initial access through external remote services or phishing.
Most of this research is passive. The attacker reads what you or others published.
The three sub-techniques cover three kinds of site. Social media is about people, search engines are about indexed content, and code repositories are about what developers publish. The first is the hardest to control and the last is the easiest to audit.
MITRE's two mitigations both concern code. That is a hint about where defenders have the most influence: the developer workflow.
How to detect it
MITRE notes that this activity may have a very high occurrence and false positive rate, and may take place outside your visibility, which makes detection difficult. Its advice is to focus on related stages of the adversary lifecycle, such as initial access.
There is no log to read for a search engine query. The detection opportunity is your own exposure: search for your company as an outsider would and see what is there.
Make external search a routine. Pick a handful of queries about your company and review the results every quarter. Record what you found and what you removed.
A related point: search results change. A page removed today can still appear in a cache or an archive, so check again after a few weeks.
How to reduce the risk
- MITRE lists two mitigations for this technique. The first is Audit: scan public code repositories for exposed credentials or other sensitive information before making commits, and ensure that leaked credentials are removed from the commit history and not just the latest version. The second is Application Developer Guidance: developers uploading to public repositories should take care not to publish credentials and API keys.
- Beyond those, mITRE says this technique cannot be easily mitigated with preventive controls, because it is based on behaviors performed outside the scope of enterprise defenses and controls. Its guidance is to minimize the amount and sensitivity of data available to external parties.
- Search for your own company, staff, and products on search engines and social platforms every quarter.
- Review hiring posts and contract announcements for detail on internal tools and systems.
- Ask staff to be careful about what they share about internal work.
Share the results with the teams that publish: marketing, recruiting, and engineering. Most exposure is created by people who had no idea it mattered.
Check your own environment
- What does a search for our company name and our staff show?
- What do our job postings reveal about internal tools?
- Have we checked public code hosting for our organization name?
- Who owns the response when something sensitive is found?
Quick check
Which mitigations does MITRE list for T1593?
Audit, which means scanning public repositories for exposed credentials before committing, and application developer guidance to avoid publishing credentials and API keys.
Why is detection hard?
Most of the research is passive and happens on third party sites, outside your logs.
Sources
- MITRE ATT&CK, Search Open Websites/Domains (T1593): https://attack.mitre.org/techniques/T1593
