Startup configuration can trigger code execution in cloud roles

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Plerion's blog post: Cloud execution roles can be abused when attackers can change startup configuration after the role check has already passed.

Why it matters: IAM and PAM teams need to treat boot-time configuration as a privileged boundary because post-approval changes can still trigger execution under an authorised role.

Context

Cloud services often separate who is allowed to configure a resource from what code runs when that resource starts. That split creates a governance gap when startup hooks, user data, or lifecycle scripts can be changed after the initial permission check.

In this pattern, the control problem is not authentication alone but the lifecycle of delegated privilege. Privileged Access Management becomes relevant because the real risk is modifying a trusted execution path after access has already been granted.

This is a familiar cloud design pattern, but the specific combination of configuration changes and later execution is still easy to overlook in permission reviews.

Key questions

Q: How do I detect instance-profile abuse through startup configuration changes?

A: Look for stop, modify, and start activity on the same compute resource, especially when the modifying identity normally does not manage that asset. The key signal is a change to startup settings such as user data or lifecycle hooks immediately before the resource is restarted. That sequence often means code execution was inserted into a trusted boot path.

Q: Why do startup scripts create privilege escalation risk in cloud workloads?

A: Startup scripts create privilege escalation risk because they run automatically at boot or instance launch, often before normal monitoring and hardening controls are fully active. If a script is writable, pulled from an untrusted source, or runs with an overprivileged instance role, an attacker can inject commands, install persistence, or change local access. Treat the script as privileged code, restrict write access, and scope the execution role tightly.

Q: How does cloud workload identity differ from human admin access?

A: Cloud workload identity is a machine identity used by an application, service, or workload to authenticate to other systems without a human logging in. Human admin access is tied to a person, usually interactive, higher risk, and governed through MFA, PAM, and approval. Workload identity should be short-lived, narrowly scoped, and separated from human credentials so compromise does not imply administrator control.

Q: What should teams do first when a cloud execution role is exposed?

A: First, disable or rotate the exposed execution role credentials and identify every workload or process that could still use them. Then review the role policy, attached secrets, and recent API activity for signs of runtime mutation such as injected commands, modified startup paths, or new persistence mechanisms. Contain the affected instance, reissue credentials, and validate that no unintended privilege paths remain.

Technical breakdown

How execution-role abuse emerges from configuration-time checks

Cloud platforms often evaluate permission to assign or attach an execution role at configuration time, then trust that configuration later when the resource starts running. If an attacker can change startup material after the check, they can redirect a legitimate execution path into attacker-controlled code while the platform still believes the original role binding is valid. The core issue is not role issuance itself but the gap between approval and runtime execution. See the Privileged Access Management Guide.

Practical implication: Review the permissions that let users alter startup configuration separately from the permissions that create or attach execution roles.

Why boot hooks and lifecycle scripts are high-value control points

Boot hooks, user data, and notebook lifecycle scripts are effectively code execution entry points hidden inside administrative settings. They are attractive because they run in a trusted context, often with access to cloud metadata, instance credentials, or service-linked permissions. Once that code executes, the attacker does not need to steal a password in the traditional sense. They can inherit the resource's authorised identity and use it to call cloud APIs. See the Cloud Workload Identity Guide.

Practical implication: Restrict and monitor any setting that can execute code on start, especially where it can inherit a cloud role.

What CloudTrail-style sequences reveal about abuse paths

The observable abuse pattern is a sequence of stop, modify, and start actions on a compute resource or notebook instance. That sequence matters because it shows the attacker is not merely operating the workload, but changing the startup conditions before asking the platform to run it again. Detection should focus on unusual identities performing these state transitions, especially when they do not normally administer that asset type.

Practical implication: Alert on stop-modify-start patterns that alter boot-time configuration on resources outside normal admin workflows.

Threat narrative

Attacker objective: The attacker wants to execute arbitrary code under a legitimate cloud execution role and use that role's privileges for further cloud actions.

1. Entry begins when an attacker gains cloud permissions that allow them to stop a compute resource and modify its boot-time configuration.
2. Credential_harvested occurs when the attacker inserts startup code that can read or exfiltrate the instance's execution credentials when the resource restarts.
3. Escalation follows when the attacker uses the resource's trusted execution context to call cloud APIs with privileges they should not have had directly.
4. Impact is achieved when the attacker uses the inherited role to run privileged actions or exfiltrate credentials at scale.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud privilege escalation becomes a lifecycle problem, not just an access-control problem. The important failure mode is the gap between configuration approval and later execution, because that gap lets an attacker change what a trusted resource will do after the permission check has already passed. In practical terms, the sensitive object is not only the role assignment but the startup path that can activate it. Teams should treat those configuration surfaces as part of privileged access governance.

Boot-time code is a delegated trust boundary, and delegated trust ages badly. When a service lets administrators attach scripts, hooks, or lifecycle actions that run with an execution role, the platform is delegating part of its security decision to later runtime behaviour. That is precisely where identity governance needs to extend into cloud operations, because the resource is acting as a machine identity with inherited authority. Cloud workload identity matters here because the workload's identity is only safe if the execution path is tightly controlled.

Stop-modify-start sequences are an identity abuse pattern disguised as routine administration. The abuse looks like ordinary resource management until the modified setting becomes code execution. That makes the control question less about whether the API is legitimate and more about whether the workflow can be used to swap trusted intent after approval. Practitioners should narrow who can alter runtime-start configuration and treat those transitions as privileged events.

Configuration-time authorisation is the wrong control point for runtime abuse. The platform may correctly check who can bind a role, yet still allow later changes that alter the behaviour of that role at execution time. That means least privilege has to cover both the initial assignment and the later mutation surface. The practical conclusion is simple: if a setting can become code, it belongs in privileged access review.

From our research library:

• Patching addresses only about 10% of privilege escalation techniques, while privilege management covers about 65%, according to Verizon's 2026 Data Breach Investigations Report.

What this signals

Lifecycle-bound privilege is now a cloud governance category of its own. The practical lesson is that access reviews cannot stop at role assignment when the same actor can later alter what the role executes. Security teams should track configuration surfaces that can become code execution points and include them in privileged access boundaries.

Execution-role abuse turns cloud admin workflows into identity attack paths. Once a platform allows trusted startup logic to be modified after approval, the relevant question is not only who can administer the resource, but who can redefine its runtime behaviour. That is why cloud IAM, PAM, and workload identity controls need to be evaluated together rather than in isolation. Identity attack paths belong in that review.

For practitioners

• Separate role binding from startup mutation permissions Limit who can stop instances, attach lifecycle configs, or modify startup settings on workloads that run with sensitive execution roles.
• Monitor stop-modify-start sequences as privilege escalation indicators Alert on CloudTrail patterns where an identity changes boot-time configuration and then restarts the same resource, especially outside normal admin roles.
• Treat user data and lifecycle hooks as code execution surfaces Require review and approval for any change that can execute on boot, including notebook lifecycle configs, instance user data, and similar startup hooks.
• Restrict execution-role boundaries on cloud notebooks and instances Use separate administrative roles for compute lifecycle management and for access to data or APIs reachable from the running workload.

Key takeaways

• The core issue is a lifecycle gap where an attacker can modify startup behaviour after role approval and still inherit trusted execution.
• The abuse pattern shows up as stop, modify, and start activity around the same workload, often with CloudTrail evidence.
• Limiting configuration mutation rights and treating boot-time hooks as privileged code execution surfaces are the controls that matter most.

Related NHI Mgmt Group resources: Privileged Access Management Guide · Cloud Workload Identity Guide · Identity Attack Paths Guide · OWASP Top 10 A01 Guide

Key terms

• Execution Role: The IAM role an AI agent assumes to call cloud services on behalf of a workflow. It is the main control point for what the agent can do, so poor scoping turns an ordinary agent into a high-blast-radius identity with access that can outlive the original use case.
• Lifecycle Configuration: Lifecycle configuration is any file or policy that controls when automation starts, stops, or reappears during normal use. For developer and AI-tool environments, these artifacts can function as persistence mechanisms if attackers can modify them, which makes them security-relevant assets.
• CloudTrail: CloudTrail is AWS’s audit logging service for recording API activity across an account. Security teams use it to track who did what, when, and from where, which supports detection, investigation, and compliance evidence. Its value depends on retention, alerting, and active review, not just log generation.
• PassRole Permission: PassRole is an IAM capability that lets one identity assign a role to a cloud service or workload at launch time. It is powerful because the service then inherits the role's permissions, which can expand access far beyond the original caller if not tightly constrained and monitored.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the cloud execution paths that workloads actually use.