Announcing the enhanced Microsoft Sentinel AWS CloudTrail solution, powered by new MITRE-Based Rules

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Use the updated Microsoft Sentinel AWS CloudTrail solution to better protect your AWS environment. The updated solution includes over 70 MITRE-based rules, and monitoring and alerting capabilities to detect suspicious activity in your environment. 

With the AWS CloudTrail solution, you can:  

• Detect and monitor your AWS environment 

• Threat hunt for anomalous behavior, and malicious activity  
• Identify suspicious events 

MITRE ATT&CK Framework: 

MITRE is the world standard knowledge base of adversary tactics and techniques based on real-world observations. The framework groups attack techniques into categories based on the MITRE Kill Chain process. This process helps organizations understand the techniques that attackers could use in any phase of the attack. 

Here is the MITRE ATT&CK Matrix for Enterprise, covering cloud-based tactics and techniques: 

Learn more about the MITRE Cloud Matrix.

Mapping MITRE 

Every rule in this solution maps to one of the MITRE Kill Chain process categories, based on the techniques that this rule is trying to detect. Here are a few examples of techniques that the updated solution covers: 

Privilege Escalation:

• An attacker could use AttachUserPolicy/AttachGroupPolicy/AttachRolePolicy permissions to attach another entity's permissions to their user. The permissions are defined by the attached policy. The attacker can then use these higher permissions for attack purposes.  
• An attacker could use the CreatePolicyVersion permission to modify customer-managed policies and then elevate a non-privileged entity to a privileged one. 

Impact:

• An attacker could use the BucketVersioningSuspend API to ransom buckets, where the victim has no backup option. 

Defense Evasion:  

• An attacker could disable GuardDuty detectors for defense evasion purposes.  

In alerts where a technique could fit a few categories, we had to consider which category to use: 

For example, an attacker with the CreateAccessKey permission could create an IAM Access and Secret Key for other users. This would allow the attacker to create credentials for more privileged users and obtain persistence or escalate privileges. Eventually, we categorized this alert as persistence, because we saw that attackers used this technique more often than for privilege escalation. In another scenario, we could have categorized the alert as privileged escalation. 

Here is an example of the usage of this permission: 

In the example, we use CreateAccessKey permissions to create a new Secret and Access Key for the admin_test admin user. 

Hunting queries 

This solution includes over 30 new hunting queries, that you can use to hunt for threats, anomalous activities, and suspicious events. Here are some examples: 

• Suspicious Activity of STS Token related to EC2: The AWS Security Token Service (STS) is a web service that you can use to request temporary AWS credentials.  This query detects suspicious activity of the STS token for an EC2 machine hosted by ECS. The query results indicates suspected token hijacking: an attacker may have stolen the token and could abuse its permissions to escalate privileges and move laterally in the cloud. 

• Risky Role Name Created: Attackers sometimes use a malicious framework to attack the victim’s cloud environment. This query detects the creation of suspicious role names , indicating that an attacker may have executed a malicious framework in your environment. 

Here is an example of the “Suspicious Activity of STS related to EC2” hunting query: 

let aws_public_ips = externaldata(prefixes: string)
    [
       h@'https://awspublicipaddresses.blob.core.windows.net/aws-public-ip-addresses/ip-ranges.json'
    ]
    with(format='multijson');
    let timeframe = 30m;
    let lookback = 12h;
    //Get the AccessKey in the STS token (IMDS) when EC2 service assumes the Role periodically
    let sts_token = AWSCloudTrail
    | where TimeGenerated >= ago (lookback)
    | where EventSource == "sts.amazonaws.com" and SourceIpAddress == "ec2.amazonaws.com"
    | extend instanceId = tostring(parse_json(RequestParameters).roleSessionName)
    | extend token = tostring(parse_json(ResponseElements).credentials.accessKeyId);
    //Identify if the EC2 belongs to ECS/EKS
    let typeOfEC2 = AWSCloudTrail
    | where TimeGenerated >= ago (lookback)
    | extend instanceId = tostring(split(UserIdentityPrincipalid, ":")[1])
    | join sts_token on instanceId
    | where UserAgent !startswith "kubernetes" or UserAgent !startswith "Amazon ECS Agent"
    | project-away SourceIpAddress1, UserIdentityUserName1, UserIdentityArn1, TimeGenerated1;
    //Get the identities who used that STS token - this can be the EC2 which assumed it (legit),
    //but it can also be an external identity (attacker) which abuses the token permissions
    let tokenUsage = AWSCloudTrail
    | where TimeGenerated >= ago (timeframe)
    | join kind=inner typeOfEC2 on $left.UserIdentityAccessKeyId == $right.token
    | extend region = AWSRegion
    | project-away SourceIpAddress1, UserIdentityUserName1, UserIdentityArn1, TimeGenerated1;
    //Check whether the called identity is legit
    aws_public_ips
    | mv-expand todynamic(prefixes)
    | extend ip_prefix=tostring(todynamic(prefixes.['ip_prefix']))
    | extend region=tostring(todynamic(prefixes.['region']))
    | extend service=tostring(todynamic(prefixes.['service']))
    | project-away prefixes
    | where service == "EC2"
    | join kind=inner tokenUsage on region
    | where SourceIpAddress !contains "amazonaws.com"
    | where ipv4_is_private(SourceIpAddress) == false
    | extend IsInRange = ipv4_is_in_range(SourceIpAddress, ip_prefix)
    | extend UserIdentityUserName = iff(isnotempty(UserIdentityUserName), UserIdentityUserName, tostring(split(UserIdentityArn,'/')[-1]))
    | extend timestamp = TimeGenerated, IPCustomEntity = SourceIpAddress, AccountCustomEntity = UserIdentityUserName, AssumedRoleArn = UserIdentityArn
    | summarize timestamp=arg_max(timestamp,*), r = make_set(IsInRange) by SourceIpAddress, UserIdentityUserName, UserIdentityArn
    | where not (set_has_element(r, true))
    | project-away ip_prefix, IsInRange

Install the AWS CloudTrail solution 

1. In Microsoft Sentinel Content Hub blade, search for “Amazon Web Services”, and select Install. 
2. Review the solution content: 
   1. In the Analytics blade, search for “AWS”.  
      1. This displays all the new analytics rules installed as part of the solution. You can use, start, or stop the rules. 
   2. In the Hunting blade, search for “AWS”. 
      1. This displays all the new hunting queries installed as part of the solution. You can use, start, or stop the queries. 

Learn more about the AWS CloudTrail solution – Github and how to Connect Microsoft Sentinel to Amazon Web Services to ingest AWS service log data 

AWS CloudTrail solution alerts and severity levels