As security researchers, we strive to ideate, identify, and document new methods of attacking cloud services and resources. We build detections for these techniques into our products to proactively protect our customers from sophisticated threat actors. On occasion, we stumble into techniques that aren’t technically vulnerabilities by themselves but that blur the line between customer and cloud provider responsibilities in the shared responsibility model.
In this post, we’ll share part of our research on alternative resource enumeration methods in AWS. Specifically, how a threat actor could use resource-explorer-2:ListResources, which previously did not log to AWS CloudTrail without additional configuration by customers through data events. Without this extra configuration, customers were unlikely to detect this technique or know that it was being used.
After we shared our concerns with AWS, AWS proactively modified this API call to be a management event, ensuring that security teams can identify when this enumeration technique is used. We appreciate AWS’s commitment to enhancing the security of its platform and better enabling security teams to identify suspicious activities in their environments.
Timeline
- April 24, 2025: Datadog Security Research contacts AWS with a concern that resource-explorer-2:ListResources is an excellent resource enumeration method that does not log to CloudTrail without additional configuration.
- April 24, 2025: AWS responds that it has received our report.
- May 6, 2025: AWS responds that it is “currently working on implementing a fix.”
- May 31, 2025: AWS releases a Health event (a copy is available in the appendix) related to
resource-explorer-2:ListResources. - July 15, 2025: AWS reclassifies
resource-explorer-2:ListResourcesfrom a data event to a management event, ensuring that it logs to CloudTrail without additional configuration from customers. - August 19, 2025: Datadog publishes this post alongside a public statement from AWS.
Why quiet enumeration matters
After gaining access to an AWS environment, threat actors typically enumerate what resources are contained in the account and what resources they can access. This process is noisy, with multiple ListX and DescribeY API calls generating suspicious CloudTrail events and alerts. If the threat actor was not lucky enough to have stolen root access keys (which account for 20% of all initial access methods in AWS) or access keys that are highly privileged, the threat actor risks getting caught because of an anomalous number of `Access Denied` errors. What is a threat actor to do in these trying times?
One option is to, in a sense, proxy enumeration activity through an AWS service. This way, those API calls aren’t traced back to the identity that the threat actor compromised. Luckily for threat actors, there is an AWS service that makes this process easy: AWS Resource Explorer.
What is AWS Resource Explorer?
AWS Resource Explorer is described as a “resource search and discovery service. With Resource Explorer, you can explore your resources, such as Amazon Elastic Compute Cloud instances, Amazon Kinesis streams, or Amazon DynamoDB tables, using an internet search engine-like experience.”
Resource Explorer works by using a service-linked role named AWSServiceRoleForResourceExplorer that regularly enumerates AWS resources in the account and adds them to an index. This index is then queried to provide information to users.
If you have Resource Explorer enabled in your AWS account, you will see CloudTrail logs associated with the service role that lists and describes resources in your account on a regular basis. After these resources have been crawled, you can use resource-explorer-2:ListResources to list all resources that have been indexed.
From an offensive perspective, Resource Explorer can be a fantastic source of information. Because it uses a service-linked role to index resources, attackers can avoid making direct API calls themselves. Instead, they can query the index and launder their enumeration calls through the service, disassociating that activity from themselves.
The quiet technique: Sneaky enumeration
Before July 15, 2025, the resource-explorer-2:ListResources API call was classified as a data event, requiring explicit customer configuration to log to CloudTrail. Without this configuration, any activity involving this API call would go unnoticed in an AWS environment.
When invoked with no additional parameters, resource-explorer-2:ListResources will return the default view, which, by default, includes all resources currently indexed by Resource Explorer.
nick.frichette@host ~ % aws resource-explorer-2 list-resources
{
"Resources": [
{
"Arn": "arn:aws:iam::111111111111:role/aws-service-role/migrationhub.amazonaws.com/AWSServiceRoleForMigrationHub",
"LastReportedAt": "2025-04-20T16:26:01+00:00",
"OwningAccountId": "111111111111",
"Properties": [],
"Region": "global",
"ResourceType": "iam:role",
"Service": "iam"
},
{
"Arn": "arn:aws:iam::111111111111:user/iam-user-cred-box",
"LastReportedAt": "2025-04-20T04:49:17+00:00",
"OwningAccountId": "111111111111",
"Properties": [],
"Region": "global",
"ResourceType": "iam:user",
"Service": "iam"
},
...
This functionality makes Resource Explorer ideal as a method for enumeration of resources. Rather than making many ListX and DescribeY API calls, you can make a single API call to enumerate the overwhelming majority of resources in an account.
Before July 15, this activity did not appear in CloudTrail by default. While many other calls in the Resource Explorer namespace were considered to be management events (for example, ListViews, ListIndexes, GetIndex, and Search) and thus were logged by default, ListResources was considered a data event. For this reason, it was the ideal avenue for threat actors to quietly enumerate resources in an account.
After we shared this observation with AWS, AWS made ListResources a management event that now has its calls logged to CloudTrail by default, without any additional configuration from customers.
Defensive considerations
Block the Resource Explorer service with an SCP
If your organization doesn’t use Resource Explorer and you want to mitigate the risk that an adversary could use it against you, you can block the service by using a service control policy (SCP).
SCPs enable you to deny specific AWS API calls and namespaces across portions of your organization in AWS Organizations or across your entire organization. To block usage of the service, you can employ the following SCP and attach it to organizational units (OUs) and accounts in your organization.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Deny",
"Action": [
"resource-explorer-2:*"
],
"Resource": [
"*"
]
}
]
}It is worth noting that employing this SCP will prevent you from using Resource Explorer in accounts that are associated with the SCP. As a result, the Resources section of the search bar in the AWS Management Console will be unavailable.
Alert when CreateIndex is called from a long-lived access key
The resource-explorer-2:CreateIndex API call effectively activates Resource Explorer in the AWS Region where the index is created. When an index is created, “Resource Explorer begins discovering the resources in this Region and stores the details about the resources in the index so that they can be queried by using the Search operation.”
For this reason, an adversary might attempt to create an index to activate the service. If your organization has no intention of using Resource Explorer, alerting on CreateIndex activity can help identify a threat actor who is attempting to use Resource Explorer for enumeration purposes.
If your organization uses Resource Explorer, you can reduce false positives from alerting on the resource-explorer-2:CreateIndex API call by filtering for calls that use long-lived access keys. Threat actors often steal and use these credentials, which account for 66% of initial access vectors, according to AWS. So, a resource-explorer-2:CreateIndex API call that uses long-lived access keys has an increased chance of being from a threat actor.
Alert when ListResources is called from a long-lived access key
For reasons similar to those that we mentioned in the preceding section, it might be beneficial for you to receive alerts when a long-lived access key invokes resource-explorer-2:ListResources. Such alerts can help filter out false positives and catch a threat actor who is attempting to enumerate resources in an account.
How Datadog can help
For Datadog customers using Cloud SIEM, the following rules help identify potential threat actors leveraging Resource Explorer for resource enumeration purposes. Long-lived access keys tend to carry a higher risk of being associated with a compromise.
- AWS ListResources executed by new principal identity
- AWS ListResources by long term access key
- AWS CreateIndex followed by ListResources via long term access key
- AWS CreateIndex by long term access key
We are constantly adding new tradecraft and technique detections to Cloud SIEM, helping customers stay ahead of common threat actor capabilities.
Statement from AWS
The following is a quote from the AWS Security Team:
"On July 15, 2025, AWS released updates that now reclassify the AWS Resource Explorer ListResources API as a management event, making it automatically available in CloudTrail Event History and in Trails that capture management events. We recommended customers update their trail configuration to remove data events logging for Resource Explorer view and managed view.
We appreciate Datadog for reporting this concern and collaborating with AWS."
Conclusion
As researchers, we are constantly exploring the security frontier and identifying new ways to attack cloud environments. This research highlights how adversaries can use alternative means of enumerating resources in an AWS environment without that activity being directly associated with the identities they compromise.
AWS’s proactive response in reclassifying the resource-explorer-2:ListResources API call to a management event demonstrates a commitment to platform security and gives security teams improved visibility of this technique by default. By understanding and monitoring these nuanced techniques, organizations can better protect their environments from sophisticated threat actors and maintain a robust security posture within the shared responsibility model.
Appendix
The following content is from an AWS Health event that was sent on May 31, 2025.
Hello,
Beginning June 10, 2025, we are making a change to how AWS CloudTrail logs the AWS Resource Explorer ListResources API [1], which may require your action. This API enables you to list your AWS resources that are indexed by Resource Explorer across services, AWS Regions, and AWS accounts. Currently, this API is classified as a data event [2], meaning you must subscribe to and pay for all logged events. After this change, the ListResources API will be classified as a management event [3], making it automatically available in CloudTrail Event History and in Trails that capture management events.
We identified your account has one or more CloudTrail with data events for Resource Explorer enabled. We recommend you update your trail configuration and remove data events logging for Resource Explorer view and managed view by June 10, 2025. A list of your affected resource(s) can be found in the 'Affected resources' tab of your AWS Health Dashboard.
Additionally, we encourage you to consider whether this change will have any impact on solutions which consume CloudTrail events and to prepare updates to accommodate this change. For example, if you have a system that scans ListResources events from Resource Explorer and makes decisions based on them, you will need to update the logic to now scan these events as management events, and point your solutions to the Trail bucket that captures your management events. For additional information, please refer to our "CloudTrail record contents for management, data, and network activity events" user guide [4].
If you have questions or concerns, please contact AWS Support [5].
[1] https://docs.aws.amazon.com/resource-explorer/latest/apireference/API_ListResources.html
[2] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events
[3] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events
[4] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html
[5] https://aws.amazon.com/support
Sincerely,
Amazon Web Services
