Am 16.05.2016 um 07:32 schrieb ToddAndMargo:> May I surmise that all the encrypted file now have > an extra extension of ".crypt"? So it is easy to > see who got clobbered.how do you come to that conclusion and even if some malware acts that way what makes you sure you can rely on that? IMHO it would only be so when the developer of the ransomware is a fool! why should he give you something to make a "locate .crypt" on the fileserver and backups easy? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20160516/f100dc48/signature.sig>
16.05.2016 14:38, Reindl Harald пишет:> > > Am 16.05.2016 um 07:32 schrieb ToddAndMargo: >> May I surmise that all the encrypted file now have >> an extra extension of ".crypt"? So it is easy to >> see who got clobbered. > > how do you come to that conclusion and even if some malware acts that > way what makes you sure you can rely on that? IMHO it would only be so > when the developer of the ransomware is a fool!By the way, could someone recommend best , or at least way this one really use, to detect that there was massive file encryption? Thank you!> > why should he give you something to make a "locate .crypt" on the > fileserver and backups easy? > > >
There is malware that names the files .crypt
A novel solution here
https://isc.sans.edu/diary/Novel+method+for+slowing+down+Locky+on+Samba+server+using+fail2ban/20805
though it seems locky specific
I use this non-samba solution in cron.hourly. Pretty awful, but it works for
malware that I know
about. I have fast drives, so updatedb only takes a few seconds.
#!/bin/sh
updatedb
wait 20
if locate DECRYPT > /tmp/cryptowall; then
mail -s "PANIC! Possible Server Cryptowall found" support at
domain.com</tmp/cryptowall
#else
# echo "not found";
fi
if locate --regex INSTRUCTIONS_\.\{3,10}\.png > /tmp/cryptowall1; then
mail -s "Possible Cryptowall 4.0 found on server" support at
domain.com </tmp/cryptowall1
fi
if locate HELP_YOUR_FILES > /tmp/cryptowall1; then
mail -s "Possible Crtptwall 4.0 found on server" support at
domain.com </tmp/cryptowall1
fi
if locate .locky > /tmp/cryptowall1; then
mail -s "Possible Locky crypto found on server" support at
domain.com </tmp/cryptowall1
fi
if locate .cerber > /tmp/cryptowall1; then
mail -s "Possible Cerber crypto found on server" support at
domain.com </tmp/cryptowall1
fi
if locate .crypt > /tmp/cryptowall1; then
mail -s "Possible CRYPTXXX crypto found on server" support at
domain.com </tmp/cryptowall1
fi
if locate _DECRYPT_INFO_ > /tmp/cryptowall1; then
mail -s "Possible Maktub crypto found on server" support at
domain.com </tmp/cryptowall1
fi
>Am 16.05.2016 um 07:32 schrieb ToddAndMargo: >>May I surmise that all the encrypted file now have >>an extra extension of ".crypt"? So it is easy to >>see who got clobbered. > >how do you come to that conclusion and even if some malware acts that way what makes you sure you can rely on that? IMHO it would only be so when the developer of the ransomware is a fool! > >why should he give you something to make a "locate .crypt" on the fileserver and backups easy?So far most of the ransomware rename the encrypted files and place files with instructions with constant names. They don't want to hide the fact that the files are encrypted. No, they want you to know that they are and that you have to pay to get them back. That's why it's called ransomware. Of course for people with backups this makes life a little easier. But for the others... https://www.reddit.com/r/sysadmin/comments/46361k/list_of_ransomware_extensions_and_known_ransom/ bye Fabi
Am 17.05.2016 um 09:47 schrieb Fabian Cenedese:> >> Am 16.05.2016 um 07:32 schrieb ToddAndMargo: >>> May I surmise that all the encrypted file now have >>> an extra extension of ".crypt"? So it is easy to >>> see who got clobbered. >> >> how do you come to that conclusion and even if some malware acts that way what makes you sure you can rely on that? IMHO it would only be so when the developer of the ransomware is a fool! >> >> why should he give you something to make a "locate .crypt" on the fileserver and backups easy? > > So far most of the ransomware rename the encrypted files and place files with > instructions with constant names. They don't want to hide the fact that the files > are encrypted. No, they want you to know that they are and that you have to > pay to get them back. That's why it's called ransomware. Of course for people > with backups this makes life a little easier. But for the others... > > https://www.reddit.com/r/sysadmin/comments/46361k/list_of_ransomware_extensions_and_known_ransom/"so far most" != you can rely on "They don't want to hide the fact that the files are encrypted. No, they want you to know that they are" *yes but* when they are finished an dnot right after starting to encrypt where not much files are affected and backups still in place what they *really* want is act in the background and get caught as late as possible when all your backups contain encrypted versions of important documents -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20160517/00e2c428/signature.sig>