MITRE ATT&CK Cloud Matrix: New Techniques & Why You Should Care - Part II

The MITRE ATT&CK Framework v.14 was released in October 2023 with over 18 new techniques. In the first part of this blog, we looked at two of the four techniques relevant to public cloud infrastructure. In this concluding part, we will examine the remaining two new techniques: Log Enumeration (T1654) and Modify Cloud Compute Infrastructure: Modify Cloud Compute Configurations (T1578.005). Note that the MITRE ATT&CK Framework v. 15 has also been released since 23rd April 2024, and we will cover the changes and implications in a forthcoming blog.

Step Up Your Cloud Threat Detection Capability

The MITRE ATT&CK framework has become the most reliable source of real world attacks. The framework collects information from multiple curated sources and provides them in structured and easily consumable formats. However, there are huge challenges with keeping track of cloud attacks. Cloud infrastructures are constantly evolving, each new cloud service introduces attack opportunities, it takes a while to grasp the security implications of the service and this gap is analogous to zero day vulnerabilities. Similarly, API changes add to the existing complexities, for example the AWS BatchGetSecretValue API, a recently introduced Secret Manager feature exposes attack opportunities not currently detected by several cloud threat detection systems (e.g. XDRs, CDRs). You will want to read more on this in our previous blog.

Furthermore, the new techniques added in v. 14 of the MITRE ATT&CK framework are challenging to flag as malicious. Well, this challenge extends across all cloud detection efforts. Threat detection systems create alert fatigue for security teams, overcoming this requires careful tuning of these systems. It is important to note that most attackers chain attacks together to achieve their objectives, therefore threat detection systems need to consider a series of techniques based on specific attributes before firing alerts. Some of these attributes include IP addresses, usernames, geographical locations, request times etc. Eventually these attributes formulate the environmental CONTEXT. But context requires validation and adversary emulation provides the best approach to security validation, without which challenges of alert fatigue etc remain. The Mitigant Cloud Attack Emulation offers an easy to use, top-notch platform for security teams to run cloud adversary emulation. Also, the Sigma Correlations project seems to be headed in the right direction, it aims to correlate several seemingly independent detections.

Log Enumeration  (T1654)

Logs are the raw material for most forms of security analysis, often leading to several security outcomes such as proactive threat detection and incident response. Accordingly, defenders cherish logs, hence log management is a fundamental aspect of effective security strategies. Conversely, attackers have a similar desire for logs often targetting log sources to either gain insights into the target environment or erase attack evidence. Consequently, several best practices for secure log management have been proposed over the years. Recently, the US NSA released the Top 10 Cloud Security Mitigation Strategies, and one of the ten strategies focuses on managing cloud logs.

Similar to other aspects of security, effective management of cloud logs differs from on-premises/traditional systems. Cloud Service Providers (CSPs) provide logs for most of their service offerings. While some services have logging enabled by default, others require cloud account owners to manually intervene. However, the sheer number of cloud services, each having separate logs results in log sprawl and bringing all these logs sources to a common source is challenging.

CSPs attempt to address this issue by providing services that centralize cloud logs, e.g., AWS Cloudtrail. However, these efforts are far from perfect; several services do not have their logs pushed to these central logging services consequently additional augmentation efforts are required to enable this gaps. To address this gaps, organizations often leverage additional log aggregation mechanisms e.g. Cloudwatch and Security Lake or alternatively use third-party systems, e.g., SIEMs.

The new MITRE ATT&CK Technique, Log enumeration (T1654) describes attacks that take advantage of these gaps in cloud logs. These gaps results in log sprawl , which opens opportunities for attackers to illegally access logs from these disparate cloud services. Attackers could easily exfiltrate logs files for further analysis allowing deeper understanding of the cloud environment. Furthermore, attackers commonly target centralized log sources e.g. cloud object storage used as log storage. AWS S3 buckets used in storing Cloudtrail and other cloud logs can easily be compromised if improperly configured . Other centralized logging possibilities including Cloudwatch and OpenSearch could be targetted by attackers. These attack techniques generally fall under the Discovery Tactic of the MITRE ATT&CK framework.

Mitigation

CSPs recommend proper log management approaches to reduce attack opportunities exposed due to illegal access to logs. Let’s examine some of these recommendations:

