Almost All The Ways to Find Your Back Orifice

Almost All The Ways
to Find Your Back Orifice
Last updated Sunday, 27 December 1998

What are the all the methods of detecting the presence of and pinpointing Back Orifice? I have no idea. But here is a series of powerful methods. Together, I'd venture to say they amount to a 100% solution.

Most of these tools are already on your Windows machine or readily available. Each has its strengths and failings. Netstat can often tell you BO is there. It can't tell you where it is. Inspecting the Registry can lead directly to BO sometimes. Sometimes it can't. Read on and I'll outline how each of these tools can help save your Orificed butt from unwanted rear entry.

There's something that must be borne in mind in any serious attempt to foil BO. Certain configurations can cause BO v1.2 to fail to erase itself and/or copy itself to the System folder. This fact is easily demonstrated, and is surely known to some of its "distributors."

This behavior is accomplished by the simple expedient of including at least one "illegal character" in the filename BO is configured to assume.

BO fails to make the usual copy of itself in the System folder because Windows won't allow the illegal filename. In such a case, whereas it is supposed to erase its original and run under the new name, it simply remains where it is and runs. This means the BO server can reside anywhere at all on the system. The RunServices Registry entry can be practically anything, and becomes completely irrelevant. Obviously, this complicates the task of locating and removing the server.

Although undoubtedly most BOs don't take advantage of this fact, any serious effort to work out a means of eradicating BO with complete reliability must take it into account, and must not rely entirely on the Registry entry it creates. BOSniffer is one perfect example of this; and surely many other implementations of BO v1.2 will be similarly stealthy despite its obligatory change to the Registry.

If BO v1.2 (unmodified) is to be run in the absence of its usual Registry key (or regardless of the content of that key) as far as I know it must happen one of four ways:

As an example of how easily BO can be set up to run by other means than its usual Registry key, I have composed this DOS batchfile. It can easily accomplish the placement of entries in WIN.INI and the Registry which will execute any chosen program at startup. This approach or something similar can easily be incorporated into an existing install routine for many legitimate programs. It's equally simple to place the necessary command in autoexec.bat and/or to place an innocent-looking shortcut in the Startup Group. Any of these will invoke BO quite effectively at every startup.

BO v1.2 always creates windll.dll in the System folder. This file is used by many of the BO detectors to spot BO's presence. However, it cannot be relied upon to find all Back Orifices.

The function of this DLL is to implement keyboard logging, and apparently nothing more. BO works just fine without it. Thus, in a "customized" BO installation it may quite possibly be intentionally deleted as part of the startup process, as a means to further obscure BO's presence.

Moreover, windll.dll can be easily renamed by direct editing of the BO server executable and will function perfectly. On 22 Oct, I received this email:

My testing demonstrates this is quite true. Any ordinary hex editor used on the BO server makes this a trivial task. The BO server will create the DLL using whatever name it finds there, and will then use the file by that name if it's in the expected (System) folder.

By editing this file's name, it's even possible to place the DLL in another directory (though it will not function), or cause it to be nonexistent by use of the "nul" filename. The filename needs only occupy the same number of characters as before. For examples:

Yes, that's right. It needs not be named with the .dll extension to function. But it must be in the System folder if keyboard logging is to work.

Also, if the filename contains an illegal character or nonexistent path, the file will not be created; but again, the server will run anyway.

BO v1.2 always makes an entry in the Windows Registry, always in the same place. This entry can usually be quickly identified. It is in:

Multiple copies of BO with varying filenames/configs can run simultaneously on the same machine and each will write its own entry to this key. In the majority of cases, this key points directly to the BO server program.

REGEDIT provides the means to read and/or delete BO's Registry entry. If that entry is the means by which BO is invoked at startup — it normally will be — its removal, followed by a reboot, will disable BO.

This approach easily locates BO in its default configuration and also works to detect, and to pinpoint, a large proportion of custom-configured Orifices. Because it is so easy, it is the first approach I recommend, especially to inexperienced users. I've written a page that lays out simple step-by-step instructions for finding most BOs by way of the Registry.

REGEDIT isn't rendered useless by trickier BOs. Normally, the BO server deletes itself when initially run and places itself in the Windows\System folder. However, as I pointed out above, if it's cleverly configured, BO can be made to remain where it is. Its Registry entry can be a direct clue to this trickery because it's the filename config that determines this behavior — and the filename config is the Registry value.

A key fact about BO (v1.2) is that it must write something to this Registry key; which is the means by which it is re-run at each startup. If you suspect a cleverly-hidden BO but the contents of the RunServices key don't lead you to it, removing all entries from this key (you should always save the data for later re-entry in case it proves valid), restarting Windows and inspecting again using REGEDIT will reveal its activity. If any entry has reappeared, it's BO at work; you know which entry it's making; and this tells you BO is being executed by some other means. (See above for what these might be.)

