Notifications
Clear all
Topic starter
25/06/2026 12:10 am
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.
NHIMG editorial — based on content published by Aqua Security: How to Set Up Runtime Protection Against Malware Like Kaiji
Questions worth separating out
Q: How should teams stop malware that hides itself after initial execution?
A: Teams should combine runtime monitoring with enforcement that can block suspicious execution paths, unexpected persistence entries, and drift from the approved workload state.
Q: Why do containerised workloads need drift prevention for malware defense?
A: Containerised workloads need drift prevention because a workload can be approved at build time and still behave maliciously at runtime.
Q: What do security teams get wrong about persistence in Linux malware cases?
A: They often focus on removing visible processes and overlook the restart mechanism that restores the malware later.
Practitioner guidance
- Block fileless execution at runtime Move from detection-only posture to policy enforcement for execution paths that never write clear artefacts to disk, especially on shared Linux workloads and exposed container nodes.
- Treat startup persistence as an active indicator Alert on unexpected startup entries, scheduled tasks, and service registrations that can relaunch a payload after reboot, then validate whether the process tree matches the approved workload.
- Use drift prevention to compare approved and observed state Compare the running workload against its expected baseline and investigate any mismatch in binaries, startup behaviour, or command visibility as a potential compromise path.
What's in the full article
Aqua Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step runtime policy setup in the Aqua console for workload protection
- Specific control selections for blocking fileless execution and drift prevention
- Audit versus enforce mode guidance for runtime policy enforcement decisions
- Support-portal remediation references for teams that want implementation detail
👉 Read Aqua Security's guidance on runtime protection against Kaiji malware →
Kaiji malware persistence in containers: are your runtime controls ready?
Explore further
25/06/2026 9:01 am
Persistence is the real control failure here, not initial execution. Kaiji’s behaviour shows that workload security cannot stop at preventing the first malicious action. Once a host accepts a persistence mechanism, the attacker is no longer gambling on a single run, but on repeated re-entry after reboot and on the defender’s inability to see the planted artefact. Practitioners should treat persistence as the control boundary that determines whether an incident becomes a cleanup event or a lasting compromise.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%, according to Astrix Security & CSA.
A question worth separating out:
Q: What should teams do when runtime protection can only observe suspicious activity?
A: They should use observation for tuning, but move high-confidence malicious patterns into enforcement. If a threat family is built to survive and hide, passive visibility can arrive too late. The goal is to stop execution before the malware finishes setting up persistence and concealment.
👉 Read our full editorial: Runtime protection against Kaiji malware needs stronger drift control
