Path & Payload

When the Lock Is Disabled: Breaking Down the CISA GovCloud Credential Exposure

A Nightwing contractor working for CISA maintained a public GitHub repository called "Private-CISA" from November 2025 until this past weekend. For six months, the respository held AWS GovCloud administrative credentials, a browser-exported CSV of plaintext passwords for dozens of internal systems, Artifactory access, and internal build documentation. Detection ultimately came from GitGuardian’s automated scanning.

The repository's contents are the headline, but the commit history is the more interesting read. Before or during the exposure, the contractor disabled GitHub's default secret-protection controls β€” including the mechanism that can block detected secrets from being pushed to public repositories, removing the earliest opportunity to stop or flag the credentials as they entered the repository. This was a deliberate configuration change, not merely a lapse in awareness, and it's where the failure chain actually starts.

This post draws on Brian Krebs's reporting published May 18, 2026, Guillaume Valadon's incident writeup published by GitGuardian on May 19, 2026, and GitGuardian's State of Secrets Sprawl 2026 report. It covers what was exposed, the behavioral pattern behind it, the attack path the credentials created, and what a 48-hour credential validity window after CISA's notification says about incident response.

The Incident

GitGuardian continuously scans public repositories for exposed secrets. On May 14, the scanner flagged a public GitHub repository named "Private-CISA." The repository was maintained by a contractor employed by Nightwing, a government contractor based in Dulles, Virginia, working for CISA.

The repository included:

The repository was created November 13, 2025. At 844 MB, it was substantial enough that GitGuardian's research team initially suspected it was a hoax β€” the directory names, file names, and contents seemed too suspicious to be genuine. But their assessment changed when analysis revealed a clear pattern of unsafe practices.

GitGuardian's Good Samaritan program had already sent nine automated emails to the commit author by May 13. None received a response. On May 14, GitGuardian filed a report through the CERT/CC portal, but with the weekend approaching and still no acknowledgment on the morning of May 15, GitGuardian contacted cybersecurity journalist Brian Krebs and activated additional partners to reach CISA directly. The repository came down that evening β€” roughly 26 hours from direct notification. The exposed AWS GovCloud keys, however, remained valid for another 48 hours after notification.

The Failure Chain

This incident is a sequence of bad decisions and gaps that compounded β€” collectively creating a fully operational attack surface that was open for six months.

Layer 1: Active Circumvention of a Default Control

ATT&CK: T1562.001 (Impair Defenses: Disable or Modify Tools)

GitHub's secret scanning is enabled by default on public repositories. It detects credentials, tokens, and keys as they're committed and alerts the account owner. The commit logs in the contractor's account show this feature was deliberately disabled.

This is the most important detail in the incident because it changes the incident's character. Most credential leaks on GitHub happen because a developer doesn't recognize the content as sensitive, or doesn't realize the repository is public, or commits a file they meant to add to .gitignore. That's a gap in awareness.

But disabling secret scanning is a gap in judgment β€” a decision to operate without a detection layer while continuing to commit sensitive material. Whatever the reasoning β€” friction reduction or alert fatigue β€” the effect was to remove the earliest detection opportunity in the chain.

Layer 2: The Scratchpad Pattern

ATT&CK: T1552.001 (Unsecured Credentials: Credentials in Files)

Philippe Caturegli of Seralys β€” whose technical analysis was provided to KrebsOnSecurity β€” assessed that the contractor used the GitHub repository to synchronize files between a work laptop and a home computer. The account's commit history shows both a CISA-associated email address and a personal email address, consistent with usage across differently configured environments.

This is a behavioral anti-pattern with a specific threat model. When a public repository functions as a file sync mechanism, the operator's mental model of what the repository contains tends to drift from what it actually contains. Files get committed without review. Exports land in working directories and get swept up in broad commits. The Firefox Passwords CSV β€” a browser password export β€” is the clearest artifact of this.

The pattern also means the exposure surface grows over time in ways that aren't actively tracked. Six months of commits to a file-sync repository accumulates significant material without anyone auditing what's there.

Layer 3: Credential Hygiene as a Systemic Signal

ATT&CK: T1110 (Brute Force), T1078 (Valid Accounts)

Many of the internal CISA credentials in the repository followed a password pattern of platform name plus current year β€” the kind of credential that constitutes a serious threat within an internal network even without external exposure, because it's the pattern threat actors test after establishing initial access and pivoting laterally.

Weak passwords in an exposed credential set that emerged from someone's routine working practice suggests the hygiene isn't isolated to what ended up in the repository. What's visible here is likely representative of a broader posture.

Layer 4: The Response Gap

ATT&CK: T1078.004 (Valid Accounts: Cloud Accounts)

After CISA was notified and the repository was taken offline, the exposed AWS GovCloud keys remained valid for 48 hours.

This is the incident response story, and it's distinct from the exposure story. A 48-hour key validity window after disclosure means anyone who harvested the AWS GovCloud credentials before the repository came down retained live, authenticated access for two more days. It also means the internal process for revoking compromised cloud credentials either doesn't prioritize GovCloud administrative keys or operates on a timeline incompatible with active-adversary assumptions.

