Aligning Falco’s Cloudtrail Rules with MITRE ATT&CK

This blog will explain how Falco’s Cloudtrail plugin rules can be aligned with MITRE ATT&CK Framework for Cloud. 

One important note is that the team at MITRE has developed several different matrices to address the unique risk associated with adversaries in the cloud, in containerized workloads as well as on mobile devices. In this blog post, we will align rules only to the Cloud matrix seen below:

Initial Access	Execution	Persistence	Privilege Escalation	Defense Evasion	Credential Access	Discovery	Lateral Movement	Collection	Exfiltration	Impact
Drive-by compromise	Serverless Execution	Account Manipulation	Domain Policy Modification	Use Alternate Auth Material	Brute Force	Network Sniffing	Internal Spear Phishing	Data from Information Repositories	Transfer Data to Cloud Account	Account Access Removal
Exploit Public-Facing Application	User Execution	Office Application Startup	Event Triggered Execution	Modify Cloud Compute Resources	Forge Web Credentials	Cloud Service Discovery	Taint Shared Content	Automated Collection		Data Destruction
Phishing		Create Account	Valid Accounts	Impair Defenses	Modify Auth Process	Network Service Discovery	Use Alternate Auth Material	Data from Cloud Storage		Defacement
Trusted Relationship		Event Triggered Execution		Indicator Removal	MFA Request Generation	Cloud Infrastructure Discovery		Data Staged		Data Encrypted for Impact
Valid Accounts		Valid Accounts		Hide Artifacts	Network Sniffing	Password Policy Discovery		Email Collection		Endpoint Denial of Service
		Modify Auth Process		Domain Policy Modification	Unsecured Credentials					Resource Hijacking
		Implant Internal Image		Unused / Unsupported Cloud Regions	Steal App Access Tokens					Network Denial of Service

The blue column denotes where a default Falco rule did not exist, so we had to build a custom Falco rule to address that specific tactic and technique within the Cloud Matrix.

Why the need for a Cloud Matrix?

The Cloud Matrix in the MITRE ATT&CK framework provides several benefits for organizations looking to improve their cloud security posture. Some of the key benefits are:

• Threat Awareness: The Cloud Matrix provides a comprehensive overview of the threat landscape in cloud environments, including the tactics, techniques, and procedures (TTPs) used by adversaries. This helps organizations understand the types of attacks they are likely to face and how to defend against them.
• Focus: The Cloud Matrix helps organizations focus on the most critical security areas, rather than wasting time and resources on less important security measures.
• Detection: The Cloud Matrix provides guidance on how to detect potential security threats, allowing organizations to quickly respond to incidents.
• Continual Improvement: The Cloud Matrix is updated regularly to reflect the latest threat landscape, ensuring that organizations can stay ahead of the curve and continuously improve their security posture.

Overall, the Cloud Matrix in the MITRE ATT&CK framework provides a valuable resource for organizations looking to improve their cloud security and defend against threats in this rapidly evolving environment.

How does Falco benefit from the Cloud Matrix

The open source Falco intrusion detection system can greatly benefit from the MITRE ATT&CK framework for Cloud in several ways:

• Improved Detection: By incorporating the threat intelligence and tactics, techniques, and procedures (TTPs) described in the Cloud Matrix of the MITRE ATT&CK framework, Falco can more accurately detect potential security threats in cloud environments.
• Alignment with Industry Standards: By leveraging the widely recognized and adopted MITRE ATT&CK framework, Falco can provide a consistent, reliable, and widely accepted method of detecting and responding to threats in cloud environments.
• Better Threat Prioritization: The Cloud Matrix helps organizations prioritize their security efforts based on the potential impact of different attack scenarios and the likelihood of an attack. Falco can utilize this information to focus its detection capabilities on the most critical security areas.
• Improved UX: The Cloud Matrix provides a clear and concise representation of the threat landscape, making it easier for security teams to understand and respond to potential threats. Falco can take advantage of this to provide a more intuitive and streamlined user experience.

By incorporating the Cloud Matrix of the MITRE ATT&CK framework into its capabilities, Falco can improve its ability to detect and respond to potential security threats in cloud environments and provide a better user experience for security teams.

