Detection rules › Splunk

ASL AWS Create Access Key

Status
production
Group by
"actor.user.account.uid", "actor.user.uid", "api.operation", "api.service.name", "cloud.provider", "cloud.region", "http_request.user_agent", "src_endpoint.ip"
Author
Patrick Bareiss, Splunk
Source
github.com/splunk/security_content

The following analytic identifies the creation of AWS IAM access keys by a user for another user, which can indicate privilege escalation. It leverages AWS CloudTrail logs to detect instances where the user creating the access key is different from the user for whom the key is created. This activity is significant because unauthorized access key creation can allow attackers to establish persistence or exfiltrate data via AWS APIs. If confirmed malicious, this could lead to unauthorized access to AWS services, data exfiltration, and long-term persistence in the environment.

Known false positives

  • While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user.

MITRE ATT&CK coverage

TacticTechniques
Persistence

Telemetry coverage

Rules detecting the same action

These rules filter on the same operation.

Rule body

name: ASL AWS Create Access Key
id: 81a9f2fe-1697-473c-af1d-086b0d8b63c8
version: 7
creation_date: '2021-03-02'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: Hunting
description: The following analytic identifies the creation of AWS IAM access keys by a user for another user, which can indicate privilege escalation. It leverages AWS CloudTrail logs to detect instances where the user creating the access key is different from the user for whom the key is created. This activity is significant because unauthorized access key creation can allow attackers to establish persistence or exfiltrate data via AWS APIs. If confirmed malicious, this could lead to unauthorized access to AWS services, data exfiltration, and long-term persistence in the environment.
data_source:
    - ASL AWS CloudTrail
search: |-
    `amazon_security_lake` api.operation=CreateAccessKey
      | fillnull
      | stats count min(_time) as firstTime max(_time) as lastTime
        BY actor.user.uid api.operation api.service.name
           http_request.user_agent src_endpoint.ip actor.user.account.uid
           cloud.provider cloud.region
      | rename actor.user.uid as user api.operation as action api.service.name as dest http_request.user_agent as user_agent src_endpoint.ip as src actor.user.account.uid as vendor_account cloud.provider as vendor_product cloud.region as vendor_region
      | `security_content_ctime(firstTime)`
      | `security_content_ctime(lastTime)`
      | `asl_aws_create_access_key_filter`
how_to_implement: The detection is based on Amazon Security Lake events from Amazon Web Services (AWS), which is a centralized data lake that provides security-related data from AWS services. To use this detection, you must ingest CloudTrail logs from Amazon Security Lake into Splunk. To run this search, ensure that you ingest events using the latest version of Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) or the Federated Analytics App.
known_false_positives: While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user.
references:
    - https://bishopfox.com/blog/privilege-escalation-in-aws
    - https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/
analytic_story:
    - AWS IAM Privilege Escalation
    - Scattered Lapsus$ Hunters
asset_type: AWS Account
mitre_attack_id:
    - T1136.003
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network

Stages and Predicates

Stage 1: search

`amazon_security_lake` api.operation=CreateAccessKey

Stage 2: fillnull

| fillnull

Stage 3: stats

| stats count min(_time) as firstTime max(_time) as lastTime
    BY actor.user.uid api.operation api.service.name
       http_request.user_agent src_endpoint.ip actor.user.account.uid
       cloud.provider cloud.region

Stage 4: rename

| rename actor.user.uid as user api.operation as action api.service.name as dest http_request.user_agent as user_agent src_endpoint.ip as src actor.user.account.uid as vendor_account cloud.provider as vendor_product cloud.region as vendor_region

Stage 5: search

| `security_content_ctime(firstTime)`

Stage 6: search

| `security_content_ctime(lastTime)`

Stage 7: search

| `asl_aws_create_access_key_filter`

Indicators

These rows show field, operator, and value matches.