Cloud-Security

On November 8, 2025, the SANS Internet Storm Center reported honeypot hits probing common repository and cloud-related paths, including /.git/logs/refs/remotes/origin/main, /.git/objects/info, /.github/* (such as dependabot.yml), /.gitlab/*, /.gitlab-ci, /.git-secret, /.svnignore, and cloud-y paths like /aws/bucket, /s3/backup, /s3/bucket, /s3/credentials (ISC Diary). If any of these return 200s, you may be serving source, CI config, or credentials. The rest of this post walks through a fast, repeatable response.

Intrusion Flow

• Recon and probing: Automated clients request telltale repo/CI paths such as /.git/HEAD, /.git/config, .github/*, .gitlab-ci*, .svn/*, or /s3/* looking for misdeployments (PortSwigger, GitHub Docs: dependabot.yml location, GitLab CI YAML).
• Exploitation if exposed: If /.git/ is reachable, attackers can reconstruct history via targeted downloads (e.g., /.git/HEAD, refs, objects) or off-the-shelf dumpers (arthaud/git-dumper, GitTools). Advisory sites treat exposed VCS dirs as source disclosure risks (Acunetix on .git).
• Post-exploitation: Harvest secrets embedded in history or CI files using secret scanners; leaked tokens often enable cloud pivots (Gitleaks, TruffleHog).
• Cloud angle: Attackers also test S3 naming or credential endpoints; your guardrail here is account/bucket-level S3 Block Public Access-on by default for new buckets since April 28, 2023, and recommended broadly (AWS Prescriptive Guidance, S3 BPA user guide, AWS announcement).

Key Artifacts to Pull

• Web access logs from the serving tier (reverse proxies, WAFs, app servers):
  • NGINX: confirm actual log file and format via access_log and log_format (defaults vary by distro; see NGINX module docs) (nginx log module, admin logging guide).
  • Apache HTTPD: Combined Log Format reference and locations configured via CustomLog (Apache docs).
  • IIS: W3C logs (fields like cs-uri-stem, cs-uri-query, sc-status) and log storage under W3SVC; field list in Microsoft documentation (Microsoft Learn, W3C logging fields, IIS logging overview).
• Server configs for containment validation:
  • NGINX: location ~ /\.(?!well-known) { deny all; } is a common pattern to block dotfiles while allowing ACME challenges (Bolt CMS nginx example).
  • Apache: <FilesMatch "^\."> Require all denied </FilesMatch> blocks dotfiles (Apache core / ).
• Evidence if exposure occurred:
  • Sample served files (e.g., /.git/HEAD, /.git/config, .gitlab-ci.yml) for scoping; prefer capturing over the wire evidence and hash it in your case notes.
  • HTTP status codes context: 200 means the resource was served; 403 means refused; 404 means not found (MDN 200, MDN 403, MDN 404).

Detection Notes

The goal is to quickly identify requests to risky repo/CI/cloud paths and prioritize 200s.