AWS IAM Credentials Added to a Bedrock API Key Phantom User
Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with
"BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile
(CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS
silently provisions a "BedrockAPIKey-
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/07/06"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2026/07/06"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with
11"BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile
12(CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS
13silently provisions a "BedrockAPIKey-<id>" IAM user with the AmazonBedrockLimitedAccess managed policy. That user is
14intended only to back a Bedrock bearer token and should never hold standard programmatic keys or interactive console
15access. Adding either converts a Bedrock-scoped identity into general-purpose IAM credentials that inherit the policy's
16Bedrock control-plane and IAM, VPC, and KMS reconnaissance permissions and that persist after the Bedrock API key is
17revoked. This is the privilege-escalation and persistence pivot documented for Bedrock API key phantom users, and there
18is no legitimate workflow that produces it.
19"""
20false_positives = [
21 """
22 There is no known legitimate workflow that adds IAM access keys or console login profiles to a Bedrock API key phantom
23 user. Any match should be investigated. Confirm the actor in "aws.cloudtrail.user_identity.arn" and the target user in
24 "aws.cloudtrail.request_parameters", and remove the credential if it was not expected.
25 """,
26]
27from = "now-30m"
28language = "esql"
29license = "Elastic License v2"
30name = "AWS IAM Credentials Added to a Bedrock API Key Phantom User"
31note = """## Triage and analysis
32
33### Investigating AWS IAM Credentials Added to a Bedrock API Key Phantom User
34
35Amazon Bedrock API keys authenticate with a bearer token. When a long-term key is created through the AWS Console, AWS provisions an IAM user named "BedrockAPIKey-<id>" and attaches the AmazonBedrockLimitedAccess managed policy. That policy is broader than its name suggests: it grants Bedrock control-plane actions (including deletion of guardrails, custom models, and provisioned throughput) as well as IAM, VPC, and KMS reconnaissance. The phantom user is meant only to back the bearer token and should never hold standard access keys or an interactive console login.
36
37Adding an IAM access key (CreateAccessKey) or a console password (CreateLoginProfile/UpdateLoginProfile) to the phantom user escalates a Bedrock-scoped identity into general-purpose IAM credentials or interactive access that inherit the full policy scope and continue to work after the originating Bedrock API key is revoked. This is a deliberate privilege-escalation and persistence step.
38
39### Possible investigation steps
40
41- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for whether this is an expected administrator.
42- Confirm the target phantom user and the credential type in "event.action" and "aws.cloudtrail.request_parameters", and enumerate the user's remaining credentials (service-specific credentials, access keys, login profile).
43- Review the phantom user's subsequent activity for use of the new credential outside Bedrock (IAM, VPC, KMS, STS calls, or console logins).
44- Correlate with the key-creation events (CreateUser and CreateServiceSpecificCredential for the same user) to reconstruct the timeline.
45
46### False positive analysis
47
48- This should be near-zero. There is no standard workflow that adds access keys or login profiles to a "BedrockAPIKey-*" user. Treat any hit as suspicious until proven otherwise.
49
50### Response and remediation
51
52- Remove the access key or login profile on the phantom user and, if compromise is suspected, deactivate or delete the associated Bedrock service-specific credential.
53- Review the actor's recent activity and rotate or restrict its credentials.
54- Deploy a Service Control Policy that denies "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam::*:user/BedrockAPIKey-*" to block this pivot organization-wide.
55"""
56references = [
57 "https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response",
58 "https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys",
59 "https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html",
60]
61risk_score = 73
62rule_id = "71159cad-f8b3-4b3c-ac6e-9cab05594670"
63setup = "This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details."
64severity = "high"
65tags = [
66 "Domain: Cloud",
67 "Data Source: AWS",
68 "Data Source: Amazon Web Services",
69 "Data Source: AWS IAM",
70 "Data Source: Amazon Bedrock",
71 "Use Case: Threat Detection",
72 "Tactic: Privilege Escalation",
73 "Tactic: Persistence",
74 "Resources: Investigation Guide",
75]
76timestamp_override = "event.ingested"
77type = "esql"
78
79query = '''
80FROM logs-aws.cloudtrail-* METADATA _id, _version, _index
81| WHERE event.provider == "iam.amazonaws.com"
82 AND event.action IN ("CreateAccessKey", "CreateLoginProfile", "UpdateLoginProfile")
83 AND event.outcome == "success"
84 AND user.target.name LIKE "BedrockAPIKey-*"
85| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.*
86'''
87
88
89[[rule.threat]]
90framework = "MITRE ATT&CK"
91[[rule.threat.technique]]
92id = "T1098"
93name = "Account Manipulation"
94reference = "https://attack.mitre.org/techniques/T1098/"
95[[rule.threat.technique.subtechnique]]
96id = "T1098.001"
97name = "Additional Cloud Credentials"
98reference = "https://attack.mitre.org/techniques/T1098/001/"
99
100[rule.threat.tactic]
101id = "TA0004"
102name = "Privilege Escalation"
103reference = "https://attack.mitre.org/tactics/TA0004/"
104
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107[[rule.threat.technique]]
108id = "T1098"
109name = "Account Manipulation"
110reference = "https://attack.mitre.org/techniques/T1098/"
111[[rule.threat.technique.subtechnique]]
112id = "T1098.001"
113name = "Additional Cloud Credentials"
114reference = "https://attack.mitre.org/techniques/T1098/001/"
115
116[rule.threat.tactic]
117id = "TA0003"
118name = "Persistence"
119reference = "https://attack.mitre.org/tactics/TA0003/"
Triage and analysis
Investigating AWS IAM Credentials Added to a Bedrock API Key Phantom User
Amazon Bedrock API keys authenticate with a bearer token. When a long-term key is created through the AWS Console, AWS provisions an IAM user named "BedrockAPIKey-
Adding an IAM access key (CreateAccessKey) or a console password (CreateLoginProfile/UpdateLoginProfile) to the phantom user escalates a Bedrock-scoped identity into general-purpose IAM credentials or interactive access that inherit the full policy scope and continue to work after the originating Bedrock API key is revoked. This is a deliberate privilege-escalation and persistence step.
Possible investigation steps
- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for whether this is an expected administrator.
- Confirm the target phantom user and the credential type in "event.action" and "aws.cloudtrail.request_parameters", and enumerate the user's remaining credentials (service-specific credentials, access keys, login profile).
- Review the phantom user's subsequent activity for use of the new credential outside Bedrock (IAM, VPC, KMS, STS calls, or console logins).
- Correlate with the key-creation events (CreateUser and CreateServiceSpecificCredential for the same user) to reconstruct the timeline.
False positive analysis
- This should be near-zero. There is no standard workflow that adds access keys or login profiles to a "BedrockAPIKey-*" user. Treat any hit as suspicious until proven otherwise.
Response and remediation
- Remove the access key or login profile on the phantom user and, if compromise is suspected, deactivate or delete the associated Bedrock service-specific credential.
- Review the actor's recent activity and rotate or restrict its credentials.
- Deploy a Service Control Policy that denies "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam:::user/BedrockAPIKey-" to block this pivot organization-wide.
References
Related rules
- AWS IAM Inline Policy Added to a Group
- AWS IAM Sensitive Operations via Lambda Execution Role
- AWS Sensitive IAM Operations Performed via CloudShell
- AWS IAM Permissions Boundary Modified or Removed
- AWS Bedrock Agent Created by IAM User or Root