Networking & Shells Update
Today we updated and revised Chapter 9 of the VHL course material: Networks & Shells. This chapter is about initiating reverse shells and binding shells after obtaining code execution on a target. In this chapter you will learn various methods to initiate a reverse shell, mainly using tools already present on the target host, such as Bash, PowerShell, cmd.exe and various scripting and programming languages. In this chapter you will also learn how to establish a bind shell on a compromised host, also known as a backdoor.
The Virtual Hacking Labs courseware PDF is also updated with the new content. You can download the updated PDF from your user account with an active membership for the PT01 or PT02 course.
Reverse Shells
When you have compromised a target and can execute code or commands on the target system, a payload resulting in a command line shell is the most obvious way to gain direct control of the machine. Depending on the network situation and restrictions, you can opt for a bind shell or a reverse shell for this purpose. Let’s have a look at a situation where you would use a reverse shell. The following network diagram shows an internal network and DMZ separated from the internet by a firewall. The firewall prevents outside access to machines on the internal network but allows access to port 443 on the web server in the DMZ area of the network. In this case, an outside attacker cannot directly access machines on the internet network but can access the web application running on the web server with IP address 10.10.1.2.
When the attacker compromises the web application on the web server in the DMZ and has code execution, a reverse shell would be the best way to get command line access to the web server. In this scenario, the reverse shell payload will be executed on the web server, which connects back to the attacker through the firewall and over the internet. The attacker must consider that network or host-based firewalls can block outgoing (egress) connections. For this reason, it is wise to use an outgoing port for the reverse shell payload that is unlikely to be blocked, such as port 80 or port 443. The attacker then listens for incoming connections from the web server using a (Netcat) listener that can intercept the reverse shell, in this example, on port 80. The following diagram shows how the web server on the DMZ network connects back to the attacker on 14.16.17.18 port 80.
In this scenario, a bind shell would not work because the attacker would not have access to the port to which the bind shell would be bound. The attacker can only access the web server through the firewall on the port configured by the firewall, in this case, port 443. Because only one service can be active on a port, it is impossible to connect the bind shell to port 443 if the web server is active.
PT01 and PT02 Penetration Testing Course
Interested to learn more about reverse shells, bind shells and other penetration testing techniques? Sign up for the VHL PT01 Penetration Testing course and check out chapter 9 of the courseware. Are you interested in more advanced techniques? Such as port forwarding, (multi level) pivoting, relaying shells and using proxies? Check out the VHL PT02 Penetration Testing course with the Pro Labs.
