What you really need to know about networ backdoor trojan programs

WHAT YOU REALLY NEED TO KNOW ABOUT NETWORK BACKDOOR "TROJAN" PROGRAMS

H. Carvey, CISSP
Note: This article was presented for publishing in the July '00 edition of the
Information Security Bulletin (edited by Gene Schultz)

Introduction

The release of several network backdoor, remote administration "trojan" programs targeting NT in the past year or two, particularly the release of BO2K by the Cult of the Dead Cow (cDc), presents a security dilemma whose true potential has only recently been glimpsed.

"Trojan" programs, named after the ancient Trojan Horse, come in a variety of flavors. For example, the ATAKA (IE0199) and WinTrinoo trojans are used to perform distributed denial of service attacks. The NTRootKit project provides a framework for trojaning the NT kernel and applications, in much the same manner as rootkits for Linux and the various flavors of Unix.

Finally, Back Orifice 2000 (BO2K), NetBus, and SubSeven are examples of remote administration programs that can potentially give a malicious intruder greater control of a computer system than the user sitting at the keyboard. This type of network backdoor, remote administration program is becoming more prevalent, and throughout this article, the term "trojan" will be used to refer collectively to network backdoor, remote administration programs targeted toward NT. See the "Trojan Data" sidebar for specific information regarding these trojan programs.

What’s the Issue

In today’s online world, several trends are becoming more prevalent:

The surge of e-commerce sites with a serious eye toward security.
The use of online purchasing and banking.
The proliferation of "always on" services such as cable modems and DSL, particularly in the home.
The generally lax security posture seen in home computer systems.

Combining these trends, it’s rather easy to see the devastating affect that network backdoor trojans can have. By loading a trojan on a home user’s system, either by sending a seemingly innocuous or enticing email attachment, or by exploiting a file share, the intruder can gain access to a full array of system resources. For example, the feature list for BO2K, with some plugins (additional functionality add-ons), includes:

File access (view or alter documents brought home from work, read emails, etc)
Share creation
Registry editing
Process control
Key logging (capturing key strokes, such as passwords typed into online banking or trading web pages)
Password listing (list the contents of the password cache on Win9x, or the SAM on NT)
Capture of the current display, in real-time (streaming video) with mouse and keyboard control

What kind of damage could a trojan do to a corporate network? Malicious activity could range from simple annoyance (sending annoying pop-up messages to the user) to the surreptitious collection (passwords, files, etc), modification (proposals, resumes, press releases, web pages, etc), or deletion of data. Consider the case of a manager who keeps copies of resumes on his hard drive, to be submitted with proposals to new clients. If a malicious individual were to be able to load a network backdoor trojan program on his system, that individual could do quite a bit of damage. Deleting the resumes and proposals, or even formatting the hard drive would be annoying, but the information will very likely be restored. But what if the malicious individual were to subtly alter the resumes? For example, modify all entries regarding years of work experience from "information security" or "system administration" to "adult film"? How likely would the company be to win that contract, or further information security work? The presence and malicious use of trojan programs may cause an organization to suffer a loss of customer confidence, and ultimately the loss of revenue.

During the first quarter of 1999, CERT received an increased number of incident reports regarding the use of trojan horse programs and issued an advisory, CA-99-02-Trojan-Horses.

The issue then becomes this…if a malicious attacker can somehow trick a user into installing a "trojan" program unknowingly, then how does the sysadmin go about detecting the presence of trojan programs? Perhaps more importantly, how does the sysadmin prevent the "trojan" program from being installed in the first place, without the user’s knowledge? The first step to take should be user awareness training, but often this is not enough. Technical controls should be put in place to assist sysadmins in preventing, and detecting, attempts to install trojan programs.

A "trojan" program is nothing more than just that…a program. It is not a virus, though every producer of anti-virus software has developed means of detecting trojans. Trojan programs, in and of themselves, are no more harmful to your computer than any other program. Certain types of programs, such as Microsoft’s SMS, Symantec’s pcAnywhere, and the freeware VNC from AT&T, allow for the remote control and administration of a computer system. This way, the system administrator (sysadmin) can manage and administer the system remotely. What makes the trojan programs a nuisance is the fact that they are generally installed on a computer system without the knowledge of the user or the sysadmin. Often they are touted as another type of program all together (i.e., a software update or patch, a game, a humorous animation, etc) so that the user will install the trojan unknowingly. Or the trojans may be attached to other programs, and installed when the host program is run. Hence the name "trojan horse". Examples of programs used to bind trojans to legitimate programs include:

