3 ms·

Nice example! As I was saying in the blog post, doing so would potentially increase chance of discovery, hence sub-optimal from the malware author perspective.

by iou 10y ago

Nice example! As I was saying in the blog post, doing so would potentially increase chance of discovery, hence sub-optimal from the malware author perspective. In the case of ransomeware, you'd assume you'd want the encryption to be idempotent. Otherwise how would you be able to offer decryption and thereby profit?

wongarsu 10y ago
>In the case of ransomeware, you'd assume you'd want the encryption to be idempotent. Ransomware could just add a magic string into encrypted files, so any subsequent infection can check if the files are already encrypted. Of course that increases discovery chance but it doesn't matter: if the computer was already infected discovery doesn't matter anymore, the ransomware likely revealed itself already; if the computer isn't infected already then you have to read those files anyway to encrypt them.
- iou 10y ago
  Ah, the immunisation-Matryoshka-doll-possibilities are endless :D So in this scenario where they add a magic string: 1) Would this magic string be constant? 2) Would this magic string be from some generative algorithm 3) Could this magic string be random? See the similarities between the original scenario and this one? I guess if they were sincerely hardcore they could use a MAC on the exposed "magic string", though to do that correctly, they'd need to embed that within the actual encrypted payload, otherwise they'd be subject to the same immunisation attack of just prepending a valid, MAC'd magic-string to files when they were requested through a file handler API. Or they could use something like AES-GCM or some other authenticated encryption, though they'd have to run the decryption algorithm on every file to obtain the AAD)
geofft 10y ago
Make it extremely infrequent, so the expected probability of re-infection is about once a week. For instance, have a 1-in-7-times-24 chance, and re-run every hour. This way you don't rely on local state, so there's no local state for AV to corrupt. When a victim pays, provide them all of the keys - a paying victim probably won't wait multiple weeks, so in the common case it should just be one or two keys. Storing these keys shouldn't be too much load on your servers, and ransomware doesn't really need to care about integrity protection, so there's no inflation of file size from repeated encryptions.

by iou 10y ago

wongarsu 10y ago

>In the case of ransomeware, you'd assume you'd want the encryption to be idempotent. Ransomware could just add a magic string into encrypted files, so any subsequent infection can check if the files are already encrypted. Of course that increases discovery chance but it doesn't matter: if the computer was already infected discovery doesn't matter anymore, the ransomware likely revealed itself already; if the computer isn't infected already then you have to read those files anyway to encrypt them.

iou 10y ago
Ah, the immunisation-Matryoshka-doll-possibilities are endless :D So in this scenario where they add a magic string: 1) Would this magic string be constant? 2) Would this magic string be from some generative algorithm 3) Could this magic string be random? See the similarities between the original scenario and this one? I guess if they were sincerely hardcore they could use a MAC on the exposed "magic string", though to do that correctly, they'd need to embed that within the actual encrypted payload, otherwise they'd be subject to the same immunisation attack of just prepending a valid, MAC'd magic-string to files when they were requested through a file handler API. Or they could use something like AES-GCM or some other authenticated encryption, though they'd have to run the decryption algorithm on every file to obtain the AAD)

geofft 10y ago

Make it extremely infrequent, so the expected probability of re-infection is about once a week. For instance, have a 1-in-7-times-24 chance, and re-run every hour. This way you don't rely on local state, so there's no local state for AV to corrupt. When a victim pays, provide them all of the keys - a paying victim probably won't wait multiple weeks, so in the common case it should just be one or two keys. Storing these keys shouldn't be too much load on your servers, and ransomware doesn't really need to care about integrity protection, so there's no inflation of file size from repeated encryptions.