Malware expert Ed Skoudis discusses Trojan horses, which are computer programs that appear to be benign, but really include hidden malicious code. He outlines different types of Trojan Horses and how to protect against them.

This chapter is from the book

This chapter is from the book

You might have read the last chapter on backdoors and thought to yourself,
"I'd never run a program named Netcat or VNC on my machine, so I'm
safe!" Unfortunately, it isn't that easy. Attackers with any modest
level of skill will disguise the nasty backdoors we covered in the last chapter
or hide them inside of other programs. That's the whole idea of a Trojan
horse, which we define as follows:

A Trojan horse is a program that appears to have some useful or benign
purpose, but really masks some hidden malicious code.

As you might expect, Trojan horses are called Trojans for short, and
the verb referring to the act of planting a Trojan horse is to Trojanize
or even simply to Trojan. If you recall your ancient Greek history,
you'll remember that the original Trojan horse allowed an army to sneak
right through a highly fortified gate. Amazingly, the attacking army hid inside
a giant wooden horse offered as a gift to the unsuspecting victims. It worked
like a charm. In a similar fashion, today's Trojan horses try to sneak past
computer security fortifications, such as firewalls, by employing like-minded
trickery. By looking like normal, happy software, Tro-jan horse programs are
used for the following goals: Duping a user or system administrator into
installing the Trojan horse in the first place. In this case, the Trojan horse
and the unsuspecting user become the entry vehicle for the malicious software on
the system.

Blending in with the "normal" programs running on a machine. The
Trojan horse camouflages itself to appear to belong on the system so users and
administrators blithely continue their activity, unaware of the malicious
code's presence.

Many people often incorrectly refer to any program that gives remote control
of or a remote command shell on a victim machine as a Trojan horse. This notion
is mistaken. I've seen people label the VNC and Netcat tools we covered in
the last chapter as Trojan horses. However, although these tools can be used as
backdoors, by themselves they are not Trojan horses. If a program merely gives
remote access, it is just a backdoor, as we discussed in Chapter 5. On the other
hand, if the attacker works to disguise these backdoor capabilities as
some other benign program, then we are dealing with a true Trojan horse.

Attackers have devised a myriad of methods for hiding malicious capabilities
inside their wares on your computer. These techniques include employing simple,
yet highly effective naming games, using executable wrappers, attacking software
distribution sites, manipulating source code, coopting software installed on
your system, and even disguising items using polymorphic coding techniques. As
we discuss each of these elements throughout this chapter, remember the
attackers' main goal: to disguise their malicious code so that users of the
system and other programs running on the system do not realize what the attacker
is up to.

In this chapter, we'll discuss both widely used and cutting-edge
techniques. Keep in mind, however, that attackers are a creative and devious
lot. They use the concepts we'll discover, but tweak them in innumerable
ways to achieve maximum subterfuge.

What's in a Name?

'Tis but thy name that is my enemy.

William Shakespeare, Romeo and Juliet

At the very simplest level of Trojan horse techniques, an attacker might
merely alter the name of malicious code on a system so that it appears to belong
on that machine. By giving a backdoor program the same name of some other
program you'd normally expect to be on your system, an attacker might be
able to operate undetected. After all, only the lamest of attackers would run
malicious code using the well-known name of that code, such as Netcat or VNC.
Don't get me wrong, however. If a really dimwitted bad guy attacks my
system and uses techniques that I can easily spot, I'm all for it. That
makes my job easier. I'm perfectly happy to catch any attacker when he or
she makes a mistake of that magnitude, and, thankfully, I have found several
instances of attackers calling a backdoor Netcat or even VNC. However, we
can't expect all of our adversaries to make such trivial errors, so
let's investigate their naming games in more detail.

Playing with Window Suffixes

