Ransomware and the Cloud - Is your cloud infrastructure vulnerable?

What is this article about?

Unless you have stayed away from cybersecurity news for the better part of this decade, it is very difficult to have missed a newsworthy event that did not involve ransomware. Organizations getting hacked and their systems being taken over by malware spread through USBs, the network, vulnerable applications etc. is commonplace in the modern world of digital connectedness.

Broadly speaking, ransomware is a class of malware that attacks a vulnerable system, encrypts the data and files on it and asks for a payment to be made to the attacker in order to recover the data. This is not a new class of malware, in fact the earliest such malware extortion was performed via the “AIDS Trojan” in 1989. However with widespread media coverage, the increasing complexity of ransomware variants in their capabilities for spreading and evading detection, and the extent of the infection and damage has brought this term to the limelight.

Notable examples of ransomware include CryptoWall, WannaCry, Petya, SamSam and DarkSide. Early 2021 also saw the rise of Ransomware As a Service (RaaS), one of the more popular services being REvil (now defunct), where a perpetrator could hire hackers to attack and infect targets with ransomware.

This article takes you through some of the approaches that ransomware authors could take to infect machines on the cloud, what impact ransomware can have on businesses and some steps you can take to stay safe on the cloud.

What’s the business impact of ransomware?

Every business that has a digital footprint can fall prey to a ransomware attack. The cost to business in the event of an attack is not only the ransom paid (which most organizations deal with on their own terms, some even choosing not to pay), but also the business lost cost due to systems being inoperational, human resource cost in managing customer support, IT support cost in recovering data, ensuring patches and controls are in added to prevent a re-infection, insurance premiums, legal defense costs and settlements and of course, the loss in brand value and trust..

A survey conducted by Sophos pegs the global industry average, in the Manufacturing and Production sector, to recover from a ransomware attack to be about $1.85 Million USD. This is predicted to go even higher in the coming years. The FBI’s Internet Crime Complaint Center (IC3) showed ransomware losses at $29.1 million in 2020, with its latest Internet Crime Report showing over 2,400 formal complaints about ransomware. This number only includes the cost for the ransom paid and does not include the other costs as described above.

The bottom line is that ransomware attacks are here to stay as an easy way to extort money either via targeted attacks or randomly picking up vulnerable systems in the cloud and on-prem for organizations that do not practice security hygiene. Ensuring the security aspects of the cloud are taken into account drastically reduces the chances of an infection that could have easily been avoided.

How is the attack and propagation different for cloud platforms?

Ransomware is often spread through phishing emails that contain malicious attachments or through drive-by downloading when a user visits malicious websites. Most ransomware is written for the Windows operating system as the ability to spread through the Active Directory, local file shares, password reuse and USB usage makes them more susceptible to attack and spread.

The delivery mechanism for the payload that causes the actual infection can be email, execution of malicious downloads, drive-by downloads, fake antivirus software, pirated software or program execution via a removable media. One of the key features that ransomware uses to maximise impact is to find additional hosts to spread.

However, when it comes to the cloud, a lot of these scenarios do not come into play, unless you are using cloud servers as workstations, like Amazon Workspaces for Windows or accessing cloud instances from an infected machine where the ransomware can piggyback on some functionality. Malware creators may utilize the API nature of the cloud to infect, spread and avoid detection. For example, malware like the Jigsaw ransomware looks for OneDrive storage and encrypts files that are locally synced. Jigsaw abuses the OneDrive storage sync capability to propagate to the shared folder and from there on to everyone else's machine that synchronizes the same set of files from the cloud.

A unique malware propagation method that cloud based ransomware may use is the ability to steal authentication tokens and secrets via metadata endpoints or environment variables. Based on which cloud platform is being targeted, metadata endpoints may provide tokens for attached roles to the machine or access tokens to the cloud. These tokens can then be used to access other machines within the cloud infrastructure or even other services based on the access level provided. The tokens could be used to access database stores or storage services like S3 to access records and files on them to encrypt the data.

Here are some attack scenarios that ransomware and other malware could use to propagate.

Attack Scenarios

The following is a list of five different threat perspectives that can be abused by malware and ransomware to spread and cause further infection. Although these vectors are not largely used by ransomware creators, it is important to identify these vectors and understand the underlying mechanics of the exploitation, infection, spread and anti-evasion phases of a malware’s lifecycle and how they stand out in the cloud world.

