Koske malware shows how cryptojacking hides inside Linux trust paths

At a glance

What this is: Koske is a Linux cryptomining malware campaign that uses polyglot JPEG lures, in-memory execution, persistence changes, and concealment techniques to mine multiple cryptocurrencies.

Why it matters: It matters to IAM and security teams because compromised access paths, hidden execution, and persistence on Linux workloads can turn legitimate identities and endpoints into durable mining infrastructure before controls notice.

By the numbers:

• Koske is designed to mine more than 18 cryptocurrencies using both CPU and GPU resources on infected Linux endpoints.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.

👉 Read Wazuh's analysis of Koske malware detection on Linux endpoints

Context

Koske malware is a cryptojacking and concealment problem first, and a detection problem second. The campaign shows how malicious code can hide inside apparently benign files, execute in memory, modify startup paths, and keep mining activity alive on Linux endpoints long enough to matter to identity and access governance.

For IAM and NHI practitioners, the relevant lesson is not that Linux is uniquely vulnerable, but that privileged execution paths, service accounts, and workload identities can be abused once an attacker reaches a development or runtime environment. That makes telemetry, identity boundaries, and endpoint controls part of the same governance picture, especially where web-based development tools and shared Linux workloads overlap.

The starting position here is typical of modern Linux cryptomining campaigns: low-friction entry, stealthy execution, and persistence built to survive routine monitoring.

Key questions

Q: What breaks when Linux cryptominers hide inside seemingly harmless files?

A: Traditional file reputation and extension-based filtering break down because the payload is no longer where the user thinks it is. Polyglot files can look legitimate while carrying executable code, so defenders need content-aware inspection, memory-execution monitoring, and integrity checks on the paths that unpack or run those files.

Q: Why do cryptominers on Linux often survive standard endpoint monitoring?

A: They rely on startup file edits, systemd services, hidden helper files, and rootkit-like concealment to keep running after reboot or login. Those techniques turn persistence into a configuration problem, which means endpoint control, service governance, and runtime integrity all have to be monitored together.

Q: How do security teams know whether Linux workload execution is actually under control?

A: Look for evidence that code only runs from approved paths, that service and shell startup files are stable, and that suspicious egress is tied to known miner infrastructure. If execution provenance is unclear, then governance is weak even if the host appears healthy.

Q: Who is accountable when a compromised Linux environment becomes a mining platform?

A: Accountability usually sits with the team that owns the development or workload environment, but the governance failure is shared across platform, security, and identity owners. If access, execution, and persistence controls were not explicitly assigned and reviewed, the organisation as a whole owns the risk.

Technical breakdown

Polyglot file delivery hides malware inside ordinary images

A polyglot file is crafted so it functions as more than one file type at once. In this campaign, the lure is a panda JPEG that also carries appended shellcode or C code, which makes static inspection harder because the image still looks valid. Once a user or process extracts and executes the hidden payload, the malware can shift into memory-only execution or compile helper components. That approach reduces obvious disk artefacts and helps the payload survive basic file-based detections.

Practical implication: inspect file-type mismatches and image uploads with content-aware detection, not extension-based trust.

Persistence and rootkit techniques keep cryptominers resident

Koske modifies shell startup files such as .bashrc and uses systemd services to relaunch after login or reboot. It also uses rootkit-style hiding, including LD_PRELOAD manipulation and hidden PID files, to mask processes and artefacts from routine checks. This is a common cryptomining pattern: the attacker does not need long interactive control if the workload continues running invisibly in the background. The operational risk is sustained resource theft and delayed incident discovery.

Practical implication: monitor startup scripts, service definitions, and preload paths as part of endpoint and workload integrity checks.

Detection must correlate process, network, and file telemetry

The blog’s Wazuh approach shows why one telemetry stream is not enough. Process creation, network connections to mining pools, file writes for miner binaries, and configuration changes all contribute pieces of the attack chain. SysmonForLinux and rootcheck-style scanning add context, while file hash matching helps identify known payloads. In practice, defenders need rules that connect execution, persistence, and egress because cryptomining often looks like normal system activity until several signals are correlated.

Practical implication: correlate endpoint process, file integrity, and outbound connection data before tuning alerts to a single malware family.

Threat narrative

Attacker objective: The objective is to covertly turn compromised Linux systems into long-running cryptocurrency mining assets while avoiding detection and preserving persistence.

1. Entry occurs through an improperly configured JupyterLab environment, with the lure delivered as a polyglot JPEG that hides malicious shellcode inside an apparently harmless image.
2. Escalation and persistence follow when the payload executes in memory, fetches miner components, alters bash startup files, and uses rootkit-style techniques to conceal processes and files.
3. Impact is sustained cryptojacking on Linux endpoints, with CPU and GPU resources diverted to mining operations and defenders seeing reduced visibility into the attacker’s activity.

NHI Mgmt Group analysis

