Kaiji malware shows how exposed Linux services become botnet footholds

At a glance

What this is: Kaiji malware is a Linux and IoT botnet threat that gains access through exposed services, then hardens itself with multiple persistence and evasion methods.

Why it matters: It matters because workload and NHI governance fails when internet-facing services, weak authentication, and post-compromise drift are left outside continuous control.

Context

Kaiji malware is a Linux-focused botnet threat that exploits exposed services, then converts compromised systems into relay and denial-of-service infrastructure. In identity terms, the issue is not the malware family alone but the unmanaged service exposure that lets a machine identity become an entry point.

For IAM and NHI teams, the important lesson is that internet-facing access, weak passwords, and ungoverned runtime changes create a durable foothold even when the initial compromise looks routine. Kaiji also shows how persistence can be built from ordinary operating system mechanisms rather than exotic exploits.

The article’s attack flow is typical of exposed-service compromise rather than a one-off anomaly. That makes it relevant to any programme responsible for workload identity, host hardening, and service-account governance.

Key questions

Q: What breaks when Linux services are exposed with weak authentication?

A: Weakly protected internet-facing services stop being neutral infrastructure and become initial-access points for malware and botnet operators. In practice, the failure is not just login compromise. It is the absence of service boundary governance, which allows attackers to land, execute payloads, and convert the host into a durable foothold before defenders notice.

Q: Why do exposed Linux servers become botnet footholds so easily?

A: Because attackers do not need a novel exploit when a server accepts weak or misconfigured access and can be made to persist. Once inside, the host can be repurposed as proxy or DDoS infrastructure. The risk comes from standing reachability plus incomplete post-compromise control over runtime state, not from malware alone.

Q: How do security teams know whether persistence controls are actually working?

A: Look for shrinking dwell time, faster invalidation of old sessions, and fewer accounts that remain active outside their intended task scope. If an attacker or rogue actor can stay invisible long enough to stage destructive activity, the control is not working. Measure the time from anomaly to containment, not just the number of alerts generated.

Q: What should teams do when a server starts acting like a proxy node?

A: Treat it as an active compromise and isolate the host before the relay can be used for further attack traffic. Then verify service units, cron entries, login scripts, and command output against known-good baselines. The key question is whether the machine is still performing the role it was intended to perform.

Technical breakdown

How exposed SSH services become the first foothold

Kaiji enters through internet-connected services, with the article’s honeypot showing misconfigured SSH access and a weak password as the observed path. That is a classic exposed-service compromise: the attacker does not need a novel exploit if an externally reachable service accepts weak or unmanaged authentication. Reports cited in the article also suggest other initial access vectors, which reinforces that the real weakness is broad service exposure rather than one protocol alone. In identity terms, the server’s reachable service boundary is the attack surface, and the login mechanism becomes the pivot from exposure to execution.

Practical implication: inventory and constrain internet-facing services before relying on downstream malware detection.

Why Kaiji persistence survives normal cleanup

Kaiji creates persistence through system services, SysV init scripts, cron jobs, and login scripts, then copies itself into plausible-looking filenames under paths such as /boot, /usr/lib, and /etc/profile.d. That matters because persistence is not a single artefact here; it is a layered launch chain that can survive the removal of one copy. The malware also weakens SELinux enforcement by generating and installing a policy that permits previously denied actions, which turns local security controls into part of its survival strategy. This is runtime drift in operational form: the host’s trusted state changes after compromise.

Practical implication: treat unexpected service units, cron entries, and policy changes as persistence indicators, not administrative noise.

How Kaiji turns compromised hosts into botnet infrastructure

Kaiji’s payload is built for long-term relay and attack use, not just infection. The article describes a multi-protocol platform with SOCKS5 and HTTP proxying, C2 over HTTP, HTTPS, and WebSocket, plus volumetric and protocol-specific DDoS capabilities. That combination lets the malware hide outbound traffic inside common protocols while using the host as both a traffic relay and a denial-of-service node. It also includes process hiding and command tampering, which frustrate inspection by masking files, processes, and runtime metadata. In practice, this is what a botnet foothold looks like once the host becomes operationally useful to the attacker.

Practical implication: monitor for proxy activity, unusual outbound tunnels, and process-manipulation behaviour as signs of botnet conversion.

Threat narrative

Attacker objective: The attacker aims to convert exposed Linux hosts into durable proxy and DDoS nodes under botnet control.

