[Rule Tuning] AWS STS AssumeRole with New MFA Device (#4999)

* [Rule Tuning] AWS STS AssumeRole with New MFA Device

This rule is triggering as expected and low volume of alerts in telemetry. This tuning:
- slight edits to IG
- removed user.id wildcard usage in query as this field always exists for these events
- added the from and interval fields for consistency across rules (they are currently using the same values by default so no real change here)

* adding investigation fields

adding investigation fields

Author: imays11

rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml

@@ -2,7 +2,7 @@
 creation_date = "2024/10/25"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/08/20"
 
 
 [rule]
@@ -14,7 +14,9 @@ While a new MFA device is not always indicative of malicious behavior it should
 false_positives = [
     "AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes and to perform periodic tasks such as data backups, updates, or deployments.",
 ]
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "5m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS STS AssumeRole with New MFA Device"
@@ -29,10 +31,10 @@ AWS Security Token Service (STS) allows users to assume roles and gain temporary
 
 ### Possible investigation steps
 
-- Review the event details in AWS CloudTrail to identify the user who assumed the role, focusing on the user.id field to determine if the user is legitimate and authorized to use the new MFA device.
-- Check the serialNumber in the aws.cloudtrail.flattened.request_parameters to verify the registration and legitimacy of the new MFA device associated with the role assumption.
-- Investigate the context of the AssumeRole action by examining the event.action field to understand if it was part of a legitimate workflow or an unusual activity.
-- Analyze the event.outcome field to confirm the success of the role assumption and cross-reference with any recent changes in user permissions or MFA device registrations.
+- Review the event details in AWS CloudTrail to identify the user who assumed the role, focusing on the `user.id` or `aws.cloudtrail.user_identity.arn` field to determine if the user is legitimate and authorized to use the new MFA device.
+- Check the serialNumber in `aws.cloudtrail.request_parameters` to verify the registration and legitimacy of the new MFA device associated with the role assumption.
+- Investigate the context of the AssumeRole action by examining surrounding events to understand if it was part of a legitimate workflow or an unusual activity.
+- Cross-reference with any recent changes in user permissions or MFA device registrations.
 - Correlate the event with other logs or alerts to identify any patterns of suspicious behavior, such as multiple role assumptions or changes in MFA devices within a short timeframe.
 - Contact the user or relevant team to confirm if the new MFA device registration and role assumption were expected and authorized.
 
@@ -83,10 +85,27 @@ event.dataset:aws.cloudtrail
     and event.provider:sts.amazonaws.com
     and event.action:(AssumeRole or AssumeRoleWithSAML or AssumeRoleWithWebIdentity)
     and event.outcome:success
-    and user.id:*
     and aws.cloudtrail.flattened.request_parameters.serialNumber:*
 '''
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "aws.cloudtrail.resources.arn",    
+    "aws.cloudtrail.resources.type",   
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+    "aws.cloudtrail.response_elements"
+]
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"