One very simple Trojan horse naming technique used by attackers against
Windows systems is to trick victims by creating a file name with a bunch of
spaces in it to obscure the file's type. As you no doubt know, the
three-letter suffix (also known as an "extension") of a file name in
Windows is supposed to indicate the file's type and which application
should be used to view that file. For example, executables have the .EXE suffix,
whereas text files end in .TXT. The information security business has done a
good job over the last decade of informing our users not to run executable
attachments included in e-mail or those that appear on their hard drive.
"Unknown EXE files cause trouble," we lecture our users, with furled
eyebrows and a deep voice to emphasize the importance of this lesson. So, given
users' fright and awe in the presence of EXE files, how could a malicious
executable program be disguised as something benign, such as a simple text file?
An attacker could confuse a victim by naming a file with a bunch of spaces
before its real suffix, like this:

just_text.txt .exe

That .EXE at the end of the name after all of the spaces makes the program
executable, but the unwary user might not notice the .EXE suffix. If users look
at such a file with the Windows Explorer file viewer, it'll appear that
the file might just be text, as shown in Figure
6.1. For comparison to a benign file, the first line in Figure 6.1 shows
a normal text file, with a normal text file icon and a file type of Text Document.
Most users would have no qualms about double-clicking such a nice-looking, happy
file. The second line, however, is far more evil. It shows an executable file
with a name of just_text.txt .exe. Note that the display shows the name of the
file as just_text.txt" followed by "...". Those innocent looking
dots mean that the file name is actually longer than what is displayed.

Of course the Explorer file viewer shows the second file's type as
Application and displays an executable's icon next to the name instead of a
text file icon. Still, the vast majority of users would never notice these
somewhat subtle distinctions. If this is a huge concern for the attackers, they
could even configure the system so that an executable program type's icon
actually appears as a .TXT icon. This can be accomplished by altering the icon
using one of a variety of tools, such as the free E-Icons program available at
http://www.deepgls.com/eicons/.
Alternatively, an attacker could choose a file type that is both executable
and has an icon that looks quite similar to a text file, such as the
Shell Scrap Object file type, with an .SHS extension. These .SHS files are used
to bundle together commonly copied and pasted text and pictures, as well as
commands, for various Windows programs. The third line of Figure 6.1 shows a
typical .SHS file. The fourth line of the figure shows a combination of these
techniques: an .SHS file is given a name of just_text.txt .shs, which includes
several spaces to make it appear as a .TXT file. You can easily see how a user
could get duped into executing this type of file.

Numerous file suffixes could be used to deliver and contain malicious code on
a target machine. Table 6.1 shows the different file types developers use to
hold binary, scripts, and other types of executable code. Many, but certainly
not all, of these script types are tied to Windows machines, as the Windows
operating system is freakishly obsessed with a file's type being stored in
the suffix. However, the phenomenon is not limited to Windows. On UNIX systems,
some program types are also indicated with a suffix, including .SH, .PL, and
.rpm files. It's important to note, however, that UNIX doesn't put any
special meaning into a file's suffix, unlike Windows. In Windows, the
operating system uses the suffix to determine which application to use when
opening a document. On UNIX machines, this suffix is just a handy reference for
users; UNIX won't run a specific application based merely on the

file suffix. Still, any one of these file types in Table 6.1 could be abused
to spread malicious code. For a detailed description of any type of file suffix,
you can refer to the very handy Filext Web site, at
http:// filext.com/.

A UNIX shell script or shell archive file, used to carry
sequences of commands for a UNIX shell, usually the bourne shell (sh) or bourne
again shell (bash)

There sure are many suffixes that could contain executable code
of some form. Your users are not going to be able to memorize every single item
in this massive list. Still, they should be wary of the biggies that are most
often abused by bad guys, such as .EXE, .COM, .BAT, .SCR, and .VBS.

Mimicking Other File Names

