How to protect Windows networks from ransomware attacks

Honda’s Customer Service and Financial Services were apparently hit by a ransomware attack recently. Kaspersky found samples in the VirusTotal database that make it appear that the company was targeted by the Snake ransomware. This incident made me think about what we can learn from how Honda was targeted to better protect Windows networks from ransomware attacks.

Kaspersky indicated that the malware was launched using a file called nmon.bat. Calling a malicious file with the .bat extension means that alert tools would see that a scriptable or batch file was used in the network. In many environments this would be an allowed file.

The attackers used a file named KB3020369.exe in the attack. This is interesting since the Microsoft Knowledgebase number 3020369 is for a Windows 7 servicing stack patch. However, the file name of the actual patch is not KB3020369.exe, but Windows6.1-KB3020369-x64.msu. The attackers named malicious files in a pattern to “hide in plain sight” from the technology professionals.

The Snake ransomware removes Volume Shadow Copies from infected systems and then kills processes including those related to virtual machines, industrial control systems, remote management tools, and network management software. The attack sequence was built to resolve domains inside the Honda domain, as third-party researchers noted in an analysis of the attack. This indicates the attackers targeted the Honda network.

Attackers go after weak spots—people. They then hide in networks until they are ready to spring upon us, sometimes for months. That doesn’t include the time that attackers take to do reconnaissance on network infrastructure.

Using the Honda ransomware as a guide, here’s how you can better protect Windows networks:

Watch out for unauthorized tools, scripts and Group Policy settings

Kaspersky suggests that that a scheduled task was used to launch some of the attacks. You can watch for unauthorized activities like this in your event logs. Follow these steps for native Windows event log reviewing:

1. Run eventvwr.msc.
2. Go to “Windows logs.”
3. Right-click on “Security logs” and then on “Properties”.
4. Ensure that “Enable logging” is selected.
5. Increase the log size to at least 1 GB.
6. Look for event 4698 event ID to find the latest scheduled task.

As noted in a Netwrix blog, you can set up a PowerShell task to send an email notification when a new scheduled task is created and run. You may need a third-party SMTP service such as smtp2go.com to set up alerts. You can use other methods to set up notifications or see if your auditing software provides such a built in service.

Identify employees at high risk for targeted phishing attacks

A nice, juicy custom email to a key user – especially a domain administrator – can provide an attacker a way to get inside a network. More work from home means greater use of remote-access technology. Credentials rather than vulnerabilities in the operating system are the low hanging fruit of 2020.

Review your licenses and tools that you provide to key employees. You can mix and match Microsoft 365 licenses within your firm so that not everyone needs to use the same license or the same level of protections. Review the need for Microsoft 365 E5 licenses that include Advanced Threat Protection (ATP). This service recently included UEFI malware detector in machines with ATP enabled. As Microsoft recently noted, “The new UEFI scanner reads the firmware file system at runtime by interacting with the motherboard chipset.” Microsoft Defender ATP also provides the admin with an actionable list of actions to take:

Susan Bradley

Review Group Policy domain and script folders for malicious files

Attacks are often launched from the very locations that administrators use to manage the network. Take the time to validate the files you keep and the script locations. Review for any new files added to folders used for administration. Review for proper permissions on folders to ensure only authorized users can add or adjust these management scripts.

Use multi-factor authentication for privileged accounts

Most importantly, ensure that domain administrators have multi-factor authentication (MFA) enabled whenever remote access is needed. Also enable MFA for Microsoft 365 accounts. Review what accounts are used in your network and where you use them.

Review your backup strategies.

Having a good backup that you can recover from helps ensure you can respond to ransomware without paying the ransom. Have regular automatic backups and make sure they are protected. The user account that does the backup process should not be the same as the user who logs in. Finally, have an offline backup process in your rotation so that media is taken offsite or offline, preventing attackers from deleting backup files. I cannot stress this enough: Having a backup is very much key to recovery from a ransomware attack.