TL;DR: Koske malware demonstrates how AI-shaped tradecraft can blend polyglot image lures, in-memory execution, rootkit concealment, and persistence changes to turn Linux endpoints into cryptomining infrastructure, according to Wazuh. The pattern reinforces that detection on Linux now depends on process, file, and configuration telemetry tied to identity-adjacent execution paths, not signature-only hunting.
At a glance
What this is: Koske malware is a Linux cryptojacking campaign that uses polyglot images, in-memory execution, rootkit concealment, and persistence changes to mine cryptocurrency while evading detection.
Why it matters: It matters because Linux detections that rely on file signatures alone will miss malware that abuses trust paths, runtime execution, and identity-adjacent persistence controls.
Context
Koske sits at the intersection of malware delivery, Linux endpoint defence, and cryptomining abuse. The core governance problem is not only that malicious code runs, but that it enters through ordinary development and content workflows that defenders may not treat as hostile. In practice, that means execution trust, file trust, and service trust all need to be monitored together.
The article is also relevant to identity-adjacent control points because persistence and execution paths on Linux often depend on service accounts, boot-time services, shell startup files, and tooling permissions. When those paths are weakly governed, malware can blend into normal administration activity and remain active long enough to mine resources and hide its tracks.
Key questions
Q: What breaks when trust-based malware delivery is not monitored closely?
A: When trust-based delivery is not monitored closely, attackers can blend malicious links, fake apps, or exploit payloads into routine user activity. That increases click-through, lowers suspicion, and lets the payload reach credential capture or remote execution stages before defenders notice. The failure is not just user error. It is the absence of controls that validate context before trust is granted.
Q: Why do polyglot files increase cryptojacking risk on Linux endpoints?
A: Polyglot files increase risk because the same object can look benign to users and security tools while still containing executable code. That lets attackers hide shellcode inside content that would not normally be treated as a threat. The risk rises when upload handling and runtime execution are not correlated.
Q: How should security teams detect malware that executes from memory instead of from disk?
A: Security teams should look for correlations between file writes and later execution events, especially when a binary never appears as a normal on-disk artifact. Tracking inode and device identity helps tie a saved payload to an exec event, which exposes fileless execution patterns and reduces reliance on manual memory dumping or debugger-based extraction. The practical goal is to surface the payload early enough for investigation and containment.
Q: What should teams do when startup files or systemd services are modified unexpectedly?
A: Treat those changes as potential persistence events and investigate whether the alteration is tied to a new binary, a downloader, or a concealed miner. Shell startup files and systemd units are high-value launch surfaces, so unauthorised edits often matter more than the file that triggered them. Contain the change before the next restart.
Technical breakdown
Polyglot image delivery hides execution payloads
A polyglot file is a single artifact that can be interpreted in more than one way, which makes it useful for hiding payloads inside content that looks benign. In this case, the JPEG appearance masks shellcode and supporting code appended to the image data. That design defeats simple file-type checks because the visible object is harmless-looking media while the executable material sits alongside it. The delivery problem is compounded when the file arrives through a development platform or exposed web service that is trusted to handle user uploads. Practical implication: inspect the full file structure and source path, not just the apparent MIME type or extension.
Practical implication: validate content beyond file extension and monitor upload paths that should never deliver executable material.
In-memory execution and rootkit concealment
In-memory execution means the malware runs without first needing a traditional on-disk executable path, which reduces the value of static file scanning. Koske then uses rootkit-style concealment, including library hooking through mechanisms such as LD_PRELOAD, to hide processes and files from normal inspection. That combination makes the endpoint appear cleaner than it is, especially when defenders rely on standard process listings or file browsing alone. The important control question is whether telemetry captures process creation, library loading, and hidden file behaviour at runtime. Practical implication: collect endpoint telemetry that can reveal runtime state changes even when the payload is not persisted as an obvious binary.
Practical implication: instrument runtime telemetry that can surface hidden processes, library injection, and concealed files.
Persistence through shell and service changes
Koske persists by modifying bash startup files and adding or abusing systemd services so the malware can relaunch after login or boot. That is a governance problem as much as a malware problem, because persistence depends on trusted configuration surfaces rather than only on a dropped executable. It also shows why defenders must watch for unexpected changes to shell profiles, service units, and other launch-time configuration artefacts. Once those are altered, the malware can survive routine reboots and continue mining resources. Practical implication: monitor configuration drift on startup paths as carefully as you monitor binaries in executable directories.
Practical implication: treat shell profiles and service units as high-value persistence surfaces and alert on unauthorised changes.
Threat narrative
Attacker objective: The attacker wants to convert Linux endpoints into covert cryptomining infrastructure while hiding the activity from standard detection and response workflows.
- Entry occurs through an improperly configured JupyterLab environment and polyglot JPEG lures that hide shellcode inside an apparently benign image file.
- Credential or execution trust is abused when the payload runs in memory, compiles supporting components, and fetches miner binaries for local use.
- Escalation and persistence follow through rootkit concealment, bash configuration changes, and systemd service manipulation that keep the malware active across restarts.
- Impact is cryptomining on infected Linux endpoints, including CPU and GPU abuse and outbound connections to mining pools for more than 18 cryptocurrencies.
Breaches seen in the wild
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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
Linux cryptojacking is now a trust-path problem, not just a malware problem. Koske does not depend on a single obvious binary drop. It abuses the ordinary pathways that admins and developers already trust, including uploads, shell startup files, and service configuration. That means the control surface is broader than endpoint signatures and has to include runtime telemetry, configuration monitoring, and execution-path governance.
Polyglot delivery creates a detection blind spot that traditional file controls are poorly positioned to close. When content looks like an image but carries executable material, the security model built around extension checks and routine media handling breaks down. This is especially important in environments where development tools and content workflows are exposed to interactive users. Practitioners need to treat file trust as contextual, not static.
Persistence on Linux often hides in administrative defaults, which makes identity-adjacent controls part of the defence story. Startup files and systemd services are not only system artefacts, they are privilege-bearing execution paths. When those paths are writable or weakly monitored, malware can survive reboots without needing a conventional autorun mechanism. The governance lesson is that endpoint resilience depends on who can alter launch paths, not just on how malware arrives.
Named concept: trust-path cryptojacking. This pattern describes malware that survives by blending into the mechanisms used to move, start, and relaunch legitimate workloads. It is a useful concept because it shifts attention from the payload alone to the trusted paths that let the payload persist and hide. Practitioners should use it to frame detection strategy around execution provenance, not only malicious indicators.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Trust-path cryptojacking: this is the pattern defenders should watch for when malware enters through benign-looking content and then survives by abusing launch and persistence surfaces. The control problem shifts from simple malware blocking to proving that files, processes, and services are behaving inside expected boundaries.
AI-shaped malware is likely to keep borrowing from legitimate Linux administration patterns because those patterns are already trusted by defenders and users alike. For practitioners, that means runtime telemetry, configuration drift control, and launch-path governance have to be treated as one detection problem rather than three separate ones.
AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That matters here because malware tradecraft is increasingly benefiting from the same sprawling operational surface that creates secret leakage.
For practitioners
- Monitor content-to-execution handoffs Alert when web-based development environments, upload directories, or collaboration tools hand off media files to shell interpreters, compilers, or downloader utilities.
- Track runtime concealment behaviours Correlate process creation, library loading, hidden file creation, and unusual network connections so in-memory malware cannot hide behind a clean file system view.
- Harden Linux persistence surfaces Review bash startup files, systemd units, and LD_PRELOAD-related paths for unauthorised changes, then alert on new persistence artifacts such as modified .bashrc variants.
- Inspect downloads and staging directories Continuously monitor user download paths and other staging areas for archive, image, or script files that appear harmless but are later executed or expanded locally.
- Use hash-based matching for known samples Compare FIM and threat-hunting outputs against known malware hashes so repeated samples can be confirmed quickly even when the initial delivery format changes.
Key takeaways
- Koske shows how Linux cryptojacking can hide behind ordinary trust paths such as uploads, shell startup files, and service launch mechanisms.
- The article’s detection lesson is that runtime behaviour and configuration drift matter more than file signatures when malware executes in memory and conceals itself.
- Teams that do not monitor execution provenance, persistence surfaces, and hidden-process indicators will miss the control failures that let cryptomining malware stay resident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0003; TA0011 — Credential Access; Persistence; Command and Control | Koske uses concealment, persistence, and outbound control channels to remain active on Linux hosts. |
| Recommendation — Map Koske-like behaviours to TA0006, TA0003, and TA0011 and hunt for process, startup, and network anomalies. | ||
| CIS Controls v8 | CIS-5 — Account Management | Persistence depends on changing launch paths and system accounts, which is an account governance issue. |
| Recommendation — Review account and service permissions that allow shell and service persistence changes on Linux hosts. | ||
| NIST CSF 2.0 | DE.CM-01 — Continuous Monitoring | This article depends on continuous endpoint monitoring to detect file, process, and configuration abuse. |
| Recommendation — Use DE.CM-01 to maintain continuous monitoring of endpoint behaviour, not just periodic file scanning. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | The malware survives by altering trusted configuration surfaces such as bash startup files and services. |
| Recommendation — Apply CM-6 to lock down launch-time configuration and alert on unauthorised changes to persistence files. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The delivery path includes an improperly configured web-based development environment. |
| Recommendation — Treat exposed development and upload surfaces as misconfiguration risks and remove unnecessary execution capability. | ||
Key terms
- Polyglot File: A polyglot file is crafted so that it is valid under more than one file interpretation. Attackers use this property to hide executable content inside a format that appears benign, which weakens extension-based trust and complicates static inspection and sandboxing.
- In-memory Execution: Execution that happens inside RAM without writing a durable file to disk. Security teams care about it because it reduces common forensic artefacts and can bypass controls that rely on file visibility, stable hashes, or persistent process indicators.
- 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.
- Rootkit Concealment: Rootkit concealment is the use of kernel, library, or process-hiding techniques to mask malicious activity from standard tools. In this campaign, the objective is to keep mining processes, helper files, and persistence mechanisms invisible long enough to maintain control and avoid containment.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building stronger control models. It helps IAM, security, and platform teams translate identity governance into operational controls that hold up under real-world abuse.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org