T1593.003: Code Repositories

Public code repositories can unintentionally publish a useful map of an organization: technologies in use, employee names, libraries, build patterns, and sometimes credentials or API keys. For leaders, the risk is not the repository itself but the downstream decisions an adversary can make from it—better phishing, account compromise, infrastructure targeting, or use of valid accounts.

Executive priority

Treat this as an exposure-management and SDLC governance issue. Executives should ask whether public repositories are inventoried, whether developer guidance covers secret handling, whether auditing can prove review of public code exposure, and whether leaked credentials can be rapidly revoked. Priority is highest where public development, cloud APIs, CI/CD, or third-party repository services are material to operations.

Technical view

T1593.003 is a reconnaissance sub-technique under Search Open Websites/Domains for the PRE platform. MITRE provides no official detection text, but a related detection strategy, DET0805 Detection of Code Repositories, is linked. SOC, IR, and detection engineering teams should validate whether they can identify organization-related public repository exposure, leaked secrets, and suspicious follow-on use of credentials or accounts. Relationship context maps use by HAFNIUM, LAPSUS$, Contagious Interview, and Shai-Hulud, so defenders should consider this behavior relevant to both social engineering and software supply chain exposure without assuming local targeting.

Likely telemetry

Public repository inventory and organization/account ownership records
Repository provider audit logs where available
Commit history, pull requests, issues, wikis, and public metadata referencing the organization
Secret scanning or exposure scanning findings for credentials, API keys, and tokens
Developer identity and access records tied to repository accounts

Detection direction

Confirm whether DET0805 or equivalent processes cover public repositories, not only private/internal code stores.
Tune monitoring for organization names, domains, employee identifiers, project names, and credential patterns in public code repositories while accounting for legitimate open-source activity.
Prioritize validation of leaked secrets by type, age, scope, and whether they remain active; avoid treating every public reference as equal risk.
Correlate repository exposure with downstream authentication, cloud API, SaaS, or CI/CD activity to determine whether reconnaissance has created an actionable access risk.
Maintain a clear distinction from T1213.003, which concerns collection from private or internally hosted code repositories.

Mitigation priorities

Implement M1013 Application Developer Guidance focused on preventing secrets and sensitive operational details from being committed to public repositories.
Use M1047 Audit to regularly review public repository exposure, repository configurations, developer activity, and evidence of remediation.
Establish a repeatable process to revoke, rotate, or scope down credentials and API keys found in public repositories.
Inventory public repositories associated with the organization and define ownership for review and takedown/remediation decisions.
Integrate repository exposure checks into SDLC, CI/CD, cloud security, and compliance evidence workflows.

Analyst notes and limits

The key decision value is whether the organization can find and remediate externally visible development artifacts before they enable phishing, account compromise, infrastructure compromise, or valid-account access. The ATT&CK relationships to named groups and software show this behavior is operationally relevant across multiple threat contexts, but local risk depends on what the organization publishes and whether exposed credentials or metadata remain usable.

Official MITRE detection guidance is not provided for this technique in the supplied fields. Telemetry and control recommendations are therefore conservative and should be validated against the organization’s actual repository providers, cloud/SaaS integrations, CI/CD design, and audit capabilities. No claim is made that any listed group or software is targeting a specific organization.

Official MITRE ATT&CK definition

Code Repositories

Adversaries may search public code repositories for information about victims that can be used during targeting. Victims may store code in repositories on various third-party websites such as GitHub, GitLab, SourceForge, and BitBucket. Users typically interact with code repositories through a web application or command-line utilities such as git.

Adversaries may search various public code repositories for various information about a victim. Public code repositories can often be a source of various general information about victims, such as commonly used programming languages and libraries as well as the names of employees. Adversaries may also identify more sensitive data, including accidentally leaked credentials or API keys.[1] Information from these sources may reveal opportunities for other forms of reconnaissance (ex: Phishing for Information), establishing operational resources (ex: Compromise Accounts or Compromise Infrastructure), and/or initial access (ex: Valid Accounts or Phishing).

**Note:** This is distinct from Code Repositories, which focuses on Collection from private and internally hosted code repositories.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 1 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1593	Search Open Websites/Domains	This object subtechnique of Search Open Websites/Domains.

Associated objects

Groups, software, and campaigns

G1052: Contagious Interview

Contagious Interview is a North Korea–aligned threat group active since 2023. The group conducts both cyberespionage and financially motivated operations, including the theft of cryptocurrency and user credentials. Contagious Interview targets Windows, Linux, and macOS systems, with a particular focus on individuals engaged in software development and cryptocurrency-related activities. [1][2][3][4][5][6][7][8]

