Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,131 @@
[[prebuilt-rule-8-19-32-aws-bedrock-agentcore-resource-created-with-iam-execution-role]]
=== AWS Bedrock AgentCore Resource Created with IAM Execution Role

Detects the creation of an AWS Bedrock AgentCore resource (code interpreter, agent runtime, browser, or harness) with an IAM execution role attached. When an attacker with iam:PassRole permission creates an AgentCore resource and attaches a privileged role, subsequent invocations inside that resource execute as the attached role — enabling privilege escalation to roles that trust bedrock-agentcore.amazonaws.com.

*Rule type*: query

*Rule indices*:

* logs-aws.cloudtrail-*

*Severity*: medium

*Risk score*: 47

*Runs every*: 5m

*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://www.beyondtrust.com/blog/entry/aws-agentcore-privilege-escalation

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Platform: AWS
* Data Source: AWS CloudTrail
* Service: AWS Bedrock
* Service: AWS IAM
* Tactic: Privilege Escalation
* Tactic: Persistence
* Rule Type: Custom Query (KQL)
* Resources: Investigation Guide

*Version*: 1

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*Triage and analysis*



*Investigating AWS Bedrock AgentCore Resource Created with IAM Execution Role*


AWS Bedrock AgentCore services (code interpreters, agent runtimes, browsers, harnesses) run user workloads inside isolated MicroVMs. When an IAM role is attached at creation time, all code executing inside the resource assumes that role's identity. An attacker with iam:PassRole and bedrock-agentcore:Create* permissions can attach a privileged role and then invoke the resource to operate as that role.

The four Create* events covered here are management-plane events logged to CloudTrail by default. The subsequent Start*/Invoke* data-plane events are NOT captured by the default management events trail and cannot be detected without enabling data-plane logging.


*Possible investigation steps*


- Check the caller identity (`aws.cloudtrail.user_identity.arn`) against expected provisioning principals. Unexpected users or roles creating AgentCore resources should be investigated.
- Examine `aws.cloudtrail.request_parameters` for the attached role ARN (`executionRoleArn` or `roleArn`) and evaluate whether that role has permissions beyond what the AgentCore workload legitimately requires.
- Check for subsequent `StartCodeInterpreterSession`, `StartBrowserSession`, or `InvokeAgentRuntime` events from the same caller against the newly created resource (requires data-plane logging to be enabled).
- Review the IAM PassRole permission of the calling identity and whether it is constrained by `iam:PassedToService` conditions.


*False positive analysis*


- Automated provisioning by CDK/CloudFormation/Terraform with a known service account.
- Platform engineering pipelines deploying Bedrock-based AI workloads.
- Filter on `user_agent.original` for known IaC tools.


*Response and remediation*


- Suspend the calling identity's iam:PassRole permission while investigating.
- Delete the newly created AgentCore resource to stop active sessions.
- Rotate the attached execution role's credentials if exploitation is confirmed.
- Enable data-plane logging for bedrock-agentcore to detect subsequent session invocations.


==== Rule query


[source, js]
----------------------------------
event.dataset: "aws.cloudtrail" and
event.provider: "bedrock-agentcore.amazonaws.com" and
event.action: (
"CreateCodeInterpreter" or
"CreateAgentRuntime" or
"CreateBrowser" or
"CreateHarness"
) and
event.outcome: "success" and
aws.cloudtrail.request_parameters: (*executionRoleArn* or *roleArn*) and
not aws.cloudtrail.user_identity.invoked_by: ("bedrock-agentcore.amazonaws.com" or "cloudformation.amazonaws.com")

----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Privilege Escalation
** ID: TA0004
** Reference URL: https://attack.mitre.org/tactics/TA0004/
* Technique:
** Name: Valid Accounts
** ID: T1078
** Reference URL: https://attack.mitre.org/techniques/T1078/
* Sub-technique:
** Name: Cloud Accounts
** ID: T1078.004
** Reference URL: https://attack.mitre.org/techniques/T1078/004/
* Tactic:
** Name: Persistence
** ID: TA0003
** Reference URL: https://attack.mitre.org/tactics/TA0003/
* Technique:
** Name: Account Manipulation
** ID: T1098
** Reference URL: https://attack.mitre.org/techniques/T1098/
Original file line number Diff line number Diff line change
@@ -0,0 +1,127 @@
[[prebuilt-rule-8-19-32-aws-bedrock-guardrail-deleted-or-weakened]]
=== AWS Bedrock Guardrail Deleted or Weakened

