5 mins to read
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, ways to inflict further damage, or just remain present. 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 be used in the context of Advanced Persistent Threat (APT) scenarios by configuring only very specific traffic be directed to bad domains/subdomains. In selecting a very small percentage of users to target, threat actors could persist access for a very 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.
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 in the next blog: Powerful Permissions You Should Know: Part 3, Lateral Movement and Privilege Escalation.
