Most of what an adversary needs to plan a phishing lure, impersonate a supplier or find a working credential is already indexed by public search engines, social networks and code hosting sites. MITRE ATT&CK T1593 Search Open Websites/Domains covers adversaries searching freely available websites and domains for victim information they can use during targeting. It sits in the Reconnaissance tactic (TA0043), applies to the PRE platform, and has three sub-techniques in ATT&CK v20: T1593.001 Social Media, T1593.002 Search Engines and T1593.003 Code Repositories. The searching happens on third-party sites, so you will not see it in your logs; the defensive job is exposure reduction, plus fast reaction when something sensitive turns up. This guide is for threat intelligence, detection engineering, application security and identity teams. Bulk extraction from your own sites is a different technique (T1594), and the broad self-assessment programme is in the OSINT and Reconnaissance Guide; this page stays on the ATT&CK technique view: recorded cases, what ATT&CK says about detection and mitigation, and how to test your exposure.
Key takeaways
- You cannot see the search, only its results. ATT&CK's detection strategies for T1593 and each sub-technique state that the activity takes place largely outside the target's visibility with a very high false positive rate, so effort goes on what is findable and on the follow-on stages.
- Public code is the highest-risk source. ATT&CK records LAPSUS$, HAFNIUM (Silk Typhoon) and ShinyHunters searching public repositories for credentials, and the only mitigations it maps at technique level are M1047 Audit and M1013 Application Developer Guidance.
- Removal is not revocation. ATT&CK's M1047 guidance is to remove leaked credentials from the commit history, not just the latest version; in practice the credential must also be rotated, because forks and caches outlive the clean-up.
- Staff profiles fuel social engineering. Lazarus Group (Operation Dream Job), Kimsuky, EXOTIC LILY and Contagious Interview all used social media to identify, monitor or impersonate people, which turns role and team detail into pretexts.
- Search your own footprint on a schedule. Run the same kinds of searches an adversary would, for credentials, internal hostnames, document leaks and high-value staff, and track findings to closure.
What T1593 covers
ATT&CK describes T1593 as searching freely available websites and domains, such as social media, news sites and sites about business operations like hiring or contract awards. The results feed further reconnaissance (T1598 Phishing for Information, T1596 Search Open Technical Databases), resource development (T1585 Establish Accounts, T1586 Compromise Accounts) and initial access (T1133 External Remote Services, T1566 Phishing, T1078 Valid Accounts).
| ID | Name | What the adversary looks for | Typical follow-on |
|---|---|---|---|
| T1593 | Search Open Websites/Domains | Victim information on any public site: news, hiring, contract awards, partner pages | T1598, T1566, T1133 |
| T1593.001 | Social Media | Business announcements, staff roles, locations and interests; fake profiles or groups to elicit more | T1598.001 Spearphishing Service, T1566.003 Spearphishing via Service |
| T1593.002 | Search Engines | General victim information and specialised queries (file types, keywords) for leaked network details or credentials | T1078, T1566, T1586 |
| T1593.003 | Code Repositories | Languages and libraries in use, employee names, accidentally leaked credentials and API keys | T1078, T1584 Compromise Infrastructure, T1598 |
ATT&CK notes that T1593.003 is distinct from T1213.003 Code Repositories, which covers collection from private and internally hosted repositories after access is gained. Information that comes from your own websites belongs to T1594 Search Victim-Owned Websites, and domain, certificate and scan data belongs to T1596 Search Open Technical Databases.
How adversaries use it: recorded cases
The procedure examples below come from ATT&CK v20 and the reports it cites. Attribution is as stated by those sources.
| Actor or software | ATT&CK ID | Recorded behaviour |
|---|---|---|
| LAPSUS$ | G1004, T1593.003 | Searched public code repositories for exposed credentials. Microsoft's DEV-0537 analysis says the group searched GitLab and GitHub for high-privilege account credentials and gathered detail on employees, team structures, help desks and supply chain relationships to make help desk calls convincing. |
| HAFNIUM (Silk Typhoon) | G0125, T1593.003 | Microsoft reported in March 2025 that the group leveraged leaked corporate passwords on public repositories such as GitHub to sign in to a corporate account. |
| ShinyHunters | G1057, T1593.003 | Searched target companies' GitHub repositories for login credentials or API keys. |
| Shai-Hulud | S9008, T1593.003 | Malware with the ability to search open sites and code repositories for compromised credentials. |
| Volt Typhoon | G1017, T1593 | CISA advisory AA24-038A describes web searches, including victim-owned sites, for host, identity and network information, especially on key network and IT administrators. |
| APT41 DUST campaign | C0040, T1593.002 | Mandiant observed APT41 using search engines in visiting victims' reachable servers before intrusion. |
| Lazarus Group, Operation Dream Job | C0022, T1593.001 | Used LinkedIn to identify and target employees within a chosen organisation. |
| Kimsuky | G0094, T1593.001 and T1593.002 | Used Twitter to monitor potential victims and prepare targeted phishing emails; searched Google for vulnerabilities, tools and geopolitical trends. |
| EXOTIC LILY | G1011, T1593.001 | Google's Threat Analysis Group describes the group impersonating real employees from November 2021 by copying details from social media and business databases, then sending spear-phishing under a business proposal pretext. |
| Sandworm Team | G0034, T1593 | Researched Ukraine's EDRPOU legal entity identifier, including queries on the EDRPOU website, before NotPetya. |
A defender-side example: the Toyota T-Connect key exposure began when a subcontractor published part of a website's source code to a public GitHub repository in December 2017, including an access key to a data server holding customer records. The key stayed public for almost five years, and Toyota could not determine whether anyone had used it. Exactly this kind of finding is what T1593.003 searching is designed to harvest.
What is findable about you
Treat T1593 as an inventory of what a stranger can learn in an afternoon. The table pairs each source with the information that matters and the control that reduces its value. These are NHI Mgmt Group recommendations built on ATT&CK's mitigations.
| Source | High-value information | Why it matters | Exposure control |
|---|---|---|---|
| Public code hosting (GitHub, GitLab, Bitbucket, gists) | API keys, cloud access keys, tokens, connection strings, internal hostnames, CI configuration | Direct, MFA-free access through T1078 | Push protection, secret scanning of public and supplier code, short-lived credentials |
| Package registries and public containers | Embedded secrets, build paths, internal package names | Credentials and dependency confusion targets | Scan artefacts before publishing, separate publishing tokens |
| Search engine indexes | Exposed documents, error pages with stack traces, login portals, cached pages | Network detail and entry points | Remove and de-index, fix the source, authenticate staging sites |
| Professional social networks | Who runs IT, identity, finance and the help desk; tools listed as skills; new joiners | Targets and pretexts for T1598 and help desk fraud | Guidance for high-risk roles, help desk verification that ignores public facts |
| Job adverts and tenders | Technology stack, product versions, project names, suppliers | Shapes exploit choice and supplier impersonation | Describe skills, not versions or internal names |
| News, filings and partner pages | Mergers, new suppliers, office moves, incident statements | Timely lures (invoice change, onboarding, IT migration) | Brief finance and help desk on current events that will be used as pretexts |
Where identity fits
The most damaging T1593 finding is usually a non-human credential: a cloud access key, personal access token, webhook URL or database password committed to a public repository by an employee, contractor or supplier. Unlike a human password, it is rarely behind MFA, may have broad scope, and often has no owner watching for misuse. GitHub's own documentation states that partner pattern scanning runs by default on public repositories and public npm packages and alerts the service provider, who may revoke the secret; that helps for supported token types but is not a substitute for your own monitoring and rotation. Give every machine credential an owner, a scope and a maximum age, prefer federated short-lived credentials in CI/CD, and treat any public exposure as a compromise. See the Git Secret Scanning Guide and the Leaked Secret Validation Detection guide.
What to detect and where
ATT&CK v20 publishes detection strategies DET0856 (T1593), DET0812 (T1593.001), DET0811 (T1593.002) and DET0805 (T1593.003). Each analytic says much of the activity may have a very high occurrence and false positive rate, may take place outside the target organisation's visibility, and that detection should focus on related stages such as initial access. That leaves three useful signal groups.
| Signal | Source | Response |
|---|---|---|
| Your secret pattern found in public code or a paste site | Secret scanning on your organisation and supplier repositories, external code search monitoring | Revoke and rotate first, then clean history and review the credential's audit logs for use |
| Provider revocation notice for a token | Email or webhook from a cloud or SaaS provider after partner scanning | Treat as an incident: find where it leaked and what it touched |
| Leaked credential used | Cloud audit logs, identity provider sign-ins, API gateway logs: use from new ASNs or hosting providers, unusual API calls such as identity enumeration | Contain the identity, hunt for persistence |
| Fake profile or group impersonating staff or the company | Brand and social media monitoring, staff reports | Report to the platform, warn affected roles |
| Phishing or vishing using accurate role or project detail | Email security, help desk call records, user reports | Flag as a probable T1593 outcome; check what is public about the targeted team |
| Sensitive document indexed by a search engine | Scheduled self-searches, alerting services | Remove at source, request de-indexing, assess what it disclosed |
Mitigations
ATT&CK v20 maps three mitigations to this technique family: M1047 Audit and M1013 Application Developer Guidance for T1593 and T1593.003, and M1056 Pre-compromise for T1593.001 and T1593.002. M1047 advises scanning public code repositories for exposed credentials or other sensitive information before committing, and removing leaked credentials from the commit history, not only the latest version. M1013 tells developers uploading to public repositories to avoid publishing credentials and API keys. M1056 says the technique cannot be easily mitigated with preventive controls and effort should focus on minimising the amount and sensitivity of data available to external parties. The steps below are NHI Mgmt Group recommendations that put those into practice.
- Block secrets before they leave: turn on repository-level push protection and secret scanning across all organisations you control. GitHub documents that repository push protection is off by default and that, by default, anyone with write access can bypass a block by choosing a reason; restrict bypass with delegated bypass and review every bypass alert. See How to enable GitHub secret scanning push protection.
- Rotate, then rewrite: when a secret is found in public code, revoke it immediately. History rewriting comes second, because clones, forks and caches may already hold it.
- Cover suppliers: require contractors who write code for you to scan for secrets and to keep your credentials out of public repositories, as the Toyota case shows.
- Shorten credential life: replace static cloud keys in pipelines with workload identity federation so a leaked value expires quickly.
- Trim public detail: keep version numbers, internal hostnames and project code names out of job adverts, conference talks and public documentation.
- Prepare people who will be targeted: give administrators, finance staff and executive assistants specific guidance on what not to post, and make help desk verification rely on things that are not public.
How to test your exposure
- Scope and authorise: write down the domains, brand names, organisation accounts and staff groups in scope, and get sign-off from legal and HR before searching social media about employees. Search only; do not log in with anything you find.
- Code search: search public code hosts for your domains, internal hostnames, unique token prefixes and product names, including personal accounts of staff and known suppliers.
- Search engines: run file-type and keyword queries against your domains for documents, configuration files, error pages and login portals; record each URL found.
- Social and hiring: list what can be learned about IT, identity and help desk staff, and what job adverts reveal about your stack.
- Validate safely: for each credential found, ask its owner to check whether it is live through the provider's own console or audit log, then revoke it regardless.
- Repeat and compare: run the exercise quarterly and after major announcements; trend the counts. Feed results into red team planning and phishing simulations that use realistic public detail.
Measuring it
- Time to revoke: median hours from a public secret finding to revocation (target under four hours for production credentials).
- Push protection coverage: percentage of repositories with push protection enabled, and the number of bypasses per month with a reviewed reason.
- Public secret findings: count per quarter from self-searches and provider notices, split by employee, contractor and supplier source.
- Static credential share: proportion of CI/CD and application credentials that are long-lived rather than federated.
- Indexed sensitive documents: number found per exercise and time to removal.
Common failure patterns
- Deleting the file, keeping the key: a commit that removes a secret leaves it in history and in every clone; only revocation closes the exposure.
- Watching only your own organisation: secrets leak through personal repositories, forks and supplier code that your organisation-level scanning never sees.
- Bypass as routine: push protection is enabled but developers routinely choose "false positive" and nobody reviews the alerts.
- Treating social media as an HR matter: nobody connects detailed public role information with help desk fraud until an attacker impersonates an administrator.
- One-off OSINT: a single exposure review is run before an audit and never repeated, while new repositories, adverts and documents appear every week.
Framework mapping
| Framework | Reference | Relevance to T1593 |
|---|---|---|
| MITRE ATT&CK v20 | T1593, T1593.001, T1593.002, T1593.003; M1047, M1013, M1056; DET0856, DET0812, DET0811, DET0805 | Technique definition, mitigations and detection strategies |
| NIST CSF 2.0 | ID.RA-02, ID.RA-03, PR.AA-01 | Receiving threat intelligence, identifying external threats, managing credentials |
| NIST SP 800-53 Rev 5 | PM-16 Threat Awareness Program, IA-5 Authenticator Management, SA-15 Development Process, Standards, and Tools, RA-10 Threat Hunting | Intelligence programme, credential protection and lifetime, developer controls, hunting for use of leaked data |
| ISO/IEC 27001:2022 Annex A | A.5.7 Threat intelligence, A.8.28 Secure coding | Collecting threat information, keeping secrets out of code |
Related reconnaissance techniques: T1591 Gather Victim Org Information (see T1591 Gather Victim Org Information Defensive Guide) and T1597 Search Closed Sources (see T1597 Search Closed Sources Defensive Guide). The tactic overview is the ATT&CK Reconnaissance Tactic (TA0043) Guide. Sibling pages: MITRE ATT&CK T1594 Search Victim-Owned Websites and MITRE ATT&CK T1596 Search Open Technical Databases. The ATLAS mirror is AML.T0116 Autonomous Reconnaissance. Reconnaissance against AI systems is covered in MITRE ATLAS AI Reconnaissance and Resource Development.
Practitioner checklist
- Push protection and secret scanning are on for every organisation and repository you control, with bypasses reviewed.
- Public code hosts are searched for your domains, hostnames and token prefixes at least quarterly, including staff and supplier accounts.
- A public secret finding triggers revocation first and history clean-up second, with audit log review for use.
- CI/CD pipelines use federated short-lived credentials where the platform supports them.
- Supplier contracts require secret scanning and forbid your credentials in public repositories.
- Job adverts and public documents avoid internal hostnames, versions and project code names.
- High-risk roles get guidance on public profiles, and help desk verification does not rely on public facts.
- Findings, time to revoke and trends are reported to the security leadership each quarter.
Standards and references
- MITRE ATT&CK: T1593 Search Open Websites/Domains
- MITRE ATT&CK: T1593.003 Code Repositories
- MITRE ATT&CK: M1047 Audit
- CISA: AA24-038A PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure
- Microsoft Security: Silk Typhoon targeting IT supply chain
- Microsoft Security: DEV-0537 criminal actor targeting organizations for data exfiltration and destruction
- GitHub Docs: About push protection
- Google Cloud (Mandiant): APT41 Has Arisen From the DUST
Related NHI Mgmt Group resources: OSINT and Reconnaissance Guide, Web Scraping Defence Guide, Executive Protection and Digital Footprint Guide, How to respond to a GitHub secret scanning alert.