These Trojan horse naming issues go beyond just putting a bunch of spaces
between the name and its file extension on Windows systems. We've just
barely scratched the surface. Often, to fool a victim, attackers create another
file and process with exactly the same name as an existing program installed on
the machine, such as the UNIX init process. Init normally starts running all
other processes while the system boots up. In this type of naming attack, you
could actually see two processes named init running on your system: your normal
init that's supposed to be there, and another Trojan horse named init by
the attacker. This is a particularly bizarre circumstance, kind of like waking
up and finding that you have two noses.

Similarly, on a Windows machine, you could notice that there are two running
processes called System Idle Process. A bunch of such naming schemes are
possible. Table 6.2 lists common programs expected to be running on Windows and
UNIX operating systems whose names are frequently borrowed by attackers for
malicious code.

It is hugely important to note the following: There are supposed
to be processes running on your machine with these names. Don't freak
out if you see a running program named init or winlogon! In all likelihood,
these are merely the legitimate programs that should be on your system. If these
are legitimate processes, you should not kill them, as your machine requires
them to function properly. We're discussing this issue because attackers
sometimes impersonate these vital programs using Trojan horses that have the
same name.

Of course, the list in Table 6.2 is not comprehensive, as tens of thousands
of possible programs and variations would fill this whole book. Still, I want to
give you a flavor for the types of Trojan horse naming attacks I'm seeing
in the wild in the incidents I handle. If you investigate computer attacks,
expect to see these exact names, subtle variations on these names, and a variety
of other similar tricks.

I remember a particularly compelling Trojan horse naming attack attempted
against me recently. I saw this technique at a SANS security conference, where I
run a hacker tools workshop about once per month. In these workshops, student
attendees get the opportunity to break into several experimental machines I
build and maintain for the class. Students learn the mindset and skills of an
attacker, and I get to have fun watching them repeatedly smash into my systems.
During one workshop, I received an urgent e-mail from one of my students. The
e-mail extolled the virtues of a very exciting new game, named

Table 6.2 Common Names Given to Trojan Horses to Blend in

Name Given to Trojan horse

Operating System

Legitimate Program That the Trojan Horse Is Trying to Look
Like

init

UNIX

During the UNIX system boot sequence, this process runs
first and initiates all other processes running on the box.

inetd

UNIX

This process listens on the network for connection
requests for various network services, such as Telnet and FTP
servers.

cron

UNIX

This process runs various programs at pre-scheduled
times.

httpd

UNIX

On a UNIX Web server, several copies of this process
typically run to respond to HTTP requests.

win

Windows

Typically there is no legitimate process by this name on
a Windows box. However, attackers take advantage of the fact that many
administrators might expect to see a process with this
name.

iexplore

Windows

This executable is Microsoft's Internet Explorer
browser. On most Windows systems, a spare browser running every once in a while
would go unnoticed.

notepad

Windows

This familiar editor frequently used on Windows systems
is an ideal program for an attacker to impersonate. Several backdoor tools
attempt to impersonate Notepad.exe.

SCSI

Any

Attackers sometimes name their Trojan horse processes
SCSI, attempting to dupe an administrator into thinking that the program
controls the SCSI chain. An administrator will hesitate to kill a process named
SCSI for fear that it might disable the hard drive.

UPS

Any

Sometimes, attackers name their processes UPS to fool
administrators into thinking the program controls the uninterruptible power
supply.

Vixens with No Clothes, or VNC for short. The sender detailed
all of the enticing blockbuster action in this exciting game, which I was
invited to install free of charge! How could any reasonable person pass up such
an incredible opportunity? In keeping with the fun atmosphere of the workshop, I
decided to take the bait knowingly and installed this supposedly nifty game.
However, as you might expect, not only were there no clothes ... there were no
vixens either! I watched as the keyboard and mouse on my screen began to move by
themselves, while squeals of joy erupted from my attacker on the other side of
the computer lab! Of course, this was all just a little game. Real-world
attackers might not be so blatant, but this example really helps illustrate the
concept of using deceptive naming to achieve installation of a Trojan horse
backdoor.

