AWS CloudControl API abuse shows how identity can hide in plain sight

At a glance

What this is: This is an analysis of how AWS CloudControl API can be misused as an attack tool to enumerate resources, persist in accounts, and evade detection.

Why it matters: It matters because IAM, PAM, and NHI teams need to understand that proxy execution paths can expose the same privileges as direct API access while making abuse harder to spot.

By the numbers:

• 1, WS CloudControl API supports 1,220 resource types, split across 237 services.
• 17 minutes.

👉 Read Exaforce's analysis of AWS CloudControl API abuse and stealthy enumeration

Context

AWS CloudControl API is a management layer that can create, read, update, delete, and list cloud resources through a unified interface. In identity terms, that matters because the control plane becomes a path for resource access, not just administration, and the permissions granted to an identity may be broader in practice than the direct service calls suggest.

For IAM and NHI programmes, the risk is not the existence of CloudControl itself but the way it can concentrate resource visibility and execution into a single proxy path. That changes detection, policy design, and audit expectations because the attacker does not always need direct service-specific permissions to achieve useful reconnaissance or persistence.

The article shows a typical cloud governance blind spot: security teams often validate direct API permissions but overlook delegated or service-mediated paths that can still expose sensitive resource data or create hidden persistence.

Key questions

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. Do not assume direct service policy coverage is enough. Review which identities can invoke resource discovery or writes through the proxy, then correlate those permissions with the backend actions they can indirectly reach.

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. That breaks simple least-privilege checks and makes direct-call monitoring miss the real execution path. Analysts need session-level correlation, not call-by-call inspection.

Q: What breaks when resource discovery is routed through a management proxy?

A: Direct permission validation stops reflecting actual reach. An attacker can use the proxy to validate guesses, map identifiers, and learn which actions are allowed, even when individual services appear locked down. The result is a wider reconnaissance surface and a weaker signal for traditional service-centric detections.

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.

Technical breakdown

How CloudControl API turns resource management into a proxy path

CloudControl uses CloudFormation schemas to abstract service-specific APIs into a standard CRUD-L interface. That makes it easier to list, retrieve, create, update, and delete supported resources without knowing the native service call for each one. The technical consequence is that one authorised identity can gain broad operational reach through a single entry point, even when the underlying services remain individually protected. For defenders, this is a control-plane problem: the permission boundary is not the same as the operational boundary.

Practical implication: inventory CloudControl permissions separately from direct service permissions and treat the API as a distinct control surface.

Why enumeration through CloudControl is attractive to attackers

The API can expose resource identifiers first and then return schema-formatted details for matching objects. That makes bulk discovery efficient, especially when attackers are trying to map IAM users, groups, tags, and attached policies. When naming or identifier guessing is possible, the interface also helps distinguish access denial from object absence, which improves brute-force validation. The result is a low-noise discovery channel that can accelerate environment mapping without obvious service-by-service probing.

Practical implication: monitor for bursts of ListResources and GetResource activity that do not match normal administrative workflows.

How CloudControl-mediated writes can create stealthy persistence

Because CloudControl can initiate create, update, and delete operations, an attacker with the right path can attempt resource changes while blending into a legitimate management pattern. The article also shows that request status and failure information can reveal policy boundaries, making the abuse path useful even when the write operation itself fails. This is where identity governance meets attack surface: if a proxy service can invoke powerful backend actions, the audit trail must be evaluated as a chained execution path, not as isolated calls.

Practical implication: alert on resource creation or policy changes that originate through CloudControl rather than direct service administration.

Threat narrative

Attacker objective: The attacker wants to discover cloud resources, validate permissions, and create or preserve access while making the activity look like normal resource administration.

