TL;DR: Kaiji malware targets Linux servers and IoT devices through exposed services, then establishes persistence with system services, cron jobs, and configuration changes while using proxy and DDoS functionality to turn compromised hosts into botnet infrastructure, according to Aqua Security. The pattern shows that NHI and workload controls fail when internet-facing access, weak authentication, and runtime drift are left ungoverned.
At a glance
What this is: This Aqua Security research dissects Kaiji malware, showing how exposed Linux services, persistence tricks, and proxy-based botnet functions combine into a durable compromise pattern.
Why it matters: For IAM and NHI practitioners, it is a reminder that service exposure and weak authentication are access problems first, not just endpoint detection problems.
👉 Read Aqua Security's analysis of Kaiji malware persistence and detection
Context
Kaiji malware is a Linux and IoT compromise pattern built around exposed services, weak credentials, and persistence after initial access. In NHI terms, the problem is not only host infection, but unmanaged machine access that persists outside normal identity governance.
Aqua Security’s analysis places the attack in a familiar governance gap: internet-facing SSH, hidden startup scripts, cron-based relaunch, and command tampering. That is not an unusual starting point for botnet malware, but it is a revealing one for teams that assume workload access is controlled once a system is provisioned.
Key questions
Q: How should security teams handle weak credentials on exposed Linux services?
A: Treat them as identity exposure, not just account hygiene. Restrict access to known sources, remove password login where possible, and pair key-based authentication with MFA or network controls. Then review the exposed service as a machine identity that can be abused for persistence, proxying, or lateral movement once compromised.
Q: When does malware persistence become an NHI governance issue?
A: It becomes an NHI governance issue when a compromised workload can keep reintroducing itself through services, cron jobs, profiles, or policy changes. At that point, the problem is not only detection. It is lifecycle control over how the machine is allowed to execute after access is gained.
Q: What is the difference between endpoint malware detection and workload identity governance?
A: Endpoint detection looks for malicious activity on a host. Workload identity governance asks whether the host should have been able to accept access, persist changes, or relay traffic in the first place. The second approach reduces blast radius before malware turns a system into reusable infrastructure.
Q: How can teams spot proxy abuse on compromised Linux systems?
A: Watch for hosts that suddenly act as SOCKS5 or HTTP relays, especially if they also show unusual outbound WebSocket or TLS sessions. Correlate that behavior with unexpected startup services, cron entries, and process-hiding tactics. Proxy functions on non-proxy systems are a strong compromise indicator.
Technical breakdown
How Kaiji turns exposed SSH into persistent access
Kaiji begins with opportunistic access to internet-facing services, in this case exposed SSH with a weak password. Once inside, the malware copies itself into multiple locations and creates systemd units and SysV init scripts so it relaunches during startup. This is a classic persistence chain: initial access, self-installation, and automatic execution through native service managers. The important technical detail is that the malware does not depend on one mechanism. It uses several launch paths so that removing a single file or service does not end the compromise. That makes containment a lifecycle problem, not a one-time cleanup task.
Practical implication: Treat exposed admin services and weak passwords as NHI exposure points that require continuous control, not periodic review.
Why proxy functionality matters in botnet malware
Kaiji is not just a payload that runs commands. It includes SOCKS5 and HTTP proxy capability, plus command-and-control channels over HTTP, HTTPS, and WebSocket. That means the compromised host can relay traffic for other malicious activity while still blending into normal network patterns. For defenders, this changes the detection model. A host may be doing more than launching DDoS traffic. It may also be forwarding connections, masking upstream activity, or supporting later-stage access. In NHI governance terms, relay capability increases blast radius because the compromised identity or workload becomes an infrastructure node for additional abuse.
Practical implication: Monitor for proxy-like behavior on systems that should not broker traffic, especially where workload identity is already exposed.
What defense evasion looks like in Linux malware
Kaiji uses several defense evasion techniques, including bind-mounting normal directories over /proc entries and tampering with userland commands such as ps, ss, netstat, ls, and lsof. It also installs SELinux policy changes that allow blocked actions to proceed. These techniques matter because they target the visibility stack, not only the application layer. If inspection tools are filtered or process metadata is hidden, responders may miss the real execution path. For NHI and workload security, this is a reminder that runtime enforcement and integrity monitoring must be designed to survive local compromise, not just detect it after the fact.
Practical implication: Pair runtime policy enforcement with independent telemetry so compromised hosts cannot fully rewrite their own evidence trail.
Threat narrative
Attacker objective: The attacker’s objective is to maintain durable control of Linux hosts so they can proxy malicious traffic and contribute to distributed denial-of-service activity.
- entry: Attackers gained access through exposed SSH with weak authentication, then dropped the Kaiji payload onto the host.
- escalation: The malware copied itself into multiple paths and created system services, init scripts, and cron jobs to ensure relaunch as root or at boot.
- impact: The compromised system was turned into a persistent botnet node that could proxy traffic and launch DDoS attacks while hiding its activity.
Breaches seen in the wild
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Kaiji is best understood as an identity persistence problem, not just a malware problem. The sample survives by attaching itself to startup services, cron, shell profiles, and SELinux exceptions. That means the real control failure is not initial compromise alone, but the absence of durable governance over how a machine identity can execute after it is touched. Practitioners should treat post-compromise persistence as an NHI lifecycle failure.
Identity blast radius matters more than the initial exploit path. Kaiji can convert a single Linux host into a relay point for proxy abuse and DDoS activity. Once a workload identity can be repurposed that way, the issue is no longer containment of one process but the scale of secondary abuse created by that identity. Teams should map which services can become traffic brokers under local compromise.
Runtime visibility has to survive local tampering. Kaiji hides processes, alters command output, and manipulates proc visibility. That is a strong signal that host-based inspection alone is fragile when the adversary has execution on the box. NHI governance must assume the compromised workload can lie about its own state and should therefore rely on layered telemetry and policy enforcement.
Weak authentication on internet-facing services remains a recurring machine identity failure mode. The article’s entry point is straightforward, but the downstream effects are not. Once a service account, login path, or shell entry point is open to the internet, malware can use it as an identity bridge into persistent infrastructure abuse. Practitioners should reclassify exposed admin access as an identity risk, not only a perimeter risk.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, showing that controls often fail at the point of implementation rather than policy.
- For teams dealing with Linux malware and NHI sprawl, the next step is to align secret handling with NHI Lifecycle Management Guide and keep the lifecycle visible end to end.
What this signals
Identity blast radius is now a practical control objective for Linux workloads. Kaiji shows how one exposed service can become a persistent relay node, which means teams should measure not just whether access exists but how far that access can be repurposed. The control question shifts from detection alone to containment of reuse, privilege, and outbound traffic paths.
With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, per The State of Secrets in AppSec, the broader governance lesson is that exposed credentials and automation often intersect in ways teams underestimate. That makes machine access hygiene part of both NHI and AI risk management.
Runtime deception must be assumed. Once malware can hide processes and tamper with command output, local inspection loses trust value. Teams should prepare for evidence that is partial, filtered, or false, and build response models that combine host telemetry, network observation, and immutable logging from outside the compromised system.
For practitioners
- Harden exposed SSH and shell access Eliminate weak passwords, restrict source IPs, and require key-based access with MFA where the service supports it. Review every internet-facing administration path as a potential NHI entry point.
- Sweep for startup persistence artifacts Look for unexpected systemd units, SysV scripts, cron entries, and shell profile changes that launch the same binary from multiple locations. Remove all persistence paths before declaring the host clean.
- Monitor for relay and proxy behavior Alert on SOCKS5, HTTP proxy, WebSocket C2 patterns, and unusual outbound forwarding from hosts that should not broker traffic. Proxy capability often indicates the machine is being used as an abuse platform, not only as an endpoint.
- Validate runtime integrity independently Use separate telemetry for process, file, and mount-state validation so local tampering with ps, lsof, or /proc cannot fully hide the compromise. Assume a hostile process can manipulate its own inspection surface.
Key takeaways
- Kaiji shows how exposed Linux access can be converted into durable machine compromise through multiple persistence paths.
- The malware’s proxy and DDoS functions turn a single host into reusable infrastructure, expanding the security impact beyond the initial infection.
- Teams should treat internet-facing admin access, runtime integrity, and lifecycle control as one NHI governance problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Kaiji relies on weak authentication and exposed access paths. |
| NIST CSF 2.0 | PR.AC-4 | The article centers on limiting and reviewing access for systems that can be repurposed. |
| NIST Zero Trust (SP 800-207) | SC-7 | Proxy abuse and lateral relay behavior are classic zero-trust boundary failures. |
Map exposed service accounts and host access to least privilege and review them regularly.
Key terms
- Workload identity: A workload identity is the machine-level identity used by a service, container, server, or automation component to authenticate and operate. In practice, it covers the credentials and trust relationships that let software execute, talk to other systems, and persist actions across restarts or redeployments.
- Persistence mechanism: A persistence mechanism is any technique that allows malware or unauthorized code to survive reboot, logout, or process termination. In Linux environments, that often includes system services, init scripts, cron jobs, shell profiles, and configuration changes that automatically relaunch the payload.
- Defense evasion: Defense evasion is the set of actions an attacker uses to hide execution, reduce visibility, or interfere with monitoring and response. On Linux, that can include tampering with process listings, obscuring filesystem paths, changing policies, or masking runtime data from standard tools.
- Proxy abuse: Proxy abuse occurs when a compromised host forwards traffic on behalf of an attacker, often to conceal origin or enable additional malicious activity. In NHI terms, it increases the blast radius because a single workload becomes a relay point for other operations, not just a victim system.
Deepen your knowledge
Kaiji malware persistence, proxy abuse, and Linux workload exposure are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for exposed services and machine identities, it is a useful place to start.
This post draws on content published by Aqua Security: Kaiji malware anatomy, persistence, and detection. Read the original.
Published by the NHIMG editorial team on 2026-01-16.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org