A tale of Phobos – How we almost cracked a ransomware using CUDA

> what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files?

Compute checksums. Also, if storing diffs check out how many files the back-up think changed. All of your photo library getting re-uploaded should be a red flag.

I do an off-line, off-site backup once a year that never gets overwritten. ZFS snapshots can help here, too, for online stuff, especially if you have monitoring about changeset size.

Don't save just up to 1 week old snapshots. Also save a 2 week old, 3 week old and 1 month old one.

I store two weeks of daily snapshots, and then 12 months of monthly snapshots. It gives me a year of pretty good coverage for only about 2x the cost of just two weeks of backups.

One technique would be to place unchanging bait files that you pre-check before allowing the backup to proceed.

don't backup file names. Backup checksums.

My backups got attacked by ransomware, but I only caught it about 6-8 months after it occurred. Thankfully, my backup drive is copied to another backup which never deletes files, only copies them, so the renamed files that were encrypted were eventually copied over to my second drive, but the originals remained. The attacker wasn't aware of the second drive.

For something like photos you could just store every revision.

Sorry that happened to you. Using a de-duplicating backup solution (such as rdiff-backup or restic), will let you keep daily increments indefinitely with very little overhead.

Don't do simple rolling backups, use something with deduplication like borg backup or ZFS/btrfs if you want to do it at the FS level. The backup size should not increase by much more than the actual size of any new files, so if suddenly, you need twice as much backup space because all your files seem to have changed, you should get suspicious.

> Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos.

I can't assist you with recovery, and without a lot of logs and forensics data (or a significant performance improvement), the described method is likely unfeasible. But I'll try to find a matching sample and let you know if it's vulnerable.

> Sidecar question: when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files?

Lots of good responses, I like incremental backups without ovewriting anything (supported OOTB by all copy-on-write filesystems, like ZFS or BTRFS). Not sure how to configure this on Windows.

I use borgbackup to a server and once a month upload it to backblaze b2 with a 90 day retention policy on the bucket. The policy doesn't let you modify or delete the files for 90 days even if you have access to the account. Costs something like 5$ for the 3x500GB of backups I have.

> when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files?

Maybe you could check the level of entropy (measure of randomness) of files before backing up - very high entropy could suggest encrypted data?

I use restic which has very flexible retention policies. Rather than retain simply "x days", one can have it "keep the last x hourlies" all the way up to "keep the last x annuals", and XOR many criteria in one policy. Since it uses snapshotting, compression and deduplication it's very storage-efficient. They also offer a simple REST server which allows one to backup with append-only permissions, which can alleviate a ransomware attack.

I use rsync manually, and always with "--dry-run" first. Unless the ransome-ware is smart enough to rot my backup very, very, very slowly, I should be able to detect any problem by simply reading which files are to be overwritten. 99.99% of the files I back up rarely change.

I also have most of my non-sensitive data on Onedrive, which keeps old versions of files.

I worked in backup software for 22 years until a few years ago. My suggestion is to make a backup and store it for long term on an external drive. The to the cloud full followed incremental backup daily so you can go back to any point along the way at any time. Currently I use Acronis and it works well. I backup to their cloud to avoid having my local backups also encrypted preventing restoring in the event of failure or malware. Good backup strategy would not overwrite old backups until you must and backup regularly, so you don't lose any more data than you can afford to lose. Remember recovery time as well.

Thanks! I wonder if the Python number is correct, I remember Python being prohibitively slow in comparison. But assuming it is:

There are 256 sha256 iterations on average, so the number is a bit better - but there's probably still a lot to improve (it's much more optimised than the naive version, but it was written by reverse-engineers, not GPGPU specialists). The PoC was also opensourced [0], it would be great if someone experienced could spot any obvious problems.

One major issue was that the key scheduling is basically

    do {
        key = sha256(key)
    while (key[0] != '\0')

So on average there are 256 SHA256s per key, but worst case it takes thousands of iterations. Coding this in a GPU-friendly way was non-trivial, and there are still some GPU cycles wasted.

> Edit: An optimized version of this is very likely deployable on consumer-grade hardware. May still not very useful due to the forensics requirement, though.

I think speeding the code three or four orders of magnitude more would go a long way towards pracical usage. I think the biggest issue was getting TID and precise enough time range. Brute-forcing a suspected TID values and widening the time search range would help a lot.

Disclaimer: I worked on that research, but I'm not an employe anymore.

[0]: https://github.com/CERT-Polska/phobos-cuda-decryptor-poc

There have been tons of projects that tried to repurpose bitcoin hardware. Even if it's not the latest that's a lot of computational power! So far though none of the project I follow have yielded any real results.

Here's a interesting read that gives a bit of info on the differences and why it doesn't really work. https://rya.nc/asic-cracking.html

Not sure if you could run that on vast.ai but they do offer more granular pricing, so that might be the better option.

Yes, that's the "almost" part of the blog post (and what makes it interesting, IMO). Not really something a regular person can do. Since CERT is not profit-driven, that kind of help was offered for governmental institutions for free (but it's hard, because government and companies need to recover ASAP and this kind of research and computation takes time).

If you want success stories, the same organisation has also published decryptors for other ransomware families (Mapo, Crypromix, Flotera) and they were just broken in a straightforward way. Usually the vulnerability is not explained for successful decryptors, to make bad guys life a bit harder.

coreweave.com has pretty cheap GPUs

I imagine it's the root of the term "phobia" in this way.

also a moon.[1].

Perhaps most importantly, also a knight of Mars, beater of ass [2]

1 https://solarsystem.nasa.gov/moons/mars-moons/phobos/in-dept...

2 https://youtu.be/BP0-znoJ6fs

I love that ransomware is around because it forces companies to take security seriously or pay the price. You could even say ransomers are the good guys in this regard, contributing to a safer world.

This is like saying it’s a good thing that burglars exist so it forces us to invest in stronger locks/doors