Ransomware Best Practices

Refer to the following best practices to help you manage the risk posed by ransomware and support your organization’s coordinated and efficient response to a ransomware incident. Apply these practices to the greatest extent possible based on availability of organizational resources.

It is critical to maintain offline, encrypted backups of data and to regularly test your backups. Backup procedures should be conducted on a regular basis. It is important that backups be maintained offline as many ransomware variants attempt to find and delete any accessible backups. Maintaining offline, current backups is most critical because there is no need to pay a ransom for data that is readily accessible to your organization.

• Maintain regularly updated “gold images” of critical systems in the event they need to be rebuilt. This entails maintaining image “templates” that include a pre-configured operating system (OS) and associated software applications. These can be quickly deployed to rebuild a system, such as a virtual machine or server.
• Retain backup hardware to rebuild systems in the event rebuilding the primary system is not preferred. Hardware that is newer or older than the primary system can present installation or compatibility hurdles when rebuilding from images.
• In addition to system images, applicable Source Code or Executables should be available (stored with backups, Escrowed, license agreement to obtain, etc.). It is more efficient to rebuild from system images, but some images will not install on different hardware or platforms correctly; having separate access to needed software will help in these cases.

Create, maintain, and exercise a basic Cyber Incident Response Plan and associated communications plan that includes response and notification procedures for a ransomware incident. Review available incident response guidance, a resource and guide to:

• Help your organization better organize around Cyber Incident Response, and
• Develop a Cyber Incident Response Plan.

• Conduct regular vulnerability scanning to identify and address vulnerabilities, especially those on internet-facing devices, to limit the attack surface.
• CISA offers a no-cost Vulnerability Scanning service and other no-cost assessments: https://www.cisa.gov/cyber-resource-hub.
• Regularly patch and update software and OS’s to the latest available versions.
• Prioritize timely patching of internet-facing servers, as well as software processing internet data, such as web browsers, browser plugins, and document readers, for known vulnerabilities.
• Ensure devices are properly configured and that security features are enabled. For example, disable ports and protocols that are not being used for a business purpose (e.g., Remote Desktop Protocol [RDP], Transmission Control Protocol [TCP] Port 3389).
• Employ best practices for use of RDP and other remote desktop services. Threat actors often gain initial access to a network through exposed and poorly secured remote services, and later propagate ransomware.
• Audit the network for systems using RDP, close unused RDP ports, enforce account lockouts after a specified number of attempts, apply multi-factor authentication (MFA), and log RDP login attempts.
• Disable or block Server Message Block (SMB) protocol outbound and remove or disable outdated versions of SMB. Threat actors use SMB to propagate malware across organizations. Based on this specific threat, organizations should consider the following actions to protect their networks:
• Disable SMBv1 and v2 on your internal network after working to mitigate any existing dependencies (on the part of existing systems or applications) that may break when disabled. Remove dependencies through upgrades and reconfiguration: Upgrade to SMBv3 (or most current version) along with SMB signing.
• Block all versions of SMB from being accessible externally to your network by blocking TCP port 445 with related protocols on User Datagram Protocol ports 137 to 138 and TCP port 139.

• Implement a cybersecurity user awareness and training program that includes guidance on how to identify and report suspicious activity (e.g., phishing) or incidents. Conduct organization-wide phishing tests to gauge user awareness and reinforce the importance of identifying potentially malicious emails.
• Implement filters at the email gateway to filter out emails with known malicious indicators, such as known malicious subject lines, and block suspicious Internet Protocol (IP) addresses at the firewall.
• To lower the chance of spoofed or modified emails from valid domains, implement Domain-based Message Authentication, Reporting and Conformance (DMARC) policy and verification. DMARC builds on the widely deployed sender policy framework and Domain Keys Identified Mail protocols, adding a reporting function that allows senders and receivers to improve and monitor protection of the domain from fraudulent email.
• Consider disabling macro scripts for Microsoft Office files transmitted via email. These macros can be used to deliver ransomware.

Ensure antivirus and anti-malware software and signatures are up to date. Additionally, turn on automatic updates for both solutions. We recommend using a centrally managed antivirus solution. This enables detection of both “precursor” malware and ransomware.

• A ransomware infection may be evidence of a previous, unresolved network compromise. For example, many ransomware infections are the result of existing malware infections, such as TrickBot, Dridex, or Emotet.
• In some cases, ransomware deployment is just the last step in a network compromise and is dropped as a way to obfuscate previous post-compromise activities.
• Use application directory allow listing on all assets to ensure that only authorized software can run, and all unauthorized software is blocked from executing.
• Enable application directory allow listing through Microsoft Software Restriction Policy or AppLocker.
• Use directory allow listing rather than attempting to list every possible permutation of applications in a network environment. Safe defaults allow applications to run from PROGRAM FILES, PROGRAM FILES (X86), and SYSTEM32. Disallow all other locations unless an exception is granted.
• Consider implementing an intrusion detection system (IDS) to detect command and control activity and other potentially malicious network activity that occurs prior to ransomware deployment.