Detects deletion, weakening, or version management of AWS Bedrock guardrails via the DeleteGuardrail, UpdateGuardrail, DeleteEnforcedGuardrailConfiguration, or PutEnforcedGuardrailConfiguration APIs. Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model invocations. Deleting a guardrail, loosening its policies, removing or overwriting the organization-enforced guardrail configuration, or creating a new version to enforce a weakened configuration allows an adversary to bypass these protections — the cloud control-plane equivalent of disabling a security tool. This activity should be validated against approved change management and the responsible identity.

*Rule type*: query

*Rule indices*:

* logs-aws.cloudtrail-*

*Severity*: medium

*Risk score*: 47

*Runs every*: 5m

*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteGuardrail.html
* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateGuardrail.html
* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html

*Tags*:

* Domain: Cloud
* Domain: GenAI
* Platform: AWS
* Data Source: AWS CloudTrail
* Service: AWS Bedrock
* Tactic: Defense Evasion
* Rule Type: Custom Query (KQL)
* Resources: Investigation Guide

*Version*: 2

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*Triage and analysis*



*Investigating AWS Bedrock Guardrail Deleted or Weakened*


AWS Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model
invocations. Adversaries who gain access to the Bedrock control plane may delete a guardrail (`DeleteGuardrail`),
loosen its policies (`UpdateGuardrail`), remove or overwrite the organization-enforced guardrail
configuration (`DeleteEnforcedGuardrailConfiguration` / `PutEnforcedGuardrailConfiguration`) to then enforce it on
model deployments. This detection identifies those control-plane changes so responders can confirm
intent before accepting the change.


*Possible investigation steps*


- **Identify the actor and context**
- Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`,
`aws.cloudtrail.user_identity.access_key_id`, `source.ip`, and `user_agent.original`.
- Confirm a related change request exists and that the identity is authorized to manage guardrails.
- **Validate the change**
- For `UpdateGuardrail` / `PutEnforcedGuardrailConfiguration`, inspect
`aws.cloudtrail.flattened.request_parameters` and `aws.cloudtrail.response_elements` to determine
which content, topic, word, or sensitive-information policies were removed or weakened.
- For `DeleteGuardrail` / `DeleteEnforcedGuardrailConfiguration`, identify the targeted guardrail
or org configuration and whether protected workloads still reference it.
- **Correlate activity**
- Look for surrounding Bedrock `InvokeModel` / `Converse` activity and other defense-impairing
actions (e.g., logging or detector changes) from the same identity.
- Check for prior enumeration such as `ListGuardrails` or `GetGuardrail`.


*Response and remediation*


- If unauthorized, restore the guardrail and/or org-enforced configuration to its approved state and
re-associate it with affected Bedrock workloads.
- Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and review the actor's
recent activity; rotate credentials if compromise is suspected.
- Restrict `bedrock:DeleteGuardrail`, `bedrock:UpdateGuardrail`, and the enforced-configuration
permissions to a small set of admin roles, and enforce guardrail state via AWS Config or SCPs.


==== Rule query


[source, js]
----------------------------------
data_stream.dataset: "aws.cloudtrail"
and event.provider: "bedrock.amazonaws.com"
and event.action: (
"DeleteGuardrail" or
"UpdateGuardrail" or
"DeleteEnforcedGuardrailConfiguration" or
"PutEnforcedGuardrailConfiguration"
) and event.outcome: "success"
and not user_agent.original: (*Terraform*)

----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Defense Evasion
** ID: TA0005
** Reference URL: https://attack.mitre.org/tactics/TA0005/
* Technique:
** Name: Impair Defenses
** ID: T1562
** Reference URL: https://attack.mitre.org/techniques/T1562/
* Sub-technique:
** Name: Disable or Modify Tools
** ID: T1562.001
** Reference URL: https://attack.mitre.org/techniques/T1562/001/
Loading
Loading