Up to a quarter of all cloud users are at risk of having their computing resources stolen and used to illicitly mine for cryptocurrency, after crims cooked up a campaign that targets publicly accessible DevOps tools.

Wiz Threat Research spotted the campaign and attributed it to an attacker it named JINX–0132, which it says exploits misconfigurations and vulnerabilities in multiple applications to deploy mining software.

JINX–0132 targets a “wide range” of DevOps tools, but Wiz thinks it prefers HashiCorp’s Nomad and Consul tools, plus Docker API and Gitea.

According to threat researchers Gili Tikochinski, Danielle Aminov and Merav Bar, Wiz data indicates that 25 percent of all cloud environments are running at least one of these technologies, and more than 20 percent run HashiCorp Consul.

We’ve asked the Wiz kids how many instances of those applications JINX–0132 hit and will update this story when we hear back from the soon-to-be-Google-owned security shop.

“Of those environments using these DevOps tools, five percent expose them directly to the Internet, and among those exposed deployments, 30 percent are misconfigured,” the team wrote.

Here’s a look at the four under–fire tools, and the flaws in each that Wiz says JINX–0132 is looking to abuse.

HashiCorp Nomad

Nomad is a scheduler and orchestrator used to deploy containers and applications across multiple platforms. According to HashiCorp’s documentation, Nomad is not secure by default.

For example, default settings in the software’s job queue feature, which schedules and manages jobs, allow any user with access to the Nomad server API to create and run such jobs.

HashiCorp suggests users take several steps to address that.

Therein lies the problem, according to Wiz, because JINX–0132 found a publicly exposed Nomad server – Shodan scans can find 405 of them – running out–of–the–box settings without security features enabled.

JINX–0132 used that insecure server to download and run XMRig miner software.

To ensure this doesn’t happen to you, turn on Nomad features documented in HashiCorp’s Security Model section and make sure access control lists deny unauthorized access to the Jobs feature.

HashiCorp Consul

The second HashiCorp tool JINX–0132 abused in this campaign is Consul, a networking platform that manages network connectivity between services and across on–premises and multi–cloud environments.

Fresh Consul installations do not populate access control lists or enable other security features by default.

HashiCorp has warned for years that attackers can use such configurations to achieve remote code execution. And this is what JINX–0132 did, abusing this feature to add malicious checks that execute miners.

“Much like their procedure for hijacking Nomad, JINX–0132 adds multiple services with seemingly random names whose real purpose was to download and run the XMRig payload,” the Wiz trio wrote.

Keep JINX–0132 off your cloud computing resources by implementing security documented here, such as disabling script checks by setting the “enable–script–checks” flag to “false,” and restrict the HTTP API to only bind only to “localhost” wherever possible.

Docker Engine API

Wiz has previously documented several instances of misconfigurations that expose Docker APIs to the public internet. Those errors give attackers the same access as the root–owned Docker command–line–interface and allow remote code execution.

As Tikochinski, Aminov, and Bar wrote:

Attackers can also use this illicit access to control Docker from within a container, then pivoting to Kubernetes or other hosts, we’re told.

“Simply not exposing the API to the Internet is the most effective mitigation,” the Wiz team said.

Gitea

Wiz’s researchers are not sure how JINX–0132 gains access to Gitea, but the team details several possibilities in its research.

Two of them – exploiting an insecure default vulnerability (CVE–2020–14144) in older versions and manually changing the default secure settings in Version 1.13 to allow users to create custom Git Hooks – require authentication to be exploited. Therefore, exploiting both CVEs for RCE isn’t realistic without first stealing credentials.

Gitea’s developers fixed another bug in version 1.4.1. That flaw allowed RCE in the short–lived 1.4.0 release. But, again, as long as you’re running an up–to–date version, you’re in the clear.

This leaves one risk: If the installation page remains unlocked, then anyone with access to the Gitea instance can re–run the installation wizard, overwrite the configuration, reset admin credentials, and then use this access to run mining software.

The moral of this story is: Keep your Gitea software up to date, do not enable Git Hooks and do not leave the installer unlocked unless necessary. ®