A sophisticated cryptojacking operation named JINX-0132 has zeroed in on core orchestration and repository tools, compromising misconfigurations made during the DevOps cycle and turning the tools into silent cryptocurrency mines.
JINX-0132, discovered in June by researchers at Wiz, is particularly dangerous because the universe of potential targets is so vast. Roughly 25 percent of cloud-based deployments run at least one of the targeted tools—HashiCorp Nomad, Gitea, HashiCorp Consul, and Docker’s API. Of those deployments, five percent expose these services directly to the internet, and among exposed instances, nearly 30 percent exhibit insecure defaults or missing access controls.
Translated into raw numbers, tens of thousands of servers are live targets. Given the modest cost of GPU or CPU time in the cloud, JINX-0132’s operators can monetize compromised infrastructure rapidly. Even if each individual server contributes a few dollars worth of Monero daily, the collective haul across hundreds or thousands of compromised nodes is significant.
Traditionally, cryptojacking has targeted end-user devices, including unsuspecting desktops and laptops. But JINX-0132’s shift toward DevOps infrastructure reflects a deeper understanding of enterprise workflows. By compromising Nomad or Consul instances, attackers gain high-volume access to CPU or GPU resources—often across multiple nodes—amplifying their mining yield without immediately raising red flags.
What makes this campaign especially insidious is the use of legitimate mining software XMRig. Instead of deploying custom binaries that trigger antivirus alerts, attackers simply download officially released XMRig builds from GitHub. Because these tools are digitally signed and widely trusted, security scanners rarely flag them as malicious. In essence, JINX-0132 blends illicit mining traffic into the background hum of everyday DevOps operations.
HashiCorp Consul, used for service discovery, configuration, and health checking, has also fallen prey. In default configurations, anyone with network access to Consul’s HTTP API can register new services and health checks. JINX-0132 abuses this mechanism by registering malicious health checks that execute bash commands on cluster nodes. Those scripts then fetch XMRig and launch mining processes.
Since health checks are a normal part of the Consul’s operation, the malicious activity masquerades as routine monitoring traffic.Without proper ACLs or TLS enforcement, these rogue checks blend into legitimate service-monitoring traffic, leaving teams blind until CPU bills or latency metrics soar.
Remediating Consul’s exposure requires disabling or tightly restricting script-based health checks, binding the HTTP API to local hosts or private networks only, and enforcing access controls (ACLs) to ensure only authorized services can register or modify checks.
Even more traditional targets—Gitea and Docker—haven’t escaped JINX-0132’s reach. Unpatched Gitea instances (notably those vulnerable to CVE-2020-14144) allow unauthenticated users to plant malicious git hooks. Each git push then triggers the execution of scripts that download and launch XMRig.
In essence, a simple code commit becomes a trigger for clandestine mining. Docker’s Engine API, if exposed without authentication, enables direct container creation. JINX-0132’s operators create lightweight miner containers that run silently in the background. Because container logs and orchestration events often flood monitoring dashboards, these unauthorized containers can slip under the radar for weeks, all while consuming CPU cycles and inflating infrastructure costs.