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.
Editorial analysis by NHI Mgmt Group, based on content published by Exaforce: “Do you feel in control? Analysis of AWS CloudControl API as an attack tool”.
Key questions
Q: What breaks when AWS CloudControl access is treated like ordinary API permissioning?
A: The control plane becomes the attack path.
Q: Why does delegated CloudControl access increase the risk of resource discovery?
A: Because the API can return resource identifiers, schemas, and existence signals through a single management request.
Q: What are the signs that proxy-based cloud access is being abused?
A: Look for unusual sequences of resource listing, identifier guessing, and backend fan-out from a single identity, especially when the original request is a wrapper around many downstream service calls.
Practitioner guidance
- Review delegated service paths as privileged access Map every API or management layer that can execute downstream actions on behalf of an identity, then compare that reach with the direct permissions the identity appears to hold.
- Detect enumeration through resource lookup patterns Alert on repeated ListResources and GetResource activity, especially where the same identity probes many resource types or cycles through guessed identifiers.
- Separate direct access from via-service execution Use policy analysis to identify identities that are denied direct service operations but still allowed to act through a trusted cloud management intermediary.
Bottom line: CloudControl can conceal meaningful privilege behind a trusted management layer, which makes direct-permission reviews incomplete on their own.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:52 pm
CloudControl-style abstraction creates an identity blind spot, not just a new API surface. The governance issue is that a single delegated control plane can carry discovery, modification, and persistence activity that does not resemble direct service use. Traditional IAM reviews often look at service permissions in isolation, which misses how a management proxy expands effective reach. Practitioners should treat abstraction layers as first-class identity pathways, not just convenience features.
A question worth separating out:
Q: How should IAM teams govern trusted management intermediaries in AWS?
A: They should evaluate the downstream effect of the intermediary, not only the front-door permission. That means reviewing who can act through the service, what resource types it can touch, and whether logging and alerting preserve the link between the wrapper call and the underlying operations.
👉 Read our full editorial: AWS CloudControl API abuse shows how identity can hide in plain sight