Azure Batch Misused for Crypto Mining

What it is

An incident walkthrough from DFIR.ch (with logs supplied by "the cybersecurity doge") of an attacker abusing Azure Batch — a legitimate HPC/parallel-compute scheduling service — to run a crypto-miner from a compromised Azure admin account. The forensic artifacts recovered: resource group Bch, Batch account websecv1, and a pool WebApp running Ubuntu 20.04 LTS on STANDARD_F8 VMs (8 vCPU compute-optimized nodes — chosen for mining throughput).

How it works

The abuse turns on Azure Batch's StartTask: a command configured on a pool that runs automatically on every node before any job task, intended for setup/initialization. The attacker plants the miner as the StartTask, so once nodes come online they self-deploy the miner with no further interaction — an "autonomous" mining fleet.

The gating detail is quota. New Batch accounts in some regions/subscription types default to a core quota of 0, which blocks any pool from spinning up. So the attacker had to file Microsoft support tickets requesting a quota increase before the pools would launch. This makes the support request part of the attack chain, not incidental.

flowchart LR
  A[Compromised Azure admin] --> B[Create resource group + Batch accounts]
  B --> C[Configure pool with miner as StartTask]
  C --> D{Core quota = 0?}
  D -->|yes, blocked| E[Open MS support ticket<br/>request quota increase]
  E --> F[Quota raised]
  D -->|no| F
  F --> G[Pool nodes spin up,<br/>StartTask auto-runs miner]

Preconditions / Affected

• A compromised Azure account with rights to create resource groups and Batch accounts (the post's actor had admin).
• A subscription where Batch can be provisioned and quota raised. The quota-0 default is a friction point, not a barrier — it is lifted via a support ticket.

What to do

The post provides no detection queries or mitigations of its own, but the recovered activity-log operations point at concrete hunting signals:

• Alert on Microsoft.Batch/batchAccounts create operations, especially outside known engineering use.
• Correlate Batch account/pool creation with Batch core quota-increase support tickets — an unusual pairing for a compromised tenant.
• Inspect StartTask definitions on any pool; a miner or unexpected setup command here is the execution vector.
• Watch for compute-optimized VM SKUs (e.g. STANDARD_F8) in Batch pools.

Caveats

The investigators never had access to the affected tenant; their analysis rests solely on activity logs forwarded by a third party, so the account is reconstructed "as good as it gets." Much of the post is a benign walkthrough of standard Azure Batch setup, used to explain the attacker's steps rather than to document new artifacts.