While MITRE ATT&CK itself is not an example of a true risk framework, many organizations will use MITRE for guidance when building their security detection rules and infrastructure guardrails. As a result, it is critical that Falco aligns its rules with this popular framework.

How do we align the rules?

In short, we need to first understand the tactics and their associated techniques in the Cloud Matrix.

Once we have done this, we need to create Falco rules to detect these techniques and sub-techniques. If a rule already exists, we can simply tag the rule definition to the relevant MITRE techniques.

Initial Access

The Initial Access tactic consists of techniques that use various entry vectors to gain their initial foothold within a network. Footholds gained through initial access may allow for continued access, like valid accounts and use of external remote services, or may be limited-use due to changing passwords.

Assuming a role in AWS involves using a set of temporary security credentials that you can use to access AWS resources that you might not normally have access to. These temporary credentials consist of an access key ID, a secret access key, and a security token.

Since any console login through an assumed role would qualify as ‘Valid Account’ compromise, this rule is therefore associated with the tactic ‘Initial Access’ and the associated technique ‘Valid Accounts.’ In order to correctly align this default rule with the MITRE ATT&CK matrix for Cloud, we need to tag the Falco rule with the Tactic, Technique, and the Technique ID, as seen below (Github Link):

- rule: Console Login Through Assume Role
  desc: Detect a console login through Assume Role.
  condition:
    ct.name="ConsoleLogin" and not ct.error exists
    and ct.user.identitytype="AssumedRole"
    and json.value[/responseElements/ConsoleLogin]="Success"
  output:
    Detected a console login through Assume Role
    (principal=%ct.user.principalid,
    assumedRole=%ct.user.arn,
    requesting IP=%ct.srcip,
    AWS region=%ct.region)
  priority: WARNING
  tags:
  - aws
  - T1078
  - initial_access
  - valid_accounts
  source: aws_cloudtrailCode language: Perl (perl)

Execution

The execution of code, whether local or remote, is a crucial aspect of security that often determines the success of an adversary’s objectives. To achieve their goals, such as network exploration or data theft, attackers employ a combination of various techniques within this MITRE tactic. 

One such technique is serverless execution, which has gained popularity with the rise of cloud computing services like AWS Lambda. While serverless functions can be a powerful tool, they also present potential security risks. To minimize false positive alerts, it’s important to establish clear conditions, such as restricting execution to approved users and regions. 

To ensure comprehensive security coverage, it’s also helpful to tag the rule with the relevant MITRE Tactic, Technique, and Identifier, as seen in the below rule snippet (Github Link).

- rule: Create Lambda Function
  desc: Detects the creation of a Lambda function.
  condition:
    ct.name="CreateFunction20150331" and not ct.error exists
  output:
    Lambda function has been created.
    (requesting user=%ct.user,
     requesting IP=%ct.srcip,
     AWS region=%ct.region,
     lambda function=%ct.request.functionname)
  priority: WARNING
  tags:
    - aws
    - T1648
    - execution
    - serverless_execution
  source: aws_cloudtrailCode language: Perl (perl)

Persistence

Persistence consists of techniques that adversaries use to maintain their foothold, keeping access across your cloud environment. Attackers can use a new set of credentials, create a new IAM account, or create a new image to be used as a backdoor to maintain access to your environment. 

Once they succeed in persistence, they are able to access your cloud environment without performing the first steps of initial access. As a result, we must treat all new account creations, especially those created without prior approval as suspicious. 

In the Cloud Matrix, the technique is simply called ‘Create Accounts’ with the Technique ID set to T1136.

- rule: Create AWS user
  desc: Detect creation of a new AWS user.
  condition:
    ct.name="CreateUser" and not ct.error exists
  output:
    A new AWS user has been created
    (requesting user=%ct.user,
     requesting IP=%ct.srcip,
     AWS region=%ct.region,
     new user created=%ct.request.username)
  priority: INFO
  tags:
    - aws
    - T1136
    - persistence
    - create_account
  source: aws_cloudtrailCode language: JavaScript (javascript)

Github Link

