white paper

Ransomware Protection and

Containment Strategies
Practical Guidance for Endpoint Protection,
Hardening and Containment
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 2

Table of Contents
Overview....................................................................................................................................................3

Endpoint Hardening..............................................................................................................................4

Endpoint Segmentation...............................................................................................................4
RDP Hardening................................................................................................................................ 7
Disable Administrative / Hidden Shares................................................................................9
Disable SMB v1................................................................................................................................ 11
Hardening Windows Remote Management (WinRM).................................................... 14

Credential Exposure and Usage Hardening............................................................................. 16

Remote Usage of Local Accounts.......................................................................................... 16

Reduce the Exposure of Privileged and Service Accounts.......................................... 18
Cleartext Password Protections............................................................................................. 20

Conclusion.............................................................................................................................................. 22
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 3

Overview
Ransomware is a common method of cyber extortion or disruption for financial
gain. This type of attack can instantly disrupt access to files, applications or
systems until the victim pays the ransom (and the attacker restores access
with a decryption key) or the organization restores and reconstitutes from
backups. Once ransomware is invoked within an organization, most variants
utilize privileged accounts and trust relationships between systems for lateral
dispersion.

Ransomware is commonly deployed across an environment in two ways:

1. Manual propagation by a threat actor after they have penetrated an

environment and have administrator-level privileges broadly across the
environment:
• Manually run encryptors on targeted systems.

• Deploy encryptors across the environment using Windows batch files (mount
C$ shares, copy the encryptor, and execute it with the Microsoft PsExec tool).
• Deploy encryptors with Microsoft Group Policy Objects (GPOs).

• Deploy encryptors with existing software deployment tools utilized by the

victim organization.

2. Automated propagation:
• Credential or Windows token extraction from disk or memory.

• Trust relationships between systems — and leveraging methods such as

Windows Management Instrumentation (WMI), SMB, or PsExec to bind to
systems and execute payloads.
• Unpatched exploitation methods (e.g., EternalBlue — addressed via
Microsoft Security Bulletin MS17-010).1

The purpose of this document is to provide practical endpoint security controls

and enforcement measures which can limit the capability for a ransomware or
malware variant to impact a large scope of systems within an environment. If
there is an active outbreak, depending upon the propagation method that the
variant is leveraging, implementing many of the recommendations within this
document can potentially disrupt and contain the event.

While the scope of recommendations contained within this document are

not all encompassing, they represent the most practical controls for endpoint
containment and protection from a ransomware outbreak. If implemented
proactively, the scope of controls outlined within this document can protect
an organization from being impacted by a ransomware event that disrupts
operations and impacts a large scope of systems.

1 Microsoft (March 14, 2017). Microsoft Security Bulletin MS17-010 - Critical.

WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 4

Endpoint Hardening
Endpoint Segmentation

Tactic: Lateral dispersion amongst systems using standard Windows Operating System protocols

Windows Firewall
During a ransomware event, many variants utilize privileged and trusted accounts to bind to systems within an environment.
Commonly, Server Message Block (SMB) is utilized for the communication channel between systems. While SMB is
typically required within a Windows operating environment (e.g., workstation to Domain Controllers or File Servers), the
scope of SMB communications permitted directly between systems can be restricted and minimized (e.g., workstation-to-
workstation).

During a ransomware event, a Windows Firewall policy can be configured to restrict the scope of communications
permitted between common endpoints within an environment. This firewall policy can be enforced locally or centrally
via Group Policy. At a minimum, the common ports and protocols that should be blocked between workstation-to-
workstation—and workstations to non-Domain Controllers and non-File Servers include:

• SMB (TCP/445, TCP/135, TCP/139)

• Remote Desktop Protocol (TCP/3389)

• Windows Remote Management / Remote PowerShell (TCP/80, TCP/5985, TCP/5986)

• WMI (dynamic port range assigned through DCOM)

Using Group Policy, the settings listed in Table 1 can be configured for the Windows Firewall to restrict inbound
communications for endpoints in a managed environment.

Group Policy Setting Path:

• Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security

Table 1. Windows Firewall recommended configuration state.

