Thanks for the infos. I summarise in this case: * 20 000+ files to be recovered with this kind of tool would mean a very heavy work load and delay, so fresh backups are still far away the best solution (if available). * If the attack would have not been stopped very quickly (would have started a Friday evening, as example), this tool couldn't possibly be used to restore the 200+ million files. * The lost of the exact file name, path and user rights means, for such a professional installation, the lost of the data, as the exact file names and path are mandatory for several critical business applications that are to be used all the time by the 70 staff. * As the restored file integrity is not guaranteed, the situation of the victim is still not comfortable (how to check each file data correctness in such a large case ?). * This tool would require the interruption of the share availability during the data restoration process. Thanks the backup and the restoration by a small bash script, the staff was still able to work during the restore period. So off-line regular full backups are definitely the best solution. This tool is certainly useful for restoring some important files (and good to know), but I don't see it as a solution against those ransom-wares, especially in large scale professional installations... On the infected (so Windows) computer, I have no idea how it behaved, as the system has been switched off, promptly fully formatted and re-installed. But as this not the first version of this ransom-ware, I'm pretty sure it takes care to override the original file, as much as it could. On the Samba server, a VFS stackable Samba module was used on some (selected) shares, and there, the original files have been found in the recycle directory after the attack. Unfortunately, those files were _also_ encrypted ! Le 15.12.2015 09:49, Alain Knaff a écrit : > On 15/12/15 09:40, Brent Frère wrote: >> Thanks for the trick. >> >> In a corporate case, the server is usually heavily working, and so >> re-allocating the hard-disk space frequently. > It also depends on how full it is. It is my understanding, that on a > less full disk, it may still take a while until the space is > re-allocated (but obviously this varies depending on which filesystem is > used...) > >> In this case, there are about 200 millions files on-line, 70 users and >> several tens of TB involved. >> The attack managed to encrypt more than 20 000 files before it was >> stopped (half an hour or so). >> Some of the files were founded back in trashes, but not all (far from >> that) as such a "recycle bin" feature was not enabled on all the shares. >> I don't know the default behaviour of Windows servers, but the server is >> here a Samba on Linux, due to the need of compatibility, stability, >> availability and scalability. >> The file system is probably not compatible with your tool. > Errrm.... "his" tool is "photorec", a filesystem-independant tool that > looks for signatures of various file types, and from there just works on > the assumption that most files are stored contiguously (which is > generally true today, if the disk is not too filled up, and especially > on Linux filesystems). As such, the tool is totally file-system > independant, and recovers a large amount of files. The only disadvantage > is that file *names* are lost (for these, it would need to be filesystem > aware) > >> Is there a "recycle-bin" feature activated by default on Windows servers ? > > ... and the next version will surely rewrite files in place, rather than > doing a copy+delete :-) > >> How to restore thousands of files from this situation ? Does you tool >> automatise this ? Are the file names, paths and the access rights >> correctly restored in all the cases ? > With photorec, no. It just gives the files generic names, only the > extension is meaningful. Same for permissions: these will be generic as > well. So, after photorec, there's still a lot of work to do to sift > through all the recovered files, to find those that are meaningful. > > However, in some cases, there may be metadata in the files themselves > (such as dates in EXIF headers of photos), which may help with that task. > >> It's just a question, for me to know. >> >> At least with a full daily backup, we managed to restore the 20 000+ >> files in half an hour, *thanks a small minute-maid bash script*. >> >> Thanks for your info anyway. > Regards, > > Alain > > >> Le 11.12.2015 13:31, Micha Lippert a écrit : >>> Hello, >>> >>> someone in my family managed to get infected by such a ransomware. >>> The files are encrypted, and the originals are deleted. These deleted >>> files may be recovered with a bit of luck. >>> I just used my favourite forensic tool (photorec) and managed to >>> salvage a large percentage of his files. >>> >>> So if you encounter this problem: Don't panic. Shut down the machine. >>> Google about forensic tools. >>> But granted, backups are a better alternative, as long as they are >>> offline during the attack... >>> >>> best regards, >>> Micha >>> >>> >>> >>> 2015-12-04 18:17 GMT+01:00 Brent Frère &lt;Brent.Frere(a)abilit.eu >>> <mailto:Brent.Frere@abilit.eu>>: >>> >>> Vous avez peut-être lu récemment des articles dans la presse >>> luxembourgeoise concernant les "rançonwares". >>> >>> http://www.guichet.public.lu/citoyens/fr/actualites/2015/02/09-ransomware/i… >>> >>> *Il y a actuellement une vague des ce type d'attaques sur le >>> Luxembourg.* >>> >>> Ces attaques sont *très efficaces et très sérieuses*. Elles >>> s'introduisent via des e-mails contenant des pièces-jointes >>> contenant le logiciel malveillant, écrit en Java, souvent sous >>> forme d'archive ZIP. >>> Elles traverses tout type de firewall et la plupart des systèmes >>> de filtrage des e-mails (antispam/antivirus). >>> Il suffit que l'utilisateur ouvre ce logiciel (clique sur la pièce >>> jointe) pour que _TOUS LES FICHIERS ACCESSIBLES_ par cet >>> utilisateur, même sur les serveurs de l'entreprise, se retrouvent >>> cryptés et donc inutilisables. >>> La seule solution, ensuite, est de payer la rançon réclamée par >>> les voleurs (donc leur donner votre numéro de carte de crédit et >>> le cryptogramme... ???) ou de récupérer vos fichiers dans un >>> backup, à condition qu'il soit à jour. >>> >>> Bien sûr, ces attaques ne fonctionnent pas sur le système le plus >>> utilisé dans le monde et sur Internet (Linux, sous ses diverses >>> formes et noms, dont Android), mais profitent des faiblesses >>> (encore et toujours) des logiciels propriétaires bien connus: >>> Windows (toutes versions), la version Java de Oracle, Outlook, etc... >>> >>> Si vous êtes (encore) utilisateurs de ces logiciels totalement >>> perméables par nature (probablement par choix de leurs éditeurs si >>> ce n'est du fait de leur incompétence), _veillez d'urgence_ à ce >>> que vos backups soient à jour et inaccessibles par les ordinateurs >>> tournant ce genre de système d'exploitation. >>> >>> De nombreuses attaches effectives et réussies ont eu lieu, y >>> compris auprès de certains de nos clients. Si vous ne prenez pas >>> les précautions élémentaires d'urgence, vous n'aurez plus, en >>> quelques heures, que le genre de message suivant en remplacement >>> de *_toutes les données de votre entreprise_*. >>>> >>>> ++++++==============================================================================================================+++++++======- >>>> >>>> What happened to your files ? >>>> All of your files were protected by a strong encryption with >>>> RSA-2048. >>>> More information about the encryption keys using RSA-2048 can be >>>> found >>>> here:http://en.wikipedia.org/wiki/RSA_(cryptosystem) >>>> <http://en.wikipedia.org/wiki/RSA_%28cryptosystem%29> >>>> >>>> What does this mean ? >>>> This means that the structure and data within your files have been >>>> irrevocably changed, you will not be able to work with them, read >>>> them >>>> or see them, >>>> it is the same thing as losing them forever, but with our help, >>>> you can >>>> restore them. >>>> >>>> How did this happen ? >>>> Especially for you, on our server was generated the secret key pair >>>> RSA-2048 - public and private. >>>> All your files were encrypted with the public key, which has been >>>> transferred to your computer via the Internet. >>>> >>>> ++++++==============================================================================================================+++++++====== >>>> >>>> Decrypting of your files is only possible with the help of the >>>> private >>>> key and decrypt program, which is on our secret server. >>>> >>>> What do I do ? >>>> So, there are two ways you can choose: wait for a miracle and get >>>> your >>>> price doubled, or start obtaining BTC NOW, and restore your data >>>> easy way. >>>> If You have really valuable data, you better not waste your time, >>>> because there is no other way to get your files, except make a >>>> payment. >>>> >>>> For more specific instructions, please visit your personal home >>>> page, >>>> there are a few different addresses pointing to your page below: >>>> 1.http://alcov44uvcwkrend.paybtc798.com/96EF1674B48EED9A >>>> 2.http://alcov44uvcwkrend.btcpay435.com/96EF1674B48EED9A >>>> 3.https://alcov44uvcwkrend.onion.to/96EF1674B48EED9A >>>> If for some reasons the addresses are not available, follow >>>> these steps: >>>> 1. Download and install tor-browser: >>>> http://www.torproject.org/projects/torbrowser.html.en >>>> 2. After a successful installation, run the browser and wait for >>>> initialization. >>>> 3. Type in the address bar: alcov44uvcwkrend.onion/96EF1674B48EED9A >>>> 4. Follow the instructions on the site. >>>> >>>> IMPORTANT INFORMATION: >>>> Your personal pages: >>>> http://alcov44uvcwkrend.paybtc798.com/96EF1674B48EED9A >>>> http://alcov44uvcwkrend.btcpay435.com/96EF1674B48EED9A >>>> https://alcov44uvcwkrend.onion.to/96EF1674B48EED9A Your >>>> personal page (using TOR-Browser): >>>> alcov44uvcwkrend.onion/96EF1674B48EED9A >>>> Your personal identification number (if you open the site (or >>>> TOR-Browser's) directly): 96EF1674B48EED9A >>>> >>>> ++++++==============================================================================================================+++++++====== >>>> >>> Si vous pensez que vos backups peuvent ne pas être parfaitement à >>> jour, veuillez nous contacter _d'urgence_. >>> Cette attaque fonctionne très très bien et il n'y a pas de moyen >>> de récupérer vos données une fois l'attaque en cours. >>> >>> Vous avez été averti... >>> >>> _______________________________________________ >>> Lilux-info mailing list >>> Lilux-info(a)lilux.lu <mailto:Lilux-info@lilux.lu> >>> https://www.lilux.lu/mailman/listinfo/lilux-info >>> >>> >> >> >> _______________________________________________ >> Lilux-info mailing list >> Lilux-info(a)lilux.lu >> https://www.lilux.lu/mailman/listinfo/lilux-info >> > _______________________________________________ > Lilux-info mailing list > Lilux-info(a)lilux.lu > https://www.lilux.lu/mailman/listinfo/lilux-info _______________________________________________ Lilux-info mailing list Lilux-info(a)lilux.lu https://www.lilux.lu/mailman/listinfo/lilux-info