[Rule Tuning] AWS Access Token Used from Multiple Addresses - possible Defender for Cloud Apps

[richlv]

Link to Rule

https://github.com/elastic/detection-rules/blob/main/rules/integrations/aws/initial_access_iam_session_token_used_from_multiple_addresses.toml

Rule Tuning Type

False Positives - Reducing benign events mistakenly identified as threats.

Description

Seeing alerts from the "AWS Access Token Used from Multiple Addresses" rule where the source addresses are in Microsoft networks, user is CloudAppSecurityAWS. This seems to be "Defender for Cloud Apps". If so, that might be worth excluding.

Potentially relevant fields:

Esql.aws_cloudtrail_user_identity_arn_values arn:aws:iam::<id>:user/CloudAppSecurityAWS

Example Data

No response

[imays11]

@richlv Do you have any sample data you could share showing this?

[richlv]

Large chunks of data would be complicated to review for sensitive info - any particular fields that would be useful?

[imays11]

Perhaps some of the criteria causing the alerts associated with that identity, I'm looking for something that could be excluded globally as I don't have any telemetry data related to that Identity arn. Maybe Esql.activity_type for context and Esql.event_action_values, Esql.event_provider_values, Esql.source_network_org_name_values for possible exclusion criteria?

[richlv]

Sure, here they are from one example alert:

Esql.activity_type multiple_ip_and_user_agent Esql.event_action_values LookupEvents ListUsers GetUser ListBuckets GetBucketAcl GetBucketLocation Esql.event_provider_values cloudtrail.amazonaws.com iam.amazonaws.com s3.amazonaws.com Esql.source_network_org_name_values MICROSOFT-CORP-MSN-AS-BLOCK

[imays11]

Thank you, I may not be able to outright exclude that network but there may be some combination of network+event.provider+user agent values that can safely be excluded, I'll do some research and put in a tuning if possible. Can you provide the user agents associated with the alerts as well?

[richlv]

Sorry about the delay, we added our own temporary exceptions, so this slipped from radar. User agents for this account:

[aws-sdk-java/1.12.528 Linux/6.6.104.2-1.azl3 OpenJDK_64-Bit_Server_VM/25.462-b08 java/1.8.0_462 kotlin/1.8.0 vendor/Temurin cfg/retry-mode/legacy, [aws-sdk-java/1.12.528 Linux/6.6.104.2-1.azl3 OpenJDK_64-Bit_Server_VM/25.462-b08 java/1.8.0_462 kotlin/1.8.0 vendor/Temurin cfg/retry-mode/legacy]]

Another user account that might be useful to exclude in the same go - arn:aws:iam::<id>:user/AzureADRoleManager. For this one, user agent seems to have only the following (although hard to be sure, the alert ESQL fields are unmapped and very hard to use).

aws-sdk-dotnet-45/3.3.9.10 aws-sdk-dotnet-core/3.3.31.2 .NET_Runtime/4.0 .NET_Framework/4.0 OS/Microsoft_Windows_NT_6.2.9200.0 ClientAsync Please let me know if you prefer a separate issue for this, though.

[imays11]

@richlv Thank you for your feedback, it's hard to exclude that network and those user agents globally. I think your local exclusions are the best option. Globally, I think the best way to go about tuning this rule is to remove the "low" and "medium" severity combinations so these combinations would not produce an alert, but there will still be the option to duplicate the rule and include these combinations as BBR rules or lower fidelity signals.

So don't alert on...

    Esql.activity_type == "multiple_ip_and_city", "medium",
    Esql.activity_type == "multiple_ip_and_network", "medium",
    Esql.activity_type == "multiple_ip_and_user_agent", "low"

and only alert on...

    Esql.activity_type == "multiple_ip_network_city_user_agent", "high",
    Esql.activity_type == "multiple_ip_network_city", "high",

How would this work in your environment?

[imays11]

A rule tuning has been created to address the noise level for this rule. I was not able to explicitly exclude any additional networks, local exclusions are best for this as it can be combined with more specific identity information (i.e. role names). However, I did reduce the scope of the alerts for this rule to only capture high fidelity score cases, while leaving the rest of the rule logic intact with a comment in the query on how to broaden the scope locally if desired. I will continue to track the outcome of this tuning and reassess further tuning if necessary.

[richlv]

Sounds great, thank you :)