[New Rule] AWS SageMaker Execution Role Passed by Unusual Principal

[bryans3c]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/921
• https://github.com/elastic/ia-trade-team/issues/1012

Summary - What I changed

Added ES|QL rule that fires the first time an IAM principal passes a specific execution role (roleArn) to a SageMaker resource-creation call (CreateNotebookInstance, CreateTrainingJob, CreateProcessingJob, CreateAutoMLJob, CreatePipeline) it hasn't used in the last 7 days.

Why it matters

These actions require iam:PassRole and attach a role the created resource then runs as, a known cloud privilege-escalation path when combined with a broad PassRole grant. roleArn only exists inside the Go-map-formatted request_parameters string, and Elasticsearch doesn't expose flattened sub-keys as independently aggregatable fields, so a native new_terms rule can't key on it. The query extracts roleArn with GROK and hand-rolls the first-occurrence comparison (7-day scan, alert only when the earliest occurrence of a given principal+role pair falls in the last 10 minutes).

Live-fire verified: created a real SageMaker notebook with a role never used before by that identity and confirmed it was correctly flagged.

• https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html
• https://stratus-red-team.cloud/attack-techniques/AWS/aws.execution.sagemaker-update-lifecycle-config/

How To Test

Query can be used in TRADE stack and other telemetry stacks.

Checklist

• Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[Copilot]

Pull request overview

Adds a new production ES|QL detection rule to identify “first seen in 7 days” usage of an Amazon SageMaker execution role (roleArn) passed via iam:PassRole, which can indicate privilege escalation risk when unusual principals begin using new or more-privileged roles.

Changes:

• Introduces a new ES|QL rule that extracts roleArn from aws.cloudtrail.request_parameters via GROK.
• Implements first-occurrence logic by aggregating over a 7-day window and alerting only when the earliest observation of a (principal, roleArn) pair is within the last 10 minutes.
• Adds investigation guide content, tags, and ATT&CK mapping for triage context.

[eric-forte-elastic]

Suggested change

	| GROK aws.cloudtrail.request_parameters """.*roleArn=(?<Esql.aws_cloudtrail_request_parameters_role_arn>arn:aws:iam::[0-9]{12}:role/[^,}]+).*"""
	| GROK aws.cloudtrail.request_parameters """.*roleArn=(?<Esql.aws_cloudtrail_request_parameters_role_arn>arn:aws[a-z-]*:iam::[0-9]{12}:role/[^,}]+).*"""

May want to do to support govcloud, other non-commercial regions, etc.