W32.Ransomware.locky

  • 3 November 2016
  • 1 reply
  • 61 views

Not sure what went wrong. 
Workstation on network had a correctly identified threat during an unattended scan at the end of a business day. 
Next morning staff logged into the computer and locky successfully implimented payload across the network to all shares available to that account. Due to a good backup procedure disruption was minimal but I'm now concerned that web root failed to prevent the payload from being executed at the next log in. 

Suggestions ?

1 reply

Userlevel 3
I had an incident a while ago so among others here is what webroot team suggested me:
 
QUOTE
Please view the detailed guide below for best tips in the fight against ransomware/malware!

https:///webroot/attachments/webroot/ent2/993/1/Guide%20to%20Avoid%20Being%20C-R%20Victim_us.pdf.

Below is a summary of the guide above and contains extra information, which can help prevent ransomware and malware.

1. Use reputable and proven endpoint security.

2. Back-up your data.

Admins should have "air gap backups” in place -- offline storage that is never connected to the internet. This is highly advised for not only these types of infections, but as a good practice in general.

3. User Education.

Create a user education plan that includes tips for safe browsing, and what to look out for in spam emails.

4. Disable execution of script files.

Ransomware such as Locky (.odin), Nemucod (.crypted), and Cerber (.cerber3) are most often delivered via spam email. This spam email usually has an attachment with a zip archive containing either a script or a macro enabled office document, which is designed to download and execute the ransomware. In order to prevent these types of documents and scripts from running we recommend performing the following steps.

Step 1: Block WSF, VBS, WSH, HTA, VBS and JS files:

There are two options to prevent script files from running on a system.

Option 1: REDIRECT SCRIPT FILE EXTENSIONS VIA GPO

To enable this policy setting, access the system set up for policy control and navigate to the following setting:

User Configuration - Preferences - Control Panel - Settings then right click on Folder Options and Navigate to New > Open With .

Type in the each unwanted extension, i.e. wsf, js, vbs into the "File extension" box, then input the path of a program you want to have as default to open the file. Then tick “Set as default” and press “OK”.

Example of redirecting the extension "wsf" to notepad:

File extension: "wsf"
Associated Program: "C:Windowsotepad.exe"

We recommend redirecting the file types: .hta, .jse, .js, .vbs, .vbe, .wsf, .wsh.

If a system administrator needs to run a WSF, VBS, or JS file, they can still be run from the command line:

C:WindowsSystem32WSCRIPT.exe C:example.vbs

For startup scripts, the same principle applies, just make a call to WSCRIPT with the script as the argument.

Option 2: REDIRECT SCRIPT FILE EXTENSIONS VIA WEBROOT CONSOLE (RECOMMENDED)

If there is not a policy controller available, as an alternative, you can redirect file extensions with the utility below:

1) Sign into the Webroot Enterprise Console and click "Group Management".
2) Select the hostnames which you would like to have this applied to, and then navigate to "Agent Commands - Advanced - Download and execute a file".

Input the following link into the URL field:
https://download.webroot.com/NoScrypts.exe

For the "Command Line Options" field, the following commands can be used:

-disable - This command will redirect the default action for the following file types: .hta, .jse, .js, .vbs, .vbe, .wsf, .wsh, to open instead with notepad.

-enable - This command restores the default execution program for the file types mentioned above.

Option 3: DISABLE WSCRIPT HOST

If you would prefer to disable WSCRIPT Host entirely, you can perform the steps below.

To disable Windows Script Host, execute the following in an elevated command prompt:
REG ADD "HKLMSoftwareMicrosoftWindows Script HostSettings" /v Enabled /t REG_DWORD /d 0 /f

To re-enable Windows Script Host, execute the following instead:
REG ADD "HKLMSoftwareMicrosoftWindows Script HostSettings" /v Enabled /t REG_DWORD /d 1 /f

It is also recommended to create an email policy to block archive files (.zip, .jar, .tar, .7z, .msi, etc.) and executable/script files (.com, .exe, .scr, .bat, .js, .jse, .vb, .vbe, .wsf, .wsh, .cmd). These emails may contain an attached word document as well, with macros enabled. This macro can silently download and execute any infection of a criminal's choosing.

Step 2: Disable Macro execution.

To enable this policy setting, Run gpedit.msc and navigate to the following setting:

User configuration > Administrative templates > Microsoft Word 2016 > Word options > Security > Trust Center.

Double-click on Block macros from running in Office files from the Internet setting, Enable it.

Office 2013: https://technet.microsoft.com/en-us/library/ee857085.aspx

5. Patch and keep software up to date.

Ransomware such as: CryptMic (.crypmic), CryptXXX, and Locky (.odin) can be distributed via exploit kits, which target the software vulnerabilities of Adobe Flash Player, Oracle Java, Internet Explorer, Microsoft Silverlight and other vulnerable applications. If this software is exploited, an exploit kit landing page can execute arbitrary code and initiate a silent drive by download. It is critical for system administrators to keep this type of software up to date as most infections dropped by Exploit Kits are known as "zero days" (malware which is fully undetected by all antivirus). If outdated software must be present in your environment, we recommend you download and install Microsoft's EMET to mitigate attacks:

https://www.microsoft.com/en-us/download/details.aspx?id=50766

6. Secure weak username/passwords which have Remote Desktop access.

Increase password complexity requirements for users which use RDP. Some variants of ransomware are deployed via compromised RDP credentials because the credentials are weak and easily guessable by a brute force attack. We also advise changing the default port from 3389 for remote desktop, to a different port.

Regards,
Webroot Advanced Malware Removal Team
UNQUOTE
 
I strongly suggest step #4(option 2) and #5 (if EMET is not preferable maybe try "Malwarebytes Anti-Exploit") from the above.
 
Furthermore, in my case I made sure that all browsers on all endpoints have installed some kind of adblocking addon and I also suggest to install CryptoPrevent (by Foolish).
Optionally you may also install "Malwarebytes Anti-Ransomware" and "BitDefender AntiRansomware".
Last but not least, you may consider using a sandbox software like Sandboxie for opening internet browsers and email attachments and forget all of the above (or do all of them for extra protection).

Reply