A contractor working with the Cybersecurity and Infrastructure Security Agency (CISA) inadvertently exposed Amazon Web Services (AWS) GovCloud credentials on a public GitHub repository. The leaked keys provided access to sensitive federal government cloud infrastructure, raising serious questions about credential management practices within agencies tasked with protecting America’s cybersecurity posture.
Introduction
In an ironic security incident that highlights the persistent challenge of insider risk and credential hygiene, a CISA contractor exposed valid AWS GovCloud access keys by committing them to a public GitHub repository. The exposed credentials granted access to federal cloud infrastructure specifically designed for sensitive government workloads, including classified information up to Impact Level 5.
This breach of operational security occurred within an organization that regularly publishes guidance on proper credential management and secure development practices. The incident underscores a fundamental truth in information security: technical controls mean nothing when human error places the keys to the kingdom in public view.
Background & Context
AWS GovCloud is Amazon’s isolated cloud region designed specifically for U.S. government agencies and contractors handling sensitive data. Unlike commercial AWS regions, GovCloud provides enhanced compliance frameworks meeting requirements for ITAR, FedRAMP High, DoD SRG Impact Levels 2-5, and CJIS security policies.
The exposed credentials were discovered by security researchers conducting routine scans of public GitHub repositories for exposed secrets. The timeline of exposure remains unclear, as GitHub commits can persist in repository history long after being removed from active branches. The contractor’s identity has not been publicly disclosed, though the repository has since been taken down.
This incident follows a concerning pattern of AWS credential exposure on GitHub. According to research from GitGuardian, over 10 million secrets were exposed on GitHub in 2022 alone, with AWS credentials representing one of the most common types of leaked secrets.
Technical Breakdown
AWS access keys consist of two components that work together for programmatic API access:
AWS_ACCESS_KEY_ID=AKIA[16 ALPHANUMERIC CHARACTERS]
AWS_SECRET_ACCESS_KEY=[40 CHARACTER BASE64-ENCODED STRING]
When committed to a public GitHub repository, these credentials become immediately discoverable through multiple vectors:
Automated Secret Scanning
Adversaries deploy continuous scanning tools that monitor GitHub’s public event stream API, detecting secrets within minutes of commitment. Tools like TruffleHog, GitRob, and commercial solutions index commits in near real-time.
GitHub Search Dorks
Manual searches using queries like filename:.env AWS_ACCESS_KEY_ID or extension:yml aws_secret_access_key reveal exposed credentials across millions of repositories.
Git History Persistence
Even after removal, credentials remain accessible in git history unless removed via git filter-branch or BFG Repo-Cleaner:
# Exposed keys persist here even after file deletion
git log --all --full-history -- "*config.yml"
The GovCloud credentials in this incident would have provided the holder with access scoped to whatever IAM permissions were attached to that access key. Depending on the role configuration, this could include:
- Read/write access to S3 buckets containing sensitive documents
- Ability to launch EC2 instances for cryptomining or lateral movement
- Access to RDS databases with citizen information
- Lambda function deployment for persistence mechanisms
- CloudTrail log manipulation to hide tracks
Impact & Risk Assessment
Immediate Access Risk
Any individual who discovered these credentials before revocation gained authenticated access to federal cloud infrastructure. GovCloud’s purpose-built nature means the stored data likely included:
- Sensitive But Unclassified (SBU) information
- Personally Identifiable Information (PII) of federal employees or citizens
- Critical infrastructure vulnerability data
- Law enforcement sensitive information
- Potentially classified material up to Secret level
Compliance Violations
The exposure potentially violates multiple federal requirements:
- FISMA (Federal Information Security Management Act) – Inadequate safeguarding of information systems
- FedRAMP – Failure to implement AC-2 (Account Management) and IA-5 (Authenticator Management) controls
- NIST SP 800-53 – Non-compliance with credential management requirements
- OMB M-22-09 – Federal Zero Trust Strategy credential protection mandates
Reputational Impact
CISA’s mission centers on improving the nation’s cybersecurity posture. A credential exposure incident within their operational sphere significantly undermines public confidence and provides ammunition for adversary information operations highlighting American cybersecurity hypocrisy.
Financial Exposure
If exploited before detection, unauthorized AWS usage could result in substantial charges through resource abuse (cryptomining, data egress, compute instance deployment). More critically, data exfiltration could lead to costs associated with breach notification, credit monitoring, and legal liability.
Risk Severity: CRITICAL
While no CVE applies to human error incidents, the risk profile aligns with critical infrastructure compromise. The window between exposure and detection creates an unknown impact period where adversary access cannot be definitively ruled out.
Vendor Response
AWS Automated Detection
Amazon Web Services operates automated secret scanning for its public GitHub repositories and has partnered with GitHub’s Secret Scanning program. However, this protection primarily covers repositories owned by AWS, not third-party users committing AWS credentials.
GitHub Secret Scanning
GitHub’s secret scanning feature, available for public repositories, detects exposed credentials from 200+ service providers including AWS. When detected, GitHub alerts the credential issuer (AWS) who can then notify the affected account owner.
GitHub’s official statement emphasizes their commitment to secret detection:
“Secret scanning automatically detects tokens and credentials checked into repositories. We partner with cloud providers to automatically revoke exposed secrets and notify account owners.”
CISA Official Response
As of this writing, CISA has not released a public statement regarding the incident. The agency’s standard protocol for credential compromise follows their own published guidance in CISA Alert AA21-148A, which ironically includes recommendations for preventing exactly this type of exposure.
AWS GovCloud Security Team
AWS security protocols dictate immediate key revocation upon detection of public exposure. The standard response includes:
Mitigations & Workarounds
Immediate Actions for Affected Organizations
1. Credential Rotation (IMMEDIATE)
Revoke compromised credentials immediately through the IAM console:
# Via AWS CLI - Deactivate compromised access key
aws iam update-access-key \
--access-key-id AKIA[REDACTED] \
--status Inactive \
--user-name [USERNAME]
# Delete the compromised key
aws iam delete-access-key \
--access-key-id AKIA[REDACTED] \
--user-name [USERNAME]
# Generate new credentials
aws iam create-access-key \
--user-name [USERNAME]
2. CloudTrail Investigation
Review all API activity associated with the exposed credentials:
# Query CloudTrail for suspicious activity
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=Username,AttributeValue=[USERNAME] \
--start-time 2024-01-01T00:00:00Z \
--max-results 1000 \
--output json > investigation.json
# Filter for high-risk events
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=Username,AttributeValue=[USERNAME] \
| jq '.Events[] | select(.EventName |
test("Delete|Put|Create|Attach|Modify"))'
3. S3 Bucket Audit
Check for unauthorized data access or exfiltration:
# Enable S3 access logging if not already active
aws s3api put-bucket-logging \
--bucket [YOUR-BUCKET] \
--bucket-logging-status \
file://logging-config.json
# Review recent access patterns
aws s3api list-objects-v2 \
--bucket [YOUR-BUCKET] \
--query 'Contents[?LastModified>=2024-01-01]'
4. Implement AWS SCPs for Prevention
Deploy Service Control Policies to prevent credential exposure damage:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:UpdateAccessKey"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"us-gov-west-1",
"us-gov-east-1"
]
}
}
}
]
}
5. Enable AWS GuardDuty for GovCloud
Activate GuardDuty threat detection:
# Enable GuardDuty in GovCloud region
aws guardduty create-detector \
--enable \
--region us-gov-west-1
# Configure alert destinations
aws guardduty create-publishing-destination \
--detector-id [DETECTOR-ID] \
--destination-type S3 \
--destination-properties \
DestinationArn=arn:aws-us-gov:s3:::security-alerts
Long-Term Prevention Controls
Pre-Commit Hooks
Implement git-secrets to prevent credential commits:
# Install git-secrets
git clone https://github.com/awslabs/git-secrets
cd git-secrets
make install
# Configure for AWS credential patterns
git secrets --install ~/.git-templates/git-secrets
git secrets --register-aws --global
# Apply to existing repository
cd /path/to/your/repo
git secrets --install
git secrets --register-aws
Environment Variable Management
Never hardcode credentials in source code:
# .gitignore - Always exclude these
.env
.env.local
*.pem
*.key
credentials.yml
secrets.json
aws-credentials
# Use environment variables instead
export AWS_ACCESS_KEY_ID=$(aws ssm get-parameter \
--name /prod/aws/access-key-id --with-decryption \
--query Parameter.Value --output text)
IAM Policy Least Privilege
Restrict credential scope to minimize blast radius:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws-us-gov:s3:::specific-bucket-only/*"
],
"Condition": {
"IpAddress": {
"aws:SourceIp": ["203.0.113.0/24"]
}
}
}
]
}
Detection & Monitoring Tips
Active Exposure Detection
Scan your repositories before attackers do:
# TruffleHog - Scan git history for secrets
docker run --rm -v /path/to/repo:/repo \
trufflesecurity/trufflehog:latest \
git file:///repo --json
# Gitleaks - Alternative scanner
gitleaks detect --source /path/to/repo \
--report-format json \
--report-path gitleaks-report.json
# git-secrets - Scan current repository
git secrets --scan-history
GitHub Advanced Security
For organizations using GitHub Enterprise:
AWS CloudTrail Monitoring
Create CloudWatch alarms for suspicious access key usage:
# Create SNS topic for alerts
aws sns create-topic --name SecurityAlerts
# Create metric filter for unusual API calls
aws logs put-metric-filter \
--log-group-name CloudTrail/DefaultLogGroup \
--filter-name UnauthorizedAPICalls \
--filter-pattern '{ ($.errorCode = "*UnauthorizedOperation") ||
($.errorCode = "AccessDenied*") }' \
--metric-transformations \
metricName=UnauthorizedAPICalls,\
metricNamespace=CloudTrailMetrics,\
metricValue=1
# Create alarm
aws cloudwatch put-metric-alarm \
--alarm-name UnauthorizedAPICallsAlarm \
--alarm-actions arn:aws:sns:us-gov-west-1:ACCOUNT:SecurityAlerts \
--metric-name UnauthorizedAPICalls \
--namespace CloudTrailMetrics \
--statistic Sum \
--period 300 \
--threshold 5 \
--comparison-operator GreaterThanThreshold
SIEM Integration
Forward CloudTrail logs to your security operations center:
# Example: Parse CloudTrail for exposed credential usage
import json
def detect_anomalous_access(event):
suspicious_indicators = [
'userAgent': ['curl', 'python-requests', 'boto3'],
'sourceIPAddress': [external_ip for external_ip
in known_external_ips],
'eventName': ['GetObject', 'PutObject', 'DeleteBucket']
]
for indicator_type, indicator_values in suspicious_indicators.items():
if event.get(indicator_type) in indicator_values:
return True
return False
Sigma Rule for Detection
Deploy this rule to SIEM platforms supporting Sigma:
title: AWS GovCloud Credential Usage from Unexpected Location
status: experimental
description: Detects AWS API calls using GovCloud credentials from non-federal IP ranges
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventSource: '*.amazonaws.com'
userIdentity.type: 'IAMUser'
filter:
sourceIPAddress|cidr:
- '198.51.100.0/24' # Replace with authorized federal IP ranges
- '203.0.113.0/24' # Replace with authorized federal IP ranges
condition: selection and not filter
falsepositives:
- Legitimate remote access from authorized contractors
- VPN endpoint changes
level: high
Best Practices & Prevention
Developer Security Training
Organizations must implement mandatory secure coding training covering:
- Credential lifecycle management
- Secret management solutions (HashiCorp Vault, AWS Secrets Manager)
- Git hygiene and .gitignore configuration
- Pre-commit hook deployment
- Incident response procedures for exposure
Secrets Management Infrastructure
Replace static credentials with dynamic secret generation:
# AWS Secrets Manager - Store and rotate credentials
aws secretsmanager create-secret \
--name prod/database/credentials \
--secret-string '{"username":"admin","password":"GENERATED"}' \
--region us-gov-west-1
# Retrieve in application code (never hardcode)
SECRET=$(aws secretsmanager get-secret-value \
--secret-id prod/database/credentials \
--query SecretString --output text)
IAM Role-Based Access
Prefer IAM roles over long-lived access keys:
# Use instance roles for EC2
aws iam create-role --role-name EC2-S3-Access \
--assume-role-policy-document file://trust-policy.json
aws iam attach-role-policy \
--role-name EC2-S3-Access \
--policy-arn arn:aws-us-gov:iam::aws:policy/AmazonS3ReadOnlyAccess
# Launch instance with role (no credentials needed in code)
aws ec2 run-instances \
--iam-instance-profile Name=EC2-S3-Access \
--image-id ami-12345678
Credential Rotation Automation
Implement automatic rotation for all access keys:
“`python
# Lambda function for automatic key rotation
import boto3
from datetime import datetime, timedelta
def rotate_access_keys(event, context):
iam = boto3.client(‘iam’)
users =