---
title: Enumeration from multiple regions using a long-term access key failed
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Datadog Security > OOTB Rules > Enumeration from multiple regions using
  a long-term access key failed
---

# Enumeration from multiple regions using a long-term access key failed
Classification:attackTactic:[TA0007-discovery](https://attack.mitre.org/tactics/TA0007)Technique:[T1526-cloud-service-discovery](https://attack.mitre.org/techniques/T1526) 
## Goal{% #goal %}

Detects denied `List*` and `Get*` AWS API calls made with a long-term IAM access key across many distinct regions for the same principal. An alert fires when that cross-region denied discovery pattern exceeds the rule's configured threshold within the evaluation window.

## Strategy{% #strategy %}

This rule monitors management events where `@evt.name` matches read-style discovery operations, `@userIdentity.accessKeyId` is a long-term IAM user key prefix `AKIA`, and `@error.kind` is `AccessDenied`. Activity is evaluated per IAM principal while counting how many different `@awsRegion` values appear for that pattern, surfacing principals whose denied discovery volume across regions crosses the threshold. The same shape of activity is uncommon for tightly scoped automation with correct least privilege and is a strong signal to validate credential use and policy intent.

## Triage & Response{% #triage--response %}

- Verify whether `{{@userIdentity.arn}}` and the associated access key are tied to approved automation, a shared service account, or an individual user.
- Review surrounding CloudTrail for the same `{{@userIdentity.accessKeyId}}` to see which APIs succeeded or failed and whether regions align with known workloads.
- Determine if `AccessDenied` on `List*` and `Get*` calls reflects deliberate policy guardrails or unexpected use of the key outside its intended scope.
- Identify when the key was issued or last rotated and whether any recent changes to IAM users, roles, or policies could explain the behavior.
- Check for correlated signals on the same principal or source IP around the alert time to distinguish misconfiguration from credential misuse.