Obfuscated Shellcode, the Wolf in Sheep’s Clothing (Part 3)

If you missed the other articles in this series please read:

We saw in part two of this article series that intrusion detection system vendors will use the presence of the NOP aka 0x90 sled as a component when building signatures for buffer overflow exploits. Though it is not the only component of the signature it is one, which most network security analysts readily recognize. This brings us to the point where we will cut out the 0x90 and put some other function, or character in its place. Our goal in doing this is to see how the intrusion detection system will react. Will it still see it as a buffer overflow attempt, or will it not? During my research into this interesting area of exploit development I came across a list of idempotent substitutions that was provided by Dragos Ruiu of Cansecwest fame. It is from this list that we will choose to build our newer, and stealthier sled.

If you recall our old NOP sled looked like this:

/* bindshell no RPC crash, defineable spawn port */
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90”
    “\x90\x90\x90\x90\x90\x90\x90\xeb\x19\x5e\x31\xc9\x81\xe9\x89\xff”










So with the partial list noted below we will build ourselves a new sled with a different function. Namely we will use 0x42, or as seen below the “inc %edx” function. EDX is a general purpose register in assembly and the “inc” stands for increment. The “inc” and its opposite function “dec” are widely used in assembly programming. The list seen below can be viewed in its entirety here. Please note that the first column seen below refers to the system architecture ie: IA32 is Intel Architecture 32 bit. The second column refers to the actual hex value for the instruction. The column after is the actual assembly instruction ie: inc %eax means that the value in the eax register will be incremented, and the last column is the instruction represented in ASCII.

IA32 27 daa
IA32 2f das /
IA32 33 c0 xor %eax,%eax
IA32 37 aaa 7
IA32 3f aas ?
IA32 40 inc %eax @
IA32 41 inc %ecx A
IA32 42 inc %edx B
IA32 43 inc %ebx C
IA32 44 inc %esp D
IA32 45 inc %ebp E
IA32 46 inc %esi F
IA32 47 inc %edi G
IA32 48 dec %eax, H
IA32 4a dec %edx J

Well we will now build our new sled, and test it against our lab box with Snort running once again, to see what it will alert on. First though let’s see what our newly obfuscated sled looks like:

/* bindshell no RPC crash, defineable spawn port */
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42\x42”
    “\x42\x42\x42\x42\x42\x42\x42\xeb\x19\x5e\x31\xc9\x81\xe9\x89\xff”










You have to be very careful here when you change the previous 0x90 to another idempotent function such as the 0x42. You must make sure that you put in the exact same amount of them for you don’t want to write over some other valid code by accident. Should you do so the code may not work, as originally intended. So now that the new sled has been written, and the code successfully compiled, it is time to try it against Snort again.

[**] [1:2351:8] NETBIOS DCERPC ISystemActivator path overflow attempt little endian [**]

[Classification: Attempted Administrator Privilege Gain] [Priority: 1]

01/28-11:15:21.861046 192.168.1.102:1045 -> 192.168.1.101:135
TCP TTL:64 TOS:0x0 ID:798 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0xB498EE5  Ack: 0x7B4CD8CA  Win: 0x5B4  TcpLen: 32
TCP Options (3) => NOP NOP TS: 12684682 1849


[Xref => http://cgi.nessus.org/plugins/dump.php3?id=11808][Xref => http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2003-0352][Xref => http://www.securityfocus.com/bid/8205]

Well we can see from the above generated alert that Snort did indeed see this newly stealthed exploit as an overflow attempt. Was it because of the character 0x42 repeating so many times in a row, or that this is a known overflow character to Snort? Well to answer our own question let’s try and further obfuscate the sled with several various other idempotent instructions. We will pick the other ones from the list that I included several paragraphs above. We will use these other ones to seed our sled with. Our goal will be to avoid too many repetitions in a row.

Having now compiled this new and improved exploit we use it against the lab box with success in so much as we once again obtain system level access. More importantly though in this case is, does Snort realize what is happening? Yes, indeed Snort does pick this up as another overflow attempt with the exact same signature seen above. This in spite of us having used various functions to rebuild our sled. Where does this leave us then? The goal of doing this shellcode obfuscation was to try and fool the intrusion detection system, but that has not worked. The reality of it is that the changes we have done would have fooled a good many network security analysts. I have seen some fooled for they chalk up the packets that were logged, as a result of a binary transfer.

Just as I alluded to earlier though the presence, or lack thereof a NOP sled it is not the only trigger for an overflow signature. There are other factors that go into creating a signature such as destination port, ascii signature, or a hexadecimal signature. Take for example the Blaster worm. This had the MS03-026 vulnerability as an exploit. One of the key building blocks for a signature for it was the following:

46 00 58 00 4E 00 42 00 46 00 58 00 46 00 58 00 F.X.N.B.F.X.F.X.

4E 00 42 00 46 00 58 00 46 00 58 00 46 00 58 00 N.B.F.X.F.X.F.X.

The ascii string of “F X N B F X F X” seen above appears in the actual packet that performs the attack. This was quickly built into a signature, and performed quite well. I can attest to that as we still get boxes compromised at a network I work with, and we are alerted to them by this signature.

Shellcode obfuscation tools

There are programs that were written that take this into account, and will rewrite the exploit code itself. This allows for IDS evasion, as now the ascii string, and sled, are both changed altogether. One of the first programs to do that was ADMutate written by K2, a Canadian security researcher. This program is not for those new to computer security, or exploit code. It requires a fair amount of knowledge to use. Other programs also are dissembler and asc.c. They will do much the same thing as ADMutate with varying methodology.

It’s a wrap

With the testing that we have now done we realize that the intrusion detection systems out there today do a reasonably good job. They will detect attacks based upon signatures, which the attack code itself has. Should you try and change various parts of that exploit code such as we did, the intrusion detection system (IDS) may still pick it up. Bearing that in mind, some of the security researchers out there have come up with more novel ways of stealthing such attacks as buffer overflows. My entire point, or theme, in writing this article series is to stress proper training. It is very important to receive training so that you can identify threats when you see them. Failing that, it is up to you to try and play with these types of tools in your home lab in an effort to keep your skills up to date. The computer security threat landscape is an ever changing one, and you must try to keep up with it. I sincerely hope that you found this article of use, and should you have any questions please do not hesitate to contact me.

If you missed the other articles in this series please read:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top