On a recent episode of Wait Just an Infosec, Ryan Chapman and I discussed the concept of ransomware and cyber extortion in the cloud. This blog post provides insights on the topic based on our discussion. Specifically, we’ll discuss what exactly ransomware in the cloud looks like, the common tactics, techniques, and procedures (TTPs) seen in ransomware attacks in the cloud, and recommendations on how you can be prepared to handle ransomware incidents in cloud environments.
Defining “Ransomware in the Cloud”
Part of the challenge when discussing this topic is the implication of the term “ransomware.” The creation of this term was originally based on the idea of “ransom software,” but as we’ll see when we discuss the TTPs in ransomware attacks, often we don’t see the same concept of executable software being used to carry out the attack. When we think of traditional ransomware attacks, we think of malicious software resulting in widespread encryption of files on systems. This is not exactly what you will see when observing so-called “ransomware activity” in cloud environments. Instead, you’ll likely see what could better be described as an extortion campaign. This is not necessarily surprising when we consider the trend of ransomware in general.
At the onset of ransomware campaigns, we saw the concept of a threat actor encrypting files in a victim environment and demanding a ransom in exchange for the decryption key associated with these files. Over time we saw such campaigns evolve. Potentially to combat organizations who had backups or capabilities to break weak encryption methods, threat actors began what were coined “double-extortion” campaigns. In these types of attacks, not only does the threat actor encrypt the data, but they also exfiltrate data prior to encryption. This provided them with extra leverage in ransom negotiations as even if the victim was able to recover files, the threat actor still had the threat of being able to release private data to the public if not paid. Interestingly, this year we’ve observed further evolution of this tactic. The ransomware group BianLian was observed to have dropped their encryption efforts and focused solely on extortion. To learn more about BianLian’s extortion campaigns, check out the following articles:
When we talk about ransomware in the cloud, we are going to observe this most recent type of behavior. Due to the nature of the cloud, there is not the same capability to get a user to run a piece of software and encrypt data stored in the cloud environment. Instead, threat actors are more easily able to exfiltrate data that has not been properly secured, delete the original files, and request a ransom in exchange for the return of the files. In this case, if the organization doesn’t have back ups, paying the ransom may be the only way of getting the data back, as the files are no longer in the environment, not even in an encrypted format. Additionally, even if back ups are present, the threat actors still have the ability to threaten the release of any stolen data, putting the victim organization in a serious predicament. In summary, when we discuss “ransomware” in the cloud, we are not talking about TTPs involving the encryption of data on victim endpoints, but rather a sole focus on stealing and holding data hostage in exchange for a ransom.
One brief topic worth mentioning that is adjacent to ransomware in the cloud is initial access brokers (IABs). IABs are threat actors who compromise an environment, but instead of carrying out an action on objective, they sell this access on the dark web to other threat actors. Ransomware actors have been observed leveraging IABs for quick access to environments where they wish to execute ransomware. It would not be surprising to see IABs begin to dip their toes into the cloud landscape by finding vulnerable environments, gaining access, and offering the access in the same way on the dark web. It’s a possible trend that will be interesting to monitor and may play a role in the progression of ransomware campaigns in the cloud.
Tactics, Techniques, and Procedures (TTPs) of Cloud Ransomware
As mentioned before, what a ransomware attack in the cloud looks like is very different from what we’ve traditionally seen in ransomware attacks in on-premise environments. First, the action on objective is more focused on data exfiltration over the historical trend of data encryption. Furthermore, the execution of malicious software in the environment to carry out the attack is no longer applicable when speaking about the cloud.
A recent blog post by Invictus Incident Response provides a prime example of a real life “ransomware in the cloud” attack and how the threat actor carried out their objectives: https://for528.com/cloud-ransom. This specific attack took place in an AWS environment, but similar steps could be leveraged in the same way via other cloud providers. There are some key components to the attack that give insight into the TTPs we will likely continue to observe in these cloud extortion campaigns.
First, the threat actor must obtain access to the environment. In the case observed by Invictus Incident Response, this was done via exposed credentials. In general, compromised credentials are going to be one of the primary methods of access. This may be through API keys, service accounts, or a regular user account. However they are exposed, the threat actor needs to find credentials with the correct permissions to be able to exfiltrate data or leverage privilege escalation techniques to obtain the permissions.
After obtaining the correct permissions required to carry out their attack, the threat actor will then perform reconnaissance in the environment to identify the data they will exfiltrate and use to ransom the victim. All major cloud providers offer storage accounts (AWS S3 Buckets, Azure Storage Accounts, Google Cloud Storage, etc.), which will be the primary target of these types of actors. Assuming they have the right permissions, direct access via the console, simple CLI commands, or API calls can be used to interact with this storage. At a high-level the following steps will be carried out:
- Enumerate contents of storage to identify target data.
- Download identified data out of the environment.
- Delete the downloaded data from the cloud environment.
- Create a ransom note within the targeted storage notifying the victim of the attack and providing contact information to negotiate the ransom.
These are the minimum TTPs we will likely observe when investigating cloud ransomware attacks. There may also be other steps the threat actor performs to increase the chances of a successful attack though. For example, in Invictus Incident Response’s case, they observed persistence being established via the creation of new user accounts. The additional TTPs implemented by threat actors will likely be based on a) the permissions obtained as part of initial access or privilege escalation and b) the level of sophistication of the threat actor. Only time and public reporting will provide us with a detailed picture of the full extent of what the evolution of ransomware when moving to the cloud looks like.
Preparing for the Worst
While the threat landscape associated with ransomware in the cloud is relatively unknown, there are many steps we can take to reduce the threat of an attack as well as prepare for the scenario where our defenses fail. From the defense perspective, there are a couple key things that should be done.
First, understand your identity and access management (IAM) to ensure permissions are adhering to least privilege. Along the same lines of access management, ensure that all API keys and service accounts are secured. These credentials should not be hard-coded into any source code and should not be over-permissioned. Since initial access via compromised credentials is a key step in attacks like this, ensuring that accounts are locked down is a great first step to limiting the risk of such an attack.
Secondly, ensure your data is secured and backed up. Backing data up in a disparate system may help should the initial system become compromised. Similar to IAM security, ensuring that data has restricted access, especially sensitive data, limits the scope of what a threat actor can do if they do gain access to the cloud environment. Cloud providers may have additional controls to reduce the risk of exfiltrating, modifying, or deleting data that should be investigated. For example, S3 buckets have a feature called “object lock” that can prevent certain versions of objects from being deleted, as detailed here: https://for528.com/aws-lock. Investigate protective controls offered by your cloud vendor for your storage accounts. Data should also be backed up. While this won’t prevent the threat of data being leaked if stolen, it will allow for the recovery of deleted data, allowing organization operations to more quickly resume post-attack. All of the cloud providers have backup services they offer.
Those are just a couple of the key steps that can be taken to defend against a cloud ransomware attack, or at least reduce the impact. There are many more defensive controls that can be enabled. Many of the cloud vendors publish materials providing guidance on security data. AWS even recently released the AWS Blueprint for Ransomware Defense, which provides a mapping between their offerings and NIST security controls. For defenses in Azure, FOR528 course author Ryan Chapman has released tips for both defending against and responding to ransomware in Azure environments: https://for528.com/azure. Whatever cloud platform you are leveraging, investigate defensive controls offered by the provider that align with countering the TTPs discussed above.
Moving onto the preparation side of things, to ensure that if the worst happens we can respond effectively, there are three key takeaways to mention:
- Log Analysis: To figure out what happened, you need to have the evidence to do so. The key word here is visibility. In the cloud, this is your logs. Many logs are not enabled by default. Those that are often have retention limits or are stored in locations that are not prime for analysis. Ensure the that:
- Non-default logs are enabled. For example, for sensitive data enable object access logging.
- Logs are retained and centralized. Determine where you want to analyze or retrieve logs from in the case of an incident and ensure all logs are forwarded to that location.
- Understanding of the Environment: When an incident occurs, you don’t want to waste time trying to learn about the cloud architecture or who is storing data where. Ideally, you should be able to begin your response with a clear understanding of what is in scope given a certain situation.
- Ransomware Procedures: Incident Response teams should always have well-documented procedures on how they will respond to incidents. A dedicated ransomware playbook should be created to understand how investigations specifically associated with cloud ransomware attacks should be carried out.
- This should not be limited to your first party teams. Should you work with any third party teams such as MSSPs, incident response firms, and others, be sure to ensure they too have cloud-specific playbooks available. Discuss this directly with these teams.
Once again, these are just a few of the steps that can be taken to prepare for a cloud ransomware incident. In general, your team needs to discuss what a ransomware incident in their cloud environment would look like, what defensive controls can reduce the impact, and how the team will respond if required.
Summary
In this blog post, we discussed the evolution of ransomware into cloud environments, the TTPs leveraged by the threat actors, and how we can defend against and prepare for such attacks. Cloud ransomware is still a new concept, but given the popularity of ransomware attacks in recent years combined with the move to the cloud, it will not be surprising to see threat actors evolve into this space. As we learn more about how these threat actors operate, we will be able to more effectively defend against their attacks. For now though, there are steps we can take to prepare for if a trend towards cloud ransomware takes place.
If you want to learn more about responding to ransomware incidents, check out SANS FOR528: Ransomware for Incident Responders. For more on cloud incident response, SANS offers FOR509: Enterprise Cloud Forensics and Incident Response.
