AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt

Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though no change occurred.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/04"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2026/06/04"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via
 11the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including
 12external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is
 13repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity
 14probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the
 15companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator
 16of credential boundary-testing even though no change occurred.
 17"""
 18false_positives = [
 19    """
 20    Access-denied errors can result from benign permission gaps: a newly created role or user whose IAM policy has not
 21    yet been provisioned, infrastructure-as-code pipelines running ahead of permission grants, or developers
 22    experimenting in non-production accounts. Verify whether the user identity, user agent, and source IP are expected
 23    to manage Bedrock resource policies in your environment. Recurring denials from known automation or onboarding
 24    workflows can be exempted from the rule.
 25    """,
 26]
 27from = "now-6m"
 28index = ["logs-aws.cloudtrail-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt"
 32note = """## Triage and analysis
 33
 34### Investigating AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt
 35
 36AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents,
 37knowledge bases, and custom models. An adversary who has compromised a credential may attempt to attach a policy
 38that grants an external principal access for persistence or cross-account access, or delete a policy to break
 39existing access controls. This rule detects `PutResourcePolicy` and `DeleteResourcePolicy` calls that were denied
 40(`AccessDenied` / unauthorized), which indicates an identity attempting an action it is not permitted to perform —
 41a strong signal of boundary-testing by a compromised or under-privileged principal even though the change did not
 42take effect.
 43
 44#### Possible investigation steps
 45
 46- **Identify the actor and context**
 47  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`,
 48    `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`.
 49  - Determine whether this identity has any legitimate reason to manage Bedrock resource policies. A denial for an
 50    identity that should never touch these APIs is more suspicious than one from an admin with a transient gap.
 51- **Assess the attempt**
 52  - Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason.
 53  - For `PutResourcePolicy`, review `aws.cloudtrail.request_parameters` and
 54    `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the attempted policy document.
 55    Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles.
 56- **Correlate activity**
 57  - Look for repeated denials across Bedrock or IAM APIs from the same identity, which can indicate permission
 58    enumeration or escalation attempts.
 59  - Check whether the identity later succeeded (e.g., after acquiring new permissions) on the same or related
 60    resources, and review any IAM changes in the surrounding window.
 61
 62### False positive analysis
 63
 64- **Permission gaps**: Newly provisioned roles/users or IaC pipelines running before policy grants are applied may
 65  generate transient denials. Validate against change tickets and known automation.
 66- **Exploration in non-production**: Developers testing in sandbox accounts may hit denials. Confirm the account and
 67  identity context.
 68
 69### Response and remediation
 70
 71- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials in
 72  `aws.cloudtrail.user_identity.access_key_id` and review the actor's recent activity.
 73- Review all Bedrock and IAM activity from the same identity in the surrounding time window for successful access
 74  grants, permission changes, or other persistence attempts.
 75- Confirm least-privilege on `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy`, and alert on both denied
 76  and successful calls.
 77"""
 78references = [
 79    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html",
 80    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html"
 81]
 82risk_score = 21
 83rule_id = "2e99477f-6099-48a9-ae0e-68801d97079c"
 84severity = "low"
 85tags = [
 86    "Domain: Cloud",
 87    "Domain: LLM",
 88    "Data Source: AWS",
 89    "Data Source: AWS CloudTrail",
 90    "Data Source: Amazon Web Services",
 91    "Data Source: Amazon Bedrock",
 92    "Use Case: Identity and Access Audit",
 93    "Resources: Investigation Guide",
 94    "Tactic: Persistence",
 95]
 96timestamp_override = "event.ingested"
 97type = "query"
 98
 99query = '''
100data_stream.dataset: "aws.cloudtrail" and
101    event.provider: "bedrock.amazonaws.com" and
102    event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and
103    event.outcome: "failure" and
104    aws.cloudtrail.error_code: (
105        "AccessDenied" or
106        "AccessDeniedException"
107    )
108'''
109
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112
113[[rule.threat.technique]]
114id = "T1098"
115name = "Account Manipulation"
116reference = "https://attack.mitre.org/techniques/T1098/"
117
118[rule.threat.tactic]
119id = "TA0003"
120name = "Persistence"
121reference = "https://attack.mitre.org/tactics/TA0003/"
122
123[rule.investigation_fields]
124field_names = [
125    "@timestamp",
126    "user.name",
127    "user_agent.original",
128    "source.ip",
129    "aws.cloudtrail.user_identity.arn",
130    "aws.cloudtrail.user_identity.type",
131    "aws.cloudtrail.user_identity.access_key_id",
132    "event.action",
133    "event.provider",
134    "event.outcome",
135    "aws.cloudtrail.error_code",
136    "cloud.account.id",
137    "cloud.region",
138    "aws.cloudtrail.request_parameters",
139    "aws.cloudtrail.response_elements",
140]

Triage and analysis

Investigating AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt

AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents, knowledge bases, and custom models. An adversary who has compromised a credential may attempt to attach a policy that grants an external principal access for persistence or cross-account access, or delete a policy to break existing access controls. This rule detects PutResourcePolicy and DeleteResourcePolicy calls that were denied (AccessDenied / unauthorized), which indicates an identity attempting an action it is not permitted to perform — a strong signal of boundary-testing by a compromised or under-privileged principal even though the change did not take effect.

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, user_agent.original, and source.ip.
    • Determine whether this identity has any legitimate reason to manage Bedrock resource policies. A denial for an identity that should never touch these APIs is more suspicious than one from an admin with a transient gap.
  • Assess the attempt
    • Inspect aws.cloudtrail.error_code and aws.cloudtrail.error_message to confirm the denial reason.
    • For PutResourcePolicy, review aws.cloudtrail.request_parameters and aws.cloudtrail.flattened.request_parameters for the target resource ARN and the attempted policy document. Look for Principal values referencing external AWS account IDs, "*", or unfamiliar roles.
  • Correlate activity
    • Look for repeated denials across Bedrock or IAM APIs from the same identity, which can indicate permission enumeration or escalation attempts.
    • Check whether the identity later succeeded (e.g., after acquiring new permissions) on the same or related resources, and review any IAM changes in the surrounding window.

False positive analysis

  • Permission gaps: Newly provisioned roles/users or IaC pipelines running before policy grants are applied may generate transient denials. Validate against change tickets and known automation.
  • Exploration in non-production: Developers testing in sandbox accounts may hit denials. Confirm the account and identity context.

Response and remediation

  • If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials in aws.cloudtrail.user_identity.access_key_id and review the actor's recent activity.
  • Review all Bedrock and IAM activity from the same identity in the surrounding time window for successful access grants, permission changes, or other persistence attempts.
  • Confirm least-privilege on bedrock:PutResourcePolicy and bedrock:DeleteResourcePolicy, and alert on both denied and successful calls.

References

Related rules

to-top