Runtime protection against Kaiji malware needs stronger drift control

At a glance

What this is: Aqua Security examines how Kaiji malware persists inside Linux and container environments by using stealth, startup persistence, fileless execution, and tamper tactics that evade routine cleanup.

Why it matters: This matters because runtime security for container and workload teams has to detect persistence and block drift in execution, not assume compromise can be handled after the fact.

Context

Kaiji is malware that targets Linux-based servers and IoT devices, and the article focuses on how its persistence techniques make compromise harder to spot and harder to remove. In identity and workload terms, this is a runtime governance problem: the malicious behaviour survives normal administrative checks because it manipulates what operators can observe.

The security gap is not simply infection. It is post-compromise persistence through fileless execution, startup hooks, and tampering with basic diagnostic commands, which means defenders need controls that operate at runtime rather than depending on periodic review or manual cleanup.

For container and workload security teams, the article frames drift prevention and tamper-aware detection as the relevant control plane, because the attacker’s objective is to stay planted long enough for ordinary remediation to fail.

Key questions

Q: What breaks when malware can hide its own files and processes at runtime?

A: Traditional host inspection loses reliability when malware tampers with the commands operators use to confirm what is running. In that situation, local output becomes part of the attack surface, so defenders need independent telemetry, runtime policy enforcement, and tamper-aware response instead of trusting the compromised system to describe itself accurately.

Q: Why do fileless threats increase the risk of container drift?

A: Fileless threats reduce the usefulness of file-based scanning because the malicious behaviour may exist only in memory or transient runtime state. That makes drift the practical control boundary, since the workload can diverge from its approved configuration without leaving a durable artefact for post-event review.

Q: How should security teams handle persistence indicators in Linux workloads?

A: Treat unexpected startup entries, suspicious auto-run mechanisms, and altered administrative output as signs of runtime compromise, not isolated anomalies. The right response is to verify the live workload against an independent baseline and contain any system that no longer matches the intended execution model.

Q: What is the difference between image scanning and runtime protection for malware like Kaiji?

A: Image scanning checks what was built or deployed, while runtime protection checks what the workload is doing after launch. For malware that uses persistence, fileless execution, and command tampering, runtime controls matter more because the threat emerges in the live execution path, not only in the artefact that was originally shipped.

Technical breakdown

How Kaiji keeps persistence after reboot

Kaiji’s persistence model relies on placing itself where routine reboots and basic host checks will not remove it. The malware can plant startup entries or other auto-run mechanisms so the malicious code returns when the system restarts. That makes the threat durable in the same way unmanaged workload state becomes durable: once the malicious change is part of the execution path, simple cleanup is no longer enough. In containerised environments, this is especially dangerous when runtime state and image state are confused, because defenders may inspect one layer while the malware survives in another. Runtime protection has to observe the active workload, not only the static artefact.

Practical implication: treat unexpected startup persistence as a runtime integrity failure, not a one-time malware event.

Why fileless execution and drift prevention are linked

Fileless execution means the malware can run without leaving the usual on-disk artefacts defenders expect to scan. That breaks a lot of traditional detection logic, especially when security tooling is tuned to find files rather than behaviour. Drift prevention matters because once a running workload changes from its approved state, the attacker has already moved from introduction to execution. In containers, that drift can include altered startup behaviour, added scripts, or runtime modifications that do not match the original deployment intent. The technical problem is not just execution, but execution that no longer resembles the trusted baseline.

Practical implication: enforce runtime policies that stop unauthorized execution paths, not just post-event file inspection.

How tampering with diagnostic tools hides the intrusion

Kaiji’s stealth depends on interfering with the administrative tools operators use to confirm what is running, what is connected, and what has changed. By altering command output or removing visible traces, the malware makes the host appear normal even when it is not. This is a classic anti-forensics pattern, but here it is paired with persistence, so the system both stays infected and appears clean. For defenders, that means detection must compare expected host behaviour against independent telemetry, because a compromised workload can no longer be trusted to describe itself accurately.

Practical implication: use tamper-aware telemetry and independent runtime signals instead of trusting local administrative output.

Threat narrative

Attacker objective: The attacker objective is to remain hidden on the host for as long as possible so the malware survives cleanup and continues to control the compromised workload.

