Home
Documentation
Modernisation Platform User Guide
IAM Exposed Credential Detection and Response

IAM Exposed Credential Detection and Response

This page describes how the Modernisation Platform automatically detects and responds to exposed IAM access keys.

Overview

AWS proactively monitors public code repositories (such as GitHub) for exposed IAM access keys. When an exposed key is detected, AWS Health generates an AWS_RISK_CREDENTIALS_EXPOSED EventBridge event and applies a limited quarantine policy to the affected user.

The Modernisation Platform supplements this with an automated response pipeline that acts immediately on detection, before any manual intervention is required.

What Happens When a Key Is Exposed

When AWS detects an exposed IAM access key in a Modernisation Platform account, the following automated steps occur in sequence:

AWS Health fires an EventBridge event — an AWS_RISK_CREDENTIALS_EXPOSED event is generated and routed to a Lambda function
The exposed key is disabled — the Lambda calls iam:UpdateAccessKey to immediately set the key status to Inactive
The user is quarantined — a deny-all inline policy named EmergencyQuarantine is attached to the affected IAM user, preventing any further API calls regardless of their other permissions
An alert is raised — a PagerDuty high priority incident is created via SNS, which also posts a notification to #modernisation-platform-high-priority-alarms in Slack

The entire process is fully automated and completes within seconds of AWS detecting the exposure.

Infrastructure

The solution is deployed via the modernisation-platform-terraform-baselines module and is applied to all accounts through the secure-baselines bootstrap layer. It consists of:

An EventBridge rule matching AWS_RISK_CREDENTIALS_EXPOSED Health events
A Lambda function (iam-credential-responder) that performs the key disable and quarantine actions
An SNS topic (iam-credential-exposed-alert) that routes alerts to PagerDuty
An IAM role with the minimum permissions required to disable keys and attach quarantine policies

Responding to an Incident

When a PagerDuty incident is raised for an exposed credential, the on-call engineer should:

Identify the affected user and key from the incident details
Verify in the AWS console that the key has been disabled and the EmergencyQuarantine policy is attached
Investigate how and where the key was exposed (e.g. a public repository, a build log)
Rotate any other credentials the user may have had access to
Once the root cause is resolved, remove the EmergencyQuarantine inline policy and either delete the key or leave it inactive
Resolve the PagerDuty incident and complete a brief incident report if required

Removing a Quarantine Policy

Once an incident has been investigated and resolved, the EmergencyQuarantine policy can be removed from the affected user via the AWS CLI:

aws iam delete-user-policy \
  --user-name <username> \
  --policy-name EmergencyQuarantine

Or via the AWS console under IAM → Users → [username] → Permissions → EmergencyQuarantine → Remove.

Testing

The Lambda can be tested by invoking it directly with a synthetic event payload. Replace YOUR_KEY_ID with a real inactive key ID from the account:

aws lambda invoke \
  --function-name iam-credential-responder \
  --payload '{"account":"123456789012","detail":{"service":"IAM","eventTypeCode":"AWS_RISK_CREDENTIALS_EXPOSED","affectedEntities":[{"entityValue":"YOUR_KEY_ID"}]}}' \
  --cli-binary-format raw-in-base64-out response.json && cat response.json

Check the execution logs to confirm all steps completed successfully:

aws logs tail /aws/lambda/iam-credential-responder --follow