Privilege escalation

Updating a Lambda function configuration is not inherently a means of privilege escalation. However, if an attacker has the ability to update the configuration of a Lambda function, they may be able to use it to gain elevated privileges in certain circumstances such us IAM misconfiguration.

For example, if a Lambda function has permissions to access sensitive resources, an attacker who can update the function’s configuration could modify its code to exfiltrate or modify the sensitive data. Similarly, an attacker who can update the function’s configuration could change the function’s permissions to allow it to access additional resources, giving the attacker broader access to the target system.

It is important to properly secure Lambda functions and restrict access to their configurations and permissions to prevent malicious actors from using them as a vector for privilege escalation. This can be achieved by implementing appropriate access controls and following AWS security best practices such as the principle of least privilege. For more information on T1546 (Event-triggered Execution), check out the official MITRE ATT&CK page.

- rule: Update Lambda Function Configuration
  desc: Detects updates to a Lambda function configuration.
  condition:
    ct.name="UpdateFunctionConfiguration20150331v2" and not ct.error exists
  output:
    The configuration of a Lambda function has been updated.
    (requesting user=%ct.user,
     requesting IP=%ct.srcip,
     AWS region=%ct.region,
     lambda function=%ct.request.functionname)
  priority: WARNING
  tags:
    - aws
    - T1546
    - privilege_escalation
    - event_triggered_execution
  source: aws_cloudtrailCode language: JavaScript (javascript)

Github Link

Defense evasion

Running EC2 instances in a non-approved region can be considered a form of defense evasion because it can help attackers hide their activity and evade detection.

When an organization has policies and procedures in place to only run EC2 instances in approved regions, this helps to ensure that the instances are within the scope of the organization’s security controls and can be monitored and audited effectively. By running EC2 instances in a non-approved region, an attacker may be able to evade the organization’s security monitoring and logging systems, making it more difficult to detect and respond to their activities and carry out their activities (such as a command and control server, or to carry out cryptomining activities) without being detected.

- rule: Run Instances in Non-approved Region
  desc: Detects launching of a specified number of instances in a non-approved region.
  condition:
    ct.name="RunInstances" and not ct.error exists and
    not ct.region in (approved_regions)
  output:
    A number of instances have been launched in a non-approved region.
    (requesting user=%ct.user,
     requesting IP=%ct.srcip,
     AWS region=%ct.region,
     availability zone=%ct.request.availabilityzone,
     subnet id=%ct.response.subnetid,
     reservation id=%ct.response.reservationid,
     image id=%json.value[/responseElements/instancesSet/items/0/instanceId])
  priority: WARNING
  tags:
    - aws
    - T1535
    - defense_evasion
    - unused_unsupported_cloud_regions
  source: aws_cloudtrailCode language: JavaScript (javascript)

Github Link

Credential access

Deactivating Multi-Factor Authentication (MFA) for a administrator user in AWS can increase the risk of unauthorized access to sensitive resources and information, which can be used for credential access.

The root user in AWS is the highest-level user account and has full access to all AWS services and resources. MFA is an extra layer of security that requires a user to provide a second form of authentication in addition to a password. 

Once an attacker has access to the root user’s credentials, they can use them to access and manipulate the entire AWS environment, including sensitive resources such as data, applications, and infrastructure. They can also potentially access or compromise other user accounts and grant themselves additional permissions.

It is important to keep MFA enabled for the root user to maintain a strong security posture and prevent unauthorized access to sensitive information. Additionally, organizations should follow best practices for securing AWS environments, including the use of role-based access controls, logging, and monitoring to detect and respond to potential security incidents.

- rule: Deactivate MFA for Root User
  desc: Detect deactivating MFA configuration for root.
  condition:
    ct.name="DeactivateMFADevice" and not ct.error exists
    and ct.user.identitytype="Root"
    and ct.request.username="AWS ROOT USER"
  output:
    Multi Factor Authentication configuration has been disabled for root
    (requesting user=%ct.user,
     requesting IP=%ct.srcip,
     AWS region=%ct.region,
     MFA serial number=%ct.request.serialnumber)
  priority: CRITICAL
  tags:
    - aws
    - T1556
    - credential_access
    - modify_authentication_process
  source: aws_cloudtrailCode language: JavaScript (javascript)

