Cryptojacking is unauthorized use of computing resources to mine cryptocurrency. The first visible symptom may be a busy CPU, a noisy fan, a cloud bill, or a slow service. The more consequential question is how the attacker gained execution and what else that access allowed.
This article expands the Cryptojacking branch of the Cyber Threat Tree. The objective is to restore control of the host or workload, not merely to make the performance graph look normal again.
Recognize cryptojacking with several signals
MITRE ATT&CK’s Compute Hijacking technique covers abuse of endpoints, servers, cloud systems, and containers for resource-intensive work including mining. Its broader Resource Hijacking guidance describes detection using resource consumption, suspicious processes, persistence, and external connections.
Correlate process ancestry, executable path, account privileges, start time, network destinations, and recent changes. High CPU alone is not proof: a build, an index, a batch job, or an approved research workload can look similarly expensive.
Conversely, a miner may be throttled or intermittently active. Keep suspicious downloads, unexpected scheduled execution, and unexplained outbound activity in scope even when the machine is currently quiet.
Contain while preserving a useful timeline
Coordinate with the service owner and incident team. Choose containment that limits further activity while considering business impact and evidence needs. Network isolation, workload suspension, and access revocation have different effects on live telemetry.
When feasible, capture volatile information before destructive cleanup: running processes, active connections, logged-in sessions, relevant execution history, and timestamps. Preserve suspicious files through the approved evidence process. Do not run an unfamiliar cleanup script on a trusted administrator workstation to see what it does.
Record the earliest supported observation and the limits of the retained evidence. The file creation time of the miner is not necessarily the time of initial access, and a missing log is not evidence that an action did not occur.
Find the execution path and persistence
Review exposed services, administrative access, stolen credentials, deployment tooling, and recently installed software according to the observed environment. Ask what mechanism could reproduce the malicious process after a reboot, a container restart, or a fresh deployment.
Check the platform’s relevant persistence locations: service definitions, scheduled tasks, startup items, launch agents, orchestration configuration, and altered images. A malicious container removed from a node may return if its deployment source remains unchanged.
Use evidence to decide scope. A mining binary does not prove that every accessible system was compromised, but it also does not justify declaring the intrusion limited to mining.
Assess the secrets and trust relationships
Identify the account under which the attacker ran and the credentials available in that context. Include environment variables, configuration files, mounted secrets, cloud identity, repository access, deployment keys, and signing material where relevant.
Prioritize revocation and rotation by access and evidence, from a trusted administrative system. Track downstream services that need the replacements. Rotating a secret on the same untrusted host can expose the replacement immediately.
For build and deployment infrastructure, assess the provenance of outputs produced during the exposure window. Investigate what the attacker could modify and what evidence remains; do not claim artifact tampering without support.
Restore from a trusted basis
When the extent of changes cannot be established, a clean rebuild from verified sources may provide a stronger recovery basis than removing known files. Fix the initial access path, replace affected deployment sources, restore only reviewed data, and verify administrative access before reconnecting the service.
Monitor process behavior, resource use, network activity, and re-created persistence after restoration. Agree a review period with the incident owner rather than treating one quiet restart as closure.
- Contain the workload and preserve evidence.
- Explain the entry path or record the unresolved uncertainty.
- Remove persistence and repair the deployment source.
- Review exposed credentials and trust relationships.
- Verify the restored service and its continued behavior.
Cryptojacking recovery is a trust decision backed by an investigation. Lower CPU usage is a useful symptom of progress; it is not the full result.
