Edited 02/25/00 15:25:03
During the week of February 13, unusual network events led to the discovery of approximately sixteen computers sending out large numbers of UDP packets to random ports. All sixteen computers were running Microsoft Windows. At least five of those were running Windows 98. Further investigation revealed that all the computers were compromised with the Back Orifice remote control trojan. After removing the trojan from one of the machines, the machine was later observed participating in another UDP flood. This led to the discovery of a program running on the machine which may be a variant of the trinoo denial of service tool. The program was forwarded to CERT and a variety of anti-virus vendors for analysis.
Contrary to the SANS NewsBites email report, we have not found 160 computers with the program (note 1). In some preliminary notifications I made to a variety of sources, I said that I had found 149 computers listening on port 34555. The actual number of computers running the program may be much less due to false positives from the scanning tool. In any case, the port is blocked. Our routers have been configured since 1997 to prevent our computers from forging their source address so any packets leaving our network are easily traced back to us. Judging from log information, the computers were not used in the high profile attacks during the week of Febrary 6. All the computers found thus far have been student owned computers on the student residence network.
The appearance of this type of program for the Windows platform was just a matter of time. At one time, careless operation of a "personal" computer could result in accepting a virus that destroyed files on just that machine. Then, with the introduction of remote control trojans, careless operation of a "personal" computer could result in the compromise of all remotely accessible resources. Now, acceptance of unknown files and other risky behavior can lead to the use of a "personal" computer as an attack vehicle against any site on the Internet. The last two scenarios have, in the past, generally been the province of cracked multi-user operating systems such as unix. But today's "personal" computer is no longer the simple standalone machine it once was. The problem is made worse by the proliferation of "always-on" connections. Those innocent screen savers, pictures, and games that we once downloaded with abandon have much more ability to play havoc today.
I have not reproduced the behavior as I don't have the corresponding trinoo master program and haven't yet hand crafted a "png" packet. Also, unlike unix trinoo daemons, this program does not send a "hello" packet back to the compiled in master. This seems to point to a different mode of operation than the corresponding unix program. CERT and individuals with experience in analyzing DDOS tools currently have the program and I expect we'll soon have confirmation that the program is, indeed, a windows version of trinoo and more information about its operation.
NAI and Privacy Software, among others, have signature updates that will detect this program. Thanks should go to Privacy Software and Axent for helping me verify the trinoo signature. Privacy Software had a detection update in less than an hour! Norton has an update but as of the posting of this page, it does not appear to be included in an Internet Live Update.
Traditional anti-virus products may not detect or remove a running version of this program unless the real-time protection is enabled and the computer is rebooted. You should test your virus product to see how it operates. Caution should be exercised in using traditional anti-virus tools in a manual scan mode. Some of the products will report the infected file but not delete it even though the product will report it as being deleted. Also, regardless if the file is deleted, the running process is usually still active until the computer is rebooted. Privacy Software's BOClean product works differently and will detect the running process, disable it, remove the file, and remove the startup entry all in real time. The same situation applies for remote control trojans like Back Orifice. This behavior is because these are standalone, running processes and not virus code attached to files. The statements made herein in no way represent a commercial endorsement of any product by James Madison University.
You may also be able to mitigate risk by blocking incoming packets destined for UDP port 34555. Scanning for UDP port 34555 with something like nmap should help you identify a collection of machines that need further scrutiny. Installing router ACLs that log packets to that port will show attempts to use the compromised machines.
Symptoms here included high router CPU utilization. This may be due to the high number of filters in our routers so I don't know if others will see the same symptom. Network management equipment should be configured to alert on high levels of UDP packets per second. We saw increases of several thousand packets per second during an incident. Our incidents typically lasted for only a few minutes and were concentrated in the early morning hours.
I loaded the program on Windows NT4, Windows 98, and Windows 95 and in all cases the program ran and opened port 34555. But, again, I haven't reproduced the behavior so I don't know if the program would actually work as a DDOS tool on all platforms.
There seems to be a relationship between the Back Orifice trojan and the suspected wintrinoo. Whether the trojan was the infection agent or was delivered simultaneously with the trinoo code is unknown.
The program executable is service.exe. It listens on UDP port 34555 for trinoo style "png" packets and responds with trinoo style "PONG" packets to UDP port 35555. This activity seemed to precede an UDP flooding incident. Blocking port 34555 seems to have blocked further incidents.
The process shows up in the Windows task list which can be obtained by hitting cntrl-alt-delete. Windows NT machines run a services.exe process which is normal and should not be confused with service.exe. The process can be shut down but will restart unless the associated registry entry is removed. The entry is HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Run.
Typing the MS-DOS command "netstat -an" will also reveal if the machine is listening on port 34555.
A strings search of the executable revealed a lot of trinoo related text such as:
A collection of sites that provide information on default remote control trojan ports:
Note 1: It appears SANS had a typographic error in their report. The preliminary incident report that someone else forwarded to them stated 16 computers were found...not 160.