Exploit Jenkins in the Cloud

What this lab covers

You gain access to a Jenkins instance, use its own scripting capability to run code on the underlying host, and recover the credentials it stores for other systems.

The value here is understanding why CI/CD is such a high-yield target. Build systems are given broad access deliberately, because deploying software requires it, and that access is centralised in one place that is often less hardened than the environments it manages.

It suits anyone responsible for pipelines as well as anyone assessing them. If your Jenkins can deploy to production, then Jenkins is production.

How Jenkins compromise leads to cloud access

Jenkins stores credentials for the systems it integrates with, encrypted on disk using a key that also lives on the same host. This is a practical necessity rather than a flaw, but it means anyone with sufficient access to the host or to Jenkins itself can recover the plaintext.

The script console is the usual route. It is an intended administrative feature that executes Groovy code in the Jenkins process, which means code execution on the host is a supported function of the application rather than an exploit. Access control on that feature is therefore the entire security boundary.

Exposure is common because build servers grow organically. They accumulate plugins, they are frequently behind on updates because upgrading risks breaking builds, and they are sometimes reachable from the internet to receive webhooks. Once an attacker has the stored credentials, they inherit whatever the pipeline was permitted to do, which typically includes deploying into cloud accounts.

How to detect this in your own environment

Alert on script console use. It is a powerful, rarely used administrative feature, so any invocation is worth reviewing. In a healthy environment this produces almost no events, which makes it an unusually clean detection.

Watch for new or modified jobs and pipeline definitions, especially changes made outside source control. An attacker who wants persistence in a build system generally adds a step rather than a backdoor, because a build step looks like normal activity.

On the cloud side, baseline what the pipeline identity does. Deployment roles have repetitive, predictable behavior, so a deployment credential suddenly enumerating identities or reading secrets it never touches is a strong signal.

How to prevent it

Do not expose the build server to the internet. Where webhooks require inbound connectivity, terminate them at a proxy that forwards only the specific paths required, rather than publishing the whole application.

Scope the pipeline's cloud identity per pipeline rather than per server. A single powerful role shared by every job means the least important build has the same access as the most important one, and attackers only need the least important one.

Prefer short-lived credentials issued through workload identity federation over long-lived keys stored in the build system. This removes the stored secret entirely, which is a stronger position than protecting it well.

Real-world context

Build systems have been repeatedly targeted because they sit at a natural chokepoint between source code and production. Supply chain incidents of the past several years have consistently involved compromise of build or distribution infrastructure rather than the application source itself.

Jenkins in particular has a large plugin ecosystem with a long history of security advisories, and instances often lag on patching precisely because upgrades risk breaking builds. That combination of broad access and cautious patching is what makes it attractive.

The pattern maps to MITRE ATT&CK T1195 Supply Chain Compromise, T1552.001 Credentials In Files and T1078.004 Cloud Accounts.

Applying this at work

• Confirm whether your build servers are reachable from the internet, and remove that exposure if they are.
• Inventory the credentials stored in your CI system and identify which could be replaced with short-lived federated access.
• Restrict script console access to a very small group, and alert on every use.
• Give each pipeline its own scoped cloud identity rather than sharing one deployment role.
• Establish a patching cadence for the build system itself, which is usually the least patched machine with the most access.

Frequently asked questions

Why is the Jenkins script console dangerous?

It executes code inside the Jenkins process on the host by design. It is an intended administrative feature rather than a vulnerability, which means access control on it is the only boundary preventing code execution on the build server.

Are Jenkins stored credentials encrypted?

They are encrypted at rest, but the key material resides on the same host. Anyone with sufficient access to the host or to Jenkins administrative functions can recover the plaintext, so encryption at rest is not a defense against host compromise.

What is the biggest single improvement for CI/CD security?

Replacing long-lived stored cloud credentials with short-lived credentials issued through workload identity federation, and scoping them per pipeline. It removes the stored secret rather than trying to protect it.

Do I need my own cloud account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack paths including CI/CD and credential abuse, and is assessed hands-on in a live AWS account.