IR Playbook: Hunting Automated Probes for Exposed Repositories and Cloud Paths

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.

• Quick grep on Linux log bundles:

grep -E '"(GET|HEAD) /(\.git|\.github|\.gitlab|\.gitlab-ci|\.svn|s3|aws)(/|$)' -n -- *.log* |
  grep -E ' 200 | 206 '  # triage the hits that served content

• Splunk examples:

index=web sourcetype=access_* (uri_path="/.git*" OR uri_path="/.github*" OR uri_path="/.gitlab*" OR uri_path="/.svn*" OR uri_path="/s3*" OR uri_path="/aws*")
| stats count by uri_path status useragent src_ip
| where status IN (200,206)

• Elastic/Lucene (adjust field names):

request:("/.git" OR "/.github" OR "/.gitlab" OR "/.gitlab-ci" OR "/.svn" OR "/s3" OR "/aws") AND (status:200 OR status:206)

• Write a Sigma rule for webserver logs (logsource category: webserver) to flag requests to repo/cloud paths and prioritize 200/206. See Sigma spec for logsources and rule structure (Sigma basics: logsources, rule creation guide).

Paths to include in your detection lists (from the honeypot observation):

• /.git/logs/refs/remotes/origin/main, /.git/objects/info, /.github/* (e.g., dependabot.yml, ISSUE_TEMPLATE/), /.gitlab/issue_templates, /.gitlab-ci, /.git-secret, /.svnignore, /aws/bucket, /s3/backup, /s3/bucket, /s3/credentials (ISC Diary, GitHub issue templates path, FUNDING.yml in .github, GitLab templates path).

Response Guidance

When the pager goes off, move in this order. We aim to keep toil low even if tooling is brittle.

1. Rapid triage

• Filter for 200/206 responses to the paths above. Treat any successful fetch of /.git/HEAD, /.git/config, .gitlab-ci.yml, .hg/*, or .svn/* as potential source disclosure (Acunetix: .git).
• If only 403s are returned, you likely blocked access; still verify server configs to prevent regressions (MDN 403).

2. Contain

• Immediately block dotfiles on your frontends:
  • NGINX: add a dotfile deny rule (keep /.well-known allowed for ACME), reload, and re-test (Bolt CMS nginx example).
  • Apache: deploy <FilesMatch "^\."> Require all denied </FilesMatch> via vhost or .htaccess and reload (Apache core docs).
• For S3, confirm S3 Block Public Access is ON at the account and bucket levels; AWS recommends enabling all four BPA settings unless a specific public use case exists (S3 BPA user guide, AWS Security Hub control S3.8).

3. Scope

• If a repo was reachable, safely acquire a copy for forensics (from evidence or a controlled re-fetch) and run secret scans. Tools: Gitleaks and TruffleHog identify common tokens and can be automated in CI (Gitleaks, TruffleHog).
• Review .git/config for embedded HTTP(S) credentials if teams used credential-in-URL patterns (a known pitfall) (TechTarget explainer).

4. Eradicate and harden

• Redeploy without VCS metadata-don’t serve .git, .hg, or .svn in web roots (PortSwigger).
• Keep dotfile denies in web server configs as a standing control (Apache core, NGINX logging/config docs for verification).
• If secrets were exposed, rotate them and, if necessary, rewrite history (git filter-repo/BFG) knowing that history rewriting does not retroactively “unleak”-rotation is mandatory (BFG cleanup guidance).

5. Monitor

• Keep a lightweight content rule or Sigma detection to alert on repo/CI/cloud path hits returning 200/206 (Sigma basics). Consider periodic external scans of your own properties for .git exposure using safe methods analogous to public tooling (do not scan others without authorization) (GitTools).

Takeaways

• Add or verify dotfile denies on all internet-facing web servers today (Apache, NGINX).
• Hunt web logs for 200s to repo/CI/cloud paths and ticket any positives (start with the list in the ISC diary) (ISC Diary).
• If exposed, capture evidence, scan for secrets, rotate credentials, and redeploy without VCS metadata (Gitleaks, TruffleHog).
• For S3, ensure Block Public Access is enforced at account and bucket levels, and route any public content through CloudFront or other controlled patterns (AWS BPA, Security Hub control).