Exploring the Shadows: Identifying and Securing Undocumented AWS APIs in the Cloud

As more organisations rely on AWS to run production infrastructure, engineers need more than just a surface-level
understanding of the tools they use. While AWS’s documented APIs are well-known and form the backbone of
automated cloud operations, there’s a quieter, more opaque layer underneath: undocumented APIs.

These are APIs that exist but aren’t listed in AWS’s official documentation. Some were never meant to be exposed;
others support legacy or internal tooling. When these APIs appear unexpectedly - via logs, recon tools, or
over-permissive IAM - they can pose a real security concern.

In this guide, we’ll break down what undocumented AWS APIs are, how they show up, why they matter, and what you
can do to reduce your exposure. If you're building or securing cloud-native systems, understanding the risks around
undocumented APIs is no longer optional. It's essential.‍

1. What Are Undocumented AWS APIs?

In AWS, an API is the programmatic gateway to infrastructure. Every time you spin up a service, update permissions,
or fetch logs, there’s an API call under the hood. These are usually documented, but not always.

Undocumented vs. Private APIs

Private APIs: strictly internal. AWS uses them to run its own systems.

Undocumented APIs: sometimes exposed publicly, but without official documentation. They’re not meant for
customers, yet they occasionally become visible - often due to legacy code, internal tooling, or misconfiguration.

Why Do They Exist?

1. Legacy endpoints never fully retired
2. Internal debugging or maintenance interfaces
3. APIs supporting experimental features or unreleased services

2. Why They’re Risky

No Visibility — Since these APIs aren’t officially documented, your monitoring tools might not flag them.

‍Unknown Functionality — Without docs, you can’t tell what a call does. A single command might unintentionally
expose data or escalate privileges.

‍Access Control Gaps — IAM policies that are too broad (like *:*) could permit access to these APIs without
you realising it.

‍Real-World Concern: In red team assessments, attackers have used API enumeration techniques to find
undocumented or under-secured endpoints. Sometimes the difference between a failed recon and full access
is just one hidden API call.

3. How to Identify Undocumented APIs

a. Enumerate with AWS SDKs & CLI

Use tools like boto3 or the AWS CLI to list available API calls. Compare them with AWS’s official documentation
to spot outliers.

Then inspect:

Look for commands that exist in the CLI but not in official docs.
‍

b. Log Analysis with CloudTrail

CloudTrail logs every API call. Use Amazon Athena, CloudWatch Logs Insights, or your SIEM to search for:

• Unknown eventName
• eventSource values you don’t recognise‍

Pro Tip: Build a baseline of documented API actions, then flag anything that deviates.
‍

c. Use Recon and Security Tools: 

• Pacu: AWS exploitation framework
• AWSRecon: enumerates services, regions, and uncommon endpoints
• Burp Suite: handy if your API is exposed via web layers

Field tip: Pacu modules can reveal services and permissions that aren’t obvious - great for testing assumptions.

4. Mitigating the Risks

a. Enforce Least Privilege via IAM

1. Avoid wildcard permissions (*)
2. Explicitly define allowed actions
3. Review policies regularly, especially during team scaling
   ‍

b. Use API Gateway & WAF as Control Points If exposing APIs externally:

• Route through API Gateway to whitelist known actions
• Add AWS WAF to detect and block suspicious calls
• Pair with AWS X-Ray to trace requests

c. Monitor Everything

• Enable CloudTrail in all regions
• Set alerts in CloudWatch for unusual calls
• Use GuardDuty to detect abnormal behavior
• Aggregate findings via Security Hub

Final Thoughts

Undocumented APIs aren’t just theoretical. They show up in real environments, and attackers know to look for them.
If you don’t have visibility into what’s exposed, you can’t secure it.

Stay proactive:

• Continuously monitor API activity
• Re-audit IAM policies regularly
• Simulate attacks using red team tools

As the AWS ecosystem grows more complex, the line between “official” and “available” gets blurrier. Your best defense?
Know what’s there - even if AWS doesn’t document it.

‍

‍

‍