RDP/SSH ports open to the world

Perhaps the most common way to detect and exploit potentially vulnerable Windows and Linux machines on the cloud is to find remote administration services like Remote Desktop and SSH, and gain access to systems from there.Remote Desktop protocol and SSH allow for administration of machines remotely. However, gaining access to any of these services also allows you to take over the system, its data, any secrets stored, additional network information etc. Malware writers will often focus on finding Remote Desktop servers that are vulnerable to? older exploits or simply attempt to brute force the password. Once logged in, the ransomware gets downloaded onto the machine and starts encrypting files.?

A quick search on Shodan shows numerous servers that have their Remote Administration ports like RDP (TCP 3389) and SSH (TCP 22) open to the world. Although these are protected services with passwords and keys, it is not unheard of to use stolen keys, weak passwords or even vulnerabilities within these services to gain access to the systems.

Once access to the system is obtained, targeted ransomware could also attempt to identify the kind of files in use, any remote cloud storage or file shares connected to the instance, secrets and key on disk or even auth tokens from metadata instances and environment variables for further spread and infection within the cloud account.

NetBIOS and file sharing ports open to the world

There is no good reason for a Windows cloud instance to have its NetBIOS port (TCP 445) or its File Sharing TCP ports (TCP 135 - TCP 139) exposed to the Internet. But the reality is different. A quick search on Shodan shows there are a lot of Windows cloud instances exposed to the world via their File Sharing services across all the major cloud platforms.

The possibility of gaining access to a remote Windows machine via an exposed File Sharing service is higher given the vulnerabilities Windows has had in the past with this service, with notable examples being Conficker, WannaCry, Stuxnet etc.

The mode of propagation, once the malware has compromised the machine, would be the same, as if a user on the system downloaded the malware and executed it. In the circumstance that the machine is connected to additional Windows machines either via an Active Directory configuration or via a flat network within the cloud, the chances of ransomware propagation to other machines are higher.

Additionally, given that this is on the cloud, accessing the environment variables or the instance metadata endpoints would likely give access to tokens that can be used to further access other services within the cloud.

App vulnerable to SSRF with platform creds

Server Side Request Forgery or SSRF is now a widely accepted security problem for web applications and network services that accept user data and perform network requests on the server. SSRF is now part of OWASP Top 10 2021 which, in a way, shows that the prevalence of this security issue can no longer be ignored.

From the perspective of the cloud, an application that is vulnerable to SSRF gives attackers the ability to make requests from the server using the web application’s vulnerable functionality. On the cloud, this can be used to access the instance metadata endpoints, usually at https://169.254.169.254/ and if an IAM role is attached to the instance (AWS), its temporary credentials would be accessible via the IAM Security Credentials Endpoint.

Here’s an example of an app that is vulnerable to SSRF that is leaking credentials which can be reused to gain access to the system or other services within AWS cloud.

A ransomware can utilise this vulnerability, identifying web applications vulnerable to SSRF using publicly available exploits or 0 day weaknesses to gain access to credentials. The malware can then gain access to systems using technologies like SSM or simply corrupt files on storage services like S3.

Service piggybacking from trusted networks

Based on what functionality and user need the cloud is used for, malware can make its way to the cloud instance or other services within the cloud by piggybacking on legitimate requests to the cloud.

An example of this is the Jigsaw ransomware that gets downloaded via email attachments but once executed starts looking for OneDrive’s locally synced folders to encrypt. The file synchronization between OneDrive and the local system then causes the encrypted files to reach the cloud and from there sync to local folders across the organization that is using the OneDrive location.

Any SaaS cloud platform that does file synchronization or backup as a service can fall prey to a ransomware attack as the propagation relies on the cloud services functionality itself using a single system as a spread vector.

Other services that can be used for piggybacking are file transfer services or remote execution services. In the event of transferring folders from a local machine to a cloud instance or even between cloud instances, a copy of the ransomware binary could also make it to the target environment resulting in additional data loss. A remote copy and execute service could also accidentally move a malware infected binary or a document to the target machine resulting in the infection of the target.