For another more real-world example, check out Figure
6.2. You can see the familiar Windows Task Manager on my Windows 2000 system.
By hitting Ctrl-Alt-Delete, selecting Task Manager, and then looking at the
Processes tab, I can see the various processes running on my box. The list of
Figure 6.2 look pretty reasonable. In particular, you can see that I'm
running one instance of the Internet Explorer browser (iexplore.exe).

Figure
6.2
Normal Windows Task Manager: Here is what I expect to be running on my Windows
2000 system.

Now, to illustrate a Trojan horse name-based attack, check out Figure
6.3. Here, we see an attacker copying the Netcat program, giving it the
rather curious name of iexplore.exe. That's pretty nasty, but rather common.
After creating the copy of Netcat, our intrepid attacker, evil dude that he
is, sets up a backdoor listener with the copy. The backdoor is waiting with
a command shell on TCP port 2222. However, if you look at the Task Manager now,
it appears that there is just another copy of iexplore.exe, the Internet Explorer
browser, running on my machine.

Users or administrators searching for a malicious process would likely
overlook this extra little goodie running on the box, as it looks completely
reasonable.

Giving a backdoor a name like iexplore.exe is pretty sneaky. However, an
attacker could do something even worse by taking advantage of an interesting
characteristic of Windows 2000, XP, and 2003. In these operating systems, the
Task Manager won't allow you to kill processes that have certain names.[1]
If a process is named winlogon.exe, lsass.exe, or any other name shown in Table
6.3, the system automatically assumes that it is a sensitive operating system
process based solely on its name. We'll discuss the interplay between many
of these processes in more detail in Chapter 8. These names are all used for
very important processes on a Windows machine [2], but attackers can use the
exact same name for a backdoor.

This process is the Windows Service Controller, which is
responsible for starting and stopping system services running in the
background.

smss.exe

The Session Manager SubSystem on Windows machines is
invoked during the boot process. Among numerous other tasks, it starts and
supports the programs needed to implement the user interface, including the
graphics subsystem and the login processes.

spoolsrv.exe

This process manages documents spooled to a printer or
fax machine.

svchost.exe

This process acts as a host for other processes that use
dynamic link libraries (DLLs).

System

This process includes most kernel-level threads, which
manage the underlying aspects of the operating system.

System Idle Process

On a Windows system, this process is just a placeholder
to indicate all of the CPU cycles consumed by idle tasks, when no specific other
processes have a pressing need.

winlogon.exe

This process authenticates users on a Windows system by
asking for user IDs and passwords, and interacting with other components to
verify their validity.

winmgmt.exe

This process is used for management of Windows clients.

If an attacker gives a backdoor a name from Table 6.3, Task Manager will refuse
to kill it. The system gets confused, believing the back-door process is really
the vital system process. The system is overprotective. To prevent a user from
accidentally killing a vital process and making the system unstable, Windows
goes overboard by preventing users from killing any process with such a name.
To illustrate this concern, in Figure
6.4, I created a copy of Netcat named winlogon.exe, executed it as a backdoor
listener, and tried to kill this imposter using Task Manager. The system instantly
popped up a dialog box saying, "This is a critical system process. Task
Manager cannot end this process." You might think that Windows would be
smart enough to differen tiate vital system processes from imposters by looking
at the file on the hard drive the process was started from, or even its process
ID number. However, Windows doesn't do this, and just assumes that any
process named winlogon.exe or lsass.exe must be okay. Therefore, unfortunately,
these names are just perfect for Trojan horse backdoors, because they are more
difficult for a system administrator to terminate, if they are ever discovered.

Figure
6.4 On Windows, backdoors that have the same names as vital system processes
cannot be killed by Task Manager.

As an additional concern, under certain circumstances, you might legitimately
have multiple copies of both csrss.exe and winlogon.exe running on a machine. If
you use Windows Terminal Services or Citrix to allow multiple users to
simultaneously log on to virtual desktops on a single Windows machine, each user
will have a Csrss.exe and Winl-ogon.exe. So, if there are two or more copies of
these two processes running, you might not have been attacked; you're just
looking at the processes created for different users. For the other processes
listed in Table 6.3, however, only a single instance of the process should show
up in Task Manager.