1. Entry begins with exposed or misconfigured Linux services, including SSH access with weak authentication, which gives the attacker a foothold on the host.
2. Credential or access abuse follows when the service accepts the login path and the attacker deploys the Kaiji payload onto the compromised system.
3. Escalation and persistence are established through system services, cron jobs, login scripts, and SELinux policy changes that keep the malware launching after reboot or login.
4. Impact is achieved when the host is turned into proxy and DDoS infrastructure, with the malware hiding its activity to prolong botnet use.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exposed Linux services are not just attack surface, they are identity boundary failures. Kaiji works because the service boundary is reachable, the authentication is weak, and the host is allowed to accept untrusted runtime changes. That is a governance problem, not merely a detection problem. In NHI terms, the service is acting as an unmanaged non-human identity with no effective lifecycle control. Practitioners should treat externally reachable services as governed identities with explicit trust boundaries, not default infrastructure.

Kaiji demonstrates persistence layering, not single-point compromise. The malware uses system services, cron, login scripts, and policy changes to survive cleanup by relying on multiple launch paths. That pattern shows why one removed artefact rarely equals eradication when the host state itself has been rewritten. The named concept here is runtime drift debt: once post-compromise changes accumulate across service, boot, and policy layers, remediation must prove state restoration, not just malware deletion. Practitioners need to assume the host is no longer in its original control state.

Host hardening and workload identity governance are now the same problem in different clothes. A Linux server that exposes SSH, runs weak passwords, and allows untracked service creation behaves like an unmanaged machine identity with standing privilege. Kaiji exposes how quickly that standing access can be converted into botnet utility. The implication is that identity governance must extend to service launch permissions, host configuration drift, and the trust level granted to internet-facing workloads.

Botnet conversion should be read as privilege monetisation. Once Kaiji lands, the host is not merely compromised, it is repurposed as an authenticated relay and attack platform. That shift matters because the attacker extracts value from the system’s network position, not just its data. Framework-wise, the pattern aligns with OWASP-NHI concerns around insecure authentication, overprivileged NHI behaviour, and long-lived secrets that keep services reachable. Practitioners should map exposed services to their real blast radius, not their intended function.

Detection has to look for state transitions, not just known bad files. Kaiji hides processes, tamper with common commands, and blends into ordinary service paths, which means static signatures will always lag. The article’s value is that it shows a chain of configuration, service, and process changes that together define compromise. The useful control question is whether your environment can detect when a trusted Linux service starts behaving like a relay node. Practitioners should anchor detection to state drift and abnormal runtime behaviour.

What this signals

Runtime drift debt: Kaiji shows how quickly a Linux host becomes untrusted once attacker-controlled services, boot paths, and policy state diverge from the baseline. That is why post-compromise governance has to measure restored state, not just malware removal.

A server that can be repurposed as a proxy or DDoS node has crossed from workload management into identity governance failure. The practical question for teams is whether their controls can stop a service from becoming a launch platform after the first login succeeds.

For practitioners

• Harden externally reachable Linux services Remove weak passwords, disable unnecessary SSH exposure, and restrict internet-facing access to the smallest possible set of hosts and source networks.
• Monitor for hostile persistence paths Alert on unexpected systemd units, SysV init scripts, cron entries, and login scripts that launch binaries from writable or unusual locations.
• Detect runtime drift in host policy Watch for SELinux policy changes, altered service files, and new executable copies in /boot, /usr/lib, /etc/profile.d, or similar launch paths.
• Inspect for proxy and relay behaviour Flag SOCKS5, HTTP proxy, WebSocket, and unusual outbound tunnel activity from servers that should not act as traffic relays.
• Hunt for command tampering and process hiding Compare live command output and /proc state against expected baselines when standard tools begin hiding processes, files, or modules.

Key takeaways

• Kaiji is a Linux and IoT botnet threat that succeeds by turning exposed services into durable host footholds.
• The article shows layered persistence through system services, cron jobs, profile scripts, and SELinux policy changes.
• The most relevant control failure is unmanaged service exposure combined with runtime drift that lets a compromised host stay operational for the attacker.

Key terms

• Exposed Service: An exposed service is a network-reachable application or protocol endpoint that can be probed from outside the trusted boundary. When authentication is missing or weak, it becomes a direct route to code execution, credential abuse, or foothold establishment without requiring user interaction.
• Policy Layering: Policy layering is the practice of applying different rules at different decision points, such as application, entitlement, and review. It improves scale and precision when it is deliberate. It becomes risky when layers overlap without a clear authority model or exception path.
• Runtime Drift: Runtime drift is the gap between an AI agent’s approved authority and its actual behaviour as conditions change. It appears when the agent adapts to new context, new integrations, or new instructions and begins acting outside the scope that governance originally defined.
• Botnet Foothold: A botnet foothold is a compromised host that has been repurposed to relay traffic, launch attacks, or support command-and-control operations. It is the stage where initial access becomes attacker utility, turning a server into part of an external criminal infrastructure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.