Cryptomining on a Production EC2 Instance
A media streaming company runs a customer-facing API on 40 EC2 instances behind an Application Load Balancer. The API has a 99.99% uptime SLA. At 02:00 UTC, Falcon Cloud Security alerts on a process named xmrig on one production instance in us-east-1. The process is making outbound connections to a known mining pool. The instance is also serving live traffic. The security team has Falcon Real Time Response (RTR) enabled and network containment available. The on-call engineer must decide whether to isolate the instance immediately, which would remove it from the load balancer and potentially reduce capacity, or to collect forensic evidence first. The company has a 15-minute incident response SLA for critical alerts. They also have an auto-scaling group that can replace the instance. The CISO wants to minimize customer impact and preserve evidence for a potential law enforcement report.
1. Outline the immediate response steps, including the order of containment and evidence collection, and justify your decisions.
Read the worked answer
Acknowledge and verify the alert within the 15-minute SLA. Confirm the process hash, parent process, and outbound connections via Falcon telemetry.
Capture volatile evidence quickly with RTR: running processes, network connections, logged-in users, and a hash of the xmrig binary. If supported, collect a memory dump before terminating the process. This is time-sensitive because the miner may be killed or the instance replaced by auto-scaling.
Contain the host using Falcon network containment to block outbound mining-pool traffic and any lateral movement. Containment does not necessarily kill the process, so the miner may continue consuming CPU, but it stops the most damaging behavior.
Remove the instance from service by deregistering it from the load balancer and terminating it. Because an auto-scaling group exists, capacity is restored automatically. Snapshot the EBS volume before termination if not already done.
Preserve artifacts for law enforcement: snapshot, memory dump, RTR transcript, and CloudTrail/VPC Flow Logs. Chain of custody matters more than speed after containment.
The order balances the SLA and forensic integrity: collect volatile evidence before termination, then contain and replace.
2. How would you use Falcon RTR and network containment to balance SLA and forensic integrity?
Read the worked answer
Use RTR first for read-only commands to capture process lists, network sockets, and file hashes. This is fast and does not alter the host. If a memory capture capability is available, use it before killing the process. Then apply network containment to cut off the mining pool and command-and-control traffic while keeping the Falcon cloud channel open for further RTR actions.
After evidence capture, use RTR to kill the xmrig process if it is still running, then deregister and terminate the instance. The ALB health check will remove the instance from rotation as soon as it is deregistered. Because the auto-scaling group can launch a replacement, the capacity impact should be brief and within the 99.99% SLA if the group is configured correctly.
Document each RTR command and timestamp. This gives the CISO a defensible record that containment was deliberate and evidence was preserved before destruction. If the instance cannot be terminated immediately due to change control, keep it contained and proceed with the standard emergency change process.
3. What post-incident improvements would you recommend to prevent cryptomining recurrence?
Read the worked answer
Investigate the initial access vector: exposed instance role, vulnerable application, leaked credentials, or unpatched service. Rotate any credentials associated with the instance and review CloudTrail for unauthorized API calls.
Harden the workload: apply least-privilege instance profiles, restrict outbound traffic to required destinations, and use VPC endpoints where possible. Consider moving the API to containers or immutable infrastructure with minimal base images. Enable Falcon prevention policies to block known mining binaries and suspicious process behavior, not just alert.
Add detection coverage for mining pools and high CPU anomalies, and integrate alerts with the on-call workflow. Enforce patch management and vulnerability scanning on AMIs. Finally, run a tabletop exercise for this scenario so the team can practice the RTR-first, contain-second sequence within the 15-minute SLA.