MITRE ATT&CK Framework: Credentials Access

This blog is the fourth publication in a series exploring the most powerful cloud permissions and how they map to the MITRE ATT&CK Framework. You can find the beginning of the series here.

—–

Using legitimate Credentials – the tokens, certificates, and passwords your internal teams and machines use – are a great way for adversaries to gain further access without raising alarm bells.

Powerful Permissions in AWS

Permission: CreateProfile, UpdateProfile

Service: Roles Anywhere

Context: Roles Anywhere is a part of AWS IAM that allows workloads to access temporary AWS credentials while running outside of AWS. You use profiles to intersect permissions with IAM managed policies.

These permissions allow you to create or update a profile – a list of the roles that Roles Anywhere service is trusted to assume.

So What?

These permissions present an opportunity for an attacker to obtain temporary permissions for workloads they’ve created outside of AWS infrastructure (note: access to Amazon Certificate Manager is needed to use the credentials).

Further, once a bad actor has compromised an external workload and obtained access to these credentials, if the credentials are set as environment variables on the box, they are available in cleartext for the remainder of the session. The actor could run AWS CLI commands to execute recon, run scripts, or enact other damage allowed by the associated credential permissions.

Permission: GetSessionToken

Service: Security Token Service (STS)

Context: This permission calls and returns with a JSON object including: AccessKeyId, SecretAccessKey, SessionToken, and Expiration.

So What?

A developer could unintentionally use this permission as the root user as opposed to their IAM role (if they’re assuming multiple identities in their everyday job it’s easy to lose track), which would result in the credentials gaining that root user level privilege. These credentials would be gold for an attacker if there was compromise down the road.

Powerful Permissions in Azure

Permission: Microsoft.Sql/servers/tdeCertificates/action

Service: Microsoft SQL Server

Context: This permission allows one to create or update a TDE certificate. Transparent Data Encryption (TDE) encrypts SQL servers and databases. Once a database is encrypted using an Azure Key Vault key, you can use a certificate to protect the key. New backups of the server are also encrypted with the same TDE protector.

So What?

Consider a data dump available on the ‘dark web’. If an SQL server were dumped, and it included a TDE certificate (or an attacker e.g. purchases the cert online from another actor), they could decrypt the protected database information with this permission in hand – even if the certificate expired but was still in use (which would be a case of poor certificate rotation practices in an organization).

If the TDE cert was stored locally to perform a backup of the SQL database, and your teams forgot about it, endpoint compromise would expose the cert (credentials) to further theft.

Permission: Microsoft.Devices/iotHubs/certificates/Write

Service: IoT Hub

Context: IoT Hub is a platform enabling the connection, management, visualization and monitoring of your devices. You can use certificates to authenticate the devices to the IoT Hub. This attests the identities on your devices when connecting to the Hub. This permission allows one to create certificates in IoT Hub.

So What?

Granted an attacker has compromised an endpoint or gotten their hands on the right identity and can access the private key of Microsoft intermediate certificates in the IoT Hub, this permission allows them to create a certificate for an endpoint and use it to act as a gateway for connecting user endpoints. 

Powerful Permissions in GCP

Permission: secretmanager.versions.access

Service: Secret Manger

Context: This permission allows accessing the payload of secrets in Secret Manager. Accessing a secret version with an API call returns the secret contents and additional metadata about the secret version.

So What?

With this API call, an attacker can receive the contents of a secret payload –the secret data in base64 encoded format – and from there all it takes is a single command to decode the credential set.

Additionally, consider a developer creating an application which needs access to a secret. They might leverage this permission/API call to store the credential set to be read from another end of the application and then forget to delete that secret output file down the road.

This could turn into a man-in-the-middle attack with a developer working from an insecure home network OR the piece of compute storing the credentials could be compromised and fall into the wrong hands (from there the attacker needs to learn where exactly to use them, but that’s possible!)

Permission: container.clusters.getCredentials

Service: Google Kubernetes Engine

Context: This permission allows the retrieval of the client certificate and static password (authentication credentials) for Kubernetes clusters.

So What?

Using this command, a user (a bad one) can grab the certificate and password. The credentials work per-cluster, but depending on the malicious user’s access, they could run an enumeration script to aggregate all the cluster credentials.

The location of the kubeconfig file is `~/.kube/config`, which contains various information about the container/cluster. With access to the file, the actor could update it with new credentials and complete further recon.

Permission: storage.hmacKeys.create

Service: Cloud Storage

Context: This permission enables creating HMAC keys for Google Cloud Storage, which are used for authenticating requests. HMAC keys can be used as credentials for service accounts.

HMAC keys can also be used to query Amazon S3 buckets.

So What?

Consider an organization considering migrating from S3 to Cloud Storage, but ultimately did not. In the process of evaluating, a shared HMAC key was created, and your team forgot to delete it.

If an attacker acquires the HMAC key, or creates their own with this permission with authorization to S3, they can query S3 and glean the contents – not to mention whatever contents are in Cloud Storage itself.

Protecting Sensitive Permissions

Cloud permissions are powerful tools. They, just like data, applications and other cloud assets should be safeguarded. This blog aimed to call out some unsuspecting cloud permissions that could be used to gain credentials in your environment. As per our last blog, here are some ways you can get started on strengthening your protection over cloud permissions:

AWS IAM Access Analyzer: Access Analyzer identifies the resources like storage objects or roles that are shared externally. It works with logic-based reasoning to analyze resource-based policies and identify what external principals have unintended access and offers findings. Beyond that it can identify some unused access, enforce policy checks, and use CloudTrail logs for policy recommendations.

Least Privilege: Least Privilege is a well known security standard many enterprises work towards. Nearly impossible to do manually, a solution that offers least privilege can help by monitoring identity permission usage to gain an understanding of what they need to do their job. Excessive or unnecessary privilege can then be stripped away and a suggested better suited policy is recommended.

CIEM: Cloud Infrastructure Entitlement Management solutions are the best option for granularly managing permissions. They are able to ‘see’ all possible permissions tied to cloud identities – machine and human – even the ones accessible through inheritance. This visibility allows a CIEM to rightsize permissions by alerting to potential risks like lateral movement, privilege escalation, unintended access, and more – so your team can remediate within the platform.

Stay Tuned

Continue following the MITRE ATT&CK path as the next blog in this series comes out; Powerful Permissions You Should Know: Part 5, Defensive Evasion.