Internal Reconnaissance Protection using NetCease and SAMRi10

What is Internal Reconnaissance?

Internal reconnaissance is one of the first steps an attacker will take once they have compromised a user or computer account in your network. Using various tools or scripts, they enumerate and collect information that will help them identify what assets they should try to compromise next to get what they want. For example, BloodHound will map out attack paths that can enable an adversary to escalate their privileges from ordinary user to admin.

Almost all common enumeration methods can be executed by an unprivileged user, which makes them extremely hard to detect and block. In this post, I will explain how to use to defend against two types of internal reconnaissance:

• Session enumeration by unprivileged users
• Queries to the MS-SAMR protocol

Types of Reconnaissance

To find information about the network they have penetrated, attackers often enumerate the following types of data:

• Sessions — To find out who is logged on where
• Users — To understand all users in the domain, ideally with their group membership
• Groups — To see all groups in the domain, ideally with their membership
• Active Directory access control lists  (ACLs) — To understand which security principals (such as users and groups) can access which resources
• Local group membership — To see who has access rights on the machine (especially who has administrative rights)

Blocking Session Enumeration with NetCease

This blog post focuses on session enumeration, which enables an adversary to determine where user and service accounts are logged in. That information helps them prioritize which hosts to attempt to compromise first — such as hosts that have an administrator logged in.

Note: The default permissions in Windows 10 have been changed to stop attackers from performing session enumeration; however, it is still worth checking.

NetCease is a short PowerShell script that helps prevent session enumeration by changing the Registry key that controls the NetSessionEnum method permissions. (The reason why this is completed using a script rather than manually is because the key, SrvsvcSessionInfo, is editable only in a reg binary value.) Here is the path to the SrvsvcSessionInfo key:

Path: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/DefaultSecurity

The default value of the SrvsvcSessionInfo registry key is the ACL that allows use of the NetSessionEnum method. This is assigned to the following:

• Member of Administrators
• Member of Server Operators
• Member of Power Users
• Authenticated Users

The Authenticated Users permission enables attackers to perform session reconnaissance using any compromised user account.

What the NetCease script does is back up the current registry value and then amend the permissions, so the following ACEs are in the ACL:

• InteractiveSid
• ServiceSid
• BatchSid
• Administrators
• Server Operators
• PowerUsers

Checking the ACL

If you want to view the security descriptor, you can use the following PowerShell snippet, which will show you the ACL:

#Registry Key Information
$key = "HKLM:SYSTEMCurrentControlSetServicesLanmanServerDefaultSecurity"
$name = "SrvsvcSessionInfo"

#Get the Registry Key and Value
$Reg_Key = Get-Item -Path $key
$BtyeValue = $reg_Key.GetValue($name, $null)

#Create a CommonSecurityDescriptor Object using the Byte Value
$Security_Descriptor = New-Object -TypeName System.Security.AccessControl.CommonSecurityDescriptor -ArgumentList $true, $false, $ByteValue, 0

#Output of the ACL to make it simple to see for document. Use only $Security_Descriptor.DiscretionaryAcl if you want to see the full ACL!
$Security_Descriptor.DiscretionaryAcl | Select-Object SecurityIdentifier, ACEType | Format-Table -AutoSize

Output before running NetCease:

Output after running NetCease:

Note: Information on well-known SIDs can be found here.

Testing Session Enumeration

An easy way to test whether you have blocked session enumeration by ordinary user accounts is to use the NetSess tool from Joeware.net, but there are plenty of other options, including SharpHound. When doing this, make sure that you are using a user account that is not a member of Administrators, Server Operators or Power Users.

Output before using NetCease

Netsess.exe [Computer]

Output after using NetCease using an unprivileged account

Netsess.exe [Computer]

Output after using NetCease with a privileged user account

Netsess.exe [Computer]

Blocking Reconnaissance using Remote SAM (SAMR)

Attackers can perform reconnaissance using the SAMR protocol, which can remotely query devices but can also query Active Directory. Using SAMR, an attacker without any administrative privileges can find highly privileged groups and users, as well as local users and groups for every system on the network. Tools such as BloodHound can then automatically map this information into attack paths to compromise Active Directory.

