On 18 March 2026, Darktrace researchers found a new DDoS botnet spreading through exposed Jenkins servers. The entry point was Jenkins' scriptText endpoint: a built-in feature for submitting Groovy scripts that becomes a remote code execution hole the moment you leave it open without authentication. Attackers were exploiting it to drop botnet payloads across Windows and Linux infrastructure with a single API call.
The botnet wasn't repurposed from somewhere else. It was built specifically to attack online game servers, with DDoS methods designed around game-specific protocols. The command-and-control server traced back to an IP registered to Webico Company Limited in Vietnam, on TCP port 5444.
If you run Jenkins in your build pipeline, this is the scenario your security team needs to know about. A publicly reachable instance with no authentication is all an attacker needs to reach your source code, your deployment credentials, and your supply chain.
The attack chain is short. It exploits a misconfiguration that's common enough to find at scale: Jenkins accessible from the public internet with no authentication required.
Jenkins' scriptText API lets authorised users submit Groovy scripts and run them server-side. Leave it exposed without authentication and anyone can do the same thing. The attacker submits a malicious Groovy script. The server runs it. That's the entire initial compromise, completed through one HTTP request.
A significant proportion of publicly accessible Jenkins installations have exactly this configuration. Attackers scan for them continuously. When they find one, they don't need to exploit a software flaw: the feature just works as designed.
On Windows, the payload downloaded from 103.177.110.202/w.exe to C:\Windows\Temp\update.dat, renamed itself to win_sys.exe, and executed. On Linux, a bash one-liner pulled a binary named bot_x64.exe to /tmp/bot.
The Linux variant is more sophisticated. It sets the environment variables BUILD_ID and JENKINS_NODE_COOKIE to dontKillMe, which exploits Jenkins' own process timeout mechanism to prevent the server from terminating it. Then it masquerades as a kernel thread by adopting names like ksoftirqd/0 and kworker. Finally, it double-forks to detach from the parent process entirely, so it doesn't appear in a standard process tree inspection and survives after the parent terminates.
This isn't unsophisticated malware. The evasion techniques suggest the developers tested against real Jenkins environments.
Once running, the infected host connects to the C2 server on TCP port 5444 and waits for instructions. The operator can then point it at any target and choose from a range of attack methods. In this campaign, the targets were game servers.
The botnet supports a broad range of attack methods. Several are designed specifically for gaming infrastructure: not adapted from generic flooding tools, but built with clear knowledge of how game servers work and which protocols they depend on.
The Source Engine Query method is the clearest signal. That protocol is specific to game servers. You don't include it in a general-purpose DDoS tool unless gaming infrastructure is exactly what you're targeting.
Jenkins occupies a privileged position in your infrastructure. It has access to source code, deployment credentials, cloud provider keys, and the ability to push directly to production. An attacker with code execution on a Jenkins server isn't just running a DDoS bot. They have a foothold that touches your entire software supply chain.
This is why exposed CI/CD infrastructure consistently appears in attack surface assessments. Most security teams monitor their web applications and databases. Jenkins instances spun up for a specific project and never decommissioned often sit entirely outside that scope.
Development environments compound the problem. They change rapidly, are often set up by individual developers rather than security teams, and rarely go through the same hardening process as production infrastructure. A Jenkins server that no one's actively watching is exactly what attackers scan for.
If you suspect your Jenkins infrastructure may have been targeted, the following indicators of compromise are worth checking immediately:
The mitigations here are well understood. The hard part is applying them consistently across every Jenkins instance in your environment, including ones you may not know exist.
This campaign reflects a shift in how DDoS botnets are built. Rather than general-purpose flooding tools, threat actors are now developing infrastructure tailored to specific industries, with attack methods designed to cause maximum disruption to their chosen targets. The gaming sector has been a consistent target for this reason: the financial consequences of downtime are immediate and quantifiable.
For organisations outside gaming, the lesson is about the initial access vector, not the payload. Exposed Jenkins servers are exploitable regardless of what the attacker intends to do with access. In this campaign, the result was DDoS bots. In another, it could be credential theft, code tampering, or a full supply chain compromise.
The combination of an easy entry point, sophisticated persistence techniques, and purpose-built attack capabilities makes this botnet worth monitoring, even if your organisation has nothing to do with game servers.
Jenkins' scriptText endpoint isn't a vulnerability in the traditional sense. It's a legitimate feature that lets authorised users execute Groovy scripts on the server. The problem arises when Jenkins instances are deployed without authentication or left exposed to the internet, allowing anyone to submit and run scripts. Attackers exploit this misconfiguration to achieve remote code execution without needing to find or exploit any software flaw.
Check your Jenkins logs for unexpected scriptText API calls, particularly any that triggered file downloads or executed bash or PowerShell commands. On Linux hosts, look for processes named ksoftirqd/0 or kworker that aren't legitimate kernel threads: check whether corresponding entries exist in /proc. Monitor for outbound connections on TCP 5444 and look for unexpected binaries in /tmp or C:\Windows\Temp.
The DDoS capabilities are designed for gaming infrastructure, including Source Engine Query attacks that target game server protocols. But the initial compromise vector targets any organisation with an internet-facing CI/CD server. If your Jenkins instance is compromised, the attacker has access to your build pipelines and deployment credentials regardless of what industry you're in.
Treat it as an active compromise. Isolate the affected host immediately and preserve logs for forensic analysis. Conduct a full review of what code was executed on the Jenkins server and what credentials it had access to. Assume any secrets stored in Jenkins have been exfiltrated: API keys, deployment credentials, repository tokens, all of it.
The initial exploitation requires external access to the Jenkins scriptText endpoint. Instances on internal networks that aren't reachable from the internet aren't at risk from this specific attack vector. That said, if a machine on your internal network is already compromised and can reach an internal Jenkins instance, the same technique can be used for lateral movement. Enabling authentication on internal instances is still recommended.
Source: Darktrace Research, March 2026