G1004: LAPSUS$

LAPSUS$ is cyber criminal threat group that has been active since at least mid-2021. LAPSUS$ specializes in large-scale social engineering and extortion operations, including destructive attacks without the use of ransomware. The group has targeted organizations globally, including in the government, manufacturing, higher education, energy, healthcare, technology, telecommunications, and media sectors.[1][2][3]

G0125: HAFNIUM

HAFNIUM is a likely state-sponsored cyber espionage group operating out of China that has been active since at least January 2021. HAFNIUM primarily targets entities in the US across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs. HAFNIUM has targeted remote management tools and cloud software for intial access and has demonstrated an ability to quickly operationalize exploits for identified vulnerabilities in edge devices.[1][2][3]

S9008: Shai-Hulud

Shai-Hulud is a supply chain worm, first reported in September 2025, that spreads through code repositories, including GitHub and NPM packages. It exploits CI/CD pipeline dependencies to propagate to victims and poisons the supply chain by publishing malicious packages. Once inside a victim environment, Shai-Hulud steals credentials and access tokens from compromised repository accounts and exfiltrates them to attacker-controlled servers via encoded GitHub Actions workflows.[1][2][3][4][5][6][7]

LinuxSaaSWindows

Relationship explorer

All related ATT&CK context

uses · Group G1052: Contagious Interview Enterprise uses · Group G1004: LAPSUS$ Enterprise uses · Group G0125: HAFNIUM Enterprise detects · Detection Strategy DET0805: Detection of Code Repositories Enterprise uses · Malware S9008: Shai-Hulud Enterprise mitigates · Mitigation M1013: Application Developer Guidance Enterprise subtechnique of · Technique T1593: Search Open Websites/Domains Enterprise mitigates · Mitigation M1047: Audit Enterprise

Mitigations

Mitigation direction

M1013: Application Developer Guidance

Application Developer Guidance focuses on providing developers with the knowledge, tools, and best practices needed to write secure code, reduce vulnerabilities, and implement secure design principles. By integrating security throughout the software development lifecycle (SDLC), this mitigation aims to prevent the introduction of exploitable weaknesses in applications, systems, and APIs. This mitigation can be implemented through the following measures: Preventing SQL Injection (Secure Coding Practice):

- Implementation: Train developers to use parameterized queries or prepared statements instead of directly embedding user input into SQL queries. - Use Case: A web application accepts user input to search a database. By sanitizing and validating user inputs, developers can prevent attackers from injecting malicious SQL commands.

Cross-Site Scripting (XSS) Mitigation:

- Implementation: Require developers to implement output encoding for all user-generated content displayed on a web page. - Use Case: An e-commerce site allows users to leave product reviews. Properly encoding and escaping user inputs prevents malicious scripts from being executed in other users’ browsers.

Secure API Design:

- Implementation: Train developers to authenticate all API endpoints and avoid exposing sensitive information in API responses. - Use Case: A mobile banking application uses APIs for account management. By enforcing token-based authentication for every API call, developers reduce the risk of unauthorized access.

Static Code Analysis in the Build Pipeline:

- Implementation: Incorporate tools into CI/CD pipelines to automatically scan for vulnerabilities during the build process. - Use Case: A fintech company integrates static analysis tools to detect hardcoded credentials in their source code before deployment.

Threat Modeling in the Design Phase:

- Implementation: Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to assess threats during application design. - Use Case: Before launching a customer portal, a SaaS company identifies potential abuse cases, such as session hijacking, and designs mitigations like secure session management.

**Tools for Implementation**:

- Static Code Analysis Tools: Use tools that can scan for known vulnerabilities in source code. - Dynamic Application Security Testing (DAST): Use tools like Burp Suite or OWASP ZAP to simulate runtime attacks and identify vulnerabilities. - Secure Frameworks: Recommend secure-by-default frameworks (e.g., Django for Python, Spring Security for Java) that enforce security best practices.

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 1.0
Created: Aug 9, 2022, 13:01 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 249fd7dc8dceb418...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.0	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`249fd7dc8dce…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
GitHub Cloud Service Credentials

Runa A. Sandvik. (2014, January 14). Attackers Scrape GitHub For Cloud Service Credentials, Hijack Account To Mine Virtual Currency. Retrieved August 9, 2022.
Open source URL
[2]
mitre-attack T1593.003
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use

Analyst context for executives and security teams