Github Link

Discovery

Listing Amazon S3 buckets can be considered a form of cloud infrastructure discovery because it provides information about the structure and content of a target’s cloud environment.

Amazon S3 is a popular cloud storage service that allows organizations to store and retrieve data in the cloud. When an attacker lists the S3 buckets in a target’s environment, they can gain insights into the structure and content of the target’s cloud infrastructure, including the types of data that are stored, the size of the data, and the permissions that are associated with the data.

This information can be valuable to an attacker as they plan their attack and determine which resources and data to target. For example, an attacker may use the information obtained through S3 bucket enumeration to identify sensitive data that is stored in the cloud, or to identify S3 buckets that have misconfigured permissions that allow for public access.

To prevent cloud infrastructure discovery, organizations should implement security measures such as access controls and encryption to restrict unauthorized access to their S3 buckets, and regularly review and monitor the permissions and configurations of their S3 buckets to ensure that they are properly secured. Additionally, organizations should implement logging and monitoring systems to detect and respond to potential security incidents, and follow security best practices such as the principle of least privilege.

- rule: List Buckets
  desc: Detects listing of all S3 buckets.
  condition:
    ct.name="ListBuckets" and not ct.error exists
  output:
    A list of all S3 buckets has been requested.
    (requesting user=%ct.user,
     requesting IP=%ct.srcip,
     AWS region=%ct.region,
     host=%ct.request.host)
  priority: WARNING
  enabled: false
  tags:
    - aws
    - T1580
    - discovery
    - cloud_infra_discovery
  source: aws_cloudtrailCode language: PHP (php)

Github Link

Note: This rule is not enabled by default.
Change the setting ‘enabled’ to ‘true’ in order to avail of this Falco rule.

Lateral movement

The lateral movement technique “taint shared content” refers to the practice of compromising shared resources in order to expand access to other systems within an organization. In the context of AWS Lambda functions, updating the code of a function can be considered a form of “taint shared content” if the code update is malicious and is intended to gain access to other systems within the organization.

For example, if an attacker is able to gain access to a Lambda function and update its code to include a malicious payload, this payload could be used to extract sensitive information or exfiltrate data from other systems within the organization. The attacker could also update the code to include a backdoor that allows them to regain access to the compromised systems at a later time.

In order to mitigate the risk of “taint shared content” in the context of AWS Lambda functions, it is important to implement strong security controls, such as access controls and code signing, to ensure that only authorized individuals are able to update the code of Lambda functions, and to ensure that any code updates are thoroughly vetted before being deployed. Additionally, monitoring the activity of Lambda functions, including changes to their code, can help to detect and prevent malicious activity in a timely manner (Github Link).

- rule: Update Lambda Function Code
  desc: Detects updates to a Lambda function code.
  condition:
    ct.name="UpdateFunctionCode20150331v2" and not ct.error exists
  output:
    The code of a Lambda function has been updated.
    (requesting user=%ct.user,
     requesting IP=%ct.srcip,
     AWS region=%ct.region,
     lambda function=%ct.request.functionname)
  priority: WARNING
  tags:
    - aws
    - T1080
    - lateral_movement
    - taint_shared_content
  source: aws_cloudtrailCode language: JavaScript (javascript)

Collection

The MITRE tactic “collection” refers to the practice of gathering information from a target system. The technique “data from cloud storage” involves the collection of data stored in cloud-based storage systems.

In Amazon Web Services (AWS), the “Put Bucket ACL (Access Control List)” operation can be aligned with these tactics and techniques because it allows you to control access to the data stored in an S3 bucket. By setting the ACL for a bucket, you can determine which users or systems have permission to access and retrieve data stored in that bucket.

For example, if an attacker were to gain access to an S3 bucket and use the “Put Bucket ACL” operation to modify the ACL in a way that granted them access to the data stored in the bucket, they could then use the “data from cloud storage” technique to collect sensitive information from the target system. By modifying the ACL, the attacker could gain the necessary permissions to collect data from the cloud storage, effectively conducting a “collection” operation.