The Dangers of Dot "." in Your Path

Another issue associated with Trojan horse names involves the setting of the
path variable for users and administrators. On Windows and UNIX, most running
programs, including command shells and even GUIs, have the concept of a path.
This variable just contains a list of directories that are searched in order
from start to finish when a new program or command name is executed. For
example, on my UNIX machine, I can view my path by typing:

$ echo $PATH

The default path for users on my UNIX box includes a variety of directories,
such as /bin, /usr/bin, /usr/local/bin, and so on. These directories are the
locations of the commands commonly run by users on UNIX machines.

On Windows, you can view your path by using the set command and searching for
the word Path, as follows:

C:\> set | find "Path"

My default path on Windows includes folders such as C:\WinNT\System32,
C:\WinNT, and others. Whenever I type a program's name at a command prompt,
my system starts combing through the directories in my path, one by one, until
it finds the command and runs it. If it cannot find the command in my path, the
system responds with an error message, saying that the program or command could
not be found.

On UNIX systems, by default, your current working directory, referred to as
"." and usually pronounced dot, is not in your path. So, if you change
to a directory, and type the name of a program in that directory, you'll
get a "command not found" error, even though you are in the same
directory as the program you are looking for. This can be frustrating for new
UNIX users, but not having the current working directory in your path is a very
good thing from a security perspective!

Suppose someone misconfigured your account, and "." was in your
path. Also, suppose that an attacker gains low-privileged access to your
machine, but hasn't yet conquered superuser privileges on the box. This bad
guy could name an evil Trojan horse program Ls, and put it in some world
writable directory on the machine. The ls command is used to get a listing of
the contents of a directory. With "." in your path, if you ever
changed directories into the attacker's trap directory and ran the ls
command to get a directory listing, you'd run the evil Trojan horse! This
Trojan horse might instantly give the attacker all of your permissions on the
machine. If you have superuser privileges, the attacker now has such privileges
as well, having successfully launched a privilege escalation attack using a
Trojan horse version of ls.

Or, similarly, an attacker could create a backdoor with a name that matches a
commonly mistyped command, such as ipconfig. The normal UNIX command for viewing
network interface information is ifconfig, with an f instead of a p. However,
users sometimes type ipconfig instead, given that a similar command with that
name is available on Windows. If I create a Trojan horse named ipconfig on your
UNIX machine, I can sit back and wait for an administrator to accidentally type
ipconfig while in the wrong directory. For this reason, "." isn't
in the path on UNIX machines by default, and you shouldn't reconfigure your
shell to add it. In this case, the default path setting for UNIX is quite
reasonable. So, do yourself a favor, and leave it as is. Also, if you do have
"." in your path, consider removing it by editing the various start up
scripts associated with your login shell, which depend on the particular shell
you are using.

However, not having "." in your path also means that if you change
directories to a place where a program file is located, you cannot just type the
program's name to run it. Instead, to run the program, you have to type
./[program_name] to execute the program. So, if the system ever complains that
it cannot find a file, but you can see the file in the current working directory
using ls, use the "./" notation to start the program. It's not
too much of a burden.

This matter differs markedly on Windows systems. In the Windows command
shell, the current working directory is implicitly in your path, and you cannot
remove it. Even though the set command doesn't show a "." in your
path, it's still there, implicitly represented, just because you are using
Windows. Therefore, if you change to a directory with an executable inside and
then type the executable's name on Windows, the executable runs. The system
automatically finds it, because "." is implicitly at the very
beginning of your path. Yes, it's convenient, as you don't have to
ever mess with the "./" notation. However, having "." in
your path is also a security hole.

