MITRE ATT&CK Cloud Matrix v.16: New Techniques & Why You Should Care Part I

The MITRE ATT&CK Framework v.16 was released in October 2024 with over 19 new techniques. This blog discusses two new Cloud Matrix sub-techniques: Modify Authentication Process: Conditional Access Policies (T1556) and Resource Hijacking: Cloud
20.11.2024
Kennedy Torkura
5 Minutes
MITRE ATT&CK Cloud Matrix v.16: New Techniques & Why You Should Care Part I
Contributors
Kennedy Torkura
Kennedy Torkura
Co-Founder & CTO
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

MITRE ATT&CK Cloud Matrix v.16: New Techniques & Why You Should Care Part I

The MITRE ATT&CK Framework v.16 was released in October 2024 with over 19 new techniques. This blog discusses two sub-techniques under the Cloud Matrix: Modify Authentication Process: Conditional Access Policies (T1556) and Resource Hijacking: Cloud Service Hijacking (T1496.004). Subsequent posts will cover more new techniques.

Modify Authentication Process: Conditional Access Policies (T1556)

This attack sub-technique described a subtle approach to abuse conditional access policies. Here is the official description of this sub-technique:

Adversaries may disable or modify conditional access policies to enable persistent access to compromised accounts. Conditional access policies are additional verifications used by identity providers and identity and access management systems to determine whether a user should be granted access to a resource.

Conditional Access is Microsoft’s Zero Trust Policy Engine (Source)



Conditional access policies allow fine-grained access control based on specific conditions. These policies are if-then conditions; they define the prerequisites for granting entities access to specified cloud resources. These conditions include IP address ranges, geographical locations, user/group memberships, devices, applications, etc. Given the effectiveness of these policies, attackers can identify these policies following a compromise in the cloud account. After that, the attacker can modify the specified condition to suit their purpose.

Quick example: AWS identity-based policies add granular permissions via condition blocks. The condition block can specify the IP range from which access to S3 objects should be granted. Effectively, the condition block would reject all requests not originating from the specified IP addresses.

Attackers can modify conditional access policies in Microsoft Entra ID (Source)

An attacker could insert an IP address within his control in such a policy to persist in accessing the resource the policy is attached to. This is subtle and allows the attacker to maintain access to the resource.

Microsoft Entra Conditional Access brings signals together to make decisions and enforce organizational policies (source: https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview)

The threat group Scattered Spider uses this sub-technique, e.g., by adding trusted locations to Azure AD conditional access policies. 

Attacker’s Can Modify Condition Blocks in Policies Attached to AWS Resources 

Mitigation

The sub-technique can be mitigated by implementing the following measures:

  • Least Principle Access: Grant permissions to modify conditional access policies to only those required per the principle of least privileges.
  • Cloud Drift Management: Changes to cloud environments should be tracked to identify changes and easily differentiate malicious from benign changes. Mitigant’s drift analysis helps with asset monitoring and drift analysis.

Detection

Monitoring requests that indicate malicious changes of policies, on AWS this would be CloudTrail eventnames like CreatePolicyVersion & PutBucketPolicy.

Resource Hijacking: Cloud Service Hijacking (T1496.004)

Attackers target cloud infrastructure for various reasons, some of which are not seemingly malicious but could have several indirect consequences, e.g., an increase in bills. These attacks are generally categorized under the MITRE ATT&CK technique - Resource Hijacking (T1496), which is described as below in the MITRE ATT&CK official documentation:

Adversaries may leverage the resources of co-opted systems to complete resource-intensive tasks, which may impact system and/or hosted service availability. Resource hijacking may take a number of different forms. For example, adversaries may:

  • Leverage compute resources in order to mine cryptocurrency
  • Sell network bandwidth to proxy networks
  • Generate SMS traffic for profit
  • Abuse cloud-based messaging services to send large quantities of spam messages
Cloudtrail Record Showing A Call Against the GetModelInvocationLoggingConfiguration API

                                

As mentioned above, the most popular attack cybercriminals use during resource hijacking has been for crypto mining. However, cybercriminals have recently started targeting GenAI cloud workloads, especially Large Language Models (LLMs). Security researchers from Sysdig first reported these attacks, and Krebs on Security later provided more information based on different sources, including Permiso Security. All the reports noticed resource hijacking attacks via LLMJacking against GenAI workloads powered by Amazon Bedrock. We provided additional analysis and countermeasures in a previous blog article, which you can access here.

LLMJacking is an Attack Where the Resource Hijacking technique is Implemented

Mitigation

Adopting zero-trust and least-privilege approaches reduces the attack surface of these resource-hijacking attacks. Monitoring suspicious resource usage via billing alerts also helps quickly identify suspicious events.

Detection

For infrastructure on AWS, monitoring requests, including the following CloudTrail eventnames, could enhance detection for LLMJacking attacks: RunInstances, GetModelInvocationLoggingConfiguration, InvokeModel. For EC2-based attacks, e.g., cryptojacking, the following eventnames could be essential to monitor  RunInstances and SendCommand.

                       Emulating LLMJacking With Mitigant Attack Emulation 

The Mitigant Advantage: Adversarial Exposure Validation

Gartner introduced Adversarial Exposure Validation  (AEV) in the Hype Cycle for Security Operations 2024.  Breach & Attack Simulation, Red Teaming, and Autonomous Penetration testing have been subsumed into AEV due to its superior value proposition. AEV technology allows organizations to implement Continuous Threat Exposure Management (CTEM) programs efficiently.

     Continuous Threat Exposure Management  (CTEM)

Validation is the fourth step in implementing a CTEM program. It aims to ensure that implemented security measures are effective based on empirical evaluation. For example, security products might not update to the latest MITRE ATT&CK release, resulting in detection gaps and successful attacks. Based on real-world observations, the techniques discussed above were recently added to the MITRE ATT&CK framework. We discovered a situation previously when several security tools were behind MITRE updates. 

The Mitigant Security Platform is the most sophisticated and comprehensive AEV platform for cloud infrastructure. Leverage Mitigant today to validate the security efficiency of cloud security tools, such as CSPM, CNAPP, CIEM, etc. 

Sign up for your free trial here   - https://www.mitigant.io/en/sign-up

 

Ready to Secure Your Cloud Infrastructures?
Connect with the Mitigant Team and proactively protect your clouds today.

Join The Cloud Security Revolution Today!

Take control of your cloud security in minutes. No credit card required.
Start 30-day Free Trial