AES Shellcode Crypter/Decrypter | Linux x86_64

 

Introduction

The Advanced Encryption Standard (AES) is a symmetric block cipher encryption algorithm that uses the same key (also known as secret-key) for encryption and decryption where each cipher encrypts and decrypts data in blocks of 128-bit using cryptographic keys of 128-bit, 192-bit and 256-bit, respectively. AES consist of multiple modes of operation to preform encryption some of which requires random Initialization Vector (IV). In this post we’ll look at shellcode encryption/decryption using AES with 128-bit key and Electronic Codebook (ECB) mode of operation.

Crypter

We will have pycrypto python library do all of the heavy lifting for us. I did add two lambdas one line functions to pad the plaintext and base64 encode the final ciphertext.

Decrypter

The decrypter first base64 decode the ciphertext and then decrypt it to reproduce the original plaintext that is the shellcode. Once the shellcode is restored we will use ctypes python library to execute it.

I’ve created execve() shellcode that spawns /bin/sh to test with.

Let’s test the scripts using the above shellcode.

If you would like to convert the above python scripts to an executable, please refer to my SLAE32 series where I use pyinstaller to preform said conversion.

Closing Thoughts

In this post we learned about AES and how powerful python can be. This post marks the end of my SLAE64 series, I hope you enjoyed it and learned something along the way. All of the above code are available on my github. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

Student ID: SLAE64 – 1579

Polymorphic Shellcode | Linux x86_64

Introduction

In general polymorphism mean the ability to appear in many forms, it’s also referred to as a feature of object-oriented programing in computer science. In this post we will take three sample shellcodes off of exploit-db and mutate them in order to beat pattern matching. The final shellcode size should be less or equal to 150% of the original shellcode. Please refer to my SLAE32 series to learn more about polymorphism.

Shellcode I

The first shellcode we’ll look at issues power off command via reboot() function and its 19 bytes in size which means we have up to 28 bytes of space.

The following is the final polymorphic shellcode with a size of 27 bytes.

Shellcode II

The second shellcode we’re going to play with changes the hostname to "Rooted !" via sethostname() function and then terminate every process for which the calling process has permission to send signals to using kill() function. The original shellcode size is 33 bytes which leave us with 49 bytes.

The final shellcode size is 38 bytes.

Shellcode III

The last shellcode generates infinite child processes using fork() function which will effectively render the system unavailable. The original shellcode size is 11 bytes meaning we need to stay below 16 bytes.

I was able to shrink down the final shellcode size to 7 bytes which is 4 bytes less  than the original one. Defiantly an improvement compared to the other two.

Closing Thoughts

This post was a good opportunity for me to explore new functions that might come in handy in the future. All of the above code are available on my github. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

Student ID: SLAE64 – 1579

Analyzing MSFVenom Payloads with Binary Ninja | Linux x86_64

Introduction

In efforts to learn more about Binary Ninja, we will be taking apart three shellcode samples generated via msfvenom. Please note that disassemblers in general including Binary Ninja are fairly new to me and as such this will be a learning experience to me as much as it will be to you.

Shellcode I

First, we’ll look at exec option and generate payload that will run whoami command.

Will use the comment section in Binary Ninja to explain the shellcode as I feel it would be easier to digest this way.

Shellcode II

Next, we will be looking at stage-less reverse shell with localhost IP address and default port of 4444.

Let’s disassemble it.

Shellcode III

Lastly, will dissect stage-less bind shell that listen on all interfaces on port 4444 (default).

And the analysis.

Closing Thoughts

I really like Binary Ninja and plan on using it more often moving forward. All of the above binaries are available on my github. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

Student ID: SLAE64 – 1579

[ROT-N + Shift-N + XOR-N] Shellcode Encoder | Linux x86_64

Introduction

Encoding schemes are used to transform data in a way that makes it consumable by different systems in a safe manner. In this post we’ll look at how we can bypass AVs by ab(using) this scheme to encode otherwise detectable shellcode.

Shellcode

We will be porting an x86 encoder I made a while back exploit-db to make it work with x86_64. Please refer to my SLAE32 series for more details on the encoder. I’ve also made a quick execve() shellcode to test with.

