Ransomware and AWS
What is Ransomware
Ransomware is currently one of the most feared and featured security incidents reported. Unlike a virus, Ransomware attacks do not necessarily involve actively executed malicious code. We can differentiate between two main types:
Malicious software or actions that encrypt or otherwise keep data hostage which can be released or de-encrypted for a ransom. Note that there can be a substantial period between infection and execution of the payload.
Sensitive data is being kept hostage and threatened to be released to the public unless a ransom is paid.
Most ransomware attacks are opportunistic. Targets are picked more often based on ease of accessibility. There is a visible trend for certain targets where the probability of success and payout is higher, such as healthcare organizations, educational institutions and governments.
Utilizing bots, anyone with less than optimal security posture will eventually be tried and tested. Although the principles can be traced back to the late 80s, ransomware blossomed with the introduction of cryptocurrencies, making it much easier to collect while remaining anonymous.
These days, some ransomware infections can lay dormant for a longer period before actively hi-jacking data. This makes it more difficult to timely detect. However, using some of the strategies mentioned in this blog can render this characteristic useless.
Ransomware in the AWS Cloud
When you look at the ransomware types mentioned above, it’s obvious that many parts of AWS can be theoretically vulnerable, essentially anything that holds data: S3, Ec2 and attached storages, but also RDS or even the parameter & secrets store.
However, there is a varying degree of difficulty involved. Secrets Manager for example can only be encrypted through AWS KMS, so a ransomware attack would need the attacker to have his own KMS key within that AWS account, or abuse a policy that allows a cross-account key (with User Managed KMS only) or some level of privileged access to that account.
So it’s most likely an attack will take place against S3, EC2 and their ephemeral storages.
Although not strictly AWS, there have been known cases of ransomware attacks against repositories in Github, Gitlab and Bitbucket. So Code Commit could be a target as well.
How to prevent
Gartner research estimates that 75% of IT companies will have been attacked by 2025, so prevention is key. There is a multitude of strategies to employ. A selection follows:
A: Awareness
Awareness on the user level is mandatory. Users need to be aware and be able to recognize attacks like phishing, social engineering emails etc. Statistics show that phishing is used in at least 80% of the known cases.
B: Protection of workstations (Point of Entry)
Workstations need to have the correct protection. This includes anti-virus but also security and other patches. Also, system hardening is extremely important. There are several system-specific guidelines on hardening for various operating systems.
C: Protection of Servers and services:
Use CIS bench AMI baseline for your golden AMI. Employ AWS Inspector on EC2 to check for vulnerabilities, or ECR Image scanning to detect issues with your container images. Employ Systems Manager Patching to keep your systems updated. Run workload endpoint protection software (AV). Using serverless over instances also reduces malicious opportunities.
For backups, you can employ S3 object lock to prevent tampering. Similarly, you can archive using Glacier Vault. A centralized backup solution using AWS backup using Central Backup Vault Lock is a very tight solution. These immutable practices are the cloud equivalent of air-gapped backups.
D: Least Privilege:
Users need to work with the least privileges possible. Only when additional privileges are needed, these should be assumed only for the purpose and duration necessary. EC2 instances that are short-lived and immutable have no user access points (EG: No SSH). Consider reducing privileges through SCPs on the organizational level. Regularly check IAM privileges using IAM Access Analyzer. Similarly, don’t open any network ports that are not needed.
Also: enable MFA.
E: Encrypt everything!
Anything that can be encrypted, should be encrypted - both in rest and transit.
F: AWS Services on your Landing Zone:
Various services can help you protect and provide insights into your security posture. There are security-specific services, such as GuardDuty, Security Hub and Detective.
GuardDuty will continuously monitor for any suspicious activity in your account(s) in the form of Intelligent Thread Detection. Security Hub is a cloud security posture management service that performs security best practices checks and alerts you when needed. Automatic remediation is a strong key feature of Security Hub.
But also consider security-related best practices, such as the multi-account strategy. After all, accounts are hard security barriers.
Using Infrastructure as Code will allow you to recover and redeploy quickly and easily.
Manual procedures in system administration are error-prone, so automation is always preferred.
G: Check regularly your Security Posture:
Besides the various methods mentioned before, you can opt to employ automated security assessments. For example the Self-Service Security Assessment tool [1]. And of course, Well Architected Reviews are just as important. Your cloud environment is a dynamic entity, so regular checkups are key here.
F: This one I really want to single out: Don’t put credentials in Git or S3 and actively monitor this. There are tools available that can scan for credentials in (public) repos and public S3 buckets.
AWS Health can monitor as well through the AWS_RISK_CREDENTIALS_EXPOSED CloudWatch Event. Exposed Credentials are one of the leading causes of severe security breaches in AWS, be it Malware infection or Resource Hijacking for BC Mining for example.
Recovering from Ransomware
A well-developed and tested incident response is vital. Consider using a Security Framework such as NIST Security Framework [2]. When you are prepared with the suggestions above, the attack surface and spread are likely limited.
Backups form the backbone of disaster recovery so create frequent backups. Employ point-in-time recovery where possible. Additional DR solutions are made easy in AWS but consider that when you use something like cross-region replication, your replication source needs to be clean and trusted. Using vaults and object locks will ensure the integrity of your backups.
But most importantly and too often overlooked, test and check your backups!
You can employ various AWS services for the automatic remediation of discovered security issues. Security Hub, Config and Lambda are your friends here. There is an automated Security Response solution add-on for Security Hub that you can use as a starting point. [3]
As always, doing post-mortems and evaluations of incidents and your response to them will continue to improve your reaction and make you better prepared for future attacks.
Finally, the only way to weed out these kinds of attacks is to make them worthless. Don’t pay and be prepared!
References:
[1] https://github.com/awslabs/aws-security-assessment-solution
[2] https://www.nist.gov/cyberframework
[3] https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/