On the other hand, if this experiment produces NO entry, then BO v1.2 is almost certainly not being run in your machine unless it's using one of the entries you just removed.

These standard Win95 desktop tools can, used well, hunt down BO on your system very effectively.

As a first step and a very telling one, look for a file named windll.dll in the Windows\System directory. Unmodified, BO v1.2 places that file there invariably every time it runs. Delete it, shut down, and restart. If another copy of windll.dll appears on restart, you've got BO. (As above, because windll.dll can be renamed, this alone is not a 100% reliable method of detection but it's pretty close.)

If using REGEDIT hasn't led you straight to your Orifice, but shows BO is around someplace, Explorer/File Find provides some strategies to locate it.

Use Windows' File Find function (it's on the Advanced tab) to look for this exact text and you should locate any and all instances of these files. This search can take a very long time, depending upon the size and number of files on your system. It will be faster, but less thorough, if you confine the search to the Windows folder and its subdirectories.

Bear in mind that the BO server can lurk in a compressed file (.ZIP, etc.) where this approach will not find it, and where it may also be overlooked by a virus scanner. A clever intruder without programming skills can easily set up the BO server to be regenerated from a compressed file at each reboot.

File size is another clue. BO v1.2 will always be a minimum of 124,928 bytes in length (122K in the Explorer window). Maximum can however be much longer. Because BO can be attached to any file, the 6 August ISS Security Alert Advisory is simply wrong about the limits it places on BO's size (within 30 bytes of 124,928). One person sent me a BO server that was 193,143 bytes in length. The file's size in that case was due to the attached plugin; that particular BO was configured to run with the Butt Trumpet plugin. BO isn't at all likely to be a 1-meg monster; that works against its strong advantage of small size. Exactly how big it can get is nonetheless unlimited.

Using File Find to locate all files on all drives at least 122K in size, then sorting them by date to find the more recent, should yield a relatively short list of likely suspects. This works especially well if you have MSInfo or Wintop and compare the list to running applications. Note: The date of the BO server file will most often be 7/11/95, the same as many standard Win95 files.

Netstat

This DOS utility shows the status of your TCP connections. It's a bit cryptic and technical but it sees all.

Netstat can provide key evidence of BO's presence. Those already familiar with it would do well to use it regularly as a means of checking up on the dial-up connection.

Netstat can also serve as a very quick test for suspicious activity. With the dial-up connection established, open a DOS window and type:

netstat -a

at the prompt. Press Enter. Netstat's display will appear.

netstat -an

displays the same data somewhat differently, substituting IP addresses for connection names.

netstat -an 1

does the same thing, but repeats its scan once every second.

netstat -an 1>netstat.txt

will feed its output to the textfile netstat.txt indefinitely until it is stopped using Ctrl-C or Ctrl-Break. This works well to monitor activity on the dial-up connection but it accumulates a huge file over time which is so gigantic it may prove impractical to inspect.

If Netstat shows activity on port 31337, you almost certainly have an Orifice. But its port can be configured to any valid number from 0 to 65535. In fact, contrary to my expectations, Back Orifice can even utilize ports normally reserved for NetBIOS networking functions, such as 137 (nbname), 138 (nbdatagram) and 139 (nbsession).

Formerly, I believed BO wouldn't work on these ports but my tests, in response to a query by a correspondent, have proven otherwise. It works just fine, and seems not to interfere with any network activity. In fact, NetBIOS is not necessarily enabled on all machines.

With BO running on port 137, 138 or 139, and when Netstat is run with the -a switch, it may list these ports twice, showing both the typical NetBIOS activity (if enabled) and BO's UDP activity. However, when Netstat is run without any switch options it does not show active BOs on these ports because it ignores them by default.

Also, note that when you're offline, the NetBIOS ports are not active and Netstat will not list them. But BO (and other trojans for that matter) will typically show an open port despite the lack of a modem connection.

As BO is revised and adapted, as it inevitably will be, Netstat should remain among the most foolproof ways to spot its activity. BO — or any similar application — absolutely must use a TCP port to function, and Netstat will always reveal what ports are in use. Also, Netstat sometimes reveals the address of the remote machine that's connected to your open port. With some trojans, this may lead you directly to your intruder, but unfortunately Netstat doesn't show the remote IP on the "connectionless" UDP protocol used by BO. That requires other tools.

I recommend to anyone that they "play around" with Netstat. Get used to its displays of typical activity, for instance what it shows during a download or when your browser is fetching a web page, what it shows when Dial-Up Networking first starts without any active Net applications running, and so on. Try it right now.

Use the command

netstat /?

to see a helpful summary of its commands.

