Proper handling of sensitive information, such as passwords and API keys, is a crucial responsibility for any organization and cybersecurity professional using cloud services for their business operations. To keep your cloud secrets secure, it is a good security practice to use cloud secrets management tools, such as AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, Kubernetes Secrets, and HashiCorp Vault. These tools help you manage secrets properly and protect your data and systems from unauthorized access and breaches.
However, these repositories are prime targets for adversaries who exploit vulnerabilities to gain unauthorized access and achieve their malicious objectives. In this blog, we will examine these techniques, understand how attackers exploit vulnerabilities in cloud secret repositories, and discuss what organizations and cyber-defenders can do to protect against such threats.
This blog aims to explore the “Cloud Secrets Management Stores” sub-technique (T1555.006) of the MITRE ATT&CK Cloud Matrix for Enterprise. This sub-technique is part of the broader Credentials from Password Stores technique (T1555), which focuses on how adversaries obtain credentials from Cloud Secrets Management Repositories. This technique falls under the Credential Access tactic, which encompasses methods attackers use to steal credentials and gain unauthorised access to systems and data.
Image showing technique (T1555) under Credential Access tactics
Cloud secret repositories, such as AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, Kubernetes Secrets, and HashiCorp Vault, ensure the secure centralised management of passwords, API keys, and other credential materials. By using secrets managers, cloud services in AWS, Azure, and GCP such as Amazon S3, Azure SQL Database, and Google Compute Engine can dynamically acquire credentials via API requests instead of accessing secrets stored insecurely in plain text files or environment variables. These secret repositories enhance cloud security by preventing unauthorised access and reducing the risk of data breaches.
However, when an attacker manages to break into an organisation’s cloud environment and gain sufficient privileges, such as accessing high-privileged cloud accounts or compromising a service with permissions to retrieve secrets, the attacker can request secrets from the secrets repositories. The Attackers can then use these commands to carry out their malicious activities:
get-secret-value
command, when executed on AWS CLI, retrieves the value of a secret from AWS Secrets Manager.$ aws secretsmanager get-secret-value --secret-id ExampleSecret
{
"ARN": "arn:aws:secretsmanager:us-west-2:123456789012:secret:ExampleSecret-1234",
"Name": "ExampleSecret",
"VersionId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE",
"SecretString": "{\\"username\\":\\"AdminUser\\",\\"password\\":\\"@d!m1Pass123!\\"}",
"VersionStages": [
"AWSCURRENT"
],
"CreatedDate": 1.678345600000E9
}
gcloud secrets
when executed on gcloud CLI, retrieves the value of a secret from GCP Secrets Manager.$ gcloud secrets versions access latest --secret="ExampleSecret"
{
"name": "projects/123456789012/secrets/ExampleSecret/versions/1",
"payload": {
"data": "eyJ1c2VybmFtZSI6ImV4YW1wbGVVc2VyIiwicGFzc3dvcmQiOiJleGFtcGxlUGFzczEyMyEifQ=="
},
"createTime": "2023-05-01T12:34:56.789Z"
}
az key vault secret show
when executed on Azure CLI, retrieves the value of a secret from Azure Key Vault.$ az keyvault secret show --name ExampleSecret --vault-name ExampleVault
{
"attributes": {
"enabled": true,
"created": "2023-05-01T12:34:56+00:00",
"updated": "2023-05-01T12:34:56+00:00",
"recoveryLevel": "Recoverable+Purgeable",
"expires": null,
"notBefore": null
},
"contentType": null,
"id": "<https://examplevault.vault.azure.net/secrets/ExampleSecret/1234567890abcdef>",
"kid": null,
"managed": null,
"tags": {},
"value": "{\\"username\\":\\"AdminUser\\",\\"password\\":\\"@d!m1Pass123!\\"}"
}
In one of Permiso's threat research blogs titled “LUCR-3: SCATTERED SPIDER GETTING SAAS-Y IN THE CLOUD,” it was observed that the LUCR-3 (Scattered Spider) APT group compromises Identity Providers (IDPs) such as Okta, Azure AD, and Ping Identity. These IDPs can be linked to secrets management repositories like AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager. The attackers' goal is to steal intellectual property (IP), code signing certificates, and customer data for extortion. They bypass multi-factor authentication (MFA) through techniques like SIM swapping and social engineering. Once inside, they use the victim's own SaaS tools to navigate and exfiltrate sensitive information without raising alarms.
LUCR-3 (Scattered Spider) - Attack Chain workFlow
According to the Sysdig Threat Research Team blog titled “SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto,” the primary objective of the SCARLETEEL APT group is to steal AWS credentials to exploit the victim’s AWS environment further. They use various scripts to steal credentials, employing different techniques and exfiltration endpoints and also an older version of one the script can be found on GitHub.
In InverseCos blog post on “Detection and Compromise: Azure Key Vaults & Secrets”, it was highlighted that threat actors abuse certain permissions in Azure Key Vault. These three key permissions include accessing secrets in cleartext, modifying access policies to grant read permissions to another malicious account, and creating new secrets or keys for further attacks.
According to the GitGuardian blog post on “How to Handle Secrets in Terraform,” the types of secrets that exist in Terraform include API keys used for authentication with cloud providers and other services, Database credentials like usernames and passwords, and SSH keys for secure server access. Inadequate management of these secrets can lead to the potential compromise of an organization's cloud secrets. The following explains how HashiCorp Vault can be compromised in an attack chain:
An open-source AWS exploitation framework called Pacu can be used by adversaries to retrieve secrets from the AWS Secrets Manager via the enum_secrets
module.
$pacu> run enum_secrets
[INFO] Fetching secrets from AWS Secrets Manager...
[INFO] Enumerating secrets for account: 123456789012
[INFO] Found 3 secrets
Secret Name: ExampleSecret1
- ARN: arn:aws:secretsmanager:us-west-2:123456789012:secret:ExampleSecret1-abc123
- Created Date: 2024-01-01T12:00:00Z
- Last Accessed Date: 2024-05-01T12:00:00Z
Secret Name: ExampleSecret2
- ARN: arn:aws:secretsmanager:us-west-2:123456789012:secret:ExampleSecret2-def456
- Created Date: 2024-02-01T12:00:00Z
- Last Accessed Date: 2024-05-02T12:00:00Z
Secret Name: ExampleSecret3
- ARN: arn:aws:secretsmanager:us-west-2:123456789012:secret:ExampleSecret3-ghi789
- Created Date: 2024-03-01T12:00:00Z
- Last Accessed Date: 2024-05-03T12:00:00Z
[INFO] enum_secrets module completed.
HackTricks Cloud reveals how Enumeration, Privilege escalation and Post Exploitation can be performed on AWS - Secrets Manager using various commands.
aws secretsmanager list-secrets #Get metadata of all secrets
aws secretsmanager list-secret-version-ids --secret-id <secret_name> # Get versions
aws secretsmanager describe-secret --secret-id <secret_name> # Get metadata
aws secretsmanager get-secret-value --secret-id <secret_name> # Get value
aws secretsmanager get-secret-value --secret-id <secret_name> --version-id <version-id> # Get value of a different version
aws secretsmanager get-resource-policy --secret-id --secret-id <secret_name>
To mitigate adversaries exploits against Cloud Secrets Management Repositories , organizations and cyber-defenders should limit the number of cloud accounts and services with permission to query the secrets manager to only those that are necessary. Additionally, ensure that accounts and services with permission to query the secrets manager only have access to the specific secrets they require. This approach minimise the attack surface and reduces the potential for unauthorised access to sensitive information.
Similarly, organizations' security teams and cyber-defenders should ensure proper configuration of AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager by implementing least privilege access, enforcing encryption, restricting network access, and regularly audit configuration settings.
In AWS environment, it is recommended that organizations' security teams and cyber-defenders enable automatic rotation for secrets in AWS Secrets Manager. This configuration significantly reduces the risk of compromise of long-lived secret keys. Additionally, unused secrets stored within the secrets manager should be removed to minimise potential attack surfaces.
In Azure environment, It is recommended that organizations' security teams and cyber-defenders properly audit users and identities with access to the following permissions during an Azure audit assessment:
Microsoft.KeyVault/vaults/read
Microsoft.KeyVault/vaults/secrets/read
Microsoft.KeyVault/vaults/accessPolicies/write
Similarly, organizations' security teams and cyber-defenders should enforce strict access controls, regularly rotate secrets, enable Azure activity logging and monitoring, use dedicated key vaults for sensitive data, and implement network security measures to restrict access to key vaults.
In GCP environment, it is recommended that organizations' security teams and cyber-defenders to do the following:
In Terraform secrets management, organizations should implement encryption for all secrets, use automated tools to detect hard-coded secrets in code, employ IAM policies and Role-Based Access Control (RBAC) ****to restrict access, and regularly rotate secrets to minimise exposure.
To mitigate potential compromises, organizations' security teams and cyber-defenders should monitor for API calls and CLI commands that attempt to enumerate and fetch credential material from the secrets manager. Specifically, watch for commands like get-secret-value
in AWS, gcloud secrets describe
in GCP, and az keyvault secret show
in Azure. Set up alerts for any suspicious usage of these commands, such as an account or service generating an unusually high number of secret requests. This proactive monitoring can help detect and respond to unauthorised access attempts swiftly.
Cloud security teams and cyber-defenders should consider using Stratus Red Team Tool to simulate adversaries activities in retrieving high number of Secrets Manager secrets, through secretsmanager:GetSecretValue
from their organisation AWS account.
$root: stratus detonate aws.credential-access.ssm-retrieve-securestring-parameters
Executing technique: aws.credential-access.ssm-retrieve-securestring-parameters
[INFO] Initiating AWS SSM SecureString Parameters Retrieval...
[INFO] Using provided AWS credentials and region: us-west-2
[INFO] Fetching SecureString parameters...
Retrieved Parameters:
Name: /myapp/database/password
Value: **********
Name: /myapp/api/key
Value: **********
Name: /myapp/secret/token
Value: **********
[INFO] Successfully retrieved 3 SecureString parameters.
[INFO] Technique aws.credential-access.ssm-retrieve-securestring-parameters completed.
In this blog, we discussed how adversaries increasingly target AWS, Azure, and GCP cloud secrets management repositories to steal credentials and sensitive data. Organizations and cyber-defenders must constantly review their security strategies to protect their cloud secrets and resources stored in these management repositories.
Organizations' security teams and cyber-defenders must regularly monitor cloud assets, adhere to security best practices, and implement robust security measures such as Privileged Access Management (PAM) and Multi-Factor Authentication (MFA) to safeguard against credential-stealing campaigns by adversaries. By staying ahead of cyber threats and remaining proactive, organizations can fortify their cloud environments and mitigate the risk of compromise.