« AWS IAM Login Profile Added to User AWS IAM OIDC Provider Created by Rare User »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

AWS IAM Long-Term Access Key First Seen from Source IP

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS IAM Long-Term Access Key First Seen from Source IP

edit

Identifies the first time, within the configured history window, that a long-term IAM access key ID (prefix AKIA) is used successfully from a given source.ip in AWS CloudTrail. Long-term access keys belong to IAM users or the account root user. They are a common target after credential theft or leakage, including supply-chain and exposed-key scenarios. Temporary security credentials (prefix ASIA) and console sessions are excluded so the signal emphasizes programmatic access patterns.

Rule type: new_terms

Rule indices:

  • logs-aws.cloudtrail-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: AWS
  • Data Source: Amazon Web Services
  • Data Source: AWS CloudTrail
  • Data Source: AWS IAM
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Tactic: Initial Access
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating AWS IAM Long-Term Access Key First Seen from Source IP

This rule is a New Terms detection on CloudTrail. It fires when a successful API call uses a long-term IAM access key (AKIA*) from a source.ip that has not appeared with that key in the rule history window.

Long-term keys are high-value targets. Unlike session credentials (ASIA*), they do not expire until rotated or deleted. Threat reporting on cloud compromises often highlights abuse of leaked or stolen AKIA keys.

Possible investigation steps

Confirm the key and principal - Identify the IAM user or root context implied by aws.cloudtrail.user_identity.arn or user.name. - aws.cloudtrail.user_identity.type: Distinguish IAMUser, Root, or other types; root long-term keys warrant extra scrutiny.

Assess the new source - source.ip and source.geo: Compare to normal geography, corporate egress, and known cloud provider ranges. - user_agent.original: Identify AWS CLI, SDKs, custom tooling, or unusual agents.

Correlate activity - Search CloudTrail for the same access key and IP over the following hours for sensitive APIs (IAM changes, STS, S3 data access, Secrets Manager, role assumption). - Review IAM last-used metadata for the key in the AWS console or API (GetAccessKeyLastUsed).

False positive analysis

  • Travel and VP* for human IAM users.
  • New CI runners, ephemeral build agents, or re-IP’d NAT gateways for automation keys.
  • Partner or MSP access from new networks if keys are shared (discouraged practice).

Response and remediation

  • If unexpected, deactivate or delete the access key, rotate credentials, and review policies attached to the user.
  • Enable or enforce MFA for console users; prefer roles and temporary credentials over long-term keys for workloads.
  • Document approved networks or principals and tune history or exceptions accordingly.

Additional information

Rule query

edit
event.dataset: "aws.cloudtrail"
    and event.outcome: "success"
    and source.ip:*
    and aws.cloudtrail.user_identity.access_key_id: AKIA*

Framework: MITRE ATT&CKTM

« AWS IAM Login Profile Added to User AWS IAM OIDC Provider Created by Rare User »