Purple teaming — Understand Pivoting
Pivoting is a crucial step in the adversaries’ strategies to further compromise a targeted environment and bypass strong perimeter defenses. This involves the abuse of an infected host to advance their intrusion into other network segments, systems, and services that are not accessible directly from the Internet
While pivoting is of significant importance to attackers, it remains relatively unpopular among cyber defenders. In this blog post, we will delve deeper into the concept of pivoting, and the ways it poses a significant threat to organizations.
P/s: in the previous article, I discussed in detail one pivoting technique via SMB-named pipe (https://medium.com/@tho-le/threat-hunting-pivoting-via-smb-named-pipe-44f5f9b45b7b)
How Pivoting Works
Pivoting represents a tactical maneuver adopted by malicious actors to bypass strong perimeter defenses. Once an adversary successfully gains entry into a target system, they often encounter roadblocks as sensitive services may be concealed from direct Internet exposure. Pivoting offers them a way to advance through the network, utilizing compromised hosts as intermediaries to access sensitive systems which are only accessible from a certain network or jump host. By “hopping” between these stepping stones, adversaries can mask their tracks and prolong their presence, complicating detection efforts for cybersecurity professionals.
The figure below illustrates 2 scenarios for pivoting.
- Scenario 1: the attacker abuses the beachhead to access services. For example, he can access shared files or internal websites to gather information. This scenario mostly relies on local and dynamic port forwarding to relay traffic between Kali and crown jewel servers via Beachhead.
P/s: In addition to proxying traffic, attackers may opt for an alternative approach by utilizing the beacon to execute a utility within the Beachhead via process injection. For instance, rather than executing a Winrm tool directly from their local Kali machine, they can inject a .NET assembly of the Winrm tool for PowerShell remoting to the targeted server. - Scenario 2: the attacker can establish a foothold on a crown jewel server and remotely control the server. This allows the attacker to further advance their movement to deeper network segments. This scenario mostly relies on reverse/remote port forwarding or abuse of Windows services to intermediate their movement (I explained Pivoting via SMB Named Pipe in the previous article)
Pivoting Simulation
To illustrate the concept of pivoting, I have configured a lab environment as in the figure above. The lab involves pivoting toward the crown jewel server (192.168.1.2) to showcase potential exploitations: (1) port scanning (2) Accessing shared files (3) PowerShell remoting via Winrm (4) Surfing internal websites (5) Tunneling Remote desktop (6) Reverve port forwarding to hop to the crown jewel server
I will use SliverC2 to establish a C2 tunnel to Beachhead as well as port forwarding; however, many other C2 frameworks or tools offer similar functionalities.
- Port scanning (Scenario 1)
Upon gaining access to the beachhead, adversaries perform reconnaissance via port scanning to discover other systems and available services.
For convenience, I will use “socks5” to dynamically forward all traffic from Kali via Beachhead. Kali will listen on port 1081.
In Kali, I update the proxychain configuration to use the newly created socks5 proxy 127.0.0.1:1081.
From Kali, nmap was executed to scan a few ports targeting the jewel server (192.168.1.2).
As expected, the SliverC2 beacon in Beachhost relays all Nmap traffic from Kali to the crown jewel server.
2. Accessing shared files (Scenario 1)
Adversaries may use automated tools and/or manually inspect shared files to gather information and exfiltrate data. For example, they may look for *.sql file to understand the structures of databases and tables.
For simulation purposes, I leverage Impactket’s smbclient.py to access shared files from the crown jewel server.
As can be seen from TCPView, “SPARKLING_LADDER.exe”, the SliverC2 beacon, is responsible for SMB traffic toward 192.168.1.2
3. PowerShell remoting via Winrm (Scenario 1)
PowerShell remoting has become a preferred choice for adversaries seeking fileless lateral movement. This article illustrates how these malicious actors can exploit PowerShell remoting to achieve remote code execution.
Since Sliver’s socks5 is not really reliable, I manually set up a local port forwarding for Winrm (port 5985). Upon executing the “portfwd add” command, Kali will listen on 127.0.0.1 port 5985, and all traffic toward 127.0.0.1:5985 will be relayed at Beachhead toward the crown jewel server (192.168.1.2)
evil-winrm, an available tool in Kali, is used to PowerShell remoting to the crown jewel server. For demonstration, only “ipconfig” command was executed, but any PowerShell commands/functions can be executed.
Similar to previous tests, the SliverC2 beacon is responsible for Winrm traffic (port 5985) toward 192.168.1.2
4. Surfing internal websites
Another abuse scenario involves leveraging the established foothold to conduct reconnaissance on internal websites, including Confluence, Jira, SharePoint, Git repositories, and more.
From port scanning, we know that there is a web service open in the crown jewel server via port 8080. In order to avoid changing the proxy configuration of my browser in Kali, I set up the local port forwarding for port 8080 as below. Otherwise, you can just update the browser’s proxy to the socks5 proxy set up in test (1).
Using Kali, I can gain access to the website hosted on the crown jewel server via the Beachhead, which is otherwise inaccessible directly from the Internet.
5. Tunneling Remote desktop (Scenario 1)
Remote desktop is one of the favorite methods to remotely access a compromised host. The port scanning in test case (1) reveals an open RDP service on the crown jewel server. Hence, adversaries can hop to the server by relaying RDP traffic via Beachhead
Similarly, I create another local port forwarding for RDP traffic as below:
using the “Rdesktop” tool, I can remote desktop to remote server from Kali
7. Reserve port forwarding to hop to the crown jewel server (Scenario 2)
Previously, I explained the concept of pivoting via named pipe in the article Threat hunting Pivoting via SMB Named Pipe. For more information, please refer to that article. In this test, we will explore another possibility via reverse/remote port forwarding.
In a nutshell, Beachead will listen on a random port that is not registered by any other processes. In this example, I instruct the beacon in Beachhead to listen for Sliver C2 traffic on port 1025 and forward those traffic toward my Sliver C2 server (Kali).
As can be seen from the figure above, another implant for TCP pivot was generated, namely SILLY_MENTION.exe. There are multiple options to deliver this newly created beacon to the crown jewel server. In this test, I will use impacket’s smbclient.py to upload the file and execute it via PowerShell remoting (which were presented in tests (2) and (3) above).
Firstly, I access the shared “Users” folder and put SILLY_MENTION.exe on the server.
evil-winrm is used to run the TCP pivoting beacon via PowerShell remoting
Upon execution of “SILLY_MENTION.exe”, a new session was shown up in the Sliver server console. From now on, the adversaries have established their control on the crown jewel server. They may abuse this server, similar to Beachhead, in order to further advance their footprint to deeper network segments.