If you want to learn more threats in cloud storage, find out about cloud storage extortion.

- rule: Put Bucket ACL
  desc: Detect setting the permissions on an existing bucket using access control lists.
  condition:
    ct.name="PutBucketAcl" and not ct.error exists
  output:
    The permissions on an existing bucket have been set using access control lists.
    (requesting user=%ct.user,
     requesting IP=%ct.srcip,
     AWS region=%ct.region,
     bucket name=%s3.bucket)
  priority: WARNING
  tags:
    - aws
    - aws
    - collection
    - data_from_cloud_storage
  source: aws_cloudtrailCode language: JavaScript (javascript)

Github Link

Building custom rules based on the ATT&CK Matrix

Adversaries may exfiltrate data by transferring it, including backups of cloud environments, to another cloud account they control on the same service to avoid typical file transfers/downloads and network-based exfiltration detection.

A defender who is monitoring for large transfers to outside the cloud environment through normal file transfers or over command and control channels may not be watching for data transfers to another account within the same cloud provider. Such transfers may utilize existing cloud provider APIs and the internal address space of the cloud provider to blend into normal traffic or avoid data transfers over external network interfaces.

However, there is no default rule available for the AWS Cloudtrail plugin that’s related to data exfiltration. To address the techniques not provided in the default rules, we can create our own custom rules. In fact, we encourage more readers to contribute rules to the Falco project to ensure we provide extensive coverage in the MITRE ATT&CK for Cloud Matrix. 

Here is an example of a bespoke rule we have written to address this gap.

- rule: Transfer Data to Cloud Account
  desc: Detects outbound connection to another AWS account.
  condition: >
    aws.eventName="CreateConnection"
    and jevt.value[/requestParameters/egress]="true"
    and eventName="ConfirmPublicVirtualInterface"
    and not aws.errorCode exists
  output: Data was transferred to a different AWS account 
          (requesting user=%aws.user, requesting IP=%aws.sourceIP, 
          AWS region=%aws.region, arn=%jevt.value[/userIdentity/arn],
          network acl id=%jevt.value[/requestParameters/networkAclId])
  priority: WARNING
  tags: [aws, exfiltration, transfer_data_to_cloud_account, T1537]
  source: aws_cloudtrailCode language: JavaScript (javascript)

This rule does not currently exist within the Falco community rules feed. 

By referencing this article from GorillaStack, we can easily reference the AWS event names. The event name ‘ConfirmPublicVirtualInterface’ is triggered when a public virtual interface has been created by another AWS account, and accepted. In our case, we want to be alerted when a connection is established to a different AWS account, the connection needs to be accepted. We do this through the ‘CreateConnection’ eventName ‘CreateConnection.’ More importantly, the data needs to be transferred to a different account. If the event value is set to egress=true, we know it’s outward facing connection to a different AWS account.

Conclusion

In conclusion, the Cloud Matrix of the MITRE ATT&CK framework provides immense benefits for open source security teams by offering a comprehensive, organized, and up-to-date representation of the threat landscape in cloud environments. 

The matrix acts as a roadmap for security teams, helping them understand the various attack techniques, tactics, and procedures used by adversaries and providing guidance on how to defend against them. By offering a clear and detailed understanding of the current security landscape, the Cloud Matrix of MITRE ATT&CK framework allows open source security teams to prioritize their efforts and resources to effectively mitigate potential security threats in their cloud environments.

Are you tired of manually sifting through logs and trying to piece together the security events happening in your AWS environment? Take control of your security today with Falco’s AWS CloudTrail plugin! This plugin leverages the powerful Falco intrusion detection system and seamlessly integrates with AWS CloudTrail to provide real-time visibility and alerts for suspicious activity. Whether it’s malicious insiders, misconfigured permissions, or external threats, Falco’s AWS CloudTrail plugin will help you stay ahead of the curve. Don’t wait any longer, take action now to secure your AWS environment. 

---

If you would like to contribute to the MITRE Rules alignment project for Falco, go ahead and join the Falco community today!
https://falco.org/community/