Chapter 18

Section: Part V:  Virtual Weapons of Mass Destruction

Chapter 18. Trojans

"For they still prefer sheep to thinking men Ah, but men who think like sheep are even better"

Brian McNeill, "No Gods and Precious Few Heroes"

"Beware of geeks bearing gifts"



        What Is a Trojan?

        Where Do Trojans Come From?

        How Often Are Trojans Really Discovered?

        What Level of Risk Do Trojans Represent?

        How Do I Detect a Trojan?

This chapter examines a type of threat to system and Internet security that has been with us almost as long as the computer: Trojan horses, often simply referred to as Trojans.



Section: Chapter 18.  Trojans

What Is a Trojan?

Trojan horses present more difficulties in definition than at first appears. Whereas viruses are defined primarily by their ability to replicate, Trojans are primarily defined by their payload, or, to use a less emotive term, their function. Replication is an absolute value. Either a program replicates, or it doesn't. Damage and intent, however, are not absolutes, at least in terms of program function. The first clue to their nature lies in ancient history and classical mythology.

Origin of the Species

Around the 12th century B.C., Greece declared war on the city of Troy. The dispute arose when Paris, variously described as a shepherd boy and as prince of Troy, abducted Helen, the wife of Menelaus, king of Sparta, and reputed to be the most beautiful woman in the world. The Greeks gave chase and engaged Troy in a 10-year war, but failed to take the city. This, of course, is the central plot of Homer's Iliad.

Finally, the Greek army withdrew, leaving behind a huge wooden horse. Greece's finest soldiers hid silently inside. The people of Troy saw the horse and, thinking with stunning naivete that it was a gift, brought it inside their city. That night, Greek soldiers under the leadership of Odysseus emerged from the horse, and opened the gates to the rest of the Greek army, who destroyed the city. It has been suggested that the Trojan horse story is the origin of the saying "Beware of Greeks bearing gifts."

In computing terms, the term Trojan horse is most often applied to an apparently attractive program concealing in some way an unpleasant surprise.