• Log Centralization: Logs can be centralized into a dedicated logging/security account that is highly secured; allowing minimal access. This approach especially suits organizations that leverage the AWS Organizations setup to manage security and other operational requirements.
• Follow the best practices for security S3 buckets if used for retaining Cloudtrail logs beyond the default 90-day availability. These include encryption of logs, use of MFA to regulate access, implementation of the principle of least privilege, etc. See this documentation for some baseline prescriptions.

Detection

Several opportunities exist for detecting illegal cloud-log access, including the two approaches listed below. However, a challenge with detecting these attacks is that most detection approaches depend on Cloudtrail events without considering the need to collect S3 object-level events. Requests for collecting log files in S3 buckets are only available as S3 object-level events, and these events are not enabled by default.

• Monitor standard API calls and commands that might indicate log collection either at the OS level (in virtual machines), exfiltration of logs from S3 buckets and qerrying of logs from the central logging service e.g. Cloudtrail (Lookupevents).
• Monitoring of access to systems and services used for collecting and managing logs, e.g., Cloudtrail and Security Lake. Cloudtrail eventnames that might be interesting to monitor include ListTrails and DescribeTrails.

Modify Cloud Compute Infrastructure: Modify Cloud Compute Configurations (T1578.005)

Attackers target cloud infrastructure for various reasons, while some attacks are outrightly malicious, some are not directly malicious (or do not aim at stealing data from the compromised environment). The attacks in the latter category are generally categorized under the MITRE ATT&CK technique - Resource Hijacking (T1496), and may aim at allowing the perpetrator to avoid paying for the high cost of cloud compute. This is especially in cases where the attacker use the compromised resources to conduct operations requiring huge computational capabilities e.g., bitcoin mining and machine learning/artificial intelligence workloads. Attackers often hijack these cloud computer resources and use them silently; without arousing suspicion, on example is when attackers compromised Tesla's AWS EKS clusters. However, in some cases, the hijacked compute resources are used as part of an attack, e.g., for hosting Command and Control servers for attacking targets within or outside the compromised infrastructure. The attackers that compromised MITRE environment used to technique, the spawned instances in the VMware infrastructure. These VMs were subsequently used for communicating to command and control servers.

CSPs assign quotas in cloud resources as a control measure, including limits on the compute resources per account. However, customers can request for additional resources. Attackers abuse this possibility by requesting for additional resources in order to carry out further malicious actions. Attacks that constitute this abuse are categorized in the new MITRE ATT&CK sub-technique - Modify Cloud Compute Infrastructure: Modify Cloud Compute Configurations. This sub-techniques falls under the Defensive Evasion Tactic of the MITRE ATT&CK framework.

For example, attackers can request an additional quota of vCPUs to increase the permissible number of EC2 instances or the size of vCPU per instance. This request may not be noticed if not actively monitored. Here, the Cloudtrail eventname RequestServiceQuotaIncrease implies is part of a Cloudtrail record of a request to increase a quota. The request can be made via AWS APIs, for example the following command:

aws service-quotas get-service-quota   --service-code ec2 --quota-code L-1216C47A

Mitigation

Adopting zero-trust and least-privilege approaches might limit the permissions around quota increase requests. These measures generally regulate the access conditions that allow for requesting increase in the quota thus making it harder for attackers with stolen credentials to make valid requests.

Detection

Monitoring requests, including the following Cloudtrail eventnames: RequestServiceQuotaIncrease and GetServiceQuota, can detect malicious requests for quota increases.

Stay Ahead of Cloud Attacks With Threat-Informed Defense

Defending against malicious entities is challenging, and there is no silver bullet. Also, sole dependence on traditional vulnerability management often leads to alert fatigue and a false sense of security. There is hardly proof that most of the vulnerabilities with high CVSS scores are eventually exploited hence focusing on these vulnerabilities is often counter-productive.

Threat-Informed Defense strategies address these concerns by hinging defenses on real-world attacks. These attacks are added to the MITRE ATT&CK framework and described explicitly. Furthermore, Cyber Threat Intelligence (CTI) is brought in to add context; by providing additional information about threat actors' behavior, tools used, industries targeted, etc.

However, the MITRE ENGENUITY recommends using adversary emulation to validate the efficiency of Threat-Informed strategies, including CTI and MITRE ATT&CK-based defensive measures.  The Mitigant Cloud Attack Emulation Platform provides an easy-to-use, agentless approach that allows teams of any size to run adversary emulation for AWS infrastructure. The platform automatically discovers suitable targets, executes the attacks, collects evidence, and cleans up the infrastructure afterward.  Sign up for a free trial today at https://www.mitigant.io/sign-up.

‍