New DDoS botnet abuses exposed Jenkins servers to attack online game servers

A newly documented DDoS botnet is abusing exposed Jenkins servers to launch attacks against online game infrastructure, including servers that use Valve’s Source Engine.

Darktrace researchers found the malware after an attacker targeted one of the company’s Jenkins honeypots on March 18, 2026. The campaign uses Jenkins access to deploy a multi-platform payload, then waits for commands to flood selected targets.

The botnet stands out because it includes game-specific attack functions. One method sends Source Engine query traffic that can force targeted game servers to respond with larger amounts of data, putting extra pressure on server resources.

What happened

Darktrace operates a global honeypot network called CloudyPots to observe real-world attacker behavior. One of those honeypots ran Jenkins, a popular continuous integration system used by developers to build, test, and automate software workflows.

The Jenkins instance used a weak password by design, allowing researchers to watch how attackers attempted to abuse the service. In this case, the attacker used Jenkins to run a malicious Groovy script and deploy a DDoS botnet payload.

The issue does not mean Jenkins is unsafe by default. It shows the risk of leaving powerful administration tools exposed to the internet with weak access controls.

At a glance

Category	Details
Threat type	DDoS botnet
Initial access	Exposed Jenkins instance with weak authentication
Observed by	Darktrace CloudyPots honeypot network
Date observed	March 18, 2026
Main targets	Online game servers, including Valve Source Engine servers
Supported systems	Windows and Linux
Main attack types	UDP floods, TCP push attacks, HTTP request floods, and Source Engine query attacks
Known C2 port	TCP 5444

How the Jenkins abuse works

Jenkins includes a Groovy script console for administration and troubleshooting. When properly secured, this feature helps administrators manage Jenkins systems.

If attackers gain access to it, they can run commands inside the Jenkins environment. Darktrace said the attacker abused the scriptText endpoint to send a malicious Groovy script to the honeypot.

The script checked the operating system and then used different installation steps for Windows and Linux. This helped the attacker deploy the botnet across more than one type of server.

Windows and Linux payloads

On Windows, the script downloaded a payload and saved it under a name that looked like a system update file. It then renamed the file and added a firewall rule for the port used by the botnet’s command-and-control traffic.

On Linux, the script downloaded a payload into a temporary directory and executed it. The same attacker-controlled IP address handled payload delivery and command-and-control activity.

Darktrace noted that this is unusual. Many malware operators separate delivery infrastructure from command-and-control systems so they can keep infected devices active if one server gets taken down.

Why game servers are a target

Game servers are sensitive to latency, downtime, and packet floods. A short disruption can make a multiplayer match unplayable and push players away from a server or platform.

The malware includes a function designed around Valve Source Engine server queries. Source Engine powers games such as Counter-Strike and Team Fortress 2, making the attack relevant to server operators in those communities.

The Source Engine query method can be effective because the attacker sends small requests that cause the target server to send larger responses. Repeating that process can drain server capacity and create service disruption.

DDoS methods used by the botnet

Attack method	Purpose
UDP flood	Sends large volumes of random UDP traffic to consume bandwidth.
UDP packets-per-second flood	Sends smaller packets at high speed to overwhelm packet handling.
TCP push attack	Rapidly opens connections and sends data to pressure the target.
HTTP request flood	Sends repeated HTTP requests to exhaust application resources.
Source Engine query attack	Targets Valve Source Engine game servers with repeated query packets.
Special UDP modes	Targets services such as DNS, NTP, and Source Engine ports.

How the malware hides on Linux

After landing on a Linux system, the malware tries to stay active and avoid easy removal. It sets Jenkins-related environment variables so Jenkins does not automatically kill the long-running process.

It then removes its original file from disk and renames itself to look like a normal Linux kernel process. Darktrace said the malware used names such as ksoftirqd/0 and kworker.

The payload also runs in the background, redirects output to /dev/null, and ignores common termination signals. These behaviors make it harder for administrators to notice and stop the process through normal checks.

Command-and-control behavior

Once active, the malware connects to its command-and-control server and reports the system architecture. After that, it waits for instructions.

Darktrace found utility commands for keep-alive checks, stopping the malware, and updating the payload. The attack commands take a target IP address, port, and duration.

This structure gives the operator a simple way to turn compromised servers into DDoS nodes. Even low-value exposed servers can become useful when attackers add them to a larger botnet.

Why this matters for Jenkins administrators

Jenkins is widely used in development and DevOps environments. A compromised Jenkins server can create more risk than a single infected machine because it may connect to code repositories, build pipelines, credentials, scripts, and deployment systems.

In this case, the attacker used Jenkins as a path into the host system. The campaign shows why internet-facing Jenkins instances need strict authentication, limited network exposure, patching, and continuous monitoring.

Administrators should also treat unexpected outbound traffic from build servers as suspicious. CI systems often have broad access, so attackers may use them for malware delivery, cryptomining, data theft, or DDoS activity.

Recommended defenses

• Do not expose Jenkins directly to the public internet unless it is necessary.
• Use strong authentication and remove weak or shared passwords.
• Restrict Jenkins administration access to trusted networks or VPNs.
• Review access to the Jenkins script console and related endpoints.
• Monitor Jenkins for unusual Groovy script execution.
• Block suspicious outbound traffic from CI and build servers.
• Watch for unexpected traffic to TCP port 5444.
• Review systems for processes pretending to be ksoftirqd/0 or kworker.
• Investigate outbound communication with 103.177.110.202.
• Use DDoS protection for public-facing game infrastructure.

Indicators for defenders

Indicator	Type
103.177.110.202	Attacker and command-and-control IP address
TCP 5444	Command-and-control port
F79d05065a2ba7937b8781e69b5859d78d5f65f01fb291ae27d28277a5e37f9b	Linux payload hash
ksoftirqd/0	Possible fake process name used by malware
kworker	Possible fake process name used by malware

FAQ