Replies

We had this infect a PC and a network share at my work recently. Luckily the user that got infected let us know right away, and we were able to quarantine the PC and restore the network share from back (also before anyone else clicked on anything in that share to further spread it).

At home - If you are running 7 or 8, and your profile has 'Admin' privelages, create another admin account that you won't actively use and then demote your current user account to 'Standard'.

You can further restrict what applications you can run by enabling Parental Controls and creating an application 'white list', so that the O/S will only allow specific .exes (or other executables) to run. This makes it virtually impossible for a payload to execute the ransomware (or any virus for that matter).

From the MS website.

Open Parental Controls by clicking the Start button Picture of the Start button, clicking Control Panel, and then, under User Accounts and Family Safety, clicking Set up parental controls for any user.‌ Administrator permission required If you're prompted for an administrator password or confirmation, type the password or provide confirmation.

Click the name of the person you want to prevent from using specific programs.

Under Parental Controls, click On, enforce current settings.

Click Block specific programs.

Click Person's name‌ can only use the programs I allow. Select the programs that you want to allow. If the program you want doesn't appear in the list, click Browse to locate the program.

Mine is a slightly different task - I am a service tech, primarily for Residential and SOHO users. Since there isn't the 'benefit' of a locked-down client/server oriented LAN, exposure is quite a bit higher. In my line of work, infections are inevitable (think teenagers). So while security is primary, the secondary or fallback position is to make certain that backups are available. Since many of my users are never going to do anything even as complicated as writing a CD, and since data stores have become gigantic (far too big for regular manual backup, even if they were so-inclined), I have relied heavily upon multiple chains of automated backup to provide reliable backup sets in case of electronic disaster (which, in your average teenage infested household, or party-oriented young adult, is a matter of 'when' not 'if'...).

So to me, the problem here is not the infection, which can be considered as inevitable, but rather, how to preserve those backups which, because of their necessary automation, are highly susceptible not only to the bug encrypting the files in backup, but are equally susceptible to good files in backup being overwritten by encrypted files from the live data (if a backup routine initiates before I am notified, or before I can get there). It's a whompin' big problem.