Profile Firewall Inbound Log Dropped Log Successful Log File Maximum
Log File Path
Setting State Connections Packets Connections Size (KB)

Block all connections

%systemroot%\system32\LogFiles\
Domain On that do not match a Yes Yes 4,096
Firewall\pfirewall.log
preconfigured rule

Block All %systemroot%\system32\LogFiles\

Private On Yes Yes 4,096
Connections Firewall\pfirewall.log

Block All %systemroot%\system32\LogFiles\

Public On Yes Yes 4,096
Connections Firewall\pfirewall.log
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 5

Figure 1.
Windows Firewall
recommended
configurations.

Additionally, to ensure that only centrally managed firewall rules are enforced during a containment event (and cannot be
overridden by a nefarious actor), the settings for “Apply local firewall rules” and “Apply local connection security rules”
can be set to “No” for all profiles.

Figure 2.
Windows Firewall
domain profile
customized
settings.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 6

To quickly contain and isolate systems, the centralized Windows Firewall setting of “Block all connections” (Fig. 3)
will prevent any inbound connections from being established to a system. This is a setting that can be enforced on
workstations and laptops - but will likely impact operations if enforced for servers; although if ransomware is spreading
throughout an environment, it may be a necessary step for quick containment.

Note: Once the event has been contained and deemed “safe” to re-establish connectivity amongst systems within an environment, via
Group Policy, the “Inbound Connections” setting can be changed back to “Allow” if necessary.

Figure 3.
Windows
Firewall - “Block
all connections”
settings.

The protocols and ports listed in Table 2 represent the most common avenues for lateral movement and propagation. If
blocking all inbound connectivity for common endpoints is not practical for containment, at a minimum, the protocols and
ports listed in Table 2 should be considered for blocking using the Windows Firewall.

For any specific applications that may require inbound connectivity to end-user endpoints, the local firewall policy
should be configured with specific IP address exceptions for origination systems that are authorized to initiate inbound
connections to such devices.

Table 2. Windows Firewall suggested block rules.

Protocol / Port Windows Firewall Rule Command Line Enforcement

SMB Predefined Rule: netsh advfirewall firewall set rule

• File and Print Sharing group=”File and Printer Sharing” new
TCP/445, TCP/139, TCP/135 enable=no

Remote Desktop Protocol Predefined Rule: netsh advfirewall firewall set rule
• Remote Desktop group=”Remote Desktop” new enable=no
TCP/3389

WMI Predefined Rule: netsh advfirewall firewall set rule

• Windows Management Instrumentation (WMI) group=”windows management instrumentation
(wmi)” new enable=no

Windows Remote Management / Predefined Rule: netsh advfirewall firewall set rule
PowerShell Remoting • Windows Remote Management group=”Windows Remote Management” new
• Windows Remote Management (Compatibility) enable=no
TCP/80, TCP/5985, TCP/5986
Port Rule:
• 5986 Via PowerShell:
Disable-PSRemoting -Force
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 7

Figure 4.
Windows Firewall
suggested rule
blocks via Group
Policy.

RDP Hardening Enforce Multi-Factor Authentication

Remote Desktop Protocol (RDP) is a common method If external-facing RDP must be utilized for operational
used by malicious actors to remotely connect to systems, purposes, multi-factor authentication should be enforced
laterally move from the perimeter onto a larger scope of for connectivity. This can be accomplished either via the
systems, and deploy malware. External-facing systems integration of a third-party multi-factor authentication
with RDP open to the Internet have elevated risk. technology or by leveraging a Remote Desktop Gateway
Malicious actors may exploit RDP to gain initial access and Azure Multi-Factor Authentication Server using
into an organization, perform lateral movement, invoke RADIUS.2
ransomware, and potentially access and steal data.
Leverage Network Level Authentication
Proactively, organizations should scan their public IP For external-facing RDP servers, Network Level
address ranges to identify systems with RDP (TCP/3389) Authentication (NLA) provides an extra layer of pre-
and other protocols (SMB – TCP/445) open to the authentication before a connection is established. NLA
Internet. At a minimum, RDP and SMB should not be is also useful for protecting against brute force attacks,
directly exposed for ingress and egress access to/from which often target open internet-facing RDP servers.
the Internet. If required for operational purposes, explicit
controls should be implemented to restrict the source IP NLA can be configured either via the User Interface (UI)
addresses which can interface with systems using these (Fig. 5) or via Group Policy (Fig. 6).
protocols.

2 Microsoft (July 10, 2018). Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 8

Figure 5.
Enabling NLA
via the UI.

Using Group Policy, the setting for NLA can be enabled via:

• Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote
Desktop Session Host > Security > Require user authentication for remote connections by using Network Level Authentication

Figure 6.
Enabling NLA via
Group Policy.

Some caveats about leveraging NLA for RDP: • On the RDP server, users permitted for remote access
using RDP must be assigned the “Access this computer
• The Remote Desktop client v7.0 (or greater) must be from the network” privilege when NLA is enforced. This
leveraged. privilege is often explicitly denied for user accounts to
• NLA utilizes CredSSP to pass authentication requests protect against lateral movement techniques.
from the initiating system. CredSSP stores credentials
in LSA memory on the initiating system—and these
credentials may remain in memory even after a user logs
off from the system. This provides a potential exposure
risk for credentials in memory on the source system.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 9

Restrict Administrative Accounts from Leveraging RDP on Internet-Facing Systems

For external-facing RDP servers, highly-privileged domain and local administrative accounts should not be permitted
access to interface with the servers using RDP (Fig. 7).

This can be enforced using Group Policy, configurable via the following setting:

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment >
Deny log

Figure 7.
Group Policy
configuration
for restricting
highly privileged
domain and local
administrative
accounts from
leveraging RDP.

Disable Administrative / Hidden Shares

Tactic: Lateral dispersion amongst systems via binding to

administrative shares for tool or malware deployment

Some ransomware variants will attempt to identify Common administrative and hidden shares on endpoints
administrative or hidden network shares, including include:
those that are not explicitly mapped to a drive letter -
and use these for binding to endpoints throughout an • ADMIN$
environment. As a containment step, an organization • C$
may need to quickly disable default administrative or
• D$
hidden shares from being accessible on endpoints. This
can be accomplished by either modifying the registry, • IPC$
stopping a service, or by using the “Microsoft Security
Note: Disabling administrative and hidden shares on servers,
Guide” Group Policy template from the Microsoft
specifically Domain Controllers, may significantly impact the
Security Compliance Toolkit.3 operation and functionality of systems within a domain-based
environment.

Additionally, if PsExec is utilized in an environment, disabling

the admin (ADMIN$) share can restrict the capability for this
tool to be utilized to remotely interface with endpoints.

3 See https://www.microsoft.com/en-us/download/details.aspx?id=55319
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 10

Registry Method:
Using the registry, administrative and hidden shares can be disabled on endpoints (Fig. 8 and Fig. 9).

Workstations:

Figure 8.
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry value DWORD Name = “AutoShareWks”
for disabling
administrative Value = “0”
shares on
workstations.

Servers:

Figure 9.
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry value DWORD Name = “AutoShareServer”
for disabling
administrative Value = “0”
shares on servers.

Service Method:
By stopping the “Server” service on an endpoint, the ability to access any shares hosted on the endpoint will be
disabled (Fig. 10).

Figure 10.
“Server” Service
Properties.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 11

Group Policy Method:

Using the “MSS (Legacy)” Group Policy template, administrative and hidden shares can be disabled on either a server or
workstation using Group Policy settings (Fig. 11).

• Computer Configuration > Policies > Administrative Templates > MSS (Legacy) > MSS (AutoShareServer)

• Computer Configuration > Policies > Administrative Templates > MSS (Legacy) > MSS (AutoShareWks)

Figure 11. Disabling administrative and hidden shares via the “MSS (Legacy)” Group Policy template.

Disable SMB v1

Tactic: Lateral dispersion amongst systems via vulnerability exploitation or

legacy protocol abuse

In addition to patching for known vulnerabilities impacting common protocols (e.g., SMB)4, disabling SMB v1 on
endpoints can reduce the mass propagation methods used by specific ransomware variants.

SMB v1 can be disabled on Windows 7 and Windows Server 2008 R2 (and above) using either PowerShell (Fig. 12), a
registry modification, or by using the “Microsoft Security Guide” Group Policy template from the Microsoft Security
Compliance Toolkit.5

PowerShell Method:

Figure 12. Set-SmbServerConfiguration -EnableSMB1Protocol $false

PowerShell
command to
disable SMB v1.

Registry Method:
Using the registry, SMB v1 can be disabled on endpoints (Fig. 13 and Fig. 14).

Disable SMBv1 Server:

Figure 13.
Registry key and HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
value for disabling
Registry entry: SMB1
SMB v1 server
(listener). REG_DWORD = “0” (Disabled)

4 Microsoft (October 10, 2017). Microsoft Security Bulletin MS17-010 - Critical.

5 See https://www.microsoft.com/en-us/download/details.aspx?id=55319
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 12

Disable SMBv1 Client:

Figure 14.
Registry key and HKLM\SYSTEM\CurrentControlSet\services\mrxsmb10
value for disabling Registry entry: Start
SMB v1 client.
REG_DWORD = “4” (Disabled)

HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation
Registry entry: DependOnService
REG_MULTI_SZ: “Bowser”,“MRxSmb20”,“NSI”

Group Policy Method:

Using the “Microsoft Security Guide” Group Policy template, SMB v1 can be disabled using the settings noted below.

• Computer Configuration > Policies > Administrative Templates > MS Security Guide > Configure SMB v1 Server

Figure 15. Disabling SMB v1 server via the “MS Security Guide” Group Policy template.

• Computer Configuration > Policies > Administrative Templates > MS Security Guide > Configure SMB v1 Client Driver

–– Enabled

• Configure MrxSMB10 driver

–– Disable driver

Figure 16. Disabling SMB v1 client driver via the “MS Security Guide” Group Policy template.

Figure 17.
Disabling SMB v1
client driver via
the “MS Security
Guide” Group
Policy template –
additional setting.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 13

• Computer Configuration > Policies > Administrative Templates > MS Security Guide > Configure SMB v1 Client (extra
setting needed for pre-Win8.1/2012R2)
–– Enabled

• Configure LanmanWorkstation Dependencies

–– Bowser

–– MrxSMB20

–– NSI

Figure 18. Disabling SMB v1 client extra settings via the “MS Security Guide” Group Policy template.

Figure 19.
Disabling SMB v1
client driver via
the “MS Security
Guide” Group
Policy template—
additional settings
ensuring that the
“MRxSmb10” option
is not present.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 14

Hardening Windows Remote Management (WinRM)

Tactic: Lateral dispersion between systems via Windows Remote Management (WinRM)
and PowerShell remoting

Manual operators may leverage Windows Remote If WinRM has ever been enabled on a client (non-server)
Management (WinRM) to propagate ransomware operating system, then the following configurations will
throughout an environment. WinRM is enabled by exist on an endpoint, and will not be remediated solely
default on all Windows Server operating systems (since through the PowerShell command noted in Figure 20.
Windows Server 2012 and above), but disabled on all client
operating systems (Windows 7 and Windows 10) and older • WinRM listener configured
server platforms (Windows Server 2008 R2). • Windows Firewall exception configured

PowerShell Remoting (PS Remoting) is a native Windows These items will need to be disabled manually through the
remote command execution feature that’s built on top of commands in Figure 23 and Figure 24.
the WinRM protocol.

PowerShell:
Figure 20.
PowerShell Disable-PSRemoting -Force
Command to
disable WinRM /
PowerShell
Note: Disabling PowerShell Remoting does not prevent local users from creating PowerShell sessions
Remoting on an
on the local computer - or for sessions destined for remote computers.
endpoint.

After running the command, the message recorded in Figure 21 will be displayed.

Figure 21. Warning message after disabling PSRemoting.

WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 15

Figures 22-25 show how to enforce the additional steps for disabling WinRM via PowerShell.

Stop and disable the WinRM Service.

Figure 22.
PowerShell Stop-Service WinRM -PassThruSet-Service WinRM -StartupType Disabled
command to stop
and disable the
WinRM Service.

Disable the listener that accepts requests on any IP address.

Figure 23.
PowerShell dir wsman:\localhost\listener
commands to Remove-Item -Path WSMan:\Localhost\listener\<Listener name>
delete a WSMAN
listener.

Disable the firewall exceptions for WS-Management communications.

Figure 24.
PowerShell Set-NetFirewallRule -DisplayName ‘Windows Remote Management (HTTP-In)’
command to -Enabled False
disable firewall
exceptions for
WinRM.

Restore the value of the LocalAccountTokenFilterPolicy to “0” (zero), which enforces

Figure 25. UAC token filtering (admin approval mode) for the built-in administrator (RID 500)
PowerShell account.
command to
configure the
Set-ItemProperty -Path
registry key for
LocalAccount HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system -Name
TokenFilterPolicy. LocalAccountTokenFilterPolicy -Value 0

Group Policy Method:

• Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote
Management (WinRM) > WinRM Service > Allow remote server management through WinRM
If the above Group Policy setting is configured as “Disabled”, the WinRM service will not respond to requests from a
remote computer, regardless of whether or not any WinRM listeners are configured.

• Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Shell >
Allow Remote Shell Access
This Group Policy setting will manage the configuration of remote access for all supported shells to execute scripts and
commands.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 16

Credential Exposure and

Usage Hardening
Remote Usage of Local Accounts
Step 1 – Option 1: S-1-5-114 SID
Tactic: Lateral movement and propagation To mitigate the usage of local administrative accounts from
using the built-in local administrator being used for lateral movement, utilize the SID
account on endpoints “S-1-5-114: NT AUTHORITY\Local account and member of
Administrators group” within the following settings:
Local accounts that exist on endpoints are often a
common avenue leveraged by attackers to laterally move • Computer Configuration > Policies > Windows Settings >
throughout an environment. This tactic is especially Security Settings > Local Policies > User Rights Assignment
impactful when the password for the built-in local –– Deny access to this computer from the network
administrator account is configured to the same value (SeDenyNetworkLogonRight)
across multiple endpoints.
–– Deny log on as a batch job (SeDenyBatchLogonRight)
To mitigate the impact of local accounts being leveraged –– Deny log on as a service (SeDenyServiceLogonRight)
for lateral movement, Microsoft Security Advisory
–– Deny log on through Terminal Services
KB28719976 introduced two (2) well-known SIDs that can
be leveraged within Group Policy settings to restrict the (SeDenyRemoteInteractiveLogonRight)
usage of local accounts for lateral movement. –– Debug Programs (SeDebugPrivilege)—permission used
for attempted privilege escalation and process injection
• S-1-5-113: NT AUTHORITY\Local account

• S-1-5-114: NT AUTHORITY\Local account and member

Step 1 – Option 2: UAC Token-Filtering
of Administrators group An additional control that can be enforced via Group Policy
settings pertains to the usage of local accounts for remote
Specifically, the SID “S-1-5-114: NT AUTHORITY\Local administration and connectivity during a network logon. If
account and member of Administrators group” is added the full scope of permissions (referenced in Option 1 above)
to an account’s access token if the local account is a cannot be implemented in a short timeframe, consider
member of the BUILTIN\Administrators group. This is the applying the UAC token-filtering method to local accounts
most beneficial SID to stop an attacker (or ransomware for network-based logons.
variant) that propagates using credentials for any local
administrative accounts. These configurations can be enforced via the previously
mentioned “Microsoft Security Guide” Group Policy
Note: For SID “S-1-5-114: NT AUTHORITY\Local account and template from the Microsoft Security Compliance Toolkit.7
member of Administrators group”, if Failover Clustering is
utilized, this feature should leverage a non-administrative local Group Policy Setting:
account (CLIUSR) for cluster node management. If this account
• Computer Configuration > Policies > Administrative
is a member of the local Administrators group on an endpoint
that is part of a cluster, blocking the network logon permissions Templates > MS Security Guide > Apply UAC restrictions
can cause cluster services to fail. Be cautious and thoroughly to local accounts on network logons
test this configuration on servers where Failover Clustering is
utilized.

6 Microsoft (May 13, 2014). Microsoft Security Advisory: Update to improve credentials protection and management; May 13, 2014.
7 See https://www.microsoft.com/en-us/download/details.aspx?id=55319
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 17

Once enabled, the registry value (Fig. 26) will be configured on each endpoint:

Figure 26.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
Registry key and LocalAccountTokenFilterPolicy
value for enabling
UAC restrictions REG_DWORD = “0” (Enabled)
for local accounts.

When set to “0”, remote connections with high integrity access tokens are only possible using either the plaintext
credential or password hash of the RID 500 local administrator, dependent upon on the setting of
“FilterAdministratorToken.”

The “FilterAdministratorToken” setting can either enable (1) or disable (0) (default) “Admin Approval” mode for the RID
500 local administrator. When enabled, the access token for the RID 500 local administrator account is filtered and
therefore User Account Control (UAC) is enforced for this account (which can ultimately stop attempts to leverage this
account for lateral movement across endpoints).

Group Policy Setting:

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > User
Account Control: Admin Approval Mode for the built-in Administrator account

Once enabled, the registry value (Fig. 27) will be configured on each endpoint:

Figure 27.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
Registry key and FilterAdministratorToken
value for requiring
admin approval REG_DWORD = “1” (Enabled)
mode for local
administrative
accounts.

Note: It’s also prudent to ensure that the default setting for “User Account Control: Run all administrators in Admin Approval Mode”
(“EnableLUA” option) is not changed from Enabled (Default) to Disabled. If this setting is disabled, all UAC policies are also disabled.
With this setting disabled, it is possible to perform privileged remote authentication using plaintext credentials or password hashes
with any local account that is a member of the local administrators group.

Group Policy Setting:

• Computer Configuration > Policies > Administrative Templates > MS Security Guide > User Account Control: Run all
administrators in Admin Approval Mode
Once enabled, the registry value (Fig. 28) will be configured on each endpoint. This is the default setting.

Figure 28.
Registry key and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA
value for enabling REG_DWORD = “1” (Enabled)
UAC restrictions
for local accounts.

UAC access token filtering will not affect any domain accounts in the local Administrators group on an endpoint.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 18

Step 2: LAPS
Once the usage of local accounts has been blocked for remote authentication and access to remote endpoints, an
organization must align a strategy to enforce password randomization for the built-in local administrator account. For
many organizations, the easiest way to accomplish this task is by deploying and leveraging Microsoft Local Administrator
Password Solutions (LAPS).8

Reduce the Exposure of Privileged and Service Accounts

Tactic: Lateral movement and propagation using domain-based accounts

Privileged Account Logon Restrictions

For ransomware to be deployed throughout an environment, privileged and service accounts credentials are commonly
utilized for lateral movement and mass propagation. Until a thorough investigation has been completed, it may be difficult
to determine the specific credentials that are being utilized by a ransomware variant for connectivity to a large scope of
systems within an environment.

For any accounts that have privileged access throughout an environment, the accounts should not be utilized on standard
workstations and laptops, but rather from designated systems (e.g., Privileged Access Workstations (PAWS)) that reside
in restricted and protected VLANs and Tiers. Explicit privileged accounts should be defined for each Tier,
and only utilized within the designated Tier.

The recommendations for restricting the scope of access for privileged accounts is based upon Microsoft’s guidance for
securing privileged access.9

As a quick containment measure, consider

blocking any accounts with privileged
access from being able to login (remotely
Figure 29.
or locally) to standard workstations,
laptops, and common access servers Example of Privileged Account access restrictions for a standard
workstation using Group Policy settings.
(e.g., virtualized desktop infrastructure).

The settings referenced below are

configurable via the Group Policy path of:

• Computer Configuration > Policies >

Windows Settings > Security Settings >
Local Policies > User Rights Assignment

Accounts delegated with local or domain

privileged access should be explicitly denied
access to standard workstations and laptop
systems within the context of the following
settings (which can be configured using
Group Policy settings similar to what are
depicted in Fig. 29):

