Incident Response in the Cloud (AWS)Part 1- Handling AWS Abuse Notifications

{This blog series is an effort from me to raise awareness about IR and threat detection in the Cloud. In this blog post we will be touching upon the part of Cloud IR where given an AWS Abuse Notice , what should be the remediation steps for a Suspected Compromised Instance or Exposed Access Keys}

Incident Response(IR) is one of the most critical component’s in today’s Cybersecurity. Large Organisations and Enterprises are investing thousands if not millions of dollars to build the Blue team for IR as because a Security Incident is a matter of when and not if. From my experience many organisations conveniently ignore the security of the infrastructure hosted on Public Cloud(such as AWS). And no matter how well architected AWS deployments are, no matter how well automated the implantation is, or how efficient the networking bad security negate it all. If you ever experience an exploit or security event, it could and often does cripple products and businesses.

Put simply, an incident is a fault or failure. In other words, it’s an event which is outside the system tolerances. So, for example, if you’re on a Web platform on one of your EC2 instances are exploited, it’s clear that that’s on intended behaviour. It’s not supposed to be and so that is an incident. Now the reason why incident response is so essential is that instances themselves are never convenient. They can occur during lunchtime at 4 p.m. on a Friday, right when you’re out, leave the office, or 3 a.m. when you’re soundly asleep. Hence one of the most important part of the response process is actually identifying incidents when they occur and also handling the end to end process of incident response starting at protection and prevention, moving through to detecting incidents, handling them and then any post-mortem style activities. Now this identification happens in a number of ways. You might become aware of it yourself, either manually or automatically, because she noticed some odd patterns maybe high network through port or CPU usage, or you might be informed by your customers. Now this is less than ideal customers being the first people to inform you of any outages, much less a security one, is never a good PR event, so you want to avoid the situation where customers are the ones telling you that you’re under the effect of a security incident. I will be writing another blog post on how to setup Automated Alerting to detect such events.

For now we will concentrate on Abuse Notifications from AWS which is AWS’s own processes, and they’ll notify you of any actual or potential incidents. Given below is a Sample Abuse Notification:-

So firstly, I’ll step you through some of the Use-Cases of when you can receive a AWS abuse notice in case of a potential or an actual incident identified by AWS and which is against the AWS Acceptable Use Policy https://aws.amazon.com/aup/. Some of the use-cases for which you might receive a Abuse Notice are as follows :-

Compromised Resource — EC2 Instance becomes part of a botnet the attacking other hosts on the internet.

Secondary Abuse — One of your end-users posts or downloads an infected file on your resources

Application Function — If you are using application such as web-crawlers, it can sometimes appear as a DOS attack and AWS will react accordingly.

There is a chance that the investigation of the abuse will turn out to be compromised account or resource and, in such cases, the following AWS Recommendations can help

· Change the Root Password and passwords for all IAM users.

· Add MFA to all Admin users and anyone who accesses the AWS Console.

· Create a new EC2 key pair and update instances (deleting the compromised key):

-Create an AMI and relaunch.

-Edit the .ssh/authorized_keys file

· Delete or rotate the potentially compromised IAM Access keys

· Review and delete unrecognised or unauthorised resources

-Instances

-IAM Users

-Spot Bids

· And do REMEMBER to Contact AWS Support and respond to the Abuse Notification with the steps you have taken to contain the threat.

Always do remember that there are bots or people scanning repositories like GitHub for access keys, EC2 key pairs, and other sensitive information. It happens all the time, constantly, 24/7. Hence it always helps to be proactive and avoid a lot of the risk around compromised accounts and compromised EC2 instances.