Microsoft introduced protections for querying SAMR with Windows 10, and in 2017 added updates for previous operating systems down to Windows 7 and Server 2008 R2 using the RestrictRemoteSAM registry key. This key is a string (REG_SZ) that will contain the SDDL of the security descriptor that protects Remote SAM calls.

In the anniversary edition of Windows 10 (1607) and Windows Server 2016 and later, the default SDDL was changed to allow only local administrators to query Remote SAM.

Below is a table breaking down the requirements, default behavior and protection options for all operating systems:

There are three ways to set the RestrictRemoteSAM registry key:

• Registry
• Group Policy
• SAMRi10 (Samaritan)

Let’s review each of them.

Registry Option

The RestrictRemoteSAM registry key is available for administrators to update as they wish:

Path:     HKLM/System/CurrentControlSet/Control/Lsa

Name: RestrictRemoteSAM

Default value (SDDL) in Windows 10:   O:SYG:SYD:(A;;RC;;;BA)

Components of the SDDL

As you can see, the default value that Windows 10 sets is SYSTEM for Owner and Primary Group and Read Control for Built-in Administrators.

Checking the SDDL before applying it

To check that the SDDL is correct before applying the change, you can use the ConvertFrom-SDDLString command in PowerShell to convert it to a security descriptor that is easier to read.

Group Policy or Local Security Policy Option

The Group Policy and Local Security Policy settings enable administrators to set this key easily. This can work well for administrators who want to set the same value across every system or multiple groups of systems (e.g., allowing Remote SAM connections for all servers in a specific OU or a certain set of application servers).

The details about the setting are as follows:

SAMRi10 (Samaritan) Option

SAMRi10 is a PowerShell script that offers a key benefit over the previous options: It creates a new local group and delegates access for the group to be able to perform Remote SAM calls. This makes it possible for administrators to control this functionality fully in Group Policy Preferences, or to manually grant it to accounts when required.

The SAMRi10 script does the following:

1. Creates a local group called “Remote SAM Users”
2. Amends the SDDL to include the newly created group:
   • If there is no default SDDL, then grant access to Built-in Administrators.
   • If an SDDL exists, then amend it to include the new ACE for the Remote SAM Users group.

Benefits of using SAMRi10

• Easy to grant granular access for Remote SAM access
• Helps organizations that want to enforce least-privileged access
• Can be used in conjunction with a local group membership Group Policy to grant users access centrally using item-level targeting
• Can be used by a privileged access management (PAM) system to easily grant dynamic (just-in-time) access if an account or process requires this specific permission

Defending against Reconnaissance with Netwrix Solutions

Netwrix StealthAUDIT includes an attack path analyzer that provides admins with insight into their Active Directory ACLs so they can plug any gaps before adversaries exploit them. Netwrix StealthINTERCEPT can monitor LDAP queries and then pass them to Netwrix StealthDEFEND, which can detect multiple reconnaissance scenarios and queries out of the box, including BloodHound, queries for all SPNs, and queries for all accounts with password never expires.

FAQ

What is internal reconnaissance and why should you care?

Internal reconnaissance occurs when attackers who’ve already gained initial access to your network start mapping out your environment to find valuable targets. They’re not breaking in anymore – they’re already logged in and looking around. This is where most security strategies fall short, focusing on perimeter defenses while attackers move freely inside using legitimate credentials.

The reality is straightforward: you can’t protect what you can’t see, and you can’t control what you don’t understand. Internal reconnaissance is the critical phase where attackers gather intelligence about your Active Directory structure, identify high-value accounts, and map out paths to your most sensitive data. Data security starts with identity, and that means preventing attackers from enumerating your identity infrastructure in the first place.

How do you implement NetCease for session enumeration protection?

NetCease blocks session enumeration attacks by preventing unauthorized users from listing active sessions on your domain controllers and servers. Implementation is straightforward but requires planning. First, download NetCease from the official repository and verify you’re running it on a system with PowerShell 5.1 or later.

