Threat hunting Pivoting via SMB Named Pipe

6 min readJul 30, 2023

Once gaining a foothold into the environment, adversaries move laterally to compromise different systems till achieving their objectives. However, most enterprise networks are heavily segmented from Internet-Accessible network segments to more restricted networks without direct Internet access. Hence, adversaries will need to leverage existing compromised systems as internal proxies to pivot to systems in restricted networks.

In this article, we simulate the pivoting via SMb Named Pipe with Sliver C2 framework and explore effective detection and threat-hunting opportunities against this attack.

The article contains 3 main parts as below:

How the attack works
Attack simulation
Detection and threat-hunting opportunities

How the attack works

As illustrated in the figure below, once the adversaries compromise a system in a targeted environment, namely Beachhead, they will need to discover the compromised environment and laterally move to different systems in order to achieve their objective, namely crown jewel servers. However, as crown jewel servers are segmented with private IPs and have no direct Internet access, the adversaries cannot interact with the crown jewel servers. To control the crown jewel servers from the Internet, attackers leverage Beachhead as an interal proxy to mediate the communication from Kali, the hackers’ own system, to the crown jewel servers.

There are many ways to relay traffic between Kali and crown jewel servers via Beachhead, such as via TCP port forwarding. In this article, we examine pivoting via named pipe since SMB is popular in Windows environments; hence, it is (1) almost always available and (2) easy to blend in normal traffic.

Attack simulation

To simulate this attack, I will use Sliver C2 framework for demonstration purposes; however, other C2 frameworks (e.g. Cobalt Strike, Metasploit, etc.) or tools can also be used. It is important to note that the direction of SMB traffic can be as in the diagram above or in the reverse direction (from Beachead to crown jewel servers) depending on C2 frameworks or tools.

below are steps to simulate the attack:

Step 1: Compromise Beachhead and setup named pipe to relay traffic

Assuming that the adversaries somehow gain the initial foothold in the environment, this could be via phishing, vulnerability exploitation and third-party compromise etc. Upon success, the adversaries execute Sliver beacon and remotely control the beachhead via HTTP traffic.

In Kali, Adversaries generate implants as below:

When Beachhead executes the implant “SPARKING_LADDER”, a session is established

Using Beachhead’s session, set up the named pipe for the pivoting purpose

as shown above, Beachhead is now listening on the named pipe: pivotingpipe to relay traffic to the Attackers’ controlled system in the Internet

Step 2: Compromise crown jewel servers with named-pipe implant

Once controlling Beachhead, attackers execute the named-pipe implant in the crown jewel server. There are multiple attack vectors for this phase. For example, if the server is outdated and has vulnerabilities, remote code execution can be achieved by exploiting a vulnerability . Another possibility is that attackers harvest an admin credential and execute code remotely via WMI, WIN RM, windows service, scheduled tasks and DCOM etc.

Upon execution of “OUTRAGEOUS_LANDSCAPE” implant in the crown jewel server, all C2 traffic from crown jewel servers is relayed via the named pipe “pivotingpipe” in Beadhead (1.1.1.1) to Kali

Detection and threat-hunting opportunities

Hypothesis: Attackers may abuse a compromised host to act as an internal proxy to relay all traffic from non-direct Internet access to a C2 server via an SMB named pipe.

below are some analytics to detect/hunt pivoting via SMB named pipe:

Analytic 1: Abnormal SMB traffic flow from restricted networks to Internet-accessible networks

Description: examine the net flow or firewall logs to detect/hunt unexpected SMB flow

SMB network connection from Zeek’s conn.log

Data source: Network flow, NDR, and Firewall logs

Analytic 2: Abnormal named pipe access from the network by detailed file share audit logs

Description: depending on your environment, accessing the named pipe remotely may not be a common behavior. Event 5145 records details of all shared access including named pipe

data source: Windows event logs 5145. Please note that this event can be noisy and is usually not configured on all Windows hosts (often only on shared file servers)

Analytic 3: Abnormal named pipe access from the network by network logs

Description: depending on your environment, accessing the named pipe remotely may not be a common behavior. Network traffic or NDR logs (e.g. Zeek) can be used to detect this behavior.

Packets showing Named pipe access on top of SMB traffic

Note: Zeek doesn’t seem to be able to parse the “end point”: pivotingpipe. (there is no smb_files.log)

Data source: network traffic and NDR logs.

Analytic 4: Abnormal named pipe access from the network by Sysmon event 18 or equivalent log

In my test, all named pipe-connected events are as below; It doesn’t have the remote IP field to indicate a remote Pipe access. The Image is System as Windows core listens to port 445 for SMB (which makes sense). This makes me question what if a process access to the named pipe locally? should it be that no SMB is required and the Named Pipe Transport protocol is run directly?

From the official page:

“Named pipes can be used to provide communication between processes on the same computer or between processes on different computers across a network. If the server service is running, all named pipes are accessible remotely. If you intend to use a named pipe locally only, deny access to NT AUTHORITY\NETWORK or switch to local RPC.”

Pipe Connected from a remote host via SMB

I tried to connect to the pipe directly via PowerShell, Event 18 shows the image as PowerShell_ISE.exe.

Pipe connected from local via PowerShell script

In conclusion, Image = system indicates Piped connect via SMB, which is our interest to detect named pipe pivoting.

In order to confirm whether the behavior is consistent, I tested the scenario with Cobalt Strike (version 4.9.1) and the result aligns with the conclusion above. rundll32.exe is the Cobalt Strike implant which created the “pivotingpipe” named pipe in the domain controller server. Then I connected to that pipe in DC-2 to remotely control it from another host.