Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Rapid Ransomware
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Rapid Ransomware

Hey guys and girls,

My dad has installed some ‘free’ download manager (against my advice) a week ago. He then got a screen telling him he was a victim of ransomware. He turned off his pc, rebooted and all was fine.

A week later, he noticed all his files were encrypted. Pretty sure it took the encrypt program a week to encrypt the full 3TB of data.

My dad never makes backups (against my advice).

He became a victim of the Rapid Ransomware. All the files are encrypted. Is there any way to decrypt the files? He is a radio engineer and has some interesting schemas from back in the 80’s that he lost and would like to have back.

Told him there’s a good chance the files are gone forever, as we do not plan to pay the ransom.

So far I already tried booting DEFT and recovering files with Foremost. Didn’t work, unfortunately.

Any idea’s?

Comments

  • Unfortunately, most of these ransomware cases, if the ring is not caught or the keys are released (and incorporated into a security tool for decryption), all hope is generally lost. Without backups, wipe the drive and call it a day.

    This happened to my mother's computer one day; it became the day we started doing backups and verifying backups... I still keep the encrypted HD just in the even that one day there is a key, but it's more of a lost hope than anything.

  • @daxterfellowes said:
    Unfortunately, most of these ransomware cases, if the ring is not caught or the keys are released (and incorporated into a security tool for decryption), all hope is generally lost. Without backups, wipe the drive and call it a day.

    This happened to my mother's computer one day; it became the day we started doing backups and verifying backups... I still keep the encrypted HD just in the even that one day there is a key, but it's more of a lost hope than anything.

    Yep! This is what I thought. It sucks big time. Gladly my dad is considering buying a backup disk now. Also, I have recommended him to use Virtual Box and run it in a VM he has some software or downloads that is from an uncertain source.

  • @DennisdeWit said:

    @daxterfellowes said:
    Unfortunately, most of these ransomware cases, if the ring is not caught or the keys are released (and incorporated into a security tool for decryption), all hope is generally lost. Without backups, wipe the drive and call it a day.

    This happened to my mother's computer one day; it became the day we started doing backups and verifying backups... I still keep the encrypted HD just in the even that one day there is a key, but it's more of a lost hope than anything.

    Yep! This is what I thought. It sucks big time. Gladly my dad is considering buying a backup disk now. Also, I have recommended him to use Virtual Box and run it in a VM he has some software or downloads that is from an uncertain source.

    @DennisdeWit said:

    @daxterfellowes said:
    Unfortunately, most of these ransomware cases, if the ring is not caught or the keys are released (and incorporated into a security tool for decryption), all hope is generally lost. Without backups, wipe the drive and call it a day.

    This happened to my mother's computer one day; it became the day we started doing backups and verifying backups... I still keep the encrypted HD just in the even that one day there is a key, but it's more of a lost hope than anything.

    Yep! This is what I thought. It sucks big time. Gladly my dad is considering buying a backup disk now. Also, I have recommended him to use Virtual Box and run it in a VM he has some software or downloads that is from an uncertain source.

    Alternatively, you can also suggest setting up Sandboxie as an interim instead of booting VMs up. Sometimes the easier the learning curve, the better it is (although I'd venture to say there may be more [configuration] with Sandboxie due to the amount of customizable options).

  • Sorry to hear that of your Dad's problems. There are several variants of Rapid and based on the work that I've read on it, it appears to use an encryption mechanism that is not likely to be easily defeated. The way that it works is to generate a unique AES key which is used to encrypt the files. The AES key is protected using an asymetric algo so the private key is only known to the criminals.

    I've read that Rapid will continue to encrypt new files if they are created. In theory, it could be possible to recover the encryption key from the running process if the malware hasn't been removed. But I don't know if anyone has done that research and analysis. Also - my knowledge of Windows OS process protection methods is dated so that may not even be possible.

  • @birchbeer said:
    Sorry to hear that of your Dad's problems. There are several variants of Rapid and based on the work that I've read on it, it appears to use an encryption mechanism that is not likely to be easily defeated. The way that it works is to generate a unique AES key which is used to encrypt the files. The AES key is protected using an asymetric algo so the private key is only known to the criminals.

    I've read that Rapid will continue to encrypt new files if they are created. In theory, it could be possible to recover the encryption key from the running process if the malware hasn't been removed. But I don't know if anyone has done that research and analysis. Also - my knowledge of Windows OS process protection methods is dated so that may not even be possible.

    The virus itself was easy to kill. The problem is the encrypted files. So what I did is completely wipe the SSD where Windows was installed to and then reinstall. All works fine again, but of course the files on the other disks will stay encrypted.

    I noticed the BIOS had some issues with booting the SSD. After I repartitioned the full SSD and reflash the BIOS, it worked fine.

    Nasty stuff.

  • NanoG6NanoG6 Member

    Ouch.. sorry to hear that. as @daxterfellowes advised please keep the encrypted HD just in case one day there is a key

  • @NanoG6 said:
    Ouch.. sorry to hear that. as @daxterfellowes advised please keep the encrypted HD just in case one day there is a key

    Will do! Also contacted some ransomware hunters. They’re asking for samples in order to decode.

  • jsgjsg Member, Resident Benchmarker

    I'm from the other side of the fence (white hat and protection) but I'm working in the security field and have a bit of experience.

    Sorry, but your fathers chances are very slim.

    As of the current state of things I'd think that even second rate criminals have good enough kits and libraries available to avoid the usual common errors (which then are the point of attack for people trying to decrypt their victims drives).

    And sorry, but the chances to somehow extract the sym. crypto key out of memory are very slim, too. About the only chance I'd see were if some seriously resourceful specialists were - for whatever reason - interested enough to properly analyze the malware which would be a BIG and very costly undertaking.

    In kind you know a bit about crypto and are interested:

    The sym. key is almost certainly NOT in the binary but hidden behind other layers like e.g. an additional sym. crypto layer and a deterministic PRNG the seed for which is somewhere in the binary or some file. And the real key to encrypt your fathers files is only generated at runtime within the processors cache and very shortlived.

    But I have a probably valuable and important piece of advice: KEEP the machine (into which you put another drive now) because even if an "anti-dote" were somehow found chances are high that some machine (and network) specific data are involved both to create the poison sym. key and the anti-dote sym. key.

  • Jona4sJona4s Member
    edited July 2018

    Im not an expert on cryptography, but Im pretty good at massive multiprocessing so I can't help to wonder.. anyone can estimate how many resources would it take to bruteforce the key in "any" amount of time, say months to years?

  • @Jona4s said:
    Im not an expert on encryption, but Im pretty good at massive multiprocessing so I can't help to wonder.. anyone can estimate how many resources would it take to bruteforce the key in "any" amount of time, say months to years?

    From what I know now, is that the key has a AES-256 private key algorithm. Some even paid the ransom. Some got a decrypter for the C-disk only. And the decrypter didn’t always work. Then the mail support stopped.

    I wouldn’t pay anything to these giant dicks.

    Thanked by 1netomx
  • jsgjsg Member, Resident Benchmarker
    edited July 2018

    @Jona4s said:
    Im not an expert on cryptography, but Im pretty good at massive multiprocessing so I can't help to wonder.. anyone can estimate how many resources would it take to bruteforce the key in "any" amount of time, say months to years?

    Half of 2 to the 128 times block size on average if you are lucky. Doing that though is FAR beyond what we could do in a life time if we used all computers on this planet (leaving aside the energy needed ...).

    Speaking practically, if we assume that each of the computers could do about 2 billion blocks per second (which they can't, not even close) we'd still need 2 to the 96 or roughly 10 to 30 such computers which would be about a billion billion billion thousand computers.

    Small reminder: Half of 2 to the 128 is NOT 2 to the 64 (which is just the root of 2 to the 128)

    And you bet that the criminals did use a good and solid AES implementation (aka library). In other words: Forget it!

    Edit:

    @DennisdeWit said:
    From what I know now, is that the key has a AES-256 private key algorithm.

    Then the necessary number of operations is the square of what I've just written and one would need a couple of gazillions of billions of computers for a brute force attack.

    About your only chance, as I said, is that some experts for whatever reason decide to analyze that malware successfully - and - also decide to create an easy to use practical utility out of their findings and publish that.

    I'm sorry but your father should have damn listened to your advice.

  • @Jona4s said:
    Im not an expert on cryptography, but Im pretty good at massive multiprocessing so I can't help to wonder.. anyone can estimate how many resources would it take to bruteforce the key in "any" amount of time, say months to years?

    256bit AES has 1.1x10^77 combinations. I came across the following:

    If you assume:
    Every person on the planet owns 10 computers.
    There are 7 billion people on the planet.
    Each of these computers can test 1 billion key combinations per second.
    On average, you can crack the key after testing 50% of the possibilities.

    Then the earth's population can crack one encryption key in 77,000,000,000,000,000,000,000,000 years!

  • @birchbeer said:

    @Jona4s said:
    Im not an expert on cryptography, but Im pretty good at massive multiprocessing so I can't help to wonder.. anyone can estimate how many resources would it take to bruteforce the key in "any" amount of time, say months to years?

    256bit AES has 1.1x10^77 combinations. I came across the following:

    If you assume:
    Every person on the planet owns 10 computers.
    There are 7 billion people on the planet.
    Each of these computers can test 1 billion key combinations per second.
    On average, you can crack the key after testing 50% of the possibilities.

    Then the earth's population can crack one encryption key in 77,000,000,000,000,000,000,000,000 years!

    Be aware though, that following Moore's law, even deep thought could've solved its 7.5 million year calculation in... 42 years.

    Thanked by 1Falzo
  • AnthonySmithAnthonySmith Member, Patron Provider

    birchbeer said: Then the earth's population can crack one encryption key in 77,000,000,000,000,000,000,000,000 years!

    So you are saying that there is a chance!

    Yep keep the drive, a few decryptors have been released years later so its always worth holding on to hope.

  • @AnthonySmith said:

    birchbeer said: Then the earth's population can crack one encryption key in 77,000,000,000,000,000,000,000,000 years!

    So you are saying that there is a chance!

    Yep keep the drive, a few decryptors have been released years later so its always worth holding on to hope.

    Yes - I should have said that too. You never know.

    Definitely keep the drive - it's usually not the AES symmetric key that needs to be discovered. The way that most ransomware works these days is to generate a random symmetric key for something like AES. That key is protected using an asymmetric cypto algo such as RSA. If the RSA (or asym) private key gets discovered, there is a chance that a decrypting tool can be created.

  • vmp32kvmp32k Member

    Jona4s said: anyone can estimate how many resources would it take to bruteforce the key in "any" amount of time, say months to years?

    I recently saw a really cool video about that question (in context of bitcoin but relevant to any 256bit cipher/hash):

    Thanked by 1dergelbe
  • Adam1Adam1 Member
    edited July 2018

    i realise they are criminals etc, but is paying the ransom out of the question? if it was $100 or an amount I could lose without worrying about it too much (Of course, they could just take the money and give you nothing, or waste your time with a failed decryptor), I'd consider paying if it means getting my data back and avoid potentially years of stress. so I'd consider the amount an expensive lesson and move on.

  • @Adam1 said:
    i realise they are criminals etc, but is paying the ransom out of the question? if it was $100 or an amount I could lose without worrying about it too much (Of course, they could just take the money and give you nothing, or waste your time with a failed decryptor), I'd consider paying if it means getting my data back and avoid potentially years of stress. so I'd consider the amount an expensive lesson and move on.

    Most times the price is way over $100 and it's not worth it because there's a slim chance you'll get the decryption key.

    Thanked by 1netomx
  • Adam1Adam1 Member

    Well, obviouly only you know how much you're prepared to pay (and potentially lose) to get your data back and maybe its possible to negotiate.

  • The ransom happens to be 1 BTC in this case, and I am not out of my mind enough to pay it.

    Thanked by 1netomx
  • jsgjsg Member, Resident Benchmarker
    edited July 2018

    @birchbeer said:
    ... it's usually not the AES symmetric key that needs to be discovered. The way that most ransomware works these days is to generate a random symmetric key for something like AES. That key is protected using an asymmetric cypto algo such as RSA. If the RSA (or asym) private key gets discovered, there is a chance that a decrypting tool can be created.

    Sorry, not to be picky but No.

    Asym. crypto is used to communicate the generated sym. key back to the kidnappers, typically along with a unique "id" or "fingerprint" for the victims system - and/or - it's involved in the sym. key generation. And that's about it.

    Asym. crypto is WAY TOO SLOW to be used for massive data encryption plus that would require way too much connections/traffic.

    The sym key usually is on the victims system albeit in encrypted and hidden form and other means are used too to keep it safe such as automorphing code, specialized small virtual machines and a bag of other tricks to thwart debugging and analysis.

    Do not underestimate the power of keeping some tiny but important routine/data in the processors cache because that thwarts even most hardware level analysis. And those algorithms exist. I use them myself (Side note: state size is a factor that is regrettably often ignored but very decisive in some cases).

    All in all and looking at the efforts needed and costs incurred to "circumvent" the kidnappers and to get ones data back without paying are almost certainly BY FAR HIGHER than the ransom asked. So in the end it comes down to a simple question: how much are your data worth to you?

    Plus there are simple prevention steps available like not having important data on a system used for general surfing, having/making backups, etc. My advice would be to pay up and to take it positively, as a price payed for learning an important lesson one carelessly ignored.

    That persons notebook might as well have been stolen or destroyed - in which case the data might be irretrievably lost. The given case of ransomware has a very ugly emotional component but looking rationally it's a malheur but one where relatively little money brings back the data. Pay and learn your lesson, simple as that.

  • @jsg said:

    Asym. crypto is used to communicate the generated sym. key back to the kidnappers, typically along with a unique "id" or "fingerprint" for the victims system - and/or - it's involved in the sym. key generation. And that's about it.

    Asym. crypto is WAY TOO SLOW to be used for massive data encryption plus that would require way too much connections/traffic.

    The sym key usually is on the victims system albeit in encrypted and hidden form and other means are used too to keep it safe such as automorphing code, specialized small virtual machines and a bag of other tricks to thwart debugging and analysis.

    Yes - I'm familiar with the differences of asym and sym algo's and their use-cases. What you saying is very interesting. I didn't realize that ransomware would try to communicate the sym key back to the attacker. I had always assumed that a different technique was being use and that the sym key would not be communicated back and was protected using an asym technique - that was the point that I was trying to make.

    I worked on botnet dns sinkholes and if the sym keys are being communicated back, that presumes that they could be using fastflux DNS as part of the communications. I've been out of that game for a few years but I wonder if anyone has sinkholed any of the Rapid variants. It could explain why I've read that some of the ransom payments for Rapid ransomware receive decryptors that don't work, it implies the attacker doesn't actually have the keys. Is my line of thinking accurate?

    Also - if you could share any links to academic papers or research on ransomware key protection, I would appreciate it. I didn't find anything that was substantially interesting.

  • jsgjsg Member, Resident Benchmarker
    edited July 2018

    @birchbeer

    Yes, DNS would be one way to communicate but the way of communication wasn't my focus. Another area I would look at if you are interested is to use SCTP and not TCP or UDP at all.

    One decisive point is that in your model (which actually is correct for some older malware) you need C&C machines with very good availability and/or an elaborate fallback scheme which not only messes things up and creates complexity but also creates a frequent flow of communication. Now if you look how many criminal operations have been uncovered, hampered, or broken up you'll see that C&C servers and those very communications flows are a preferred analysis and attack vector for LEA and related.

    So a trend started to keep things seperate. The infection phase is an independent operation from the ransomware operation which again (sometimes) is divided into a run phase and cashing in phase. In fact some smarter ransomwares do a one time run phase only and then stop (and sometimes delete themselves or the crypto material) rather than running until the victim pays and the encrypting his data stops.

    This sounds like just a small difference but it isn't. Looking closer you'll find that "running once or a short period of time" is a technically rather different mechanism than "running until deactivated".

    Now look at the criminals side. He gains a lot by giving up quite little. Both his risk phase and his risk level are much lower while at the same time the window for defense for the victim shrinks. Also both communication frequency and complexity decrease which (that's important) also allows much enhanced server changing/hopping for the criminal.

    It works about like this: (independant infection operation, sometimes even a bought service) - victim is infected, malware on first run creates and "installs" a unique payload (the actual disk encrypting engine). - The encrypting engine collects some system id relevant data and creates a kind of unique system id (usually a 256 or 512 bit hash) which it sends to the server. Additionally it sends some (freshly created) random string - based on those two items both sides can create the sym. key for disk encryption. - the C&C short term saves those until they are collected. The victim side adds an additional layer of obfuscation which can be very small, say a rol plus an xor with some random value (in reality it's more complex but for explanatory purposes that's good enough) and that random value - and NOT the sym key - is stored (typically in an obscured fashion too. Think e.g. "seed for a PRNG"). This goes on for a relatively short time until enough files are encrypted and then stops and maybe even deletes itself after running the final "your files have been encrypted, pay up!..." message.

    Advantage: Nothing to analyse because the ransomware or at least the sensitive parts are deleted; they aren't needed any more. Particularly evil specimen might install a changed version (or morph into that) basically just for show and distraction. Plus total seperation of operations, data, etc. The guys whom the victim pays in the end might be quite different from the guys who ran and controlled the encryption which again might be quite different from the guys who were in charge of the infection. In fact the guys payed by the victim might even have payed themselves to get at the unique id/sym key pairs (comparable in a way to people selling and buying debth). Plus your database is very small; it's just the unique id/sym. key pairs which on top of it by definition look like random data which translates to very much decreased risk. Good luck proving a crime there (on that side. Money transfer is another thing).

    The rather small price to pay for that is that your sym. key obfuscation is a somewhat weak point but that price is small as hardly any victim will identify, extract, and save the relevant bytes quickly enough. Plus, if done smartly that mechanism can be designed with high algorithmic flexibility so that even if one system were actually analyzed no general antidote could be derived.

    @birchbeer said:
    Also - if you could share any links to academic papers or research on ransomware key protection, I would appreciate it. I didn't find anything that was substantially interesting.

    Sorry, neither do I. Actual (interesting) academic papers seem to be hardly available and most of what the big names (Kaspersky, Sophos, etc) publish is largely marketing oriented "look how great we are!" BS. My knowledge is based only on my work (with lots of crypto and protocols) plus some experience and a hobby interest in how the guys on the other side of the fence work.

    Thanked by 1birchbeer
  • Wanted to chime in and say running a DNS like quad 9s plus something like PFBlockerNG with updated IP and URL lists might have prevented this.

    It's seamless once it's set up.

    Setting up PFSense w/ PFBlockerNG is def a PIA, at least from my experience. Be sure to block outgoing DNS requests so anyone on your network has to use your resolvers.

    It's not perfect, but I am convinced as long as the block lists are updated frequently, it's the least effort for max reward part of this equation.

  • @jsg
    Thanks for the dialogue. It's definitely an interesting topic. I have a little experience with botnets but not with ransomware.

    @jsg said:
    Yes, DNS would be one way to communicate but the way of communication wasn't my focus. Another area I would look at if you are interested is to use SCTP and not TCP or UDP at all.

    I probably should have clarified my comment about fastflux DNS. Many malware that create zombies in a botnet use a technique to protect the C&C by setting up lots of different C&C servers. The way that the zombies find the C&C is to use an algorithm that generates random domain names on a time based interval. What we do to break up botnets is to reverse-engineer the malware to uncover the seeds for the domain name generation algo. It's then a race to register those domains which effectively render large swaths of zoombie to be harmless. But I believe that malware that use p2p communications to the c&c however cannot be defeated with DNS sinkholes.

    @jsg said:
    So a trend started to keep things seperate. The infection phase is an independent operation from the ransomware operation which again (sometimes) is divided into a run phase and cashing in phase. In fact some smarter ransomwares do a one time run phase only and then stop (and sometimes delete themselves or the crypto material) rather than running until the victim pays and the encrypting his data stops.

    That's interesting to read. Makes sense. And I can attest to that. I was chatting with former colleagues a while ago who are still researching malware. They were describing malware samples that have evasion techniques that include self-deletion to avoid analysis. The malware would try to detect if it was being run in a cuckoo sandbox or VM and self-destruct.

  • jsgjsg Member, Resident Benchmarker
    edited July 2018

    @birchbeer said:
    @jsg
    Thanks for the dialogue.

    You are welcome. My pleasure.

    @jsg said:
    ... DNS ...

    I probably should have clarified my comment about fastflux DNS. Many malware that create zombies in a botnet use a technique to protect the C&C by setting up lots of different C&C servers. The way that the zombies find the C&C is to use an algorithm that generates random domain names on a time based interval. What we do to break up botnets is to reverse-engineer the malware to uncover the seeds for the domain name generation algo. It's then a race to register those domains which effectively render large swaths of zoombie to be harmless. But I believe that malware that use p2p communications to the c&c however cannot be defeated with DNS sinkholes.

    I see. I misunderstood you there. Frankly, I think that approach (by the bot netters) is quite primitive and has seriously weak points. Maybe an interesting sidenote: I'm often
    under the impression that the malware world is actually different worlds. A network centric world that is based on networking approaches and, much much smaller, the ITsec/crypto world which has a quite different approach. I also see that when looking at advise how to protect oneself.

    @jsg said:
    So a trend started to keep things seperate. ...

    That's interesting to read. Makes sense. And I can attest to that. I was chatting with former colleagues a while ago who are still researching malware. They were describing malware samples that have evasion techniques that include self-deletion to avoid analysis. The malware would try to detect if it was being run in a cuckoo sandbox or VM and self-destruct.

    I think that we techies are often too tech minded. It took me a while too to understand that those gangsters tick just like any other gangsters: Optimization of efforts/costs vs result and of course a very strong desire to reduce risk. That combination resulted in what I described above. In that regard crypto suddenly turns against us because their "treasure", e.g. unique system id/sym. key pairs look just like random so even if LEA got hold of those they'd be quite worthless in terms of evidence.

    A small closing remark in case you have some deeper interest in that matter: Micro VMs seem to be the trend and they can add very considerably to make it harder for the good guys (e.g. trying to analyze ransomware).

  • sinsin Member

    Sounds like my dad...I am constantly on him about the importance of backups and keeping his laptop secure and he never does any of it.

Sign In or Register to comment.