--- title: Core OS - Network Stack & Lateral Movement slug: core-os-network-stack-and-lateral-movement docTags: createdAt: 2026-10-19T19:51:50.036Z --- # Enterprise *** ## ESM Security Setting - Network Bridge Policy **Description**: \[coming soon] **Why It's Important**: \[coming soon] **Learn More** - \[coming soon] *** ## ESM Security Setting - Require secure RPC communication **Description**: Specifies whether a Remote Desktop Session Host server requires secure RPC communication with all clients or allows unsecured communication. You can use this setting to strengthen the security of RPC communication with clients by allowing only authenticated and encrypted requests. If the status is set to Enabled, Remote Desktop Services accepts requests from RPC clients that support secure requests, and does not allow unsecured communication with untrusted clients. If the status is set to Disabled, Remote Desktop Services always requests security for all RPC traffic. However, unsecured communication is allowed for RPC clients that do not respond to the request. If the status is set to Not Configured, unsecured communication is allowed. Note: The RPC interface is used for administering and configuring Remote Desktop Services. **Why It's Important**: This setting helps protect the system by making sure that any remote management traffic is encrypted and authenticated. It blocks untrusted or unsecured connections that could be used by attackers to control or spy on the system. Think of it like requiring a secure, verified phone line for sensitive conversations—so no one can eavesdrop or impersonate someone else. It’s a key part of keeping remote access safe and locked down. **Learn More** - [RemoteDesktopServices Policy CSP | Microsoft Learn](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-remotedesktopservices?WT.mc_id=Portal-fx#remotedesktopservices-requiresecurerpccommunication) *** # Privileged *** ## PSM Security Setting - Multicast Name Resolution Policy **Description**: Specifies that link local multicast name resolution (LLMNR) is disabled on client computers. LLMNR is a secondary name resolution protocol. With LLMNR, queries are sent using multicast over a local network link on a single subnet from a client computer to another client computer on the same subnet that also has LLMNR enabled. LLMNR does not require a DNS server or DNS client configuration, and provides name resolution in scenarios in which conventional DNS name resolution is not possible. If you enable this policy setting, LLMNR will be disabled on all available network adapters on the client computer. If you disable this policy setting, or you do not configure this policy setting, LLMNR will be enabled on all available network adapters. **Why It's Important**: This policy is like disabling a public intercom system that lets anyone on the network respond to name requests. By turning off LLMNR, SHIELD reduces the risk of spoofing attacks where malicious devices impersonate legitimate ones to intercept traffic or credentials. It helps enforce stricter name resolution practices and ensures that only trusted DNS infrastructure is used, improving overall network security. **Learn More** - [ADMX\_DnsClient Policy CSP | Microsoft Learn](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-dnsclient?WT.mc_id=Portal-fx#turn_off_multicast) *** ## PSM Security Setting - Smart Multi Homed Name Resolution Policy **Description**: Specifies that a multi-homed DNS client should optimize name resolution across networks. The setting improves performance by issuing parallel DNS, link local multicast name resolution (LLMNR) and NetBIOS over TCP/IP (NetBT) queries across all networks. In the event that multiple positive responses are received, the network binding order is used to determine which response to accept. If you enable this policy setting, the DNS client will not perform any optimizations. DNS queries will be issued across all networks first. LLMNR queries will be issued if the DNS queries fail, followed by NetBT queries if LLMNR queries fail. If you disable this policy setting, or if you do not configure this policy setting, name resolution will be optimized when issuing DNS, LLMNR and NetBT queries. **Why It's Important**: Specifies that a multi-homed DNS client should optimize name resolution across networks. The setting improves performance by issuing parallel DNS, link local multicast name resolution (LLMNR) and NetBIOS over TCP/IP (NetBT) queries across all networks. In the event that multiple positive responses are received, the network binding order is used to determine which response to accept. If you enable this policy setting, the DNS client will not perform any optimizations. DNS queries will be issued across all networks first. LLMNR queries will be issued if the DNS queries fail, followed by NetBT queries if LLMNR queries fail. If you disable this policy setting, or if you do not configure this policy setting, name resolution will be optimized when issuing DNS, LLMNR and NetBT queries. **Learn More** - [ADMX\_DnsClient Policy CSP | Microsoft Learn](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-dnsclient?WT.mc_id=Portal-fx#dns_smartmultihomednameresolution) *** ## PSM Security Setting - Hardened UNC Paths **Description**: This policy setting configures secure access to UNC paths. If you enable this policy, Windows only allows access to the specified UNC paths after fulfilling additional security requirements. **Why It's Important**: This policy is like requiring both parties to show ID before exchanging sensitive documents. By hardening UNC paths, SHIELD ensures that access to network shares is protected by strong authentication and integrity validation. It helps prevent attackers from intercepting or tampering with file transfers over the network, especially in environments. **Learn More** - [Connectivity Policy CSP | Microsoft Learn](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-connectivity?WT.mc_id=Portal-fx#hardeneduncpaths) *** ## PSM Security Setting - Driver Initialization Policy **Description**: This policy setting allows you to specify which boot-start drivers are initialized based on a classification determined by an Early Launch Antimalware boot-start driver. The Early Launch Antimalware boot-start driver can return the following classifications for each boot-start driver: - Good: The driver has been signed and has not been tampered with. - Bad: The driver has been identified as malware. It is recommended that you do not allow known bad drivers to be initialized. - Bad, but required for boot: The driver has been identified as malware, but the computer cannot successfully boot without loading this driver. - Unknown: This driver has not been attested to by your malware detection application and has not been classified by the Early Launch Antimalware boot-start driver. If you enable this policy setting you will be able to choose which boot-start drivers to initialize the next time the computer is started. If you disable or do not configure this policy setting, the boot start drivers determined to be Good, Unknown or Bad but Boot Critical are initialized and the initialization of drivers determined to be Bad is skipped. If your malware detection application does not include an Early Launch Antimalware boot-start driver or if your Early Launch Antimalware boot-start driver has been disabled, this setting has no effect and all boot-start drivers are initialized. **Why It's Important**: This policy is like inspecting every tool before it’s used to start a machine. By controlling which boot-start drivers can run, SHIELD ensures that only trusted or essential components are loaded during startup. It helps prevent rootkits and other early-stage malware from compromising the system before traditional security tools are active. This strengthens the system’s defenses at its most vulnerable point—during boot—and supports a secure foundation for the operating environment. **Learn More** - [System Policy CSP | Microsoft Learn](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-system?WT.mc_id=Portal-fx#bootstartdriverinitialization) *** ## PSM Security Setting - Unauthenticated RPC Client Restriction Policy **Description**: This policy setting controls how the RPC server runtime handles unauthenticated RPC clients connecting to RPC servers. This policy setting impacts all RPC applications. In a domain environment this policy setting should be used with caution as it can impact a wide range of functionality including group policy processing itself. Reverting a change to this policy setting can require manual intervention on each affected machine. This policy setting should never be applied to a domain controller. If you disable this policy setting, the RPC server runtime uses the value of "Authenticated" on Windows Client, and the value of "None" on Windows Server versions that support this policy setting. If you do not configure this policy setting, it remains disabled. The RPC server runtime will behave as though it was enabled with the value of "Authenticated" used for Windows Client and the value of "None" used for Server SKUs that support this policy setting. If you enable this policy setting, it directs the RPC server runtime to restrict unauthenticated RPC clients connecting to RPC servers running on a machine. A client will be considered an authenticated client if it uses a named pipe to communicate with the server or if it uses RPC Security. RPC Interfaces that have specifically requested to be accessible by unauthenticated clients may be exempt from this restriction, depending on the selected value for this policy setting. - **None** allows all RPC clients to connect to RPC Servers running on the machine on which the policy setting is applied. - **Authenticated** allows only authenticated RPC Clients (per the definition above) to connect to RPC Servers running on the machine on which the policy setting is applied. Exemptions are granted to interfaces that have requested them. - **Authenticated without exceptions** allows only authenticated RPC Clients (per the definition above) to connect to RPC Servers running on the machine on which the policy setting is applied. No exceptions are allowed. :::Paragraph{indent="1"} **Note**: This policy setting will not be applied until the system is rebooted. ::: **Why It's Important**: This policy is like requiring a verified badge before letting someone into a secure system. By restricting unauthenticated RPC clients, SHIELD ensures that only trusted, verified systems can communicate with sensitive services. It helps prevent remote attacks, blocks anonymous access, and strengthens the overall security of the operating system. This is especially important for protecting encrypted drives and maintaining the integrity of system-level communications. **Learn More** - [RemoteProcedureCall Policy CSP | Microsoft Learn](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-remoteprocedurecall) *** ## PSM Security Setting - Require secure RPC communication **Description**: Specifies whether a Remote Desktop Session Host server requires secure RPC communication with all clients or allows unsecured communication. You can use this setting to strengthen the security of RPC communication with clients by allowing only authenticated and encrypted requests. If the status is set to Enabled, Remote Desktop Services accepts requests from RPC clients that support secure requests, and does not allow unsecured communication with untrusted clients. If the status is set to Disabled, Remote Desktop Services always requests security for all RPC traffic. However, unsecured communication is allowed for RPC clients that do not respond to the request. If the status is set to Not Configured, unsecured communication is allowed. **Why It's Important**: Requiring secure RPC communication helps prevent unauthorized access and protects sensitive data during remote desktop sessions. It blocks unsecured or unauthenticated requests, reducing the risk of man-in-the-middle attacks and credential theft. SHIELD enables this policy to ensure that only trusted and secure clients can connect. It’s like requiring a verified badge before letting someone into a secure meeting—only those who meet the security standard are allowed in. **Learn More** - [RemoteDesktopServices Policy CSP | Microsoft Learn](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-remotedesktopservices?WT.mc_id=Portal-fx#requiresecurerpccommunication) *** ## PSM Edge Browser Settings - Allow Prelaunch **Description**: Allow Microsoft Edge to pre-launch at Windows startup, when the system is idle, and each time Microsoft Edge is closed. **Why It's Important**: This policy is like preventing an app from quietly starting up behind the scenes without permission. By blocking Edge prelaunch, SHIELD helps reduce unnecessary background activity, improves system performance, and ensures that browser sessions only start when explicitly initiated by the user. It also minimizes potential attack surfaces and supports tighter control over application behavior in managed environments. **Learn More** - [Browser Policy CSP | Microsoft Learn](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-Browser?WT.mc_id=Portal-fx#allowprelaunch) *** ## PSM Security Setting - Network Bridge Policy **Description**: Determines whether a user can install and configure the Network Bridge. Important: This settings is location aware. It only applies when a computer is connected to the same DNS domain network it was connected to when the setting was refreshed on that computer. If a computer is connected to a DNS domain network other than the one it was connected to when the setting was refreshed, this setting does not apply. The Network Bridge allows users to create a layer 2 MAC bridge, enabling them to connect two or more network segments together. This connection appears in the Network Connections folder. If you disable this setting or do not configure it, the user will be able to create and modify the configuration of a Network Bridge. Enabling this setting does not remove an existing Network Bridge from the user's computer. **Why It's Important**: This policy prevents users from creating or modifying network bridges on domain-connected devices. It helps maintain network integrity and security by stopping unauthorized bridging of network segments, which could expose internal resources or allow unintended traffic between networks. **Learn More** - [Connectivity Policy CSP | Microsoft Learn](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-connectivity?WT.mc_id=Portal-fx#prohibitinstallationandconfigurationofnetworkbridge) *** ## PSM Security Setting - Prohibit Use Of Internet Connection Sharing Policy **Description**: \[coming soon] **Why It's Important**: \[coming soon] **Learn More** - \[coming soon]