• Deny access to this computer from

the network (also include S-1-5-114: NT
AUTHORITY\Local account and member
of Administrators group)
• Deny log on as a batch job

• Deny log on as a service

• Deny log on locally

• Deny log on through Terminal Services

8 See https://www.microsoft.com/en-us/download/details.aspx?id=46899
9 Microsoft (February 13, 2019). Active Directory administrative tier model.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 19

Service Account Logon Restrictions • Active Directory Users and Computers > Select the
Organizations should also consider enhancing the security Account Tab
of domain-based service accounts - to restrict the capability –– “Log On To” button > Select the proper scope of
for the accounts to be used for interactive, remote desktop, computers for access (Fig. 30)
and where possible, network-based logons.
Protected Users Security Group
On endpoints where the service account is not required
By leveraging the “Protected Users” security group
for interactive or remote logon purposes, Group Policy
for privileged accounts, an organization can minimize
settings can be used to enforce recommended logon
various risk factors and common exploitation methods for
restrictions for limiting the exposure of service accounts.
exposing privileged accounts on endpoints.
• Computer Configuration > Policies > Windows Settings
> Security Settings > Local Policies > User Rights Beginning with Microsoft Windows 8.1 and Microsoft
Assignment Windows Server 2012 R2 (and above), the “Protected
Users” security group was introduced to manage
–– Deny log on locally (SeDenyInteractiveLogonRight)
credential exposure within an environment. Members of
–– Deny log on through Terminal Services this group automatically have specific protections applied
(SeDenyRemoteInteractiveLogonRight) to their accounts, including:

Additional recommended logon hardening for service • The Kerberos ticket granting ticket (TGT) expires after 4
accounts (on endpoints where the service accounts is not hours, rather than the normal 10-hour default setting.
required for network-based logon purposes):
• No NTLM hash for an account is stored in LSASS
• Computer Configuration > Policies > Windows Settings since only Kerberos authentication is used (NTLM
> Security Settings > Local Policies > User Rights authentication is disabled for an account).
Assignment • Cached credentials are blocked. A Domain Controller
–– Deny access to this computer from the network must be available to authenticate the account.
(SeDenyNetworkLogonRight)
• WDigest authentication is disabled for an account,
If a service account is only required to be leveraged on a regardless of an endpoint’s applied policy settings.
single endpoint to run a specific service, the service account • DES and RC4 can’t be used for Kerberos pre-
can be further restricted to only permit the account’s usage authentication (Server 2012 R2 or higher); rather
on a predefined listing of endpoints. Kerberos with AES encryption will be enforced.
• Accounts cannot be used for either constrained or
unconstrained delegation (equivalent to enforcing the
Figure 30. Option to restrict an account to logon to specific “Account is sensitive and cannot be delegated” setting
endpoints.
in Active Directory Users and Computers).

To provide Domain Controller-side restrictions for

members of the “Protected Users” security group, the
domain functional level must be Windows Server 2012 R2
(or higher). Microsoft Security Advisory KB287199710 adds
support for the protections enforced for members of the
“Protected Users” security group to Windows 7, Windows
Server 2008 R2, and Windows Server 2012 systems.

Note: Service accounts (including Managed Service Accounts)

should NOT be added to the “Protected Users” security group —
as authentication will fail.

10 Microsoft (May 13, 2014). Microsoft Security Advisory: Update to improve credentials protection and management; May 13, 2014.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 20

Cleartext Password Protections

Tactic: Obtaining cleartext credentials in memory for credential harvesting

In addition to restricting access for privileged accounts, controls should be enforced that minimize the exposure of
credentials and tokens in memory on endpoints.

On older Windows Operating Systems, cleartext passwords are stored in memory (LSASS) to primarily support WDigest
authentication. WDigest should be explicitly disabled on all Windows endpoints where it is not disabled by default.

By default, WDigest authentication is disabled in Windows 8.1+ and in Windows Server 2012 R2+.

