Most misconfiguration breaches involving non-human identities need no exploit at all: a web server serves a .git or .env file, a database answers without a password, or a signed link grants more than anyone intended, and the machine credentials inside are simply read. This guide takes the misconfiguration cases in the NHI Mgmt Group breach database and draws out the four exposure types that keep recurring, why each one leaks credentials rather than just data, and the checks that find them before an internet-wide scanner does. It is written for cloud, platform and application security teams and for anyone who owns secrets scanning or external attack surface. Each case links to its full breach analysis; the value here is the shared pattern and the controls.
Key takeaways
- Misconfiguration is a major route in. NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026) counts 32 breaches whose route was misconfiguration, 8 of them AI-related.
- Four shapes repeat. Exposed .git and .env files, databases and data services with no authentication, over-permissive share links and signed URLs, and management interfaces open to the internet.
- The real loss is the credential, not the file. Git remote URLs carry tokens, .env files carry database and SMTP passwords, logs carry API keys, and each one opens another system.
- Attackers scan, so exposure time is short. EmeraldWhale and TeamTNT found their targets by mass scanning; assume any public misconfiguration is found within days.
- Prevention is cheap and testable. Deploy build artefacts not working copies, deny hidden paths at every hostname, require authentication on every data service, scope and expire every signed link, and scan your own footprint the way attackers do.
What the breach data shows
The State of NHI & AI Agent Breach Report 2026 records 32 breaches with misconfiguration as the route in, and 8 of the AI-related breaches came the same way. The report maps this route to Posture Management, with the controls "Find exposed .git and .env files, open databases and over-permissive share links; one identity per environment." Misconfiguration also feeds the report's leaked secret figures: a credential left in a served file is both a misconfiguration and a leaked secret, which is how several cases below are classified.
The four exposure types
| Exposure type | What leaks | Cases | Root cause |
|---|---|---|---|
| Served .git and .env files | Git remote URLs with embedded tokens, database, SMTP, Redis and cloud credentials | Indian Government (2021), EmeraldWhale (2024), Misconfigured Git Servers (2026) | Working copies deployed to web roots; hidden paths not denied on every hostname |
| Open databases and data services | API keys in logs, agent tokens, user data | DeepSeek (2025), Moltbook (2026) | No authentication, or a client-side key with no row-level authorisation |
| Over-permissive share links and signed URLs | Whole storage accounts, including workstation backups with passwords and keys | Microsoft SAS token (2023) | Account-level SAS with full control and a 2051 expiry, published in a public repository |
| Exposed management interfaces and over-scoped workload roles | Cloud credential files on hosts, instance role credentials | TeamTNT (2020), Capital One (2019) | Docker APIs open to the internet; a misconfigured firewall whose role could read S3 |
Lesson 1: deployed working copies are credential stores
Sakura Samurai's research into Indian government sites found 10 exposed .git directories and 23 exposed .env files, yielding 35 credential pairs for databases, SMTP, Redis, SMS services and WordPress, plus five private keys. EmeraldWhale, reported by Sysdig, scanned for served .git/config and Laravel .env files and collected more than 15,000 cloud service credentials. In February 2026 the Mysterium VPN team counted 4,964,815 IP addresses serving .git directories, about 5% of them with deployment credentials in .git/config; those figures are the researchers' own and the method was not published.
Three causes explain almost all of it:
- Deploying the repository, not the build: a git clone or folder copy into the web root carries .git, .env and sometimes shell history.
- Tokens in remote URLs: https://user:token@host remotes write the token into .git/config. Use a credential helper, SSH deploy keys or short-lived tokens instead.
- Partial blocking: a deny rule on the main virtual host does not cover the raw IP, alternate hostnames or a new CDN origin. The 2026 study notes protections often covered only the main domain.
See the Git Secret Scanning Guide for finding what is already in history.
Lesson 2: an open data service exposes the platform's own keys
Wiz found DeepSeek's ClickHouse database on ports 8123 and 9000 with no authentication, and a log_stream table of more than one million entries containing chat history and API keys. At Moltbook, the Supabase publishable key was in client-side JavaScript, as designed, but Row Level Security was not configured, so anyone could read and write every table, including about 1.5 million agent API tokens. Both teams fixed the issue within hours of disclosure, but the exposure window before discovery is unknown.
- Logs are a secret store: request logs, error traces and debug tables pick up keys. Redact at the logger, not later.
- Backend-as-a-service needs authorisation per table: with Supabase or Firebase, the public key is not the control; RLS or security rules are. Test as an anonymous user before launch. See the Supabase Keys Security Guide and Firebase Security Rules Guide.
- Store hashes of issued API keys: Moltbook's tokens were readable because they were stored as usable values.
Lesson 3: a signed link is a credential with its own scope and lifetime
The Microsoft AI research repository linked to an account-level SAS token with full control. It was committed in July 2020 with a 2021 expiry, then extended to 6 October 2051, and exposed about 38TB including workstation backups with passwords and secret keys. Microsoft's secret scanning had flagged the URL and marked it as a false positive. The lesson generalises to S3 presigned URLs, Google Cloud signed URLs and "anyone with the link" sharing in SaaS.
| Sharing option | Revocable without rotating keys | Audit trail | When to use |
|---|---|---|---|
| Azure account SAS | No, only by rotating the account key | Azure Storage does not track generated SAS tokens | Avoid for external sharing |
| Azure service SAS with stored access policy | Yes, by changing the policy | Policy visible on the container | Scoped sharing of a container |
| Azure user delegation SAS | Ad hoc, so plan short expiry; authorised through Entra ID, so the signing identity can be disabled | Tied to an Entra identity | Microsoft's recommended type where supported |
| Dedicated public storage account, read-only | Not applicable | Normal storage logs | Publishing public data such as models |
See the Cloud Storage Exposure Playbook for the response when one is found.
Lesson 4: exposed control planes hand over the host's identity
TeamTNT mass-scanned for Docker APIs with no access control, started containers on them and copied the AWS CLI credential files from users' .aws folders; 119 systems were listed on its mining pool page, including Kubernetes clusters and Jenkins servers. At Capital One, a misconfigured web application firewall in AWS gave an attacker temporary credentials for its IAM role, which could list and sync S3 buckets for about 106 million people. In both, the host's identity was worth more than the host.
- Keep management APIs private: Docker, Kubernetes dashboards, Jenkins and database admin consoles belong behind a private network or an identity-aware proxy.
- No static keys on servers: use instance roles and workload identity so there is no file to steal.
- Require IMDSv2 and scope roles: see the EC2 Instance Metadata Service Hardening Guide.
- One identity per environment: the report's control. A firewall role should not read customer data buckets.
How to find your own exposures first
- Build the external inventory. List every public hostname, raw IP and CDN origin from DNS, cloud accounts and certificate transparency. Misconfigurations live on the hosts nobody listed. See the Attack Surface Management Guide.
- Probe for hidden paths. Request /.git/HEAD, /.git/config, /.env and common backup names on every host and IP. A 200 response with content is a finding; treat any credential in it as compromised.
- Check data services. Scan cloud accounts for databases, search clusters and caches with public endpoints, and test each as an unauthenticated client. For Supabase and Firebase, run the anonymous read and write test per table.
- Inventory signed links and public sharing. Use cloud posture checks for public buckets and account SAS usage, and SaaS admin reports for "anyone with the link" shares on sensitive drives. See the Prowler and Cloud Posture Scanning Guide.
- Revoke, rotate, then review logs. For every exposed credential, revoke first, rotate everything in the same file, and review provider logs for use during the exposure window.
- Fix the pipeline, not just the host. Change the deployment to ship build artefacts, add deny rules to the base web server or CDN configuration, and add a pipeline test that fails if hidden files reach the artefact.
- Re-test continuously. Run the external probe on a schedule and on every new hostname.
Prevention controls by layer
| Layer | Control | Stops |
|---|---|---|
| Build and deploy | Ship artefacts only; exclude dotfiles in packaging; no credentials in Git remote URLs | .git and .env exposure |
| Web server and CDN | Deny hidden paths (for example nginx location ~ /\. deny all) on every server block, IP and origin | .git and .env exposure |
| Data services | Authentication required; private endpoints; RLS or security rules on every table | Open databases |
| Logging | Redact keys and tokens at the logger; restrict log store access | Secrets in logs |
| Storage sharing | No account SAS externally; short expiry; read-only; dedicated public accounts | Over-permissive links |
| Hosts and workloads | Private management APIs; workload identity instead of static keys; IMDSv2 | Exposed control planes |
| Detection | Secret scanning with careful triage; canary credentials in likely leak locations | Late discovery |
Decision guidance
- Small teams: start with the external probe for hidden paths and the anonymous database test; both take an afternoon and cover the commonest cases in the database.
- Large estates: use cloud posture management for public resources and attack surface management for unknown hosts, and route findings to owners with a deadline. See the Secrets Management Guide for moving what you find into a vault.
- Public data: where you must publish data or models, use a separate storage account with nothing else in it, rather than a scoped link into a shared one.
Detection and measurement
- What to log: web server requests for /.git/ and /.env paths (scanners announce themselves), unauthenticated queries on data services, storage access via SAS or presigned URLs, and cloud API calls from credentials found in exposed files.
- What to alert on: new IAM users or access keys and unusual email-sending activity, which EmeraldWhale's toolset attempted with stolen AWS keys; ListBuckets from unusual identities, which is how Sysdig found that operation.
Metrics:
- Number of public hosts and IPs returning content for hidden paths (target zero).
- Percentage of data services with authentication and private endpoints.
- Count of account-level SAS tokens or public links on sensitive storage, and their maximum expiry.
- Time from exposure detection to revocation of every credential in the exposed file.
- Percentage of servers with no static cloud keys on disk.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK | T1595 Active Scanning; T1552.001 Credentials In Files; T1552.005 Cloud Instance Metadata API | Mass scanning for exposed files and services; credentials taken from files and metadata |
| MITRE ATT&CK | T1530 Data from Cloud Storage; T1496 Resource Hijacking | Bulk storage access (Capital One, SAS); cryptomining (TeamTNT) |
| NIST CSF 2.0 | PR.PS-01, ID.AM-02, ID.RA-01, PR.DS-01 | Configuration management, inventory, finding weaknesses, protecting data at rest |
| NIST SP 800-53 Rev 5 | CM-6, CM-7, CM-8, SC-7, IA-5, RA-5 | Secure settings, least functionality, component inventory, boundary protection, authenticator management, scanning |
| CIS Controls v8.1 | Control 4 Secure Configuration; Control 3 Data Protection | Hardened configuration and data access control |
Common failure patterns
- Rotating one credential from an exposed file: every secret in it is compromised. The Internet Archive breach shows what unrotated keys cost after an exposure.
- Marking a scanner hit as a false positive without checking: Microsoft's scanner had flagged the SAS URL.
- Blocking hidden paths on one hostname only.
- Trusting the public key of a backend-as-a-service instead of its authorisation rules.
- Extending a link's expiry to keep it working, as happened with the 2051 SAS token.
Practitioner checklist
- Probe every public host and IP for /.git/ and /.env, and alert on any hit.
- Change deployments to ship build artefacts with dotfiles excluded.
- Remove credentials from Git remote URLs across build servers and web hosts.
- Require authentication and private endpoints on every database and search cluster.
- Test Supabase RLS and Firebase rules as an anonymous user before each release.
- Ban account-level SAS for external sharing and cap signed link expiry.
- Close internet-facing Docker, Kubernetes and admin consoles.
- Replace static keys on servers with workload identity; require IMDSv2.
- Revoke and rotate every credential in any exposed file, then review its use.
Standards and references
- NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)
- Microsoft Learn: Grant limited access to Azure Storage resources using shared access signatures
- Supabase: Row Level Security
- MITRE ATT&CK: T1552.001 Credentials In Files
- MITRE ATT&CK: T1595 Active Scanning
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- CIS: Critical Security Controls v8.1
Related NHI Mgmt Group resources: the Secrets Management Guide, the Cloud Storage Exposure Playbook, the Developer Secret Scanning Triage guide and the Attack Surface Management Guide.