Stop the bleeding by isolating the affected network segment immediately. Do not power off the instance, as this destroys volatile memory evidence. Capture network logs, identify the entry point, and rotate all credentials. Rebuild the workload from trusted infrastructure-as-code templates to ensure a clean state.
First hour
You suspect cryptojacking when resource utilization spikes without a corresponding increase in application traffic. The immediate goal is containment, not investigation. You must stop the attacker from moving laterally to other systems before you analyze the root cause.
- Isolate the affected instance by modifying security groups or network access control lists to deny all ingress and egress traffic.
- Capture a memory dump if your platform supports live forensic acquisition without terminating the process.
- Snapshot the disk volume for offline analysis.
- Rotate the credentials of any user or service account that had access to the compromised instance.
- Check for new user accounts or SSH keys added to the system.
Isolating the instance via network rules is safer than killing processes. Killing processes can trigger anti-forensics scripts that delete logs or evidence. Network isolation keeps the attacker stuck while you gather data. You are buying time to understand the scope without losing the "why" and "how" of the breach.
First day
Once the immediate threat is contained, you shift to evidence collection and scope determination. You need to know how the attacker got in and what else they touched. This phase requires patience and methodical logging analysis.
Start by reviewing the cloud provider’s audit logs. Look for unauthorized API calls, particularly those creating new instances, modifying security groups, or accessing storage buckets. Attackers often use the initial foothold to expand their access. They may create new administrators or exfiltrate data before launching the cryptocurrency miner.
| Action | Purpose |
|---|---|
| Review audit logs | Identify unauthorized API calls and privilege escalation attempts. |
| Analyze network flows | Detect command-and-control traffic and data exfiltration paths. |
| Check container images | Verify if the base image was tampered with or if a vulnerable layer was exploited. |
You must also check for persistence mechanisms. Attackers often install cron jobs, systemd services, or modified startup scripts to ensure the miner restarts after a reboot. If you are using containers, check for modified entrypoint scripts or injected sidecar containers. The presence of a specific mining binary is less important than the mechanism that launched it.
First week
Recovery involves rebuilding the environment from trusted sources. You do not clean a compromised system; you replace it. This principle applies to servers, containers, and database instances. Cleaning is error-prone and leaves hidden backdoors.
Use your infrastructure-as-code scanning practices to validate the templates used for the rebuild. Ensure that the configuration does not contain the same misconfigurations that allowed the initial breach. If you lack a proper cloud asset inventory, you may miss related compromised assets during the rebuild.
Rebuild the application in a clean environment. Restore data from backups taken before the incident. Verify the integrity of the restored data. Do not restore code or binaries from the compromised environment. Compile or pull them from your trusted artifact repository.
Who to tell
Notification is a legal and operational requirement. You must inform internal stakeholders, including leadership, legal, and human resources. External notification depends on the data involved. If customer data was accessed, you may have regulatory obligations.
Contact your cloud provider’s support team. They can provide additional logs and assist with account-level security reviews. If you have cyber insurance, notify your insurer immediately. Delaying notification can void coverage.
You should also consider notifying your customers if there is a risk of harm. Transparency builds trust, even when the news is bad. Provide clear information on what happened, what data was involved, and what steps you are taking to prevent recurrence.
How to stop a repeat
Prevention requires a shift from reactive to proactive security. You must reduce the attack surface and assume breach. This means limiting permissions and monitoring for anomalies.
Implement microsegmentation to limit lateral movement. Even if an attacker compromises one instance, they cannot easily access others. Use least-privilege access for all service accounts. Regularly review and revoke unnecessary permissions.
Adopt confidential computing to protect data in use. This technology encrypts data even while it is being processed in memory. It prevents attackers from reading sensitive data even if they compromise the underlying infrastructure.
Review your insecure container images regularly. Use automated scanning to detect known vulnerabilities. Patch base images promptly. Do not run containers as root. Use read-only filesystems where possible.
See also: DevSecOps vs CI/CD: Why Security Needs Its Own Pipeline · How to Set Up Single Sign On: Protocol Choices and Risk Controls
Continuous improvement
Security is not a one-time event. It is a continuous process. You must regularly test your defenses and update your response plans. Conduct tabletop exercises to simulate incidents. This helps your team practice under pressure.
Monitor for anomalies in resource usage. Sudden spikes in CPU or network traffic can indicate cryptojacking. Set up alerts for unusual API calls or privilege changes. Automate response actions where possible.
Integrate security into your development lifecycle. Shift left by scanning code and configurations early. Educate your team on secure coding practices. Make security a shared responsibility, not just a compliance checkbox.
Key takeaways
- Isolate the network segment before terminating the instance to preserve forensic evidence and stop lateral movement.
- Assume all credentials are compromised; rotate secrets and API keys before restoring services.
- Rebuild workloads from trusted infrastructure-as-code templates rather than attempting to clean the compromised environment.
Isolate the network before terminating the instance to preserve forensic evidence and stop lateral movement. Rebuild the environment from trusted infrastructure-as-code templates rather than attempting to clean the compromised system.
Frequently asked questions
How do I know if my cloud instance is compromised by cryptojacking?
Look for sustained high CPU usage without corresponding application traffic, unusual network connections to mining pools, or new processes running with elevated privileges.
Should I delete the compromised instance immediately?
No. Isolate it first to preserve evidence. Terminating it immediately destroys volatile memory data needed for forensic analysis and root cause determination.
Can I clean a compromised server instead of rebuilding it?
Cleaning is unreliable. Attackers often leave hidden backdoors or persistence mechanisms. Rebuilding
How this guide was produced: written by the Malware Chronicle editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