Prerequisites:

• Administrative privileges
• PowerShell 5.1 or later
• Windows Server or domain-joined system

The tool works by modifying registry settings that control how the Windows Server service responds to session enumeration requests. Run NetCease with administrative privileges on each server you want to protect, starting with non-critical systems for testing. The changes take effect immediately without requiring a reboot, but you should validate that legitimate administrative tools and monitoring solutions still function properly.

Best practice is to implement NetCease gradually across your environment rather than deploying it everywhere at once. Start with servers that don’t host business-critical applications, monitor for any disruptions, then expand to domain controllers and other high-value targets. Remember that preventing reconnaissance isn’t about making your network invisible – it’s about making attackers work harder and giving your detection systems more time to identify malicious activity.

What’s the difference between SAMRi10 and Group Policy SAM restrictions?

SAMRi10 and Group Policy both restrict access to the Security Account Manager (SAM) database, but they work at different levels and serve different use cases. SAMRi10 is a PowerShell script that directly modifies registry settings on individual machines, giving you granular control over SAM access restrictions on specific systems.

Group Policy SAM restrictions work at the domain level, allowing you to push consistent policies across multiple systems simultaneously. The Group Policy approach is better for large-scale deployments where you need uniform protection across many machines. SAMRi10 is ideal for specific servers, test environments, or situations where you need custom configurations that don’t fit standard Group Policy templates.

The technical implementation differs too. SAMRi10 modifies the RestrictRemoteSAM registry key directly, while Group Policy uses the administrative template system to achieve the same result. Both methods are effective, but SAMRi10 gives you more flexibility for troubleshooting and custom configurations. For most organizations, a hybrid approach works best: use Group Policy for baseline SAM restrictions across the domain, then use SAMRi10 for specific systems that need additional hardening.

How do you verify that reconnaissance protection measures are working?

Testing your reconnaissance protection requires a methodical approach that simulates real attacker techniques without disrupting operations. Start with basic session enumeration tests using tools like NetSess or PowerShell’s Get-WmiObject commands from a non-administrative account. If NetCease is working correctly, these attempts should fail or return limited information.

For SAM restrictions, test remote access to the Security Account Manager database using tools like enum4linux or rpcclient from a Linux system, or net use commands from Windows. Properly configured SAM restrictions should block unauthorized enumeration attempts while still allowing legitimate administrative access.

The key is testing from the attacker’s perspective. Create test accounts with standard user privileges and attempt common reconnaissance techniques such as domain enumeration, share discovery, and user account listing. Document what works and what doesn’t, then adjust your protection measures accordingly. Remember that effective security isn’t about blocking everything – it’s about controlling what information is available to whom while ensuring legitimate business functions continue to operate properly.

When should you rollback NetCease and SAMRi10 changes?

Rollback scenarios typically involve compatibility issues with legitimate administrative tools, unexpected application failures, or business process disruptions that weren’t identified during testing. NetCease and SAMRi10 both provide rollback options, but the process differs for each tool.

For NetCease, rollback involves reversing the registry modifications that control session enumeration. The tool includes parameters to restore original settings, but you should always document the baseline configuration before making changes. Test the rollback process in a lab environment first to ensure you understand the steps and timing involved.

SAMRi10 rollback is more complex because it involves multiple registry keys and potentially Group Policy interactions. If you’ve implemented SAM restrictions through Group Policy, use the policy management tools to reverse changes. For direct registry modifications, SAMRi10 includes restoration functions, but manual verification is essential to ensure complete rollback.

The best approach is proactive: implement changes during maintenance windows, have rollback procedures documented and tested, and monitor affected systems closely for at least 24-48 hours after implementation. Most compatibility issues surface quickly, but some may only become apparent during specific business processes or system operations.

Joe Dibley

Security Researcher at Netwrix and member of the Netwrix Security Research Team. Joe is an expert in Active Directory, Windows, and a wide variety of enterprise software platforms and technologies, Joe researches new security risks, complex attack techniques, and associated mitigations and detections.