The encoder (python script) pretty much stays as is, all we need is feed it our newly created  /bin/sh shellcode and generate an encoded version of it.

Here’s Decoder.asm ported to x86_64 including previously generated encoded shellcode.

Let’s run it.

Out of curiosity, I decided to compare my x86 encoded shellcode VT results (taken at the time the original x86 encoder was created) with x86_64 one and I found the results quite interesting.

x86 VT Results
x86 VT Results
x86_64 VT Results
x86_64 VT Results

Closing Thoughts

The VT results clearly shows that AV vendors don’t care much for x86_64 shellcode at this point in time which is another good reason why we should use it more. All of the above code are available on my github. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

Student ID: SLAE64 – 1579­

Egg Hunter | Linux x86_64

Introduction

Egg hunter is a technique used to capture larger payloads in memory by tagging the start of the shellcode with an egg. In most cases, egg hunters are used when you don’t have enough space to host your desired shellcode. In this post we’ll create an egg hunter for Linux x86_64 and couple it with execve() shellcode for testing. Please refer to my SLAE32 for more details about egg hunting.

Shellcode

In efforts to experiment with skape awesome piece of shellcode, we will create a slightly different version of egg hunter that does the following:

  • No hardcoded egg marker which will effectively eliminate the need for the second egg marker check.
  • Use a readable memory region as starting address which allow the exclusion of memory access check routine.

As you can see this method is indeed unsafe compared to skape’s but hey it works!

And as always we follow with a demo.

Closing Thoughts

On behalf of all the shellcoders out there, I would like to say thank you skape for producing such an elegant shellcode that will remain glorious for years to come. All of the above code are available on my github. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

Student ID: SLAE64 – 1579­

Password Protected TCP Reverse Shell (IPv6) | Linux x86_64

Introduction

In this post we will create a custom TCP reverse shell for Linux x86_64 architecture that requires password to spawn a shell. This post is a continuation of Password Protected TCP Bind Shell | Linux x86_64 and since my SLAE32 series include an in-depth analysis of the functions used in reverse shells we won’t spend too much time there.

Shellcode

I decided to create an IPv6 reverse shell this time around for two reasons, the first being I haven’t done any before! and the second is for some reason msfvenom don’t have one for x86_64 so the final shellcode could be of use to somebody, maybe.

Creating an IPv6 reverse shell is not rocket science, all we need is use AF_INET6 as domain when calling socket() function and use IPv6 structure to specify what IP and port we want amongst other things (I used localhost ::1 in this case). Lastly, we need to accommodate for the structure length when calling connect() function using RDX register.

The following is the final null-free shellcode. Please refer to the link of my previous post in the introduction section to learn more about read() function used in the password check routine.

Now its demo time.

Closing Thoughts

I did learn a thing or two about IPv6 addressing while crafting this shellcode and I hope you did too. All of the above code are available on my github or exploit-db. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

Student ID: SLAE64 – 1579­

Password Protected TCP Bind Shell | Linux x86_64

Introduction

In this post we will create a custom TCP bind shell for Linux x86_64 architecture that requires password to spawn a shell. We wont be going into too much details on how each function work as this has already been discussed in my previous Creating Custom TCP Reverse Shell | Linux x86 post.

Shellcode

If you’re not familiar with x86_64 assembly its pretty much the same as x86 from shellcoding standpoint. The following are the key add-ons (I should say) that you get when using x86_64 assembly as opposed to x86:

I used read() function to check for input via stdin and then compare it to a predefined password (in this case I used “pwnd”), if the check fails the shellcode will jump to “_nop” section which will effectivly cause the bind shell to crash. Please refer to the link in the introduction section for more in-depth analysis of the functions used by the bind shell. The following is the final null-free shellcode.

Now comes that fun part, let’s test out the shellcode.

Closing Thoughts

I feel passwords are essential when it comes to bind shells and hope this post will benefit folks looking to create one. All of the above code are available on my github. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel . This post is one of many to come so stay tuned!

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

Student ID: SLAE64 – 1579­