Nonproduction API Endpoints

Techniques for avoiding CloudTrail detection

Overview

When interacting with AWS services, there is an API Endpoint you hit e.g.,

aws iam list-users

The IAM commands hit the service endpoint iam.amazonaws.com over HTTPS. Every service and region has different endpoints with some supporting both HTTP and HTTPS. You can add --debug to your AWS CLI commands and view the endpoint in the output e.g.,

aws iam list-users --debug

[SNIP]
2025-08-02 14:47:29,094 - MainThread - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): iam.amazonaws.com:443
2025-08-02 14:47:29,426 - MainThread - urllib3.connectionpool - DEBUG - https://iam.amazonaws.com:443 "POST / HTTP/1.1" 200 619
[SNIP]

You can also specify alternative endpoints like so,

Notice the EC2 service endpoint supports HTTP so the data sent/received is unencrypted

aws ec2 describe-instances --region us-east-1 --endpoint http://ec2.us-east-1.amazonaws.com

---

Using Nonproduction API Endpoints

It's rare to find a nonproduction endpoint that does not log to CloudTrail and also returns production data.

Bypassing CloudTrail in AWS Service Catalog, and Other Logging Researchdatadoghq

DataDog has published a tool undocumented-aws-api-hunter to discover nonproduction API endpoints that are created and used by the team at AWS for different purposes and which are regularly recycled.

From an attacker's perspective, these endpoints are interesting for a number of reasons:

• they may or may not return production data (i.e., data in your account — provided you have permissions to view this)

• they may or may not log the API call to CloudTrail

• even if they don't return production data (and even better if it's not logged to CloudTrail), it's a useful way to identify what permissions you have in the account

• even if they log to CloudTrail, it may show up as a non-standard Event Source which may not get picked up by detection rules / tooling