On backups

In my previous post I mentioned that I’d been using CrashPlan for making backups on our Windows PC. Like many, I prefer to get a feel for the software before I pay for a copy, so I installed the free version. It all seemed to set up OK, I didn’t immediately come across any missing features and so I left it alone to do its thing.

And in the absence of any error messages I believed that it was working just fine. Alas, that was not the case.

In checking out my backup drive when dealing with our Trojan infection, I found out that CrashPlan had filled its allotted hard drive and in fact hadn’t backed up anything in weeks. And in the process had utterly failed to alert me to that fact. Hey CrashPlan – how about using the Windows notification area for alerts? I mean, a backup failing is a major error and the user should be told about it as soon as possible.

One of the reasons I installed CrashPlan in the first place was that I wanted something that was more intelligent backup than Windows’ own. However, the free version of CrashPlan has a set of default settings for the backup frequency and number/age of versions that runs the risk of filling your backup hard drive then nothing more will be backed up because nothing will be old enough to delete. CrashPlan’s official advice on solving this problem? Get a bigger hard drive. Okaaay….

OK I could solve this problem by paying for the basic version, which includes unlimited online backups too. After all, $60 a year isn’t that much to pay for peace of mind is it? Normally I’d argue that is cheap, but in this case all I wanted was a local fire-and-forget backup of our primary documents directories that didn’t rely on me remembering to run rsync. And $60 was too much for just that.

Enter Windows FileHistory. I hadn’t heard of it until I searched again for Windows backup solutions. After a bit of fiddling about (tip: don’t include any folders that have a frequently-updated cache, like that for a web browser!) I seem to have it working just fine. It’s been going for a few days now, and is updating only what it needs to update which is pretty much all I want in a backup program!

However, I’m not entirely convinced that it’s a long-term solution as it seems a bit fragile. When configuring FileHistory, it seemed to get itself into a state where I couldn’t add new folders to the backup, and remove one would remove them all. A round of disabling it, reboot, and re-enabling FileHistory fixed it, but I shouldn’t have to do that every time. (I shouldn’t have to do it at all, of course…)

So we’ll see how it goes. I didn’t like the fact that CrashPlan forced me to create yet another account even to use the free version – my Windows 10 box uses local logins, so no additional accounts needed to use FileHistory. Plus I’ll keep doing my rsync backups to the Linux box, so at least I’ll always have a second copy. Mind you, even that backup drive is filling up…

Postscript: I should admit some fallibility here. My initial backup plan included a directory tree that mistakenly contained our web browser caches, which of course tend to a) be large and b) change frequently. (Not to mention that they are pointless to back up!) That meant every time the backup ran, it saw that a few GB of files had changed and duly did exactly what I’d asked it to do. Alas, this resulted in my paltry 160 GB drive filling up way sooner than expected. So one of the things to make sure when you set up a backup is to make sure it really is only backing up the files that you wish to keep! I know this now… 🙂

A passing encounter with ransomware

It all began with the most innocuous of actions: a click. One of those many articles on Facebook that pops up in the “Related stories” area when you “like” an article. Next thing we had a web page showing all manner of error codes along with advice on how to fix the “problem” that had been detected, pop-up dialogs galore and the computer began beeping, like the alarm system on a science-fiction spaceship. It was almost comical.

Until I realized what was happening.

Then I had the “Oh shit – ransomware” moment, and lunged for the power button. (In retrospect I should have just tried to shut down the web browser from the task manager but I didn’t want to delay shutting down the computer if it was about to start encrypting our hard drives.)

That done, I thought for a moment, trying to assess the damage in the worst case that the hard drives had been encrypted. We figured that we might lose the past two weeks of photos and any edits. That wasn’t too much of an issue, really as we hadn’t cleared the memory cards in our cameras for over a month. We would probably lose a few recent PDFs and text files – annoying but not disastrous.

Having weighed up the situation, I retrieved some cables for reading bare hard drives and then set about dismantling the computer. First I detached the external hard drive used for continuous backup of a few folders (more on that later). Then I opened the case and removed the 3-TB main hard drive that contains all our photos and documents.