• Take into consideration the risk management and cyber hygiene practices of third parties or managed service providers (MSPs) your organization relies on to meet its mission. MSPs have been an infection vector for ransomware impacting client organizations.
• If a third party or MSP is responsible for maintaining and securing your organization’s backups, ensure they are following the applicable best practices outlined above. Using contract language to formalize your security requirements is a best practice.
• Understand that adversaries may exploit the trusted relationships your organization has with third parties and MSPs.
• Adversaries may target MSPs with the goal of compromising MSP client organizations; they may use MSP network connections and access to client organizations as a key vector to propagate malware and ransomware.
• Adversaries may spoof the identity of, or use compromised email accounts associated with, entities your organization has a trusted relationship with in order to phish your users, enabling network compromise and disclosure of information.

• Employ MFA for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems.
• If you are using passwords, use strong passwords and do not reuse passwords for multiple accounts. Change default passwords. Enforce account lockouts after a specified number of login attempts. Password managers can help you develop and manage secure passwords.
• Apply the principle of least privilege to all systems and services so that users only have the access they need to perform their jobs. Threat actors often seek out privileged accounts to leverage to help saturate networks with ransomware.
• Restrict user permissions to install and run software applications.
• Limit the ability of a local administrator account to log in from a local interactive session (e.g., “Deny access to this computer from the network.”) and prevent access via an RDP session.
• Remove unnecessary accounts and groups and restrict root access.
• Control and limit local administration.
• Make use of the Protected Users Active Directory group in Windows domains to further secure privileged user accounts against pass-the-hash attacks
• Audit user accounts regularly, particularly Remote Monitoring and Management accounts that are publicly accessible; this includes audits of third-party access given to MSPs.
• Leverage best practices and enable security settings in association with CIS Benchmarks.

• Develop and regularly update a comprehensive network diagram that describes systems and data flows within your organization’s network. This is useful in steady state and can help incident responders understand where to focus their efforts.
• The diagram should include depictions of covered major networks, any specific IP addressing schemes, and the general network topology (including network connections, inter-dependencies, and access granted to third parties or MSPs).
• Employ logical or physical means of network segmentation to separate various business unit or departmental IT resources within your organization as well as to maintain separation between IT and operational technology.
• Ensure your organization has a comprehensive asset management approach.
• Understand and inventory your organization’s IT assets, both logical (e.g., data, software) and physical (e.g., hardware).
• Understand which data or systems are most critical for health and safety, revenue generation, or other critical services, as well as any associated inter-dependencies (i.e., “critical asset or system list”). This will aid your organization in determining restoration priorities should an incident occur. Apply more comprehensive security controls or safeguards to critical assets. This requires organization-wide coordination.

Not every control in this post applies to every SaaS company. Much of the hardening guidance targets Windows domains: SMB, RDP, PowerShell logging, AppLocker and Active Directory groups.

If your company is cloud-native, runs on managed Linux containers and issues macOS laptops, those sections are not your priority. Your ransomware exposure sits in cloud consoles, CI/CD pipelines, SaaS admin accounts and object storage, and the relevant controls are MFA on every privileged identity, immutable or versioned backups of production data stores, restricted service account permissions and monitoring of API keys. Gold images matter less when infrastructure is rebuilt from code, but only if the code repository is backed up outside the primary cloud account.

If an MSP manages your endpoints, do not duplicate their tooling; get their coverage in writing and test a backup restore yourself. And a small team does not need a 40-page incident response plan. One page naming who isolates systems, who calls counsel and who decides on payment, tested once a year, beats a long document nobody has read.

• Restrict usage of PowerShell, using Group Policy, to specific users on a case-by-case basis. Typically, only those users or administrators who manage the network or Windows OSs should be permitted to use PowerShell. Update PowerShell and enable enhanced logging. PowerShell is a cross-platform, command-line, shell and scripting language that is a component of Microsoft Windows. Threat actors use PowerShell to deploy ransomware and hide their malicious activities.
• Update PowerShell instances to version 5.0 or later and uninstall all earlier PowerShell versions. Logs from PowerShell prior to version 5.0 are either non-existent or do not record enough detail to aid in enterprise monitoring and incident response activities. PowerShell logs contain valuable data, including historical OS and registry interaction and possible tactics, techniques, and procedures of a threat actor’s PowerShell use.
• Ensure PowerShell instances (use most current version) have module, script block, and transcription logging enabled (enhanced logging).
• The two logs that record PowerShell activity are the “PowerShell” Windows Event Log and the “PowerShell Operational” Log. We recommend turning on these two Windows Event Logs with a retention period of 180 days. These logs should be checked on a regular basis to confirm whether the log data has been deleted or logging has been turned off. Set the storage size permitted for both logs to as large as possible.

Get more Ransomware Protection Tips!