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

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/04/06"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2026/04/10"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the first time, within the configured history window, that a long-term IAM access key ID (prefix AKIA) is
 11used successfully from a given source.ip in AWS CloudTrail. Long-term access keys belong to IAM users or the account
 12root user. They are a common target after credential theft or leakage, including supply-chain and exposed-key scenarios.
 13Temporary security credentials (prefix ASIA) and console sessions are excluded so the signal emphasizes programmatic
 14access patterns.
 15"""
 16false_positives = [
 17    """
 18    Legitimate users may travel, rotate through VPN egress IPs, or run automation from new build hosts, producing a
 19    first-seen IP for an existing access key. Baseline the principal, confirm with the key owner, and extend the history
 20    window or add exceptions for known automation networks if needed.
 21    """,
 22]
 23from = "now-6m"
 24index = ["logs-aws.cloudtrail-*"]
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "AWS IAM Long-Term Access Key First Seen from Source IP"
 28note = """## Triage and analysis
 29
 30### Investigating AWS IAM Long-Term Access Key First Seen from Source IP
 31
 32This rule is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) 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.
 33
 34Long-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.
 35
 36### Possible investigation steps
 37
 38**Confirm the key and principal**
 39- Identify the IAM user or root context implied by `aws.cloudtrail.user_identity.arn` or `user.name`.
 40- **`aws.cloudtrail.user_identity.type`**: Distinguish `IAMUser`, `Root`, or other types; root long-term keys warrant extra scrutiny.
 41
 42**Assess the new source**
 43- **`source.ip`** and **`source.geo`**: Compare to normal geography, corporate egress, and known cloud provider ranges.
 44- **`user_agent.original`**: Identify AWS CLI, SDKs, custom tooling, or unusual agents.
 45
 46**Correlate activity**
 47- 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).
 48- Review IAM last-used metadata for the key in the AWS console or API (`GetAccessKeyLastUsed`).
 49
 50### False positive analysis
 51
 52- Travel and VP* for human IAM users.
 53- New CI runners, ephemeral build agents, or re-IP'd NAT gateways for automation keys.
 54- Partner or MSP access from new networks if keys are shared (discouraged practice).
 55
 56### Response and remediation
 57
 58- If unexpected, deactivate or delete the access key, rotate credentials, and review policies attached to the user.
 59- Enable or enforce MFA for console users; prefer roles and temporary credentials over long-term keys for workloads.
 60- Document approved networks or principals and tune history or exceptions accordingly.
 61
 62### Additional information
 63
 64- [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.pdf)
 65
 66"""
 67references = [
 68    "https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise",
 69]
 70risk_score = 47
 71rule_id = "9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f"
 72severity = "medium"
 73tags = [
 74    "Domain: Cloud",
 75    "Data Source: AWS",
 76    "Data Source: Amazon Web Services",
 77    "Data Source: AWS CloudTrail",
 78    "Data Source: AWS IAM",
 79    "Use Case: Threat Detection",
 80    "Tactic: Credential Access",
 81    "Tactic: Initial Access",
 82    "Resources: Investigation Guide",
 83]
 84timestamp_override = "event.ingested"
 85type = "new_terms"
 86
 87query = '''
 88data_stream.dataset: "aws.cloudtrail"
 89    and event.outcome: "success"
 90    and source.ip:*
 91    and aws.cloudtrail.user_identity.access_key_id: AKIA*
 92'''
 93
 94
 95[[rule.threat]]
 96framework = "MITRE ATT&CK"
 97[[rule.threat.technique]]
 98id = "T1552"
 99name = "Unsecured Credentials"
100reference = "https://attack.mitre.org/techniques/T1552/"
101
102
103[rule.threat.tactic]
104id = "TA0006"
105name = "Credential Access"
106reference = "https://attack.mitre.org/tactics/TA0006/"
107
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110[[rule.threat.technique]]
111id = "T1078"
112name = "Valid Accounts"
113reference = "https://attack.mitre.org/techniques/T1078/"
114[[rule.threat.technique.subtechnique]]
115id = "T1078.004"
116name = "Cloud Accounts"
117reference = "https://attack.mitre.org/techniques/T1078/004/"
118
119[rule.threat.tactic]
120id = "TA0001"
121name = "Initial Access"
122reference = "https://attack.mitre.org/tactics/TA0001/"
123
124[rule.investigation_fields]
125field_names = [
126    "@timestamp",
127    "user.name",
128    "user_agent.original",
129    "source.ip",
130    "source.geo.city_name",
131    "source.geo.country_iso_code",
132    "source.as.organization.name",
133    "aws.cloudtrail.user_identity.arn",
134    "aws.cloudtrail.user_identity.type",
135    "aws.cloudtrail.user_identity.access_key_id",
136    "event.action",
137    "event.outcome",
138    "cloud.account.id",
139    "cloud.region",
140]
141
142[rule.new_terms]
143field = "new_terms_fields"
144value = ["aws.cloudtrail.user_identity.access_key_id", "source.ip"]
145[[rule.new_terms.history_window_start]]
146field = "history_window_start"
147value = "now-10d"

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

References

Related rules

to-top