Ransomware

Containment and
Remediation
Strategies
v4.0
 CONTENTS
Background ................................................................................................................................................. 3
Segmentation .............................................................................................................................................. 3
Windows Firewall ................................................................................................................................... 3
Network Segmentation .......................................................................................................................... 6
Local Accounts – Lateral Movement Mitigation Techniques ............................................................... 8
Step 1 – Option 1: S-1-5-114 ............................................................................................................... 8
Step 1 – Option 2: UAC Token-Filtering ............................................................................................. 8
Step 2: LAPS........................................................................................................................................... 9
Privileged Account Logon Restrictions ................................................................................................. 10
Password Protections .............................................................................................................................. 12
Disabling Administrative / Hidden Shares ............................................................................................ 14
Patching ..................................................................................................................................................... 16
Disable SMB v1 ........................................................................................................................................ 17
Hardening Permissions for Endpoint Persistence ............................................................................... 19
Registry Hardening .............................................................................................................................. 19
Scheduled Tasks .................................................................................................................................. 21
RDP Hardening......................................................................................................................................... 23
Enforce Multi-Factor Authentication .................................................................................................. 23
Leverage Network Level Authentication ........................................................................................... 23
Restrict Administrative Accounts from Leveraging RDP on Internet-Facing Systems .............. 24
AppLocker ................................................................................................................................................. 25
AppLocker Whitelisting Using PowerShell ....................................................................................... 27
AppLocker Cautions............................................................................................................................. 28
Modify NTFS Permissions using Group Policy .................................................................................... 29
Recovery and Reconstitution ................................................................................................................. 30
Domain Controller Isolation ................................................................................................................ 30
Backups ................................................................................................................................................. 31
Domain Controller Recovery .............................................................................................................. 32
Building a New Server for Domain Controller Promotion ........................................................... 32
FSMO Roles - Seize and Transfer ................................................................................................ 32
Removing Stale Domain Controllers ............................................................................................. 33
Domain Controller Backups ............................................................................................................ 34
Non-Authoritative Domain Controller Restoration ....................................................................... 34
Authoritative Domain Controller Restoration................................................................................ 35
Background
Ransomware is a common method of cyber extortion or disruption for financial gain. It’s a type of attack
that instantly disrupts access to files, applications or systems until either the victim pays the ransom and
the attacker restores access with a decryption key, or an organization restores and reconstitutes from
backups. Once ransomware is invoked within an organization, most variants utilize privileged accounts
and trust relationships for lateral dispersion.

Common methods that ransomware utilizes to laterally prorogate throughout an environment include:

• Credential or Windows token extraction from disk or memory (ex: Mimikatz)

• SMB exploits (ex: EternalBlue – addressed via Microsoft Security Bulletin MS17-010)
• Leveraging Windows Management Instrumentation (WMI), SMB, or PSEXEC to bind to systems
and execute payloads

The scope of this document is to capture 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.

Segmentation
Windows Firewall
During a ransomware event, most variants utilize privileged and trusted accounts to laterally interface with
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 (ex: workstation to Domain Controller or File Server), the scope of SMB communications
permitted directly between systems can be restricted and minimized (ex: workstation-to-workstation).

During a ransomware event, a Windows firewall policy can be configured and centrally enforced via
Group Policy, to restrict the scope of communications permitted between common endpoints within an
environment. 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

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

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

Log Log Log File

Profile Firewall Inbound
Dropped Successful Log File Path Maximum
Setting State Connections
Packets Connections Size (KB)
Domain On Allow Yes Yes %systemroot%\ 4,096
system32\LogF
iles\Firewall\pfir
ewall.log
Private On Block All Yes Yes %systemroot%\ 4,096
Connections system32\LogF
 iles\Firewall\pfir
ewall.log
Public On Block All Yes Yes %systemroot%\ 4,096
Connections system32\LogF
iles\Firewall\pfir
ewall.log
Table 1: Windows Firewall Recommended Configuration State

Figure 1: Windows Firewall Recommendation Configurations

Additionally, to ensure that only centrally managed firewall rules are enforced during a containment event,
the settings for “Apply local firewall rules” and “Apply local connection security rules” should be set to “No”
for all profiles.

Figure 2: Windows Firewall Domain Profile Customized Settings