1. Entry occurs through an identity with CloudControl permissions that can invoke resource operations through a managed proxy rather than direct service APIs.
2. Escalation happens when the attacker uses ListResources, GetResource, or write operations to map IAM objects, validate guesses, or attempt persistence through resource changes.
3. Impact is achieved by hiding reconnaissance or account modification inside a legitimate-looking management workflow, reducing the chance that direct-service monitoring will catch the activity.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Resource enumeration through a management proxy creates identity blast radius. The article demonstrates that identifiers, tags, attached policies, and other resource details can be surfaced through a single control plane path. That is enough to support targeting, permission mapping, and attack planning without touching every native service directly. The practical conclusion is that discovery controls must account for mediated access paths, not only service-native API abuse.

CloudControl can turn normal administration into an attacker camouflage layer. When writes, updates, and request-status checks are available through a legitimate platform workflow, malicious activity can resemble infrastructure management traffic. That does not make the behaviour harmless; it makes detection harder because the signal is buried inside expected operational patterns. Security teams should view this as a governance gap in audit interpretation, not merely a logging gap.

Identity programmes need a distinct control category for service-mediated execution paths. The article highlights a named concept worth carrying forward: proxy execution visibility gap: the difference between who is authorised to manage a resource and who can reach it through a delegated service. That gap matters across IAM, PAM, and NHI oversight because the indirect path often becomes the path attackers prefer. Practitioners should close the governance blind spot before they chase individual detections.

Detection must focus on sequence, not single events. CloudControl abuse becomes visible when enumeration, resource requests, and backend service calls are analysed as one chain. A lone API call may look routine, but a burst of proxy-mediated discovery followed by atypical write activity is materially different. The field should move from call-level monitoring to session-level identity investigation when proxy services sit in the middle of the workflow.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• If you are mapping delegated execution paths, NHI Lifecycle Management Guide is the next step for provisioning, rotation, and offboarding controls.

What this signals

Proxy execution visibility gap: cloud teams need to distinguish direct service access from mediated API paths, because attackers increasingly prefer the latter when it gives them broader reach with less obvious telemetry. That means access reviews should include service-mediated execution, not just role policies and native API permissions. Aligning this work with NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor the monitoring and audit expectations.

The practical signal for IAM teams is simple: if a management API can fan out into multiple backend calls, then your detection model must follow the chain instead of the headline request. Pair that with the MITRE ATT&CK Enterprise Matrix when you map credential access, discovery, and persistence behaviours to real attacker tradecraft.

For practitioners

• Map proxy-mediated privileges separately Inventory every identity that can use AWS CloudControl API and document which backend resource actions it can trigger indirectly. Compare that list to direct service permissions to find places where effective access exceeds what standard IAM reviews show.
• 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. Use baselines for administrative sessions so that discovery traffic inside CloudControl stands out.
• 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. Prioritise identities that can change IAM-related resources or account-scoped configuration.
• Correlate proxy calls with backend service events Build detections that join CloudControl requests to the downstream API calls they generate. The article shows that the proxy can fan out into multiple backend events, so analysts need the whole chain to judge whether activity is legitimate or malicious.

Key takeaways

• A single management proxy can expose broad cloud reach, so IAM reviews that focus only on native service calls will miss real attack paths.
• CloudControl-style enumeration creates a reconnaissance channel that can reveal resource names, identities, and policy structure with far less noise than direct service probing.
• Security teams should correlate proxy calls with downstream service activity, because the abuse pattern becomes visible in the sequence, not in one event alone.

Key terms

• CloudControl API: AWS CloudControl API is a unified management interface for creating, reading, updating, deleting, and listing supported cloud resources. In identity terms, it matters because one delegated path can expose broad operational reach even when direct service permissions remain narrower.
• Proxy execution path: A proxy execution path is an indirect route through which one service invokes or mediates actions against another service. For identity governance, this means effective access can exceed the permissions visible in direct API reviews, especially when the intermediary hides the true backend calls.
• Resource enumeration: Resource enumeration is the process of discovering resource names, identifiers, tags, and related configuration details in an environment. Attackers use it to map targets, validate guesses, and plan follow-on access, which makes it a valuable signal for cloud and identity defenders.

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

👉 Exaforce's full post covers the attack workflow, persistence pattern, and detection approach in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI programme, it is worth exploring.