If an attacker gets low-privileged access to your machine, and then tricks an
administrator into running a command, the attacker can escalate privileges. One
of the most common tricks attackers utilize in Windows is to create a
privilege-escalating Trojan horse named cp. On Windows, the copy command is used
to copy a file, and there is no default command named cp. However, users
sometimes mistakenly type cp when they try to copy files. If they type cp in a
directory where the attacker placed a Trojan horse with that name, the attacker
could easily get that user's privileges on the machine.

Unfortunately, you cannot easily remove "." from your path on a
Windows machine. It's built into the operating system itself. Happily, the
"." comes at the end of your path, so any built-in commands located in
their normal directories will be executed instead of a Trojan horse with the
same name. Remember, the system searches for commands starting from the
beginning of your path, running the first matching program that it finds. Still,
mistyping a command name could lead to a privilege escalation attack on a
Windows system, so be careful when typing commands with an account with
administrator privileges.

Trojan Name Game Defenses

So, in light of these deviously named Trojan horses, what can we do to defend
ourselves? First, we must keep the malicious code off of our systems in the
first place by employing the antivirus tools described in Chapter 2 and the
backdoor defenses described in Chapter 5.

Also, you should be ready to kill suspicious processes that usurp the names
of legitimate processes. Even though Task Manager cannot kill processes with
certain names, you can deploy a free tool called PsKill from the PsTools
package, available for free at
http://www.sysinternals.com.
PsKill can shut down any running process, regardless of its name. However, be
careful with this tool! If you shut down a legitimate process, you could cause
your system to be unstable or even create an instant crash. Therefore, you need
to research each process of concern in more detail before shutting it down.

To conduct this research, you can use some tools we initially discussed in
Chapter 5. Remember our good friends, Lsof and Fport? As you might recall,
Fport, run on a regular basis by diligent system administrators, will help you
discover strange port usage associated with Trojan horses on your system. For
each running process that has an open TCP or UDP port on the network, Fport
shows the process ID, process name, port number, and the full pathname of the
file that the process ran from on the hard drive. Fport is very simple, yet
highly effective. On UNIX machines, you can use the Lsof command to achieve
similar functionality to Fport, as we discussed in Chapter 5.

Remember our example in which the attacker renamed Netcat so that it appeared
as iexplore.exe? In Figure
6.5, we can see how Fport displays this subterfuge.

Figure
6.5 Using Fport. Why is iexplore.exe listening on TCP port 2222 and why is
it running from C:\iexplore.exe? That looks like a problem!

Fport tells us that there are a variety of programs using ports on this
machine. All of these ports are pretty normal on a Windows machine, except for
the one with a Process ID (Pid) of 1084. It's called iexplore.exe, but is
listening on TCP port 2222 and running out of C:\iexplore.exe. That just
doesn't look right!

Using Fport, we can differentiate between the real browser, which should have
a path of C:\Program Files\Internet Explorer\iexplore.exe, and the
attacker's backdoor, which runs from C:\iexplore.exe. Unfortunately, this
kind of analysis requires an administrator to be intimately familiar with what
is supposed to be running on the system. That way, if a counterfeit pops up, an
administrator can quickly identify it and investigate. This can be very
difficult, but rock-solid system administrators should have a gut feel for what
is installed and running on critical systems. If an experienced sys admin
notifies you that "something just doesn't look right with this
program," you ignore their concerns at your own peril. Your best bet is to
analyze suspect programs in a laboratory environment to determine if they are
attempting to access files or the network unexpectedly. In Chapter 11,
we'll discuss a recommended laboratory environment and analysis process you
can use to pinpoint problematic software.

Another defense for these Trojan naming schemes is to block executable e-mail
attachments at your Internet gateway. You should filter out all programs that
are potentially executable. These include the familiar EXE programs, but go well
beyond that, too. In reality, you should filter out at least all of the program
types described in Table 6.1. For more information about these and other file
extension types, you should check out the extremely useful File Extension Source
Web site at http://filext.com.