Ransomware — beyond encrypting files

I’m always looking for the bigger picture on topics and trends. A while back, it occurred to me that encrypting files was just one of many choices. Indeed, we’ve seen ad-hoc extortion take a number of forms over the decades. So far, though, the more automated form of extortion — what we call ransomware, has focused mostly on encrypting files.

Just looking at one ransomware use case is shortsighted

One of the reasons I try to look for the bigger picture is to uncover any gaps or shortcomings in security defenses. I’m seeing the majority of vendors implementing defenses for ‘ransomware’ that are really just defenses against ransomware that happens to encrypt files. Attackers have realized that most operating systems have powerful native features that can be used against their owners, to extort or perhaps distract. I’ve seen several cases where an attacker blinds a business by sinkholing DNS for the company’s banking website while millions are transferred out of accounts. In most cases, this was as simple as dropping a line in local hosts files.

Ransomware defenses/“solutions” I’ve seen so far:

• Detect when unauthorized encryption is being used and block it
• Whitelisting/App
• After discovery, globally blacklist it (this is how Apple handled KeRanger; Android can do this also — not sure about iOS, but probably)

Potential defenses (most of these already being implemented/explored) — this list is pretty lame, as this post was mainly just notes to myself, and I didn’t spend as much time brainstorming on defenses:

• Make the act of encrypting files at rest an action that has to be approved by the underlying OS — not just Windows EFS any file encryption operation has to be pre-authorized or it is blocked from running.
• Or, don’t allow any “untrusted” app to perform sensitive actions like encrypting files or making configuration changes; use file owner, source of app, method of app’s introduction to the environment, code signing, etc as ways to determine trust
• Kill process acting suspicious and send off for analysis
• Ask user if they want to allow the action, and simultaneously send off an alert to admins/security

If we just ‘solve’ ransomware by shutting down the encryption use case and don’t address the larger problem, it is likely that attackers will just choose another approach. What could they potentially do? My friends Guillaume and Stephen brainstormed with me on Twitter and came up with some ideas:

On the suggestion of preventing the computer from booting, there could be a few ways to make this work — replace the master boot record with a customized GRUB/LILO-like bootloader that locks you out of your data partitions, but could also display a URL and/or instructions on paying the ransom. I had a few additional ideas of my own:

• Based on Stephen’s idea, use a captive portal/proxy to prevent the system owner from going to any page except the one where you pay the ransom — similar to the captive portals hotels, airports and coffee shops use to force you to pay to use the Internet
• Take data offsite, then delete local copies (many people don’t have backups, or don’t have working/usable ones)
• Steal SaaS/PaaS/IaaS credentials and threaten to shut down/delete your data or infrastructure in the cloud (see the CodeSpaces story)
• Real world/kinetic impact
• Hospital/HealthCare
• Industrial — water supply, power plant
• Employees — threaten to expose HR data, salary data
• Executives — threaten to expose email, company plans and strategies

Jim Shook also tossed out a rather devious idea:

• Make subtle changes to a company’s financials that mess up their books when they sync with the SEC, makes it near impossible to straighten things out without paying a ransom to get the original data back

A few other folks weigh in on the topic:

• Some ideas on tactics and strategies to prevent ransomware
• The Grugq weighs in
• Anup Ghosh predicting the rise of ransomware two years ago

Finally, a few more notes on what other native OS features can be used against us (or have been already). This is important for threat modeling, because anything built into the operating system is something the attacker doesn’t have to bring with them.

• Built-in firewall/packet filtering
• hosts file
• any native encryption capabilities
• Ability to automatically install patches/software from unauthorized sources
• Native anti-malware/or app whitelisting
• Enable something bad by marking as trusted
• Disable something good by marking as malicious