+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: Ransomware (/thread-8012.html)
Pages:
1
2
Ransomware - galeforce9 - 12-13-2018
Hello,
I don't know if anyone can help but we got hit with Ransomware over the weekend. This has taken out a number of servers and client PC's totalling about 25 hard drives. They have used Diskcryptor to encrypt the all our drives (including all backups, NAS etc).
What we know so far is that the passwords used were only numeric and vary in length from 8 digits to 11 digits. This means that hashcat will be able to find the codes. However our one stumbling block is we do not know how to find the hash from the encrypted drives. We also know they used version 1.1.846.118 of diskencryptor which was the last released in 2014. The source files for this are available on the website.
Any help appreciated as we feel this is the only way forward to retrieve our data and with our rough calcs even an 11 digit number should crack in under 3 days.
Thank you
Ian
RE: Ransomware - Mem5 - 12-13-2018
We may better help you if we know the encryption algorithm used by the ransoware?
RE: Ransomware - philsmd - 12-13-2018
First of all, this is of course not the usual use case for hashcat.
Furthermore, Diskcryptor is probably a legit software just misused by the malware, it's not malware but can be used to encrypt files/disks, I guess.
Therefore, I think you should be more specific on what malware is used. What's the name of the malware ? I guess there are many malicious executables that use DiskCrypto, like those Mamba-like ransomware.
How do you know that the password is "only" 8 to 11 digits long ? My guess is that DiskCryptor accept much longer and complex passwords too. So this must be a limitation by the malicous software itself (not DiskCryptor). How sure are you that it's only numbers of length 8, 9, 10 or 11 ? Are there some resources online about the details of this specific malware that (after reverse engineering) came to the conclusion that there is that hard-coded 9-11 number limit?
I also think that there is probably a password based key derivation function used to generate a key for the encryption algorithm, that means that it could in theory be "similar" to already supported "hash modes" like luks/truecrypt/veracrypt etc. Of course the algorithms could be different, I didn't look into the DiskCrypto source yet.
BTW: I guess you already considered recovering from backups or paying the ransome (I'm not really recommending it but since I heard most users are quite happy with the ransomeware author's support and would recommend paying it - at least for other malware -, some affected users - of other malware - even mentioned that they even got some very good deals/discount after chatting with the support or even some official government sites recommending to pay since it's the only way to get the files back - again for other maybe even more sophisticated malware -
)I don't know how you did your "rough calcs", to do this you would need all the details and know how fast modern GPUs can deal with that specific algorithm... what are the details/facts on what you base your 3-day estimate (again, I didn't look into the details of DiskCryptor yet) ?
RE: Ransomware - galeforce9 - 12-13-2018
Hello
I am no expert on this but the information i believe you require is as follows:
Cipher - AES
encryption mode - XTS
Pkcs5.2 prf: - HMAC-SHA-512
Thanks for the reply
Ian
RE: Ransomware - philsmd - 12-13-2018
I had a glance at this page: https://diskcryptor.net/wiki/Volume
and the source here https://github.com/smartinm/diskcryptor
it seems that the algo for key derivation from the password is PBKDF2-HMAC-SHA512 ($pass, $salt, 1000)
- https://github.com/smartinm/diskcryptor/blob/a47ad40d2752894bdf9c7954c3e4fbcef62b68b0/driver/enc_dec.c#L676
- https://github.com/smartinm/diskcryptor/blob/a47ad40d2752894bdf9c7954c3e4fbcef62b68b0/driver/crypto_head.c#L70-L71
where 1000 is the hard-coded iteration round and salt is stored within the first 64 bytes of the partition/volume (not encrypted see the typedef struct _dc_header and "Salt. Random number used when deriving volume header key. " and "Encryption No" on this page https://diskcryptor.net/wiki/Volume)
This means that you could in theory derive the key and "only" check for the "DCRP" signature in the decrypted header (and if needed the crc32 checksum of the remaining decrypted bytes of the header if you get too many false positives with just the DCRP check).
RE: Ransomware - Xanadrel - 12-14-2018
(12-13-2018, 07:07 PM)galeforce9 Wrote: They have used Diskcryptor to encrypt the all our drives (including all backups, NAS etc).
They got physical access to the hardware or something ? How could they also encrypt ALL backups ?
RE: Ransomware - galeforce9 - 12-14-2018
Hello,
Thank you for the replies. I'll provide as much information as I can so you can understand this is legitimate.
On arriving at work Monday morning and putting monitor screens on we were greeted with a ransomware message on the screens. Further checking revealed how severe this was. We had a number of actual servers and some VM's as well as a number of clients kept switched on for access.
Backups went firstly to a file servers which was also duplicated. Each server had its own backup drive and also backed up to a synology NAS box. They used Diskcryptor to encrypt all the drives on the network including all the server backup drives. The only drive they could not encrypt was the synology which was attached to AD. They used there gained network credentials to access the NAS delete the volume, then recreate the volume then factory default the drive which is how we found it. We know this because Synology remoted into the drive and recovered it from the factory default state and we then recovered the log file.
The perpetrators were in touch via a secure email and to prove who they were offered a few keys. These were for just OS based drives so they knew it what not really benefit us. The keys given were between 8 and 11 digits. I do not have a name for this attack the nearest is "Mamba" although this attack varied to mamba in they actually used Diskcryptor on each PC as was not wrapped in their own tools but as was mentioned you would expect a script to generate the passwords although we have been unable to locate one so far. We will know more if we can access the drives hopefully.
The information given is very helpful. I can use DD to extract any parts of the disk but any help in formatting the correct hashcat command to attempt to brute force this would be appreciated.
Thank you
Ian
RE: Ransomware - philsmd - 12-14-2018
Well, if it wasn't really clear yet, this specific algorithm is not supported yet by hashcat since you can't really extract a hash, but need to generate the AES-XTS keys on-the-fly and verify the decryption on-the-fly to check the crc32 checksum (or just the "DCRP" sequence of bytes if you allow some/several false positives).
It's not the most difficult kernel to implement, because most of the stuff should be already in hashcat (like the AES decryption and PBKDF2-HMAC-SHA512 hashing (in your case the AES key generation)).
It could make sense to implement just the bare minimum for you (like the -a 3 = mask attack OpenCL kernel, well it will be a so-called "slow" kernel anywasys with init/loop/comp kernel functions
) and that might be feasible and cost/time effective.It would also make sense to provide and/or generate some examplles.
I think the correct password and the first 2048 bytes of the volume (i.e. the encrypted volume header including the very important 64 bytes of salt see https://diskcryptor.net/wiki/Volume) should be enough to at least come up with a POC verify script.
It's needless to say that you should of course make backups of the data you want to recover and make sure there is no further attack vectors (disconnect everything from the networks) that the attackers could use to make it even worse (maybe contacting a data recovery (forensic) company or a professional security company should be considered too, before you make even *more?* mistakes).
RE: Ransomware - galeforce9 - 12-14-2018
Hello,
Thank you again for the reply. Yes we are imaging the drives currently and they have not been used so we will have the data, just encrypted.
There are other things happening so I am having to be careful to some degree as to what I say. However steps have been taken to prevent further attacks.
We have 4 verified keys, I don't know if this is much of an advantage in this case.
If anyone knows of someone who could take this further to enable decryption asap this would be appreciated. I believe the forum has PM so please just message.
Thank you
Ian
RE: Ransomware - Banaanhangwagen - 12-14-2018
Did you also check https://www.nomoreransom.org/ ; they have a couple of solutions; maybe you're lucky