Silk Rope and Saran Wrap (http://www.netninja.com/bo/index.html)
EliteWrap (http://packetstorm.securify.com/trojans/)

A wide range of trojan programs, under a variety of names, are freely available on the Internet. In fact, the source code for some trojan programs is also available, making it relatively simple for anyone with the necessary skill to modify the program to either alter it’s capabilities or attempt to avoid detection by anti-virus products. The source code for BO2K is available, and a malicious individual may decide to modify the code so that when the program is installed, it simply overwrites the file "findfast.exe." When Microsoft Office is installed on a system, a shortcut to this executable is invariably installed in the StartUp directory in the "All Users" profile.

Regardless of its capabilities, every trojan program has two characteristics in common. No matter how stealthy it tries to be, a trojan program will make its presence known in three ways. The first is that the trojan program has to be able to provide some means for the attacker to connect to it, and issue commands to the "victim" computer system via the trojan. To do this, the trojan needs to act as a server, that is, open a port to which the attacker can connect. Most trojan programs have a default port that they listen for connections on, though many trojans also have a facility for modifying this port. By using port scanning tools from another computer system on the network, or by using the "netstat" command on the "victim" computer system, the sysadmin can detect the presence of suspicious ports. A simple command, executed from the command prompt, will show you all of the ports that are listening, acting as servers:

C:\>netstat –a | find "LISTENING"

The second characteristic that trojan programs share is that they need to have a method for reactivating whenever the user logs in, or restarts the computer. When the trojan is first installed, it needs to leave a telltale sign of it’s presence somewhere on the computer system, preferably in a location that is accessed each time the computer is restarted, or a user logs in. After all, it needs to be restarted without any user intervention in order to remain hidden. For example, on Win9x systems, a logical location for such an entry is in the system files, such as autoexec.bat, config.sys, system.ini, or win.ini. The SubSeven trojan can use this method to "hide" itself. On NT, the situation is a little different, because NT does not access these files by default when the system is started. The logical place to hide the presence of a trojan on NT is within the technological minefield known as the Registry. After all, there isn’t a book or paper or KnowledgeBase article dealing with the Registry that isn’t preceded by stern warnings stating that a misstep in modifying the Registry can cause a complete breakdown of the entire system. This is enough to make the casual user wary, and not likely to go looking around in the Registry. Yet, for the trojan to be restarted each time the computer itself is restarted, or when a user logs in, there are only a few suitable Registry keys in which to "hide" the presence of the trojan program. Examining the contents of these Registry keys will aid you in your "trojan hunting."

Finally, when the installation routine for the trojan program is executed, files are invariably written to the hard drive of the "victim" system. By monitoring changes to specific directories, or performing routine, remote searches of those directories, sysadmins may be able to detect the presence of a trojan program. However, the configuration utilities for some trojans allow filenames to be modified. A preferable solution may be to use access control lists (ACLs) to prevent users from creating files within specific directories on the local hard drive.

Knowing what changes a trojan program makes to the computer system when it’s installed not only helps the sysadmin detect, but also prevent, the installation of such a program. Tools such as "RegMon" and "FileMon" from Mark Russinovich of Systems Internals (http://www.sysinternals.com) and InCtrl 3 by Neil J. Rubenking (InCtrl 3 can be found at http://packetstorm.securify.com/Win/) will allow a sysadmin to monitor changes made to files, directories and the Registry when a program is installed.

Solution

The key to detecting or preventing the installation of a trojan program is in understanding how the trojan is installed on the target system. First, a trojan makes it’s way onto the target system through a variety of means, such as an email attachment, via a floppy disk, or FTP download, for example. Many times, the malicious network backdoor program is attached or bound to some other innocuous program, such as a game, hence the name "trojan". When the host program is executed, the trojan installation takes place in the security context of the user, meaning that the program can only do those things that the user can do on the target computer system. During installation, the program attempts to write values to the Registry, and to copy a file or files to a directory. If the security context of the user does not give that user the ability to add values to the Registry, or save a file to the directory, the trojan will not be installed properly, and will not run.

The first step toward protecting your computer system is to ensure that the file system used is NTFS. The other file system available for NT 4.0, FAT, does not allow for security settings. Access control lists (ACLs) should then be set on particular directories, and Registry keys, restricting the type of access users have to those resources. Enabling auditing of failed write events (write on files and directories, set value and create subkey for Registry keys) to those resources will allow the system administrator to detect attempts to install a trojan program.

Specifically, set the ACLs on the C:\WINNT and C:\WINNT\SYSTEM32 directories to prevent users from creating files in these directories. Give users Read (RX) access to the directories, and files within the directories. Be sure to remove the Everyone group from access to these directories. Also be sure to remove the Everyone group and all user groups from the "Bypass Traverse Checking" privilege via the User Manager.

Also, set the ACLs on the following Registry keys to prevent users from adding values (i.e., Set Value or Create Subkey) to these keys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

Note: The above list of Registry keys modified by trojan programs is not a comprehensive list.

Finally, enable auditing on the above listed directories, and choose "Replace Auditing on Existing Files." At a minimum, audit failure events for users attempting to write to the directories. For the Registry keys, enable auditing and choose "Audit Permission on Existing Subkeys." At a minimum, audit failure events for Set Value and Create Subkey.

The key here is that if the user does not have ability to either add a value to a Registry key or add a file to a directory, the trojan will not be installed properly. Attempts to install software will show up in the Security EventLog with Event ID 560, as event type "Failure Audit." For example, an attempt to write to a protected Registry key in tests using the above instructions appears as follows:

Computer: MUSASHI
Category: 3 (Object Access)
Event ID: 560
EventType: 16 (Failure Audit)
Source: Security
SourceName: Security
Generated: Fri Apr 21 22:01:17 2000
Written: Fri Apr 21 22:01:18 2000
Flags: 0
User: MUSASHI\harlan
Description:
                +Security
                +Key
                +\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
                +-
                +0
                +112205
                +2210750976
                +harlan
                +MUSASHI
                +(0x0,0x1847C)
                +-
                +-
                +-
                +%%4434
                +-

Note: The above data was retrieved from the Security EventLog using a Perl script.

Attempts by a user to write to a protected directory appear in a similar format, and differ only in the information contained in the "Description" section. By using any one of a number of freeware, shareware, or commercial tools, a system administrator can collect EventLog entries from across the enterprise and filter on specific events.

Preventing users from writing to or creating files in the above listed directories may not be the right solution for every environment. Alternative approaches include:

Use a comprehensive anti-virus package, and keep it updated. Configure updates and scans to be performed automatically during off-hours.
Computing MD5 checksums of directories. These checksums are then used as a baseline that subsequent computations can be compared to. However, any modifications to the directories require that the baseline be recomputed.
Regularly perform remote scans of the directories, looking for specific filenames. The trojans generally do not overwrite or append to critical system files and DLLs, so computing MD5 checksums of critical system files may not be the best use of resources. Knowing the signature for various trojans and looking for those files does provide a means of tracking them down.
Regularly perform scans of the Registry keys, particularly the "Windows\CurrentVersion\Run" key listed above. Many trojans leave a footprint in this key. System administrators can use freeware or shareware tools to scan for known signatures, or perform a baseline scan, and compare all subsequent scans to the baseline. Only known, authorized software packages should be present in this key.

Should a trojan program be detected, removal of the program is generally performed by removing the entries from the Registry, rebooting the system, and removing the executable or DLL files.

Conclusion

Setting appropriate policies with regards to how your computer systems are configured will go a long way toward protecting those systems, and your entire network infrastructure, from current and future problems. The first step in any security plan should be to establish and implement an information security policy. Information security policies provide executive management’s overall guidance and vision for the corporate security program. Security standards defining which technical and non-technical controls to use in implementing the security plan are derived from and support the policies. Technical security controls inherent to the host operating system should be employed to enforce those policies. The standards should also include mechanisms for:

Ensuring the information security policies and standards establish a requirement for comprehensive backup and recovery procedures, as well as the use of anti-virus software.
Remaining alert and keeping up to date on relevant security issues.
Establish audit and logging procedures, as well as guidelines for collecting and analyzing audit data from across the organization.
A periodic assessment procedure that first baselines systems, then provides for verification of compliance with established policies and standards.
User awareness training to inform and remind users to not execute arbitrary executables, particularly those that arrive in email from unfamiliar sources.

These steps describe a dynamic process for establishing a "defense in depth" security posture that not only protects you from current threats, but allows you to detect and protect your infrastructure from future threats.

Additional Web Resources

CERT Advisory
"Windows Backdoor Update III"
"Wintrinoo", by Gary Flynn, James Madison Univ.

Trojan Data Sidebar

Information on network backdoor trojans can be obtained from anti-virus web sites:

F-Secure
Symantec AVRC
AntiViral Toolkit Pro
Computer Associates Virus Information Center

Back Orifice 2000
Description: BO2K is highly configurable, but the default installation writes the file "UMGR32.EXE" to the Winnt\system32 directory, and adds an entry to the "HKEY_LOCAL_MACHINE\...\Run" Registry key. Tests have also shown that the installation routine will try to create a service by modifying the Registry. The source code for BO2K is available.

Ports: configurable (original BO defaults to 31337 UDP)

Web Resources
http://www.bo2k.com
http://www.datafellows.com/v-descs/bo2k.htm
http://xforce.iss.net/alerts/advise31.php3
http://www.iss.net/prod/whitepapers/bo2k.pdf
Microsoft KB article Q237280, "How to Determine if Back Orifice 2000 Is Installed On Your System", http://support.microsoft.com/support/kb/articles/Q237/2/80.ASP

NetBus
Description: By default, v. 1.6 and 1.7 add the file "Patch.exe" to the Winnt\sytem32 directory and add an entry pointing to that file in the "HKEY_LOCAL_MACHINE\...\Run" Registry key.

Ports: 12345, 12346 (TCP) (v. 1.2 – 1.7); 20034 (TCP) (v 2.x)

Web Resources
http://www.netbus.nu/
http://www.datafellows.com/v-descs/netbus.htm

Note: NetBus is now a commercial product

SubSeven
Description: Adds the file "qsjtneaw.exe" to the C:\WINNT\system32 directory and modifies the NTUSER.dat and ntuser.dat.log files in the C:\WINNT\Profiles\Administrator directory. Creates the "HKLM\HARDWARE\Windows" Registry key, and adds eight entries (see "Tracking Trojan Installs" sidebar), most of which look like garbage.

Ports: 27374 (TCP)

Web Resources
http://subseven.slak.org/main.html
http://xploiter.com/security/sub7.html
http://www.datafellows.com/v-descs/subseven.htm

Version 2.2 for NT is available, at the time of this writing, from the SecurityFocus web site.

Tracking Trojan Installs Sidebar

Installing a trojan on purpose, just to watch what it does, is not for the faint of heart. It definitely requires a certain degree of confidence regarding your tools as well as your skills. For that reason, it’s a good idea to use multiple tools.

The two tools that were used when testing trojan installations for this article were RegMon, from Mark Russinovich of System Internals, and InCtrl3 by Neil Rubinking. RegMon will track all Registry accesses (queries, writes, etc) and is available as freeware from the System Internals web site. InCtrl3 monitors a software installation on Win9x and NT systems and displays a list of system changes (files, directories, Registry keys). InCtrl3 can be found in the PacketStorm archives.

Before installing a trojan…on purpose…just for fun…make sure that there is a fresh Emergency Repair Disk (ERD) and/or system backup on hand. Make sure to close all unnecessary windows and applications. Since one of the important pieces of information that will be collected is the default port that the trojan opens, run the command:

C:\>netstat –a > troj_tst.before

Then open InCtrl3 from the command line, and step through the configuration settings. The setup for InCtrl3 is pretty straightforward. On the second page of the configuration, leave the "Install Program" and "Command Line Parameters" text fields blank; this will allow InCtrl3 to run in "two-phase mode". In this mode, InCtrl3 will take a snapshot of your system before the installation, and will compare the post-installation state to that snapshot. Once all of the configuration settings for InCtrl3 have been entered, choose "Close" to close the application, and then open Regmon. Hit Control-E to stop capturing Registry accesses.

The next step is to execute the trojan installation application. In the case of SubSeven, the application is "server.exe". Execute the application by double-clicking on the icon in Explorer, or by typing "server" at the command line. Just prior to executing the application, return focus to Regmon and hit Control-E to resume capturing Registry accesses. Immediately after the installation is complete, return focus to Regmon once again and hit Control-E to stop capturing. Be sure to save the data collected by Regmon.

Execute InCtrl3 once again, and perform the post-installation comparison. The data collected by InCtrl3 will let you see what files were added or modified, and which Registry keys were added or modified. The following are the results of installing the SubSeven trojan for NT:

Installation report: SubSeven Test Install
(generated by INCTRL 3, version 3.01)
Thursday, May 4, 2000 06:02 PM

Windows NT, version 4.00
Notification by Disk contents comparison

Tracking:
c:\
d:\

FILES AND DIRECTORIES ADDED: (1)
c:\WINNT\system32\qsjtneaw.exe

FILES CHANGED: (4)
c:\Program Files\Netscape\Users\carvdawg\Cache
c:\WINNT\Profiles\Administrator\ntuser.dat.LOG
c:\WINNT\Profiles\Administrator\NTUSER.DAT
c:\WINNT\system32

NO CHANGES MADE TO C:\WINNT\SYSTEM.INI...
NO CHANGES MADE TO C:\WINNT\WIN.INI...

REGISTRY KEYS ADDED: (1)
HKEY_LOCAL_MACHINE\HARDWARE\Windows

REGISTRY KEY VALUES CHANGED: (2)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability
Value "LastAliveStamp": from "D0,07,05,00,04,00,04,00,15,00,39,00,33,00,02,02" to "D0,07,05,00,04,00,04,00,16,00,02,00,33,00,04,02"

REGISTRY KEY VALUES ADDED: (8)
HKEY_LOCAL_MACHINE\HARDWARE\Windows\‚¡š ="yl"}€NŠŽŠ²§¦e£ei•¥¥jª œš«`e®—"
HKEY_LOCAL_MACHINE\HARDWARE\Windows\†"ª¦–=""
HKEY_LOCAL_MACHINE\HARDWARE\Windows\†žž…§¦=""
HKEY_LOCAL_MACHINE\HARDWARE\Windows\… š|£ ="‰—«Yª›cª›¤˜¢"m›R¤²"¨i™¦ ¦A<S›¦WŒ¨"rª‡§Ydb1fbDC"
HKEY_LOCAL_MACHINE\HARDWARE\Windows\‰¦©†¨–="fbgid"
HKEY_LOCAL_MACHINE\HARDWARE\Windows\‰¤‡¡—="¬›šŸ_¤"¤ž"
HKEY_LOCAL_MACHINE\HARDWARE\Windows\‰¤‰¦¡=""
HKEY_LOCAL_MACHINE\HARDWARE\Windows\‰¤‰¦¦="hijph"

Once this data has been collected, run the command:

C:\>netstat –a > troj_tst.after

This will allow for a comparison of the before and after files to see which port(s) the trojan opened. After the SubSeven trojan was installed, the following evidence appeared:

TCP musashi:27374 0.0.0.0:0 LISTENING

Now that the pertinent data has been collected, it would be prudent to remove traces of the trojan from your test system. Consult the InCtrl3 and Regmon data, and remove any Registry keys that were created, and any Registry values that were added to keys. Reboot the system, and remove the files that were added, and any entries that were made to files.

In summary, the steps are:

Make ERD/backup.
Close all windows and applications.
Run initial netstat command.
Execute InCtrl3 in two-phase mode.
Open Regmon.
Execute trojan installation.
Halt Regmon.
Run InCtrl3.
Run netstat command.
Remove Registry entries for trojan.
Reboot.
Remove files/file entries put in place by trojan.

Interesting how that works out to twelve steps…