- Newest
- Most votes
- Most comments
I suggest you start by stopping (powering off) the compromised server to stop any damage that hasn't already been done from going any further.
Next, create a new security group under the EC2 console's "security groups" section. In the inbound rules, delete all the rules that may be automatically added, and only add one rule to allow yourself or your technical staff to access it from your/their IP address over the protocol that you normally use to access the server, such as TCP 22 (SSH) or TCP 3389 (Remote Desktop). Make sure to allow only a single IP address, such as 192.0.0.2/32 (the /32 at the end being significant), so that access will only be permitted from your IP address. If multiple people need access from different locations, add an equivalent rule for each user's IP address. In particular, do not allow access from 0.0.0.0/0, which represents the entire global internet.
Launch a new server from a standard AWS-provided AMI (Amazon Machine Image) with no security groups attached except the new one you just created. Launching the server from a clean image and only allowing network access from trusted source IPs will help to avoid getting the new server infected.
Ensure that the old server is in the "stopped" state. Then detach the EBS volume or multiple volumes from it in the "volumes" section of the EC2 console. The volumes will change to the "available" state. Attach them to the new, clean server, also in the "volumes" view of the console.
This way, the new server will be running a safe operating system, launched from a clean image, but the old server's compromised disks and all their remaining data contents will be accessible as secondary disks on the new server. Depending on the operating system, they might be discovered as new disks automatically, or you may manually need to add them to your "fstab" file to mount them.
Once you see the old disks, be extra careful not to start any software, scripts, or applications from the old disks. If you do, the new server may be compromised and any destruction that may have been happening will get the opportunity to continue from where it left off. Only copy the files to where you want them, and make sure to run them through an up-to-date anti-malware or other endpoint protection software before using any of the files.
After shutting down the old server and before detaching the EBS volumes, you can also create an AMI of the old server. This will incur some storage costs for the time you retain the AMI and its associated EBS snapshots, but it will ensure that if something happens during the data extraction, you'll be able to roll back to the point in time when you made the AMI, by creating new EBS volumes from the snapshots and trying the same process again.
Relevant content
- asked a year ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated 2 months ago
Thank you Leo for the prompt answer. The thing is that I don't have to tech savviness to execute what you just mentioned without having a detailed guide. If you can be kind to help us execute it or point us to a resource that shows the steps in detail, it will be much appreciated.
I've already stopped the server. Our busines site at https://9figuremedia.com has been offline for the past 3 days now. We've tried getting some IT guy to do it, but he's lost. Please point us in the right direction and we will be grateful. We can pay for your services since we don't know how to get a hold of AWS support in this regard even though we tried to subscribe to the $100/mo support offer.
I'm working full-time, so I'm sorry but I won't be able to allocate many hours to recovering the server. However, following the instructions I gave, a general mid-level engineer working with EC2 should be able to do this. I suggest you check afterwards that the remains of the old server and any AMIs created get deleted (after all the data is safe at the new location), because this is often overlooked by engineers whose priority is to deal with an incident, and leftover resources will continue to be charged until they're deleted.