admin 
A new botnet campaign is turning poorly secured Jenkins servers into attack nodes aimed at online game infrastructure, including Valve Source Engine servers used for titles such as Counter-Strike and Team Fortress 2. The activity shows how a single exposed continuous integration system can be repurposed to generate UDP, TCP and application-layer floods against multiplayer platforms.
Cybersecurity researchers observed the activity on March 18, 2026, after a threat actor gained access to a Jenkins honeypot configured with weak credentials. The attacker abused Jenkins’ scriptText function, which can execute Groovy scripts, to run commands on the compromised host. Jenkins documentation states that its Groovy script console can run arbitrary scripts within the controller runtime or on agents, making administrative access highly sensitive when exposed to the internet.
The malware chain contains separate execution paths for Windows and Linux systems. On Windows, the script downloaded a payload from 103.177.110.202, saved it in the Windows Temp directory, renamed it to appear less suspicious, removed download restrictions and opened TCP port 5444 for command-and-control traffic. On Linux, it used a Bash one-liner to fetch a 64-bit binary into /tmp and execute it.
Once installed, the Linux payload attempted to remain active by setting Jenkins-related environment variables to “dontKillMe”, a technique designed to prevent Jenkins from terminating long-running jobs. It then deleted its original executable, renamed itself to resemble legitimate Linux kernel worker processes such as “ksoftirqd/0” or “kworker”, ran in the background, redirected output to /dev/null and ignored termination signals.
The bot then connected to its command-and-control server, reported the system architecture and waited for instructions. Its command set included utility functions such as keep-alive, stop and self-update, alongside attack commands that accepted a target IP address, port and duration. The reuse of one IP address for payload delivery, command-and-control and other stages made the infrastructure simpler but less resilient to takedown.
The campaign’s most notable feature is its gaming focus. One attack mode sends Valve Source Engine query packets, a method that can force game servers to generate heavier responses and drain resources with limited attacker bandwidth. Another “special” function can target port 27015, commonly associated with Source Engine servers, while also supporting crafted traffic for DNS and NTP services.
Valve’s Source Engine Dedicated Server supports multiplayer gameplay for Source-based titles, including Counter-Strike and Team Fortress 2. That makes the malware relevant not only to game publishers but also to community server operators, hosting providers and esports environments where short outages can disrupt matches, rankings and paid services.
The botnet also supports broader volumetric and application-layer techniques. Its UDP flood functions can send large random packets to saturate bandwidth or smaller packets to maximise packet rates. TCP push floods and HTTP GET floods add further pressure, although several advertised attack modes appear to map to the same underlying functions, suggesting either capability inflation or unfinished features.
The incident fits a wider pattern in which gaming remains a favoured DDoS target because services depend on low latency, predictable uptime and real-time connectivity. Cloudflare’s 2025 fourth-quarter DDoS report said the number of DDoS attacks more than doubled in 2025, while the company reported a record 31.4 Tbps attack at the end of that year.
Jenkins remains central to software delivery pipelines, often holding credentials, build scripts and access to code repositories or deployment systems. A compromised instance can therefore become more than a DDoS node: it may expose secrets, enable lateral movement or weaken the integrity of software releases. Jenkins security advisories during 2026 have continued to warn about flaws that can lead to file writes or code execution under specific configurations.
Defensive steps are straightforward but often neglected. Jenkins servers should not be exposed directly to the public internet unless strictly necessary; administrative functions should be protected by strong authentication, least-privilege access, network restrictions and prompt patching. Script console access should be limited to trusted administrators, while build agents and controllers should be monitored for suspicious downloads, unexpected processes and unusual outbound connections.