One well-known definition is included in the (now obsolete) RFC 1244, the first draft of the Site Security Handbook (the more recent draft doesn't include a definition):

A Trojan horse program can be a program that does something useful, or merely something interesting. It always does something unexpected, like steal passwords or copy files without your knowledge.

This definition contains three useful ideas not that they give us the best possible summary, but they serve as a good starting point for discussion of some implicit ambiguities. First, the definition doesn't say that the Trojan always does something useful or interesting, but that it might. This generality opens a wide range of possibilities, from programs whose only function is to do something malicious; through programs that do something desirable and something malicious but covert; to accidental Trojans, which are intended to do desirable things, but somehow do something undesirable as well (or instead).

Second, this definition includes the idea that a Trojan does something "unexpected" (unexpected to the recipient, or "victim", but not usually to the programmer). This assumption is common to nearly all definitions of Trojans.

Third, it contains the implication that the "payload" is something malicious. In fact, it's quite specific (intentionally or otherwise) about the fact that the cited example payloads (stealing passwords or copying files) involve unauthorized access rather than a breach of data integrity. For our purposes, this is less useful. It is overly specific about the type of security breach it appears to address (breach of privacy), and carries an assumption of malicious intent that is not universally accepted.

Most security professionals would accept a general definition along the lines of "A Trojan is a program that claims to perform some desirable or necessary function, and might even do so, but also performs some function or functions that the individual who runs the program would not expect and would not want."

I Didn't Mean It

Like many definitions, this one misses out on the idea of malicious intent. It therefore begs a number of questions about Easter Eggs (harmless code concealed more or less legitimately in production software by the original production team). Joke programs, installation routines that pass back information to the manufacturer and overwrite previous versions of system files, and accidental Trojans also present difficulties. However, as far as this chapter is concerned, these ambiguities are no bad thing. This chapter will refer (not necessarily in depth) to a whole range of relevant issues, rather than ignore everything that doesn't conform to a strict single definition.

A common modern usage distinguishes Trojans (and related malware, or MALicious softWARE) from viruses and worms, based on the Trojans'inability to self-replicate. In fact, Ian Whalley, in an article for Virus Bulletin (Talking Trojan. Virus Bulletin, July 1998) has suggested using the term non-replicative malware rather than Trojan horse, thus avoiding the popular confusion between replicating programs (viruses, worms) and static code (Trojans, for instance). This certainly has advantages, but reintroduces the assumption of malicious intent (by using the word malware). Clearly, while we may prefer not to admit to malicious intent as a defining characteristic, we can't avoid considering it as a possible or even likely characteristic.

Apart from the intent to deceive implicit in many Trojan definitions, malicious intent can cover a wide range of intentions and mechanisms.

Using the classic tripod model of data security, Trojans can be divided into three broad classes of intent:

        Intent to gain unauthorized access

        Intent to obstruct availability (deny service)

        Intent to modify or destroy data and systems without authorization

By extension of this idea, we can also postulate three further classes of accidental Trojan that allow unauthorized access, obstruct availability, or compromise integrity, but are not intended to do so.

A problem here is that, whereas automated examination and analysis of the binary content of a program can tell us a great deal about function, it can tell us little about the intent of the author.

Dr. Alan Solomon gave a definition in All About Viruses that neatly illustrates the problem from the other end:

Suppose I wrote a program that could infallibly detect whether another program formatted the hard disk. Then, can it say that this program is a trojan? Obviously not if the other program was supposed to format the hard disk (like Format does, for example), then it is not a trojan. But if the user was not expecting the format, then it is a trojan. The problem is to compare what the program does with the user's expectations. You cannot determine the user's expectations for a program.

Solomon's scenario is useful because it shifts the focus away from the programmer's or distributor's intent and onto the recipient/user's expectations. Implicitly, it also indicates that social engineering is a major component of a Trojan horse because it manipulates the victim's expectations. The passage also restates a problem that we will need to consider in more detail. It is (sometimes) possible to analyze a virus automatically because the defining characteristic of viral code is replication. It is at least theoretically possible to deduce the ability to replicate by automatic or semi-automatic code analysis. (This is one of the ways in which heuristic virus scanners are meant to operate.) It is much more difficult, however, to deduce either the intentions of the programmer or the expectations of the program user by tracing what the code does.

Viruses and worms are sometimes referred to as a special case of Trojan horse. The argument is that, because the legitimate program now contains embedded malicious code, it has been Trojanized (or, less commonly, Trojaned). This is a defensible position, although it doesn't distinguish between a program written to be malicious and an "innocent" program hijacked by a malicious code. However, the main reason for disregarding this argument is that it compounds the popular confusion between Trojans and viruses.

All malicious programs are popularly described as viruses, irrespective of their replicative properties or the lack thereof. In fact, some programs and coding problems that aren't even malicious are also described as viruses (the so-called Millennium virus, for instance). The situation isn't helped by the fact that hoaxes almost invariably describe mythical "viruses" that would be more properly described as Trojans, if they were capable of existing at all. Even worse, anti-virus vendors, although fully aware of the distinction between replicative and non-replicative malware, continue to display nonsensical alert messages such as "Virus Trojan/W32/xxx detected in file xyz.exe ". For a scanner to alert not only on Trojans but also on other non-viruses such as joke programs, garbage files, and intended viruses (attempted viruses that can't replicate), is misleading and might inspire panic quite inappropriately.

Trojan Classifications

Trojan horses are usually regarded as representing either an attack on privacy (password stealing, for instance, leading to unauthorized access and possibly modification), or on integrity (destructive Trojans). This is a little over-simplified. After all, unauthorized modification is an attack on integrity. A privacy-invasive program often destroys files so as to cover its tracks, and an attacker might want to gain access for specifically destructive purposes. Furthermore, this approach presupposes malicious intent, which, as we've seen, isn't universally accepted as a defining characteristic. Consequently, some types are included here that are often not considered in this context.

The sort of payload you expect a Trojan horse (technically, I suppose it was a Greek horse) to carry might reflect your computing orientation. For many years, mainframe and minicomputer users tended to think in terms of programs that stole passwords or otherwise breached privacy, whereas microcomputer users tended to think in terms of destructive Trojans which formatted disks or trashed file systems. In real life, both destructive and privacy-invasive Trojans have been known at both ends of the Big Iron/PC spectrum for many years. However, recent years have seen more cross-fertilization.

Destructive Trojans

Trojans whose main purpose is destructive have long plagued microcomputer owners. The Dirty Dozen list, first published via FidoNet in the mid-1980s, originally focused on such programs, and at one time the list defined a Trojan in terms of purposeful damage. Of course, the list quickly outgrew the original dozen Trojans and went through a number of changes through the 1980s and 1990s. It might still be possible to find it on some Simtel mirror servers in the DOS/virus directory hierarchy, but it is really only of historical interest. Old Trojans of the type generally listed in DIRTYD*.ZIP are almost invariably short-lived.

Malicious, non-replicating programs have also been widely reported on Macintosh comput ers, including destructive Trojans. Virus Info purported to contain virus information but actually trashed disks. (It should not be confused with the informational [but obsolescent] HyperCard stack Virus Reference.) A PostScript hack that could effectively render certain Apple printers unusable by attacking firmware also excited much interest at one time. NVP modified the Sys tem file so that no vowels could be typed, and was originally found masquerading as New Look, which redesigned the display. More recently, destructive and privacy-invasive, compiled AppleScript Trojans have been noted. For more information, see

However, the social impact of such Trojans is often disproportional to their impact in terms of actual incidents. Since they don't self-replicate, unlike viruses and worms, they are less likely to be spread by innocent third parties. They tend to be crudely programmed. Simple batch files using DEL, DELTREE, or FORMAT are still common, sometimes compiled into an .EXE or .COM file using a batch-file compiler such as BAT2COM. This makes them harder to identify. Trojans are usually direct action, that is, as soon as a Trojan is executed, it does all its damage at once This militates against their being spread by previous victims. There are, however, resident Trojans that install themselves so that they are run during every computing session. Often, these are associated with activities such as password stealing. However, any Trojan whose payload is not immediately and overtly malicious maximizes its own chances of being passed on.

The PKZip "Trojan virus" is described in the alt.comp.virus FAQ (which I have my own permission to quote and to correct slightly, since the FAQ is slightly out-of-date in the relevant section). I've included most of the section, since it makes an interesting case history.

The threat described in recent warnings is definitely not a virus, since it doesn't replicate by infection.

There have been at least two attempts to pass off Trojans as an upgrade to PKZip, the widely used file compression utility. A recent example was the files PKZ300.EXE and PKZ300B.ZIP made available for downloading on certain Internet sites.

An earlier Trojan passed itself off as version 2.0. For this reason, PKWare have never released a version 2.0 of PKZip: presumably, if they ever do release another DOS version (unlikely, at this date, in my opinion), it will not be numbered version 3.0(0). [In fact, the latest version is 2.50 at time of writing.]

In fact, there are hardly any known cases of someone downloading and being hit by this Trojan, which few people have seen (though most reputable virus scanners will detect it). As far as I know, this Trojan was only ever seen on warez servers (specializing in pirated software).

There are recorded instances of a fake PKZIP vs. 3 found infected with a real live in-the-wild file virus, but this too is very rare. To the best of my knowledge, the latest version of PKZip is 2.04g [now 2.50], or 2.50 for Windows [now 2.60/2.70].

There was a version 2.06 put together specifically for IBM internal use only (confirmed by PKWare). If you find it in circulation, avoid it. It's either illicit or a potentially damaging fake.

The recent rash of resuscitated warnings about this is at least in part a hoax. It's not a virus, it's a trojan. It doesn't (and couldn't) damage modems, V32 or otherwise, though I suppose a virus or trojan might alter the settings of a modem if it happened to be on and connected .

It appears to delete files, not destroy disks irrevocably.

It's certainly a good idea to avoid files claiming to be PKZip vs. 3, but the real risk hardly justifies the bandwidth this alert has occupied.

Why is it an interesting case history? For one thing, the subject of the attack is a typical target for a destructive Trojan that passes itself off as something it isn't. PKZip is a popular and very useful shareware utility. Recently, it has been rather overshadowed by other utilities using the same compression format, which might explain why PKZip is a less attractive target for Trojanization nowadays. In the following, we allude to a similar utility for the Mac whose identity was also purloined to lure incautious victims into running an imposter program.

Second, it was a counterfeit program that made no effort to assume the appearance or functionality of the program whose identity it claimed. This is characteristic of direct action, destructive Trojans, but not a defining characteristic.

Third and most interestingly, a program that very few people ever saw became a major nuisance because of the number of people who received and passed on a "semi-hoaxified" warning about the Trojan. In fact, the impact of the chain letter was more serious than the Trojan itself was ever likely to be. (This is a not uncommon side effect of direct action Trojans, but it rarely displays such spectacular impact.)

By semi-hoax, we refer to a misleading alert based on a real virus or Trojan, but into which enough misinformation has been introduced to render it too inaccurate to be useful. We should probably distinguish here between a number of possibilities:

        An alert based on real malicious software, but too imprecise to be useful. (Many virus alerts passed on by non-experts fall into this category.)

        An alert based on real malicious software, but rendered less useful by misinformation based on imperfect understanding of the relevant technology. Even knowledgeable individuals can inadvertently introduce such an inaccuracy into an alert.

        An alert based on real, malicious software, but invalidated by the introduction of deliberately misleading material, exaggeration, or complete fabrication of attributes and potential for damage.

Isn't a warning either a hoax or not a hoax? I think not. The intent to hoax (or the lack of it) might be absolute, but the mixture of fact and fiction is commonplace in hoaxes, where fact lends circumstantial support to an essentially fictional assertion.

In late 1997, a bogus version of StuffIt Deluxe was distributed. (StuffIt is a another popular archiving tool used primarily on Macs.) During installation, the program would delete key system files. Aladdin systems, makers of StuffIt, issued widespread advisories about the Trojan at the time.

Malicious Trojans have also been known to masquerade as anti-virus software.

A very well known Trojan that combined sabotage and extortion was the PC CYBORG Trojan horse, or AIDS Trojan. In 1989, some 10,000 copies of an AIDS information diskette were distributed in Europe, Africa, Scandinavia, and Australia, many to medical establishments. After the program was installed and run, a hidden program encrypted the hard disk after a set number of reboots. The idea was that the victim would have to send a "license fee" to PC Cyborg's Panamanian address to get the decryption key. Fortunately, a virus researcher in the UK cracked the encryption.

You can find the CIAC bulletin Information About the PC CYBORG (AIDS) Trojan Horse at

Privacy-Invasive Trojans

Privacy-invasive Trojans generally perform some function that reveals to the programmer vital and privileged information about a system or otherwise compromises that system. Passwords are, for obvious reasons, a very common target.

They can also (or instead) conceal some function that either reveals to the programmer vital and privileged information about a system or compromises that system.

Some anti-virus companies have differentiated between PC-specific privacy-invasive Trojans and destructive Trojans by restricting the use of the term Trojan to destructive programs. They use the term password stealers for the most common privacy-invasive programs. In the latter half of the 1990s, password-stealing programs aimed specifically at AOL users seemed to become very common (some estimates at the number of such programs rose to many hundreds). Some anti-virus software uses an APS identifier for such programs, probably standing for AOL Password Stealer. However, AOL is not and never was the only vulnerable service. In their paper Where There's Smoke, There's Mirrors, Sarah Gordon and David Chess describe running user simulations on AOL over a seven-month period. While attempts were made to gain their dummy users'screen passwords, these attempts generally used direct social engineering techniques by correspondents masquerading as AOL staff, rather than indirectly with password stealing programs.

Back Door Trojans

Trojans have, from time to time, been planted in legitimate applications. Ken Thompson describes in Reflections on Trusting Trust a number of interesting (not entirely hypothetical) scenarios, the most famous being the Trojanized compiler scenario. In this case, production software offers the means of privileged access to anyone knowing of the back door or trapdoor described.

Back doors and trapdoors offering unauthorized access (and maybe modification) are not the only instances of unauthorized code introduced into legitimate programs, however. Many Mac owners who bought a certain brand of third-party keyboard with a Trojan hardcoded into ROM chip found that the text "Welcome Datacomp" was inserted into their documents at apparently random intervals. PC motherboards with a Trojanized BIOS were characterized by "Happy Birthday" played through the system loudspeaker at boot-up, apparently on the programmer's birthday.

Remote Access Tools (RATs)

Though few anti-virus vendors would claim to detect all known Trojans, most do detect at least some on the platforms for which they have products, especially those Trojans that do direct damage. Remote Access Tools (RATs) such as Netbus and Back Orifice, however, straddle a line between legitimate systems administration (similar to that carried out by programs such as PC Anywhere) and covert unauthorized access. When the system owner is persuaded to run the installation program, a server program is installed that can be accessed from a client program on a remote machine without the knowledge of the user. The server is used to manipulate the victim machine.

Functionally, there might be no difference between a RAT and a "legitimate" tool. The difference lies not in the functionality, but in the facilitation of the covert availability of that functionality to unauthorized individuals. As with sniffers and network scanners, it's not what the program does so much as the reason it's being used. Yet if RAT software is willingly installed, opening the system to an attack the user does not expect, does that make it a Trojan? Using Microsoft Word also makes the user vulnerable to attacks he might not have anticipated. It was, for instance, literally years before some computer users realized that using versions of Word and other Microsoft Office applications supporting macro languages made them vulnerable to macro viruses and Trojans. Does that make Bill Gates a Trojan author? No, because the functionality in this case is too generalized to be described as a back door. However, a RAT broadcasting its presence to a hacker, who probes a characteristic range of port numbers, can certainly be described as a back door Trojan. It promotes the intentions of the author and subverts the expectations of the victim.

This is a serious issue not least in that the "Bad Guys" frequently allude to the shortcomings of legitimate software (especially Microsoft's) as if unforeseen bugs in Office justified their own premeditated activities.

Nonetheless, some RAT authors have exploited this ambivalence by producing "Professional" versions of such software and charging for them. This allows the authors to complain of the anti-capitalist, anti-competitive behavior of security vendors who detect their program as a Trojan (or, all too often and inaccurately, a virus). It works, too. Several anti-virus vendors have dropped detection of the Professional version of Netbus, despite the murkiness of its antecedents and its continuing potential for misuse. Others have gone out of their way to distinguish between standard Netbus Pro installations and Trojanized installations.


A dropper is a program that is not itself a virus, but is intended to install a virus. Curiously, given the popular association of Trojans and viruses, droppers are a comparatively rare entry point for viruses in the wild (see the preceding chapter on viruses). In the PC world, dropper programs are most commonly associated with transporting boot sector viruses across networks, and can be used for that purpose by both pro- and anti-virus researchers. They can be used as a covert means of introducing a virus onto a system, if the victim can be persuaded by social engineering techniques to run the dropper program.

Droppers have been used surprisingly frequently in the Mac world, though. The MacMag virus was introduced via a HyperCard stack called New Apple Products. The Tetracycle game was implicated in the original spread of MBDF. ExtensionConflict is supposed to identify conflicts between extensions (now there's a surprise), but installs the SevenDust virus. Both SevenDust and MBDF are still being reported in the field. Back in the PC world, the Red Team alert muddied the waters by attaching a virus dropper alleged to be a fix for a virus that didn't and couldn't possibly exist.


Joke programs are almost as old as computing. One venerable example is the PDP Cookie program, which popped up and asked the victim for a cookie. PC and Mac users have both long been delighted or irritated by such programs. Confusion has arisen due to the habit of anti-virus software of alerting (using the word virus) not only on viruses and Trojans, but on joke programs such as CokeGift. This widely distributed program offers the victim their CD tray as a holder for their fizzy drink (or possibly white powder for nasal ingestion or carboniferous fossil fuel). Cute for some, irritating for others, but not exactly life-threatening. However, the practice of alerting on joke programs might have arisen in response to supposed joke programs that threaten to format disks, or claim to have done so, but make no such actual attempt. Indeed, there have been instances when, what one vendor has reported as a Trojan, another vendor reported as a joke.


Logic bombs are malicious programs that execute their payload when a preprogrammed condition is met. When the trigger condition is a time or date, the term time bomb may be used. A time-out is a logic bomb sometimes used to enforce contract terms. Characteristically, the program stops running unless some action is taken to indicate (for instance) that the license fee has been paid, or the contractor who wrote the code has been paid. It's not unknown for a contractor to introduce some more drastic time bomb to be triggered if a dispute over payment arises.

The use of the word bomb does suggest a destructive payload, but this need not, in fact, be the case. Mail bombs and subscription bombs, which don't really belong in a chapter on Trojans, are DoS (Denial-of-Service) attacks intended to inconvenience the victim by battering his or her mailbox with a barrage of mail. Often this is done by subscribing the victim to large numbers of mailing lists. Email Trojans certainly exist, although email is more commonly an infection vector for viruses and worms.

The term ANSI bomb usually refers to a mail message or other text file that takes advantage of an enhancement to the MS-DOS ANSI.SYS driver. This allows keys to be redefined with an escape sequence, in this case, to echo some potentially destructive command to the console. Such programs were at one time quite frequently reported on Fidonet. However, nowadays few systems run programs that require ANSI terminal emulation, and ANSI.SYS is not normally installed in Windows 9x or later.

There are alternatives to ANSI.SYS that don't support keyboard redefinition, or allow it to be turned off.


A rootkit is an example of a set of trojanized system programs that an intruder who manages to root-compromise a system might be able to substitute for the commands'standard equivalents. Examples include modified versions of system utilities such as top and ps, allowing illegitimate processes to run unnoticed; daemons modified to compromise log entries or hide connections; utilities gimmicked to enable escalation to root privileges or to hide rootkit component files or other backdoor functionality (secret passwords to allow privileged access, for instance). Associated programs include packet sniffers and utmp/wtmp editors (used to doctor log files).

Rootkits exist for a number of flavors of UNIX, and are appearing in NT versions. However, one-off Trojanized versions of login (that is, versions not included in a suite of programs such as a rootkit) have been used, for instance, to harvest passwords since Pontius programmed in PILOT.

You can find information on rootkits in the FAQ at

Sarah Gordon's paper Publication of Vulnerabilities and Tool (Proceedings of the Twelfth World Conference on Computer Security, Audit and Control, 1995) includes a technical analysis of some rootkit components.

DDoS Agents

DDoS (Distributed Denial-of-Service) tools like Stacheldraht, TFN2K, and Trinoo are Trojans designed with a very specific purpose. They are intended to bring down Internet servers by remotely coordinating packet-flooding attacks from multiple machines. Typically, the intruder controls a number of master machines. These, in turn, control daemons on remote machines. Covertly installed, their presence is often concealed by the installation of rootkits. Daemons can be installed on many hundreds of remote machines, all directing flooding attacks at the victim system.

Detailed analysis of DDoS attacks and counter-attacks is beyond the scope of this chapter. However, the installation and presence of a DDoS attack tool can be detected by the same means as other malware. That is, recognition of a specific search string (Known Something Detection), heuristic scanning, and change detection. Virus scanners usually detect known DDoS tools. Network traffic can be monitored for characteristics such as IP packets with spoofed source addresses. Intrusion detection systems can be configured to scan for patterns characteristic of communications between master software and daemon software. A number of papers are available discussing these issues at greater length:


In principle, this should probably be the longest subsection in this chapter. Many system administrators now apply the term Trojan to what the author of Chapter 17, "Viruses and Worms," described as worms. While I regard this usage as misleading, it is defensible, common, and can't be ignored.

It's defensible because, as discussed in Chapter 17, most present-day worms are reliant on social engineering to persuade the recipient to execute the malicious code. In other words, they conform to one of the definitions we've previously examined suggesting that Trojans are programs that purport to do one (desirable) thing while actually doing some other (less desirable) thing.

The usage is misleading because it defies the definition of Trojans as non-replicative malware. In the virus business, most people hold the view that viruses and worms replicate. Some believe that the class worm is a subset of the class virus, and many regard Trojans as non-replicative. These distinctions are not just academic. To fight malicious code effectively, we need to understand how it works, and distinctions are particularly important when we come to examine a multipartite threats such as MTX or LoveLetter. Modern mail-borne malware might include components which can be described as parasitic (a file virus), a worm (a network virus that doesn't infect other files by direct attachment), and/or a classic Trojan.

The theoretical basis of computer virology might be a little shaky as we consider the impact of such recent developments. However, there is plenty of information on such programs on Web sites maintained by anti-virus companies, such as those listed in Chapter 17.



Section: Chapter 18.  Trojans

Where Do Trojans Come From?

Usenet is a common source of Trojans (and viruses), especially newsgroups that carry binaries of any sort, and more particularly, groups that traffic in warez (illicit software) or pornographic material.

The AOLGOLD Trojan horse was distributed via Usenet and through email. The program was claimed to be an enhancement package for accessing America Online (AOL). The distribution consisted of an archived file that, when unzipped, revealed two files, INSTALL.EXE and README.TXT. Executing INSTALL.EXE resulted in expanding 18 files to the hard disk. One of the new files, called INSTALL.BAT, attempted to delete several directories on drive C, as well as running a program called DOOMDAY.EXE (which failed to execute because of a bug in the batch file).

You can find the security advisory titled Information on the AOLGOLD Trojan Program at or

Trojans frequently masquerade as games, joke programs, screensavers, and other programs frequently exchanged by email, especially when strict system policies or security policies are not enforced. If software contains a privacy-invasive Trojan or a destructive Trojan with a delayed payload (a time bomb or other form of logic bomb, for example), the Trojan might be distributed by a victim who is not yet aware that the program is malicious.

AOL users are frequently targeted by privacy-invasive Trojans, as we've already seen, but also by destructive Trojans.

In April 1997, someone developed a trojan called AOL4FREE.COM (not be to be confused with the AOL4FREE virus hoax that surfaced that same year of course such confusion was part of the point of the hoax). The Trojan claimed to be a tool to gain unauthorized access to AOL destroyed hard disk drives on affected machines. To learn more about it, check out the CIAC advisory at

In fact, attacks on AOL users are symptomatic of a mindset regularly encountered among computer vandals of all types. Like Usenet newbies and unwary IRC users, they are seen as a group of "lamers" lacking low-level knowledge of the systems they use. This is seen in itself as some twisted justification, not only for jokes and hoaxes, but for intentionally destructive programs.

Direct intrusion allows installation of rootkit components and other trojanized files, especially if the intruder is able to gain root/administrator privileges.



Section: Chapter 18.  Trojans

How Often Are Trojans Really Discovered?

Trojans are frequently discovered in communities such as AOL. AOL presents an Internet service for computer users who don't want or need to be computer geeks. Many newcomers to the Internet have no interest in the finer points of networking protocols and the mysteries of Gopher, Telnet, and Archie, and AOL emphasizes user-friendliness rather than 1970s'geek cliques. Trojans in AOL usually target the least computer-literate members (new users, children) of those communities, already seen by technosnobs to be among the least computer-literate groups. This is significant because there are Black Hats (bad guys), who regard the technical ignorance of everyday users as justification of vandalism. They reason, "If lame AOLers can't learn to protect their systems, they deserve everything they get."

In the corporate arena, Trojans are a major security concern on multiuser systems. They can be insidious, too, because even after they're discovered, their footprints may remain in dark corners of the directory system or Windows Registry. Trojans are often hidden within compiled binaries. The Trojan code is therefore not in human-readable form or machine language. Without using a debugging utility, you can learn little about binary files. Using a text editor to view a binary file, for example, is futile. The only recognizable text strings will be copyright messages, error messages, or other data that prints to STDOUT at various points in the program's execution stub loader messages, for example. In a graphical environment, recognizable strings will be even less frequent or useful. However, reverse-assembling serious quantities of potentially damaging code is not a task for the fainthearted or under-resourced. As we've already noted, such code is not always susceptible to automated analysis.


Compiled binaries are not the only places you'll find Trojans. Batch files and other shell scripts, Perl programs, and perhaps even code written in JavaScript, VBScript, or Tcl can carry a Trojan. Scripting languages have been described as unsuitable for the creation of Trojans if the code remains humanly readable. This increases the victim's chances of discovering the offending code. In real life, though, victims often seem quite happy to run unchecked code, even when it's humanly readable. The LoveLetter virus was executed by countless recipients, even though the cleartext code clearly included a subroutine whose very name indicated that it was intended to infect files.

Nesting a Trojan within such code is, however, more feasible if the file is part of a much larger package for example, if the entire package extracts to many subdirectories. In such cases, the complexity of the package can reduce the likelihood that a human being, using normal methods of investigation, would uncover the Trojan, especially if it's an easily overlooked short sequence like DELTREE C:\ or rm -rf.


Trojans don't usually announce their intent. Worse still, many Trojans masquerade as legitimate, known utilities that you'd expect to find running on the system. Thus, you cannot rely on detecting a Trojan by listing current processes.

In detecting a Trojan by eye, much depends on the user's experience. Users who know little about their operating systems are less likely to venture deep into directory structures, looking for suspicious files. More proficient users are unlikely to have time to examine the complex system structures of modern operating systems, especially on server-class machines. Even experienced programmers can have difficulty identifying a Trojan, even when the code is available for their examination. Identification of malicious code by reverse-engineering can be more difficult and time-consuming by orders of magnitude.



Section: Chapter 18.  Trojans

What Level of Risk Do Trojans Represent?

Trojans can represent a moderate-to-serious level of risk, mainly for reasons already discussed:

        New Trojans are difficult to detect using heuristic detection. (Unless you use the somewhat sweeping heuristic that a change in a file detected automatically is likely to indicate a Trojan substituted for a legitimate file.) There is no absolute test for code to determine whether it is (or is not) a Trojan because author intent and user expectations are not generally susceptible to automated analysis.

        In most cases, Trojans are found in binaries, which remain largely in non-human-readable form. However, the fact that the code is largely static does make Trojans at least as susceptible to "known-something" detection as viruses. In other words, when a known malicious program is identified, it can be detected by software updated with an appropriate search string. Remember that, by most definitions, replication is not a characteristic of the Trojan breed. Trojans spread through the action of being copied by an attacker or a victim socially engineered into carrying out the attacker's wishes, not by self-copying. Thus it is not usually feasible for an attacker to utilize techniques such as polymorphism to reduce the chance of detection. Since the copying of the program is not a function of the program itself, the program has no means of evolving into a nonidentical copy (a morph) of itself.

Nevertheless, undetected Trojans can lead to total system compromise. A Trojan can be in place for weeks or even months before it's discovered. In that time, a cracker with root privileges could alter the entire system to suit his or her needs. Even when the Trojan is discovered, many hidden loopholes might be left behind when it is removed.



Section: Chapter 18.  Trojans

How Do I Detect a Trojan?

Detecting Trojans is easy, if you have a static search pattern to scan for. Anti-virus software routinely detects (some) Trojans using much the same pattern-searching techniques used for detecting viruses. However, identification of a known Trojan isn't always the best defense. Detection of previously unknown Trojans is also (conceptually) simple, provided you have always maintained the best security practices (literally always, at least as far as the protected system is concerned).

Most detection methods on traditional multiuser systems derive from a principle sometimes called object reconciliation. Object reconciliation is a fancy way of asking, "Are things still just the way I left them?" Here's how it works: Objects are system areas, such as files or directories. Reconciliation is the process of comparing those objects against a snapshot record of the same objects taken at some previous date when the protected object was known to be in a trustworthy, "clean" state.


Strictly speaking, there is no such "clean state" time. Even a "day zero" installation of system software onto a virgin system assumes a program suite with no substitutions and back doors. Can you place unlimited trust in a system you didn't build totally from scratch yourself? "No amount of source-level verification or scrutiny will protect you from using untrusted code," says Ken Thompson in his Reflections on Trusting Trust. Does this mean we should give up on this approach? Of course not, but we should bear in mind that, even if we build an applica tion from scrutinized source code, we might not be able to trust the compiler or every snippet of hardware microcode on the system motherboard.


More commonly, the process described as object reconciliation is known as change detection, integrity checking, or integrity management. However, these terms are not strictly synonymous.

Change detection simply describes any technique that alerts the user to the fact that an object has been changed in some respect.

Integrity checking has the same core meaning, but is often taken to imply a more sophisticated approach, not only to detecting change in spite of attempts to conceal it, but to ensuring that the reporting software itself is not subverted.

Integrity management is a more general term. It can include not only the detection of unauthorized changes, but other methods of maintaining system integrity. Such methods can include some or all of the following, in no particular order:

        Maintaining trusted backups

        Blocking unknown intrusions at entry (for instance, by running system files from read-only media or refreshing system files from trusted read-only media)

        Maintenance of strict access control

        Careful application of manufacturer patches to block newly discovered loopholes

        A finely engineered change-management system, using only signed (trusted) code.

A simple method of testing file integrity, is based on reports of changes in file state information. Different file integrity tests vary in sophistication. For example, you can crudely test a file's integrity using any of the following indexes:

        Date last modified

        File creation date

        File size

Unfortunately, none of these three methods constitute a really adequate defense against more than the crudest attack. Each time a file is altered, its values change. For example, each time the file is opened, altered, and saved, a new last-modified date emerges. However, this date can be easily manipulated. Consider manipulating this file timestamp. How difficult is it? Change the system time, apply the desired edits, archive the file, and re-set the system time. Better still, get and save the date/time information using standard C library functions (for instance), modify or replace the object, and restore the file modification date. On a single-user system (like MS-DOS) with minimal or no access controls, the coding involved is trivial. For this rea son, checking time of modification is an unreliable way to detect change. Also, the last date of modification reveals nothing if the file was unaltered (for example, if it was only copied, viewed, or mailed). On the other hand, if there is a disparity between the modification date returned by the system and the date of modification recorded by a system monitoring utility, there is a distinct possibility of malicious action.

Another way to check the integrity of a file is by examining its size. However, this value can be very easily manipulated, either by trimming or padding the file itself, or by altering the value reported by the operating system.

There are other indexes. For example, basic checksums could be used. However, although checksums are more reliable than time and date stamping, they can be altered, too. If you rely on a basic checksum system (or use change detection software, which relies on simple checksumming), it is particularly important that you keep your checksum list in a trusted environment. This might mean on a separate server or even a separate medium, accessible only by root or other trusted users. Checksums work efficiently and appropriately for checking the integrity of a file transferred, for example, from point A to point B, but are not suitable for high security applications. They simply aren't designed to guard against a malicious attempt to subvert them to return false information.


If you've ever performed file transfers using communication packages such as Qmodem, you might remember that these programs perform cyclical redundancy checksum (CRC) verification as the transfers occur. This reduces the likelihood that the file will be damaged in transit. When dealing with sophisticated attacks against file integrity, however, this technique is insufficient. Tutorials about defeating checksum systems are scattered across the Internet. Most are related to the development of viruses. (Some older virus-checking utilities used checksum analysis to detect possible infection by new viruses: that is, viruses not yet known to the compilers of virus-specific scanner databases.) You can learn more about CRC32 (and other algorithms) at


A less easily subverted technique involves calculating a more sophisticated digital fingerprint for each file using various algorithms. A family of algorithms called the MD series can be used for this purpose. One of the most popular implementations is a system called MD5.


MD5 belongs to a family of one-way hash functions called message digest algorithms. The MD5 system is defined in RFC 1321 as follows:

The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA.

RFC 1321 is located at

When you run a file through MD5, the fingerprint emerges as a 32-character value. It looks like this:


Many sites that distribute UNIX software use MD5 to generate digital fingerprints for their distributions. As you browse their directories, you can examine the original digital fingerprint of each file. A typical directory listing might look like this:

MD5 (wn-1.17.8.tar.gz) = 2f52aadd1defeda5bad91da8efc0f980
MD5 (wn-1.17.7.tar.gz) = b92916d83f377b143360f068df6d8116
MD5 (wn-1.17.6.tar.gz) = 18d02b9f24a49dee239a78ecfaf9c6fa
MD5 (wn-1.17.5.tar.gz) = 0cf8f8d0145bb7678abcc518f0cb39e9
MD5 (wn-1.17.4.tar.gz) = 4afe7c522ebe0377269da0c7f26ef6b8
MD5 (wn-1.17.3.tar.gz) = aaf3c2b1c4eaa3ebb37e8227e3327856
MD5 (wn-1.17.2.tar.gz) = 9b29eaa366d4f4dc6de6489e1e844fb9
MD5 (wn-1.17.1.tar.gz) = 91759da54792f1cab743a034542107d0
MD5 (wn-1.17.0.tar.gz) = 32f6eb7f69b4bdc64a163bf744923b41

If you download a file from such a server and find that the digital fingerprint of the downloaded file is different, there is a good chance that something is amiss.

With or without MD5, integrity management is a complex process. Various utilities have been designed to assist with integrity management on complex and distributed systems. The following utilities were originally UNIX-based, but similar programs are available for Microsoft operating systems.


Tripwire (written in 1992) is a comprehensive file integrity tool. Tripwire is well designed, easily understood, and easily implemented.

The original values (digital fingerprints) for files to be monitored are kept within a database file. That database file in simple ASCII format is accessed whenever a signature needs to be calculated or verified.

Ideally, a tool such as Tripwire would be used immediately after a fresh (day zero) installation. This gives you 100% assurance of file system integrity as a starting point (or nearly 100% remember the Ken Thompson article). Once you generate the complete database for your file system, you can introduce other users (who will immediately fill your system with junk that, optionally, may also be fingerprinted and verified on subsequent checks). Here are some of its more useful features:

        Tripwire can perform its task over network connections. Therefore, it's possible to generate a database of digital fingerprints for some entire networks at installation time.

        Tripwire was written in C with a mind toward portability. It will compile for many platforms without alteration.

        Tripwire comes with a macro-processing language, so that your tasks can be automated.

Tripwire is a popular and effective tool, but there are some security issues common to most or all integrity management tools. One such issue relates to the database of values that is generated and maintained. From the beginning, Tripwire's authors were well aware of this:

The database used by the integrity checker should be protected from unauthorized modifications; an intruder who can change the database can subvert the entire integrity checking scheme.

Tripwire is discussed at length by its original authors in The Design and Implementation of Tripwire: A File System Integrity Checker by Gene H. Kim and Eugene H. Spafford. It is located at

One method of protecting the database is to store it on read-only media. This eliminates any likelihood of tampering. Kim and Spafford suggest that the database be protected in this manner, although they point out that this could present some practical, procedural problems. Much depends upon how often the database will be updated, and its size. Certainly, if you are implementing Tripwire or a similar utility on a wide scale (and using its most stringent settings), the maintenance of a read-only database could be formidable. As usual, this breaks down to a trade-off between the level of risk and the inconvenience of setting and maintaining paranoid defaults.

You can find Tripwire (and papers on usage and design) at In its commercial incarnation, more information (and an unsupported but downloadable version of the original software) is available from


The TAMU Tiger suite (from Texas A&M University) is a collection of tools that greatly en hance the security of a UNIX box. These tools were created in-house, in response to an extensive attack from a coordinated group of Internet crackers. The package has been upgraded and renamed TARA (Tiger Analytical Research Assistant). It incorporates a number of scripts used to scan UNIX systems for problems. More information from TARA-PRO is available from


Hobgoblin is an interesting implementation of file- and system-integrity checking. It is both a language and an interpreter. The language, according to the authors, describes the properties of a set of files, and the interpreter checks whether the description matches the actual files, and flags any exceptions.

Hobgoblin and its source are located at You might want to check the link at for more information.

On Other Platforms

File integrity checkers exist for Windows, (in fact there is an implementation of Tripwire for Windows NT). Integrity checkers are not necessarily expressly designed to check multiple machines and file systems over networks. Some older DOS and Windows tools use simple CRC checksumming as an index and therefore might be easier to subvert than tools that employ MD5 and related algorithms. The majority are intended for use as a supplement to virus scanners (since detectable changes to an infectable object might indicate virus infection). This doesn't invalidate the potential usefulness of integrity checkers as a means of detecting possible substitutions of compromised code for system files.

However, change detection is less convenient on Windows platforms in that system files accessed by multiple applications can be replaced by legitimate installations and upgrades. There is often a sharper delineation on other platforms between files belonging to the system and files that belong to an application.

Furthermore, change detection only works well with certain types of binary executables, even in the context of virus detection. Many viruses and Trojans infect files whose main purpose is to contain data (spreadsheets, word-processing files, and so on). However, such files are usually intended to be modified, as are the log files used on many multiuser systems to track possible malicious action. Clearly, change detection based on the presumption that files remain static isn't going to work in these instances. In some instances, it's possible to specify changes that might signify a breach (the addition of macro code to a Word file, for instance). This approach requires that the inspecting software "know" more about the internals of the file, rather than just its digital fingerprint. That would entail serious administrative difficulties, so the approach is not well favored at present.

The safest defense, though, is to block unauthorized modification of system files proactively by code signing, read-only media, and other pre-emptive measures.



Section: Chapter 18.  Trojans


Reflections on Trusting Trust. Ken Thompson. Reprinted in Computers Under Attack: Intruders, Worms and Viruses. Ed. Peter J. Denning. ACM Press, 1990. 0-13-185794-0.

Where There's Smoke, There's Mirrors: The Truth About Trojan Horses on the Internet. Sarah Gordon and David M. Chess. Virus Bulletin Conference Proceedings, 1998.

Testing Times for Trojans. Ian Whalley. Virus Bulletin Conference Proceedings, 1999.

Practical Unix and Internet Security. Simson Garfinkel and Gene Spafford. O'Reilly & Associates 1996. 1-56592-148-8.

Security in Computing. Charles P. Pfleeger. Prentice-Hall International, Inc. 1997. 0-13-185794-0.

MDx-MAC and Building Fast MACs from Hash Functions. Bart Preneel and Paul C. van Oorschot. Crypto 95.

Message Authentication with One-Way Hash Functions. Gene Tsudik. 1992. IEEE Infocom 1992.

RFC 1446 1.5.1. Message Digest Algorithm.

RFC 1510 6. Encryption and Checksum Specifications. Connected: An Internet Encyclopedia.

RFC 1510 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des.

A Digital Signature Based on a Conventional Encryption Function. Ralph C. Merkle. Crypto 87, LNCS, pp. 369 378, SV, August 1987.

An Efficient Identification Scheme Based on Permuted Kernels. Adi Shamir. Crypto 89, LNCS, pp. 606 609, SV, August 1989.

Trusted Distribution of Software over the Internet. Aviel D. Rubin. (Bellcore's Trusted Software Integrity (Betsi) System). 1994.

International Conference on the Theory and Applications of Cryptology. 1994 Wollongong, N.S.W. Advances in Cryptology, ASIACRYPT November 28 December 1, 1994. (Proceedings) Berlin & New York. Springer, 1995.

Managing Data Protection, Second Edition. Dr. Chris Pounder and Freddy Kosten. Butterworth-Heineman Limited, 1992.



Section: Chapter 18.  Trojans


Trojans are a significant security risk to any network, server, or workstation. While Windows and UNIX-hosted anti-virus software usually detects known Trojans, there are strong arguments for using integrity management tools, especially on server-class machines, to reduce the possibility of system compromise from Trojans masquerading as system utilities. This approach is viable on workstations, too, although it may be harder to implement effectively. A combination of targeted integrity management, efficiently backing up data but restoring systems from a standard day zero image rather than from backup tapes, and sound user management controlling the installation and execution of unauthorized software, is more effective than any single strategy in any server or workstation environment.



Enterprises - Maximum Security
We Only Played Home Games: Wacky, Raunchy, Humorous Stories of Sports and Other Events in Michigans
ISBN: 0000053155
EAN: 2147483647
Year: 2001
Pages: 38 © 2008-2017.
If you may any questions please contact us: