5 mins to read
MITRE ATT&CK Framework: Lateral Movement & Privilege Escalation
This blog is the third publication in a series exploring the most powerful cloud permissions and how they map to the MITRE ATT&CK Framework. You can find the previous blog on Persistence techniques here.
—
An attacker is in your cloud. They are looking to move around it in search of further opportunity. Whether it is pivoting in and out of different accounts, hopping from identity or the next, or gaining more privilege, they’re on the move.
Traditionally, Privilege Escalation and Lateral Movement are distinct stages in the MITRE Framework. For the purpose of this blog, we’ve decided to address the two together. The nature of the cloud allows for new identity-based forms of lateral movement, blurring the lines between horizontal (lateral movement) and vertical movement (privilege escalation. Many of the same cloud permissions can be used to accomplish both techniques, it just depends on the context in how they’re used. We will detail several examples for both stages.
We have categorized permissions under ‘Lateral Movement’ if they either intentionally or unintentionally create opportunities for an attacker to move across your environment, such as from service to service or identity to identity.
Permissions are categorized under ‘Privilege Escalation’ if they allow an identity to escalate their privilege (i.e. gain a higher level of privilege) in order to accomplish their desired action (e.g. access a service).
Powerful Permissions in AWS
Permission: ReplicateSecretToRegions
Service: Secrets Manager
Context: This permission allows one to replicate a secret to a new region. Secrets Manager is used to store credentials, API keys, tokens and other sensitive information.
So what?
If an attacker has access to a stored secret in the original compromised region, this permission allows them to replicate said secret (whether it is credentials, tokens, etc.) to another region. This gives them the ability to move laterally to another region and access additional accounts, resources or services there.
Consider an attacker coming across a compromised EC2 instance with hardcoded variables or secrets exposed in plaintext, with the permission, they can replicate it to another region and leverage the same gained permissions there.
Even more damaging, the attacker could bake the replication into an organization’s base CloudFormation templates to allow this lateral movement beyond just a one-off manual implementation.
Permission: StartSession
Service: Simple Systems Manager (SSM)
Context: This permission grants the ability to initiate a connection to a specified target for a Session Manager session.
Session Manager is a capability of AWS Systems Manager. Sessions Manager allows you to manage EC2 instances and Virtual Machines in a secure and auditable way without the need to open inbound ports or manage SSH keys.
So what?
With a well-privileged role in hand, an attacker can use this permission to initiate an SSM session to repurpose the communication channel for their desired action. This could be adding new credentials to a compute instance, enumerating information within the instance, or other opportunities to move laterally.
Permission: PutDomainPermissionsPolicy
Service: Code Artifact
Context: Code Artifact supports resource-based permissions – which let you specify who has access to a resource and what they can do. By default, only the original account that owns the domain can create or access repositories in the domain. However, one can apply a policy document to a domain to allow others to access it.
When called, this permission triggers the resource policy on the domain to be ignored when evaluating permissions. This means the owner of the domain cannot lock themselves out of the domain, preventing them from updating the resource policy.
So what?
A bad actor could add themselves to the domain access list, bypassing the resource policy present on the domain – giving them unauthorized access. This increase in privilege can allow them further opportunity to inflict damage. For example, creating their own malicious package into a public repository, and then pointing the production domain codeartifiact instance to it.
Powerful Permissions in Azure
Permission: Microsoft.DataBoxEdge/dataBoxEdgeDevices/users/write
Service: Data Box
Context: This permission allows the creation of new users or updating current user passwords in Data Box. Data Box allows offline data ingestion and transport. Data is stored and transported on disks.
So what? This is lateral movement gold. An attacker could create a new user to their liking or overwrite a current user’s password and move laterally to the Data Box device. From there, they can enumerate other user accounts or continue on to exfiltrate data by connecting an external Linux/Window box to the disk.
Permission: Microsoft.Authorization/policyAssignments/exempt/action
Service: N/A
Context: This permission enables the ability to exempt specific resources from certain policy measures.
So what?
Quite straight forward, this permission allows lateral movement that would otherwise be inaccessible. For example, let’s say there’s a resource with a policy restricting access or restricting the ability to communicate to other resources in local networks – with this permission in hand, the attacker can exempt the restriction and complete a desired action.
Powerful Permissions in GCP
Permission: compute.instances.osAdminLogin
Service: Compute
Context: This permission allows administrative login to the operating system of compute engine instances.
So what?
If a bad actor can gain access to a compute instance and OSAdminLogin is enabled, they essentially control the instance itself. This is a direct form of privilege escalation. This can be especially damaging if the instance is responsible for integral operations like a CI/CD pipeline or website content delivery.
Additionally, this permission allows SUDO (SuperUser DO) – the greatest form of privilege escalation available on a Linux box. It temporarily allows elevated privileges without being the root user. With this enabled, the actor can have their way with your cloud.
Permission: iam.serviceAccounts.implicitDelegation
Service: IAM
Context: This permission allows a GCP service account to delegate its permissions implicitly to other services. It allows a service account to get tokens in a delegation chain.
So what?
A user can impersonate a service account without ever retrieving a credential for the service account (in cases of programmatic access using generateAccessToken method).
Using this permission is a great way to bypass implicit credential requirements by chaining a request through several service accounts. The initial credential gets passed through a number of service accounts (if they all have the implicitDelegation permission). Additionally, you can also create access tokens with higher privileges than the base service account for other service accounts to elevate their privileges.
All in all, It enables services to gain broader access than initially granted.
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 in this series: Powerful Cloud Permissions You Should Know: Part 4, Credential Access.
