MITRE ATT&CK Framework: Persistence

This blog is the second publication in a series exploring the most powerful cloud permissions and how they map to the MITRE ATT&CK Framework. If you have not yet read the first blog on the Initial Access stage, you can find it here.

–

Once an attacker has gained a foothold into your environment, their first thought is, ‘how can I stay here?’ Meaning, what nooks and crannies can they create or windows can they leave open to offer them ways back into your cloud or ways, inflict further damage, or just remain. This is how we categorized permissions into the Persistence stage.

For real life examples of persistence techniques at play you can read our blog: An Analysis of Three Cloud Breaches and the Role of Cloud Permissions.

As we introduced in the first blog, these permissions on their own appear harmless, but can introduce significant risk if used poorly by unsuspecting employees or are intentionally used to cause harm.

Below, we will detail several examples from the major cloud providers of permissions attackers can leverage to persist in their endeavors.

Powerful Permissions in AWS

Permission: PutKeyPolicy 

Service: Key Management Service (KMS)

Context: This permission attaches a key policy to the specified KMS key.

A key policy is a resource policy for an AWS KMS key – every KMS key must have exactly one. Key policies are the primary way to control access to KMS keys. The statements in the key policy determine who has permission to use the KMS key and how they can use it. 

So what?

With this permission, attackers can sneak in a policy to allow them access later on. For example, attaching a key policy to a compromised user that defines access to specific Customer Managed Keys (CMKs.) 

Then, if the malicious actor can maintain access to this compromised identity, the actor can obtain whatever sensitive data is provided by the key, even without directly accessing the services where the data is stored.

Beyond this, by configuring the relevant IAM policy on an external user outside your cloud environment, the bad actor could maintain access to your organization with this compromised CMK.

Permission: CreateEmailIdentity, CreateEmailIdentityPolicy/UpdateEmailIdentityPolicy

Service: Simple Email Service (SES)

Context: CreateEmailIdentity kicks off the process of verifying an email identity – the identity is an email address or domain that you use when sending email. Before you can use the identity to send email, you must verify it. Verifying it indicates you’ve given Amazon SES API v2 permission to send emails from the identity. 

CreateEmailIdentityPolicy allows one to create the specified sending authorization policy for a given identity.

So what?

With these permissions to SES, attackers can create a new email identity through which they can distribute spam or malware embedded emails. This is tricky to detect unless recipients report it or you happen to notice changes in your billing cycle.

Even more under the radar, an attacker can create custom email verification templates to send from your own domain (i.e. a trusted source) to your users’ email addresses, including malicious links. 

[e.g. SuccessRedirectionURL,FailureRedirectionURL] 

What’s important to note is once an email identity is set up and verified it remains active. So let’s say your teams detect attacker activity, tighten your controls and force them out, the email activity will persist unless you explicitly change or delete the configurations in SES.

Permission: CreateTrafficPolicy

Service: Route53

Context: This permission creates a traffic policy in Route53, which you use to create multiple DNS resource record sets for one domain name (such as example.com) or one subdomain name (such as www.example.com).

So what?

With access to Route53 comes the capability of directing traffic to specific domains — a common method for delivering malware. Often these malicious domains are short-lived, but with Route53 access, a bad actor can continue to change the settings or create policies that direct your user traffic to any number of domains over time. 

This tactic can quickly become an Advanced Persistent Threat. If the actor configures only a small subset of traffic to a bad domain, it can persist for a long time without being noticed.

Even further, in cases where similar (to your) domains are available for purchase, an attacker could create a very convincing phishing page that appears close to an internal resource within your organization. With no SSL in place, the traffic (and entered credentials) could be logged and used to access additional resources.

Powerful Permissions in Azure

Permission: Microsoft.Storage/storageAccounts/localusers/write

Service: storageAccounts

Context: This permission creates a storage account level user that can access stored data with the ‘write’ permission.

So what?

If an attacker added a Storage Account user, said user could persist access using an SSH key. By leveraging ‘sshAuthorizedKeys’, the user can exfiltrate data through SSH File Transport Protocol (SFTP) and depending on what the stored data is, find other entry points in your environment.

If there is an available credentials/key dump on the web, those credentials are an additional way to persist within the network and continue to peruse and exfiltrate information. 

Powerful Permissions in Google Cloud

Permission: iam.serviceAccounts.undelete, iam.serviceAccounts.enable

Service: Identity and Access Management (IAM)

Context: iam.serviceAcounts.undelete allows for the restoration of previously deleted service accounts in Google Cloud.

iam.serviceAcounts.enable enables reactivating or enabling service accounts in Google Cloud that were previously disabled.

So what?

Both permissions map to persistence as undeleting service accounts or reenabling them can regain the attacker access or maintain presence in a compromised environment. Consider an employee that’s just left or a service account deleted after a project ended. 

A bad actor could re-enable these accounts and leverage whatever the associated permissions are. If your organization doesn’t have specific monitoring for this action you may never realize it’s happened.

Permission: compute.instances.setServiceAccount

Service: Compute

Context: This permission enables setting or changing the service account associated with a virtual machine instance.

So what?

With this permission, a bad actor can set a specific service account to a compute instance, allowing them to maintain access to their desired resources and services. Further, the privileges associated with the service account would be inherited by the instance. This can then lead to other privilege escalation and lateral movement opportunities. 

Permission: serviceusage.services.enable

Service: Service Usage

Context: This permission enables reactivating or enabling specific services in a project.

So what?

This permission offers up the whole gamut, and the possibilities are endless. There are many services available that one could enable to use for many purposes: 

– Enabling cloud APIs (programmatic access to information through the REST API)

– Enabling cloud shell (a shell with command line opportunities)

– Enabling key management (persist by adding a key)

– Enabling application integration (send the data to an external system)

– Enabling cloud CDN (deliver malware via your cloud/resources)

All of this offers further potential for attackers to persist in your environment.

Conclusion

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 persist 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 3, Lateral Movement and Privilege Escalation.

*** This is a Security Bloggers Network syndicated blog from Sonrai | Enterprise Cloud Security Platform authored by Tally Shea. Read the original post at: https://sonraisecurity.com/blog/powerful-cloud-permissions-you-should-know-part-2/