Beginning with Windows 7 and Windows Server 2008 R2, after installing Microsoft Security Advisory KB2871997,11
WDigest authentication can be configured either by modifying the registry or by using the “Microsoft Security Guide”
Group Policy template from the Microsoft Security Compliance Toolkit.12

Figure 31.
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\
Registry key UseLogonCredential
and value for
disabling WDigest REG_DWORD = “0”
authentication.

Registry Method:
Another registry setting that should be explicitly configured is the “TokenLeakDetectDelaySecs” setting (Fig. 32), which will
clear credentials in memory of logged off users after 30 seconds, mimicking the behavior of Windows 8.1 and above.

Figure 32.
Registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs
and value for REG_DWORD = “30”
enforcing the
“TokenLeakDetect
DelaySecs” setting.

Group Policy Method:

Using the “Microsoft Security Guide” Group Policy template, WDigest authentication can be disabled via a Group Policy setting
(Fig. 33).

• Computer Configuration > Policies > Administrative Templates > MS Security Guide > WDigest Authentication

Figure 33. Disabling WDigest authentication via the “MS Security Guide” Group Policy template.

11 Microsoft (May 13, 2014). Microsoft Security Advisory: Update to improve credentials protection and management; May 13, 2014.
12 See https://www.microsoft.com/en-us/download/details.aspx?id=55319
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 21

Additionally, an organization should verify if any applications are explicitly listed in the “Allow” keys (Fig. 34) - as this
would permit the tspkgs / CredSSP providers to store cleartext passwords in memory.

Figure 34. Additional registry key for hardening against cleartext password storage.

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults

As Microsoft Security Advisory KB287199713 is not applicable for Windows XP, Windows Server 2003, and Windows
Server 2008, to disable WDigest authentication on these platforms, prior to a system reboot, WDigest needs to be
removed from the listing of LSA security packages within the registry (Fig. 35 and Fig. 36).

Figure 35. Registry key to modify LSA security packages.

HKLM\System\CurrentControlSet\Control\Lsa\Security Packages

Figure 36. LSA security package registry key before and after the
removal of WDigest authentication from the listing of providers.

By default, Group Policy settings are only reprocessed and reapplied if the actual Group Policy was modified prior to
the default refresh interval.

Many attackers will manually “enable” WDigest authentication on endpoints by directly modifying the registry
(UseLogonCredential configured to a value of “1”). Even on endpoints where WDigest authentication is automatically
disabled by default, it is recommended to enforce the Group Policy settings noted in Figure 33—and configure automatic
policy reprocessing for the configured settings on an automated basis.

• Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure security policy
processing
–– Enabled - Process even if the GPOs have not changed

• Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure registry policy
processing
–– Enabled - Process even if the GPOs have not changed

13 Microsoft (May 13, 2014). Microsoft Security Advisory: Update to improve credentials protection and management; May 13, 2014.
WHITE PAPER | FIREEYE MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 22

Conclusion
Ransomware poses a serious threat to organizations, as attackers continue
to utilize this tactic to monetize breaches. This whitepaper provided practical
guidance on protecting against ransomware attacks and containing ongoing
ransomware events. This whitepaper should not be considered a comprehensive
guide on every tactic and control that can be used for this purpose, but it can
serve as a valuable resource for organizations faced with this challenge. It is
based on years of experience of helping our clients protect against and recover
from ransomware attacks—and it can help your organization do the same.

To learn more about FireEye, visit: www.FireEye.com

FireEye, Inc. About FireEye, Inc.

601 McCarthy Blvd. Milpitas, CA 95035 FireEye is the intelligence-led security company.
408.321.6300/877.FIREEYE (347.3393) Working as a seamless, scalable extension of customer
[email protected] security operations, FireEye offers a single platform
that blends innovative security technologies, nation-
state grade threat intelligence, and world-renowned
©2019 FireEye, Inc. All rights reserved. FireEye is Mandiant® consulting. With this approach, FireEye
a registered trademark of FireEye, Inc. All other eliminates the complexity and burden of cyber security
brands, products, or service names are or may be
trademarks or service marks of their respective
for organizations struggling to prepare for, prevent and
owners. E-EXT-DS-US-EN-000212-01 respond to cyber attacks.