Live data from Hacker News

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

cert.pl

1–10 of 65 posts

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

#2
Overall, cool work! Especially the search space reduction part.

I haven't dive into the code, but only 818000/60=13633 attempts per second for 64 SHA-256 rounds plus one AES-256 decryption on a 2080 doesn't sound right. Learn some GPU and tuning the code can likely increase the throughput a lot.

Mind you, that's only 25x naive Python implementation on (supposedly) 1 core.

Also, hashcat does >1M hash/s for even higher number of SHA256 iterations, and hundreds of million attempts per second on single block AES-256.

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.

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

#3
post #2

Overall, cool work! Especially the search space reduction part. I haven't dive into the code, but only 818000/60=13633 attempts per second for 64 SHA-256 rounds plus one AES-256 decryption on a 2080 doesn't sound right. Learn some GPU and tuning the code can likely increase the throughput a lot. Mind you, that's only 25x naive Python implementation on (supposedly) 1 core. Also, hashcat does >1M hash/s for even higher…

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

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

#5
Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update.

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? I found out too late that all my backups were encrypted. I only had 1 week retention to save space. Is longer retention and manual checks the only sane strategy? Or has some backup software built in sanity detection for crypto attacks by now?

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

#7
So, if you're a victim and you don't want to pay ransom

- hire an expert to find out the missing data (timestamp, is it the vulnerable version?, ...), then

- rent a GPU server and keep the fingers crossed.

I've looked for cheap GPU servers yesterday, the cheapest i found was Ultrarender at 200€ per week for a Dual RTX 3080Ti remote workstation. Which is probably overkill, a single RTX 3080Ti can do it in 33 hours or so (assuming the "12 Nvidia GPUs" they mentioned in the article are of similar speed).

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

#8

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. 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? I found out too late t…

> 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.

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

#9

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. 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? I found out too late t…

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.

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

#10

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. 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? I found out too late t…

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