How to Audit AWS Secrets Manager for Security Weaknesses

Cloud security assessments often begin with enumeration—a critical process that helps security professionals identify exposed secrets, misconfigured permissions, and potential attack vectors. AWS Secrets Manager, designed to securely store and manage sensitive credentials, can become a weak point if access controls are improperly configured. In this hands-on guide, we explore how attackers use AWS CLI commands to inspect user permissions, list secrets, and extract hidden payloads during a simulated red team engagement.

Understanding the Scope of Secrets Manager Enumeration

Enumeration in cloud environments is less about exploitation and more about discovery. During a red team assessment, attackers first determine the identity and permissions of their current access keys. This initial phase reveals whether the compromised credentials grant visibility into Secrets Manager or other critical AWS services.

For example, an attacker with access to a set of AWS keys can invoke the Security Token Service (STS) to confirm their identity and account context. The following command returns key details about the authenticated user:

aws sts get-caller-identity --profile SecretsManagerEnum

A sample response might look like this:

{
  "UserId": "AIDAQGYBPW3JHDS5K4A75",
  "Account": "014498641618",
  "Arn": "arn:aws:iam::014498641618:user/Julie"
}

This output confirms that the access keys belong to an IAM user named Julie in an AWS account with the numeric identifier 014498641618. The next step involves mapping out what Julie is permitted to do within the environment.

Assessing Permissions: Mapping Out Attack Surface

Once the identity is confirmed, attackers analyze the user's permission policies to identify exploitable gaps. AWS Identity and Access Management (IAM) policies define what actions a user or role can perform. In Julie’s case, an inline policy named AllowReadSecretsManager grants specific permissions related to Secrets Manager.

The command to list attached policies for a user is straightforward:

aws iam list-user-policies --user-name julie --profile SecretsManagerEnum

After identifying the policy, the attacker retrieves its contents to understand the exact permissions:

aws iam get-user-policy --user-name julie --policy-name AllowReadSecretsManager --profile SecretsManagerEnum

The policy document reveals three key permission blocks:

• AllowIAMActions: Permits read-only access to IAM resources, enabling the enumeration of other users, roles, and policies.
• AllowListSecrets: Grants the ability to list all secrets across the AWS account, regardless of resource path.
• AllowSecretsManagerActions: Restricts secret value extraction to only two specific secret types: those prefixed with sm-enumerate-password and sm-enumerate-api-key.

This granular control highlights a common misconfiguration: overly permissive policies that allow listing secrets without restricting access to their values. Such gaps can be leveraged by attackers to discover and exfiltrate sensitive data.

Discovering and Extracting Secrets

With the right permissions in place, attackers can now list all available secrets in the targeted AWS region. The following command queries Secrets Manager for stored secrets:

aws secretsmanager list-secrets --profile SecretsManagerEnum

The response identifies two secrets that match the allowed prefixes:

• sm-enumerate-password
• sm-enumerate-api-key

These secret names suggest that they contain credentials or API keys, which are high-value targets for attackers. To extract the actual values, the attacker uses the get-secret-value command for each secret:

aws secretsmanager get-secret-value --secret-id sm-enumerate-password --profile SecretsManagerEnum

The response includes the secret in JSON format:

{
  "ARN": "arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-password-cSojGz",
  "Name": "sm-enumerate-password",
  "SecretString": "{\"password\":\"cybr-labs-are-super-fun-2211\"}"
}

Similarly, the API key secret is retrieved:

aws secretsmanager get-secret-value --secret-id sm-enumerate-api-key --profile SecretsManagerEnum

Its response reveals a Base64-encoded payload:

{
  "ARN": "arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-api-key-zShLNz",
  "Name": "sm-enumerate-api-key",
  "SecretString": "{\"secret-api-key\":\"Y3lici1sYWJzLWZha2UtYXBpLWtleS0xMTIy\"}"
}

Decoding the Hidden Payload

The extracted API key is encoded in Base64, a common encoding scheme used to obfuscate sensitive strings. To reveal the actual value, the attacker decodes it using a local Linux terminal:

echo "Y3lici1sYWJzLWZha2UtYXBpLWtleS0xMTIy" | base64 -d

The decoded output is:

cybr-labs-fake-api-key-1122

While this example simulates a Capture the Flag (CTF) challenge, real-world scenarios often involve highly sensitive credentials, API tokens, or database connection strings. Misconfigured Secrets Manager instances can expose entire infrastructures to compromise, making proper access controls and regular audits essential.

Strengthening AWS Secrets Manager Against Enumeration

Enumeration is a double-edged sword—it can be used defensively as well as offensively. Organizations should proactively audit their Secrets Manager configurations to prevent unauthorized access. Key recommendations include:

• Restricting the secretsmanager:ListSecrets permission to specific paths or roles to limit visibility.
• Implementing least privilege access for secret retrieval, ensuring only necessary users or services can access sensitive values.
• Enabling AWS CloudTrail logging to monitor and alert on Secrets Manager API calls.
• Regularly reviewing IAM policies and secret usage to identify and remove outdated or overly permissive rules.

By adopting these practices, security teams can significantly reduce the risk of secrets enumeration leading to data breaches or unauthorized system access.