Jenkins Security Threats: Attack Vectors, Exploitation Techniques, and Mitigation Strategies

1 Introduction

Jenkins is a leading open‑source automation server that is popular among development teams. Recently, adversaries have been observed targeting large Jenkins servers to deploy cryptomining payloads and to maintain access via the Jenkins web console. Numerous well‑documented blog posts discuss exploitation of web‑console vulnerabilities and post‑exploitation techniques.

This blog focuses on the techniques attackers typically use to gain, maintain, and exfiltrate data. CrowdStrike’s Red Team leveraged these techniques in adversary‑simulation exercises against compromised development environments.

2 Locating Jenkins

Finding and identifying Jenkins servers depends on the environment. For most red‑team engagements, a Jenkins instance can be accessed somewhere inside the internal network. Access is often obtained by exploiting recently disclosed vulnerabilities, mis‑configured authentication plugins, or previously stolen credentials.

Targeted exploitation is not always observed, but recent activity shows attackers actively exploiting Jenkins vulnerabilities.

3 Java Deserialization

Java deserialization vulnerabilities (e.g., CVE‑2017‑1000353) can provide remote code execution on unpatched Jenkins servers. Exploit‑DB hosts a modifiable proof‑of‑concept that can be used for testing.

Without exploiting a vulnerability, attackers usually rely on previously compromised credentials or mis‑configured Jenkins authentication. By default Jenkins requires authentication, but many teams change this setting, potentially exposing the server depending on configuration. Jenkins supports various authentication plugins (LDAP, Kerberos SSO, SAML, etc.). A common mis‑configuration is anonymous read access in the “Global Security Configuration”.

Although disabled by default, anonymous read access can expose build history and credential plugins. In some cases, anonymous script‑console access is also enabled, granting full Java runtime access and allowing command execution. It is strongly recommended to lock down Jenkins, especially the web console, because mis‑configured authentication plugins are a common path for attackers.

Authentication plugins allow teams to customize login methods (e.g., Google login when Active Directory is unavailable). Regardless of implementation, these methods must be properly protected. Adversaries have been observed leveraging authentication mechanisms to gain web‑console access; therefore, thorough edge testing of these plugins is essential (e.g., does every AD user authenticate via the web console?).

4 Parsing Jenkins

Jenkins is a Java application that runs on Windows, Ubuntu/Debian, and Red Hat/CentOS. While the web UI is largely identical, there are notable differences between Windows and Linux installations:

Windows

By default Jenkins runs under the NT AUTHORITY\SYSTEM account. Changing this to a limited‑privilege service account is strongly advised because SYSTEM has full system rights, and script‑console access would give an attacker complete control.

Unix‑like

On Linux, Jenkins creates a service account without sudo or root privileges by default, though this should be verified. Script‑console access grants the attacker the same privileges as the Jenkins service account.

Script Console

The Jenkins script console is a web‑based Groovy console that provides full Java access. Commands executed via the console run as Java subprocesses (e.g., java.exe on Windows or /usr/bin/java on Ubuntu).

Attackers can generate beacons, list files, decrypt stored passwords, etc. Detecting malicious Jenkins activity may involve spotting suspicious process trees, such as PowerShell commands generated from the script console.

In some cases, attackers avoid built‑in Java methods for C2 and instead rely on PowerShell. Compromised Jenkins instances often target credentials.xml, master.key, and hudson.util.Secret. The master.key encrypts hudson.util.Secret, which in turn encrypts secrets stored by the credentials plugin. credentials.xml contains encrypted password phrases and keys for Jenkins users.

These files can be obtained via SSH or C2, or by executing Groovy scripts in the script console. Example Groovy script (shown in the image) retrieves the files without spawning malicious subprocesses, using the Base64 class to read the binary hudson.util.Secret file.

Access to the Jenkins script console therefore provides multiple avenues for extracting critical and sensitive files; it should be disabled or tightly restricted.

5 Creating Projects

Even without script‑console access, an attacker who can view the web UI may enumerate jobs or build history, gaining valuable information. CrowdStrike’s Red Team identified scenarios where an attacker could reconfigure jobs but not create new ones, and vice‑versa.

By inspecting the default page of the web UI, one can determine which permissions are granted to authenticated users. In some configurations, job creation does not require authentication.

With job‑creation rights, an attacker can create a freestyle project, execute commands, and view console output.

After saving, the attacker can trigger an immediate build.

Build output can be viewed, revealing any leaked secrets.

Because the Jenkins server allowed anonymous job creation, the user associated with the build is unknown. Attackers can also edit existing jobs to inject environment variables containing credentials and write them to a globally readable userContent folder.

The userContent folder is a special directory that bypasses most access controls, making it a convenient location for exfiltrated secrets.

6 Conclusion

Automation platforms such as Jenkins are valuable targets for adversaries. Administrators should invest time in hardening and auditing Jenkins installations because these systems are likely to be attacked.

CrowdStrike recommends that Jenkins administrators consider the following checklist based on recent adversary activity:

Is the Jenkins web console accessible to anyone after authentication? Does this include script‑console access? Can they view credentials or build history? Can they create or schedule builds?

What permissions do authenticated users have? Does this include script‑console access? Can they view credentials or build history? Can they create or schedule builds?

Is any sensitive information stored in build history or console output?

Does Jenkins need internet access?

Is the Jenkins service account running with the least privileges required?

How are credentials stored? Who can access credentials.xml, master.key, and Secret?

The list is not exhaustive; securing Jenkins will depend on the organization’s context.