You Need to Prevent Ransomware from Devouring Your Research

Your research is precious.¹ It’s too precious to lose. But it’s also not nearly as precious to anyone else as it is to you. And you’ll make little progress on it if you were to lose it all and have to start from scratch. It’s even more sickening to think about having that happen more than once.

You aren’t pursuing biblical scholarship to develop a side hobby in information security. But while the Internet allows you to access a vast amount of research material, it potentially also allows bad actors to destroy the research you’ve worked so hard on.

It almost happened to me. And I’d like to share the story and what I’ve learned from it. By doing so, my hope is that the same thing won’t happen to you.

Background

To set the stage, though, let me affirm again the importance of having good backups. That’s something I firmly believe and thought I had in place.

All my working files were in at least three places:

• a drive in my campus office,
• a drive in my home office, and
• a cloud storage account.

Both in my campus office and in my home office I also had an external hard drive. Windows File History copied to that drive any working file that got changed. I then had that file history set up to stay in sync between the two external hard drives so that I had the complete file history in two places also.

If any one or even two sets of files got corrupted or deleted, I still had one more set to restore and keep working from. Even if some of the files in a cloud storage got corrupted or deleted, I had the file history to restore from.

I also made sure to have my firewall and antimalware software updated, working, and doing routine scans. But all of this almost wasn’t enough.

What Happened

On 18 April 2022, I was sitting at home working. I’d been doing that for almost a full week while my family was out of town. And because it was only me at home with the dogs, I also just happened to be working later than usual.

Initial Discovery

As I sat there working on a journal article, OneDrive started notifying me that a lot of files were getting deleted. That wasn’t terribly unusual since I keep my Zotero storage folder in OneDrive.

When Zotero empties its recycle bin, it’s pretty common for OneDrive to provide some notification about a lot of files getting deleted. So, I didn’t think anything was that odd and kept working.

But then, I started noticing OneDrive downloading a lot of new files—files whose names I knew but whose extensions I didn’t. That was odd.

So, I started searching for the filenames to see if, for some reason, they’d just gotten copied to new extensions. Nope. They were gone. Just the weird extension versions remained, and I couldn’t open them. Anxiety started to rise.

Then, OneDrive or Windows—I don’t recall which—said it saw activity consistent with ransomware. Uneasiness became full blown.

I immediately started an antimalware scan. But I’d also noticed something odd—all of the activity seemed to be in OneDrive and all of the activity seemed to be OneDrive downloading encrypted files.

Thankfully, I had remote access set up to the computer in my campus office. So, I logged in and there found the root of the problem. I hadn’t been on campus in almost a week, but there my campus computer was

• compromised by ransomware,
• encrypting files,
• deleting originals, and
• uploading the encrypted copies to the cloud.

First Steps and Key Takeaways

What I saw while I was working from home was only the end result of that process. Sure, I had backups, but the longer the ransomware went on working,

• the more work it was going to take to restore my working files from their backups and
• the more likely it would be that the backups themselves would get encrypted.

1. Protect your backups.

This last point is a key weakness of the backup strategy I’d adopted. I had several good backups to recover files from. But I didn’t have a way to protect those backups themselves from corruption in the event that a system ever became compromised.

What ensued was, as quickly as I could,

• disconnecting my campus computer from anything that could possibly sync to the cloud or the computer I was working on at home,
• starting a full antimalware scan on my campus computer, and
• getting word to our information technology department about what I thought I was seeing happen.

There isn’t anything here that isn’t more or less stated or implied in the official statement about the incident that the university has now made available.² There’s also nothing particularly unique about this incident. It’s a story we’ve all heard all too frequently in all too many quarters in recent years.

But what still turns my stomach a bit is how frightfully close to home it all was—and how it could have turned out so very much worse.

2. Protect against even trusted actors.

And it highlights yet another key weakness in the backup strategy that I’d adopted. I had a strategy for managing and recovering my data in case I ever did something to endanger it. But I didn’t have a good way of preventing a threat to that data that might come in because of someone else’s action.

I’ve since learned about “zero trust,” which is

an IT security model that demands every person and device provide strict identity verification to access network resources, whether or not they are inside the network perimeters.³

My backup strategy had explicitly trusted the services and technologies I was using to enable it. But I hadn’t thought about how I was implicitly trusting everything that my devices might be connected to through, for example, the campus network. However remote or functionally irrelevant that connection might be day to day, it was still there. And I hadn’t thought through the costs that there might be if that implicit trust ever proved problematic.

What Recovery Looked Like

Through this whole process, I obviously got concerned. But I knew I had backups I could restore from, so I wasn’t as worried as I would otherwise have been.

Even so, because of how I had backed things up, that recovery process took several months. Most of the work was in the first few days. Thereafter, it quickly became more occasional chipping away at some remaining pieces.

Some of this work involved smoothing out workflow disruptions or adjusting settings having restored my computer on campus. But another good part of it also involved using the experience I’d had to create a system that would

1. better protect my data should anything similar ever happen again and
2. allow me to recover more quickly if needed.

Conclusion

All of this was pretty sobering for me, and I’m hopeful it might help you think about whether you might have any weak spots in your own plans for protecting your research. If you think of some, remember that paranoia can be productive.⁴

It doesn’t need to leave you always uncomfortably anxious. It can move you to take action to protect the research you work so hard to produce. And it should.

Next week, I’ll share more about how my own practice changed as a result of what I learned from this experience. But if you’d rather not wait for that, drop your email address in the form below, and I’ll send you a copy of my toolbox for biblical studies. In that toolbox, especially have a look at the last two types of tools I discuss and that you can start using too.

1. Header image provided by Markus Spiske. ↩

2. “Notice of Security Incident,” Faulkner University, n.d. ↩

3. “What Is Zero Trust,” Yubico, n.d. ↩

4. See Jim Collins and Morten T. Hansen, Great by Choice: Uncertainty, Chaos, and Luck—Why Some Thrive despite Them All (affiliate disclosure; New York: HarperCollins, 2011). ↩