Ransomware during a Pentest, Yes or No?

NOTE: Some of the topics in this article are probably going to be a bit contentious, but part of the hope in publishing this article is to drive some additional discussion within the offensive security community

Ransomware has become one of the most prevalent threats that companies face today. It seems that not a week goes by where we aren’t hearing about another major ransomware attack and it’s not just a feeling, it truly is big business with Chainanalysis reporting that ransomware payments reached $1.1 Billion last year. And that’s just the payments, IBM has estimated that the average recovery cost of a ransomware data breach is $4.45 million. These are devastating numbers for a lot of businesses, so is it any wonder that ransomware protection has become a major concern for the defensive cybersecurity community?  EDR and MSP advertisements are chockfull of stats about how they thwart ransomware and it seems like every other booth at security conferences are specializing in ransomware. So clearly, the defensive side of the industry has made the pivot to address this exploding threat, but where does that leave the offensive security industry?  How should we be addressing this threat in our engagements?

If you are familiar with BC Security, you know that our whole deal is threat emulation, and this is clearly a big part of the modern threats game plan, but for a long time, we were pretty against running full ransomware simulation (i.e., encrypting actual client files or targeting backups). There are just a LOT of risks involved in doing so. Anytime you are encrypting something, there is a chance that you won’t be able to recover and that could have catastrophic consequences. Especially for many of our customers who are smaller companies that sometimes have limited backups and usually have limited tech support, should we break something important on the network? Instead, we offered to drop files to prove that we had reached certain places and had write access. Sometimes, we would also encrypt those files to give the EDR/AV systems a chance to detect encryption activity.  Even with that, the rate at which customers inquired about “full” ransomware simulation continued to grow. So, we were forced to reevaluate how we handled ransomware simulation. There are, in fact, a lot of shortfalls caused by the drop file and encrypt method. Palo Alto put out a good article about a lot of the shortfalls that exist in a lot of current ransomware testing methodologies, but to summarize:

• Encrypting files that you have dropped from the same context mimics legitimate tool behavior more than it mimics ransomware. For instance, compression software does something similar. It’s also not how any big real ransomware behaves.
• Testing known extensions only verifies the detection of known IOCs and not whether endpoints can detect ransomware behavior.
• Not targeting backups. Ransomware attempts to generate additional leverage by removing an organization’s backups so that they don’t have the option of recovering without paying.
• No targeting of remote shares. Most tools that have been published only target the local machine and don’t scan for remote shares, which is often where the most interesting files live. 
• Dropping dormant “real” ransomware. Some tools and engagements try to drop actual ransomware samples without executing them, but this again only tests the detection of known IOCs rather than testing for behavioral detection.

Some of those are easier to overcome than others, but those are also just the issues of ransomware simulation tools without adding in the complexities of running them within the context of Red Team engagement.

Given the obvious pain point for customers and the complexities of running this kind of testing, you would think that this would be a significant topic of discussion for the industry. Still, there are almost no guides, blogs, or open-source discussions about how this should be done. I am only opening Pandora’s box a little bit here, there are almost no open-source tools available for doing ransomware simulation available. Now, there are some very good reasons for this, chief among them being that there is basically no way to build a simulation tool that can’t also be used as a real ransomware tool. Whether right or wrong, the open-source tool community has decided that ransomware is a red line that shouldn’t be crossed. Although there’s a valid discussion about how meaningful that line is when all the widely published C2s are the key enablers for the deployment of the ransomware in the first place but, that’s a topic for another blog post or perhaps a roundtable webcast.

The result of all this is that there are very few resources for small companies and smaller red teams on how they should be approaching this topic and tools for them to do it with. This was one of the reasons we decided to integrate PSRansom into Empire a while back. This was met with a lot of consternation initially but a telling sign about the difficulty that many smaller budget offensive security teams face. Because no one questioned that it was a common request from customers, in fact, most of the detractors admitted that not only was it a common request but that their teams’ also maintained their own private ransomware simulator implementation to carry out those requests.

So with that, let’s get into tackling a few of the points that have been raised so far, starting with whether you should do “full” ransomware simulation on an engagement? To that I would say no, at least not in a fully operational environment or all at once. There are some ways that customers can setup an isolated network that enables us to go full bore, but that’s more in the realm of large companies with already mature security environments. Instead, in some ways, can we test in stages or alleviate some of the above issues laid out in the Palo Alto article?

First, and probably easiest to address, is the encryption of files we are dropping. One way to do this is to have the customer pre-place some target files themselves. This gives the file a legitimate user context and ensures we can still target a less risky asset. The major drawback of this method, though, is that there are unlikely to be many files on the target machine for us to encrypt. Only a few files still run into the possibly legitimate behavior problem. Alternatively, we can actually encrypt some real files. Share drives can be a good target for this as the version control of the drives does give us a recovery option should something go wrong. We would still want to encrypt some local files as well, though, as that’s the core tactic of real ransomware. An option for this is to clone a real user’s box and deploy it on the network. This can work well if the customer is running a lot of cloud endpoints anyways, as it’s low cost and relatively low effort. In a local environment, the customer will need to have spare hardware to make the target box. In general, we reserve doing encryption on legitimate boxes to customers that we have an established relationship with. These kinds of operations require a high degree of trust both from the customer to the Red Team and from the Red Team to the customer.    

A more difficult problem to solve is the targeting of backups. To be honest, this is something we still don’t really do. In my opinion, the risks are simply too high. If a customer is insisting on it and you were going to consider doing it, then at the very least, I would great a dummy backup to target and only target the backups as part of a separate controlled test. I would not be comfortable doing it as part of an ongoing engagement. In fact,  we tend to conduct ransomware specific testing as its own event. This breaks with our standard threat emulation methodology, but in our opinion, the elevated risks justify this departure. Also, while there are a lot of shortfalls with how we have traditionally done ransomware testing, as has been outlined, there are still many things that traditional Red Teaming does already help address.

For example, I already mentioned that C2s are a key enabler of ransomware attacks. Generally speaking, a single end-user box being encrypted is not catastrophic for an organization. In order to be effective, adversaries therefore need to spread as far and wide into the network as possible. Without some kind of wormable exploit, this means they need a Post-Exploitation framework to use to prep the environment. Mandiant has reported that on average there are three days between the initial detection of malicious activity and the deployment of ransomware. Additionally, ransomware attacks no longer entail only the standard behavior of data encryption but also data theft for later extortion. Data exfiltration has long been a standard TTP in Red Team assessments.  This means that if the customer can detect and prevent initial lateral movement techniques and other traditional C2 TTPs, they are likely to be highly effective in protecting themselves against ransomware.

So while data encryption attacks are important to begin incorporating into Red Team and pentesting engagement there is no reason to entirely abandon our traditional TTPs. Implementing these types of tests all take high levels of coordination between the Red Team and customer. You should also conduct thorough testing of any tool you are considering using on a range to fully understand what you would be using. Ideally, you should build your own tool to ensure that there are no secondary functions in the project, but a handful of highly vetted tools, such as Empire, have now incorporated some type of encryption attack into their capabilities.

If you find this topic interesting and want to explore some training, we will be offering an Empire Ops: Tactics course focusing on the Lazarus Group and their ransomware attacks at HackMiami on May 15.