One .git Directory Away From a Cloud Compromise

Introduction

During a security assessment of a government web application, I discovered an exposed .git directory on the production server.

What initially appeared to be a source-code disclosure quickly turned into a much more serious issue.

The exposed Git repository allowed me to recover the application's source code. While reviewing the code, I discovered hardcoded AWS credentials that were still valid. Using those credentials, I was able to authenticate to the associated AWS environment and access cloud resources containing sensitive user PII.

The resulting attack chain was:

Exposed .git directory
        ↓
Source code disclosure
        ↓
Hardcoded AWS credentials
        ↓
AWS authentication
        ↓
Cloud resource access
        ↓
Sensitive PII exposure

This post walks through the discovery and impact of the vulnerability, with sensitive target-specific information redacted.

1. Discovering the Exposed .git Directory

The assessment started with the public-facing application.

I checked whether the application's Git metadata was accessible by requesting the .git directory:

https://[REDACTED-TARGET]/.git/

The server returned a 403 Forbidden response.

Although the directory contents were not directly displayed, the response confirmed that a .git directory existed on the production server.

That was enough to investigate further.

A .git directory should never be exposed on a production web server. Git metadata can contain source code, configuration, historical commits, and potentially sensitive secrets.

2. Dumping the Git Repository

To determine whether the exposed Git metadata could be reconstructed, I used git-dumper.

First, I installed the tool:

pip install git-dumper

I then used it against the redacted target:

git-dumper https://[REDACTED-TARGET]/.git/ target-source

The repository was successfully reconstructed locally.

I could now inspect the application's source code and Git history rather than simply interacting with the public-facing application.

3. Reviewing the Source Code

After dumping the repository, I moved into the recovered source:

cd target-source

I started reviewing the project structure and configuration files, paying particular attention to components related to AWS and other external services.

I also searched the source for common cloud-related keywords and credential patterns:

grep -RniE 'AWS|S3|ACCESS_KEY|SECRET_KEY|CREDENTIAL' .

The search led me to an AWS-related configuration file.

Further inspection revealed hardcoded AWS credentials.

The actual values are omitted here:

AWS_ACCESS_KEY_ID="[REDACTED]"
AWS_SECRET_ACCESS_KEY="[REDACTED]"
AWS_DEFAULT_REGION="[REDACTED]"

Finding credentials inside source code is already a serious security issue.

The next question was whether those credentials were still active.

4. Validating the Exposed Credentials

The credentials were not merely old values left behind in the repository.

They were still valid.

I used the exposed credentials to authenticate to the associated AWS environment.

For the public version of this write-up, the target-specific values have been removed:

aws configure

The credentials entered during the assessment were:

AWS Access Key ID:     [REDACTED]
AWS Secret Access Key: [REDACTED]
Default region name:   [REDACTED]
Default output format: [REDACTED]

Successful authentication confirmed that the credentials recovered from the publicly exposed source code were usable against the application's AWS environment.

At this point, the vulnerability had escalated from source-code disclosure to unauthorized cloud access.

5. Enumerating Accessible Storage

The next step was to determine what resources were accessible using the compromised credentials.

I performed limited AWS resource enumeration.

For S3, this included:

aws s3 ls

The command returned storage resources associated with the environment.

The actual bucket names are redacted:

[REDACTED-BUCKET]
[REDACTED-BUCKET]
...

The purpose of this step was to establish the permissions associated with the exposed credentials and determine whether sensitive resources were accessible.

6. Sensitive Data Exposure

The accessible cloud resources contained sensitive user information.

This was the point at which the complete impact of the vulnerability became clear.

The issue was no longer limited to source-code disclosure or credential exposure. The compromised credentials provided a path into cloud resources containing sensitive user PII.

I did not need to extensively access or extract user information to establish the impact. Confirming that the exposed credentials provided access to resources containing sensitive PII was sufficient to demonstrate the severity.

7. Why the .git Exposure Was Critical

An exposed .git directory might initially appear to be a straightforward information-disclosure issue.

The actual severity depends heavily on what exists inside the repository.

In this case, the repository contained active cloud credentials.

That created a direct relationship between the public web server and the underlying cloud infrastructure.

The progression was:

/.git/

git-dumper https://[REDACTED-TARGET]/.git/ target-source

grep -RniE 'AWS|S3|ACCESS_KEY|SECRET_KEY|CREDENTIAL' .

aws configure

aws s3 ls

Each step increased the potential impact of the original configuration mistake.

8. Business Impact

The vulnerability exposed multiple layers of the application's security architecture.

The potential impact included:

• Source code disclosure — proprietary application logic and implementation details were exposed.
• Credential compromise — active AWS credentials were present in publicly recoverable source code.
• Unauthorized cloud access — the credentials could be used to authenticate to the associated AWS environment.
• Sensitive data exposure — accessible cloud resources contained user PII.
• Further cloud compromise risk — depending on permissions, exposed credentials could potentially provide access to additional resources.
• Regulatory and reputational impact — exposure of personal information can have serious consequences for an organization handling sensitive user data.

The most significant aspect of the finding was the combination of these issues rather than any single vulnerability in isolation.

Conclusion

This assessment started with a simple observation: a production application had an exposed .git directory.

That single configuration issue provided access to the application's source code.

The source code then revealed active AWS credentials.

Those credentials provided access to cloud resources containing sensitive user information.

The important takeaway is that source-code exposure should never be considered harmless simply because the application's frontend does not expose sensitive functionality.

Source repositories can contain the keys to the infrastructure behind the application.

Don't deploy .git to production. Don't hardcode cloud credentials in source code. And once credentials are exposed, treat them as compromised and rotate them immediately.