white paper

Ransomware Protection and

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

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

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

Endpoint Segmentation.............................................................................................................. 4
RDP Hardening............................................................................................................................... 8
Disable Administrative / Hidden Shares............................................................................. 10
Disable SMB v1...............................................................................................................................12
Hardening Windows Remote Management (WinRM)....................................................15

Credential Exposure and Usage Hardening............................................................................. 17

Remote Usage of Local Accounts..........................................................................................17

Reduce the Exposure of Privileged and Service Accounts..........................................19
Cleartext Password Protections..............................................................................................21

Domain Controller Isolation and Recovery Planning...........................................................23

Group Policy Object (GPO) Permissions and Monitoring..................................................25

Conclusion..............................................................................................................................................27
WHITE PAPER | 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 | 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 | 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 | 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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 7

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

Additionally, the Windows Firewall can be configured to Firewall rules to block specific binaries from making
block specific binaries from making outbound connections outbound connections from an endpoint.
on endpoints. During ransomware response engagements,
Mandiant has identified legitimate Windows binaries being Using powershell.exe and bitsadmin.exe as examples, the
leveraged to download backdoors and encryptors from figure below provides configurations of leveraging Windows
both internal and external locations. To protect against this Firewall rules to deny the ability for specific binaries to
tactic, an organization can leverage a series of Windows establish outbound connections from an endpoint.

Figure 5.
Windows Firewall
rule example to
block specific
binaries from
making outbound
connections on an
endpoint.
WHITE PAPER | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 8

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 and
Malicious actors may exploit RDP to gain initial access Azure Multi-Factor Authentication Server using RADIUS.2
into an organization, perform lateral movement, invoke
ransomware, and potentially access and steal data. Leverage Network Level Authentication
For external-facing RDP servers, Network Level
Proactively, organizations should scan their public IP Authentication (NLA) provides an extra layer of pre-
address ranges to identify systems with RDP (TCP/3389) authentication before a connection is established. NLA
and other protocols (SMB – TCP/445) open to the Internet. is also useful for protecting against brute force attacks,
At a minimum, RDP and SMB should not be directly which often target open internet-facing RDP servers.
exposed for ingress and egress access to/from the Internet.
If required for operational purposes, explicit controls should NLA can be configured either via the User Interface (UI)
be implemented to restrict the source IP addresses which (Fig. 6) or via Group Policy (Fig. 7).
can interface with systems using these protocols.

Figure 6.
Enabling NLA
via the UI.

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

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 7.
Enabling NLA via
Group Policy.

Some caveats about leveraging NLA for RDP: Restrict Administrative Accounts from Leveraging RDP
on Internet-Facing Systems
• The Remote Desktop client v7.0 (or greater) must be For external-facing RDP servers, highly-privileged domain
leveraged. and local administrative accounts should not be permitted
• NLA utilizes CredSSP to pass authentication requests access to interface with the servers using RDP (Fig. 8).
from the initiating system. CredSSP stores credentials
This can be enforced using Group Policy, configurable via
in LSA memory on the initiating system—and these
the following setting:
credentials may remain in memory even after a user logs
off from the system. This provides a potential exposure • Computer Configuration > Policies > Windows Settings
risk for credentials in memory on the source system. > Security Settings > Local Policies > User Rights
• On the RDP server, users permitted for remote access Assignment > Deny log
using RDP must be assigned the “Access this computer
from the network” privilege when NLA is enforced. This
privilege is often explicitly denied for user accounts to
protect against lateral movement techniques.

Figure 8.
Group Policy
configuration
for restricting
highly privileged
domain and local
administrative
accounts from
leveraging RDP.
WHITE PAPER | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 10

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

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

Workstations:

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

Servers:

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

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

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

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

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. 12).

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

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

Figure 12. 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. 13), a
registry modification, or by using the “Microsoft Security Guide” Group Policy template from the Microsoft Security
Compliance Toolkit.5

PowerShell Method:

Figure 13. Set-SmbServerConfiguration -EnableSMB1Protocol $false

PowerShell
command to
disable SMB v1.

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

Disable SMBv1 Server:

Figure 14.
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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 13

Disable SMBv1 Client:

Figure 15.
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 16. 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 17. Disabling SMB v1 client driver via the “MS Security Guide” Group Policy template.

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

• 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 19. Disabling SMB v1 client extra settings via the “MS Security Guide” Group Policy template.