1. Entry occurs on Linux-based servers or IoT devices that become exposed to Kaiji through the environments it targets, giving the malware a foothold to begin its runtime activity.
2. Credential access is not the central story here; instead, Kaiji relies on stealthy runtime persistence, startup hooks, and fileless execution to keep operating once present.
3. Escalation comes from tampering with standard administrative views and system reporting, which hides malicious files and processes from routine inspection.
4. Impact is long-lived hidden residency that makes cleanup harder and allows the malware to remain planted across reboots and operational checks.

Breaches seen in the wild

• Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.

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

Runtime drift is the control failure Kaiji exploits: the malware succeeds when defenders rely on static cleanliness checks while the live workload has already diverged. In container and Linux environments, the approved image or last scan is not the same thing as the active runtime state. The practitioner takeaway is to govern execution drift as a first-class identity and workload risk, not a cleanup problem after compromise.

Stealthy persistence turns routine administration into an unreliable signal: once a malware strain can alter what basic commands report, operators lose confidence in the host as its own source of truth. That breaks the assumption behind many response workflows that local inspection can validate integrity. The implication is that runtime trust has to come from independent control points, not the workload itself.

Persistence plus fileless execution creates an identity blast radius at runtime: the compromise is not just a hidden file, it is a living execution path that survives reboots and evades simple hunting. In NHI terms, the workload is behaving like an unmanaged runtime actor with durable privilege over itself. Practitioners should treat that as a lifecycle and governance problem, not only a detection problem.

Container security programmes need tamper-aware governance, not just image hygiene: the article shows why pre-deployment scanning and build-time assurances stop short when the live process mutates after launch. Runtime Protection, drift control, and anti-tamper telemetry belong in the same governance model because the attack happens after trusted delivery. The right conclusion is that runtime state must be continuously constrained and independently observed.

Kaiji illustrates why control-plane assumptions fail when the system changes its own evidence: if an attacker can hide files, hide processes, and reframe what administrators see, then the environment is no longer self-reporting truthfully. That is the governance gap practitioners need to name. The practical conclusion is to design for untrusted runtime evidence and enforce integrity from outside the workload boundary.

What this signals

Runtime drift control is the real gap exposed here: once a workload can alter its own visible state, the security programme can no longer depend on post-infection cleanup as the primary defence. Teams need policy enforcement at execution time and independent verification of host behaviour, because the compromised system cannot be treated as a trustworthy source of truth.

Container and Linux estates should be evaluated for tamper resilience, not just malware signatures: Kaiji shows how persistence, fileless execution, and hidden startup hooks combine into a long-lived runtime problem. The programme implication is to look for controls that constrain live behaviour, detect deviation, and preserve observability when the host itself is under attack.

For practitioners

• Harden runtime policies against fileless execution Block execution paths that do not match approved runtime behaviour, especially where workloads can run code without a corresponding file artefact.
• Turn on drift prevention for container workloads Treat unexpected startup entries, modified scripts, and altered process behaviour as policy violations that should be blocked or isolated at runtime.
• Add tamper-aware detection for host reporting Correlate local command output with independent telemetry so a compromised workload cannot conceal processes, connections, or persistence mechanisms.
• Review persistence indicators in Linux and IoT estates Look for unexpected startup mechanisms, scheduled tasks, and other auto-run paths that allow malware to reappear after reboot.

Key takeaways

• Kaiji demonstrates that runtime persistence can outlast routine cleanup when malware blends into startup paths and hides its own evidence.
• The article points to drift control, fileless execution blocking, and tamper-aware detection as the controls that matter most.
• Teams should treat the live workload as untrusted once local commands or outputs can no longer be verified independently.

Key terms

• 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.
• Fileless Execution: Fileless execution is malicious activity that runs without leaving a conventional on-disk payload for scanners to inspect. It reduces obvious forensic artefacts and shifts detection toward behavioural controls, memory inspection, and runtime enforcement rather than file-based hygiene alone.
• Tamper detection: Tamper detection is the ability to identify unauthorised changes to identity records, policies, or audit data. In identity programmes, it matters because compliance evidence is only useful if the underlying record can be trusted. Detection must be paired with logging, retention, and review so edits are visible and provable.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.

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 building or maturing an IAM programme, it is worth exploring.