Polyglot delivery is a governance failure, not just a malware trick. When a JPEG can carry executable payloads, file-type trust collapses and conventional user education is irrelevant. The real issue is that defenders still treat content format as a proxy for safety, even though execution depends on parser behaviour, not file extension. Practitioners should treat suspicious polyglots as an integrity and provenance problem across the endpoint pipeline.

Linux cryptomining increasingly depends on the abuse of legitimate execution paths. Bash startup files, systemd services, and memory-resident execution give attackers persistence without needing exotic exploits. That means workload identity, service ownership, and configuration control matter as much as malware signatures. In identity terms, the compromise is often an over-trusted runtime path rather than a stolen password.

Detection needs identity-adjacent telemetry because privileged runtime is the real target. The article shows why process creation, egress, and file changes must be evaluated together. A miner that launches successfully from a trusted development environment is not just an endpoint event, it is a governance event about who or what is allowed to execute code on that host. Practitioners should align Linux workload controls with least privilege and execution provenance.

AI-shaped malware changes the defender’s assumptions about pace and adaptation. Even when attribution is uncertain, the code style suggests automated generation and rapid variant creation. That raises the bar for static rules and makes behavioural correlation the sustainable control pattern. Security teams should expect more samples that mutate faster than signatures and plan for control logic that survives variant churn.

Named concept: execution-path trust collapse. Koske illustrates how an environment can remain formally authenticated while the trusted execution path has already been subverted through file tricks, startup persistence, and hidden runtime activity. The practical implication is to govern execution provenance, not just login events and file reputation.

What this signals

Execution-path trust collapse: Linux defenders need to treat startup scripts, service files, and in-memory execution as governance boundaries, not just technical artefacts. Once an attacker can place code into a trusted runtime path, ordinary malware hunting becomes too late in the chain. That is why execution provenance and host integrity now sit alongside endpoint telemetry in modern control design, especially when workloads are exposed to development tooling and shared automation.

The broader signal is that cryptojacking continues to blend into business-as-usual activity unless teams correlate process, file, and network evidence. Security programmes that only look for known hashes will miss the persistence layer, while teams that only watch egress will miss the delivery path. The control answer is integrated detection, not isolated point products.

For identity and access teams, the lesson is to classify Linux service accounts and workload execution as governed identities with explicit ownership. That means using least privilege, restricting interactive paths, and reviewing who can change startup behaviour or deploy web-based development services. The issue is not just malware presence, but the trust granted to execution paths that should have been tightly bounded.

For practitioners

• Harden development environments used for Linux payload delivery Review JupyterLab and similar web-based development platforms for exposure, weak access controls, and unnecessary internet reachability. Treat notebook and code-execution services as privileged entry points, because they can become staging areas for payload delivery and in-memory execution.
• Monitor persistence locations that attackers actually use Add detections for .bashrc changes, systemd service creation, LD_PRELOAD manipulation, and hidden files under shared memory locations such as /dev/shm/.hiddenpid. These paths are more operationally useful than generic malware indicators because they catch the mechanisms used to keep miner code resident.
• Correlate endpoint execution with outbound mining traffic Create detection logic that links process creation, miner binary drops, and TCP connections to known mining pools. A single suspicious process is ambiguous, but a process plus configuration change plus outbound pool traffic gives a much stronger case for containment.
• Use integrity checks on files that should never contain shellcode Inspect image uploads, archives, and downloaded artefacts for mismatched file signatures and appended executable content. Polyglot files defeat assumptions about trusted media types, so content-aware validation is necessary before files reach execution-capable paths.

Key takeaways

• Koske shows that cryptomining malware now relies on file deception, hidden execution, and persistence paths that bypass naive trust assumptions.
• The combination of polyglot delivery, rootkit concealment, and startup-file abuse makes Linux endpoints a durable mining substrate unless teams correlate multiple telemetry sources.
• Defenders should govern execution provenance, persistence locations, and outbound mining traffic as one control problem rather than three separate alerts.

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.
• 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.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.
• Systemd Persistence: Systemd persistence is the use of Linux service units to relaunch malicious code automatically after a reboot or service restart. It matters because it converts a one-time compromise into recurring execution, making removal harder unless service configuration and ownership are reviewed.

What's in the full article

Wazuh's full blog post covers the operational detection detail this post intentionally leaves for the source:

• Step-by-step Wazuh decoder and rule configuration for SysmonForLinux telemetry on Ubuntu endpoints
• Custom rootcheck signatures for Koske artefacts such as hidden PID files, preload manipulation, and modified bash profiles
• CDB list setup for known Koske SHA256 hashes and the alert rule that matches new or modified files
• Dashboard workflow for filtering threat hunting events and validating the generated alerts

👉 The full Wazuh blog post shows the decoder logic, rule IDs, and dashboard workflow used to catch Koske activity.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It gives practitioners a structured way to connect privileged execution paths to broader access governance.