=======================
Clients, Servers, and Ports

Most Internet applications use the client/server model. At the user's end of a connection, a client program sends queries to a server, and the server gives responses back to the client. Your browser is a client and the websites you contact are servers.

Servers are also sometimes called daemons.

Most servers listen on a predefined "port." This port is not a physical connection like your modem link, but is actually a "virtual port" defined by a number. This number is contained in the data packets which are the standard format of Internet communications. Each packet contains a number indicating its source IP address and port; and its destination IP address and port. The port is represented by a 16-bit number; so in theory there are 2^¹⁶ or 65,536 possible ports.

A number of ports, mostly below number 1024, have been assigned standardized functions or protocols. Mail servers "listen" on ports 25 and 110. HTTP servers (web servers) use port 80. In general, ports below 1024 are reserved for servers of various kinds.

Clients are dynamically assigned a free port number for outgoing requests. The combination of an IP address and a port number is called a socket. The socket mechanism makes each client/server connection unique.

Protocols

Protocols are in essence sets of rules for data exchange between Network-connected computers. There are many protocols, some intended for very specific purposes.

On the Internet, all protocols utilize the underlying Internet Protocol (IP) to route messages correctly between machines. All data is sent in packets which carry IP address information.

The Transmission Control Protocol (that's the TCP in the term TCP/IP that you see so often) is the usual method to establish an ongoing and reliable link between machines. It's uswed for most ordinary web-surfing and file transfer activity on the Net. TCP allows for error correction, and for reconstruction of multiple sequential packets into larger files.

The User Datagram Protocol (UDP) is a very simple but connectionless protocol. While a TCP connection involves "negotiations" between machines — acknowledgment and verification of received data and so forth — UDP doesn't even check for the existence of the other machine. It simply sends / receives packets without added steps. It's often described as a "best-effort" transport protocol. UDP is used for applications that do not need protection against data loss.

Back Orifice uses UDP. NetBus uses TCP.

Microsoft packages MSInfo32 with its Office suite and, I believe, with some of its other applications. If you have it, MSInfo can often point an accusing finger straight at your Orifice.

If you think you may have MSInfo32, first simply try selecting Start... Run... and typing in its name, MSINFO32. If that fails, use Find... Files or Folders... to search for it by name.

If you find MSInfo and start it, simply click on Running Applications and you will see a full list with paths and filenames.

Using MSInfo's ability to view all running applications, you have a starting point to systematically track down each app if necessary and determine whether it is an Orifice. Comparing the Running Apps to files found using File Find, or those listed in the appropriate Registry key(s), is very effective.

In particular, because MSInfo displays the full path, a BO that's been located somewhere obscure may be easily unveiled. Burying BO in a sub-sub-directory of drive E: may seem clever, but that makes it stand out prominently in the MSInfo listing. Practically everything else will be on C: and/or will be easily recognized as a valid program.

Windows 98 has its own built-in utility, virtually identical in function to MSInfo and with added features. Select Start... Programs... Accessories... System Tools... System Information.

Microsoft offers the Windows 95 Kernel Toys Set for free download on its website. One of these "toys," the Windows Process Watcher — also called "Wintop," works in a manner similar to MSInfo. It displays all running applications and also monitors their use of CPU time.

I consider Wintop superior to MSInfo, and more convenient to use, for monitoring running apps. This excellent application sees constant use on my own machine.

The file can be downloaded directly from here on the Microsoft site; but I recommend visiting Microsoft's page on the Kernel Toys for more information and installation instructions. (Thanks to Julie B. for the update on Microsoft's new page location!)

I recommend installing the whole Kernel Toys package, but each Toy can be installed separately.

Unfortunately, Microsoft says the Kernel Toys are "not intended" for use under Windows 98. I suspect Wintop and the others work OK anyway. (Microsoft often wilfully discourages use of older applications it doesn't wish to support, such as MS-DOS itself. Obsolescence is its bread and butter.) One helpful person has already reported to me that Wintop does indeed work just fine on Win98.

Relying on pushbutton software tools to deal with our problems is tempting. But as BOSniffer demonstrates, that entails its own risks.

The most powerful asset any of us can possess is knowledge. Basic knowledge, brought to bear with basic tools.

These tools I've covered on this page are among the very basic and serve well to uncover any and all trojans of BO's type, as well as to provide generally greater control to the Windows user.

D3dsys.dll	... might seem an innocuous alternate filename. Works just fine.
..\.\.\nul	... will send the file harmlessly to oblivion.
..\sys.dll	... places the file in the Windows folder (but keylogging doesn't work).
Iosubsys\x	... places the file "x" in the System\Iosubsys folder (doesn't work).
readme.txt	... works just fine and the name would never arouse suspicion.