To quickly contain and isolate systems, the centralized Windows Firewall setting of “Block all connections”
(Figure 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 the environment, it may be a necessary step for quick
containment.

Note – once the event has been contained and it has been deemed “safe” to re-establish connectivity
amongst systems within an environment, via Group Policy, the setting can be changed back to “Allow”.
Figure 3: Windows Firewall - "Block all connections" settings

If blocking all inbound connectivity for common endpoints during a containment event is not practical, or
for Domain Profile configurations, at a minimum, the blocks listed in Table 2 should be enforced using
either Group Policy - or via the commands referenced below.

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.

Protocol / Port Windows Firewall Rule Command Line Enforcement

SMB Predefined Rule: netsh advfirewall firewall set rule
• File and Print group="File and Printer Sharing" new
TCP/445, TCP/139, TCP/135 Sharing enable=no
Remote Desktop Protocol Predefined Rule: netsh advfirewall firewall set rule
• Remote Desktop group="Remote Desktop" new
TCP/3389 enable=no
WMI Predefined Rule: netsh advfirewall firewall set rule
• Windows group="windows management
Management instrumentation (wmi)" new enable=no
Instrumentation
(WMI)
Windows Remote Predefined Rule: netsh advfirewall firewall set rule
Management / PowerShell • Windows Remote group="Windows Remote
Remoting Management Management" new enable=no
• Windows Remote
TCP/80, TCP/5985, Management Via PowerShell:
TCP/5986 (Compatibility) Disable-PSRemoting -Force

Port Rule:
• 5986
Table 2: Windows Firewall Suggested Block Rules
Figure 4: Windows Firewall Suggested Rule Blocks via Group Policy

An additional command that can be leveraged to block the remote execution of PSEXEC on endpoints is
referenced in Figure 5.

FOR /F “usebackq tokens=2 delims=:” %a IN (`sc.exe sdshow scmanager`) DO sc.exe sdset

scmanager D:(D;;0x00040002;;;NU)%a
Figure 5: Command to block remote execution of PSEXEC on endpoints – via
https://cloudblogs.microsoft.com/microsoftsecure/2017/06/29/windows-10-platform-resilience-against-the-petya-
ransomware-attack/

This command enforces an access control entry (ACE) that denies both “CreateService” (used by
PSEXEC) and “WriteDAC” (used to reverse the permissions).

Network Segmentation
Another method to quickly enforce logical isolation of systems within an environment is to segment using
network-based controls. These can include Layer 3 access-control lists (ACLs) applied to specific
physical or virtual (VLAN) interfaces, firewalls configured with stateful ACLs, or routing configurations
which temporarily null route traffic based upon pre-defined parameters.

Note – enforcing segmentation at the network layer will not fully protect against system-to-system
connectivity (ex: systems that reside in the same subnet or VLAN where an ACL may be applied). It is
still recommended to utilize host-based firewalls to restrict system-to-system communications, in addition
to segmentation and communication restricts enforced at the network layer.

Using the example of blocking INBOUND traffic from one network segment to another (systems residing
in VLAN100), based upon the following ports (below), the ACL in Figure 6 can be utilized as an example.

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

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

deny tcp any 10.100.100.0 0.0.0.255 eq 135

deny tcp any 10.100.100.0 0.0.0.255 eq 139
deny tcp any 10.100.100.0 0.0.0.255 eq 445
deny tcp any 10.100.100.0 0.0.0.255 eq 3389
deny tcp any 10.100.100.0 0.0.0.255 eq 80
deny tcp any 10.100.100.0 0.0.0.255 range 5985-5986
permit ip any 10.100.100.0 0.0.0.255

interface vlan 100

ip address 10.100.100.254 255.255.255.0
ip access-group VLAN100_ACL_BLOCK_INBOUND out
Figure 6: Layer 3 ACL to block INBOUND traffic to systems in a destination VLAN

ACL applied in the out

direction will take effect for
any traffic destined to the
systems on the specific VLAN
ACL applied in the in
direction will take effect for
any traffic originating from
systems within the VLAN, VLAN100 Interface
with a destination of any
systems outside of the
specific VLAN

VLAN100

Figure 7:VLAN to ACL binding example

Local Accounts – Lateral Movement Mitigation
Techniques
Local accounts that exist on endpoints are often a common avenue leveraged by attackers to laterally
move throughout an environment. This tactic is especially impactful when the password for the built-in
local administrator account is configured to the same value across multiple endpoints.

To mitigate the impact of local accounts being leveraged for lateral movement, KB2871997
(https://support.microsoft.com/en-us/help/2871997/microsoft-security-advisory-update-to-improve-
credentials-protection-a) introduced two (2) well-known SIDs that can be leveraged within GPO settings
to restrict the usage of local accounts for lateral movement.

• S-1-5-113: NT AUTHORITY\Local account

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

Specifically, the SID “S-1-5-114: NT AUTHORITY\Local account and member of Administrators group” is
added to an account’s access token if the local account is a member of the BUILTIN\Administrators
group. This is the most beneficial SID to leverage to stop an attacker (or ransomware variant) that
propagates using credentials for local administrative accounts.

Note: For SID “S-1-5-114: NT AUTHORITY\Local account and member of Administrators group”, if
Failover Clustering is utilized, this feature should leverage a non-administrative local account (CLIUSR)
for cluster node management. If however, this account is a member of the local Administrators
group on an endpoint that is part of a cluster, blocking the network logon permissions can cause
cluster services to fail. Be cautious and thoroughly test this configuration on servers where Failover
Clustering is utilized.

Step 1 – Option 1: S-1-5-114

To mitigate the usage of local administrative accounts from being used for lateral movement, utilize the
SID “S-1-5-114: NT AUTHORITY\Local account and member of Administrators group” within the following
settings:

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies >
User Rights Assignment
o Deny access to this computer from the network (SeDenyNetworkLogonRight)
o Deny log on as a batch job (SeDenyBatchLogonRight)
o Deny log on as a service (SeDenyServiceLogonRight)
o Deny log on through Terminal Services (SeDenyRemoteInteractiveLogonRight)
o Debug Programs (SeDebugPrivilege – permission used for attempted privilege escalation
and process injection)

Step 1 – Option 2: UAC Token-Filtering

An additional control that can be enforced via GPO pertains to the usage of local accounts for remote
administration and connectivity via a network logon. If the full scope of permissions (referenced above)
cannot be implemented in a short timeframe, consider applying the UAC token-filtering method to local
account for network-based logons.

To leverage this configuration via a GPO setting:

1. Download the Security Compliance Toolkit (https://www.microsoft.com/en-

us/download/details.aspx?id=55319) to utilize the “MS Security Guide” ADMX file.
2. Once downloaded, the "SecGuide.admx" and "SecGuide.adml" files must be copied to the
\Windows\PolicyDefinitions and \Windows\PolicyDefinitions\en-US directories
respectively.
 3. If a Centralized GPO store is configured for the domain, copy the “PolicyDefinitions” folder to the
C:\Windows\SYSVOL\sysvol\<domain>\Policies folder.

GPO Setting:
• Computer Configuration > Policies > Administrative Templates > MS Security Guide > Apply UAC
restrictions to local accounts on network logons
o Enabled

Once enabled, the registry value (below) will be configured on each endpoint:
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilter
Policy
o REG_DWORD = “0” (Enabled)

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’s Local Administrator Password Solutions (“LAPS”).

For additional information regarding LAPs, reference:

• https://www.microsoft.com/en-us/download/details.aspx?id=46899
• https://blogs.technet.microsoft.com/askpfeplat/2015/12/28/local-administrator-password-solution-
laps-implementation-hints-and-security-nerd-commentary-including-mini-threat-model/
Privileged Account Logon Restrictions
As ransomware propagates throughout an environment, privileged credentials are commonly utilized for
lateral movement and mass “spreading” capabilities. Until a thorough investigation has been completed,
it may be difficult to determine the specific credentials and accounts that are being utilized by a variant for
connectivity to a large-scope of systems within the environment. As a precaution and immediate
containment measure, the following restrictions can be enforced, to minimize the scope of privileged
accounts that can be utilized for remote logon purposes within a managed environment.

For any accounts that have privileged access throughout the environment, the accounts should not be
utilized on standard workstations and laptops, but rather from designated systems (ex: jump boxes) 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 (reference Figure 8).

The recommendations for restricting the scope of access for privileged accounts is based upon
Microsoft’s guidance for securing privileged access. For additional information, reference:
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-
access-reference-material

Figure 8: Tiered Model Logon Restrictions for Privileged Access

As a quick containment measure, consider blocking any accounts with privileged access from being able
to login (remotely or locally) to standard workstations, laptops, and common access servers (ex: Citrix).
For the Group Policy configurations referenced below, the settings are configurable via the path of:

• Computer Configuration > 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 laptops systems within the context of the following settings (which can be configured
using Group Policy settings – reference Figure 9):

• 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
Figure 9: Example of Tier 2 Privileged Account access restrictions using Group Policy
Password Protections
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, clear-text passwords are stored in memory (LSASS) to primarily
support WDigest authentication. WDigest should be explicitly disabled on all Windows endpoints.

By default, WDigest authentication is disabled in Windows 8.1 (higher) and in Windows Server 2012 R2
(higher).

After installing KB2871997, WDigest authentication can be configured either by modifying the registry or
by using the “Microsoft Security Guide” Group Policy template
(https://blogs.technet.microsoft.com/secguide/2018/10/01/security-baseline-draft-for-windows-10-v1809-
and-windows-server-2019/) or the SCM: Pass the Hash Mitigations Group Policy template.

Registry:
• HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential
o REG_DWORD = “0”

Another registry that should be explicitly configured is the "TokenLeakDetectDelaySecs" setting - which
will clear credentials in memory of logged off users after 30 seconds, mimicking the behavior of Windows
8.1 and above.
• HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs
o REG_DWORD = "30"

Group Policy:
Using the Microsoft Security Guide Group Policy template, WDigest authentication can be disabled via a
GPO setting (reference Figure 10).

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

Figure 10: Disabling WDigest authentication via the “MS Security Guide” Group Policy template

Using the Security Compliance Manager (SCM) Group Policy administrative template, WDigest
authentication can be disabled via a GPO setting (reference Figure 11).

• Computer Configuration > Policies > Administrative Templates > SCM: Pass the Hash Mitigations
> WDigest Authentication
o Disabled
Figure 11: Disabling WDigest authentication via the “SCM: Pass the Hash Mitigations” Group Policy template

Additionally, an organization should verify that “Allow*” settings are not specified within the following
registry keys, as this configuration would permit the tspkgs / CredSSP providers to store clear-text
passwords in memory:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation
Disabling Administrative / Hidden Shares
Some ransomware variants (ex: CryptoFortress) will attempt to identify administrative or hidden network
shares, including those that are not explicitly mapped to a drive letter, and bind to additional endpoints
throughout the environment. As a containment step, an organization may need to quickly disable default
administrative or hidden shares from being accessible on endpoints throughout the environment. This
can be accomplished either modifying the registry, stopping a service, or by using the “MSS (Legacy)”
Group Policy template (https://blogs.technet.microsoft.com/secguide/2018/10/01/security-baseline-draft-
for-windows-10-v1809-and-windows-server-2019/).

Common administrative and hidden shares on endpoints include:

• ADMIN$
• C$
• D$
• IPC$

Note – disabling administrative and hidden shares on servers, specifically including Domain Controllers,
may significantly impact the operation and functionality of systems within a domain-based environment.

Registry:
Using the registry, administrative and hidden shares can be disabled on endpoints.

Workstations:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
o DWORD Name = “AutoShareWks”
▪ Value = “0”
Servers:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
o DWORD Name = “AutoShareServer”
▪ Value = “0”

Service:
By stopping the “Server” service on an endpoint, the ability for any shares (hosted on the endpoint) to be
accessed will be disabled (reference Figure 12).
Figure 12: “Server” Service Properties

Group Policy:
Using the “MSS (Legacy)” Group Policy template, administrative and hidden shares can be disabled via a
GPO setting (reference Figure 13Figure 10).

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

Figure 13: Disabling administrative and hidden shares via the “MSS (Legacy)” Group Policy template
Patching
Applying patches for known exploits is a key recommendation for containment and potential remediation
for a ransomware infection. Many variants utilize known exploits to compromise systems and invoke
lateral movement within an environment. A common example of this is the WannaCrypt ransomware
variant, which exploited one of the vulnerabilities that is addressed as part of the MS17-010 Microsoft
Security update.

Organizations should ensure that patches are tested and verified before enforcing on production systems
within an environment. Additionally, leveraging tested processes, in addition to a centralized platform for
expediting the deployment of critical patches, is vital to ensuring that proper containment and remediation
measures can be invoked in the event of a large-scale outbreak within an environment.
Disable SMB v1
Similar to patching, disabling SMB v1 on endpoints can reduce the mass propagation methods used by
some ransomware variants. Specifically, the Petya ransomware variant, also known as Petrwrap or
NotPetya, utilized an SMB v1 vulnerability to rapidly infect systems within connected infrastructures.

SMB v1 can be disabled on endpoints using either PowerShell (Figure 14), registry modification, or by
using the Microsoft Security Guide Group Policy template.

PowerShell:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Figure 14: PowerShell command to disable SMB v1

Group Policy:
Using the Microsoft Security Guide Group Policy template, SMB v1 can be disabled via GPO settings.

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

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
o 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

• Computer Configuration > Policies > Administrative Templates > MS Security Guide > Configure
SMB v1 Client (extra setting needed for pre-Win8.1/2012R2)
o 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 extra settings via the “MS Security Guide” Group Policy template – additional settings

Registry:
Using the registry, SMB v1 can be disabled on endpoints

Disable SMBv1 Server:

• HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
o Registry entry: SMB1
▪ REG_DWORD: “0” (Disabled)

Disable SMBv1 Client:

• HKLM\SYSTEM\CurrentControlSet\services\mrxsmb10
o Registry entry: Start
▪ REG_DWORD: “4” (Disabled)

• HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation
o Registry entry: DependOnService
▪ REG_MULTI_SZ: “Bowser”,”MRxSmb20″,”NSI”
Hardening Permissions for Endpoint Persistence
Registry Hardening
Many ransomware variants will leverage persistence on an endpoint, to ensure that the ransomware is
still present and able to execute even if the endpoint is rebooted. A thorough investigation will yield
evidence of the various persistence mechanisms which a variant may utilize – although it may become
necessary to temporarily enforce hardened permissions that reduce risks related to additional systems
being configured with a persistent mechanism for malware invocation.

The Windows registry contains various keys that are often leveraged for persistence. Figure 20 provides
a high-level listing of common registry keys that are often leveraged for persistence on an endpoint.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell
Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell
Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Figure 20: Common Registry Keys Used for Persistence

Using a hardened Group Policy configuration, an organization can centrally reduce the scope of
permissions assigned to a specific registry key, and explicitly deny write or modify access for privileged
accounts, or accounts observed to be leveraged by a ransomware variant for propagation and
persistence.
• Computer Configuration > Policies > Windows Settings > Security Settings > Registry

Figure 21 provides an example of a GPO which has configured explicit deny permissions for the Domain
Admins group for the registry key
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run.

Figure 21: GPO example for enforcing an explicit DENY configuration for a specific registry key

To configure a similar GPO:

• Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Registry
– then Right Click and choose “Add Key”
o Navigate to the registry key that needs to be further secured
▪ Choose Advanced within the Security Permissions window
Figure 22: Advanced Security Permissions for editing
• Add > Select a Principal – then select the appropriate account or security
group for which permissions need to be denied – and select the
appropriate scope of permissions. Figure 23 provides the minimal subset
of permissions that should be included for an explicit deny.

Figure 23: Permission Entry window

o Click OK – and an “Add Object” box will appear (Figure 24). Select
the appropriate option for the intended configuration.

Figure 24: Add Object Configuration

▪ “Propagate inheritable permissions to all subkeys" forces
the specified ACL onto all subkeys of the target key.
▪ "Replace existing permissions on all subkeys with
inheritable permissions" forces only the new ACL onto
subkeys that inherit from the target key.
▪ Selecting the option for “Do not allow permissions on this
key to be replaced" indicates that the existing permissions
cannot be modified.
Once configured and the GPO is linked to a container, any attempts to write to the specified registry key
on an endpoint using an account where access was explicitly denied will result in an error (Figure 25).

Figure 25: Error when attempting to write to a registry key where access was denied

Scheduled Tasks
For scheduled tasks, another persistent mechanism that can be leveraged on an endpoint, an explicit
deny (via GPO) can be added for the following folder and files – to restrict execution of scheduled tasks
on an endpoint.
• %systemroot%\system32\tasks
• %systemroot%\system32\schtasks.exe
• %systemroot%\system32\at.exe

The process for configuring a GPO to enforce an explicit deny for NTFS folders and files be found within
the “Modify NTFS Permissions using Group Policy” section of this document.

Once configured, if the specified account attempts to configure or execute a scheduled task on an
endpoint via the command line or the Task Scheduler user interface, an error will occur (Figure 26 and
Figure 27).

Figure 26: Error message when attempting to execute a scheduled task using “schtasks.exe”

Figure 27: Error message when attempting to configure a scheduled task via the Task Scheduler user interface

Attackers often leverage the AT command to initiate or configure a scheduled task on an endpoint. A
Group Policy setting exists (below), that can further restrict the scope of permissions needed to invoke a
scheduled task via the AT command either locally or remotely for an endpoint.

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies >
Security Options > Domain Controller: Allow server operators to schedule tasks
o Disabled

If this policy setting is Enabled, tasks that are created by an account with the “Server Operator” role
(using the AT command) will be run within the context of the account that runs the Task Scheduler
service (Local System account). Setting this policy to Disabled will require that the authenticated
account have local administrative permissions on the endpoint in order to successfully invoke the task
using the AT command.
Once configured, the registry value (below) should be reflected on endpoints:
• HKLM\System\CurrentControlSet\Control\LSA\SubmitControl
o REG_DWORD = “0”

Note – this GPO setting does not restrict the capability for an account with Server Operator permissions
to configure a scheduled task using the Task Scheduler user interface. For this to be restricted, the
NTFS permissions for the %systemroot%\system32\tasks folder must be restricted (as noted above).
RDP Hardening
Remote Desktop Protocol (RDP) is a common method used by malicious actors to remotely connect to
systems and drop ransomware (ex: SamSam). When external-facing systems have RDP open to the
Internet, this elevates risks for not only ransomware, but also for malicious actors to gain initial access to
an organization, perform lateral movement, and potentially access and steal data.

Proactively, organizations should scan their public IP address ranges to identify systems with RDP
(TCP/3389), and other protocols (ex: SMB – TCP/445) open to the Internet. Explicit controls should be
implemented to restrict the source IP addresses which can interface with systems using these protocols,
in addition to implementing the hardening recommendations listed below.

Enforce Multi-Factor Authentication

If external-facing RDP must be utilized for operational purposes, at a minimum, multi-factor authentication
should be enforced for connectivity. This can be accomplished either via the integration of third-party
multi-factor authentication technologies or by leveraging a Remote Desktop Gateway and Azure Multi-
Factor Authentication Server using RADIUS (https://docs.microsoft.com/en-us/azure/active-
directory/authentication/howto-mfaserver-nps-rdg).

Leverage Network Level Authentication

For external facing RDP servers, Network Level Authentication (NLA) provides an extra layer of pre-
authentication before a connection is established. NLA is also useful to protecting against brute force
attacks, which often target open internet-facing RDP servers.

NLA can be configured either via the User Interface (UI) (reference Figure 28) or via Group Policy
(reference Figure 29).

Figure 28: Enabling NLA via the UI

Using Group Policy, the setting for NLA can be configured 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
o Enabled

Figure 29: Enabling NLA via Group Policy

Some caveats about leveraging NLA for RDP:

• The Remote Desktop client v7.0 (or greater) must be leveraged
• NLA utilizes CredSSP to pass authentication requests on 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.
• On the RDP server, users permitted for remote access using RDP must be assigned the "Access
this computer from the network" privilege. This privilege is often explicitly denied for user
accounts to protect against lateral movement techniques (reference Figure 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 systems using RDP (reference Figure 30).

This can be enforced using Group Policy, configurable via the path of:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights
Assignment > Deny log on through Terminal Services

Figure 30: Group Policy configuration for restricting highly privileged domain and local administrative accounts
from leveraging RDP
AppLocker
AppLocker is a set of inherent configuration settings within a Microsoft Active Directory domain which
provide lockdown and control mechanisms on endpoints. If an identified ransomware variant is rapidly
spreading throughout an environment, and consistently is executing malicious files from a specific
directory, using Group Policy, AppLocker can be utilized as containment measure – to deny the execution
of binaries based upon specific attributes or file path conditions.

Using AppLocker, the following types of rules can be configured in Group Policy:

• Publisher rule: Can be leveraged to allow or restrict execution of files based upon digital
signatures and other attributes.
• Path rule: Can be leveraged to allow or restrict file execution or access based upon files residing
in specific path.
• File hash rule: Can be leveraged to allow or restrict file execution based on a file’s hash.

To configure an example AppLocker ruleset to restrict access to any files attempting to execute or write
content within the “c:\ransomware” directory, the following process can be utilized.

• Create a Group Policy, and configure:

o Computer Configuration > Policies > Windows Settings > Security Settings > Application
Control Policies > AppLocker > Executable Rules
▪ Create New Rule
• Action: Deny (Everyone user or group)
o Path
▪ c:\ransomware
• After creating the Path deny rule (and accepting the default permit rules), the settings
represented in Figure 31 should be present.

Figure 31: Sample AppLocker Executable Rules

• The executable path rules now need to be enforced within the Group Policy (reference Figure
32).
o Right click AppLocker > Properties
▪ Click “Configured” for Executable Rules

Figure 32: AppLocker enforcement of Executable Rules

• For the AppLocker policy to be enforced, the Application Identity service must be running on an
endpoint (reference Figure 33). This can also be configured within the same Group Policy where
AppLocker policy settings are enforced (reference Figure 34).
o Computer Configuration > Policies > Windows Settings > Security Settings > System
Services
▪ Application Identity
• Select service startup mode:
o Automatic
 Figure 33: AppLocker Rule Enforcement requirements

Figure 34: Application Identity Service Properties via Group Policy

• Once the Group Policy is linked to the appropriate OU where the scope of computer objects
reside, the configured policy should take effect – and any files attempting to execute within the
specified directory will be blocked (reference Figure 35).

Figure 35: AppLocker enforcement - blocking of executables within a specified path

This can be further verified by reviewing the Event Log on an endpoint.

o Event Viewer > Applications and Services Logs > Microsoft > Windows > AppLocker >
EXE and DLL
▪ Event ID 8004

Figure 36: AppLocker Event ID 8004

AppLocker Whitelisting Using PowerShell
Rather than blacklisting a specific file (based upon known attributes), PowerShell can be leveraged to
create, fine tune, and optimize AppLocker whitelisting policies.

To list the available PowerShell related AppLocker functions, the command referenced in Figure 37 can
be utilized.

Get-Command -Module AppLocker

Figure 37: PowerShell command to list AppLocker functions

The “Get-AppLockerFileInformation” can be used to enumerate files in a directory to determine the

specific AppLocker rule types that can be leveraged (reference Figure 38). For the ransomware
scenario, assuming that the directory “c:\ransomware” contains legitimate files that should not be blocked
from being executed on a system, the directory can be quickly enumerated to identify the specific files
and file attributes for whitelisting.

Get-AppLockerFileInformation –Directory “c:\ransomware” -Recurse

Figure 38: Get-AppLockerFileInformation command - to enumerate files within the "c:\ransomware" directory

The output of the file (displayed in GridView) is provided in Figure 39.

Figure 39: Output from the "Get-AppLockerFileInformation" command

AppLocker whitelisting rules can be quickly created by using the “Get-AppLockerFileInformation”

command and piping the output to the “New-AppLockerPolicy” function. For the example command
sequence depicted in Figure 40, the “c:\ransomware” folder will be enumerated and a new AppLocker file
hash and publisher Policy will be created within the context of the “ransomware-folder-whitelist.xml” file.

Get-AppLockerFileInformation -Directory "c:\ransomware" -Recurse | New-

AppLockerPolicy -RuleType Hash,Publisher -User Everyone -RuleNamePrefix ransomware-
folder-whitelist -XML | Out-File c:\ransomware-folder-whitelist.xml
Figure 40: AppLocker whitelist hash and publisher rule creation - based upon enumerating contents of the
"c:\ransomware" directory

Using the newly created AppLocker whitelisting policy, the rule can be tested against a binary that is not
part of the whitelist - to verify that once the policy is enforced, the binary will be blocked from executing
(reference Figure 41 and Figure 42).

Test-AppLockerPolicy -XMLPolicy "C:\ransomware-folder-whitelist.xml" -Path

"c:\ransomware-proof-of-concept\ransomware.exe"
Figure 41: AppLocker rule verification command

Figure 42: Output of the "Test-AppLockerPolicy" command

Once the rules have been thoroughly tested and optimized, the XML file can be imported as an
AppLocker policy within a Group Policy (reference Figure 43).

Figure 43: Importing a previously created AppLocker policy within Group Policy

AppLocker Cautions
• The default executable rules created by AppLocker (reference Figure 31) do restrict access for
file executions for non-administrative users. The default rules will only permit files to be executed
from the “Program Files” and “Windows” folders (and subfolders). This could impact functionality
on endpoints if files attempt to execute from additional paths on the endpoint. This configuration
should be tested and vetted prior to enforcing on a large scope of endpoints.
• For Windows 8.1 (and above) – if AppLocker “Executable Rules” are enforced, “Packaged app
Rules” must also be enforced. If “Packaged app Rules” are not configured and enforced, the
Windows Start Menu and other functionality will be impacted on the endpoint.
o It is recommended to use the “Create Default Rules” for “Packaged app Rules” – and
then enforce these rules as part of an AppLocker policy (reference Figure 44 and Figure
45).

Figure 44: Packaged app Rules – “Create Default Rules” for AppLocker

Figure 45: Packaged app Rules - Rule Enforcement within an AppLocker Policy
Modify NTFS Permissions using Group Policy
While AppLocker can provide protections for executables, if a specific ransomware variant is consistently
copying or writing files to a specific directory, as a short-term containment tactic, Group Policy can be
leveraged to modify NTFS access/write permissions to a specific folder. Using the previous example of a
ransomware variant leveraging the “c:\ransomware” folder for copying and staging files on endpoints, the
following Group Policy configuration can be leveraged to restrict access to this folder on all endpoints.

• Create a Group Policy, and configure:

o Computer Configuration > Policies > Windows Settings > Security Settings > File System
▪ Right click – “Add File”
• Folder: C:\ransomware

Figure 46: Add a file or folder configuration

o Edit the NTFS Permissions – and assign the “Everyone” group

with “Deny” permissions for the folder. Note – this
configuration will deny all accounts access to the folder
(and subsequent contents) – so proceed with caution before
implementing this configuration.

Figure 47: Denying the "Everyone" group access to a folder

• Once the Group Policy is linked to the appropriate OU where the scope of computer objects
reside, the configured policy should take effect – and any access to the folder (and subsequent
contents) will be denied.
 Figure 48: Access Denied based upon Group Policy folder restrictions

Recovery and Reconstitution

Domain Controller Isolation
An isolated Domain Controller can be leveraged for full recovery and reconstitution of an Active Directory
database in the event that a large scale outbreak has impacted the availability of other Domain
Controllers within the enterprise. In the event of an active and ongoing ransomware outbreak, it may
become necessary to quickly isolate and contain a Domain Controller. This isolation tactic is especially
important if other Domain Controllers in the environment become encrypted and are unavailable, or data
within the Active Directory database file (ntds.dit) becomes corrupted.

To quickly isolate a Domain Controller, an organization may need to physically (or virtually) disconnect
the network adapter for the Domain Controller, so that the server is no longer accessible via the network.
While the Domain Controller is offline, this will protect the entire server from being compromised or
impacted by a ransomware variant.

If isolation and protection of the Active Directory database file (ntds.dit) is required, the Repadmin
command line tool can be leveraged to disable replication to/from peer Domain Controllers within the
environment.

To verify the current replication settings for a Domain Controller, the command referenced in Figure 49
can be utilized (from an elevated command prompt).

Repadmin /options <Domain Controller>

Figure 49: Command to display Repadmin options

To disable both inbound and outbound replication for a Domain Controller, the commands referenced in
Figure 50 can be utilized.

repadmin /options <Domain Controller> +DISABLE_OUTBOUND_REPL

repadmin /options <Domain Controller> +DISABLE_INBOUND_REPL
Figure 50: Commands to disable inbound and outbound replication from a specific Domain Controller

Once disabled, displaying the Repadmin options should reflect the newly enforced DSA Options (Figure
51).

Figure 51: Output of the enforced replication configuration for a Domain Controller

To re-enable both inbound and outbound replication (after an outbreak has been contained), the
commands referenced in Figure 52 can be utilized.

repadmin /options <Domain Controller> -DISABLE_OUTBOUND_REPL

repadmin /options <Domain Controller> -DISABLE_INBOUND_REPL
Figure 52: Commands to enable inbound and outbound replication from a specific Domain Controller

Note – another method that could be leveraged for an Active Directory database recovery is based upon
the concept of delayed replication. Essentially, this method leverages a replication schedule that only
synchronizes a Domain Controller once or twice a week. Microsoft Support does not recommend this
method as a disaster recovery or isolation strategy. Hotfixes, patches, and service packs will often
detect the state of delayed replication as a malfunction, and attempt to correct the replication schedule. In
addition, Microsoft Exchange Server is not designed to operate in a site with delayed replication, may not
function properly when attempting to replicate with a Domain Controller configured in this manner.

Backups
Once the full scope of the ransomware infection has been identified, and the proper containment actions
have been implemented to reduce the likelihood of the event impacting additional systems – specific
endpoints may need to either be rebuilt, or completely sanitized of any malware and potential backdoors
that an attacker was leveraging. Additionally, data may need to be restored and external facing
infrastructure may need to be hardened to prevent an attacker from regaining access into the
environment.

When needing to utilize backups to recover data is the only option, an organization must first ensure that
they have a solid backup plan and strategy to guarantee the availability and integrity of the data that
needs to be reconstituted. Organizations should ensure that they abide by the parameters outlined
below:

• Offline backups – ensure that a copy of data backups are stored separately from online /
production backups and data
• Encryption - backup data should be encrypted both during transit (over the wire) and when at rest
or mirrored for offsite storage.
• Configure alerting for critical operations - backup products and technologies should detect and
provide alerts for operations that are critical to the availability and integrity of data (ex: deletion of
backup data, purging of backup metadata, restoration events, media errors).
• Data Retention - backup products and technologies should ensure that backups are retained for a
minimum period-of-time before overwriting or purging data.
• Enforce role-based access control – Access to backup media and the applications that govern
and manage data backups should utilize role-based access controls, to restrict the scope of
accounts that have access to data elements and configuration parameters. Ideally, access to
retained data should utilize unique accounts per function (ex: financial data, customer data,
employee data) – to limit and restrict data access and exposure to specific backup accounts
based upon data labeling and mappings.
• Testing and verification – An organization should periodically test and verify that data can be
restored and reconstituted from both online and offline media sources.
Domain Controller Recovery
Unfortunately, a ransomware outbreak can result in the necessity to fully recover a Domain Controller, or
in more extreme cases, fully recover an Active Directory forest. A high-level overview of best practices for
backing up and restoring Domain Controllers are provided below.

Note – if all Domain Controllers are not impacted, rather than attempting to perform a non-authoritative
restore (reference below) – an organization can likely resume with domain authentication by building new
virtual or physical servers - and promoting the newly built server(s) to a Domain Controller. This is the
most efficient method for reconstituting domain authentication if all Domain Controllers were not impacted
by the ransomware event.

Building a New Server for Domain Controller Promotion

The steps below outline the process for promoting an existing or newly built Windows Server 2012 R2
system to a Domain Controller:

• Server Manager > Manage > Add Roles and Features

o Role-based or feature-based installation
▪ Select the server
• Add the “Server Role” of “Active Directory Domain Services”
o Additionally – the following components will also be installed:
▪ DNS Services
▪ DFS Namespaces Services
▪ DFS Replication Services- Replication Services
▪ Group Policy Management

Post installation of the role, the option to promote the system to a Domain Controller will be available via
Server Manager.

• In the top right corner, a Warning label will appear.

o Clicking this icon will yield the option to “Promote this server to a Domain Controller”.
• The Active Directory Domain Services Configuration Wizard will begin.
o To add a Domain Controller to the existing domain – choose the option for “Add a new
domain controller to an existing domain”.
▪ Provide credentials for a domain account with either DSRM (local admin), Domain
Admin, Schema Admin, or Enterprise Admin permissions.
• Domain Controller options will provide additional Domain Controller capabilities that may be
required.
o DNS Server
o Global Catalog Server
o Read-Only Domain Controller (RODC)
• For Additional Options – choose “Replicate from any Domain Controller” (or a specific Domain
Controller can be specified)
• Once the Wizard process has completed, Windows will perform prerequisite checks. If the account
used to promote the server does not have sufficient privileges (Schema Admin or Enterprise
admin), then the promotion will fail.
o If successful, a reboot will be required.

FSMO Roles - Seize and Transfer

If a newly built and promoted Domain Controller is replacing an offline Domain Controller, seizing and
transferring of the Flexible Single Master Operations (FSMO) roles will likely be required. To determine
the Domain Controller(s) that are currently assigned FSMO roles, the command referenced in Figure 53
can be invoked from an elevated command prompt on a Domain Controller.

netdom query fsmo

Figure 53: Command to query FSMO roles in a domain

The command will output a listing of Domain Controllers that hold the following roles:
• Schema Master
• Domain naming master
• PDC
• RID Pool Manager
• Infrastructure Manager

If an offline Domain Controller holds one of the FSMO roles, additional steps must be taken to seize and
transfer those roles to an online and functioning Domain Controller.

The PowerShell command to seize and transfer the “Naming Master” role is referenced in Figure 54.
Move-ADDirectoryServerOperationMasterRole -Identity <NewDC> -OperationMasterRole
domainnamingmaster -Force
Figure 54: PowerShell command to seize and transfer the Naming Master role

Additional parameters that can be specified via the OperationMasterRole switch:

• schemamaster
• domainnamingmaster
• pdcemulator
• ridmaster
• infrastructurema

The ntdsutil command can also be leveraged to facilitate the FSMO seizure and transfer process:
• ntdsutil > roles
o Connect to the Domain Controller for which the roles will be transferred
▪ Connections > Connect to server <NewDC> > quit
o From the “fsmo maintenance” prompt:
▪ For the Schema Master role, type “seize schema master” and press Enter.
▪ For the Domain Naming Master role, type “seize naming master” and press Enter.
▪ For the RID Master role, type “seize rid master” and press Enter.
▪ For the PDC Emulator role, type “seize pdc” and press Enter.
▪ For the Infrastructure Master role, type “seize infrastructure master” and press
Enter.

Removing Stale Domain Controllers

If a Domain Controller has been impacted by ransomware and will not be directly restored, the Domain
Controller must be removed from the domain. There are three methods that can be leveraged.

Active Directory Users and Computers (ADUC) Console:

• Via the Active Directory Users and Computers (ADUC) console
o Domain Controllers OU
▪ Right-click the Domain Controller to be removed and then select “Delete”

Active Directory Sites and Services Console:

• Via Active Directory Sites and Services console
o expand the Sites object and locate the Domain Controller
▪ Right-click the NTDS Settings (under the Domain Controller) and then click
“Delete”

Ntdsutil:
• Ntdsutil
 o metadata cleanup
▪ Connections > Connect to server <NewDC> > quit
o operation target
▪ list domains
• select domain <-number>
o List sites
▪ select site <-number>
• list servers in site
o select server <-number>
▪ remove selected server

Domain Controller Backups

To restore and reconstitute an Active Directory environment if no Domain Controllers are available or
online, backups of the Active Directory database must be accessible.

To backup the Active Directory database on a Domain Controller, a system state backup must be
executed. For Windows 2008 +, the system state backup can be conducted via the User Interface,
command line, or leveraging third-party backup software technologies.

To backup the system state on a Domain Controller using the User Interface, leverage the “Windows
Server Backup” feature within Server Manager (reference Figure 55). Note – “Windows Server Backup”
must be installed as a feature on the Domain Controller.

Figure 55: Server Manager - Windows Server Backup

On the Select backup configuration page – choose Custom. On the Select Items for Backup screen, click
Add Items and select System State. It is recommended to backup System State data to an external data
source, for offline storage.

Alternatively, the command “wbadmin” can be leveraged via an elevated command prompt to initiate a
System State backup on a Domain Controller (reference Figure 56).

wbadmin start systemstatebackup -backuptarget:<targetDrive>:

Figure 56: "wbadmin" command

Non-Authoritative Domain Controller Restoration

When a single Domain Controller is restored, there are two restore methods available:
 • Non-authoritative restore - the newly restored Domain Controller allows for other in-site Domain
Controllers to update its database due to the Domain Controller likely being offline for a certain time
period.
• Authoritative restore - the new restored Domain Controller claims itself as the only one with correct
information and a valid database, and it authoritatively updates other Domain Controllers with its
own data.

To perform a non-authoritative restore from a System State backup:

• From an elevated command prompt – run the command referenced in Figure 57 – or reboot the
Domain Controller and Press F8 during reboot and choose “Directory Services Restore Mode”
(DSRM).
bcdedit /set safeboot dsrepair
Figure 57: Command to reboot a Domain Controller for a non-authoritative restore

• Reboot the Domain Controller

o Once the Domain Controller has rebooted, log on either locally or remotely, and supply the
DSRM password that was set when promoting the server to a Domain Controller. The
username for the DSRM account is “administrator”.

• From an elevated command prompt – run the command referenced in Figure 58 to list the available
System State backups to restore from. Identify the version identifier for the backup that will be
used for recovery.
wbadmin get versions

Figure 58: Command and output when listing available System State backup

• Execute the command in Figure 59 to begin the restoration process.

wbadmin start systemstaterecovery –version:10/25/2018-20:47
Figure 59: Command to restore a Domain Controller from a System State backup

• Reboot the system when prompted.

o Log back on using the DSRM password and a command prompt dialog confirming that the
system state recovery operation completed successfully should be displayed.

• From an elevated command prompt – run the command referenced in Figure 60Figure 57.
bcdedit /deletevalue safeboot
Figure 60: Command to reboot from safeboot mode following the non-authoritative restore

Authoritative Domain Controller Restoration

To perform an authoritative restore from a System State backup:

• From an elevated command prompt – run the command referenced in Figure 43 – or reboot the
Domain Controller and Press F8 during reboot and choose DSRM.

• Reboot the Domain Controller

o Once the Domain Controller has rebooted, log on either locally or remotely, and supply the
DSRM password that was set when promoting the server to a Domain Controller. The
username for the DSRM is “administrator”.
• Leverage the “Windows Server Backup” feature within Server Manager (reference Figure 41).
Select the “Recovery Wizard” option, then select the media where the backup is stored and ensure
that the correct System State backup date is selected.

• Via the Wizard, check the option for “Perform an authoritative restore of Active Directory files”
(reference Figure Figure 61).

Figure 61: Authoritative Restore option

• Note – selecting this option during a System State restore does not affect objects in the Active
Directory database – and this option will not restore Active Directory objects that have been
deleted. Rather, checking the box will mark the Domain Controller's copy of SYSVOL as
authoritative. The local Domain Controller's copy of the SYSVOL folder will become the master
copy for the domain once the Domain Controller is rebooted out of DSRM, and any online Domain
Controllers will copy its contents into their own SYSVOL folders.
o If the box is not checked, any changes made to SYSVOL since the backup was made will
be copied to the local Domain Controller when it is rebooted into normal mode.
o When recovering deleted Active Directory objects by restoring a Domain Controller's
system state, Ntsutil must be used to mark the objects as authoritative after the restore is
complete and before the DC is rebooted out of DSRM.
o This option is useful when repairing a corrupt SYSVOL folder, but it should be used
with caution, as it can result in domain-wide loss of SYSVOL data if the SYSVOL
folder in the local Domain Controller's System State backup is corrupt or
incomplete.

• Alternatively, to perform an authoritative restore of specific Active Directory objects, following the
steps above and do not select the option for “Perform an authoritative restore of Active Directory
files”.

• Restart the Domain Controller, select Press F8 and choose DSRM and login with the DSRM
account.

• Open an elevated command-prompt – and execute the Ntdsutil command referenced in Figure 62.
ntdsutil: authoritative restore
Figure 62: Ntdsutil - authoritative restore mode

• If the entire Active Directory database must be marked as authoritative, execute the command
referenced in Figure 63.
authoritative restore: restore database
 Figure 63: Ntdsutil - authoritative restore of an entire Active Directory database

• If only certain objects must be restored as authoritative (ex: deleted OU), execute the command
referenced in Figure 64.
authoritative restore: restore subtree <distinguished name--DN--of subtree, ex:
OU=users,DC=testdomain,DC=local>
Figure 64: Ntdsutil - authoritative restore of specific Active Directory objects

• Exit Ntdsutil by typing “quit”

• Restart the Domain Controller back to normal mode.

Additionally, if an authoritative restoration is occurring from a snapshot or full system (non-system state)
backup of a Domain Controller, the following process should be followed.

• From an elevated command prompt – run the command referenced in Figure 57 – or reboot the
Domain Controller and Press F8 during reboot and choose “Directory Services Restore Mode”
(DSRM).

• Reboot the Domain Controller

o Once the Domain Controller has rebooted, log on either locally or remotely, and supply the
DSRM password that was set when promoting the server to a Domain Controller. The
username for the DSRM account is “administrator”.

• On the Domain Controller, run the command Regedt32 and browse to the registry path noted in
Figure 65.
HKLM\SYSTEM\CurrentControlSet\Services\ NTDS\Parameters
Figure 65: Registry path for modification
o Add the following Dword (32-bit) value noted in Figure 66. This key will allow the DNS
zone for the domain to load without having to wait for peer replication partners (Domain
Controllers).
Repl Perform Initial Synchronizations
Value = 0

Figure 66: DWord value for the key "Repl Perform Initial Synchronizations"

• Browse to the registry path noted in Figure 67.

HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
at Startup
Figure 67: Registry path for modification
o Change the Dword (32-bit) value for “BurFlags” to “d4”, which sets the Domain Controller
to be Authoritative (reference Figure 68).

Figure 68: Dword value for the key "BurFlags" for an authoritative Domain Controller

• Reboot the Domain Controller.