The original text is in EN, taken from the source site. Source ↗

Nozomi Networks Labs has documented Kairos, a previously undocumented Go-based DDoS bot for Linux. It turns compromised Linux devices into attack nodes that exhaust a victim’s connection capacity with thousands of idle TCP sessions.

Honeypot telemetry captured three Kairos builds. They differ only in the hard-coded C2 address and the Go compiler patch level (1.27.0 and 1.27.1), which points to a build-per-C2 distribution model.

According to the technical analysis published by Nozomi Networks Labs, attackers gained access through Telnet using the default root user with an empty password. Like the Tengu Linux bot, the operator then ran a shell sequence from /tmp.

The sequence fetched the architecture-matched payload with wget, curl, BusyBox wget and TFTP in turn, using chmod 777 and background execution on each copy. In the sample chain, 172[.]86[.]85[.]39 hosted the payload on TCP/8080 and acted as C2 on TCP/9999.

.webp)

Captures of Telnet Execution and Command Downloading Chain (Image Source: nozominetworks)

The bot connects to one hard-coded IPv4 address on TCP/9999 and sends a plaintext beacon: REGISTER linux amd64 . A keepalive newline follows every two seconds. If the session drops, the bot redials every five seconds with no jitter or retry limit.

It accepts only three commands: hold starts the flood, !ka cancels all attacks and pauses the bot, and !ku resumes the bot so it accepts attack commands again.

The binary has no persistence, self-propagation, command execution, payload download or anti-analysis logic. Its intact .gopclntab exposed symbols such as kairos/methods.HoldFlood and kairos/methods.holdConn.

.webp)

Reverse Engineered Command Processing Logic (Image Source: nozominetworks)

The bot starts 128 workers per CPU core, with a minimum of 256. A 16-core host therefore opens 2,048 concurrent connections per attack. Each worker completes a real TCP handshake with a five-second timeout.

It then sends one space character (0x20) every five seconds to hold the socket open. Failed connections retry every 100 milliseconds, which turns an attack on a refusing port into a connect storm.

This is not a spoofed SYN flood, so the victim sees the infected device’s real source IP. Large attacks can also exhaust the bot’s own file descriptors. Compared with larger Mirai derivatives such as the Evooo1Bot botnet, Kairos is minimal and built around one technique.

The bot rewrites os.Args[0] to [kworker/0:1] to imitate a kernel thread. It does not change the original argv memory or call prctl(PRSETNAME), so /proc//cmdline, comm and ps still show the real binary.

A userland ELF containing both [kworker/0:1] and the build path kairos/bot is almost certainly Kairos.

A YARA hunt on VirusTotal found six more samples for ARM, MIPS (big and little endian) and 32-bit x86. All use the known C2 172[.]86[.]85[.]39.

Defenders can protect environments by blocking egress to 91[.]92[.]42[.]84, 172[.]86[.]85[.]39 and 85[.]11[.]167[.]41 on ports 9999 and 8080, and blocking the attacker IPs 103[.]124[.]165[.]53, 45[.]129[.]56[.]140 and 45[.]129[.]56[.]222.

Security teams should add an IDS signature for the plaintext REGISTER linux beacon on TCP/9999, disable Telnet, and replace default or empty passwords. Furthermore, administrators should deploy the YARA rule across file and memory scanning and alert on “kernel worker” processes holding many outbound TCP connections.

Because each build changes its C2 address while the code stays the same, code-based signatures last longer than IP blocks.