A little creativity on the part of malware writers could also cause services that use database connections to insert a copy into remote cloud database instances or affect web pages or configuration files to auto-execute when a container is created. The variations are limited only by the imagination of the ransomware creators and how misconfigured the state of affairs is for the cloud environment.

Malicious repos and software installed directly on the machine

This technique is the most common and oldest method of infection and propagation for ransomware. This is equivalent to a user receiving a malicious attachment via email or an infected file via a USB storage device that gets executed and causes data to become encrypted on the system and spread to other connected machines.

WannaCry was notorious for its ferocity at which it attempted to spread to other machines.

An example on the cloud where this would be relevant is with cloud platforms that provide virtual desktops as workstation hosts. Amazon WorkSpaces is one of them. A user receiving an email from a known sender but with a malicious attachment is a very reliable delivery mechanism for malware. Another example would be where a user is tricked into visiting a website that downloads malicious content using scareware which are websites or software that scare the user by using fake messages about an infection on the system and that they need to “clean” it by using a free scan etc.

Regardless of how the ransomware is downloaded to the machine, once it is executed, it attempts to encrypt files and spread to other machines on the network or within the cloud infrastructure. Again, on the cloud, the infection mechanism could be via authentication tokens that are obtained via instance metadata endpoints, environment variables or via config files located on the instance.

How can you stay vigilant and safe?

With so many different ways of infection and propagation within the cloud, how different are the measures that one would take on-prem and on the cloud?

Identifying potential entry points for the ransomware is the key to thwarting any attempts of an attack. This requires visibility into resources that are running within the cloud, their configurations, the way they are set up and who has what kind of access to them. Here are some quick pointers though that you can use

1. Ensure network segregation is well understood and implemented. Using security groups and network firewalls to restrict traffic to management ports, to only bastion hosts or to trusted systems is an important first step. Restrict access services that have no business being visible to the Internet like FTP, file sharing services and database endpoints.
2. Ensure credentials for remote management are well protected and stronger means of shell access is used (unique SSH keys > passwords for example). Most cloud providers give the ability to use a just in time shell via the browser or an agent that is running on the cloud instance.
3. Perform periodic code reviews and security tests on web applications that are exposed to the Internet. Ensure the application is updated regularly and security controls around authentication and authorization are well established.
4. Restrict privileges to IAM roles and account tokens that are attached to cloud instances. This is to reduce the blast radius in the event of a breach as the restricted privileges will reduce the impact the ransomware causes. Implement the latest versions of instance metadata on AWS (and other clouds wherever applicable) to ensure an additional level of security is in place.
5. Educate users on the threat that ransomware poses. Implement security controls within the organisation to prevent employees from using external storage media, browsing on websites with questionable content or even trusting email attachments from known sources. Basic security hygiene like using strong passwords, connecting to only trusted wireless networks and restricting the kind of software that is downloaded and installed on the system, goes a long way in preventing an infection.?
6. Lastly, ensure that periodic backups of all data are made and are ready to be rolled out in the event of a disaster. Protect these backups with hardened access and verify data integrity on a daily basis.
7. AWS has published a generic guide on how you can secure your cloud environment from ransomware here - https://d1.awsstatic.com/WWPS/pdf/AWSPS_ransomware_ebook_Apr-2020.pdf
8. Google talks about some best practices that can be used to protect organizations from the threat of ransomware here - https://cloud.google.com/blog/products/identity-security/5-pillars-of-protection-to-prevent-ransomware-attacks
9. Azure talks about data backup and restore planning to protect against rnsomware here - https://docs.microsoft.com/en-us/azure/security/fundamentals/backup-plan-to-protect-against-ransomware

It is crucial to not underestimate the threat that ransomware poses. The impact of a ransomware attack can be much larger than you anticipate because of the additional work that needs to be done to get your business back on track after the attack. Proactively protecting your cloud assets is the only way to ensure you remain safe and your business can continue without any hiccups.

To be able to secure your cloud infrastructure, you need to have complete visibility within your cloud and have answers for things like who your users are, what kind of access they have, how are the various services and resources configured, are you certain these resources are required and not already created as a means of malware propagation, which of your data stores are public, are they protected using the cloud provider’s encryption, what ports are visible to an attacker on the Internet, which of your services can become a security nightmare for you. Having answers to these questions will allow you create a well planned security strategy for your cloud.