Figure 20.
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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 15

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 21.
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 24 and Figure 25.
the WinRM protocol.

PowerShell:
Figure 21.
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 22 will be displayed.

Figure 22. Warning message after disabling PSRemoting.

WHITE PAPER | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 16

Figures 23-26 show how to enforce the additional steps for disabling WinRM via PowerShell.

Stop and disable the WinRM Service.

Figure 23.
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 24.
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 25.
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 26. 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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 17

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 member template from the Microsoft Security Compliance Toolkit.7
of Administrators group”, if Failover Clustering is utilized, this feature
should leverage a non-administrative local account (CLIUSR) for
Group Policy Setting:
cluster node management. If this account is a member of the local
Administrators group on an endpoint that is part of a cluster, blocking • Computer Configuration > Policies > Administrative
the network logon permissions can cause cluster services to fail. Be Templates > MS Security Guide > Apply UAC restrictions
cautious and thoroughly test this configuration on servers where Failover
to local accounts on network logons
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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 18

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 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. 28) will be configured on each endpoint:

Figure 28.
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. 29) will be configured on each endpoint. This is the default setting.

Figure 29.
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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 19

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 30.
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. 30):

• 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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 20

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. 31)
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 31. 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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 21

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 32.
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. 33), which will
clear credentials in memory of logged off users after 30 seconds, mimicking the behavior of Windows 8.1 and above.

Figure 33.
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. 34).

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

Figure 34. 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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 22

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

Figure 35. 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. 36 and Fig. 37).

Figure 36. Registry key to modify LSA security packages.

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

Figure 37. 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 configure automatic policy reprocessing for the configured
and reapplied if the actual Group Policy was modified settings on an automated basis.
prior to the default refresh interval.
• Computer Configuration > Policies > Administrative
Many attackers will manually “enable” WDigest Templates > System > Group Policy > Configure security
authentication on endpoints by directly modifying the policy processing
registry (UseLogonCredential configured to a value of – Enabled - Process even if the GPOs have not changed
“1”). Even on endpoints where WDigest authentication is
automatically disabled by default, it is recommended to • Computer Configuration > Policies > Administrative
enforce the Group Policy settings noted in Figure 33—and 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 | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 23

Domain Controller Isolation

and Recovery Planning
In the event of a ransomware outbreak, an organization resolution, and GPO processing. If Domain Controller
must ensure that they have a practiced plan in place to backups are either encrypted or are not current, an
quickly isolate key systems, and ensure that at least one organization may be faced with a complete rebuild of an
Domain Controller can be quickly taken offline and safely entire forest, which can further impact downtime.
isolated for each domain within managed and trusted
forests. If the disk partition that houses the Active Directory When Mandiant is engaged to help contain an active
database (%SYSTEMROOT%\ntds\ntds.dit) and SYSVOL ransomware deployment, the first steps recommended
(%SYSTEMROOT%\SYSVOL) on all Domain Controllers that an organization take are to isolate at least one Domain
were to be encrypted, this will impact the availability of Controller (preferable one that holds FSMO roles) and
domain services and functionality for all domain-based ensure that offline backups of SYSVOL (%SYSTEMROOT%\
applications and services, including authentication, name SYSVOL\*) and GPOs are available and current.

Figure 38. Command to determine a Domain Controller that holds a FSMO role.

netdom query fsmo

Figure 39. PowerShell command to backup all GPOs in a domain.

backup-gpo -domain “domain.local” -all -path “c:\temp\gpo-backups”

Proactively, in the event that either an authoritative or non- the DSRM password available, the password can be set
authoritative Domain Controller restoration is required, to a known value by following the process outlined in the
an organization should ensure that the Directory Services figure below. The steps will need to be initiated on each
Restore Mode (DSRM) password is set to a known value Domain Controller.
on all Domain Controllers. If an organization does not have

Figure 40. PS C:\Windows\system32> ntdsutil

C:\Windows\System32\ntdsutil.exe: set drsm password
Command to Reset DRSM Administrator Password: reset password on server null
set the DSRM Please type password for DS Restore Mode Administrator Account: *****************
password on a Please confirm new password: **************
Domain Controller. Password has been set successfully.

Reset DRSM Administrator Password: q

C:\Windows\System32\ntdsutil.exe:
WHITE PAPER | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 24