I booted up the Linux box and plugged in the external backup drive. It mounted just fine and I could read the files on there – at least as much as you can read the files in a CrashPlan backup. There was no sign of any recent modifications to the file system, so I figured that if something had started the encryption process, it hadn’t got to that drive yet (after all, it was down the list at F:).

I breathed a sigh of relief: it looked like we’d actually have up-to-date copies of our documents. Yay!

Next step was to attach the 3-TB drive. That’s when my heart started to sink. It mounted as an empty volume. No partitions, nothing. Wait, that’s not quite true. In actual fact it didn’t even mount – it just showed up as empty in the disk utility. Oh crap. Was that it? Had we actually lost the contents of that drive? I didn’t dare hope it was just some quirk.

Unplugging that drive, I moved on to the main system drive. Plugging that in was immediately more hopeful: a partition called “System Restore” mounted, and then I got an error message saying that the main partition couldn’t be mounted because Windows had been put in hibernate mode. Another light bulb moment, this time a positive one – I think – as I remembered I’d configured the power switch to hibernate rather than power off. OK, so the drive had gone into hibernation correctly. I mounted it read-only and lo-and-behold I was in business.

Poking around on the C: drive it appeared that everything was in order. I couldn’t find any nefarious-looking files (not that I really knew what to look for) with the right timestamp. So I decided to make a local backup, just in case. I used the tried-and-tested rsync to make a copy on one of the drives in the Linux box, which gave me time to do a bit of research about ransomware…

What I found gave me hope. It seemed that a couple of the most common types were in fact browser-based and weren’t real ransomware at all. I looked at screenshots to compare with the picture in my memory from the brief glimpse I took before hitting the power button, and decided that – if I was lucky – we’d most likely been hit with the TechBrolo.C Trojan installer. Furthermore, Windows Defender seemed to know about them and could remove them.

Progress of sorts, then. Once my local backup was done, I decided it was time to test those ideas, and got back down on my hands and knees to reattach the hard drives. Leaving the network cable unplugged, I tentatively hit the power switch. I was soon looking at a normal login screen – very promising, which told me we hadn’t been hit by real hard-drive-encrypting ransomware. I logged in and waited. Everything looked fine. I checked the 3 TB drive and was relieved to see that all our files were still there. I started up ACDSee to browse some photos just to be sure. All looked OK. Phew!

I restarted Firefox – which of course tried to load all the previously-open tabs. At least this time I was able to kill the tab with the offending payload, and looked through the history to see what website had spawned it. I copied the URL and deleted the entry from the history. I won’t give the URL as I would hate for someone else to click on it, but the site is in the .ml top-level domain (which is Mali, where Timbuktu is located).

Everything still looked fine, so I started up Windows Defender and set it to run a full scan. However, not long after it got under way, a warning sign did show up saying that a potential malicious file had been discovered.

When the scan ended (two-and-a-half hours later), the report did indeed show a single potential threat: the TechBrolo.E trojan, hiding in our Firefox cache. I clicked “Remove” and within moments it was gone. I re-ran a quick scan just to double check and it came back clean. Yay! I plugged in the network cable, started the task manager and waited. Nothing was happening: just an idle computer. Next up was Firefox again, and it too wasn’t doing anything out of the ordinary.

Now, remember that backup I did on my Linux box? Well, that included the Firefox cache, so I went in and had a look. Sure enough the file was a gzipped Javascript file with some stern warnings and more newlines than I’ve ever seen in my life! It looks like it tries to load a PHP file with an insane name, which I’m guessing is where the main payload is.

I wonder if the Javascript downloaded is country-dependent? I mean, showing a ransomware web page with a 1-8XX number won’t get you very far outside the US and Canada.

And so there I was a few hours later, and all was as well as it could be.

At the end of the day, all I can say is I’m glad I had that Linux computer, both as a second (and more importantly non-Windows) computer and as a backup for all the files we care about, as well as having the right cables to connect hard drives to a USB port. I’m also glad that I could shrug and say that at worst, we’d have lost only a couple of weeks’ documents and photos.

My take away from this? Have a backup of all the files you care about. And make sure that backup runs as often as you need it to. Every day, if necessary, though weekly is probably good enough. And watch what you click on…!