From a Single .git Directory to Full AWS Compromise

A Real-World Case Study on How Small Misconfigurations Lead to Cloud Takeover

In this article, I'll walk through one of my recent security finding that demonstrates how a seemingly low-risk misconfiguration — an exposed .git directory—can escalate into a full AWS cloud compromise, including leaked credentials, unrestricted S3 bucket access, and excessive IAM permissions.

This is not a theoretical scenario. This is a real-world chain that started with a single mistake and ended with complete control over critical cloud resources.

The Initial Finding: Exposed `.git` Directory

During routine reconnaissance on a publicly accessible web application, I discovered that the .git directory was accessible over HTTP.

https://target.com/dir/.git/

https://target.com/dir/.git/

This immediately raised red flags. An exposed .git directory often allows attackers to reconstruct the entire source code repository, including commit history, configuration files, and sensitive secrets.

Using Gitdumper, I was able to retrieve:

Full application source code
Commit history
Configuration and environment files
Developer notes and commented secrets

At this stage, the issue may appear to be "just source code exposure", but the real impact was only beginning.

Full Git Repository Dump

Once the .git directory was dumped and reconstructed locally, the repository revealed multiple critical files such as:

Application configuration files
CI/CD references
Cloud-related scripts
Hardcoded credentials

One of the commits contained AWS Access Key ID and Secret Access Key (AK/SK) that were still valid.

This is a common but dangerous mistake — assuming that old credentials committed to Git are no longer usable.

These credentials were tested using AWS CLI — and they worked.

At this point, the vulnerability escalated from information disclosure to cloud account compromise.

Impact Validation: Access to AWS Account

Using the leaked credentials, I was able to:

Authenticate successfully to AWS
Enumerate AWS services
List IAM permissions

The IAM policy attached to the compromised credentials was overly permissive, which made the situation significantly worse.

S3 Bucket: Full Read & Write Access

One of the most critical findings was unrestricted access to Amazon S3.

The compromised credentials allowed:

Listing all S3 buckets
Downloading sensitive data
Uploading and overwriting objects
Deleting bucket contents

This included:

Application backups
Logs
Internal files
Potential customer or production data.
User data including PII, Credit card details, mail conversation backups etc.

At this point, an attacker could:

Exfiltrate sensitive data
Modify hosted content
Inject malicious payloads
Permanently destroy data

CVSS Perspective: Scope Change Matters

From a vulnerability scoring perspective, this is important:

The vulnerable component is the web application
The impacted component is AWS cloud infrastructure
Credentials allow access beyond the original trust boundary

This clearly qualifies as a Scope Changed vulnerability under CVSS v3.1, significantly increasing the severity score.

Proposed CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

10.0 — Critical

Why Each Metric Applies

Attack Vector (AV:N — Network) The .git directory was accessible over the internet without any internal access.
Attack Complexity (AC:L — Low) No special conditions were required. Public access + standard Git dumping tools were sufficient.
Privileges Required (PR:N — None) The attacker did not need authentication to access .git or extract credentials.
User Interaction (UI:N — None) No user action (clicks, uploads, approvals) was required.
Scope (S:C — Changed) The vulnerability originated in a web application, but the impact extended to AWS cloud infrastructure, breaking the original security boundary.
Confidentiality Impact (C:H — High) Full source code disclosure and access to sensitive S3 bucket data.
Integrity Impact (I:H — High) Ability to modify or delete S3 objects, inject malicious content, or alter infrastructure state.
Availability Impact (A:H — High) Potential deletion of buckets, data loss, or service disruption.

Final Thoughts

This finding is a textbook example of how small misconfigurations cascade into catastrophic breaches.

An exposed .git directory is not a low-impact bug. When combined with poor secret management and excessive cloud permissions, it can lead to total infrastructure compromise.

Security is not about fixing individual bugs in isolation — it's about understanding how attackers chain them together.

Contents