28,000 Exposed Git Repositories Reveal API Keys, Bank Details and Employee Disciplinary Files

Blog WriterCybersecurity News - Original News Source is cybersecuritynews.com

Spread the love

A routine development mistake has exposed thousands of software repositories. Researchers found 28,000 publicly reachable .git repositories containing credentials, financial information and internal employee records that could give criminals a direct route into cloud accounts and business systems.

This is not a malware campaign in the usual sense. The risk begins when a web server accidentally leaves its hidden Git directory reachable, allowing automated scanners to retrieve code and earlier versions of files.

A leaked secret can then be used for data theft, payment fraud, phishing or malicious code changes. Intruder analysts identified the exposure while examining internet-facing systems at scale.

Intruder said in a report shared with Cyber Security News (CSN) that it tested 3.5 million live hosts and found a problem that can persist long after a developer believes a credential has been removed.

The findings add weight to recent reporting on publicly leaked AWS credentials, where old cloud keys remained usable years after exposure.

In this case, the danger is especially broad because repository history can preserve secrets, configuration data and documents across deleted branches and past commits.

28,000 Exposed Git Repositories

The researchers began with 40 million likely targets drawn from Certificate Transparency data, narrowing the set to hosts running an HTTP service before checking for exposed repositories.

They developed gitreaper to inspect repository history in memory, without downloading every complete project. That history matters. Removing a password or key from the newest version of a project does not erase the earlier commit that contained it.

AWS key (Source – Intruder)

Git metadata, branch pointers and logs can lead a visitor back to old content, a weakness also seen in the CISA public GitHub exposure involving cloud credentials and infrastructure code.

The scan recovered more than 400 AWS access keys, 107 Stripe API keys, 123 OpenAI API keys, 80 Telegram tokens and 17 GitHub personal access tokens. Some remained active during testing, meaning an intruder could potentially enter the linked environment.

One hardcoded AWS key gave access to a bucket holding internal employment documents, including attendance records and disciplinary files.

Such material can help criminals make fraudulent messages appear credible, target individual staff, or pressure an organization with a threat of disclosure. A separate key, committed in a configuration file, exposed payout and transaction history through a payment service.

The accessible data included revenue figures, payout schedules and partial bank-account details. Depending on permissions, a valid payment key could also be abused to issue refunds, view customer information or redirect payouts.

Old Commits Turn Small Errors Into Incidents

The report shows why exposed Git directories should be treated as an urgent security incident, not a minor web-server error.

Attackers increasingly automate the search for secrets; previous research has shown automated credential hunting bots locating exposed AWS credentials within minutes of public disclosure.

Organizations should immediately remove public access to .git directories, determine whether the repository was copied, and rotate every credential found in current and historical commits.

Stripe API keys (Source - Intruder)
Stripe API keys (Source – Intruder)

Revoking only the visible key is not enough if related tokens, passwords or deployment secrets were also stored in the project.

Teams should review cloud activity and payment logs for suspicious use, restrict each credential to the minimum access it needs, and move secrets into a managed vault or environment-based system.

Regular checks for exposed environment configuration files can catch a related route to cloud-account takeover before criminals do.

Developers also need controls before code reaches production. Secret scanning in commits, block rules for private files, and a deployment check that denies access to .git paths can prevent repeat exposure.

Repository history should be cleaned where possible, but teams must still assume any previously public secret was copied and replace it.

Intruder reported that it responsibly notified owners it could identify. Several affected repositories were removed and several organizations rotated the flagged credentials.

The broader lesson is straightforward: a hidden development folder is not harmless when it is exposed online, because it can become a searchable archive of access to the organization behind it.

Indicators of compromise (IoCs):-

Type Indicator Description
Exposed Git file path HEAD Git file used to identify the currently checked-out branch and a potential starting point for retrieving repository history.
Exposed Git file path packed-refs Git reference file that can expose branch and tag pointers.
Exposed Git file path objects/info/packs Git manifest path that can identify packed repository objects available for retrieval.
Exposed sensitive file .env Environment configuration file referenced in the research as containing previously committed AWS credentials.

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC

The post 28,000 Exposed Git Repositories Reveal API Keys, Bank Details and Employee Disciplinary Files appeared first on Cyber Security News.