Notifications
Clear all
Topic starter
02/08/2026 11:40 am
TL;DR: AWS CloudControl API can be abused to enumerate resources, persist through delegated access paths, and blur malicious activity into normal cloud operations, according to Exaforce. The deeper issue is that identity controls built around direct service calls can miss proxy-based execution and attacker-led resource discovery.
NHIMG editorial — based on content published by Exaforce: Do you feel in control? Analysis of AWS CloudControl API as an attack tool
By the numbers:
- 1, WS CloudControl API supports 1,220 resource types, split across 237 services.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams govern AWS CloudControl API access in AWS environments?
A: Treat CloudControl as a separate control plane with its own permissions review, logging, and alerting.
Q: Why do proxy-managed cloud APIs complicate IAM review and detection?
A: Because the identity may not touch the native service directly, yet it can still enumerate resources or trigger backend actions through a delegated management layer.
Q: What breaks when resource discovery is routed through a management proxy?
A: Direct permission validation stops reflecting actual reach.
Practitioner guidance
- Map proxy-mediated privileges separately Inventory every identity that can use AWS CloudControl API and document which backend resource actions it can trigger indirectly.
- Alert on enumeration bursts through management APIs Detect unusual sequences of ListResources and GetResource calls, especially when they span IAM, policy, or tag-heavy resource types.
- Review write-capable CloudControl paths for hidden persistence Look for CreateResource, UpdateResource, and DeleteResource activity initiated through CloudControl and correlate it with subsequent service-level changes.
What's in the full article
Exaforce's full blog covers the operational detail this post intentionally leaves for the source:
- Command examples showing how ListResources and GetResource expose resource identifiers and schema-formatted data
- Walkthrough of how CloudControl fans out into backend IAM and CloudFormation activity during a single request
- Policy examples that show how proxy-mediated access can be allowed while direct access remains blocked
- Detection logic and analyst workflow examples for identifying suspicious CloudControl behaviour
👉 Read Exaforce's analysis of AWS CloudControl API abuse and stealthy enumeration →
AWS CloudControl API abuse: what IAM teams need to watch?
Explore further
02/08/2026 12:52 pm
Proxy-mediated privilege is an identity problem, not just an API design choice. CloudControl compresses many service actions into one management surface, which means the real question is not whether the API is convenient but whether identity governance can still see the true blast radius. When the same principal can enumerate, inspect, and modify resources through a single path, direct-permission reviews become incomplete by design. Practitioners should treat proxy execution as part of the identity model, not an exception to it.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when CloudControl is used to hide malicious resource changes?
A: The accountable parties are the identity owner, the platform team that granted proxy access, and the security team responsible for monitoring delegated execution paths. In practice, the gap is often shared: IAM approves the access, operations keeps the proxy enabled, and detection fails to join the resulting events into one incident chain.
👉 Read our full editorial: AWS CloudControl API abuse shows how identity can hide in plain sight
