Cross-compilation allows you to develop for one platform (like Kali) and compile to run on a different platform (such as Windows). For developers, it means that they can work on their platform of choice and compile their code for their target platform. For hackers, it means we can compile exploit code for Windows from Kali.
The majority of available hacking tools are targeted towards Linux, assuming most hackers will be operating on some form of Linux environment. Most Linux distros include a compilation toolchain, which will happily build local exploit code for Linux targets all day. If the machine we're targeting is Windows, Metasploit has plenty of Windows exploits, but this leaves us unable to compile any Windows exploits ourselves. This is where cross-compilation comes into play.
In this article, we'll go through the installation and basic usage of MinGW-w64 on Kali Linux to compile local exploit code. The MinGW-w64 project is a complete runtime environment for GCC (GNU Compiler Collection) to support binaries native to Windows 64-bit and 32-bit operating systems.
First, we will need a root shell. Kali Linux defaults to a single root user on install. If you have made no changes to the system, you already have a root shell when you open your terminal! In my case, I will be using SSH to connect to my headless Kali system.
Before we install MinGW-w64, we will want to update our available packages and upgrade out-of-date packages on our system. This can be done by typing the following command.
apt update && apt upgrade
Some of our users may be more familiar with apt-get update && apt-get upgrade. Both of these commands would accomplish the same task. My preference is towards apt. If you haven't looked into the many features of apt, I would recommend doing some reading on it.
Once our package lists are updated and our system is upgraded, it's time to install MinGW-w64. Simply issue the command below.
apt install mingw-w64
Kali will prompt you to confirm the installation. Press enter to proceed.
Cross-compiling exploits can be challenging. Exploit code is developed in varying environments and intended to work on a specific version and patch level of the software it is targeting. Many public exploits do not work straight out of the box. When cross-compiling, you will run across bad code, shell code that needs to be swapped, and other issues. With that out of the way, let's try out our new cross-compiler.
First, the exploit code itself. The best place to grab raw exploit code when using Kali Linux is the SearchSploit tool. Exploits can also be found on the web at exploit-db.com, securityfocus.com, and on many more sites. When compiling and running pre-written exploits, it is important that you trust the source or analyze the code yourself. There are plenty of malicious exploits out there and you don't want to run into one!
First, I search using SearchSploit, by typing the following into terminal.
searchsploit -e 'windows 7'
The "e" argument specifies exact match.
In the results from my search, I can see matching exploits. Though the highlighted result is labeled as a text file by SearchSploit, it is, in fact, C code.
To copy the code into your directory, type the following command.
cp /usr/share/exploitdb/platforms/win_x86-64/shellcode/13729.txt ~/
Next, it's important to view the code before attempting compilation. I viewed the code with the command:
cat 13729.txt | less
Immediately, there is a problem. The banner in the code isn't commented out, which would lead to the compiler trying to read it, creating compilation errors. Good thing we checked.
Beyond fixing that, there's nothing special happening here. This is just basic shell code. It would give us cmd.exe. If we wanted to spice it up a bit, we could remove the existing shell code and replace it with something generated by Msfvenom, though Msfvenom can also generate to PE format.
Since we know this code won't compile without removing the banner, we will make a copy of it to edit. Type the following command in terminal.
cp 13729.txt shell.c
Next, open your favorite text editor and remove the uncommented text banner. When you have finished, your code should look like the image below.
The banner has been cleaned out, leaving behind around 40 lines of C.
To compile the code, run the command:
x86_64-w64-mingw32-gcc shell.c -o shell.exe
This command works for C files on x86 64-bit architecture. The "-o" determines the name of the compiled binary. If we were compiling for 32 bit, we would use a command that looks like this.
i686-w64-mingw32-gcc shell.c -o shell.exe
Since this code is for 64-bit machines, we use the 64-bit version of the cross compiler. MinGW comes with quite a few options for cross-compilation. In order to see a list of available compilers installed with the MinGW package, enter the following command.
apt-cache search mingw-w64
As we can see, there are quite a few options available.
The final step is to run your compiled program. I'll be testing it out on my Windows VM.
There are many ways to transfer files to your VM, but the easiest right now is simply by hosting the file on my Kali box and pointing IE at it. In order to do this, run the commands:
cp shell.exe /var/www/html/
systemctl start apache2
On your target system, navigate to http://your.kali.machine/shell.exe (with the "your.kali.machine" replaced by your Kali system's IP address). You will be presented with a prompt. Click on the save button.
Lastly, run the resulting "shell.exe" from a command prompt. When shell.exe is run, it immediately terminates, though we do see the cmd window open for a second. This could be adjusted by changing the shell code in the source and then recompiling it.
This article covers extremely basic usage of MinGW-64. Compiling exploits can be very difficult and time-consuming. Exploits found on the web can be riddled with bugs, syntax errors, even malicious code. Due to the time it takes to go through and fix broken exploit code, I usually keep working compiled exploits on my system and back them up regularly.
I usually will only cross-compile an exploit if it is absolutely necessary. Sometimes, it's less time-consuming to find another route in than it is to debug someone else's exploit code. In cases where the code is so bad it might require a near re-write in order to function in your environment, I would recommend taking some time and porting it into Metasploit. If you're already rewriting it, why not make it modular?
Stay tuned for more, you can leave any questions in the comments.