The Attack Path That Was Open

The credential set exposed in this repository isn't a collection of isolated access points. It's a connected attack surface. Walking through what an adversary would have done with this access makes the stakes explicit.

Step 1: AWS GovCloud access (T1078.004)

Three administrative AWS GovCloud accounts were accessible with valid credentials. Authenticated cloud access from valid keys doesn't generate the same detection signatures as exploitation. An adversary typically authenticates, enumerates resources and IAM policies, identifies what the environment contains, and maps adjacent services β€” before taking any action likely to generate an alert.

Step 2: Supply chain position via Artifactory (T1195.002)

The exposed Artifactory credentials are the highest-consequence element of this exposure. Artifactory is CISA's internal repository of code packages used in software builds. Authenticated access to Artifactory means the ability to modify or replace packages in that repository. Caturegli's assessment is direct: backdoor a package in Artifactory, and every subsequent build depending on that package deploys the backdoor. This is persistent access that survives credential rotation, system rebuilds, and most conventional incident response β€” because the persistence is in the build pipeline, not in any single system.

Step 3: Lateral movement via internal credential set (T1078, T1550)

The Firefox Passwords CSV contained credentials for dozens of internal CISA systems, including what appears to be "LZ-DSO" β€” the Landing Zone DevSecOps environment. Combined with the kubeconfig exposure, an adversary with this credential set has multiple authenticated paths to move laterally within CISA's internal infrastructure without triggering exploitation-based alerts.

Step 4: Authentication persistence via Entra ID SAML certificates (T1550.001)

The Entra ID SAML certificates in the repository represent a distinct and durable attack surface. SAML certificates underpin SSO authentication β€” an adversary with access to these certificates can forge authentication assertions for any service that trusts the identity provider, bypassing credential-based controls entirely. Unlike passwords or API keys, compromised SAML certificates don't just grant access to known systems; they provide a path into any service integrated with the identity provider. Rotation requires coordination across every relying party, making this one of the harder exposures to fully remediate.

The full path from public GitHub repository to supply chain persistence in CISA's build pipeline required no exploitation, no zero-days, no novel technique β€” just a valid credential set and patience.

Technique in Focus: Credentials in Source Control β€” and Why Disabling Detection Changes the Risk Model

T1552.001: Unsecured Credentials: Credentials in Files

Credentials committed to source control is a well-documented technique. What's examined less frequently is how the presence or absence of automated detection changes the risk timeline.

With GitHub secret scanning enabled, exposure is typically brief. A committed key triggers an alert, the account owner is notified, and β€” if response is timely β€” the credential is rotated before significant harvesting occurs. GitGuardian's external scanning layer provides a second detection opportunity for cases where native scanning fails or is bypassed. This architecture is why short-lived credential exposures on GitHub are common but catastrophic outcomes are less frequent.

When native secret scanning is disabled, the first detection layer is gone. Exposure duration is no longer measured in minutes or hours β€” it's measured by how long it takes an external scanner or a human to find the repository and escalate successfully. In this case: six months.

The broader picture makes the duration less surprising. GitGuardian's State of Secrets Sprawl 2026 β€” published by the same organization that detected this exposure β€” found that 64% of credentials confirmed valid in 2022 were still unrevoked in 2026. The report describes these as "durable access paths": not short-lived mistakes but persistent entry points that organizations consistently fail to close, often because teams hesitate to rotate credentials tied to production systems.

Where Defenders Had a Window

1. Organization-level enforcement of secret scanning. GitHub's organization-level settings allow administrators to enforce secret scanning across all repositories and prevent individual users from disabling it. If repositories used for CISA work were required to live inside a CISA-controlled GitHub organization or enterprise account, CISA could have applied centralized security configurations β€” and reduced the chance that an individual contractor could disable repository-level protections. That's the window that didn't exist here.

2. Escalation paths independent of account-owner responsiveness. Escalation here required a journalist. Organizations using external credential scanning services need an explicit escalation path that doesn't depend on the flagged account owner. Triage SLAs for high-severity findings (GovCloud keys qualify) should route to a security team, not just the committing account.

3. Automated credential rotation with defined time-to-revocation targets. The 48-hour window between disclosure and key revocation is the most actionable item in this incident for cloud security teams. AWS GovCloud administrative credentials should have a rotation procedure that can execute faster than 48 hours when triggered by a disclosure event. If the process requires manual intervention at multiple stages, the timeline will expand to fill the available time. Define and test the runbook.

4. Contractor account auditing. The repository was public and actively committed to since November 2025. A routine audit of GitHub repositories and account associations tied to contractor accounts and organization-linked email addresses would have surfaced this. Contractor environments warrant the same monitoring posture as internal environments β€” and the dual personal/organizational email pattern is a specific indicator worth flagging in access reviews.

Takeaway for Defenders

For teams managing contractor security posture:

Sources

#Attack Chain Breakdowns