TL;DR: Kaiji has evolved from a straightforward Linux and IoT threat into malware that uses persistence, fileless execution, and system tampering to stay hidden after compromise, according to Aqua Security. That makes runtime enforcement, drift prevention, and tamper-aware detection more important than simple post-infection cleanup.
Editorial analysis by NHI Mgmt Group, based on content published by Aqua Security: “How to Set Up Runtime Protection Against Malware Like Kaiji”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Kaiji demonstrates that runtime persistence can outlast routine cleanup when malware blends into startup paths and hides its own evidence.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime protection against Kaiji malware needs stronger drift control