Why does a cryptomining implant keep its host healthy and leave the data alone?

## The value model Most malware objectives assume the victim's data is the prize: it is encrypted for a ransom, copied for resale, or destroyed. A mining payload assumes the opposite. It treats the host as a rented machine and sells the only thing that machine produces continuously, which is compute. Cycles are converted into a cryptocurrency at a cost the operator does not pay: the electricity, the cooling, the metered vCPU-hours and the wear are all charged to the owner of the hardware or the owner of the cloud account. The operator's marginal cost is close to zero, which is why the business works at all despite terrible margins per host. It only becomes worthwhile at scale, and at scale the operator cannot babysit individual machines. That single economic fact explains almost every observable behaviour of this class of payload. ## Why the host must survive Revenue accrues per unit of time. A host that is wiped, rebuilt, taken offline by its user, or crashed by a badly written payload stops paying immediately, and the operator has to find another one. So the payload is deliberately non-destructive: - **No encryption and no deletion.** There is nothing to gain and the owner would notice within minutes. - **No obvious theft.** Reading the files is a different objective with a different buyer; a miner has no use for them. - **Resource restraint.** Many implants cap CPU usage, pause when a user is at the keyboard, or run only outside business hours. A laptop whose fans scream all day gets taken to the help desk; a server at 40% extra load may not be questioned for months. - **Housekeeping the operator has no obligation to do.** It is common for a mining crew to patch the very vulnerability they exploited or kill competing miners already on the box. That is not goodwill; it is protecting an income stream from other tenants. Coin choice follows the same logic. CPU-friendly, privacy-oriented coins such as Monero are preferred precisely because ordinary server and container CPUs can contribute usefully without specialised hardware, and because the payouts are harder to trace to a wallet. ## What the victim actually loses On owned hardware the loss is electricity, cooling, degraded lifetime and the capacity your own workloads no longer get, which surfaces as latency, noisy-neighbour effects and evictions rather than as a security symptom. In a metered cloud account the loss is direct and unbounded in a way on-premises mining is not: the account is billed for what runs, and if the environment is elastic, autoscaling will helpfully add capacity to satisfy the extra demand. The victim's own scaling policy becomes the mechanism that grows the adversary's farm and the invoice at the same time. There is also a reputational and contractual layer. Sustained outbound connections from a corporate range to mining infrastructure can put that range on abuse lists, and a cloud provider's acceptable-use terms usually make the account holder answerable for it. ## The part candidates miss The payload is not the finding. The finding is that unauthorised code chose to run on your host, which means an entry path existed and someone reached it. Mining is what you do with an access you could not sell for more, or an access whose new owner has not yet decided what it is worth. Access is a commodity that changes hands: the crew that installed a miner today may sell that foothold tomorrow to someone whose objective is extortion or data theft, and the second buyer has no reason at all to keep the host healthy. So "nothing was taken, nothing was encrypted" describes the payload's intent, not the exposure. Judging the severity by the payload is exactly the mistake this objective invites, because the payload was chosen to be tolerable.