GBHackers

AWS GovCloud Credential Leak Leads CISA to Share Critical Cyber Incident Lessons


The Cybersecurity and Infrastructure Security Agency (CISA) has disclosed details of an internal security incident involving exposed AWS GovCloud credentials, offering a transparent account of its own incident response to help other organizations strengthen their defenses.

On Friday, May 15, CISA’s Office of the Chief Information Officer (OCIO) launched an internal investigation after an investigative reporter flagged that CISA’s AWS GovCloud keys and other sensitive data were exposed in a public repository.

The tip originated from a security researcher at a firm that continuously scans public code repositories for leaked secrets.

Independent reporting identified the exposed archive as a public GitHub repository named “Private-CISA,” maintained by an employee of contractor Nightwing, which had reportedly sat exposed since November 2025.

AWS GovCloud Credential Leak

The repository was not part of CISA’s official GitHub organization but a contractor’s personal account, containing CISA’s Infrastructure as Code and build automation scripts, along with admin and build credentials copied in to provision cloud infrastructure autonomously.

One exposed file reportedly contained administrative credentials for three AWS GovCloud servers, while another contained plaintext usernames and passwords for numerous internal CISA systems.

CISA’s OCIO moved through three response phases. In containment, the public repository was taken offline and preserved for forensic analysis, the development environment was disabled, credentials were reset, and the individual’s system access was revoked.

During scope assessment, investigators confirmed the leak came from a personal repository rather than official infrastructure, though it included live infrastructure code and credentials.

Impact analysis found no evidence the leaked credentials were used outside CISA’s environments, and no customer or mission data was exposed.

Remediation went beyond the exposed keys, as CISA rotated all credentials across every environment where the individual held admin rights, tightened allow and deny lists for its code repositories, and restricted users’ ability to push code to public repositories before restoring development systems.

CISA’s after-action review highlighted notable strengths. External reporting worked well because timely engagement by the researcher and journalist enabled rapid containment.

Zero Trust principles applied to development environments, not just production, proved critical for visibility and early detection. Strong logging maturity gave CISA’s security operations center the forensic depth needed to accurately trace the incident.

Public repository upload controls were insufficient, prompting enforcement through endpoint detection and response tooling. Secrets management in private repositories needs strengthening, as no repository should contain hardcoded credentials.

CISA lacked a dedicated cloud and GitHub incident playbook, forcing responders to build one mid-crisis. Unclear reporting channels led the researcher to try multiple contact paths, including contacting the contractor directly and using CISA’s vulnerability disclosure platform, before reaching a reporter.

The agency is now consolidating those channels and publishing contact instructions more prominently. CISA further noted that cryptographic key rotation took longer than expected due to the complexity of its interconnected systems, underscoring the importance of key agility as a foundational security practice.

By publicly detailing this incident, CISA aims to model the transparency it has long urged from other organizations. As the agency put it, cybersecurity incidents are a matter of “when,” not “if,” and open post-incident reporting builds sector-wide resilience, improves detection maturity, and strengthens trust between defenders.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.



Source link