Determine files that were encrypted by ransomware (cryptolocker, cryptowall, etc.)

[mfecteau]

Here's a "solution" to determine which files were encrypted by the cryptolocker or cryptowall ransomware.  I'm posting it here because it's done in the autoit language.  And I know many people on the web were asking for a solution about this.

You must have access to a backup copy of your files to use this, it won't decrypt your files.

It is useful in an enterprise environment where you have a lot of users accessing a file server with a lot of files.  Without this, it is difficult to know where the encrypted files are located.  Some files are encrypted and other aren't and there's no way of knowing witch one except by manually trying to open the file.

This script will locate those files (and list them), and optionally restore them from your backup.

Update : I forgot to mention that the source is included.  The only binary is the lz4.exe compression command that you could grab somewhere else if suspicious.  Also, the misleading title was changed.

cryptocheck.zip

Edited September 3, 2014 by mfecteau

[computergroove]

I think that posting the source is a more smiled upon solution for a post here. At lease its less suspicious.

[MikahS]

Example scripts go in the example scripts section of the forum

Edited September 2, 2014 by MikahS

[iamtheky]

With user permissions and filecopy you should restore roughly 0 files on a ransomware infected box.  The only way a file backup is useful is to restore it onto a fresh load.  And restoring a backup is not a solution to anything, it is what you do when none of your solutions worked.

[JLogan3o13]

@computergroove, while it is an older thread, this still holds true. There is no requirement for anyone to share source. If there is an issue with trust, the Mods will make the determination.

[Jos]

To be more specific: The files does contain the script sources and an some lz4.exe file so the whole comment is totally unclear, but that is happening regularly.

Jos

[mfecteau]

With user permissions and filecopy you should restore roughly 0 files on a ransomware infected box.  The only way a file backup is useful is to restore it onto a fresh load.  And restoring a backup is not a solution to anything, it is what you do when none of your solutions worked.

 

Indeed, there's no solution against the cryptolocker/cryptowall ransomware.  We must restore from backup.  Or money could be given to those crooks, but that's not a solution for us.  The subject of the thread is in fact misleading, my fault.  It should have been something as :  "solution to determine files encrypted by ransomware ...".

I insist on the fact that this script won't be useful to a lot of people, only to enterprise admins that manage big file servers (with daily backup) who need to locate the encrypted files (to determine which users or departments were affected by the ransomware outbreak).

I indeed included the sources except the compression command is compiled (if suspicious, grab it somewhere else).  I chose lz4 because it's 10 times faster than zip. 

Finally, I know that I'm not the best programmer on the planet (far from it), so bear with me.

[JohnOne]

If the title is misleading then edit it with full editor.

[iamtheky]

I still dont understand how you are going to perform actions on a file to which you do not even have the most basic of read rights.   And if you have the backup why not just diff the whole structure and mark all the directories where acls have changed?

[mfecteau]

I still dont understand how you are going to perform actions on a file to which you do not even have the most basic of read rights.   And if you have the backup why not just diff the whole structure and mark all the directories where acls have changed?

 

The script must run with local admintrator account on the file server (so full rights on all files without UAC interference). I used it and it works.

Apparently, cryptowall doesn't change the ACL (ownership),it only changes the last modification date.  And without auditing enabled on file server, we don't know who made the last modification (Windows doesn't keep track of this out of the box). 

You're right, other ways surely exist to do something similar as this script.  I didn't test it, but surely a graphical tool like winmerge could be used to do a diff based on something else than the compression ratio.  But I didn't find a free tool that did a diff comparing the compression ratio as my script is doing. 

[iamtheky]

The second piece is a bit on how CryptoLocker functions: since it uses the logged in user account to encrypt files, and since it is literally replacing the files with encrypted copies, the newly encrypted files are being created by the logged in user.  This means that, no matter who owned them before, the logged in user will become the file owner. 

 

 

http://www.poshcodebear.com/blog/2014/5/2/function-to-aid-in-finding-cryptolocker-encrypted-files

 

The elevated tokens available to you will not gain full any rights on a cryptolocker protected file (that i have seen).  What variant did you use this on?

Edited September 3, 2014 by boththose

[mfecteau]

http://www.poshcodebear.com/blog/2014/5/2/function-to-aid-in-finding-cryptolocker-encrypted-files

 

The elevated tokens available to you will not gain full any rights on a cryptolocker protected file (that i have seen).  What variant did you use this on?

 

The variant is cryptowall.  We saw that the encrypted files didn't change ownership, the files were only modified. Also, the NTFS ACL were not changed (NTFS inheritance was still applied).  So the files were "readable" (NTFS-wise), but encrypted.

Thanks for the link, that was a good read.

[iamtheky]

ive reading to do on cryptowall then.  we couldnt even copy the files in a windows session with cryptolocker, so that is why i have so many questions as to how you are getting them into the container to even test.

[mfecteau]

ive reading to do on cryptowall then.  we couldnt even copy the files in a windows session with cryptolocker, so that is why i have so many questions as to how you are getting them into the container to even test.

 

With the local administrator account (or admin privileges), you should be able to get full NTFS rights recursively on a folder with a tool like "setACL.exe" (or you could also get it done through the Windows GUI).  If you cannot, maybe it's because your file server was itself infected with the ransomware and it has done something nasty to your Windows installation preventing you changing the NTFS permissions (though I'm only speculating).  On my side, the file server was not itself infected.  It's the client machines that were infected and the those clients encrypted files on the file server from a network share that was mapped as a drive letter on the clients. 

[Rais]

An article about cryptowall - http://soft2secure.com/knowledgebase/cryptowall

[Pumpkin_30]

On 23.10.2014 at 5:53 PM, Rais said:

An article about cryptowall - http://soft2secure.com/knowledgebase/cryptowall

Thanks for the link!