The Evolution of Ransomware

5/28/2021 - By Stephen R. Reyes, CISA, CISSP

As many people know, ransomware started by simply encrypting large amounts of victims’ data and holding the encryption key until the victim paid a ransom. The initial iterations of this were almost harmless, but as we look back, the genius involved is obvious.

As originally designed, the attack was thoughtful and included elements of solid small business strategy. The hacker needed to be paid in bitcoin, so they made sure to include tutorials on how to acquire and transfer the bitcoin. They wanted to build confidence in their “customer base” so they never asked for repeated ransom. They understood their “customer’s” needs so they established a process where the hacker never had access to the data and it never left the original system. This allowed their “customer” to avoid reporting requirements that could be triggered by information disclosure.

Eventually, disrupters moved in. Backup products and technical support staff began to improve backup and recovery options. Soon the hackers’ “customers” were no longer willing to pay to recover their data because they had cheaper and faster alternatives in the form of backups and versions to roll back to. This is when the hacker networks seemingly dropped the illusion of being a “customer-focused operation” and moved on to more traditional, sinister techniques. Initially, the hackers would simply encrypt the data in place. Later versions began to transfer some of the data to a location in the hacker’s control. The hackers would then use this as leverage. If the victim simply restored their data and refused to pay, the hackers would publicly release a small amount of the data it transferred out and make another demand with the ultimate threat of releasing all the data.

Showing the World What They Will Do

The first example of this escalated version of ransomware that went public was inflicted on two cities, one in Florida and the other in California. Ultimately, the cities decided they had sufficient internal options to recover the data that they did not need to pay ransom to get the recovery keys from the hackers. When the hackers then threatened to release the data publicly, the cities again refused to pay. The problem for the hackers in these cases was that the majority of the data was already public information and was not protected. The small amount of data that was protected information largely belonged to city employees. The cities determined that the fallout from the release would be minor, so they proceeded with their plan to not pay the hackers. Ultimately the hackers released the data and the cities’ assessments of the risk were correct, as there were no notable impacts from the incident.

Many saw this as a win for the good guys and believed the hackers lost. However, this could not have worked better for the hackers. Since they attacked a city, the discussion of the hack was public. In addition, because the city refused to pay and the hackers ultimately released the information, the hackers publicly displayed their ability and willingness to release information if they are not paid. For a local government institution, this was relatively insignificant because they did not lose customers, their revenue was not reduced and there was no hit to their stock price. However, had this been a business, the risk would have been much greater and the motivation to pay would have been much higher. Therefore, this was not a win for the city and a loss for the hackers. It was the ultimate demonstration of what could happen if you refuse to pay their ransom - a public deterrent of sorts.

Now, there is yet another evolution in the world of ransomware. In the latest version, the hacker sends notices to your customers, clients, employees or other interested parties letting them know they have stolen the company’s data. It then stresses those interested parties to pressure the compromised organization to pay, supposedly preventing the stolen information from being leaked to the public.

The U.S. Government to the Rescue

In October 2020, the US Treasury Department Office of Foreign Assets Control (OFAC) publicly announced its position on this issue, stating they considered it illegal to pay ransomware. Per their statement, “OFAC may impose civil penalties for sanctions violations based on strict liability, meaning that a person subject to U.S. jurisdiction may be held civilly liable even if it did not know or have reason to know it was engaging in a transaction with a person that is prohibited under sanctions laws and regulations administered by OFAC.” It is clear the government is pushing organizations not to pay in an effort to cut off funding to hacker networks. In addition, the fractal of regulation governing data protection gets continually more complex as every government agency from the European Union to your local county government creates their own rules, definitions, penalties and more.

Is there a bright side?

Unfortunately, all of this leaves many businesses feeling caught in the middle, but there is one bit of good news: the public is becoming somewhat numb to the release of private data. The pragmatic risk of a data release to a business is no longer the loss of client base or revenue, it is now largely the impact from government agencies, and perhaps this is how it should be.

The malware world is ever-changing. Your company needs to be aware and continuously audit its systems for any weaknesses. If you need additional insight or have questions regarding vulnerabilities in your IT programs, please email me, reach out to a member of our team or explore our services.

Join our email list to receive updates as they are released!

About the Author | Stephen R. Reyes, CISA, CISSP

Stephen is shareholder in charge of the Information Technology Services Department of Saltmarsh, Cleaveland & Gund. He joined the firm in 1997 and has been practicing in this field since 1990. His experience includes computer networking and technology consulting. Stephen is a Certified Information Systems Auditor, Microsoft Certified Systems Engineer and a Cisco Certified Network Associate. He also holds certifications with ISACA, Novell, Citrix, and CompTIA.