Pivoting Between Corporate IT and OT Networks with Network Shell

Often during a penetration test, one of the primary objectives is to find a way to pivot from the corporate network to the operational technology (OT)/SCADA networks. The reason for this objective is that it is unlikely that an adversary can cause an operational impact with access limited to the corporate IT networks.

While pivoting to OT networks is not a trivial task, it is often aided by poor security hygiene like weak network perimeters and shared credentials. For example, in 2021, 77% of Dragos’ service engagements included a finding about improper network segmentation and 44% included a finding related to shared credentials between IT and OT systems. This blog explores one way an adversary may leverage the Network Shell (Netsh) utility to exploit weak network segmentation and gain access to OT networks.

What is Network Shell?

Network Shell, or Netsh, is a command-line utility included in Microsoft’s Windows NT line of operating systems beginning with Windows 2000 up to the most recent releases of Windows 10 and Server 2019. Netsh was commonly used to support troubleshooting network issues such as resetting the TCP/IP stack to default, or to change the IP address of a machine. Administrative level access is required to use Netsh to make network interface configuration changes such as adding firewall rules.

In newer operating systems, Microsoft has recommended replacing Netsh with Windows PowerShell to manage networking technologies. Even though PowerShell is recommended and more commonly used on modern Windows operating systems, Netsh can still be commonly found on many systems today.

The Pentest

With an understanding of the Netsh utility, we can now discuss how it can be applied to support lateral movement between networks, especially between the corporate and OT/SCADA environments. To provide context, we will use a penetration test scenario as an example where our team was placed inside of the corporate network with an objective to find a way into the OT/SCADA DMZ.

After performing active directory reconnaissance and enumeration, we identified a group called “SCADA Security” that had Remote Desktop (RDP) privileges into the OT/SCADA DMZ. Additionally, referencing the firewall rules that segmented the corporate network and the OT/SCADA DMZ, we noted RDP rules that allowed incoming traffic on port 3389 (RDP) from specific IP addresses (SCADA Security group) into the environment. With our level of access as domain administrator and our knowledge of the network, we had a variety of options at our disposal to meet our objective

Living Off the Land

The Netsh approach was chosen for this situation to showcase how an adversary could blend in with the environment, minimize their chances of triggering security alerts by “living off the land”, and maintain a degree of persistence. With our level of access, it was tempting to simply masquerade as a user in the SCADA Security group to RDP directly into an OT/SCADA DMZ asset, but there were potential risks to consider from an offensive perspective. Masquerading as a user could potentially kick them off from their active session, triggering a security alert or drawing suspicion to our actions. Since we knew the firewall rules were based on static IP addresses, we decided to login to a computer that was part of the SCADA Security group as a domain administrator and create a Netsh port-proxy firewall rule.

The Netsh rule, as shown in Figure 2, configured the host to listen on port 49897 and forward traffic from the corporate network, through the victim host (192.168.10.10) to an asset in the OT/SCADA DMZ (10.10.10.25) on port 3389 (RDP). With the firewall rule configured on the victim computer in the corporate network, all we needed to do was spawn an RDP session directed at the victim computer (192.168.10.10) configured with port 49897.

The victim computer redirected the RDP session from our corporate workstation right into the OT/SCADA DMZ environment, prompting us with a login screen.

Blending In With Netsh

Netsh can be used to maintain a degree of persistence and depending on the configuration, a certain level of obfuscation. The degree of persistence will depend on the compromised host; a user workstation that reboots daily will wipe clean any Netsh rules that were configured on the host. On the contrary, if a Windows server that rarely reboots is compromised, any Netsh rules created may persist if the server is running. Also, depending on how the Netsh rule is configured, a certain level of obfuscation can be achieved; Windows computers tend to have ephemeral ports listening anywhere in the range of 47001 to 49700 to support various RPC services.

The picture above is the netstat command executed from the compromised host (victim) in the scenario. Netstat is short for Network Statistics, and it’s a Windows utility to display statistics for all network connections. Highlighted is the Netsh rule we created earlier to listen on port 49897, note how difficult it may be for one to quickly identify any misconfigurations on a system just by viewing listening ports.

Identifying Netsh

With our newfound perspective of the Netsh utility, one might consider the potential use cases especially when considering adversarial objectives. For example, an adversary that has compromised a network could leave behind a chain of Netsh port-proxies to help them achieve a level of access assurance. Despite the potential implications of Netsh, asset owners and security professionals do have options to defend against such attacks.

Executing the netstat command with the -b option will display the service tied to the listening port, and in the case of Netsh, the iphlpsvc service will be displayed. One drawback to this approach is that the iphlpsvc service may correspond to legitimate services used for networking purposes and may also be time consuming. PowerShell can be used to identify at scale the configuration of port-proxy rules by querying the registry with the following command:

Additionally, network monitoring solutions can provide a centralized approach by incorporating asset characterization combined with traffic analyzers and threat detectors to yield a more comprehensive view of the environment.

In Conclusion

Netsh is just one example of how a native Windows utility can be leveraged to support a malicious purpose. Leveraging native tools, also known as Living Off the Land Binaries (LOLBins), are popular techniques used amongst adversaries to support their operations. Utilizing native Windows utilities may help adversaries to bypass security restrictions and support their overall Operations Security (OPSEC) strategy. Although it may appear that adversaries have the advantage, defenders do have options to identify and defend against the malicious use of LOLBin such as Netsh.

One example of a potential indicator is RDP connections utilizing unconventional ports. The Dragos platform can distinguish connections utilizing nonstandard RDP ports with the capability to identify potential Netsh proxies by correlating follow on connections. Incorporating a holistic approach to security by including centralized networking and host-based monitoring solutions coupled with a robust defense in depth strategy may help to identify malicious use of legitimate utilities.