5 mins to read
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.
—–
‘Credential Access’ is the next stage of the MITRE ATT&CK Framework we’ll explore – an attacker’s efforts to hijack accounts and steal passwords. For the purpose of mapping permissions to the framework, we’ve considered any sort of credential theft OR the ability to create new credentials as ‘credential access’.
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.
Instantly Secure The Most Sensitive Permissions
Sonrai’s Cloud Permissions Firewall knows the 3,000 most sensitive cloud permissions out there — and how your identities are using them. Unused sensitive permissions are instantly protected with a global default deny policy fit to your specific access needs — all you have to do is a click a button to deploy. Grant future access needs on the fly with a permissions-on-demand workflow integrated into your ChatOps tool.
While you’re at it, quarantine zombie identities and disable unused cloud services and regions for ultimate risk reduction.
Want to Read More?
Continue following the MITRE ATT&CK path with the next blog; Powerful Permissions You Should Know: Part 5, Defensive Evasion.