When restoring Active Directory from previous Domain • Data Retention: backup products and technologies
Controller backups is the only viable option to restore should ensure that backups are retained for a pre-defined
domain services, an organization must first ensure that period-of-time - before overwriting or purging data.
they have a working and tested backup plan and strategy • Enforce role-based access control: Access to backup
to guarantee the availability and integrity of the schema media and the applications that govern and manage
and domain services that need to be reconstituted. The data backups should utilize role-based access controls,
following best practices should be proactively reviewed by to restrict the scope of accounts that have access to the
an organization: stored data and configuration parameters.
• Offline backups: ensure that offline Domain Controller • Testing and verification: An organization should
backups are secured and stored separately from periodically test and verify that data can be restored
online backups. and reconstituted from both online and offline media
sources. Both authoritative and non-authoritative
• Encryption: backup data should be encrypted both
Domain Controller restoration processes should be
during transit (over the wire) and when at rest or
documented and tested.
mirrored for offsite storage.
• Configure alerting for backup operations: backup
products and technologies should be configured to
detect and provide alerting for operations that are
critical to the availability and integrity of backup data
(e.g., deletion of backup data, purging of backup
metadata, restoration events, media errors).
WHITE PAPER | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 25

Group Policy Object (GPO)

Permissions and Monitoring
A common tactic utilized by ransomware operators is Active Directory to accomplish their mission, without the need
to deploy encryptors by modifying an existing GPO to directly interface with each endpoint to invoke encryptors
configuration, or by creating a new GPO, and linking either at across an enterprise environment.
the root of the domain or to a large scope of Organizational
Units (OUs) that contain computer objects. By leveraging Proactively, organizations should review the scope of
scheduled tasks, startup / logon scripts, or software configured GPOs, and the last modified timestamp of a
installation package settings within GPOs, ransomware GPO to ensure that all modifications align to authorized
operators are able to leverage native functionality within and expected activities.

Figure 41. PowerShell command to review the scope of configured GPOs – including the last modified timestamp

get-gpo -all | export-csv -path “c:\temp\gpo-listing-all.csv” -NoTypeInformation

Additionally, organizations should review permissions the ability to modify a large scope of GPOs, or GPOs that are
for existing GPOs—specifically focusing on the scope of linked-to and enforce security settings for a large scope of
accounts and groups that have the ability to modify GPOs endpoints (e.g., Default Domain Policy) should be carefully
within a domain. Any accounts or security groups that have protected, and deemed to be privileged within a domain.

Figure 42. PowerShell commands to list existing GPOs and assigned permissions.

$permissions = Foreach ($GPO in (Get-GPO -All | Where {$_.DisplayName -like “*”}))

{
Foreach ($Permission in (Get-GPPermissions $GPO.DisplayName -All | Where {$_.Permission
-like “*”}))
{
New-Object PSObject -property @{GPO=$GPO.DisplayName;Trustee=$Permission.Trustee.
Name;Permission=$Permission.Permission}
}
}
$permissions | Select GPO,Trustee,Permission | Export-CSV c:\temp\GPO-Permissions.csv
-NoTypeInformation
WHITE PAPER | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 26

GPO modifications can be proactively detected by reviewing Policy GPO (well-known GUID of 31B2F340-016D-11D2-
Security event logs on Domain Controllers for Event ID 945F00C04FB984F9) being modified, and a Scheduled
5136 - which requires that “Audit Directory Service Changes” Task (client side extension of AADCED64-746C-4633-
auditing be enabled. Figure 6 provides an example of A97C-D61349046527) being added.
a Security event log detection for the Default Domain

Figure 43. Event ID 5136 detection for GPO modifications.

WHITE PAPER | MANDIANT RANSOMWARE PROTECTION AND CONTAINMENT STRATEGIES 27

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/mandiant

FireEye, Inc. About Mandiant Solutions

601 McCarthy Blvd. Milpitas, CA 95035 Mandiant Solutions brings together the world’s leading
408.321.6300/877.FIREEYE (347.3393) threat intelligence and frontline expertise with continuous
info@FireEye.com security validation to arm organizations with the tools
needed to increase security effectiveness and reduce
business risk.
©2020 FireEye, Inc. All rights reserved.
FireEye and Mandiant are registered trademarks
of FireEye, Inc. All other brands, products, or
service names are or may be trademarks or
service marks of their respective owners.
M-EXT-WP-US-EN-000212-03